In the previous part I covered the development side — when to go solo, what not to delegate to an agent, which documents to maintain, and why modularity is non-negotiable. This part is about what happens around the code: how delivery is managed, how PRs are governed, what testing looks like now, and what compliance requires that it did not before.
The context matters: coding has traditionally accounted for 30 to 40 percent of total SDLC effort. With agentic coding that share is shrinking. Low-level design, testing, feedback cycles, and deployment are picking up the weight. The skills that matter most in delivery are shifting accordingly.
1. Ownership has to be explicit
When agents are generating code at high velocity, ambiguity about who owns what becomes a serious risk. Three roles need clear, non-overlapping ownership.
The project manager owns requirements.md end to end. In a services context where there is no dedicated business analyst, this falls to whoever understands the work and faces the customer — whatever title they hold. That person writes the acceptance criteria, validates test cases against requirements, and is available to defend or update requirements when the team challenges them. Requirements that nobody owns drift. Drifted requirements produce working software that does not solve the right problem.
The architect owns HLD, LLD, database design, and deployment. Any deviation from the planned architecture should be known to the architect before it is committed, not discovered in a review. One practical approach: the architect provides the first commit — boilerplate, folder structure, claude.md files per module — so the foundation is set before any agent-generated code arrives.
Beyond that, each developer can maintain a comment file — developername_comment.md — for the architect. It is a defense-and-update stream: the developer records what they did and why. Alongside it, an architect_comment.md on each developer’s branch holds the architect’s ongoing guidance and responses to the developer’s questions. Both files are temporary by nature and refresh with each commit, so there is no benefit in persisting them. Agents can help draft these files, but the architect reviews and owns them before they are shared. The role may be a tech lead or senior tech lead in your context. The title is less important than the ownership being explicit and unambiguous.
Developers own unit tests. No function goes to a commit without a test. This is not new as a principle, but it is more consequential now. Regression testing under agentic development requires a test suite that covers the ground the agent has covered. Without it, a fix to one part of the system can silently break another and there is no automated gate to catch it.
Testers own the CI/CD pipeline. Agents sometimes change files that were not part of the stated task — an undeclared modification to pass a failing test or resolve a stubborn bug. This is one of the more subtle failure modes of agentic development, and it is not always visible in the code itself. A tester tracking which files changed per commit, and why, is the check on this. The tester having final control over the CI/CD pipeline is what gives that check actual weight.
2. The PR volume problem is a process problem
A lead or architect in a traditional team handles three to four pull requests per week, perhaps two or three per day on a busy sprint. A developer working with an agent can push ten to twenty PRs in a single day.
Manual code review at that volume is not feasible for most people. The response is not to slow the agents down — it is to structure PRs so they can be evaluated efficiently.
Every PR in an agentic development workflow should include: which files changed and why, with a reference to the requirement if possible; what was built, linked to the relevant requirement; the status of tests at the time of the PR; and any known limitations or deliberate deviations from the plan.
A PR that arrives without this information puts the entire review burden on the reviewer. A PR that arrives with it reduces the review to a verification task rather than an investigation.
The format and milestone rules for PRs are the architect or lead’s responsibility to define before development starts, not to negotiate after the volume problem has already appeared.
3. Testing is now a gatekeeping role
Testing was always important. What has changed is the nature of the risk.
In a human-paced development team, the scope of change in any given commit is bounded by how fast a person can write code. An agent is not bounded in the same way. It can go back to an early part of the system and change it to resolve a problem that appeared much later. By the time that change surfaces in testing, it may have been layered over by several subsequent commits.
A tester in an agentic development context needs to be vigilant about scope — what changed, not just whether the feature works. Using an agent specifically to validate whether a file change was actually necessary is a legitimate and useful technique. It brings an independent perspective to a question that the coding agent has an interest in answering a particular way.
On the question of which agent to use for testing: if the development team is using one agent family, the testing team should use a different one where possible. If that is not practical, use different models within the same family. This is not a minor point. Agents have biases toward their own outputs. An agent from the same family that wrote the code is more likely to find the code acceptable than one that did not. Using a different family for testing removes that bias. The same principle applies to local models: use different model families for writing and for testing.
Unit test results should be run and reviewed before functional testing begins, not alongside it. The sequence matters — a functional test that passes on top of failing unit tests is not a reliable signal.
4. Compliance cannot be managed with prompts
This is the section most teams learn the hard way.
The instinct when working with agents is to manage access and restrictions through prompts — telling the agent what it is and is not allowed to do. This does not work as a compliance mechanism. Prompts are instructions, not enforcement. An agent operating under a prompt restriction can still take the restricted action if the access exists. Controlling access through prompts is, as a practical matter, asking the agent politely not to do something it has the technical ability to do.
The correct approach is to remove access at the infrastructure level. If an agent should not use a particular tool, API, or resource, do not give it access to that tool, API, or resource. Prompts can communicate intent. Infrastructure enforces it.
The compliance layer built around agents is not a one-time configuration. It requires ongoing maintenance in the same way that security tooling does. The ways an agent can bypass a guardrail are not static — they evolve as models change and as the systems around them change. Treat the compliance layer as something that needs regular review and updating.
On secrets: a .env file should be treated as plaintext for security purposes. The fact that it is excluded from version control does not make it safe. If you are working in a cloud environment, keep secrets in the platform’s secret management service and access them from there. If you are developing locally, load secrets into the environment explicitly each time they are needed rather than storing them in a file that persists on disk. An agent that has file system access can read a .env file. Assume that it can and plan accordingly.
The two parts together cover the full picture of what agentic development requires in practice — from the individual developer’s workflow to the team’s management and delivery structure. The technical decisions and the organisational ones are both load-bearing.
If you are thinking through how this applies to a specific project or team structure, the Idea Lab is a good place to work through the constraints before committing to an approach. For a direct conversation, contact me.
Top comments (0)