By Jorge Orenday, Chief Revenue Officer, ArkusNexus
"Agentic AI development" gets used to describe two very different things. One is a coding agent given a prompt and a green light to ship. The other is a development cycle where agents do the drafting, planning, and implementation , but a human still has to say yes before anything moves forward. At ArkusNexus, it's the second one. Five stages, one rule: nothing advances without a human checkpoint. Here's what that actually looks like in practice, not as a diagram, but as a week of real work.
Why this distinction matters
Most of the market anxiety around AI-generated code isn't about the code , it's about who's accountable for it. If an agent can propose a change and merge it, the accountability question has no answer. If an agent can propose a change but a named person has to approve it before it moves to the next stage, the accountability question is the same as it's always been: whoever signed off owns the outcome.
That's the entire design principle behind how we run engineering work: agents handle the volume, humans hold the pen at every transition.
The five stages
1. Spec. Before any code gets written, the request gets turned into a concrete specification , what's being built, what "done" looks like, what's explicitly out of scope. An agent can draft this from a ticket or a conversation, but a human has to actually read it and agree it's right. This is the stage most teams skip when they're moving fast with AI tools, and it's the single biggest source of expensive rework later.
2. Plan. The spec becomes a sequence of concrete steps , which files change, what the approach is, what could break. Again, an agent can produce this quickly. A human decides whether the plan is sound before a single line of implementation code gets written.
3. Implement. This is where the agent does the most visible work: writing the code, running the tests it knows to run, producing a diff. It's also the stage where "agentic" gets confused with "unsupervised" , the agent is fast here, but fast isn't the same as done.
4. Review. The diff doesn't go anywhere until someone senior looks at it , not a rubber stamp, an actual review: does this match the plan, does it introduce risk the plan didn't account for, is it something a human would be comfortable putting their name on. If it doesn't hold up, it goes back, not forward.
5. Deploy. Even after review, deployment is a decision, not an automatic next step. Someone accountable says "this goes live now" , and that's a different judgment call than "this code is correct."
None of these stages are novel on their own , spec, plan, implement, review, deploy is how good engineering has always worked. What's different is that agents now do a large share of the drafting at every stage, which means the discipline of not skipping the human step matters more, not less, than it used to.
Where this actually breaks down (and why)
Most of the bad outcomes attributed to "AI-generated code" trace back to one of the five stages getting skipped, not to the code itself being poorly written:
| Stage skipped | What tends to happen |
|---|---|
| Spec | The agent builds something technically correct and functionally wrong , it solved a problem nobody quite stated |
| Plan | Implementation starts before anyone's checked whether the approach is sound; rework costs more than the time "saved" |
| Review | Code ships that passes tests but fails the judgment call a senior engineer would have made , the "it works but nobody would sign off on this" problem |
| Deploy | Release timing becomes an automation artifact instead of a decision, and there's no accountable "why did this ship now" answer |
The common failure mode isn't that agents write bad code. It's that teams under pressure to move fast start treating one or more of these five stages as optional. The stages aren't overhead , they're the mechanism by which a human stays accountable for what an agent produced.
What this looks like on a real week of work
Take a typical request: a product team asks for a new feature , say, a reporting export that a handful of customers have been asking for. An agent drafts the spec from the ticket and the surrounding conversation. A senior engineer reads it in ten minutes, catches that the ask actually implies two different export formats, not one, and corrects the spec before anything else happens. The plan comes back clean. Implementation takes an agent a fraction of the time it would take a person to type it out by hand. Review catches an edge case around empty datasets that the plan hadn't accounted for , back it goes, not to a person to manually fix, but to the agent, with the note attached. The second pass clears review. A human decides it's a low-risk Friday-morning deploy, not a Friday-afternoon one, and it ships.
Nothing about that week required the team to "trust the AI." It required the team to trust a process that happens to use AI at four of its five stages.
Frequently asked
Does an agent ever ship code without a human reviewing it first?
No. Every change passes through a human checkpoint before it moves to the next stage, and specifically before anything reaches production. The agent's speed is in drafting and iterating , the accountability for what ships stays with a person.
Is this the same as "vibe coding"?
No. Vibe coding typically means letting an agent generate and often merge code with minimal structured review. The cycle described here is closer to how a disciplined engineering team has always worked : spec, plan, implement, review, deploy : with agents doing more of the drafting at each stage, not replacing the checkpoints.
How is this different from traditional staff augmentation?
Staff augmentation is about adding headcount to an existing process. This is about running a specific process : the same five-stage cycle : with a senior team built to work inside it. We'll go deeper on how that comparison actually breaks down in a follow-up post.
Does moving faster with agents mean cutting corners on quality?
The opposite is the intent: agents remove the time cost of drafting specs, plans, and implementations, which makes it more feasible, not less, to actually do all five stages properly on every change : instead of skipping the ones that feel like they're "just process."
ArkusNexus has been building software for 23+ years and works with a senior engineering bench of 250+ engineers across the Pod model : four senior roles running each engagement, not a rotating pool of contractors.
