How I work with agents
Agentic coding gives a team speed. Left unconstrained, it also gives them a review problem. This is what I did about it.
The problem, as it actually showed up
While working for extended periods on agentic-accelerated projects, team productivity starts to decline. Not because the agents become slow, but because their output drifts from conventions, and every correction lands on whoever reviews it. Throughput goes up and delivery goes down. That is the failure mode nobody warns you about.
The fix
I encoded the architecture and review standards into a spec-driven workflow — a CLAUDE.md at the repository root that agents read before writing any code. Standards stopped being something policed after the fact and became a precondition.
It moves architecture from something we police in review to something enforced before the first line gets written.
Adoption was passive by design: the specification was consistently followed by the agents. That is a deliberately narrower claim than “I rolled it out to the team”, and it is the claim that survives a reference check.
Three enforcement layers
- Stated constraints. Architectural rules at the repository root, written as constraints rather than advice.
- Mechanical enforcement. Module boundaries as separate Swift Packages, so a wrong import will not compile; custom lint rules as CI errors rather than warnings; a build step that fails on misplaced files.
- A reference vertical slice. One hand-built path through the app, so the agent imitates a real pattern instead of inventing one.
The order matters. Layer one is advisory and agents drift from it. Layer two is the one a team can actually trust, because they do not have to trust the agent — they trust the build.
What I would ask you
- What does your agentic workflow look like in production today?
- How do you measure agent output quality?
- Who owns architecture when agents write most of the code?