Over the last two years, AI went from a curiosity to the default across our org. Engineers were using agents to write PRs, fix bugs, and generate documentation, whilst product managers vibe coded prototypes and leaders built internal tools over lunch. It was decentralized in the truest sense, everyone experimenting, with no coordination layer underneath.

The results were predictable: a lot of AI slop, a steep learning curve, and a growing pile of code that worked but that we didn’t fully understand. We ran hackathons, carved out AI budget and that was only the beginning.

What actually moved the needle was crowdsourcing the learnings. Teams started comparing notes, surfacing what worked and what didn’t, and gradually we established team-level rules and a set of best practices that stuck. We didn’t have a name for it at the time, but looking back, we were already living the AI-DLC methodology before we’d ever heard of it.

Not All Automation Is Created Equal

The conversation around AI in engineering pipelines treats automation as binary, as though the only question is whether to trust AI or not. Confidence should be task-specific: some things AI handles beautifully right now, and others it isn’t ready to own without supervision.

The pattern that works: automate aggressively on the left side of that spectrum, and invest in better tooling on the right side. The teams getting burned are the ones sprinting toward full autonomy everywhere because it demos better, which is exactly how we end up jolted awake by a PagerDuty alert, squinting at a screen full of AI decisions with no audit trail.

The Vibe Coding Problem

Vibe coding is exhilarating. I’ve watched friends who’ve never written a line of code ship working apps in an afternoon, product managers prototyping features faster than their engineering teams can scope them, and leaders who used to wait for quarterly roadmaps suddenly building tools over a weekend. The dopamine rush is real, and it should be. The interesting question now is what comes after the dopamine: how do we take that energy and channel it into something that holds up at scale?

Production-grade code goes beyond functioning; it reflects an understanding of failure modes, edge cases at scale, and the reasoning behind architectural choices. That kind of context, built from years of scar tissue from production incidents, can’t be captured in a prompt.

Production-grade code goes beyond functioning; it reflects an understanding of failure modes, edge cases at scale, and the reasoning behind architectural choices.

AI can generate a retry handler in seconds, and it’s getting closer to understanding that the handler needs to behave differently during a Stacks chain reorganization than during a standard API timeout. We’re not there yet, but the gap is narrowing fast, and the teams closing it are the ones pairing AI speed with hard-won production intuition.

The teams most at risk are the ones using AI without senior engineers who can spot output that looks right but quietly breaks under pressure.

Assisted vs. Autonomous: A Design Problem

“AI-assisted” and “AI-autonomous” represent entirely different operating models, not points on the same slider.

In the assisted model, the team is the decision-maker; in the autonomous model, they’re reduced to a notification recipient. The gap between those two models is one of kind, with distinct assumptions about where judgment lives.

“Oversight in the loop” has become a checkbox, and that’s the problem: someone clicks “yes” whilst reading Slack in another tab. The approval becomes theater.

Real oversight requires three things working together: context (the reviewer needs to understand what the AI did and why), authority (they need the organizational standing to actually block something), and tooling that surfaces the right information at the right moment instead of dumping a wall of diffs and a thumbs-up button.

This is a design problem with emerging solutions. We didn’t solve it by hiring more people to stare at approval queues. We started building systems that make expert judgment efficient: surfacing anomalies, providing diffs with context, and making “no” as frictionless as “yes.”

Enter the AI-DLC

Every team is going to use AI in development; the open problem is how to structure it so velocity doesn’t come at the cost of reliability.

The gap between “vibe coding” and “disciplined AI development” needs a concrete methodology, something more actionable than principles alone.

The AI-Driven Development Life Cycle (AI-DLC) from AWS is the most practical framework I’ve found for this. It’s backed by open-source workflows, and it maps cleanly to the problems described above.

The methodology moves through three phases. Inception determines what to build and why, using “Mob Elaboration” where cross-functional teams (PMs, devs, QA, ops) compress quarter-long planning into 3-4 hour sessions with AI handling the research and drafting legwork. Instead of weeks of design docs passed back and forth, the team gets focused, high-bandwidth alignment in a fraction of the time. Construction determines how to build it: single-pizza teams co-locate for “Mob Construction,” following a Plan-Verify-Generate cycle where AI creates plans, engineers verify them, AI executes, and engineers validate the output. Every iteration has a review checkpoint, which is the assisted model done right. Operations covers deployment, monitoring, and production readiness validation with the same structured oversight: AI handles the toil, teams own the decisions.

The key principle that separates AI-DLC from vibe coding is that engineers must understand every line of code they commit, and accountability cannot be delegated to AI. The methodology explicitly replaces the “prompt until green” habit with a structured cycle: plan, verify, generate, validate.

Engineers must understand every line of code they commit, and accountability cannot be delegated to AI.

The methodology is also adaptive. A bug fix doesn’t need every stage, but a greenfield application does, and that flexibility matters because rigid process kills the velocity gains AI provides in the first place.

Team Practices That Work

Beyond the framework, a few concrete practices have consistently separated the teams shipping reliably with AI from the ones generating impressive demos that crumble in production.

Context management turned out to be a bigger lever than we expected. Maintaining high semantics-per-token ratios in prompts (“refactor the payment module using the builder pattern” rather than a paragraph of vague description) and trimming irrelevant conversation history aggressively made a measurable difference in output quality. The less noise the model processes, the better it performs.

AI-assisted development is deep work, and context-switching kills it.

On the code side, we found that asking AI to mimic existing patterns in the codebase beats describing desired behavior from scratch every time. Decomposing tasks narrowly, one function, one concern, one prompt, and maintaining comprehensive test coverage meant that even “prompt until green” had a meaningful definition of green.

The organizational enablers mattered just as much as the technical ones. Blocking contiguous, meeting-free time for flow state was essential, because AI-assisted development is deep work and context-switching kills it. Mature CI/CD pipelines are a prerequisite too, since velocity gains vanish if deployment is a bottleneck. And measuring the baseline, time from business decision to production launch, gave us something concrete to improve against.

The best starting point we found was picking low-risk backlog items, estimating them traditionally, then executing with AI-DLC and comparing outcomes. There’s no gold standard yet, so running safe experiments and iterating on what works for a specific team is the only honest approach.

Looking Forward

The guardrails, escalation paths, and structured oversight that production systems need now have a name and a framework. The AI-DLC grounds the conversation in verification rather than hope, giving the industry something more concrete than principles to build on.

The shift from vibe coding to structured AI development is already underway, and the teams that come out ahead will be the ones who figured out, early enough, that AI development is a discipline with its own failure modes and that speed without structure just moves the pain downstream.