Isolated Development Agents: Reinventing Waterfall With AI

A Question Too Obvious to Ask

How can something call itself an integrated development environment if the developer can't directly edit the code? After more than two decades of writing software, I didn't expect to be asking that, but the way AI coding agents are being packaged keeps raising it.

Standalone agent apps, command-line agents and conversational coding interfaces are being positioned as the future of development, and some are promoted as a replacement for the IDE itself. The workflow they assume goes like this. I describe what I want, the agent writes the code, and I evaluate the result. If something isn't quite right, I write another prompt, and then another one after that. Somewhere in that loop, the person accountable for the software has lost the ability to simply change the software.

My complaint is with that working arrangement, and not with the agents. I use them in nearly all of my development work, and they read requirements, generate implementations, run tests, cut branches and open pull requests well enough that I consider them a real advance in how software gets built.

There's a second problem that bothers me more. How do I know what the agent actually changed?

Put those two problems together and the arrangement deserves a different name than IDE. I've started calling it an isolated development agent, and the longer I look at it, the more it resembles a process the industry spent decades trying to leave behind.

I Read the Delta First

When I review any change, whether a person wrote it or an agent generated it, I start with the delta: what changed, why it changed, and what that change does to the rest of the code. Before I care how many tests passed or how confidently the agent announces it's finished, I want to see the diff. The delta is the actual change to the software. The completion summary is somebody's description of it.

Here's a hypothetical that shows why the order matters. I ask an agent to correct one validation rule on an order-creation endpoint. It reports success, the summary reads well, and all 214 tests pass. Then I look at the change set:

 src/Api/Orders/CreateOrderValidator.cs          |   6 +-
 src/Api/Middleware/AuthenticationMiddleware.cs  |  18 ++-
 src/Services/PricingService.cs                  |  22 +++--
 src/Services/InventoryService.cs                |  11 +-
 src/Services/CustomerService.cs                 |   9 +-
 src/Shared/appsettings.json                     |   3 +-
 src/Validation/IValidationRuleProvider.cs       |  41 ++++++
 7 files changed, 89 insertions(+), 21 deletions(-)

One of those seven files is the job. My reaction to the other six is immediate: why are you in the authentication middleware? That isn't in scope. You've gone off the rails.

An unexpected file isn't automatically a mistake. There may be a real dependency, or a sound architectural reason the scope had to grow. But every one of those files owes me an explanation, and the diff is where I get to ask for it before the change quietly becomes part of the solution.

My First Check, Not My Last

Agents are very good at producing plausible accounts of their own work. They will tell me what they meant to implement, which requirements they believe they satisfied and why they chose a particular design. That's useful, and it's still the agent grading its own homework. I would rather look at the evidence.

So I read in a fixed order. The changed-file list comes first, because it tells me whether the scope makes sense. Then the modifications themselves: do they address the problem I asked about, preserve the behavior I wanted kept, avoid complexity nobody needed, and leave other consumers and contracts alone? Only after that do I weigh the tests and the acceptance criteria. A passing suite tells me the tested behavior passed. The delta tells me what to question. I need both, and neither stands in for the other.

This matters more with agents than with people because an agent can change a lot of code very quickly. That speed is a gift when it understood the scope and a liability when it didn't, and watching the delta is how I stay in control of which one I'm getting. It's also why the environment around the agent matters so much.

What "Integrated" Was For

An IDE earned its name by pulling the work of development into one place: editing, navigation, debugging, compilation, test runs, dependency management, source control, and lately deployment and operational tooling. Its value came from letting me move from a failing test to a breakpoint to the offending line to a diff without carrying information between disconnected applications.

Adding an agent to that environment is a natural next step. Taking away my ability to work directly in the code is something else entirely.

Go back to a pull request that's 95 percent right. A condition needs flipping, a variable has a misleading name, or the agent misread a business rule and wrapped it in an abstraction nobody asked for. In an IDE I open the file, make the change, rerun the test and move on. In a prompt-only environment I explain the problem in prose, wait for the agent to interpret it, let it modify the code and then review the new diff. I've turned a deterministic edit into another round of probabilistic interpretation, and that round can change something that was already correct.

If an AI tool makes a simple change harder than it was before AI, I have a hard time calling it a productivity gain.

Naming the Other Thing

The name I used at the start deserves a proper definition, set next to the term it keeps getting confused with.

An IDE, an integrated development environment, is a workspace where the tools and the people involved in building software interact with the evolving solution.

An IDA, an isolated development agent, is an agent-centered setup where development work is delegated to an autonomous system and the human mostly interacts through instructions and reviews.

I chose "isolated" deliberately. An IDA often has full access to the repository, the build, the test framework and even the deployment pipeline. The isolation is in the working relationship. One participant submits instructions, another does the work out of sight, and the result comes back for evaluation.

