The AI Engineering Stack: Specs, Standards, Skills, Agents, Reviews, and Memory

The model writes the function in four seconds. The pull request lands an hour later. The reviewer spends most of that hour reconstructing what the function was supposed to do, because nobody wrote it down. Multiply that across a delivery team and you get the thing leaders keep describing to me without a name for it: more code, more sessions, more output, and a delivery line that has not moved. The speed is real. The compounding never arrives.

The new AI engineering stack is not your IDE and your model. It is the six durable classes of artifacts that have to exist around the speed for that speed to compound into delivery: Specs, Standards, Skills, Agents, Reviews, and Memory.

That sentence is doing a lot of work, so let me be precise about what it is arguing against. Ask most engineering leaders what their AI stack is and they will name products: the editor, the model, the agent framework, maybe a vector store. That answer is not wrong. It is a different cut of the same territory, and it is the cut everyone already publishes. The pieces you buy are real and you need them. But the products are not where AI-assisted delivery succeeds or fails. The artifacts are.

This is the layer that gets discussed in pieces but rarely mapped as one owned system. There are excellent guides to which coding agent to adopt and which model to put behind it. There are almost none that describe the layer between the model and the delivery outcome: the things a team produces, owns, and maintains so that AI speed turns into changed work instead of faster mess. That layer is what I want to map here. Each class in it is a durable thing your team writes and keeps, with a named owner, a specific failure mode when it is absent, and a way it composes with the others. Get the map right and you can look at any AI-assisted team and see where to investigate: which classes it has built, and which one is missing. Presence is a diagnostic, not a guarantee. Whether those classes actually produce leverage depends on whether the artifacts are valid, used, and tied to outcomes, not on which model the team picked.

AI speed is the input, not the win, and the artifacts are what convert it

Here is the part that surprised me the first time I watched it carefully. AI sharply reduced the marginal cost of producing many kinds of code. It reduced almost none of the cost of specifying the work, governing it, reviewing it, and remembering what was decided. Those costs did not disappear. They moved.

Every feature still demands work across four fronts: figuring out what to build, writing it, checking it, and retaining what you learned for next time. The total does not vanish; the balance between the fronts shifts. For two decades, writing it was the expensive part, so that is where tools and headcount went. Generative coding agents collapsed that line item. The other three costs are now the binding constraints, and most teams have no artifacts that carry them. So the work does not get cheaper. It gets relocated onto the reviewer, who is now reconstructing intent the spec should have held, and onto the next session, which re-derives a decision the memory should have kept.

This is the operational shape of the most common complaint I hear from CTOs and VP-Engineering: AI usage is high, delivery metrics are flat. The instinct is to read that as an adoption problem. Buy more seats, run more training, write better prompts, switch the tool. None of that touches the actual gap, because the gap is not whether people are using AI. It is whether the work around the AI has been redesigned to absorb the new volume. Tool adoption without that redesign produces activity, not capability. You can measure the difference: did cycle time, review load, and rework move, or did only the usage dashboard move?

So the question a delivery leader should be asking is not "are the developers using AI." It is "which of the stack's six classes does the team actually have, and which one is the missing class that is leaking all the leverage." That is the map. The rest of this piece walks it, one class at a time.

Specs are the artifact that decides whether you review intent or review code

Picture the agent receiving a one-line ticket: "add export to CSV." It will produce working code. It will also invent the column order, the date format, the handling of nulls, the encoding, and whether the export respects the current filter. Some of those guesses will be wrong, and you will only find out at review, where you are now reading a hundred lines of code to reverse-engineer a decision that should have taken one sentence to state up front.

Specs are the executable intent layer: the artifact that states what to build and what "correct" means before the agent writes a line. This is the class that the spec driven development conversation is circling, though that conversation usually treats it as a single practice rather than as one position in a larger system. The work at martinfowler.com on spec-driven development, and the tooling around GitHub's spec-kit, are both worth reading as evidence of where this class is heading: a spec becomes a structured, version-controlled input the agent reads, not a Confluence page nobody opens. The operational read is that the spec stops being documentation about the work and becomes the control surface for the work. That is the brand of this class. Specs are not documentation, they are the layer where you review intent up front, so code review can concentrate on risk, integration, and judgment instead of reconstructing intent line by line.

The typical accountable owner is the PM or BA who holds the requirement, working with the Dev Lead who holds the technical shape. This is a real role-level redesign, not a tooling tweak: a PM who used to write a user story for a human now writes an input precise enough for an agent to execute against, and a BA who used to validate requirements in a meeting now validates them as a checkable artifact. The failure mode when the class is absent is specific and expensive. The agent guesses, the guesses scatter, and your most senior reviewers spend their time reconstructing intent from implementation. Review load rises with throughput instead of falling, which is the opposite of the leverage you bought the agent for.

Specs compose with everything downstream. A spec is what an agent should be governed against, what a review should check against, and what memory should retain. When this class is missing, the other five have nothing solid to anchor to, which is why I treat it as the foundation of the map even though it is not the most visible class.

