If AI is going to write a lot of your software, one question follows fast: how do you make sure it builds things your way — to your standards, your guardrails — and not just plausible code that looks right and quietly isn't?
That question has a name now: the AI-DLC, the AI-driven development lifecycle. We've been trying to actually run one — less "prompt and hope," more a real process the AI follows. Not a how-to; just the honest state, and where we're still stuck.
What we've learned
A few things get clear the moment you actually try this — and most are the opposite of where the hype points. It isn't the model or the tool of the week; it's the scaffolding underneath:
- The rules aren't about code style — they're the whole lifecycle. Not naming and formatting; the rules shaping the lot — how you capture requirements, write the design, define tests and acceptance criteria, code to the spec, and close the loop with deployment and observability.
- The real substance is memory, not context. Memory is everything the system has learned — rules, guidelines, past decisions, the "we don't do it that way" — durable, and it grows. Context is the small window a single task gets. You build the memory once; each task pulls what it needs. (It's also the answer to the token problem: never load everything, just what's relevant.)
- Governance can be a rule the AI follows, not a PDF nobody reads. Security, performance, and the compliance a domain drags in — PCI, RBI, DPDP, HIPAA — declared up front and turned into checks the lifecycle actually runs.
- It only gets real when it's wired into where the work actually happens. Disconnected from your real systems, even the best rules are a clever demo.
- MCP is what does the wiring. The common protocol that lets the AI reach your real tools — GitHub for code and PRs, Jira for tickets, Confluence for the documents (all of them: PRDs, architecture, design, test cases, acceptance criteria, benchmarks — everything except the rules and config, which stay in Markdown and load into the AI's memory). Wire it up and an agent pulls the actual ticket, reads the actual spec, opens the actual PR. Get it right and the whole lifecycle clicks; skip it, and you've got a very smart assistant with its hands tied.
Put together, that's the shift: an AI-DLC isn't a smarter autocomplete — it's the scaffolding that lets an AI work the way your team already does. Which is exactly why the framework was never the hard part.
What we really want
The goal is simple to say, hard to do: a lifecycle where the AI does the heavy lifting and the judgment stays in. It builds the way your best people would — same standards, same guardrails, same "no, not like that" — fast where speed is safe, stopping to ask exactly where a human should. Not AI instead of the team, but AI that carries how the team works, everywhere.
The shape we're aiming for
Picture it as a relay of agents, each owning a stage and handing off to the next — a conductor keeping them in step, a human at the gates that matter:
- Requirements → PRD. It starts where projects are messiest — a rough request, a few lines, maybe a diagram. An agent researches, fills the gaps, asks what's ambiguous, and turns it into a proper PRD, iterating until a human would sign off on it.
- PRD → architecture & design. Then the system design and its trade-offs — not just the happy path: security, performance, reliability, cost, every pillar (the AWS Well-Architected Framework makes a good checklist).
- Design → code + tests. It builds to the design — code that does what the requirements asked, unit tests to prove it — and opens a PR only once they pass. Not "it compiles," but does what the PRD said, the way the design said to.
- PR → review. A reviewer agent reads the PR against the rules, files tickets back to the devs for what's wrong, and keeps at it until everything verifies. (Qodo, Greptile and others already do multi-agent review and rule enforcement — the aim is to fold that in, not reinvent it.)
- Past the merge, agents deploy, watch production, and roll back the reversible things themselves — escalating the scary ones to a human with the diagnosis already done.
The point isn't the number of agents. It's that the judgment — what "done" means, which risks are acceptable, when to stop and ask — is written down once, in the rules, and every agent inherits it. A one-line fix skips most of it; a big feature runs the lot. And the loop closes: what breaks in production becomes a new rule, so it doesn't break twice.
That's the aim — though plenty of it is still hope and duct tape. Which brings us to the honest part.
The gap
Here's where it keeps hitting the wall — the parts no framework hands you:
- Adherence. How do you know the team is actually following it, and not quietly switching the rules off the moment they feel like friction? A rules file is trivial to ignore, and there's no dashboard for whether everyone really is.
- Whether the rules are even right. You can write a hundred; how do you know they catch real problems and aren't just ceremony? You need a feedback loop that tells you a rule is earning its keep.
- The economics. Only a couple of people usually lean on it hard before the token cost and context limits bite. Prompt/token optimisation and caching stop being nerdy details — they decide whether it's affordable at team scale.
- Where the line sits. Company-wide rules, what a team gets to change, local tweaks. The hierarchy makes it possible; knowing what's genuinely non-negotiable and what a team should own is the hard call.
None of these are tooling problems. They're the human, operational parts — which is exactly why they're hard.
What we see as options
The raw materials exist, and most are open. What's on the table:
- Shared rules files — the AGENTS.md convention most AI tools read, plus RULES.md, config and the rest, in a hierarchy: company rules at the root, team overrides below. Each stage of the cycle also gets its own outline — what's expected, and explicitly what isn't — so agents and humans both know the bar.
- A ready-made lifecycle — AWS open-sourced its AI-DLC and "adaptive workflows": skip stages for a small fix, run the full set for a bigger one, humans on the gates. Adopt whole, or borrow from? Still weighing it.
- Tool integration over MCP — the connective layer above, wiring the agents to the code, tickets and docs.
- Rules as memory — treating the accumulated rule-set as durable memory, loading only what each task needs.
None of these, alone, closes the gap above. The pieces are here; making them work for a real team — affordably and consistently — is what we're still solving.
So — how are you doing it?
Honest caveat: we're not far enough along to hand anyone a playbook — we're in the thick of it, stitching the pieces together and hitting the same walls. So this isn't us harvesting your hard-won lessons from a comfortable distance; it's a genuine compare-notes between people still figuring it out. And we'll go first: once we're far enough in, a follow-up on exactly what we built — what's working, and what isn't. If you're doing this too: how are you approaching it, and what caught you off guard?