Your board evaluates AI maturity by tool adoption.
That is like evaluating manufacturing maturity by counting machines on the floor.
The number tells you who has spent money. It does not tell you who has changed how the work gets done. Most organizations are at Stage 1 of an actual maturity curve. The competitive advantage lives at Stage 4. And the gap between those stages is not technology — it is engineering discipline, which does not show up on any of the dashboards your board is currently reading.
Four stages, observable from the outside
The curve has four stages. Each one describes how a coding agent is actually being used inside the organization, not which products have been licensed. Each stage produces output of a categorically different quality, because each stage gives the model categorically different context to attend to. Same model. Same vendor. Different operating discipline.
Stage 1: Vibe coding. Developers chat with an AI. They type a request, receive a response, and edit the response into something usable. The output varies between developers, between sessions, and between attempts in the same session. Nothing is repeatable, nothing is auditable, and nothing about the workflow scales without adding more humans. The diagnostic from the outside: ask three engineers to perform the same task in isolation. Compare the results. If they diverge in structure, naming, error handling, and edge case treatment, the organization is at Stage 1 — regardless of which model is in use.
Stage 2: Structured prompting. Better instructions, prompt templates, internal style guides. The team has noticed that vague requests produce vague output and has invested in language. Output quality improves. But the improvement is bounded by what a human can carry in their head and translate into a paragraph at the moment of generation. Junior engineers underperform senior ones because the senior engineer's mental model fills gaps the prompt does not. The diagnostic: when the senior person leaves for vacation, output quality drops. The organization is at Stage 2 when prompt quality lives in tribal knowledge instead of versioned artifacts.
Stage 3: Specification-driven. Specifications are written, versioned, and treated as first-class artifacts. Validation pipelines test the output against the specification, not against the implementation the agent happened to produce. When output is wrong, the fix goes into the specification, not the code. The same specification regenerates working implementations across language migrations, framework changes, and personnel changes. The diagnostic: when an engineer leaves, the work continues at the same quality. The specification — not the engineer's memory — is the source of truth.
Stage 4: Reliable systems. The full operational substrate is in place. Specifications are coupled to validation pipelines, validation pipelines are coupled to orchestration, orchestration is coupled to provenance — every state mutation records its source, timestamp, and version, making the entire execution history queryable. Output is repeatable, auditable, and scalable across teams without coordination overhead growing linearly with headcount. The diagnostic: a new engineer reads the specifications and validation pipelines and starts producing on day one without absorbing tribal knowledge. Throughput grows with the harness, not the headcount. This is the configuration where adding a person makes the system faster, not slower — the inversion of Brooks' Law that OpenAI's harness-engineering case study documents in production.
The gap is engineering discipline, not technology
Every organization has access to the same frontier models. The vendors do not run a different tier for sophisticated buyers. GPT, Claude, Gemini — the same weights, the same context windows, the same APIs are available to your competitors. If model access were the differentiator, the maturity curve would not exist.
The reason it exists anyway is that model output is determined by what reaches the model's context window at the moment of generation. A vague request produces generic output because the model's attention has nothing project-specific to weight. A complete specification with type definitions, edge cases, integration interfaces, and test cases produces output that conforms to the system's actual requirements because the requirements are present as tokens that attention heads can match against. The same model produces categorically different output because the context engineering produces categorically different conditions for the model to operate in.
That is what the four stages are measuring. Stage 1 sends short, ad-hoc messages into the context window. Stage 2 sends templated but still-verbal instructions. Stage 3 sends versioned specifications that the agent can attend to with high weight. Stage 4 sends specifications, retrieved code patterns, validation contracts, and execution state — assembled deterministically by the harness. Each stage gives the same model dramatically more useful material to work with. The output quality difference is not the model getting smarter. It is the operating model getting more disciplined.
This is why a procurement statement is not a maturity statement. The license tells you nothing about what the engineering organization has standardized on. An organization where every developer prompts a coding agent however they want is at Stage 1 even if the seat count and spend are impressive. An organization with thinner tooling but versioned specifications and validation pipelines is at Stage 3.
Why most companies are overstating their stage
Three patterns produce overstatement, and they are visible at the board level if you know what to look for.
Adoption-as-maturity confusion. Tool seats and usage volume are easy to measure and read as progress. They are also entirely uncorrelated with whether the operating model has changed. A board that hears "75% of engineers are using AI daily" is hearing an adoption statistic. The maturity question is what those engineers are producing, how repeatably, and whether the workflow they are running could be inherited by a new hire on day one. Adoption is the input. Maturity is the operating discipline that converts the input into reliable output.
Senior-engineer compensation. Stage 2 organizations frequently look like Stage 3 because the senior engineers fill specification gaps from memory. They have absorbed the team's conventions, the architectural decisions, and the unwritten rules — and they extend those into every prompt without realizing they are doing it. The organization mistakes the senior engineer's intuition for organizational discipline. The diagnostic is to remove the senior engineer from the loop for two weeks and observe what happens to output quality. If quality drops materially, the organization was at Stage 2, not Stage 3.
Spec-shaped artifacts that are not specifications. Many organizations have documents they call specifications that are actually requirement summaries — descriptions of what the system should do, written for human review and not engineered for agent consumption. A real specification has an input contract, an output contract, acceptance criteria, edge cases, and test cases at sufficient precision that a coding agent can regenerate the implementation deterministically. A requirements summary has none of those. The diagnostic is to point a coding agent at the document and ask it to regenerate the component from scratch. If the regeneration drifts substantially from the production implementation, the document is not a specification.
Each of these patterns lets an organization claim Stage 3 while operating at Stage 2, or claim Stage 4 while operating at Stage 3. Boards that accept the claim at face value are not getting the picture they need.
What the board should actually be asking
A small set of questions cuts through the adoption-versus-maturity confusion. Each one has a Stage 1 answer, a Stage 2 answer, a Stage 3 answer, and a Stage 4 answer — and the gap between answers is observable without engineering credentials.
- "If we asked three engineers to build the same component independently, how similar would the results be?" Stage 1: not at all. Stage 4: nearly identical, because the specification is the source of truth.
- "When the senior engineer on this team takes parental leave, what happens to output quality?" Stage 2: it drops. Stage 4: it does not change, because the specifications and validation pipelines hold the discipline.
- "What happens when this component needs to be migrated to a new language or framework next year?" Stage 1: a rewrite project. Stage 4: an update to the specification followed by regeneration.
- "How is AI-generated code reviewed differently from human-written code?" Stage 1: it is not. Stage 3: it is reviewed against an attached specification. Stage 4: it is reviewed against a specification with an automated validation pipeline that decides admissibility before a human looks at it.
- "Show me the artifacts that document why this module behaves the way it does." Stage 1: tribal knowledge and Slack threads. Stage 4: a versioned specification in source control alongside the code, with full execution provenance.
These are not engineering questions. They are operating-model questions. A board member without a software background can ask any of them and read the quality of the answer.
The leadership move
AI changes software economics only when leadership changes the operating model. Buying tools without changing the model produces a more expensive Stage 1 — same vibe coding, more seats. Reporting velocity in aggregate without separating the stages obscures whether the operating model has actually moved.
The first concrete action is to stop reporting tool adoption to the board and start reporting stage. Where on the curve is the organization actually operating, by component, by team? What is the plan to advance the stage on the components that matter most? What investments — in specifications, in validation pipelines, in orchestration — are required to move from one stage to the next? These are the metrics that put engineering discipline on the agenda alongside procurement spend.
Every company can buy the same tools. Very few can produce the same result twice, explain why it worked, and scale it without adding chaos. That is what separates vibe coding from reliable systems. Your board should know which stage you are actually at.
Are you still reporting adoption instead of maturity?