AI coding tools are incredible. And dangerous.

They make it easy to build systems nobody fully understands. I've shipped features in hours that later required weeks to untangle. The core problem isn't the tools themselves — it's the speed they enable.

When code can be written instantly, the friction that once protected good engineering practices disappears.

Without that friction, building poorly architected systems becomes surprisingly easy.

The Catalyst

A quote from the OpenCode team resonated with me:

"We shipped features we shouldn't have and left the code worse than we found it."

This reflects a predictable pattern — AI tools patch around flawed designs rather than identifying fundamental problems. The result: working code with no clear understanding of why it functions.

The paradox is real. Speed doesn't improve thinking; it can actually worsen it. A two-hour build might require two months of untangling later.

That realization prompted me to experiment with maintaining AI development speed while preserving engineering discipline.

The AI Engineering Loop

I developed a structured workflow consisting of six phases:

  1. Plan — Design work before coding begins
  2. Cross-Model Critique — Gather multiple AI perspectives
  3. Iterate Until Convergence — Refine designs until criticisms stabilize
  4. Implement in Phases — Build methodically
  5. Validate — Run automated and manual checks
  6. Reconcile With the Plan — Verify implementation matches specifications

Plan First — Always

AI does not write code until a plan exists.

Plans must include:

AI tools enthusiastically over-engineer. Clear scope boundaries prevent unnecessary complexity.

Before requesting code generation, I specify: "First write a plan. Break it into phases. Each phase needs automated verification steps and manual validation steps. Include a section titled 'What We're NOT Doing.' Do not write any code until I approve the plan."

Never Trust Single Perspectives

Different AI models identify different problems — one notices architecture weaknesses, another catches edge cases, another flags unclear requirements. Cross-model critique exposes design flaws faster.

I write plans using one tool, then ask another: "Review this as a skeptical senior architect. What assumptions are risky? What would break at scale?"

Iterate Until Criticism Stops

Multiple review rounds yield a predictable progression: structural problems first, then edge cases, then minor flaws.

When feedback shrinks from major concerns to nitpicks, convergence has occurred — mirroring how experienced engineers refine designs together, but in minutes instead of days.

Reconcile Plan With Reality

Design drift occurs when plans diverge from actual implementation. This is the step most people skip.

Before finishing any feature, I verify: "Review this plan item by item and verify what has actually been implemented. Be skeptical."

The gap between what you planned and what you built is where the worst bugs hide.

The Complete Framework

  1. Plan — design before coding
  2. Critique — multiple perspectives
  3. Iterate — refine until convergence
  4. Implement — phase by phase
  5. Validate — automated and manual checks
  6. Reconcile — verify reality matches design

AI provides velocity; humans provide judgment. Tools automate workflow, but discipline prevents poor architecture.

The Real Lesson

The OpenCode confession wasn't about tools being bad — it was about removing friction from processes that depended on it.

Code reviews, planning, architecture discussions — they felt like overhead but were actually load-bearing walls. Remove them and the structure collapses, no matter how fast you can build.

The goal isn't abandoning AI tools. It's rebuilding safeguards that work with speed rather than against it.

Our job now is to make sure we think just as fast as we build.

Have AI coding tools made your development cleaner or messier? What guardrails have you found that prevent speed from becoming chaos? I'd love to hear what's working — or what isn't.