Using AI to write code does not make someone a “meat proxy.” Giving up engineering judgment does. Software development has always relied on delegation. We depend on libraries, frameworks, compilers, databases, documentation, examples, and knowledge created by other engineers. AI expands that delegation into implementation itself. That is a meaningful...
There is a derogatory term starting to appear in discussions about AI-assisted software development: “meat proxy.”
The idea is that a developer receives a task from another human, hands it to an AI coding agent, waits for the AI to produce the implementation, and then forwards the result into the codebase.
The human has become little more than a biological API between management and the model.
There is a legitimate criticism hiding inside that joke.
But I think it identifies the wrong boundary.
Using AI to write code does not make someone a meat proxy.
Giving up engineering judgment does.
The romantic version of programming is that a developer sits down in front of an empty editor, understands the problem, and constructs the solution directly from their own knowledge.
That has rarely been how real software development works.
A more realistic development loop has always looked something like this:
Requirement → research → documentation → existing code → libraries → examples → experiments → implementation → debugging → tests → refactoring
Developers search documentation.
They read source code.
They find similar implementations.
They use libraries implementing algorithms they could not reproduce from memory.
They depend on frameworks containing millions of lines of code they have never read.
They ask coworkers.
They search Stack Overflow.
They run experiments when documentation is unclear.
They use debuggers when their mental model turns out to be wrong.
They change their design when reality disagrees with the original plan.
Eventually something works.
Then they clean it up, test it, document it, and move on.
Software engineering has always been mediated by tools, abstractions, and knowledge created by other people.
Even the code we personally write is converted by compilers, runtimes, operating systems, database engines, and hardware into behavior we do not manually control.
Delegation is not new.
That does not mean AI coding agents are merely a faster version of Stack Overflow.
They represent a meaningful change.
Stack Overflow might have given you a ten-line answer.
A modern coding agent can inspect an unfamiliar repository, trace a feature across several modules, propose an architecture, modify fifteen files, write tests, run those tests, inspect failures, revise the implementation, and produce a summary explaining what it changed.
That is a much larger unit of delegation.
The cost of producing a candidate implementation has collapsed.
And that creates a new problem.
A developer can now produce far more code than they understand.
Previously, implementation itself created friction. Even when copying examples or adapting libraries, the developer usually had to manually connect many of the pieces.
AI can remove much of that friction.
That is enormously useful.
It is also dangerous.
The most concerning workflow is not simply:
Human asks AI to write code.
It is this:
AI proposes the architecture.
AI writes the implementation.
AI writes the tests.
AI runs the tests.
AI interprets the failures.
AI fixes the implementation.
AI explains why the final solution is correct.
The human then approves the pull request because the tests are green and the explanation sounds reasonable.
At that point, there may be no independent source of judgment left in the loop.
The implementation and the evidence supporting the implementation came from the same system.
That is where the “meat proxy” criticism becomes meaningful.
The problem is not that the AI typed the code.
The problem is that the human may no longer have enough of a model of the system to recognize when the AI is wrong.
I think this is the distinction that matters.
Delegating execution is normal engineering.
We already delegate enormous amounts of execution to compilers, databases, frameworks, cloud platforms, CI systems, code generators, and libraries.
AI expands that delegation into implementation.
That is not automatically a problem.
Delegating judgment is different.
Someone still needs to decide:
Does this actually satisfy the requirement?
Did we misunderstand the requirement?
Does this fit the existing architecture?
Is this abstraction necessary?
Did the implementation introduce a new failure mode?
Are the tests checking the behavior we care about?
Did the tests simply encode the same incorrect assumption as the implementation?
What state changes?
What happens when the database is unavailable?
What happens when the request is repeated?
What happens when two operations occur concurrently?
What happens six months from now when another engineer changes this code?
Those are engineering questions.
The person responsible for shipping the system needs to own the answers, regardless of who or what generated the implementation.
There is another trap in this discussion.
Some people respond to AI-assisted development by implying that a “real developer” should be able to explain every line of code they ship from memory.
That standard was unrealistic before AI.
Software changes constantly during development.
The implementation you originally planned may not be the implementation that survived contact with the actual system.
Libraries behave differently than expected.
APIs have undocumented constraints.
Database behavior forces a redesign.
A seemingly clean abstraction turns out to be unnecessary.
Tests expose edge cases.
Code gets rewritten several times.
Months later, even the engineer who manually wrote every character may need to reopen the repository before explaining exactly how it works.
Memory is not ownership.
A better minimum standard is having a reliable mental model.
For a change you own, you should be able to explain:
What behavior changed.
Why the change exists.
Where the behavior starts.
The major steps from input to result.
What state can change.
Which important conditions change the execution path.
At least one important failure mode and what happens when it occurs.
The main constraint or tradeoff that shaped the implementation.
What evidence gives you confidence that it works.
Where to look in the code when deeper detail is needed.
You do not need to recite the implementation.
You need to understand the system well enough to reason about it.
This changes how I think about AI-assisted development.
The question is not:
“How much of this code did you personally type?”
That measures authorship.
It does not necessarily measure engineering.
The more useful questions are:
Could you recognize if this design were wrong?
Could you identify an important missing edge case?
Could you explain why this approach fits the system?
Could you determine whether the tests provide meaningful evidence?
Could you modify the system when the requirement changes?
Could you debug it when production behaves differently than the test environment?
Could you reject the implementation the AI produced?
That last question may be the most important one.
An engineer does not need to author every line.
They need to be able to reject the wrong lines.
Before modern coding agents, implementation consumed a large fraction of software development time.
Now that step can sometimes be compressed from hours into minutes.
That does not eliminate engineering.
It shifts the bottleneck.
Understanding requirements matters more.
Architecture matters more.
Defining constraints matters more.
Review matters more.
Testing assumptions matters more.
Observability matters more.
Security review matters more.
Knowing what evidence to trust matters more.
The ability to generate code is becoming cheap.
The ability to determine whether code should exist, whether it belongs in the system, and whether it actually works remains expensive.
That is why I do not think “AI wrote the code” is a particularly useful criticism.
The more important question is:
Who owns the judgment?
If the human understands the problem, defines the constraints, evaluates the design, challenges the implementation, verifies the behavior, and accepts responsibility for the result, then AI is another layer of engineering leverage.
If the human simply forwards requirements to a model and forwards the model's output to production, then “meat proxy” starts to become an uncomfortable but reasonable description.
AI did not remove the engineering loop.
It compressed the implementation step.
The danger is not delegation.
The danger is delegating both execution and judgment.
Your cart is currently empty.
Start Shopping
