On 3 August, developer Niklas Gruhn gave a name to something every team working with agents had already seen: the meat proxy, the person who forwards what an AI produces without reading, understanding or validating it. His sharpest example isn't a Slack message, it's a pull request. You paste the ticket into the agent, don't look at what comes out, and let the reviewer's comments drive the iterations. The change eventually gets merged, but the reviewers did the work with the agent, and you were the go-between.
On 21 September, the Spanish talent platform Shakers took the term into Spanish with the right question — who signs off what the AI writes — and an example of harm any CTO will recognise: a functional specification that reaches development with an invented requirement and gets built in full before anyone notices the business never asked for it. It also puts a cost on it, citing the September 2025 study by BetterUp Labs and the Stanford Social Media Lab: 40% of 1,150 US desk workers had received that kind of content in the previous month, each incident took around two hours to deal with, and the total came to $186 per employee per month. That's office work in general, not code, but the mechanism is the same.
This piece picks up the specification example, because it points at something the meat-proxy conversation hasn't said yet: in a development cycle run with agents, the answer isn't to review the code harder, it's to sign off earlier. And the sign-off has a specific place.
The meat proxy isn't an attitude problem
The easy reading is moral: some people don't read what they send. The useful one is about design. If the only point in your process where a person validates the work is the pull request, whoever opens that pull request is a go-between by construction. They didn't choose the approach — the agent did — they didn't write the lines, and if the change is large they're reading it for the first time with the same attention as their reviewer.
We set out the data in your review still expects an author: code review rests on there being someone you can ask why, and with generated code that someone often doesn't exist. The conclusion there was to move the why into an artefact written before generation. This piece picks up what was left open: who answers for that artefact, and how you can tell someone has.
Reviewing harder doesn't fix what was decided earlier
Go back to the Shakers example and follow the invented requirement through the process. The agent implements it well, with passing tests. The reviewer checks that the code is correct, that nothing is duplicated and that the tests actually test something. Everything checks out. A flawless review confirms that the invented requirement has been built properly.
Review compares code against an intention. If that intention was never written down and nobody approved it, the comparison is against whatever the reviewer remembers or assumes about the ticket. No extra effort on the diff fixes that, because the error isn't in the diff: it's in a decision nobody made explicitly. That's why a test written from the code doesn't test it, it describes it, and why a review done without a written criterion ends up as an opinion.
Where the sign-off goes in an agent-driven development cycle
The flow shared by Spec Kit, Kiro and most Spec-Driven Development implementations is the same: specification, plan, tasks, code. Thoughtworks' Technology Radar has summarised it that way since November 2025. What none of those outlines says is which artefact each person answers for. This is our proposal:
| Artefact | What it decides | Who answers for it | How it's exercised |
|---|---|---|---|
| Project constitution | The rules no change may break: architecture, allowed dependencies, security, conventions | Tech lead / architecture | Sign-off. Changes rarely, and each change is approved separately |
| Specification | What gets built, why, what's out of scope and which cases make it acceptable | Product (what and why) + tech lead (buildable) | Sign-off, before generation. This is the main checkpoint |
| Technical plan | How it gets built: modules, data, contracts, risks | Developer responsible for the change | Approval. Checked against the spec and the constitution |
| Tasks | The plan broken into units the agent executes | Proposed by the agent | Accepted, not signed off. If they need debating, the problem is in the plan |
| Code | Nothing new: it should follow from everything above | Written by the agent | Reviewed against the spec: does it do what it says, and what else does it do? |
| Acceptance cases | Executable proof that the spec is met | Whoever signed off the spec (derived from it) | They come from the spec, never from the generated code |
Two real sign-offs — constitution and specification — one technical approval, and everything else judged against what was signed. onext's proposal
Two things in the table are worth not skimming. First: the sign-off goes where there's a human decision the agent can't make, not at every step. Signing off tasks or generated code is bureaucracy; signing off what gets built and what stays out is responsibility. Second: the code stops being the place where things get decided. If a new decision shows up in review — a dependency, a field nobody asked for, a way of handling errors — it isn't argued about in the diff. It goes back to the spec, because that's where someone has to answer for it. It's the same rule we apply to the line in the pull request nobody argues about.
The tools generate the spec; none of them require anyone to sign it
Here's the uncomfortable part for anyone who bought SDD as a tool. We went through the documentation of the two most widely used ones looking for the point where a person approves the specification before moving on.
In Spec Kit, GitHub's toolkit, the specification phase is well designed: it asks you to define the what and the why before deciding the how, and leaves technology for the plan. But its documentation doesn't set any mandatory approval between phases. It recommends reviewing the result before continuing, and leaves it there. In Amazon's Kiro, the full flow guides you through requirements, design and tasks, and the documentation also offers an explicit shortcut: for well-understood features, Quick Spec generates all three artefacts “without approval gates”. Claude Code has a plan mode that proposes a plan and doesn't touch any file until you approve it, but that approval lives in one person's session, not in a versioned artefact in the repository.
This isn't a criticism of the tools: generating the artefact is their job, and deciding who answers for it is the organisation's. But it's worth seeing the risk it opens up. With a badly implemented SDD, the agent writes the spec, the agent writes the code, and the person forwards both. That's a meat proxy with more steps and the look of a method. Thoughtworks' Radar points the same way in different words: some tools generate long specifications that are hard to review, and it's sometimes unclear who they're meant for.
The serious objection: nobody wants to read specifications
It deserves to be told in full, because it's the best published critique of SDD and the hardest one to answer. In October 2025, Birgitta Böckeler of Thoughtworks tried Kiro, Spec Kit and Tessl on real cases. Her conclusions: Spec Kit's output felt very verbose and tedious to review, to the point that she wrote she'd rather review code than all those markdown files. Kiro turned a small bug into four user stories with sixteen acceptance criteria. And the agent, with the full specification in front of it, didn't follow every instruction: it went as far as duplicating code by mistaking the description of an existing class for a new requirement.
All three observations are true, and none of them sinks the thesis. They correct it in three specific ways:
- A sign-off on twelve pages is also symbolic. If nobody can read the whole spec, signing it off is the same empty gesture as approving a 400-line pull request. The spec you sign off has to fit on one page, and anything that doesn't fit is a sign the change is too big. We cover format and length in the decision table for SDD artefacts.
- Not everything needs a spec. A one-line bug doesn't get specified: it gets fixed with a test that fails and then passes. Sign-off is for anything that changes business behaviour or touches money, personal data, permissions or migrations.
- A spec doesn't guarantee the agent will follow it. That's why the table doesn't stop at the specification: the code is judged against it, and the acceptance cases come from it. Sign-off doesn't replace verification, it gives it a criterion. It's the same logic that makes the golden set the thing that survives model changes.
Böckeler also distinguishes three levels: the spec written and discarded after the task, the spec kept alongside the feature, and the spec that replaces code as the thing you edit. Sign-off only makes sense in the last two. If the specification is thrown away when the task is done, what you signed off is a document that no longer exists.
SDD, TDD and BDD with agents: what each one validates
The question comes up in every training session, and with agents the answer shifts slightly. The three practices don't compete: each answers a different question, and all three fail the same way when the agent generates the control artefact from what it has already built.
| Practice | Question it answers | Artefact | How it fails with agents |
|---|---|---|---|
| TDD | Does the code do what the tests say? | Unit and integration tests | The agent writes the tests after the code, and they describe the implementation instead of testing it |
| BDD | Is the behaviour what the business described? | Given / When / Then scenarios | Scenarios are generated from the implementation and paraphrase it |
| SDD | Is what's being built what was decided, and who decided it? | Versioned, signed-off specification | The agent generates the spec and nobody signs it off: the invented requirement gets in looking like method |
The same failure mode in all three: the control is born from the thing it controls
In practice they fit together like this: the acceptance scenarios live inside the spec — they're signed off together with the what and the why — and the tests are derived from those scenarios, not from the code. BDD provides the format, SDD provides the sign-off and TDD runs the check. The order matters more than the label: first what was signed off, then what was generated.
The spec lives in your repository, not in the tool
A practical consequence of putting the sign-off in the artefact rather than the tool: the method doesn't tie you to any agent. Claude Code, Copilot, Cursor or Kiro all read files from the repository. If the signed-off spec is a file, switching tools doesn't change who answers for what. If the sign-off lives in a particular product's session, you lose it when you switch, and the tooling market changes every quarter, as we covered in Claude, Cursor and Copilot in the enterprise.
You already have the mechanism, and it isn't a new tool: a specifications folder in the repository, a CODEOWNERS file assigning that folder to whoever answers for it, and a branch protection rule requiring their approval before merging. With that, the sign-off is recorded with a name, a date and the exact version of the text. One caveat from GitHub's documentation that almost nobody reads: with code owner review switched on, approval from any one owner is enough. If you want both sign-offs — product and technical — you have to require them separately. The tool, on its own, doesn't know the difference between roles.
What you configure in the agent is the reverse: that it doesn't start generating without an approved spec, and that it reads the project's constitution and skills before proposing a plan. Responsibility lives in the repository and the agent reads it. Not the other way round.
A spec you can sign off, in full
So the idea doesn't stay abstract, this is how short a spec you can genuinely sign off is. The case is made up but typical: exporting the month's invoices for the external accountant.
specs/invoice-export-accountant.md · v1.2
GOAL
An admin user downloads, as a single file, the invoices issued in
a given month, in the format their accountant asks for.
WHY
Today they're copied by hand at every month-end close (about 3 h).
Requested by Finance in ticket FIN-214.
OUT OF SCOPE
- Invoices received.
- Automatic sending to the accountant.
- Any format other than CSV.
ACCEPTANCE CASES
1. Given a month with issued invoices, when I export, I get a CSV
with one row per invoice and the columns in appendix A.
2. Given a month with no invoices, when I export, I get the CSV
with a header and no rows, and an on-screen notice.
3. Given a user without the admin role, they don't see the option.
OPEN DECISIONS
None.
SIGN-OFFS
Product ......... [product owner] · 2026-09-18 · PR #412
Technical ....... [tech lead] · 2026-09-18 · PR #412Three lines in that example do almost all the work. “Out of scope” is the one that catches the invented requirement: if the agent adds automatic sending because it seemed useful, review is no longer an opinion, it's a comparison against a signed-off line. “Open decisions: none” is the condition for signing: as long as there's one, the spec isn't ready and the agent doesn't start. And the sign-offs aren't decoration: if someone asks tomorrow why the export doesn't include received invoices, the answer has a name, a date and a pull request.
Signing off that page takes minutes. It takes a lot less than reading 400 generated lines looking for something nobody said shouldn't be done. And it changes the review question from “is this all right?” to “does this do what we signed off, and what else does it do?”, which is a question a reviewer can actually answer, even without having written a single line. It's also what separates an MVP from a quick ship.
Every merge is already a sign-off
One last point, for anyone who thinks this adds red tape. Your team already signs off: every pull request approval is a sign-off, with a name and a date, on a change that goes to production. The only thing agents change is what's being signed. If the only sign-off in the process is on the code, you're signing off something no person wrote. If it's on the specification, you're signing off the one thing a person actually decided.
You don't fix the meat proxy by asking people to read more. You fix it by moving the sign-off to where there's something to decide.
Frequently asked questions
What is a meat proxy, and what does it have to do with software development?
It's someone who forwards what an AI produces without reading, understanding or validating it. The term was coined by developer Niklas Gruhn on 3 August 2026, and his sharpest example is about code: paste the ticket into the agent, don't look at what comes out, and let the reviewer's comments drive the iterations. In that case, Gruhn says, the reviewers did the work with the agent, and whoever opened the pull request was only a go-between. In software the pattern is especially expensive, because what gets forwarded ends up in production.
What does it mean to “sign off” a specification in practice?
Nothing like a PDF with a signature scrawled on it. It means the specification is a versioned file in the repository, and it gets into the main branch through a pull request approved by named people, before the agent generates any code. The sign-off is that approval: it records who, when and on which exact version of the text. From then on, the code is judged against that file, and any change of scope means editing it and getting it approved again.
Who should sign off the specification?
Two people, because they sign off different things. Whoever owns the product signs off the what and the why: that this is what the business asked for, and that what's out of scope is rightly out. Whoever owns the technical side signs off that it can be built and is consistent with the project's rules. What doesn't work is having only the person who generated it with the agent sign it: that's the same person reviewing their own forwarding. Watch the tooling: with GitHub CODEOWNERS, approval from any one owner is enough, so you have to require both sign-offs separately.
Can the agent write the specification?
As a draft, yes, and it usually saves time. The condition is that whoever signs it off can defend every line without going back to the agent: it's Gruhn's test applied to the spec. If they couldn't explain a sentence in a meeting, or don't know where a requirement came from, they can't sign it. The example of harm Shakers gives is exactly that: a specification that reaches development with an invented requirement and gets built in full before anyone notices the business never asked for it.
How is SDD different from TDD and BDD when you work with agents?
They answer different questions and complement each other. TDD checks that the code does what the tests say. BDD checks that the behaviour is what was described in business scenarios. SDD pins down what was decided, why, what's out of scope and who decided it. With agents, all three fail in the same way if the agent generates the control artefact from the code: tests that describe the implementation, scenarios that paraphrase it, or a spec nobody signed off. In practice, the acceptance scenarios should live inside the spec, and the tests should be derived from them, not from the code.
Isn't this just going back to waterfall?
No, as long as the spec covers one feature and fits on one page. Waterfall signed off a big document at the start of the project; here you sign off a short text before each meaningful change, in minutes. The objection is partly right, and it's worth accepting that part: Birgitta Böckeler watched a tool turn a small bug into four user stories with sixteen acceptance criteria. A one-line bug doesn't need a spec. A feature that touches money, data or permissions does.
Sources cited
- Gruhn, N. — Don't be a meat proxy (3 August 2026; origin of the term and the pull request example)
- Willison, S. — Don't be a meat proxy (3 August 2026; the note that spread the term)
- Shakers — Meat proxy: quién firma lo que la IA escribe (21 September 2026, in Spanish; the example of the specification with an invented requirement)
- BetterUp Labs and Stanford Social Media Lab — Workslop (September 2025; 1,150 US desk workers, 40% affected in the previous month, about 2 hours per incident, $186 per employee per month)
- Böckeler, B. — Understanding Spec-Driven-Development: Kiro, spec-kit, and Tessl (15 October 2025; the three levels of SDD and the critiques on review burden, sizing and compliance)
- Thoughtworks — Technology Radar: Spec-driven development (Assess ring, November 2025)
- GitHub — Spec Kit (constitution, specify, plan, tasks and implement flow)
- Kiro — Specs (documentation; Quick Spec without approval gates)
- Anthropic — Claude Code: Common workflows (plan mode: proposes and makes no edits until approved)
- GitHub — About code owners (required code owner review; approval from any one owner is enough)
Jordi García is Tech Lead at onext. He works on bringing AI into governed production across development and product teams —with Spec-Driven Development, context engineering and human verification at every step— and authors onext's technical insights on the method, quality and cost of applied AI.
LinkedIn →