The term describes how development happens rather than whose product it is. Tools like Claude Code and OpenAI Codex can play either role depending on how they're used. Working alongside a full editor, where I can see and change the same files, they are contributors inside an IDE. Run as a prompt-in, pull-request-out service, they behave much more like IDAs. An IDE helps me develop software, while an IDA helps me delegate development work. Both are useful. They solve different problems, and treating one as the successor to the other is where the trouble starts.

I've Seen This Movie Before

For most of my career the industry has been working its way out of sequential, siloed development. In a classic Waterfall shop, an analyst gathered requirements and handed a document to the developers. They built what they understood from it and handed the result to QA. QA logged defects, the developers fixed them, and the business finally saw the system, sometimes discovering only then that the requirements had been misunderstood from the start.

Everyone was doing their assigned job. The failure was in treating development as a chain of handoffs instead of a continuing conversation. Context leaked out at every stage, assumptions went unchallenged, feedback arrived late, and small misunderstandings compounded into expensive ones. Agile grew, in large part, out of that frustration. Its aim was never to abolish requirements or planning; it set out to shrink the distance between understanding a problem and delivering a solution.

Now lay an agent-only workflow next to that old sequence:

The diff exists, and the pull request makes it visible. It just arrives at the end, which is exactly where Waterfall's feedback arrived. The agent may finish in minutes instead of months, and that is a real improvement in execution speed. A faster handoff is still a handoff, though. I've swapped the development department for an agent and kept the process Agile was meant to fix. What I've built is Waterfall with a faster typist.

Responsibility Without Control

The pull request is where the contradiction becomes hard to ignore.

The agent implements a feature, creates a branch, touches a dozen files, runs its tests and opens a PR. Approving it is my job, and approval is supposed to mean something: a professional judgment about correctness, maintainability, security and fit. The first thing I want is the delta. I skip past the congratulatory completion message and the long narrative of how the agent approached the problem, and go straight to the files it changed and the lines that differ. I'm looking for scope creep, refactoring nobody asked for, accidental behavior changes and edits to components that should have been left alone.

Say I find a method that should be simpler, or a business rule implemented wrong. I know exactly what needs to change. In a prompt-only deployment, the route the interface offers is to issue another instruction. I'm qualified to approve the code, and the tool I'm reviewing in has no place for me to edit it.

Of course I can check out the branch in another editor, make the change, run the tests and push. So the edit is still possible; it has just been pushed outside the environment, along with the context I built up while reviewing. If finishing an ordinary review requires leaving the environment, I'd like to know what was integrated about it in the first place. The agent may be an excellent contributor. It may write better first drafts than many developers. That still doesn't make its chat window a development environment, and I don't think a developer should have to justify wanting to edit code directly.

Autonomy Is a Setting

None of this is an argument against autonomous agents. I want agents working independently when the task suits it. Updating dependencies across several projects, hunting down duplicated logic, generating a test suite or chasing an intermittent defect are all good candidates, and I have no interest in supervising every line. I do want to know what changed, and I want to be able to step in when the changes stop making sense.

An agent that touches fifteen files for a feature may be making exactly the right calls. It may also have misread the architecture and started rewriting unrelated components. The diff and the rationale behind it are how I tell those apart, and I shouldn't have to wait for "task complete" to learn the scope tripled an hour ago. Autonomy with no visibility is delegation without oversight, and I don't count that as collaboration.

A good agentic environment lets me pick my level of involvement task by task. Sometimes I hand over a whole bounded job. Sometimes I review changes as they land. Sometimes I make a three-line correction myself, and sometimes I stop the agent cold because the diff shows it heading the wrong way. I've written about earning autonomy one step at a time in Autonomy Guardrails, and the same idea applies here: a truly integrated environment supports all four modes without making me drop context or switch to a disconnected tool.

Ceremony Is Easy to Automate

I've run into a version of this in my own spec-driven work with DevSpark. I value clear requirements, explicit acceptance criteria, automated validation and evidence that a change behaves as intended, and those practices matter more when agents write large parts of the implementation. I've also watched how quickly a workflow accumulates ceremony: another planning stage, another validation gate, another review, another agent checking the previous agent, more documentation justifying work that should have been simple, until the process was taking more of my attention than the feature. I wrote about one round of that in Escaping the Scope-Creep Spiral.

Process overhead is an old problem. What AI adds is the ability to produce it at scale. An agent can write a twenty-page implementation plan in seconds, which says nothing about whether the problem needed one. It can open another pull request for a minor fix when a direct edit would have done. It can run several rounds of automated review without any guarantee the software got better, and it can produce a polished implementation summary while the diff shows it modified files it had no business touching.

That's why I keep coming back to the delta. Show me what changed, why it changed and how you validated it. If those three things aren't clear, more process isn't making the software better. It may only be making the uncertainty harder to see. I'd rather AI helped me cut unnecessary process than industrialize it.

What an Integrated Agent Session Could Look Like

