Deciphering Glyph ::<br>Adversarial Communication

Deciphering

Glyph

About

Archives

Mastodon

GitHub

Patrons

Adversarial Communication

“AI” turns every conversation into a fight, because fighting is what<br>they are good at.

aillmprogramming Tuesday June 23, 2026

As I have discussed in previous posts,<br>“AIs” can make mistakes. In fact, they do make mistakes, and their<br>mistake-making patterns are such that where and how they will make mistakes is<br>both uncertain and constantly changing.

Thus, in any scenario where you want to attempt to make “productive” use of<br>“AI”, you must have a system in place for checking every result. Not checking<br>some results; checking every result. If each result might have a<br>consequence for you (and if it didn’t have a consequence, why bother automating<br>it?) and you cannot predict in advance which kinds of results will need<br>verification, then verification is always required.

The verification often ends up being just as expensive as doing the work in the<br>first place, which means that if you want your usage of “AI” to be personally<br>profitable, you have to find someone else to externalize the cost of<br>verification onto. This person becomes your adversary, and, if you are<br>successful, your “AI’s” victim.

The Ladder-Climber And Their Reverse-Centaur Rungs

One way that this constellation of facts can straightforwardly assemble<br>themselves into a dystopian nightmare is the phenomenon, described by Cory<br>Doctorow, of the reverse<br>centaur.<br>This is when your employer non-consensually turns you into the verification<br>system. The “AI” does the fun part of initially performing the work, and then<br>you do the boring part where you check if the robot is right and clean up its<br>messes, even if everyone already knows that it would, in aggregate, be cheaper<br>for you to do the work in the first<br>place.

Reverse centaurs can be made from any automation, not only “AI” automation.<br>I think that there is a reason that this term happens to have emerged in the<br>“age of AI”, though, and not with earlier automation technologies (even those<br>which were<br>considerably<br>more viscerally<br>horrific). That reason<br>is: the wrongness of “AI” output is not merely a technical feature that must<br>be compensated for, it is a generalized externality.

As I mentioned above, if you are responsible for the entirety of the work, both<br>extruding the “AI” output and checking it, it’s usually cheaper to have<br>humans do the entirety of the work to begin with. When humans do the writing<br>directly, we can check as we go, and thus verification doesn’t need to be as<br>comprehensive.

When “AI” coding advocates say “code review is the<br>bottleneck”, what<br>they are observing is that the LLM is still rolling the dice for each PR, and a<br>human is still necessary to verify that each of those rolls is a winner. But<br>calling this process “code review” is a bit of a<br>misnomer; it’s not really “code<br>review” in the traditional sense, it’s human understanding.

Before the advent of “AI”, the human understanding was implicit in the process<br>of writing the code in the first place1, and the code review was a way of<br>diffusing and extending that understanding. Now that the code can be authored<br>with no initial understanding taking place, that cost has not gone away, it has<br>moved.

Human understanding was always the bottleneck.

However, this is taking a collaborative view of a software project, where<br>satisfying the needs and solving the problems of your customers are the goals.<br>We can see that “AI” is a bad tool to satisfy those goals, because all it’s<br>doing is converting the first half of the work, that of understanding the code<br>as you write it, to understanding the agent’s output as you read it.

What if, instead, we were to take the view that every software company is a<br>Hobbesian nightmare, red in tooth and claw? In this view, the only goal of a<br>software project is for the individual developers to make their promo cycles<br>and get their bonuses. Given that there is only a certain amount of money to<br>go around, this is a zero-sum game where each programmer wants to look more<br>productive than their colleagues.

Pretty much every organization finds it easy to reward “productivity” as<br>expressed by lines of code emitted, but the benefits of doing<br>thorough and thoughtful design, analysis, and code review very difficult to<br>reward. In this world, an LLM is an invaluable tool for the sociopathic<br>ladder-climber, particularly if your legacy organization is still structuring<br>their workflows as if the person prompting the bot is “writing” the code, and<br>then they get to foist off the act of “reviewing” the code onto someone else.

Here, the prompter effectively externalizes the cost of the LLM’s failures but<br>internalizes any benefits. The prompter will vibe-code a big feature, so large<br>that the assigned reviewer can’t possibly comprehend it all effectively. When<br>this happens, the reviewer will, eventually, be pressured to approve it, even<br>if they can try to spot a few problems along the...