Search for a command to run...
Series
Four series of The Pragmatic Stack have explored the architecture and operation of LLM-powered systems: the discipline inside the agent, the systems around it, the operational practices that keep those systems running in production, and the .NET runtime used to implement them.
All four series focused on systems that contain agents or agents that serve users.
Series 5 examines a different kind of agent: one that opens your repository, understands your codebase, makes changes, and commits code.
Coding agents are more than a new developer experience. They are a new actor in the software delivery system.
Most delivery systems, including repositories, task backlogs, branching strategies, test suites, review processes, and deployment pipelines, were designed around human authors. Introducing automated authors changes the assumptions behind those systems. Some of those assumptions will need to evolve.
Engineering With Coding Agents is a six article series focused on what needs to change and how engineering teams can adapt.
This is the fifth series in The Pragmatic Stack.
Series 1, Architecting Agents, covered the discipline inside an agent.
Series 2, System Design, Reimagined, covered the systems around the agent.
Series 3, Shipping AI Systems, covered how those systems are operated in production.
Series 4, AI for the .NET Architect, covered what all of the above looks like in .NET.
Series 5, Engineering With Coding Agents, covers what your software delivery system needs to handle agents as authors.
What You Will Learn
By the end of the series, you will have:
A framework for making any repository legible to a coding agent without creating an extensive instruction manual.
A task contract format that prevents vague intent from becoming production code faster than the team can identify and correct it.
An isolation model for parallel coding agent work based on one branch, one worktree, and one environment per task.
A six layer verification ladder that distinguishes software correctness from LLM benchmark performance.
A code review approach designed for generated diffs at scale, with an emphasis on risk, provenance, and test evidence.
A seven stage delivery loop that produces accepted, verified, and reviewable changes rather than raw generated output.
The Articles
The Repository Is the Prompt: Preparing a Codebase for Coding Agents
The Ticket Is the Contract: Specifying Work for Coding Agents
One Agent, One Worktree: Isolation and Concurrency for Coding Agents
Tests Are the Verification Layer: Proving Agent Generated Changes
Reviewing Code Nobody Typed: Human Judgment in an Agentic Workflow
The Pull Request Is the Product: A Delivery System for Coding Agents
Read the articles in order if you are building an agent ready delivery system from the ground up. If your organization has already begun adopting coding agents, start with the article that addresses the constraint you are currently encountering.
The agent writes the code. The delivery system determines what reaches production.
A coding agent did not fail to read the documentation. The repository stopped producing documentation years ago. Apparently, intelligence was expected to compensate for archaeology.
The team called this agent unpredictability. The ticket was six words long.
Within a month there are several teams, several tools, several permission models, and several definitions of done. Management asks how much faster engineering has become. Nobody can say, but the token dashboard is exceptionally detailed.
A pull request arrives with thirty seven changed files, polished comments, and a description that explains the architecture with unusual confidence. The reviewer approves it. Two days later the team finds the bypassed authorization rule. Nothing looked careless. That was part of the problem.
The coding agent reports that the feature is complete. The project compiles. Four tests pass. The fifth was deleted because it represented legacy behavior. This is one way to achieve a green build.
Three coding agents start from the same checkout and finish in the filesystem they happen to inherit. Parallel coding is not primarily a coordination problem. It is first an isolation problem.
