Mikkel Bergmann logo
Contact

AI-assisted SDLC: the Inception method

agentic-aienterprise-aiengineeringsaasai
·16 min read
The Inception method - working code as the only artefact that proves which level of the SDLC dream you are actually in

In this post we examine what it might be like if we could invert the traditional SDLC and plant the idea first as real code, through the eyes of the movie Inception, we work our way back up to real artefacts, with the code as the idea seeding the dream.

"What is the most resilient parasite? An idea." Cobb says it twice in Inception, and the second time he says it the audience knows the heist is not really about stealing - it is about planting. - Inception

The 2026 enterprise SDLC is, in almost every respect, the inverse of that operation. We start at the surface - PRDs, tickets, estimation, design reviews - and only descend into actual code once everyone above is satisfied. The implant comes last, after the dream has already been built around it. We do this because, traditionally, code was the expensive layer; you sequenced everything else first to de-risk the part you could not afford to throw away. AI flips the economics of code. Working code is now the cheap layer - the one you can spin up four versions of in a long afternoon. The implant can come first now.

That is the move this article is about, and the name I am going to use for it: The Inception Method. Implant the idea as working code, in a deep, sandboxed layer where mistakes do not carry weight, then ride the kicks back up - hardening, planning, discovery - reconstructing the dream-architecture of artefacts around the idea that already exists. Working code becomes the totem; the only artefact that does not lie about which level of the SDLC you are actually on.

The traditional SDLC + AI = 29% faster

The scenario: a multi-team enterprise SaaS organisation shipping a single cross-platform feature across Backend, Web, iOS, and Android. Four codebases, three disciplines, multiple squads, one PRD. The traditional lead time from "idea on a customer call" to "100% rollout" for a moderately complex feature is roughly 13 weeks. With the full 2026 AI toolchain applied honestly - including the costs it introduces - that number lands at about 9.2 weeks. A ~29% reduction. Some suggest that AI will help everyone become "10x developers" and compress the cycle to much less time, but that is not what actually happens.

To see why it is 29% and not 90%, it helps to walk the whole pipeline chronologically, phase by phase.

Note: this is a sample software development pipeline, based on past experiences - not a universal one. Your org's version will differ in the specifics, but it is good enough for our purposes. The estimations are averages, not precise numbers.
Phase 1 (2wk)2.0w → 1.7w (~15%)

Product discovery and definition

This is where the unstructured noise of the customer base gets compressed into something a team can act on. AI is genuinely useful here, but the humans stay firmly in the loop.

  • 1. Idea from a product user (~20% faster): LLMs synthesise thousands of unstructured feedback points across Intercom, Gong, and Slack into actionable themes. The constraint is not reading the feedback; it is deciding which theme aligns with the strategic roadmap, and that is still a human call.
  • 2. Feature discussion and ideation (~10% faster): AI helps with brainstorming and feasibility modelling, but the clock is dominated by synchronous meeting time - aligning Backend, Web, and Mobile stakeholders on what "done" actually looks like.
  • 3. Product Requirements Document (~50% faster): An LLM turns a messy meeting transcript into a structured PRD with user stories and acceptance criteria pre-populated. The PM still owns the content; they just spend their time editing instead of formatting.

Net effect on this phase: a modest speed-up, but only for the drafting work. Alignment time is almost untouched.

Phase 2 (2wk)2.0w → 1.1w (~45%)

Technical planning and scoping

This is where AI starts to look genuinely transformative on paper, and only partially transformative in practice. The moment work has to be coordinated across four repositories, structure beats speed.

  • 4. Team allocation (minimal speedup): A pure managerial function. Capacity, expertise, and on-call rotations across a dozen squads are not a prompt-engineering problem.
  • 5. Ticket writing in Jira or Linear (~70% faster): This is the first place AI really earns its keep. Agents decompose the PRD into atomic sub-tasks for all four platforms, auto-generate descriptions, labels, and dependencies, and cross-link the tickets. A job that used to take a tech lead a full afternoon now takes about thirty minutes of review.
  • 6. Fibonacci estimation (~29% faster): AI can suggest story points (1, 2, 3, 5, 8, 13) by comparing a new ticket to similar completed ones in the team's velocity history. The grooming session itself stays human-led, because its real purpose is building shared understanding, not producing a number.

Phase total drops from 2.0 weeks to 1.1 weeks, about 45%. The win is concentrated in the one step (ticket writing) that is almost entirely mechanical translation.

Phase 3 (9wk)9.0w → 6.2w (~31%)

Implementation and validation

