Have you tried Plan Mode and want to get more out of your AI agents for software engineering?

This blog post walks you through my experience as a skeptic of AI for serious coding to a pragmatic user. If you want to skip to more modern (2026) findings, skip to either Plan Mode or Skills to skip some of the background context. 

I've been a professional full stack engineer working primarily with Python and JS to build Django apps since 2014. I'm also an avid guitar player and mountain biker. I love learning in varied domains and connecting the dots between different concepts to build more holistic understanding of my world.

I am currently the tech lead and engineering manager for the Inpatient Clinical Staffing team at LeanTaaS, building software to help ensure patients have the right staff in place at the right time to provide them with the best care possible. Despite the leadership position, I like to get my hands dirty and build as much as I can 

I enjoy playing with other languages and tools outside of work to see how problems can be solved in different fashions and understand the tradeoffs you make with given tool choices.

Like many of my contemporaries in the software engineering world, I was initially impressed and then skeptical when generative AI came into our collective consciousness with ChatGPT in late 2022/early 2023. It seemed to have some interesting use cases, but they were limited and prone to problems. The initial use case that piqued my curiosity was using AI for writing regexes, something I had done myself for a while, but was time consuming and error prone. I could ask ChatGPT for a regex to catch certain things and then check its work with a handful of test cases I had in mind using unit tests and other tools.

The initial novelty faded quickly after I got access to Codieum and then Copilot through work in PyCharm, my daily driver IDE. I found these tools generated quite a bit of nonsense. Worse still, they took a while to produce this and hijacked my normal usage of the tab key with their unpredictable delay while I tried to write code, injecting that nonsense into my stream of thought in a manner that was disruptive and unhelpful.

I soon found myself turning off the tools and going back to writing things by hand, and using the Copilot chat for certain asks. One early conversation there that sparked my curiosity a bit further was asking Copilot to help suggest a refactor from dictionaries to dataclasses, which it aced. 

However, this was before the more current integrations with the editor and I had to copy and paste this code from the chat window into the actual code which felt brittle and potentially error prone to refactor this code correctly. This moment did illustrate the promise of the tools, and had me hopeful for what was to come.

Before I talk about Cursor myself, let me get this out of the way: I'm an avowed JetBrains fanboy. I love their tools, they made me a much more effective developer and I have a soft spot for how they work. I had heard through some friends and reading in the usual software engineering spots on Reddit and Hacker News that Cursor was making waves and was much more effective than the other tools I tried.

I only used VSCode previously when working with languages that didn't have first class JetBrains support, primarily Elixir. Elixir is a language I have a soft spot for and often experiment with in my spare time ever since watching Saša Juric's seminal talk: The Soul of Erlang and Elixir. After working through Saša's excellent book, Elixir In Action, I had been working to learn more Elixir by using CodeCrafter's challenges, namely Build an HTTP Server and Create Your Own Redis. These projects were an excellent way to test and further my understanding of concepts from the book, but I was an Elixir novice still.

While working through the Redis project in VSCode, I figured I'd try Cursor given the buzz around it. I wanted to use a Cursor Rule to try to get LLMs to help me write idiomatic Elixir code, as a more experienced engineer would. This was in early 2025, prior to Plan Mode or Ask Mode existing in Cursor and while it spit out (mostly) working code and used some patterns that had more effective control flow than I had written with my primitive Elixir skills, I found I wasn't learning quite as well and it often wrote code that didn't meet the requirements I had asked of it.

Where Cursor did shine however, was how it showed you what it had actually changed. It made reviewing the work done by the AI simpler, but this was still frustrating across files. Since we adopted Cursor at work shortly after this, Cursor has made many improvements to reviewing GenAI produced code and this has been one of the biggest unlocks with the tools to becoming actually useful for experienced developers.

Additionally, Cursor's tab completions were wildly better than my previous experience with other tools. I found it addictive to start working on an idea, have the tab completion be correct, and then jump around the file implementing related code.

Late in 2025, I asked my CTO about how he found using Cursor, as I thought it was useful, but I still had a lot of frustrations with it. He asked me one simple question that led to a step change in how useful the tools were for me:

"Have you tried Plan Mode?"

I was a bit skeptical at first. He also suggested a couple of models he was having better success with at the time. Combining Plan Mode with these models made me actually see the deeper use of the tools.

Plan Mode with more powerful models was like having another engineer you could rubber duck ideas with and much more deeply explore the codebase. I found myself using the tools more heavily for design work, even if I did a fair bit of the actual coding myself still.

One breakout moment was the Friday before Thanksgiving 2025, a team member on our outbound team asked for an internal tool to save her a lot of manual entry, as otherwise she'd have to work over Thanksgiving break.

I used Plan Mode to design, build, and test in a few hours instead of 2 or so days of development. I had a similar feature that I was able to direct the AI to model the new feature around and used the older feature's tests as a model to follow as well.

We deployed the feature that same Friday as a staff only tool, that coworker was able to use the tool and didn't have to work over break.

Plan mode taught me that it's all about giving AI the context to do a job correctly, similar to how I might delegate an implementation task as a tech lead. I learned to give the models existing examples of similar solutions and patterns, using language to describe how a design could be shaped and potential alternate approaches.

