The pull request says it “improves authentication reliability.” The checks are green. The summary has a tidy list of files changed, tests added, and risks considered. Then you open the diff. A permission branch has moved. The description never mentions it.
You leave a comment: Why did this condition change?
The author pastes your question into the agent and returns with its answer. You are now reviewing the agent through a human relay.
This is the developer version of TAI-DR: Too AI. Didn’t read. The site behind the phrase asks, “If you couldn’t bother to read it, why should I?” In software, the sharper question is: If you haven’t reviewed this change, why am I the first person who has to?
Agents can produce useful code. They can also produce a convincing account of code they misunderstood. The problem begins when we treat that account as proof that the engineer submitting the change understands it too.
Two names for the same missing step
Developer Niklas Gruhn called the human in this loop a meat proxy: someone who relays a question to an AI and forwards the answer back without adding understanding or judgment. His example comes from Slack and pull request feedback. A reviewer asks about a change; the contributor copies the comment into an agent; the agent drafts a reply or another patch; the contributor passes it along. The reviewer and agent are doing the implementation conversation. The named author is carrying messages between them.
The two phrases describe different sides of one handoff. TAI-DR names the unread artifact. Meat proxy names the person who forwards it. Neither is an argument against using an agent. The missing step is the same in both cases: a human has put their name on work they have not absorbed.
That is why the term has caught on with developers. It is a blunt description of a familiar review loop, not a technical classification. PaperMC’s agent instructions now warn against turning a contributor into a meat proxy: maintainers can run agents themselves; a contributor’s value is their context, validation, and ownership. The point is not that every AI-assisted patch is suspect. It is that forwarding output is not a contribution by itself.
A green check is not an explanation
A test suite tells you that certain assertions passed in a particular environment. It does not tell you why a branch changed, whether a missing test matters, or whether the new behavior is what the product needs. The same is true of an agent’s summary. It can describe the intended change without noticing the consequential one.
Imagine a 400-line PR to simplify login. Most of it is routine: renamed functions, moved helpers, new tests. Deep in the diff, a fallback path now returns success where it used to reject an expired session. The tests cover valid credentials and malformed input, but not the expired-session path. The PR description says “no behavior change.” A reviewer finds the problem because they read the code. The author’s job was to find it before asking for review.
This is not a claim that humans never miss such bugs. They do. The difference is the handoff. If I submit code under my name, I am telling a teammate I have made a first pass: I know the behavior I intended, I have looked for unintended changes, and I can answer questions about the patch. Without that pass, review becomes outsourced comprehension. The meat proxy has done the one thing a proxy does well—forwarded the request—while leaving the important work for somebody else.
Oxide’s public guidance on LLMs puts the responsibility for generated code on the engineer using the model and calls self-review essential before peer review. That is a practical rule, not a purity test. A reviewer is there to bring another mind to the change, not to be the first mind applied to it.
The code is only one artifact
Developers leave a trail for the next person: commit messages, PR descriptions, migration notes, runbooks, and design decisions. AI can write all of them. That makes their failure mode less obvious than a broken test.
A generated PR summary often reports what files changed while skipping the question a reviewer actually has: why this design? “Refactored the service layer for maintainability” is a sentence with nowhere to go. “Moved retry handling into the queue worker because a request timeout was causing duplicate jobs; the worker now records the attempt before retrying” gives someone a claim they can check against the diff. The second sentence is useful because it carries a causal story, not because it sounds less like AI.
Commit history is even less forgiving. Six months later, nobody cares whether the message was typed by hand. They care whether git blame leads to an explanation of the tradeoff. “Fix login” attached to three successive commits is a locked door. A well-written but inaccurate agent message is a door that opens onto the wrong room.
Documentation can drift the same way. If an agent writes a setup guide from code it has not run, the guide may be beautifully organized and still tell a new teammate to set an environment variable that no longer exists. The reader pays for the polish by debugging a problem the author could have caught with one dry run.
Ben Martens wrote about tai;dr in the context of documents and software: writing down a system is often part of how you come to understand it. When an agent does all the explaining, it is possible to ship a design note without ever having formed the design in your own head. The warning is less “write every word yourself” than “do not mistake a finished paragraph for a finished thought.”
What a responsible agent-assisted PR looks like
There is no virtue in manually typing boilerplate that an agent can produce well. The point is to spend the saved time on the parts that require ownership. A developer stops being a meat proxy the moment they become an interpreter: they inspect the result, connect it to the system, decide what to keep, and can explain why.
Before opening a PR, a developer should be able to do four things:
- State the behavior change in plain language. Include the old behavior, the new behavior, and the reason. If the answer is “the agent handled it,” the change is not ready.
- Read the entire diff, including generated tests. Look for unrelated edits, changed defaults, broadened permissions, deleted checks, and tests that merely encode the new implementation. A passing test that asserts the wrong behavior is still a passing test.
- Exercise the risky path. That may mean running a focused test, checking a migration against real data shapes, trying the failure path locally, or inspecting the emitted request. The right evidence depends on the change; “CI is green” is rarely the whole story.
- Write the handoff for the reviewer. Say what deserves attention, what you verified, and what remains uncertain. If the patch has a tradeoff, name it. A reviewer can work with uncertainty; they cannot work with a summary that hides it.
This is also a useful standard for reviewers using AI. Let a model flag suspicious hunks or explain an unfamiliar module. Then inspect the evidence yourself. A generated review comment that you cannot defend simply moves the meat proxy to the other side of the conversation.
Do not turn this into an AI detector
The phrase “too AI” can make us overconfident. Fluent prose does not prove that an author skipped review. Clumsy prose does not prove diligence. Developers who write in a second language or use assistive tools may rely on AI to make their reasoning readable. Dismissing a contribution because it has a recognizable model cadence misses the real question.
Ask about the work instead. What does this line do? Why is this test sufficient? What breaks if the deployment stops halfway through? Can the author point to the source of a claim in the design doc? If they can, the origin of the first draft matters much less. If they cannot, the patch needs another pass even if every sentence sounds unmistakably human.
This distinction matters for teams that want the benefits of agents without creating a culture of suspicion. Review should test understanding and behavior, not guess authorship from punctuation.
Speed for whom?
At Cadesia, the attraction of automation is obvious: a developer should not have to repeat tedious setup to get an app running. The same logic applies to coding agents. Let them search, scaffold, compare, and run the boring loops. But count the time of the teammate who reviews the patch, the operator who debugs it at night, and the future developer who reads its history. A change is not fast if it saves its author twenty minutes and costs everyone downstream an afternoon.
The best agent-assisted work often looks quiet. The PR may be smaller than the agent’s first attempt. The summary may be shorter than the generated one. A test may be added after the developer notices an edge case the agent missed. That is the human contribution: choosing what belongs, checking what is true, and leaving a trail another person can trust.
TAI-DR is a joke with a useful edge. Meat proxy is a harsher name for the person who ignores it. Keep the agent. Keep the speed. But before you ask someone else to read your diff, make sure you have read it yourself—and can explain the line they are about to ask about.