Standards are what stop every agent session from re-litigating how you build

Run the same prompt against the same codebase on Monday and again on Thursday, and you can get two different architectures, two naming conventions, two takes on error handling. The model did not change. What changed is that nothing told it how this team builds, so it decided fresh each time. Quality becomes a coin flip per session, and the variance shows up as review churn.

Standards are the agent-readable rules: the conventions, constraints, and architectural decisions written in a form the agent reads on every run. In the Claude Code paradigm this lives in a CLAUDE.md file; in the OpenAI Codex paradigm, an AGENTS.md; more generally, the rules files and configuration that travel with the repository. The distinction that matters is the word agent-readable. A wiki of coding standards that humans are supposed to remember is not this class. Agent-readable standards are loaded into the context of every session automatically, so the conventions are present before the agent generates rather than discovered at review time. That placement is not enforcement: standards bias what the agent produces, and actually enforcing them still takes executable checks, permissions, tests, or review gates. Standards are not a style guide humans consult, they are the conventions the agent reads before it writes, and the reason review has less to catch.

The owner is the Dev Lead or the Architect, because this is where architectural intent gets encoded into something that actually constrains the work. The failure mode when the class is absent is that every session re-decides the conventions, so consistency depends on whoever happens to be reviewing and how much energy they have that day. With standards present, the convention is upstream of the code; without them, it is a negotiation that happens after the code exists, which is the most expensive place to have it. Standards compose tightly with Specs: the spec says what to build, the standards say how this team builds it, and together they shrink the review to checking the parts that required judgment.

Skills are the class that decides whether capability compounds or dies in one person's prompt history

The most capable person on an AI-assisted team is usually the one who has figured out, through a few hundred sessions, exactly how to get an agent to do the hard thing reliably: the right sequence of steps, the right tool to wire in, the right way to frame the problem so the model does not wander. That capability is worth a great deal. It is also, in most teams, completely invisible and entirely unowned. It lives in one person's chat history and walks out the door when they take a new role.

Skills are codified, reusable capability: a named procedure, a wired-in tool, a documented workflow that any team member or any agent can invoke without re-deriving it. This is the class where the Claude-Code-paradigm vocabulary becomes operational. A skill file packages a procedure so it can be triggered by name. The neighbors matter for keeping the boundary clean: MCP, the Model Context Protocol, is a cross-cutting platform dependency, the wiring several classes use to reach real tools and data; delegation and subagents belong to Agents; deterministic hooks and gates belong to Reviews. Skills is the procedural-knowledge class, not a catch-all for every extension mechanism. The point is not the specific names. The point is that capability has to become an artifact, or it does not compound. Skills are not individual cleverness, they are the team's capability written down so it survives the person who discovered it.

The natural owner is a Senior Engineer, because identifying which capabilities are worth codifying, and writing them so they hold up across contexts, is senior judgment. The failure mode when the class is absent is the one I see most often in teams that are individually good with AI and collectively flat: every engineer reinvents the same workflows privately, the strongest patterns never propagate, and the team's capability is the sum of its individuals rather than something larger than them. That is the difference between AI activity and AI performance at the capability layer. Skills compose with Standards and Agents directly: a skill encodes a procedure, the standards constrain how it runs, and the agent is the surface that executes it.

Agents need a governed surface or the speed turns into faster chaos

A coding agent with full access to a repository, no constraints, and a vague instruction is the fastest way I know to generate a large volume of plausible work that nobody asked for and nobody can fully trust. The speed is not the problem. The speed without a control surface is the problem, and it is the precise mechanism behind the "faster chaos" that leaders describe when their delivery metrics refuse to move despite obvious AI activity.

Agents are the governed execution surface: the AI coding agents that actually do the work, plus the controls around how they are allowed to do it. Claude Code, Codex, Cursor, and Copilot are the class examples most teams will recognize, and naming them is the easy part. The hard part, and the part that defines this class, is the word governed. An ungoverned agent is a productivity demo. A governed agent is one that runs against a spec, obeys the standards, invokes skills, and operates inside boundaries a human set deliberately: what it can touch, what requires approval, where a human gate sits. That governance is what turns a coding agent from a source of volume into a source of leverage. Agents are not the stack, they are one surface in it, and an agent without the artifacts around it is the most expensive way to ship faster mess.

The owner is the Dev Lead together with whoever owns the platform, because this is where execution meets control. The failure mode when the class is ungoverned is exactly the Pain Point most leaders are living: throughput rises, review load rises faster, seniors spend their time cleaning up confident output, and the delivery line stays flat. The agent is doing more. The system is not getting better. Agents compose with Specs, Standards, and Skills as the surface that consumes all three, which is why an investment in the agent that skips the other classes reliably underperforms its demo.

Reviews must be redesigned for AI volume, or review becomes the bottleneck the AI was supposed to relieve

Most teams imported their old review process into the AI era unchanged, and it is quietly breaking. Human review was designed for a world where writing code was slow, so a senior could read every line a colleague wrote because there were not that many lines. AI inverted that. The writing is fast and the volume is large, but the review is still one human reading every line, which means the human becomes the bottleneck the speed was supposed to remove. Throughput went up; the review queue went up faster.

