Your dev team has ADD. So does mine. Here's the other kind. 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. works ships nobody can fully explain 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. Inspired 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. urgently 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. above 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. every choice in a product's development needs to be tested for alignment with business vision, mission, and requirements. 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. what why this specific thing who when 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. visible 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. Vibe build drift. 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. Spec orphaning. 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. Decision diffusion. 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. Business blindness. 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: Who made or approved this decision
What the decision was (and what alternatives were on the table)
When it was made
Why it aligns with the stated business vision and requirements Who made or approved this decision Who What the decision was (and what alternatives were on the table) What When it was made When Why it aligns with the stated business vision and requirements Why 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. It makes the development journey self-documenting. 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. reactively visible 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. during 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. 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. responsible 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. 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 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

This story contains new, firsthand information uncovered by the writer.

Urgency as Office Culture (duh, AI makes it worse)

Read My Stories

Alignment-Driven Development: The Orchestration Framework AI-Paired Coding Forgot to Build

About Author

Comments

TOPICS

THIS ARTICLE WAS FEATURED IN

Related Stories

⚠️Calling All Brains! ⚠️GenAI Misconceptions!

AI-Assisted Coding with Tabnine

DOE v. Github: Code Stored on GitHub Ultimately Belong to Their Authors

DOE v. Github: Defendants' Conduct Raises Questions Related to DMCA Violations, Privacy, Data Breach

DOE v. Github: Defendants Never Sought Permission to Use Others' Code to Train Codex or Copilot

DOE v. Github: Lawsuit Falls Under California's Jurisdiction Because of GitHub & OpenAI's HQ

⚠️Calling All Brains! ⚠️GenAI Misconceptions!

AI-Assisted Coding with Tabnine

DOE v. Github: Code Stored on GitHub Ultimately Belong to Their Authors

DOE v. Github: Defendants' Conduct Raises Questions Related to DMCA Violations, Privacy, Data Breach

DOE v. Github: Defendants Never Sought Permission to Use Others' Code to Train Codex or Copilot

DOE v. Github: Lawsuit Falls Under California's Jurisdiction Because of GitHub & OpenAI's HQ

Light-Mode

Classic

Newspaper

Minty

Dark-Mode

Neon Noir

Minty

HN StartUps