Thirty engineers in a room. One feature to build. By the end of the day, they had a validated specification, working code, and infrastructure configuration, all generated from a structured intent document they wrote together that morning.
In the feedback survey, the team rated the experience 9.7 out of 10. Every single respondent expressed interest in a guided pilot. Zero rejections. When asked what section was most valuable, 41% chose Mob Elaboration (the collaborative human ritual) over Mob Construction (the AI-powered code generation, at 24%).
That last number is the one that matters. The humans in the room recognized immediately that the bottleneck was never code generation. It was intent definition, and the methodology gave them a structured way to solve it together.
This is what AI-DLC looks like when a team actually runs it. Not a whiteboard exercise, not a conference talk, not a blog post about principles. A working session where the methodology carries the process and the humans carry the judgment.
How a session runs
A team has a new feature to build: a customer notification preferences service.
Intent first. The team writes a one-page intent document describing what they want to build and why. Not a specification or user stories, just the business intent in plain language: “We need customers to control which notifications they receive, through which channels, with GDPR-compliant consent management.”
Mob Elaboration. The AI agent reads the intent, the governance guardrails, and the project context. It generates: a unit decomposition (how the feature breaks into deliverable pieces), user stories with acceptance criteria for each unit, non-functional requirements with measurable thresholds, a risk register, and a bolt plan (the sequence of construction sessions needed to deliver the feature).
The team reviews everything. They challenge the boundaries, add edge cases the AI missed, flag regulatory requirements the AI did not know about. The AI revises. Within two hours, they have a validated specification that would have taken days to produce manually.
Construct bolt by bolt. Each bolt moves through four stages: domain modeling, logical design, code generation, and test validation. The AI generates each stage’s artifacts, the team validates at each checkpoint, and nothing advances until the team approves. Governance guardrails are active throughout: the AI checks every artifact against security baselines, compliance constraints, and architectural standards before presenting it to the team.
Ship. The output of each bolt is a deployment unit: tested code, infrastructure configuration, and documentation, all generated from the validated specification and all compliant with the guardrails.
What the team walks away with
After a full-day session, the team has concrete artifacts they can use immediately. A validated domain model that names the bounded contexts and their relationships. Eight to twelve user stories with acceptance criteria specific enough that an AI agent can execute them without ambiguity. An architectural decision record documenting the one or two trade-offs the team debated and resolved during elaboration, so the reasoning survives even if the people rotate. Non-functional requirements with measurable thresholds: not “the system should be fast” but “P95 latency under 200ms at 500 concurrent users.” And a bolt plan that sequences the construction work into daily deliverables the team can track.
None of these artifacts are novel individually. What changes is that they exist before the first line of code is generated, they are validated by the team collectively, and they become the AI’s operating context for every subsequent generation step. The specification constrains the generation space. The AI produces different output when it has a validated domain model and explicit NFRs than when it has a one-paragraph prompt and good intentions.
What goes wrong without structure
Every team that runs the workshop recognizes at least one of these failure modes from their own experience.
Approval fatigue. The AI generates a specification that looks internally consistent, the team reviews it, and because it reads well, they approve it without challenging the assumptions underneath. Three sprints later, they discover the domain model was wrong from the start. AI-generated internal consistency creates a false sense of correctness. The Mob Elaboration ritual prevents this by forcing the team to challenge every boundary before the AI moves to construction.
Quick-cement. AI output solidifies before anyone verifies it. A developer prompts the AI, gets working code in twenty minutes, commits it, and moves on. By the afternoon, three other components depend on architectural decisions nobody reviewed. Undoing them costs more than building them right would have. The bolt structure prevents this by constraining generation pace to validation pace: nothing advances until the team approves.
Comprehension debt. Six months after a feature ships, nobody can explain why the code works the way it does. The developer who prompted the AI left, the reasoning was never documented, and the codebase functions but exists outside anyone’s mental model. The methodology prevents this by generating architectural decision records and intent documentation alongside the code, so the “why” survives independently of the people who were in the room.
These are not hypothetical risks. They are the patterns I see across organizations that adopted AI coding tools without a structured methodology. The tools work. The methodology gap is what breaks.
What makes this different from “just prompting better”
Three things separate structured AI development from the “write better prompts” advice that fills every AI productivity thread.
The methodology remembers itself. You do not need to remember whether you are in elaboration or construction, which stage of construction you are in, or what the exit criteria are. The process tracks where you are and tells the AI what to do next. This is the difference between a methodology you have to remember and a methodology that carries itself.
Governance is embedded, not appended. Security, compliance, and architectural standards are not a review gate at the end. They are part of the AI’s generation context from the first artifact. The AI generates compliant code because the constraints are part of its input, not because someone reviews the output three weeks later.
The structure adapts to the work. A greenfield application has different rituals and quality gates than a brownfield modernization or a cloud governance assessment. The methodology flexes to the domain while maintaining the same core principle: intent before generation, validation before advancement, governance throughout.
The adoption curve I have observed
Teams that adopt structured AI development go through a predictable sequence. The first session feels slow because they are learning the ritual structure. The second session is faster because the AI agent already has context from the first session’s artifacts. By the third session, the team stops thinking about the methodology and starts thinking about the problem.
Their primary barrier to adoption is skills readiness, not skepticism or resistance: 53% said “we need to identify the right project,” and 29% already had one in mind. They believed it worked after seeing it once. They just needed a guided path from workshop to production.
A smaller team I worked with recently, six engineers at a fintech company, ran the methodology on a brownfield problem: modernizing a payment reconciliation service that had accumulated three years of undocumented business rules. They used Code Elevation first to make the existing codebase legible to the AI agent, then ran Mob Elaboration against the elevated context. The team’s lead told me afterward that the elevation phase surfaced twelve implicit business rules that nobody on the current team knew existed. They had been maintaining code that enforced constraints they could not explain. The methodology made the invisible visible before they started changing anything.
The fastest adopters already tried AI-assisted development without structure and hit the walls I described in The Mismatch Between AI Code Assistants and Enterprise Software Development. They already know what unstructured AI development costs. They do not need to be convinced that the problem exists. They need a solution that does not require them to become methodology experts first.
One developer I work with tried the methodology manually before we had the structured process in place. He wrote intent documents by hand, broke them into units, drafted stories with acceptance criteria, then fed everything to his AI agent as context. It took him four hours to produce what the methodology generates in forty minutes. The stories were good, the structure was right, but sustaining it manually across a real project was exhausting. His second project, with the full methodology supporting him, took him from intent to deployed feature in three days.
We have already built the tooling, the process scaffolding, and the governance templates that make this repeatable across enterprise teams. The methodology is not a concept waiting for implementation. It is a working system with structured onboarding paths designed to get teams from first session to autonomous execution without requiring them to build the infrastructure themselves.
What this means for engineering leaders
If you lead a team that uses AI coding tools, you have already made a choice about methodology, whether you realize it or not. The absence of a structured approach is itself a methodology: it is vibe coding with extra steps.
The evidence from the community, from the architecture review gap, and from the governance paradox all point the same direction. Your team needs structure around AI-assisted development.
If you want to see the methodology in action, I run workshops where teams go from intent to validated specification and working code in a single day. The response I hear most often afterward is not “interesting concept.” It is “which project do we start with?”
Ricardo
