AI-Built Software, Part 3 of 7: the case for agentic coding tools like Claude Code and Codex, and the development disciplines they require
What I Mean by AI-Assisted Coding
Before I begin, it’s important that I define what I mean by “AI-assisted coding”. It can look a lot like the prompt-to-app platforms I wrote about in Part 2 of this series, but there are some important distinctions.
On the prompt-to-app platforms, you describe the app, the platform writes it (incorporating many foundational elements private to their platform) and hosts it for you on their system. The app creator may never see the code, and the result is typically a standalone app that supports a specific use case and is rarely designed for deep integration into internal business systems.
On the other hand, when I refer to AI-assisted coding, I’m describing work done within your own environment on your existing codebase (if any), running on a technology stack you control, capable of deep integration into your data and systems. The output of an AI-assisted coding session is ordinary source code, in whatever language and stack you already use, running where you run things today.
In essence, prompt-to-app removes the need for a developer, while AI-assisted coding multiplies the development resources you already have. One note on labels: in Part 1, I split these tools into assisted (a person writes the code and AI helps) and delegated (the AI writes most of it). In this article I’m using “AI-assisted coding” the way the industry does, as the umbrella for both, and I’ll say which one I mean.
As with all other AI technologies, there are many vendors rushing to this space, but a few names come up far more often than the rest. Most development environments now ship with an integrated AI assistant, often referred to as an editor assist tool (e.g., GitHub Copilot, Cursor, and the assistants now built into PhpStorm and Xcode). However, the real workhorses are the agentic coding tools, where Claude Code (Anthropic) and Codex (OpenAI) are the ones you will have heard of. That being said, the major development environments are adding agentic coding modes, so the two groups of tools are converging.
You can view the difference between the two groups of tools as this: editor assist suggests as a developer manually writes code, while agentic coding tools are handed the codebase and given a task, ultimately doing work across however many files. Risk and productivity both rise as human hands leave the keyboard.
If you have developers, it is almost certainly true that they are using one or both types of AI-assisted coding tools, whether you are aware of it or not. I’ll come back to that more in Part 6 of this series.
The Case for AI-Assisted Coding
I’ve been paid to write code, or to manage the people writing it, since 1985.
So, when AI-assisted coding came along, I looked at it with a lot of skepticism. Early on, that skepticism was justified; the tools just weren’t that good. But over the last couple of years the tools have improved to the point that I’ve changed my opinion completely.
I’ve moved my own development to agentic coding and seen productivity gains of five to ten times, and sometimes even more. I can do now in a week what would have taken a couple of months, without compromising quality, security, reliability, or performance.
Note that the gains I’m describing come from agentic coding, not editor assist. There’s nothing wrong with editor assist (it’s very useful), but it does not deliver anywhere near the productivity gains that agentic coding does. As a result, I’m going to focus on agentic coding for the remainder of this article.
The practical impact of adopting agentic coding is that a company with one or two developers now has the output of a far larger team. The backlog that sat for years is suddenly reachable, and the resulting code can absolutely be stable, enterprise-ready code.
Whether you actually get that quality is the rest of this article, because it isn’t a given.
The Case Against AI-Assisted Coding
That earlier claim about quality, security, reliability and performance comes with a large caveat. To deliver on these promises, your development process needs to be structured and disciplined.
In many small shops (and surprisingly, even a lot of larger ones) development practices are loose or ad hoc. Someone comes with a request for new functionality or a change to an internal tool, the developer sits down and writes the code according to their understanding of the request and after (some) testing, it goes into production.
In a shop like that, the tendency is to outsource the thinking to the agent: Let the agent decide what will get built, how the system is shaped, which shortcuts are fine. Ultimately, nobody ends up owning (or even understanding) the overall shape of the system, that is, the data flows or the structures that make up the foundation of the system.
An unstructured, ad hoc development process just doesn’t work with agentic coding. More accurately, it does work in the short term as new code is quickly developed and put into production, but over the long term the productivity of those tools cuts both ways: The agents will generate code on top of code on top of code, and in short order the system accumulates more technical debt than anyone can pay down and is out of control.
That outsourcing of responsibility is the biggest issue I see with agentic coding, but there is one other thing to be aware of. Most apps created by agentic code look very similar to one another, and with enough experience you can just look at an app and recognize the handiwork of agents. In many cases this isn’t an issue; the apps look and work just fine, but if you want to differentiate the app, you may need to engage someone who specializes in front-end app design.
The Structure That Makes It Work
As you’ve no doubt realized by now, I’m a strong proponent of agentic coding when the right structure is put in place. So, what does that structure look like?
You must approach agentic coding with a specific mental model. You are now the manager (or perhaps better, orchestrator) of a crew of very productive coders who will use bad business judgement and run up code debt unless someone stays right on top of them. That implies a few things. As the orchestrator, you must:
- Understand the business problem. Agents should never be put to work on a task unless you’ve given them a detailed set of requirements that both you and the requestor have read closely, refined, and agreed to.
- Have explicit development standards and conventions. Agents will happily do their own thing unless you restrict them, so you need to be explicit about things like the permitted tech stack, conventions, data structures, exception handling, logging styles, required test procedures, single source of truth. In short, write down how your shop builds software, and make the agents read it.
- Implement guardrails. You must create a three-tier boundary system that includes what the agent must always do (e.g., unit tests after every edit), when the agent must ask first (e.g., modifying database schemas), and what the agent must never do (e.g., hardcoding secrets). These conditions should include clear operational limits on what data, tools, systems, and permission levels the agent can access.
- Understand what the agents are producing. Often this means reading the code, looking at database structures, and pushing back on poor designs and implementations that don’t fit existing standards and the requirements. This is the question I said I’d keep returning to in this series: can the person responsible read and understand what was written, and do they? With agentic coding the answer to the first half is usually yes; the risk is in the second half, when a long session has touched forty files and the reading stops.
- Have a development pipeline. You should implement a full continuous integration/continuous deployment pipeline (CI/CD). This wasn’t as important when one or two people were working on the code, but when agents are pumping out code, it is imperative. At a minimum your pipeline should include source code control, branching discipline, and mandatory reviews before merges.
This may sound daunting and perhaps even constraining, especially if your development team currently operates in an ad hoc environment. But the investment in building this structure (which I’d argue should be in place anyway) is returned many times over once agents start creating high-quality code far faster than a developer ever could.
This advice is hard-won. When I started Architected Intelligence, as the only developer on staff I took shortcuts on some of these steps, even though I’d lived through seeing the benefits of implementing a strong development process in a shop with many developers. I’ve learned from that mistake, and I’m now reaping the benefits.
If your shop already works this way, with real requirements, written standards, guardrails, reviewed code and a pipeline, you don’t need any help here. The tools just made a good team faster.
Closing
Whether your developers are on your payroll or a contractor’s, it’s a virtual certainty that agentic coding is in play, and everything above applies the same way; the only difference is that you ask the questions at the quote instead of at the standup. The real question is if the appropriate structures have been built around it so that you don’t come to regret it at some point in the future.
In the next part, I’ll look at infrastructure and security when AI writes your software. The code turns out to be the easy part; where it runs, how it’s backed up, where the secrets live and who is watching it are questions you must have answers for, so that’s where we’ll go next.