The answer isn't to abandon autonomous agents or go back to purely hand-written code. I'd like the next generation of development environments to blend human and agent contributions so naturally that the boundary between them is a choice rather than an obstacle. Here's the session I have in mind, as a constructed picture rather than a product I can point to.

I'm building a substantial feature, and the agent and I share the same repository, working branch, tests and context. I ask it to implement a large slice. While it works, the diff updates in front of me. A shared service changes unexpectedly, so I ask why. Maybe it found a real dependency; I accept the reason and it carries on. Maybe it has drifted into a refactor nobody needed, in which case I stop that thread, restore the scope and redirect it, without waiting for a finished pull request to discover the problem.

Reviewing another change, I see a method I can simplify, so I edit it myself. The agent picks up my version as the current state of the code. It doesn't overwrite my correction or argue its way back to its original implementation. A failing integration test turns up another problem; the agent investigates, proposes a fix and explains the trade-off. QA finds a scenario nobody anticipated, it becomes a test case, and the implementation adjusts.

That paragraph glosses over the hardest part. When I edit a file the agent is in the middle of changing, someone's work has to win, and the agent's picture of the code goes stale the moment I touch it. An agent that keeps reasoning from a version I've already replaced will undo my fix with complete confidence. Those are the unsolved problems in this picture, and they go a long way toward explaining why so many tools fall back to the handoff: give the agent the branch, wait, review the result. The handoff is simpler to build, so it ships first, and I'd hate to see the first model to ship mistaken for the right one.

Every participant works from the same view of what changed. QA can trace a defect to the implementation and the acceptance criteria it touches, which is the connection I described in QA Was Always My Last Battle Front. The product owner can see whether the delivered behavior matches the business requirement. The build, the static analysis and the pipeline feed back continuously. Not everyone needs to read a Git diff, but the evidence of change has to be available and understandable to whoever is responsible for judging it.

By the time the pull request is ready, review confirms a set of changes everyone already understands instead of serving as the first chance to discover what happened. Nobody translates every small edit into natural language, and nobody is confused about who is accountable. The agent is a participant in the environment, not a separate development organization on the far side of a handoff.

The Developer Isn't the Bottleneck

Much of the conversation about AI coding is about reducing how much code humans write. That's reasonable. Writing code takes time, and plenty of implementation work is a good fit for automation. Behind the idea that a developer should increasingly just prompt and approve sits an assumption I disagree with. It treats direct human involvement in implementation as an inefficiency, and the developer as a bottleneck to be engineered out of the loop.

A developer's value has always been in understanding systems, challenging assumptions, spotting patterns, weighing trade-offs and turning business needs into reliable software, with typing as the visible part of that work. Working directly in the code is one of the main ways that understanding gets built and exercised. Reading a method, flipping a condition, stepping through a debugger or trying an idea in place is sometimes the fastest route to understanding the problem, and sometimes it's how the solution shows up at all.

I'm happy to automate whatever doesn't benefit from a human. I don't want tools that block human involvement where it would help. The goal is to increase what a developer can deliver, and removing the developer from development is a very different goal.

A Lesson Already Paid For

The Agile Manifesto was published in 2001. Two of its values were individuals and interactions over processes and tools, and responding to change over following a plan. Those values didn't expire when AI learned to write code. If anything, they matter more now.

AI gives me a real chance to shorten feedback loops, improve testing, speed up experiments and close the gap between a business need and working software. None of that is automatic. The same tools can keep the delta visible throughout the work, or leave me reading an implementation summary and discovering surprises at approval time. They can let me work at a higher level of abstraction, or make me negotiate with a chatbot over a one-line fix. The people who build and adopt the tools make that choice; the technology doesn't.

An isolated development agent can be a genuinely useful tool, and there are plenty of jobs where delegation and autonomous execution are exactly right. It just shouldn't be mistaken for an IDE or assumed to be the IDE's successor.

One principle has guided most of my career: solve the problem, and get out of the way. A development tool lives up to it by removing obstacles between me and the code. AI coding agents could be among the most valuable tools software engineering has ever had, and that value shows up when developers, agents, QA and the business work on one evolving solution with the delta in plain view.

The industry spent decades learning that handing requirements to another team and waiting for the result was a poor way to build software. That lesson doesn't change because the team on the other side of the handoff is now an agent. If I can't edit the code, can't watch the delta as it evolves, and can't step in when the work goes off the rails, then whatever the tool is, I'd stop calling it an IDE.

Explore More

• Shift Left Into Planning — agentic coding sped up the build; this is the case for slowing down the planning that decides what gets built
• QA Was Always My Last Battle Front — how acceptance criteria at the start of a change connect to independent validation at the end
• DevSpark Dogfooding: Escaping the Scope-Creep Spiral — what happened when my own spec-driven process started generating the complexity it was built to control
• Autonomy Guardrails: Bounding Agent Action Safely — expanding agent autonomy in steps, starting with review
• Mountains of Misunderstanding: The AI Confidence Trap — why fluent AI output makes independent checking matter more, not less