The most dangerous moment in AI-assisted development isn’t when the model gets something wrong.
Like most things in life, it’s when everything is going right and you stop paying attention.
I’ve been building a complex software project using Claude Code and Codex as my primary implementation engine. The productivity is real. The output quality, when the workflow is disciplined, is genuinely impressive.
But a few times I fell into a different mode entirely.
Prompt after prompt, change after change, no spec, no checkpoints, no Git discipline. Just vibing: chasing a goal with whatever the model suggested, iterating fast, feeling productive.
Until something broke.
And when I went to undo it, I couldn't separate the good changes from the bad ones. They were tangled together across files, across sessions, across prompts I could no longer reconstruct (and even the ones I could would not have helped, because running them again wouldn't reproduce the same code).
I had to roll back work that was correct alongside work that wasn't, with no safe way to recover what I'd lost. I built the bad outcome myself. The model just helped me get there faster.
That experience forced me to design something I’d been resisting: a structured workflow that keeps the implementation grounded and close to deterministic, even when my specs are too ambitious and my instincts are telling me to just ship.
Here’s what it looks like.
Step 1 - Plan: generate a durable spec
A slash command takes the goal and produces a structured specification as a file committed directly to the repository, not a chat artifact, not a temporary prompt. A durable, reviewable, version-controlled document that defines exactly what is about to change and why.
This matters because the spec is now part of the codebase. It can be reviewed by a human, challenged by a subagent running a critic persona, or sent to a different model entirely ( Codex, a local model) for an independent second opinion before a single line of implementation begins.
The spec is the contract. Committing it to the repo makes that contract real.
Step 2 - Decompose: break ambition into steps
Overambitious specs are where agentic workflows go wrong. A goal that sounds coherent at the planning level often requires changes across too many files, too many layers, too many concerns simultaneously (and the model loses coherence trying to hold it all).
The decompose step breaks the spec into sequential sub-specs, each targeting no more than 8 self-contained steps. Dependencies are grouped into step groups. Each step group has a simple validation gate between steps and a full validation gate at the end of the group.
The ambition doesn’t go away. It gets sequenced.
Step 3 - Apply: scoped, gated, recoverable
Implementation is scoped to single files per step. After each step: syntax check, compilation, tests. Only when the gate passes does the next step begin.
No gate, no progress.
This is the part I was skipping when I vibe-coded my way into trouble. The gates feel slow when everything is going well. They feel essential the first time something fails cleanly at step 3 instead of corrupting steps 1 through 7 simultaneously.
If this sounds familiar, it should.
It's the same discipline Terraform enforced on infrastructure a decade ago. You don't run terraform apply on a hunch. You run terraform plan first, you review exactly what is about to change, you confirm it matches your intent, and only then do you apply. The plan is reviewable, the apply is scoped, and the state is always recoverable.
There's a useful way to think about why this matters now. If an agent is a kind of fuzzy compiler (something that turns intent into working code, but non-deterministically) then the plan starts to look like our real source code, and the code itself becomes more like a build artifact. That shifts where the discipline has to live: plan is what you review and version, because it's the thing that actually captures intent. It's the same split Terraform draws between the plan you scrutinize and the state you protect.
We learned that lesson for infrastructure. We're relearning it now for code.
The difference is that a reckless terraform apply might delete a database. A reckless agentic coding session might delete your understanding of what you built - and that's much harder to restore from backup.
The workflow didn’t make me build faster. It made what I built recoverable.
There’s a version of AI-assisted development that is genuinely fast and genuinely reliable, where you can move quickly because you have checkpoints, where you can be ambitious because the ambition is sequenced, where a failure at step 4 doesn’t take steps 1, 2, and 3 down with it.
And there’s a version that feels faster (prompt after prompt, change after change) right up until the moment it isn’t.
I’ve done both. The structured version is slower to start and harder to resist bypassing. But it’s the only one where I can honestly say I know what I built, why it works, and how to reproduce it.
The insight that took me too long to internalize:
Agentic tools don’t just amplify good judgment. They amplify the absence of it too.
The workflow exists to make sure that when I’m too ambitious, too impatient, or too deep in a flow state to notice, the system catches it before I do.
Have you developed guardrails for your own agentic workflows? What forced you to build them?
Top comments (1)
I am waiting for this❤️