The Agentic Development Lifecycle - Nobody removed six controls

Chapter 5 · One thing got cheap, and six safeguards fell with it

Nobody Removed Six Controls: AI Made Writing Code Cheap, Not Safe
One thing got cheaper. Six safeguards quietly went with it.
AI coding agents can generate code, write tests, refactor modules, and implement features faster than ever. But there’s a catch: when writing code becomes cheap, the surrounding engineering practices can start to look unnecessarily expensive.
Code reviews feel like bottlenecks. Design discussions feel slow. Small changes get merged with less scrutiny. Developers begin trusting generated output because it looks plausible.
Nobody explicitly decided to remove engineering safeguards.
The economics changed, and some safeguards disappeared along with the friction they were designed to manage.
That is the problem at the heart of the Agentic Development Lifecycle (ADLC).

1. The Chesterton’s Fence Problem Imagine finding a fence in the middle of a field. You might think it is pointless. It blocks the way, slows people down, and serves no obvious purpose. So you remove it. Only later do you discover that the fence was keeping livestock out, protecting a boundary, or preventing a problem you had never encountered. Engineering processes often work the same way. A pull request, a design review, a testing requirement, or a release approval can look like overhead when everything goes well. But each may exist to prevent a particular class of failure. AI changes how quickly we can produce code. It does not automatically eliminate the risks those processes were designed to control. Before removing a process, understand which failure it was preventing.
2. Six Things That Used to Come Along With the Cost of Code When producing code required more time and effort, several useful behaviors often came with the process. As AI reduces that cost, those behaviors need to be protected deliberately.
3. Effort and care When writing a change takes significant effort, developers have an incentive to think through the problem before implementing it. When an agent can generate several alternatives in seconds, experimentation becomes easier. That is a genuine advantage. But generating more code does not necessarily mean making better decisions. Cheap implementation can encourage unnecessary changes, speculative abstractions, and solutions that solve the wrong problem.
4. Author intent A developer who writes a change manually often understands why each major decision was made. Generated code can be technically plausible without reflecting the actual intent behind the task. A reviewer may see a clean implementation while missing that the agent interpreted the requirement incorrectly. The important question is no longer just, “Does this code work?” It is also, “Does this code do what we intended?”
5. Pacing Traditional development naturally creates pauses: writing code, running tests, requesting review, responding to feedback, and preparing a release. Those pauses can provide opportunities to discover mistakes. An agent can move through several of these steps rapidly, making it tempting to compress or bypass the checkpoints. Speed is valuable. Removing every opportunity to reconsider a decision is not.
6. Trust boundaries AI agents may read repository files, inspect documentation, consume issue descriptions, and act on text supplied by external sources. Not all of that text should be trusted as instructions. A malicious or misleading instruction embedded in an issue, document, or file can attempt to redirect an agent's behavior. This is one reason prompt injection and excessive tool permissions matter in agentic development. A reliable workflow needs explicit boundaries around which instructions an agent may follow and which actions it may take.
7. Natural cleanup When changes are expensive to produce, developers may be more selective about what they add. When changes are cheap, temporary workarounds, redundant helpers, unnecessary dependencies, and unused abstractions can accumulate quickly. AI can help clean up a codebase, but cleanup does not happen automatically just because code generation has become faster. Teams need explicit checks for unnecessary complexity, duplicated logic, abandoned experiments, and changes that exceed the task's scope.
8. Learning through small tasks Small coding tasks are often how junior developers build intuition: reading existing code, making a change, seeing the consequences, and learning from review. If agents perform all the routine work, junior developers may lose some of those opportunities. The solution is not to avoid AI. It is to use it in ways that preserve learning: ask for explanations, review alternatives, predict test outcomes, and have developers justify important decisions. The common thread: these benefits were not always documented as separate controls. Some emerged naturally from the cost and pace of doing software work. When that cost changes, teams need to make those benefits intentional.
9. The Bottleneck Has Moved Suppose an engineer spends four hours implementing a feature and one hour reviewing it. Now imagine an AI agent produces a similar change in ten minutes. The code-writing stage has become much faster. But the team still needs to establish whether the change is correct, secure, maintainable, and aligned with the requirement. The bottleneck moves from producing code to evaluating and governing the result. That changes the economics of software engineering. The goal should not be to preserve every old process exactly as it was. Some manual steps may become unnecessary. Others may need to become stronger or more automated. The key distinction is between a process that was slow because code was expensive and a control that remains necessary because failure is expensive. A slow manual check might be replaceable with a reliable automated test. A security boundary cannot simply be discarded because an agent works quickly. This is the difference between a change in degree and a change in kind. AI changes the degree of effort needed to produce code. It does not change the fundamental need to control risk.
10. What Should Developers Do Differently? Instead of asking, “How can we remove friction from our AI workflow?”, ask: “What was this friction protecting, and what will protect it now?” Try this simple exercise with your team. For each process gate, document three things:

These are examples, not universal replacements. The right controls depend on your system, threat model, team, and consequences of failure.
The objective is not to add more process for its own sake.
It is to make sure that when a safeguard disappears, its purpose does not disappear with it.

1. The Real Challenge of Agentic Development AI coding tools are becoming more capable. The next challenge is designing the development lifecycle around that capability. A good agentic workflow must do more than generate working code. It must preserve intent, make decisions reviewable, respect trust boundaries, prevent unnecessary complexity, and help developers become more capable over time. Some old processes will become obsolete. Others will become more important. The hard part is knowing which is which. That is why adopting AI successfully is not just a tooling decision. It is a lifecycle-design decision. ________________________________________

Try This in Your Next Sprint
Choose one process gate your team considers slow or unnecessary.
Ask:

1. What specific failure was this gate designed to prevent?
2. Does that failure still exist when AI writes the code?
3. If we remove or automate the gate, what will provide equivalent protection?
4. How will we know the new approach is working? Do not remove the gate until you can answer the third question. Continue Reading

This article is based on Chapter 5: “What Actually Breaks” from The Agentic Development Lifecycle.
Read the full chapter: https://neam-lang.github.io/The-Agentic-Development-Lifecycle/chapters/05-what-actually-breaks.html
The next part explores the next step: once we understand which safeguards have been lost, how do we deliberately bring them back into an AI-driven development lifecycle?

Join the Discussion
Which safeguard do you think AI-assisted development teams are most likely to lose first: careful review, author intent, security boundaries, code cleanup, or developer learning?
Share your experience in the comments.
Follow along for more practical ideas on building reliable software with AI agents.