Treat the plan that is produced in the same way you would evaluate another engineer coming to you with a design spec.

While I did find Plan Mode in Cursor and Claude Code quite helpful, I was finding it a bit irritating to keep having to tag files and rebuild similar prompts to give the AI context. Being an engineer, I started hunting for tools or abstractions that would help me solve the pattern now that I had seen it emerge in the wild with a particular shape. Always stick to the rule of three, not just for code, but also for your own processes.

This brings me to skills, one of the more useful tools to emerge recently and an open standard that seems to be supported by each of the bigger players: Cursor, Claude Code, and Codex.

Skills have a beautiful design aspect compared to older standards like rules and commands in that they facilitate progressive disclosure. Your main SKILL.md file can be pretty thin and have reference files to certain details. Think about carving up bigger reference skills into specific reference files and provide common actions in a file like cookbook.md.

You can go a step further by having some of your domain knowledge skills reference other domains if there is crossover. Keeping the main SKILL.md files tight and providing effective reference tables to the other files in a skill lets you share and refactor skill info in the same way you would with regular code. Keep reference skills light on things that can drift and prefer code anchors and generalized patterns to follow.

Skills can also allow AI to perform a repeated set of actions, similar to how you as an engineer might have a runbook to do a manual process or write scripts to do an action. On that note, skills can even invoke scripts to facilitate other text instructions you have in your runbook. Think about how you might first write a script to get details from an API, then use natural language to describe what you might do with that result in a way that might be difficult to simply script.

Let's talk about an action skill that I found has been a real help to my workflow as a tech lead.

As the tech lead of my team, I'm responsible for reviewing a lot of code. The clients my team serves are hospitals and by nature hospitals are a 24/7/365 operation. The domain we work in has a fair bit of complexity and I wanted to build something to augment my capabilities as a reviewer. This brought me down the rabbit hole of building my own code review agent using skills.

Yes, there are tools you can buy for this, but the best way to learn about something is to build it yourself. The code review skill contained the following:

These aided the tool along the way, but we must discuss how these code review guidelines were shaped. As new feedback came up in human code review or bugs were fixed in production, my team and I would ask ourselves the question:

"How can we get the code review tool to spot this?"

Your eval process does not have to be super sophisticated to get powerful results. Oftentimes, we would simply take a commit where a problem was identified, and try different variations of guidelines, running them through the code review skill to see if the agent detected the problem. It can be as simple as doing this A/B testing locally yourself.

From an organizational behavior point of view, the powerful side effect of building code review tooling in house is the engineers in the team are learning the finer points of AI usage on a problem that they are invested in solving. No one wants to have to drop what they are doing to deal with a production issue, so it's a good entry point to get other engineers who are newer to AI tooling to learn and document their domain context for AI. This leads to more effective code reviews as the  Engineers can quickly see building skills is not magic and is actually a relatively simple proposition after seeing other curated examples.

Now that we've discussed different ways of building up context for AI to be more effective, let's talk about how to protect your precious context window for a given task. Context management is your chief concern as you get further into building with AI to improve the quality of your agent's work. Too much context is bad for a given agent in a way that is similar to giving a human way too much information, especially if not all of it is relevant.
 
If your product manager gave you a ticket with every detail from a customer call instead of just the salient feature ask or bug report, think of how you would feel trying to parse that ticket.

Thinking about how to share context between tasks is the next step along the way. The easiest way to do this is to write output files from your skills as you finish a task. This is how Plan Mode is effective and leads to the right thing being built. 

A key consideration for bigger pieces of work is to figure out how you can decompose them. Can you have a larger file that has various stages to implement a bigger feature with stages to implement them in. You can then use Plan Mode to work with an agent on the best way to implement that specific part of the feature, to keep a tight and clean context. Experiment with different scopes of task to find the best breakdown here.

Subagents are another way to protect task context by having a child agent perform a task with a fresh context window and then pass its findings to the parent agent. The major tools have built-in subagents for different tasks, but one I'd like to highlight is for file exploration. This allows the subagent to fill its context windows with many different files and pieces of code, but it can then summarize the patterns it sees and hand this compressed output to the parent agent, without the parent context window being filled up with that exploration.

For my code review example, we worked on a subagent for code review. We aimed to have the review broken up by domain, having the subagent read a table of different domains (e.g. FE, BE, feature specific domains, etc) mapped to relevant domain skills the subagent should load and then have it receive a relevant part of the diff. The code review subagent would explore related files and use the domain specific context to provide a more detailed review of given parts of the code. The parent agent would then receive findings from the subagents, along with what they called out as needing an integration pass. The parent agent would then do a cross cutting integration review based on all these findings from the subagents.

There are a few things to be very careful about here:

A lot of AI tooling is moving fast and much of this may be outdated later in 2026. My hope is that this gives you an idea of how to go from being a skeptical, frustrated user of the tools to someone who finds pragmatic usage of the tools divorced from the hype.

Keep your eye on how your AI tooling gets context and use fresh clean context whenever you start running into AI doing silly things. Happy hacking!