The Stages of Judgment-Driven Development
Most of the pain I’ve seen in software wasn’t caused by bad code. It was caused by bad decisions that were never treated explicitly as such.
In the last two posts, I argued that execution is no longer the bottleneck. AI made building cheap. Judgment is now the scarce resource. If that’s true, the way we develop software must change, not in terminology or ceremonies, but in where and how we place judgment.
When I started thinking about Judgment Driven Development (JDD), I didn’t start with stages. I started with that observation and asked: Where does judgment actually need to sit? What happens if we design around that?
It starts before code: Defining Intent
The first mistake in the AI era is starting too fast. We now have the ability to go from idea to prototype in an afternoon. That’s exhilarating, and reckless if misused.
Before a single line of code is generated, someone has to answer a harder question: Should this exist?
The question isn’t whether we can build it, or how cool it would be, but whether it should exist, and under what constraints? Who is it for? What risk are we willing to take? Under what condition do we stop?
AI can generate options, simulate competitors, or propose positioning. But it cannot define intent. It cannot set the risk appetite. It cannot decide what trade-offs are acceptable for your business. If intent is fuzzy, execution only amplifies the confusion.
The first stage of JDD is simple: define intent and boundaries explicitly, before the system grows momentum.
Then move fast, on purpose: The Discovery Phase
Once intent is clear, move fast. This is where “vibe coding”, rapid, AI-assisted prototyping with minimal upfront architecture, shines.
Generate the prototype. Let AI scaffold the backend. Let designers shape something real rather than stare at static mocks. Let developers explore without friction. But treat this as exploration, not endorsement.
The scope of impact must stay low. This is the realm of “Two-Way Doors”, decisions that are easy to reverse. Use sandbox environments, feature flags, and internal builds.
This stage is about learning, not shipping. AI is an accelerator here, and that’s exactly where it belongs.
The mistake is assuming that because something works in a sandbox, it deserves to survive in production.
Validate structure, not just demos: The Uncomfortable Stage
This is the uncomfortable part. The prototype works. It demos well. People are excited. This is usually where organizations confuse “it works” with “it’s viable.”
Now the system has to survive reality: scale, security, data integrity, regulatory constraints, and long-term maintainability. These are the things that never show up in a three-minute demo.
This is no longer vibe territory; this is structural judgment.
Someone has to look at the generated system and ask: Does this align with our architecture? Are we accumulating technical and ethical debt? If this becomes core infrastructure, will we regret today’s shortcuts six months from now?
AI can scan for vulnerabilities or suggest refactors, but it cannot decide if a system is structurally sound within your specific context.
This is where experienced engineers earn their place, not by writing every line, but by using their “red pen” to decide what survives and what gets rewritten.
Shipping is a judgment call, not a technical milestone
We like to treat releases as technical events. They aren’t.
At some point, someone has to say: The trade-offs are understood. The downstream consequences are acceptable. This is ready. And more importantly: This is on me. Not ’the team decided.’ Not ’the AI generated it.’ Not ‘we’ll fix it later.’
Accountability has to have a name attached to it.
AI can automate deployment and monitor for anomalies, but it cannot absorb responsibility. If no one is clearly accountable for a release, you don’t have velocity; you have diffusion.
What’s actually different here?
A fair question: isn’t this just good engineering management? Partly. The principles aren’t new, but the failure mode is.
When execution was expensive, bad judgment slowed you down. You’d waste quarters, painful, but recoverable. When execution is nearly free, bad judgment scales. You ship the wrong thing faster and create complexity that no one authorized, but everyone inherits.
Traditional development optimized for execution efficiency (protecting developer time). JDD optimizes for decision quality because that’s where the leverage moved.
Not every decision needs senior involvement; most shouldn’t. Small decisions should move fast and be owned locally; that’s how people grow. Large decisions, those with consequences that outlast the sprint, must slow down and sit with people who understand long-term implications.
JDD isn’t about adding friction everywhere. It’s about placing friction precisely where it prevents expensive mistakes.
The Shift in Roles
In this model, roles evolve from producing artifacts to curating outcomes:
Product Managers: No longer just write specs. They define intent and constraints, and generate the first working expression of that intent.
Designers: Work on living systems instead of static artifacts.
Developers: Shift from “authors” to “editors-in-chief,” ensuring the generated code isn’t just functional, but sustainable, secure, and architecturally sound.
The Core Principle
Judgment Driven Development rests on one principle: Speed is safe only when accountability is explicit.
AI gives us extraordinary acceleration, but acceleration without structured judgment leads to systems we can build but cannot live with.
JDD doesn’t slow innovation; it protects it.
In the next post, I’ll go deeper into what makes all of this sustainable: memory. Because AI without memory doesn’t just move fast, it helps you repeat the same mistakes faster.