I wrote about the Dark Factory earlier this year, covering StrongDM’s Level 5 autonomous software factory where three engineers ship production code with no human touching the implementation. In that article I mapped the five levels of AI coding autonomy, a framework that has become a useful shorthand for where organizations sit on the spectrum from human-driven coding to full autonomy:
- Level 1: AI-Assisted. Human drives everything; AI is a faster keyboard
- Level 2: AI-Generated + Human Review. AI drafts, human approves every PR
- Level 3: AI-Generated + Automated Gates. AI writes, tests review, humans on failures
- Level 4: Mostly Autonomous + Escalation. AI handles the full loop, humans on novel issues
- Level 5: Full Dark Factory. AI runs end-to-end, humans define goals only
Most organizations today are somewhere between Level 2 and Level 3. They have some form of AI coding assist: GitHub Copilot, Cursor, Claude Code, an internal agent pipeline. And they are measuring the productivity gains in pull request velocity. Stripe’s Minions ship 1,300 PRs per week at Level 2-3. The numbers are impressive and real.
But here is what those velocity metrics are hiding: the bottleneck is migrating upstream, and most teams won’t notice until it has already constrained them.
The Bottleneck Migration#
Every level transition in this framework shifts where the constraint lives. At Level 1, the bottleneck is writing code. Getting a 2x or 3x speedup on implementation produces visible gains because that is where all the time was going.
At Level 2 (generated + human review), the bottleneck moves to code review. You are generating code faster than humans can validate it. Teams respond by automating review checks: linting, static analysis, test gates. That gets you to Level 3.
At Level 3 (automated gates), the bottleneck moves to integration and deployment. Running generated code through CI at scale becomes the constraint. Teams build automated validation pipelines, digital twin environments, probabilistic satisfaction metrics. That gets you to Level 4.
At Level 4, something different happens. The factory can handle implementation, testing, and deployment with minimal human intervention. The bottleneck moves upstream for the first time. It lands on the humans who write the specs that feed the factory. Your AI agents can build almost anything, but only what has a written specification that is precise enough, complete enough, and unambiguous enough for autonomous implementation.
This is the spec ceiling. Most organizations haven’t hit it yet because they are still at Level 2 or Level 3. They are celebrating coding speed gains that their current spec throughput can support. But as they climb toward Level 4, which every AI-accelerated organization eventually does, the constraint will shift from “how fast can we build” to “how fast can we define what to build.”
The symptom is predictable: product managers rushing, specs getting thinner, misalignment between what was specified and what was needed, and the quiet realization that you built the wrong thing faster than you ever could have before.
As orgs climb the five levels of AI coding autonomy, the bottleneck migrates upstream. At Level 4, the constraint is no longer implementation velocity: it is spec creation.
The Raw Material Already Exists#
The most elegant part of this problem is that the raw material for solving it is already being produced by every organization that runs stakeholder meetings.
You should record every product conversation by default. The technology is effectively free: Zoom transcripts, Otter, Fireflies, built-in meeting recording platforms, or a local Whisper instance if you want to keep the data on your own infrastructure. The cost of not recording is orders of magnitude higher: lost context, misremembered decisions, requirements that shift because nobody can go back to what was actually said.
That hour-long call with a stakeholder is not just a meeting recap. It’s the densest signal source your organization produces about what actually needs to be built. Stated requirements, implied constraints, deferred decisions, edge cases buried in anecdotes, abstract nouns that sound shared but are not; all of it is in the transcript.
The problem is that human note-taking extracts only a fraction of that signal, and the rest stays in the recording, effectively lost.
What I Built#
I spent the last year building the toolchain that extracts the other 80 percent. It’s open source, lives in my hermes-profiles and agent-skills repositories, and works with any AI agent platform that supports the Agent Skills format. It has three layers, designed to match the three phases between a raw conversation and an executable spec.
Layer 1: The product-discovery skill#
This skill takes a meeting transcript and runs it through a structured distillation process. It segments the conversation by utterance type: statements of desire, anecdotes, rules and constraints, hedges, deflections. It extracts candidate acceptance criteria (AC) from each segment using linguistic markers: “we need to [capability]” becomes a direct AC, “when X happens, Y breaks” becomes an implied AC (the inverse of the complaint), “remember when X happened?” gets freeze-framed into three specific edge cases (before, during, after).
Every AC gets classified by origin. SAID requirements are explicit statements from the stakeholder. IMPLIED requirements are logically necessary for a SAID requirement to work. INTERPRETED requirements come from domain knowledge the distiller brings. INFERRED requirements are derived from gaps and avoided topics; those stay as open questions, never as ACs.
Then there’s the cleanup pass: flagging weasel words like “we should probably handle that” (a deferred decision) or “ideally it would integrate with Salesforce” (a wish list item without a priority). And decomposing abstract nouns: “scalable,” “secure,” “user-friendly,” “efficient” all sound like shared understanding but never are. Each one gets broken into specific, measurable thresholds before it becomes a requirement.
The output is a structured requirements artifact: a document that organizes every finding from the conversation by type and confidence level. It’s ready for a product manager or technical lead to review.
Layer 2: The product-manager profile#
The PM profile consumes the distillation artifact and produces a product requirements document (PRD). That means a problem statement, target audience, user stories in proper “as a / I want / so that” format, scope boundaries, success criteria, explicit non-goals, and open questions. It enforces layer discipline: concepts and principles at the right level of abstraction, never implementation details masquerading as requirements.
The output follows the artifact-pyramid format: progressive disclosure. An L1 summary for stakeholders and executives, L2 analysis for the product team, L3 dossiers with raw evidence for implementers. No information loss between layers.
Across the pipeline, a few product terms are worth knowing if you haven’t worked in that space. Acceptance criteria (AC) are the specific, testable conditions that must be true for a feature to be considered complete: “the system returns a 200 response within 500ms” is an AC, “the system should be fast” is not. Given/When/Then is a format for writing those ACs that comes from behavior-driven development: given a certain state, when an action happens, then a specific outcome should occur. Non-functional requirements (NFR) are the operational constraints (performance thresholds, security requirements, observability standards) that sit alongside the behavioral spec.
Layer 3: The SDD Pipeline#
The Spec-Driven Development (SDD) pipeline takes the PRD and produces implementable specifications. Acceptance criteria in Given/When/Then format. Edge case enumeration. Non-functional requirements with measurable thresholds. Data contracts. Quality gates at every transition point.
The SDD pipeline is tool-agnostic. The specs it produces can feed Claude Code, Cursor, Devin, OpenHands, Hermes Agent, or any other AI coding system. The spec format defines the destination; the factory finds the path.
Where Humans Stay in the Loop#
None of this pipeline replaces the people who understand the domain. It amplifies them. Here is where the human judgment sits.
The product-discovery skill produces a requirements distillation. A product manager or technical lead reviews it before anything moves forward. Did the agent correctly interpret the stakeholder? Are the SAID/IMPLIED classifications right? Are the open questions complete? The review is quick, not a second shift of work.
The PM profile produces a PRD. That PRD becomes the agenda for the next conversation: a working session between the product manager, the technical architect, and (where relevant) a data architect or platform lead. This is a small team of subject matter experts who know the domain, the constraints, and the tradeoffs. They discuss how they want to execute on the PRD. What architectural approach fits this problem? What do we already have that we should reuse? What risks do we need to design around?
This conversation is also recorded. Its transcript feeds into the technical-architect profile, which I created to handle exactly this handoff. The profile loads architecture skills (C4 diagramming for structural views, ADR authoring for decision records, arc42 context mapping for system constraints) and produces a complete architectural artifact pyramid.
Specialist profiles for data architecture, site reliability, and security each contribute domain-specific artifacts: data models, operational requirements, threat models. The orchestrator profile ties them together, decomposing the full workflow and routing each phase to the right specialist. The verifier profile gates every transition. The SDD pipeline takes the full picture and produces implementable specifications.
The key insight: the process never removes the human. It removes the friction of manual documentation so the humans can spend their time on the things that require judgment. Decisions, not typing.
How It Works End to End#
Record a stakeholder meeting. When it ends, drop the transcript file into a directory and tell your AI agent to load the product-discovery skill. The agent processes the transcript against the full methodology: stakeholder role classification, question pattern analysis, gap detection, conflict identification.
The output lands as a structured artifact. A product manager or technical lead reviews it. This takes minutes, not hours, because the artifact is structured and opinionated. Did the agent correctly identify the SAID requirements? Are the open questions complete? The review is a confirmation pass, not a reconstruction.
Load the product-manager profile against the reviewed artifact. The profile produces a PRD with properly scoped user stories, explicit non-goals, and flagged open questions.
Now the PRD becomes the agenda for the working session that produces the actual spec. The product manager, technical architect, and (where relevant) a data architect or platform lead sit down to discuss how they want to execute. What architectural approach fits this problem? What do we already have that we should reuse? What risks do we need to design around?
This conversation is recorded too.
That second transcript feeds into a different set of skills: the C4 diagramming skill produces architecture views, the ADR authoring skill captures architectural decisions, the arc42 context skill maps system constraints. The SDD pipeline takes the full picture and produces implementable specifications with acceptance criteria, edge cases, non-functional requirements, and data contracts.
The end-to-end pipeline: two transcripts, three phases, multiple specialist profiles, verifier gates at every transition. No information loss between handoffs.
Every spec carries an audit trail back to its origin. Every decision is documented. Every open question is flagged.
If you are running a software factory at Level 4 or 5, those specs feed directly into the implementation pipeline. If you are at Level 2 or 3, they give your engineering team better requirements than they are getting today from rushed product meetings and hallway conversations.
A meeting that used to end when you left the Zoom now ends when your agent hands you a draft spec. You do not lose the 80 percent of signal that falls through the cracks of human note-taking. And as your organization climbs the autonomy levels, you are not bottlenecked by spec throughput because the pipeline is already in place.
The Factory Needs Fuel#
The AI coding agent industry is obsessed with one question: how fast can we generate code? Every new model release, every new agent benchmark, every demo video centers on implementation velocity. And the gains are real. But generation speed is only one side of the equation.
A factory that can build anything but can only be fed by humans writing specs by hand is a factory running at 20 percent utilization. The bottleneck has moved upstream. The tools for breaking through that bottleneck exist today. They are open source. They start with the simplest possible input: a transcript from a meeting you should have been recording anyway.
Clone the hermes-profiles repository. Load the product-discovery skill and the SDD pipeline from the agent-skills repository. Wire them into any agent platform that supports the Agent Skills format. The pipeline runs. The spec ceiling breaks.
The question is not whether your organization will hit this ceiling. It’s whether you will have the pipeline in place when you do.