Your dev team has ADD. So does mine. Here's the other kind.

Yes, the acronym is ADD. Attention Deficit Disorder. I didn't plan it — but I'm keeping it, because it turns out to be the most accurate metaphor available for what's happening in software teams right now.

Vibe coding, unchecked AI-assisted development, and spec-driven processes that quietly lose the "why" somewhere between the product brief and the first sprint review? They produce exactly that: attention deficit behavior at the product level. Chasing shiny outputs. Losing the thread. Shipping things nobody can fully explain, defend, or trace back to a business decision.

Alignment-Driven Development is the other ADD. The one that brings the focus back.

We Gave Teams AI and Forgot to Give Them Guardrails

Andrej Karpathy coined "vibe coding" earlier this year, and the tech industry laughed and panicked in roughly equal measure. He meant it somewhat playfully — let the model cook, iterate fast, ship. In the right context, for the right project? Honestly, fine. But what happens when vibe coding meets a real product, a real business, real compliance requirements, and a real customer who paid for something specific?

You get software that works. That ships. That nobody can fully explain — and more dangerously, that nobody is formally on the hook for.

That's not a coding problem. It's a governance problem dressed up as a productivity win.

Marty Cagan spent years arguing in Inspired that product teams need genuine ownership — that product managers should own outcomes, not just manage backlogs. He was right. But here's what that argument assumed: that empowerment comes with alignment. Empowerment without alignment isn't autonomy. It's distributed chaos at a higher velocity.

The Agile manifesto gave us iteration. Scrum gave us sprints and ceremonies. Shape Up gave us an appetite and a fixed time. What none of them gave us — and what AI-accelerated development now makes urgently necessary — is a framework where every decision in the development pipeline is traceable back to a business requirement, and every person who touched that decision is identifiable and accountable.

What ADD Actually Is

ADD is not a tool. It's not another plugin for your IDE or a new Jira board configuration. It's a process philosophy that sits above your tech stack, above your AI coding assistant, and above your sprint cadence.

The core premise is simple: every choice in a product's development needs to be tested for alignment with business vision, mission, and requirements. Tech docs need to stay scoped and focused — not sprawl into engineering rabbit holes nobody asked for. Design needs to support both business intent and technical requirements — not go off on its own creative journey. And when automated coding enters the picture (which it has — let's stop pretending it hasn't), the documentation that governs those decisions becomes the audit trail that makes the software self-accountable.

This is fundamentally different from spec-driven development, which tells you what to build. ADD tells you why this specific thing — and no other thing — is being built, who decided it, and when. The spec is a snapshot. Alignment is a continuous, living process.

Simon Wardley built an entire career making strategic context visible — his Wardley Maps exist precisely because the gap between executive intent and execution reality is where most strategy goes to die. ADD applies that same instinct one layer down the stack, inside the development pipeline itself.

The Four Failure Modes ADD Is Built to Solve

If you're a CTO or engineering leader right now, you're probably living with at least one of these:

Vibe build drift. Your developers — or your AI pipelines — are technically productive but directionally unchecked. Features accumulate. The codebase grows. Nobody can draw a straight line from a business objective to what shipped last Tuesday. The output looks healthy. The alignment is quietly hemorrhaging.

Spec orphaning. You wrote great requirements. Then the build started, the spec became a historical document, and the actual product evolved in the gap between what was written and what was interpreted. The spec didn't lose — it just got abandoned. Nobody's fault. No process to prevent it.

Decision diffusion. Engineers are making product decisions because nobody else was in the room. Not because they're bad at product thinking — some are exceptional at it — but because the process never required a business or product owner to formally own and document that call. When something goes sideways, nobody knows whose decision it was.

Business blindness. The people with the most context on customer needs and business value have no real visibility into whether what's being built actually reflects that context. They get demos at the end of a sprint. They don't get pipeline visibility. By the time they see the thing, three weeks of drift have already compounded.

ADD treats all four as the same root problem: the absence of a documented, auditable alignment layer between business intent and the code that ships.

What the Pipeline Actually Looks Like

At every significant decision point in development — requirements definition, technical architecture choices, design decisions, feature scoping, AI-generated output review — ADD documents the following:

When AI-assisted or automated coding is part of the workflow — and in 2026, that's not optional, it's the default — this documentation layer does something remarkable. It makes the development journey self-documenting. The audit trail becomes mineable. Drift becomes detectable early, not in the post-mortem.

Misalignment that previously lived quietly in a codebase for weeks or months surfaces rapidly, because the documented intent and the actual execution can be continuously compared. Requirements gaps, defects, and scope creep become reactively visible — correctable during the build, not discovered at launch or, worse, by a customer filing a support ticket.

This is what Agile's retrospectives tried to approximate but could never quite achieve, because retrospectives are backward-looking by design. ADD makes misalignment visible during the journey.

Why the AI Era Makes This Non-Negotiable

Here's the uncomfortable truth that most AI productivity narratives conveniently skip: AI makes a good process faster and a bad process catastrophic.

If your team has no alignment discipline, adding an AI coding assistant doesn't amplify your output — it amplifies your drift. You ship more. You ship faster. You ship further than what the business actually needed. The velocity looks great on the dashboard. The product is quietly becoming something nobody originally decided to build.

The question that every engineering leader should be asking right now is not "how much faster can AI make my team?" It's: "If an AI wrote that code, who decided it should be written — and can I prove it?"

ADD isn't anti-AI. It's the governance layer that makes AI-assisted development responsible. It's what transforms AI-paired coding from a productivity hack into a business-grade development practice.

The teams that build this discipline first won't just ship better software. They'll ship software their business can stand behind, audit, defend in a boardroom, explain to a regulator, and evolve without losing the thread of why it exists.

The Bottom Line

We've spent fifteen years debating methodologies — waterfall vs. agile, sprints vs. Shape Up, top-down vs. empowered teams. All of it was useful. None of it solved the alignment problem, because none of it was designed for a world where AI can execute faster than humans can think.

ADD is not a replacement for those frameworks. It's what they all missed: the orchestration layer that connects business intent to development output, keeps it visible, keeps it documented, and keeps a human accountable for every decision along the way.

Vibe coding gave your product ADD.

This is the treatment.

Accountability, it turns out, is not a soft skill. It's an architecture decision.

Andrew Schwabe is a serial entrepreneur and full-stack engineer with 25+ years in EdTech, AI, and data science. He is the Chairman and Co-Founder of Saigon A.I., a comunity builder and a TEDx speaker. Stay tuned for new AI orchestration tech from him