Most engineering teams that bring AI agents into their workflow hit the same uncomfortable week. Throughput goes up dramatically. Four hundred lines appear in two minutes, they work, the tests pass. Three days later nobody on the team can explain why that function exists, what alternative was rejected, or what breaks if you roll it back.
The agent isn't at fault. Most engineering processes quietly assumed that writing code was slow, and that friction was the thinking time. Remove it and you discover something uncomfortable: you never had an explicit decision mechanism. You had an implicit one made of drag.
So at Aztia we did the boring thing and put the rigor where friction used to sit. We run spec-driven development, meaning the specification gets written before the code, and we work with AI agents inside the flow under explicit human approval at every irreversible step.
We learned all of this building Hura, our technical assessment platform. A recruiter pastes in the job description, and the platform generates the test, grades it, and compares candidates, without needing an engineer to give up an afternoon. The first working prototype took two weeks. Keeping it alive afterward is what demands process.
Every feature starts as a written spec, versioned in the same repository as the code. Not in a separate tool, not in a doc someone maintains by hand. In the repo, under the same review cycle as everything else.
The phases are numbered and they don't change:
Spec. The problem, what's in and out of scope, what "correct" looks like.
Technical design. The shape of the solution and the alternatives we rejected, with reasons.
Implementation plan. The work split into reviewable blocks.
Test plan. What proves it works, including the cases we expect to fail.
Deploy plan. How it reaches production and how it comes back.
Between phases sits a phase gate: an objective checklist you either satisfy or you don't. It isn't a meeting and it isn't an opinion. The practical consequence is blunt and useful: no code gets written for a block until that block's spec is approved.
That sounds bureaucratic until you put it against a real week. A block-level spec is usually short. What it prevents is the scenario where an agent, or a person, ships an elegant implementation of the wrong reading of the problem.
This is the part people ask about most. The rule is easy to state: AI for speed, humans for judgment, with explicit approval at every irreversible step. Day to day, irreversible means four things:
pushing to a shared branch
opening a PR
any deploy
any database change
Everything else runs at whatever speed the agent gives us: exploring, drafting specs, generating tests, refactoring locally, proposing three competing designs. We have very little interest in slowing that down. We have enormous interest in nothing crossing that line without a person saying yes, knowingly.
We also have a review rule worth saying out loud, because it holds up everything else: "the AI wrote it" is never an accepted answer in a code review. We mark agent co-authorship in the git history so we know what came from where, and the diff still gets reviewed by a person who answers for it. The traceability is there for auditing, not for assigning blame.
The other half of that discipline is change size: one bug per PR, one feature per PR. Small, reviewable, reversible. When generated code volume goes up, a human reviewer's only realistic defense is that the diff fits in their head. A 900-line PR doesn't get reviewed. It gets approved.
The upside is easy to point at.
Auditable decisions. Six months later, "why is this like this?" has an answer in the repo instead of in someone's memory. That includes the alternatives we rejected, which is usually the most valuable part and the first thing lost.
Reversible by default. When every PR does one thing and every deploy plan includes the way back, rolling back stops being an event and becomes a routine operation.
An agent that works better. This one we didn't see coming. A well-written spec happens to be excellent context for an AI agent. The same document that forces the team to think before typing is what makes the agent produce something close to what we wanted. The rigor wasn't a tax on AI. It was the missing input.
And the costs, because an article about process that only lists the wins is worth nothing:
The ramp is slower and it feels bad. For the first few weeks there's real tension between "I already know what to build, let me build it" and the spec phase. That tension never fully goes away. We absorb it because the cost is paid once and the return arrives with every incident we didn't have.
Not everything deserves the full process. A copy change, a config tweak, an exploratory spike don't need five phases. Apply the whole ceremony to everything and the team learns to route around it, and the process then dies of disrespect rather than disagreement. We scale spec depth to the risk of the change, not its size.
Phase gates only work if they're objective. A gate that says "the spec should be good" isn't a gate. A gate that says "the spec lists error cases and acceptance criteria" is. Every time one of ours drifted toward subjective, it stopped stopping anything.
If you're adding AI agents to your workflow and your team feels faster but understands less, the model probably isn't the issue. Your process was leaning on the slowness of typing code to buy thinking time. Write the spec first, version it next to the code, define objective checklists between phases, name which steps are irreversible and require a human yes, and never let "the AI wrote it" stand as an argument in review. That's the line between accelerating and losing control.
About Aztia. We're a software development firm. We build Hura, our technical assessment platform (huraapp.com), holding ourselves to the same process we describe in this series. More at aztia.co
Thirty minutes, no pitch. Tell us what you're building.
Talk to us →