Reviews are the durable verification system redesigned for AI-volume output: the review policies, checklists, automated gates, and evaluation suites that define what gets checked, by whom or by what, when the volume of generated work no longer fits line-by-line human reading. The label is Reviews, but the class is wider than human PR review: it includes the deterministic checks and evals that handle the routine cases so human judgment is spent only where it is scarce. This is the class most adjacent to the reliability and evals work that some teams build as a separate quality harness, and the two reinforce each other, but they are not the same artifact. AI code review as a class is about the review process itself: which changes need a human eye and which can be gated by a spec check or an automated standard, where the human reviewer's attention should be concentrated, and what "reviewed" means when a human did not read every line. Reviews are not a gate you keep the same and run more often, they are a process you redesign so human judgment lands where it is scarce and valuable instead of spread thin across everything.

The owner is the QA Lead together with the Dev Lead, because redesigning review is a joint act of quality definition and engineering judgment. The failure mode when the class is not redesigned is the most measurable failure in the whole map: review load rises in direct proportion to throughput, your seniors become a queue, and the time-to-merge that AI was supposed to shorten gets longer. Reviews compose backward onto Specs and Standards in a way that makes the whole system pay off: when the spec is precise and the standards are enforced at generation time, review shrinks to checking the judgment-heavy parts, because the routine correctness was handled upstream. A team that fixes Reviews without fixing Specs and Standards is treating the symptom.

Memory is the difference between a team that compounds and a team that starts every session from zero

Watch an AI-assisted team work for a month without this last class and you will see the same decisions get made three or four times. Why did we choose this pattern over that one? Litigated again. What was the reasoning behind this constraint? Re-derived from scratch. The agent has no memory of last week, and increasingly, neither does the team, because the context that used to live in long-tenured engineers' heads now scatters across hundreds of disposable sessions. Each session is locally productive and collectively amnesiac.

Memory is durable context: the decision logs, the memory files, the compounding notes that carry forward what was learned, decided, and tried so the next session and the next engineer start ahead instead of starting over. This is the class that the "compound engineering" and "AI memory" conversation is pointing at, and it is worth reframing what that conversation usually treats as a plugin feature into what it actually is: one class in a larger system. A memory file that records why a decision was made is an artifact the team owns, the same way a spec or a standard is. Memory is not a nice-to-have add-on, it is the class that decides whether your team's AI work accumulates into capability or evaporates after each session.

The owner is a Senior Engineer, because deciding what is worth remembering, and writing it so it stays useful, is the same judgment that codifies skills. The failure mode when the class is absent is the most strategically expensive one, because it is invisible in any single sprint and devastating across a quarter: the team never compounds. Every individual is faster and the organization learns nothing, which is the exact gap between AI activity and durable organizational capability. Memory composes with every other class as the thing that makes them improve over time: specs get sharper because you remember which ambiguities bit you, standards get tighter because you remember which conventions the agent kept violating, skills get better because you remember which procedures worked. Without memory, the other five classes stay static. With curated memory and feedback, they improve across iterations instead of resetting each session.

The six classes, their durable artifact, the role that owns each, and what breaks when the class is missing:

What this map changes for how you run delivery

Here is the implication, and it is an operating-model implication, not a shopping list. If a team's leverage depends far more on which artifact classes it has built and put to work than on which model or editor it bought, then the most important thing a delivery leader can do is stop evaluating the AI rollout by its tools and start evaluating it by its artifacts. Walk the stack's six classes against your own team and the diagnosis tends to be uncomfortable and clear: usually two or three classes are strong, one is the visible weak spot, and one is missing entirely and quietly leaking most of the leverage you thought you bought.

Worth being precise about the boundary of this claim. These six classes are not your operating model. An operating model is a wider thing, covering roles, decision rights, workflows and handoffs, review and control standards, information and system access, incentives and measures, and cadence. The artifact stack is what that operating model produces and runs on. It is the install surface, the place where the abstract decision to change how delivery works becomes six concrete things a team writes, owns, and maintains. You do not get an AI operating model by adopting these artifacts, and you do not get the artifacts without the operating-model decisions behind them. But you cannot run the operating model without the install surface, which is why the artifact stack is the layer worth naming on its own.

So the test on Monday morning is not "did the team use AI." It is concrete and per-role. Did the PM write a spec the agent could execute against, or a story the agent had to guess at. Did the Dev Lead encode the conventions into agent-readable standards, or leave them in a wiki. Did the Senior Engineer codify the team's best AI workflows into skills, or let them stay private. Was the agent governed against the spec, or turned loose. Was review redesigned for the new volume, or just run more often by exhausted seniors. Did the team write down what it decided, or start the next session from zero. Six artifacts, six owners, six failure modes. The teams whose AI investment compounds are the ones who can answer those six questions with an artifact rather than an intention. That is the stack. Everything else is the speed, and the speed was never the part that was hard to buy.

Frequently Asked Questions