The engine room. This is where the "35-45% faster coding" headlines come from, and also where most of those headlines quietly break.

  • 7. Development (~35-45% gross, ~25% net): AI handles boilerplate, unit tests, and "logic porting" - translating Backend logic into Swift on iOS and Kotlin on Android. The gross speedup is real. The net speedup is smaller because high-volume AI code creates Review Debt: senior engineers end up spending their day auditing a queue of AI-generated PRs for long-term maintainability, subtle bugs, and architectural drift.
  • 8. Testing and QA (~50% faster): AI is excellent at generating E2E test scripts - Playwright on the web, XCUITest on iOS, Espresso on Android. The constraint is manual exploratory testing: the fixed human cost of verifying the "feel" of the feature across devices. That time does not compress.

Phase total drops from 9.0 weeks to 6.2 weeks (dev + QA combined). The gap between the 35-45% gross figure and the ~25% net figure is the story - it is the cost of introducing a high-volume code producer to a team whose bottleneck was never typing speed.

Note: Review Debt is the 2026 equivalent of tech debt. It does not show up on a dashboard, but it is the single biggest reason the "10x faster coding" claims collapse when you measure them at team scale.
Phase 4 (2wk)2.0w → 1.9w (~5%)

Strategic deployment and rollout

AI is operationally helpful here, but this phase is governed by physics - specifically, the physics of real users encountering real code.

  • 9. Feature flag activation at X% (~15% faster): AI makes sure flag configuration is identical across Backend, Web, and Mobile environments, which is the number one source of rollout-day incidents. The phase itself is gated by Soak Time - the 24 to 48 hours you wait to confirm stability in a real-world dark launch. That clock does not care about your model size.
  • 10. Measure errors and fix (~60% faster): AI-driven observability (Datadog, Sentry, New Relic's AIOps) correlates error spikes directly to the PR that introduced them and suggests auto-remediation. Time-to-triage collapses. Time-to-merge-a-hotfix depends on, well, Phase 3.
  • 11. 100% rollout and flag cleanup (~90% faster): This is arguably AI's best trick in the whole cycle. An agent sweeps across all four repositories, rips out conditional logic, deletes obsolete code paths, and opens clean cleanup PRs. A task everyone used to procrastinate on becomes a background job.

Net: 2.0 weeks drops to 1.9 weeks. A rounding error at the macro level, but the cleanup step alone is worth the price of admission - it is the first time in my career I have seen flag hygiene actually stay on top of itself.

The bottom line: ~29% net lead-time reduction

Stack the phases next to each other and the shape of 2026's actual productivity gain comes into view:

PhaseTraditional baselineAI-accelerated (2026)Net time saved
Planning & scoping2.0 weeks1.1 weeks~45%
Implementation (dev)6.0 weeks4.4 weeks~27%
Testing & QA3.0 weeks1.8 weeks~40%
Deployment & rollout2.0 weeks1.9 weeks~5%
Total lead time13.0 weeks9.2 weeks~29%

Two things jump out. First, the gain is roughly uniform across planning, dev, and QA - roughly a third off each. The idea that AI is mostly a coding tool is already out of date; it is equally a scoping and testing tool. Second, deployment is a brick wall. You can't prompt your way out of Soak Time.

Wait, isn't everyone a 10x developer now?

There is an obvious shortcut hiding in the 29% number. AI now writes about 46% of the code (as of December 2025) the average developer commits, every engineer is augmented, and the lone-wolf 10x developer of the 2010s job ads has been replaced by a bench full of people each running their own little agent swarm. So just lift everyone to 10x and the 9-week calendar caves in - right?

Most engineers absolutely can hit 10x velocity in short bursts when conditions are ideal - greenfield problem, no legacy codebase to wrangle, no design disagreement, no blockers. Real work is the opposite of those conditions, and trying to outrun them at sustained 10x is a reliable recipe for burnout - the Stack Overflow blog and Overcommitted's burnout episode both make the point, and the longitudinal data backs it up: after about four weeks of sustained 60-hour weeks, total output falls below a steady 40-hour pace. What separates the engineers who actually sustain it is mindset, not skill: the person with Claude Code remote on their phone, a workstation set never to sleep so an agent keeps grinding on the train ride home, MCP wired up before the platform team gets there, three agents running on a Saturday because they wanted to see if a different framework would feel better. The load-bearing trait is passion. Without it, 10x is a sprint that ends in burnout; with it, the cruising speed lifts and stays lifted.

What shifts at enterprise scale is not personality, it is what you fund. The bottleneck on the 9-week calendar was never typing speed - it was alignment, review, and rollout. The more interesting question is what AI tooling makes possible if we stop using it to speed up the cycle we already have, and start using it to run a different one.

The Inception method - 41% faster

Here is what changes once code is the cheap layer. Pick a candidate from the PRD intake. Drop straight to implementation - the deepest dream level, where mistakes are weightless because the environment is throwaway and the artefacts have no audience yet. Send three or four agents down, each carrying the same problem statement and a different architectural bet. Each one builds a credible version of the feature, in isolation, in a sandboxed branch. The implant is whichever idea takes hold first as actually-running code.

A few days later the team picks the variant that lands - by feel, on working code, not on slides. That is the kick. From there they ride back up through the dream layers in reverse: reconstruct the PRD from what the chosen prototype taught them, decompose the variant into tickets, harden it with tests, observability, and edge-case coverage, then ship through the same flag-and-soak phase the traditional cycle uses. Same four phases as the relay race - just travelled in the other direction. The implant comes first; the dream-architecture of PRDs, plans, and tickets gets reconstructed around the idea that already exists.

Traditional SDLC (13 weeks, dream first)
2wDiscovery
2wPlanning
7wImplement + test
2wDeploy
Traditional SDLC + AI (~9.2 weeks, dream first)
1.7wDiscovery
1.1wPlanning
4.5wImplement + test
1.9wDeploy
Inception method (~7.7 weeks, implant first)
2wImplant
0.5wPRD
0.5wPlan
2.8wHarden
1.9wDeploy
All three bars share the same 13-week axis. Top: the traditional cycle, dream first. Middle: AI applied to that same cycle, ~29% off the calendar. Bottom: the Inception method, same four phase colours travelled in the opposite order. The empty stretches on the right are the calendar time each approach gives back.

Stack the three approaches side by side and the gain comes into view:

ApproachLead timeSaved
Traditional baseline13.0 weeks-
AI on traditional SDLC9.2 weeks~29%
Inception method~7.7 weeks~41%

That ~41% is rough and conditional, not measured. It only materialises when the surrounding tooling actually exists.

Cobb's heist depended on Yusuf's chemistry, Arthur's logistics, Eames's forgery, Ariadne's architecture, and Saito's funding - the team did not just walk into the dream and improvise.

The Inception method has its own equipment list, and most of it overlaps with the shared layer the 10x conversation was already heading toward, just pointed at a different job:

  • Sandboxes that don't break things - ephemeral environments per spike, branch-per-variant, full-state snapshots, instant rollback. Without these, "play freely" stays theoretical.
  • Parallel-agent fan-out - the orchestration pattern that lets a squad spin up three or four agents on the same problem in different repos or branches, each pursuing a different architectural bet, without the agents stepping on each other.
  • Reverse-spec extraction - tools that read working code and emit candidate PRDs, ADRs, ticket decompositions, and test plans. This is the rebuilding of "the working" after the answer has already arrived.
  • Stakeholder-friendly preview deploys so PMs, designers, and real users can poke at variants before the team commits. The variant gallery is what closes the discovery phase that did not happen up front.
  • Architectural diff between variants - "variant A differs from B in these three structural decisions, with these implications." Without this, picking the winner becomes vibes.
  • Internal MCP servers that let any engineer ask natural-language questions about the architecture ("which service owns billing write paths?") and get a correct, traceable answer in seconds - load-bearing when several variants are exploring the same surface area at once.
  • Spec-driven harnesses (eg: OpenSpec) that lock the architectural intent in the repo before anyone writes code - even more important when multiple variants are being explored simultaneously than when a single team is shipping a single design.
  • Shared review agents that pre-audit each variant against the team's style guide and architectural decisions, so senior reviewers spend their time on the differences that actually need human judgment.
  • Observability glue that maps errors back to the exact PR, flag, and on-caller, compressing the feedback loop on the chosen variant once it ships.
Note: the Inception method only works where wrong-but-working code is acceptable in someone's hands. Skip it for regulated, safety-critical, or consistency-bound systems where the design must be pinned before any code can be trusted. Mal stayed in limbo because she stopped trusting the totem; teams that ship the first spike straight to production meet the same fate.

The Inception Method in practice

Walking the same four phases as the relay race earlier - travelled in the opposite direction - this is what an Inception-method cycle actually looks like end to end.

Phase 1 (2wk)~2 weeks

Implementation and validation

This is the dive. Instead of writing the answer last, the team plants several candidate answers first - in throwaway environments, in hours, not weeks. Mistakes do not carry weight at this depth because nothing here is real yet; the team's only job is to find an idea that takes hold as actually-running code.

  • 1. Frame the candidate (~1 day): A tech lead skims the PRD intake, picks a problem worth a spike, and decides how many variants are worth exploring. The PRD itself stays deliberately thin - the spikes are doing the discovery, not the document.
  • 2. Fan out to 3-4 agents (~1 week): Each agent gets the same problem statement and a different architectural bet - different framework, different data model, different UX shape. They run in isolated branches or sandboxed environments so they cannot contaminate each other's state. The team is not micro-managing them; the orchestration is the deliverable.
  • 3. The kick - pick the winner by feel (~half a week): The team gathers in front of working variants, not slides. PMs, designers, sometimes real users click through preview deploys. The pick is grounded in actual interactions with actual code, which is exactly the evidence that traditional discovery never had access to. The moment a variant is chosen is the kick - the team starts riding back up.

Phase total: ~2 weeks. The traditional implementation phase took 6-9 weeks; this one took the time to build four versions of the feature and pick the one that lands.

Phase 2 (0.5wk)~0.5 weeks

Product discovery and definition

Now the dream-architecture gets reconstructed around the implant. Discovery becomes a justification artefact rather than a blueprint - the PRD describes a feature that already exists in working code, which is a much easier document to write honestly.

  • 4. Distil the PRD from working code (~half a week): An agent reads the chosen variant, cross-references it against the stakeholder reactions captured during the variant gallery, and emits a candidate PRD with user stories and acceptance criteria. The PM edits, not authors - the document grounds itself in artefacts that already exist.
  • 5. Capture what the variants taught (~half a week): The variants the team did not pick are usually more informative than the one they did - they encode the rejected designs, the edge cases that surfaced, and the risks the team ruled out. Document them as "considered alternatives" so the discovery is not lost when the throwaway branches are deleted.

Phase total: ~0.5 weeks. Faster than traditional discovery because every claim in the PRD is provable against a working artefact someone has already poked at.

Phase 3 (3.3wk)~3.3 weeks

Technical planning and scoping

The chosen variant is real but rough - the implant exists, but the layer of dream-architecture immediately above it (tickets, tests, observability, edge cases) does not yet. Phase 3 builds it, on the same calendar a traditional team would still be writing tickets from scratch.

  • 6. Decompose the variant into tickets (~half a week): An agent reads the prototype's commit history and structural shape and emits a candidate ticket breakdown for the harden-and-ship work. Tech leads adjust for capacity, on-call rotations, and squad dependencies the agent cannot see.
  • 7. Harden (~2.8 weeks): Tests, observability, performance budget, edge-case coverage, accessibility pass, security review on the diffs that survive. Most of the human time in Phase 3 lives here. The good news: tests are far easier to write against working code than against a spec that does not exist yet, and the failure modes are concrete instead of imagined.

Phase total: ~3.3 weeks. Comparable in calendar time to traditional dev + QA combined, but the work is finishing code that already runs rather than writing code from scratch against a specification.

Phase 4 (1.9wk)~1.9 weeks

Strategic deployment and rollout

This phase looks identical to the AI-accelerated traditional cycle. Soak Time still applies, real users still need to encounter the code, and the physics of dark launches do not bend just because the implant happened first. This is the layer where the totem stops spinning - reality is reality.

  • 8. Feature flag activation (~half a week): Same dark-launch pattern as traditional Phase 4 - flag config validated across Backend, Web, and Mobile environments by an agent, soak window observed, ramp curve managed by playbook.
  • 9. Measure, fix, clean up (~half a week): AI-driven observability correlates errors back to the surviving PRs from the harden phase. The flag-cleanup agent sweeps once the rollout hits 100%. Identical to the AI-accelerated traditional Phase 4.

Phase total: ~1.9 weeks. Effectively unchanged from traditional - this is the part of the cycle the Inception method cannot compress, because it is gated by real users meeting real code. Soak Time is the rule that no level of dream-architecture can rewrite.

Try the Inception method

To try the Inception method, do not reorganise the whole company. Run one contained feature through the loop and treat it as a team operating model experiment.

  • Pick one slice where wrong-but-working code is safe to show someone - not the whole portfolio.
  • Name an orchestration owner for sandboxes, branches, and parallel-agent fan-out. The role is coordinating several agents at once, not driving a single chat session.
  • Isolate variants so each spike has its own environment or branch and cannot overwrite the others.
  • Fan out 3-4 agents on the same problem with different architectural bets.
  • Review working previews with PM, design, engineering, and optional users - evidence beats slides.
  • Pick the winner, then reverse-write the PRD and ADRs from the code you chose.
  • Harden like normal - tickets, tests, observability, security on diffs - and keep 10x-traditional delivery where the implant does not fit.
  • Ship behind a flag, measure in production, then delete losing branches and unused flags.

Keep it light. Treat the list as a small habit, not a new rollout pack. If it grows rituals and sign-off layers before you have run one slice end to end, strip it back until it fits on one screen again.

So, whose team is going to plant the idea first - and whose is still trying to build the dream from the surface?

Further reading