Meat Proxies, Vibe Coding, and Building Teams That Still Think

TL;DR

• A recent post about “meat proxies” describes people who relay AI output verbatim, without reading, validating, or synthesizing it themselves.
• I’m seeing the same failure mode in engineering work — “vibe coding” tickets closed by asking AI to do whatever was asked, with no one actually understanding the change.
• The fix isn’t banning AI. It’s building a culture where using AI well is a visible skill, not a shortcut around thinking.

The meat proxy problem********

I came across an article about being a “meat proxy” recently, and it stuck with me. The idea is simple: a meat proxy is someone who takes an AI’s answer and passes it along untouched — pasted into a company channel, dropped into a PR comment, forwarded as “feedback” — without doing the work of reading it properly, checking whether it’s actually correct, or putting it in their own words.

The reason that’s a problem isn’t that AI output is bad. It’s that unfiltered AI output is verbose, confidently wrong often enough to matter, and dense with jargon nobody asked for. If someone just relays it, the reader now has to do the filtering the sender skipped — and if that’s the deal, the reader would’ve been faster asking the AI directly themselves. The human in the loop stopped adding value. They became a pipe.

Vibe coding is the same failure mode, wearing a different shirt

Reading that, I couldn’t help but map it onto something I’ve been watching happen around me recently: people shipping code they can’t explain, or sending me pages of AI generated document without actionable output (its garbage literally).

Or worse — I ask for a solution, and instead of thinking about the actual problem, they hand the ask straight to an AI assistant, take whatever comes back, and open a PR. No mental model of what the code does. No opinion on whether it’s the right approach. Just relay.

That’s “vibe coding” as a meat proxy problem. The AI isn’t the one who forgot to think — the person routing the request through it did. And in both cases, the tell is the same: if you can’t explain it in your own words, you haven’t actually done the work, you’ve just laundered it through a tool.

Why this worries me more than it might sound like it should

I lead engineering at a licensed payment platform. We carry the platform and compliance responsibility, and we answer to regulators and customers who expect someone to be able to explain, in detail, why a system behaves the way it does. “The AI suggested it” is not an answer any of them will accept — and it shouldn’t be one we accept internally either.

A team that gets used to relaying answers instead of forming them quietly loses its ability to catch the answer that’s subtly wrong. AI is very good at producing plausible-sounding code and plausible-sounding explanations. Plausible is exactly the failure mode you don’t want in a system that moves real money — you want someone who actually understood the trade-off and can defend it.

What I actually try to do about it

I don’t think the answer is to restrict AI usage — that’s fighting the tide, and it throws away real productivity gains. What I try to build instead is a team where using AI well is visibly a skill, and outsourcing your judgment is visibly not:

• “Explain it like you wrote it.” In review, I don’t care whether a person used AI to draft a change. I do care whether they can walk me through why it’s correct, what it trades off, and what breaks if the assumption underneath it is wrong. If they can’t, the PR isn’t ready — not because of the tool, but because no one understands the change yet.
• AI output is a draft, not a deliverable. Treat the first answer — code, explanation, or design doc — as a rough draft that needs to survive contact with your own understanding before it goes anywhere near a teammate, a PR, or a merchant-facing system.
• Rewrite before you relay. If you’re forwarding an AI’s answer to someone else — a teammate, a support ticket, a Slack thread — put it in your own words first. That step is where you find out whether you actually understood it.
• Reward the “why,” not just the “what.” When someone pushes back on a task — “why are we building it this way” — that’s a signal the culture is healthy, not a signal they’re being difficult. I’d rather have an engineer who questions a poorly-scoped ask than one who routes it straight into an AI and ships whatever comes out.
• Ownership doesn’t transfer to the tool. AI is just a tool, it cannot help us carry ownership. Instill a work culture that cultivates critical thinking.

Where this leaves us

None of this is about being anti-AI — I use these tools constantly, and they’ve made my team meaningfully faster. The line I care about is narrower than “use AI or don’t”: did a human actually think about this, or did they just relay it? A team that’s fast because everyone understands what they’re shipping is resilient. A team that’s fast because everyone’s forwarding AI output is fragile — it just hasn’t found the bug that proves it yet.

The goal is a team that treats AI the way a good engineer treats any powerful tool: use it to go faster, but never let it replace the part of the job that was always the actual job — thinking clearly about the problem in front of you.

Disclaimer

This post is partially generated using Claude, but the ideas and gist of contents are 100% from myself. You get the gist :)