This is part two on Agentic Coding. I did a video about a month ago on how to be effective with using agents to write code. Now I’m going deeper because there’s been a lot of interest and questions.
We’ve been doing this for about two-three months. Not that long. We went through a lot of pain and suffering to get to where we’re at in terms of knowing how to use it effectively. There are others out there also figuring this out. We’re not the only ones. We’re probably not the first ones. But it does have huge potential. Honestly, it’s the future of where coding is going.
Want to watch this in video format? Here is the same content over on YouTube:
Three Ways to Work with AI
There are three kinds of ways of using AI. Here’s a quick recap:
AI Assisted. This would be someone using Copilot, or maybe they’re using Cursor, or some browser window. They are using AI to help them write code. This could be writing specific functions, it could be fixing a specific bug. You’re like, “Hey, I’ve got a bug here, here’s the error, fix it.” These are like one-shot prompt assistants. I think of it like using the AI to help you pass a screwdriver. It’s the robot next to you that’s helping you out. You can do larger work with this. But you need to really know how to direct it, how to control it. This particular way of working with AI has been already used in a lot of enterprise environments. Average of about 25 to 30-ish percent performance gains. We’re not talking about that today, though. I just want to make clear what that is.
Vibe Coding. This often has no or very little setup. But the more the better actually for your success. Typically more for prototyping or internal tools. Maybe you’re an executive and your company wants a tool to do budgeting, financing overview, and you want to connect all these things. You can really replace SaaS applications with your own application. Probably not rolling this out to thousands of customers usually. Vibe coding has a lot of issues as you get further and further into trying to iterate it. But it can be really good for getting an idea out quickly as well.
Agentic Coding. This is what we’re talking about today. The AI is writing software, but it’s doing it with a network of agents, not just a single AI. You’re engaging a process, that process is what ensures the quality. It also helps you to be able to write much larger volumes of code or to do complicated code refactoring, which is traditionally really hard to do with just AI assistants. And often leads to frustration… “toss it out the window”… and go back and just write it by hand. Agentic Coding a lot more setup, so it’s not well suited to one-off coding activities.
If your client calls you up and says, “Hey, can you add another menu item on my dashboard?”: Just go in and do it. Or write it with an AI assistant, don’t approach it with Agentic Coding.
The Perception Shift
AI assistance is you’re using the AI to help you speed up. Agentic development, it’s more like a car factory where all the robots are building the car. You’re up in the little control tower monitoring, optimizing, figuring out how to code the brains of these little agents. Solving problems when they don’t work well together. You still need software engineering, but it’s a different kind of approach.
One thing I’ve been experimenting with is actually running multiples of these Agentic coding frameworks in parallel. Every single time one of them waits for me to review, the other one is going. You can achieve crazy productivity speeds when this approach is effective. You just need smart people at the head to orchestrate it, and you become an orchestrator.
Where the Tools Stand Right Now
Right now at this time of writing (we’re in February 2026) I would say personally I still find Claude Code to be the leader. Google’s Gemini is catching up. Cursor just released in January two features that were missing to kind of make it compete with Claude Code. So I think there could be potential for Cursor to start heading the race as well. Nice benefit of Cursor is that it’s model agnostic. Claude requires you to use Anthropic. When using Cursor, use whatever you want. You can even plug in your own AI models through API calls that can be very low-cost models.
Identify What Agents You Need
The first thing you’re going to need to do is identify what agents you’re going to be needing for your software development. Here is an overview of what I would say are the minimum agents that I think you need to be successful:
You need a Task Manager. This agent’s job is not to write code. It’s to structure a job, a series of tasks, and then to make sure that the other agents are doing their work. Verifying that they’re doing their work correctly. Escalating when there are issues. And you provide rules for this agent to understand when that’s true.
A good ecosystem start is a Developer, a Tester, and a Software Architect. All three of these have different objectives, and therefore different lanes. You want in general to have as few agents as possible, you don’t want to have 20 of these, since you really want to have the agents that you’re actually using. But you do want to make sure each agent has a very clear focus.
Antagonizing objectives in your agents is very helpful. AI systems want to please, so we have to make them want to please us by performing well at their functions, which should oppose one another for maximum benefit. So what I mean by that is: if you have a Developer, the Developer gets brownie points for writing effective code. The Task Manager scores best if the other agents are completing their work and reporting completions. But the Tester gets bonuses for finding problems. So it actually is antagonistic to the Developer because the Tester is going to get a pat on the back when they’re able to find more bugs or more problems.
This is healthy because you want the Tester to struggle to find problems and to say “I can’t find anything wrong” before you accept that the process can continue (and like anything, you can over-tune this, so make sure you are not going overboard or the system can get TOO nitpicky).
The Software Architect is crucial, especially for refactoring projects. I like to think of it as the “code police.” Its job is to make sure the Developer follows design patterns, doesn’t create duplicate functions, and adheres to the standards you’ve established. The Architect gets a first look at each task to set constraints and guidelines before the Developer starts. Then once the Developer is done, it reviews the output again. Like the Tester, it’s scoring points for finding problems, specifically in architecture and design.
Even with four core agents, you may find that certain tasks need their own sub-agent. For example, the Tester in our setup needs to batch-execute the software, capture log data, then validate against that output, all without a human running anything. That batch execution step became its own delegated skill. You might similarly find yourself spinning up a narrow web research agent, or a data processing agent, called by one of your core four as needed.
Commands Are Important
Once you’ve got your agents, the next most important thing to set up is your commands. Commands save you from typing out the same detailed instructions every time you want the system to continue working or generate project documents. You just run /dev-docs to kick off a new project documentation build, or /continue to pick up where you left off.
They also serve a less obvious but equally important function: they signal to the AI you’re talking to that it needs to delegate, not do. Without commands, what tends to happen is the main AI starts doing the agent work itself rather than routing it to the network. Commands prevent that almost completely. I haven’t seen the delegation problem once commands are in place. You can also add hooks and skills to extend the ecosystem further — I won’t go into those today, but worth looking into.
Documentation. Documentation. Even More Documentation.
How do you go from “we need to refactor the code” to actually executing it? Documentation. Documentation. Even more documentation. It’s kind of insane how much you need in order to get a near-zero error rate, which is the goal. The way you solve for that right now is through really extensive, well-written documentation upfront.
We’ve had the best results using an ADR — Architecture Design Requirements document format. It was a tip someone passed along and it stuck. First thing you do is write your ADR for whatever you’re building: a new feature, a major refactor, an entire application. Then you break each part of the ADR into its own sub-document. And from each of those, you create a Plan, a Task list, and a Context document. It ends up being a pyramid of documentation, four levels deep for bigger projects.
You can write the ADR yourself, write it with AI helping, or have AI write it and ask you questions. If you go the AI route, make sure someone technical is driving it — a Software Architect, a Tech Lead, or a technical Product Manager. You need someone who actually understands what’s being built, otherwise you’re just doing vibe coding with extra steps.
One more thing on ADRs: the model you use to write the documentation doesn’t have to be the same one writing the code. It’s worth testing both. For our hydraulic simulation work, Gemini outperformed Opus on the scientific modeling. On a separate client project involving tax law, Gemini again had more accurate domain knowledge. Don’t assume your default model is always the best fit. Test it upfront on documentation, benchmark a few models on smaller tasks, then scale with what works.
Write It for a Junior Developer
When you’re breaking down the ADR into steps, whether you’re doing it yourself or having AI do it, tell the AI that we’re writing this for a Junior Developer.
It sounds counterintuitive. AI is supposed to be powerful, right? But the more precise and literal your specs are, the less space the Developer agent has for interpretation. And that’s what you want. When it knows exactly what to do, it just executes. No questions, no guessing, no creative liberties. Your Tester and Architect still catch issues at the end, but there’s a lot less to catch. The goal is to find fewer problems post-implementation than you would with a human developer. If you’re not hitting that bar, the approach isn’t worth it.
Acceptance Criteria
Each step in your ADR breakdown should have clear acceptance criteria, both for the agents and for humans. At what point does a person need to step in? Maybe you want a visual check at certain milestones. Maybe the refactor has hit a stage where you want to personally verify the new design pattern was applied correctly before moving on.
I’ve also used external AI agents, completely outside the project, to independently review results. If Anthropic wrote the code, I’ll have Gemini review it. Different model, different perspective, less shared bias. It catches things the primary model family might let slide.
Acceptance criteria also defines what each agent is actually checking. What does the Tester validate? What does the Architect review? You could even add a Client UAT Agent that holds its own set of expectations and needs to see them proven before signing off. And it’s worth having the AI flag risks and edge cases upfront while writing the documentation — catching those early is a lot cheaper than finding them after implementation.
Build Dev Docs
Once your ADR and step breakdowns are done, you run /dev-docs to generate the core project documents. There are three that I consider essential.
The Plan is straightforward: what are we building and why.
The Context is where it gets interesting. This is your shared memory pool. Every agent, after completing its work, adds a note to the Context document. The next agent picks it up, reads the full history, and knows exactly where things stand. This also means if you shut down Claude Code and come back the next day, the system can resume with no context lost — it reads the Context and picks up where it left off. If agents are logging to the terminal or chat window instead of this file, you’re going to have problems.
One thing worth noting: if you as a person need to give input mid-process — you spotted an issue, you want to flag something for testing — add it to the Context document rather than jumping into the chat. This keeps you inside the process instead of breaking it. You become another contributor to the shared memory rather than a manager who just interrupted the workflow. The one caveat is that if you insert something mid-task, you can confuse the Task Manager, so be thoughtful about when and how you do it.
The Tasks document is the checklist. The Task Manager creates it: step 1.1, 1.2, 1.3, who does what, in what order. For a substantial project, a single step can generate 800 to 1,000 lines of tasks across multiple phases.
Beyond those three, a standalone Code Review document from the Architect or a Validation Report from the Tester can be useful, especially when they need to be referenced by specific tasks rather than living in the Context. What documents you need depends on the project.
An Example From Our Work
For our hydraulic simulation project, the documentation pyramid ended up four levels deep. Each sub-step of the ADR had its own documents, so we were working inside Step 1.3 of a larger Step 1.
The Task document for that step shows Phase 0 first: the Scientific Architect and Software Architect both creating their documentation before any code gets written. Phase 3 is testing — batch execution, log validation, checking that values fall within expected ranges. After that, the Architect reviews the code changes and confirms everything was applied correctly. If both the Scientific and Software Architect agents sign off, and acceptance criteria passes, checkboxes get marked complete and the step is done.
That particular step ran cleanly. No issues.
In Practice
Building your first project with an Agentic network takes real time and patience. It’s overhead, and you’re making an investment. But the lessons carry forward. By your second or third project, you know which agents work, you’ve learned where they tend to trip up, and you can preempt most of the common problems. The investment pays off across every project after.
A few things worth knowing: we still run traditional AI assistance alongside the Agentic network on bigger projects. The two approaches run in parallel but through different interfaces into the same codebase. Claude Code handles the structured Agentic work — documentation, task flow, agent coordination. We never use Claude Code’s chat to ask the AI anything directly; it’s purely for driving the network. For one-off tasks or collaborative coding where a human is actively involved, we use Cursor separately. Keeping them split prevents context corruption. If you try to use the same interface for both, you’ll end up with context rot and the system starts breaking down.
The biggest gains come from big projects. That’s where this approach earns its setup cost.
Getting Started
Claude Code is easy to find — just Google it. For a starting point on agent structure, I’d point you to the diet103/claude-code-infrastructure-showcase repository on GitHub. You can clone it and build from there. We ended up modifying a fair amount of it and added a /continue command that wasn’t included, which turned out to be one of the more useful additions for our workflow. It’s not a finished solution, but it gives you a solid foundation to see what agents look like and start iterating.
Two other resources worth looking at: Builder Methods and Human in the Loop — the latter came recently recommended to me as a complementary overlay for Agentic coding. I haven’t used it yet, but it’s on my list.
If you want to dig into this more — questions, a 30-minute conversation, or something more hands-on like workshops or implementation help — I’m happy to connect. This is something I’m genuinely excited about and would enjoy talking through with you. Thanks for reading!
Sebastian Chedal is CEO of Fountain City. We help businesses implement practical AI solutions and navigate digital transformation. We’re currently exploring agentic coding approaches across multiple project types and sharing what we learn along the way.
Fast-track your team’s transition to Agentic Coding
Reading about agentic coding is one thing; implementing it across a team is another. We offer hands-on training and implementation support to help your engineering team build their own agentic workflows, standardized documentation patterns, and automated testing rigs.
Top comments (0)