There's no point at which turning your brain off will work

The meat proxy problem

Since early 2025, a pattern has become familiar: hand a task to an LLM — summarizing text, writing some code — and assume it worked. That assumption rarely held up then, and the results were often absurd. As models have improved, the behavior has spread rather than faded. Some people now let an LLM write code and simply trust the output; others stay nominally in the loop, feeding failures back to the model to diagnose and fix. Niklas Gruhn calls variants of this being a "meat proxy."

The for-loop version works better than it did in early 2025, and software built this way sometimes sort of functions — not to a standard worth using, but impressively so as of September 2026. One can imagine models improving to the point where brain-off, meat-proxy development yields average-quality software, or where they produce great software with no human in the loop at all.

Suppose that happens. What reason would a company have to keep the meat proxy? It could run the LLM in a loop and lay the employee off. There is no point at which this methodology works for the employee.

Where the loop breaks down

Luke Burton argues that walking away from an LLM's output says more about the work than people think. He only does it for low-value tasks that can afford to fail. On high-value tasks the odds of a one-shot success are much lower, and he ends up acting as QA, engineering manager, and architect; the while loop feels like crunch time, with the constant suspicion that a vague prompt produced an architectural choice that will have to be undone. Higher throughput also raises his own shipping bar: agents polish and explore edge cases beyond his usual norm, but never without prompting.

His questions for meat proxies whose agents supposedly nail everything: is it possible you were already coasting, and why aren't you pushing agents past tasks they handle easily? He notes that converting a codebase to build with Bazel looks like ideal hands-off work. It has taken months even with agents, because the task hides intangible, hard-to-specify requirements that require constant supervision. "Convert this to Bazel" and walk away is months away at minimum — possibly years, possibly never — given the number of decision points and unknown unknowns. The same applies when you find code whose purpose isn't clear but whose answer changes your course of action, or when a stakeholder reveals that a component you assumed had to be preserved isn't used anymore: what decisions were made around that false assumption?

The decision-making need becomes most obvious when an agent hits something out of distribution. In one minor case, agents handled obscure programming languages far worse than mainstream ones despite training exposure. Board games are a sharper example: on a modern game like Lost Cities or Dominion, a state-of-the-art model and harness performs worse than a reasonable human who has never played. Ask the agent about the game and it produces statements that sound plausible to a non-player but are obviously wrong to anyone who knows it. A new Dominion player who used ChatGPT to learn the game was, in practice, made worse — ChatGPT's guidance was about half right, and the wrong half steered them somewhere worse than general game-playing heuristics would. A never-before player who spent five hours reading about the game — or maybe thirty minutes with references during play — could plausibly reach the 99th percentile. Un-fun and not recommended, but it shows the gap between a human and an agent on out-of-distribution problems today. The next big model release could flip this, but the gap remains large. Even in coding, you regularly hit such questions, and producing a good overall result today means noticing and handling them.

Failure modes and false confidence

When assumptions replace verification, the failure modes are concrete: agents that heavily overfit to tests, or to a metric. Whether agents cheat more on eval-shaped problems is unclear, but even granting it, people who don't build eval-shaped tasks have hit the same problem — sometimes more severely — by writing instructions and letting agents run unsupervised. Where supervision has worked with minimal oversight, it came from fencing agents in tightly, which itself makes the work more eval-shaped.

Software from people who outsourced thinking to an LLM tends to have serious issues. A programming thought leader declared on Twitter that programming is solved, citing projects across many fields that Claude solved as well as an expert. Checking their GitHub, every example examined (a non-zero number) either didn't work or worked badly. Their board game AI was an AlphaZero-style bot weaker than an LLM-prompted simple minimax heuristic bot tweaked in a loop — a result that, for that game, should be demolished by a mediocre AlphaZero-style bot. In another case, the standard flow of a real commercial product led into an infinite loop that most programmers could escape but a typical user of non-programmer-facing software probably could not, locking them out of the main functionality.

Self-made "works for me" software is a different category. A regex engine built by an agent to speed up ripgrep searches and a Rust interpreter built to shorten an agent iteration loop both fail as products, and an agent loop producing incorrect data analysis that gets corrected later is valuable. But there's a difference between software known to break when held wrong, or incorrect work you fix up, and declaring programming solved after writing broken software, or shipping that quality commercially. Thomas Dullien's reaction to a draft of these thoughts: whenever he says LLMs don't solve all programming problems, people look at him like he's crazy, and he looks at them like they are. Gary Bernhardt observed how surreal it is to contrast actual agent output with the claims made about it: everyday changes often see his reviews cut diffs to 25% of their original size, full of useless tests, paranoia, and inverted logic. One example: told to fix DATABASE_URL management, the agent added ifs directly inside NPM scripts and a conditional node invocation in CI running an inline JS script — about 20 hunks. After correction: +0 lines, +1 word.

Two more examples of cheap confidence. A reader sent a ChatGPT fact check with a condescending note about errors in a post that had already been fact checked by ChatGPT; the real errors were fixed, leaving only ChatGPT's. For this kind of task the false positive rate (precision) is poor and the false negative rate (recall) is mediocre, but running the checks is still worth it, since sifting a list of false positives is cheaper than asking another human to read a draft. Separately, tpatcek's point stands: don't let an LLM flatter you into thinking a piece of work was good — writing in particular, but other work too. That an LLM calls your work genius or demolishes your interlocutor's reasoning isn't meaningful yet at current accuracy levels, and using such puffery as justification is mostly a sign that you turned your brain off, and a fairly strong signal that the work or reasoning is poor.

Why turning off doesn't pay

The behavior may work for founders and large shareholders, but the observed cases have been employees or personal-project builders making claims about software being solved — claims that imply something about employed engineers. The argument "we'll all be obsolete, so why not give up?" runs backwards unless obsolescence is guaranteed to be very near. If you're financially ready to retire, you can turn your brain off, but that was always true and people have always mailed it in. If you're not ready to retire, doing something that makes more money is the better move, and that almost certainly doesn't mean turning your brain off. If obsolescence is coming soon and you need money, now is the time to rush, not coast. The line of thinking that effort doesn't pay because pay doesn't change is wrong: raises and bonuses have come from finding and fixing problems, for him and for friends, unless the workplace was so dysfunctional that it didn't reward good work — in which case people leave.

The inertia argument — that there will be a window where you can get away with being a meat proxy after LLMs are good enough to replace programmers — also looks backwards given how eager companies are to lay people off. If doing as little as possible is the goal, the best time was the past. Stories from big companies tell of people who literally stopped showing up, and who took months or years to fire: one teammate took six months to fire after deciding to retire and collect a few more paychecks by not appearing at a pre-pandemic, non-remote company; at a friend's company, another took two years. Nobody started the process for a while, then came slow escalating warnings. A manager noted that if the person had shown up and pretended to work a bit, a new clock would have started and firing would have taken even longer — a competent slacker could have held the job indefinitely under those conditions. Companies are now using AI as an excuse to move away from that state, making now and the near future the worst time in a long while to hold a job while providing no effort and no value. Some companies will still allow it, but anyone who wanted to do nothing and collect a paycheck could have been doing that for a long time in an easier environment.