What enterprise teams need from AI delivery frameworks: a look at ADLC5 and Spec Kit

When I wrote the AI-driven development lifecycle (AIDLC) policy at YMCA of the USA, the hard part wasn't deciding whether our teams should use AI coding tools. They already were. The hard part was writing down what "done" means when an agent wrote most of the code, and how a team proves it.

That question is why I've spent real time with spec-driven development frameworks. Two stand out to me: GitHub's Spec Kit and ADLC5, a newer open-source delivery workflow for AI coding tools. I've used both on real work. What follows is my take on each, from where I sit: accountable for making AI-assisted delivery work across many teams, not just for one fast developer.

Fast developers, slow organizations

AI has made my best engineers noticeably faster. It hasn't made the organization faster by the same amount, and for a while I couldn't fully explain why.

The answer turned out to be unglamorous. Code shows up faster than people can review it. Design decisions get made inside a chat window and disappear when the session ends. Two teams using the same tool define "finished" in completely different ways. None of that is a model problem. It's a delivery problem, and a framework is only worth adopting if it helps with that.

Spec Kit

Spec Kit is the one I'd hand to a team that has never worked this way. You install the specify CLI, point it at your agent, and you're working in the chat within minutes. You write a constitution once, a short set of principles for the project, and then each feature moves through specify, plan, tasks, and implement.

What I like about it:

It's easy to start. A team can be productive with it in an afternoon, and the habit it builds, writing before generating, is most of the value of spec-driven development.
The constitution earns its keep. It puts your architecture standards in front of the agent on every feature, without anyone having to remember to paste them in.
Everything is plain Markdown. A product manager or an auditor can read the spec without ever opening an AI tool, and in an enterprise that matters more than people think.
It travels. It works across a range of AI agents, and it's MIT-licensed.

The constitution is where it won me over. I put in the standards that used to eat up our code reviews (API-first design, no secrets in config, and accessibility), and every feature after that followed them. Review time went to design questions instead of reminders.

Where I hit its limits was consistency across teams. Spec Kit gives you a good structure, but it trusts each team to bring the rigor. How detailed the spec should be, whether the tests really prove the acceptance criteria, who reviews the agent's work, and when a person has to approve are all left to you. One disciplined team will do very well with it. Ten teams will give you ten different levels of quality.

ADLC5

ADLC5 follows the same four stages (specify, plan, tasks, implement), and you kick off a feature with one line: @adlc5 for my-feature. What's different is how firmly it holds the agent accountable.

The process matches the risk. A tiny fix gets a single change.md. A normal feature gets a short plan and story specs that can be checked automatically. Anything high risk gets a detailed design, an independent critique, QA, and a human sign-off. I've watched developers quietly abandon process because it asked for the same paperwork on a typo as on a payment flow. This fixes that.
The agent can't declare itself done. A deterministic kernel controls progress and runs the checks against the current version of the code, not a test run from an hour ago. The project calls this "repeatable acceptance and failure handling, not identical generated code," which is the right framing for an enterprise.
It learns the codebase. Repository maps, guidance carried between sessions, and a context pack for each story mean the agent starts out knowing the code. A discipline the project calls SOUL keeps it from wandering off on confident tangents.

Here's the moment that sold me. On Vernacy, the document intelligence platform I'm building at Melitrus, every test passed, but none of them covered one of the acceptance criteria: PDFs where accented names came through garbled. ADLC5 flagged the gap before the story could close. In most workflows, that ships as a green build and shows up weeks later as bad extracted data.

None of this is free. ADLC5 asks more of a team, and it's openly in public preview, with comparative coding-quality results still pending. I appreciate that honesty, and it's why I'd pilot it before rolling it out widely.

Side by side

	Spec Kit	ADLC5
Core flow	Constitution, then specify, plan, tasks, implement, converge	Specify, plan, tasks, implement
Process depth	Same structure for every feature, with optional quality gates	Scales with risk: tiny, standard, high-risk
Who decides "done"	The agent and the team	A deterministic kernel and current evidence, plus human approval for high-risk work
Codebase context	Constitution and feature artifacts	Repository maps, carried-forward guidance, per-story context packs
Adoption effort	An afternoon	A deliberate pilot
Maturity	Backed by GitHub, MIT-licensed, broad agent support	Public preview, with comparative results pending
Best fit	Teams new to spec-driven development, and lower-risk work	High-stakes work, and scaling AI delivery across many teams

The questions I actually care about

After using both, I stopped asking which one writes better code. What I care about is whether, as the person accountable for delivery, I can answer five questions without chasing anyone down:

What did we decide, and why? I want that in the repository, not in someone's chat history.
Who checked the work, and were they independent of whoever built it? An agent grading its own homework isn't a review.
Did the amount of process match the risk?
Where did a person approve it? Accountability for software built with AI still sits with people, so the sign-off points need to be explicit.
Is the agent getting better at our codebase, or starting from scratch every session?

Spec Kit handles the first one well and leaves the rest to your teams. ADLC5 is built to cover all five, and you pay for that in process and maturity.

What I'd tell a CEO

If a CEO asked me whether to invest in an AI delivery framework, I wouldn't start with tools. I'd make three points.

The return is real, but it comes from delivery, not typing speed. At YMCA of the USA, building in-house with AI under a governed delivery model has finished work that had stalled, at a fraction of what buying or outsourcing it would have cost. The savings came from shipping, not from developers typing faster.
The risk is in verification, not generation. AI will produce plausible code all day. The exposure is code nobody independently checked, running in systems that handle money, health data, or personal information. Fund the checks, not just the licenses.
Measure outcomes, not usage. Seat licenses and prompt counts tell you nothing. Track time from approved spec to production, defects that reach users, and how much rework AI-built changes need. If those don't move, the tools aren't paying off.

A framework is how those three become repeatable across teams instead of depending on a few strong people.

Where I've landed

If your teams are new to spec-driven development, start with Spec Kit. Writing before generating is a habit, and Spec Kit builds it with almost no friction.

If you're further along, with AI-assisted delivery already working on some teams and the challenge now being scale or high-stakes work, ADLC5 is what I'd reach for. Pick one team, give it genuinely risky work, measure what changes, and decide from there.

Either way, the framework isn't your AI strategy. The strategy is deciding what "done" means for AI-assisted work and holding every team to the same standard. A good framework just makes that decision easier to enforce.

Links: Spec Kit on GitHub · ADLC5 · ADLC5 on GitHub

Views here are my own and don't represent YMCA of the USA.