Have Your AI Call My AI
AI-to-AI handoffs are quietly creating a telephone game in engineering orgs, where intent degrades and ownership evaporates. Here is how to stop it.
A product manager describes a feature out loud to an AI assistant, which expands it into a tidy PRD. The PRD lands in a ticket. An engineer pastes the ticket into a coding agent, which produces a branch and a pull request. A reviewer opens the diff, asks an AI reviewer for a summary, reads the summary, and clicks approve. The feature ships.
Notice what is missing from that sequence: at no point did a human being hold the whole thing in their head. Each person touched a handoff, not the substance. The PM never wrote the spec. The engineer never wrote the code. The reviewer never read the code, only a generated description of it. Three humans participated, and yet the artifact passed through the organization like a hot potato — handled by everyone, understood by no one.
This is the dysfunction worth naming. It is not that AI writes bad code, or that AI writes good code. It is that AI makes it frictionless to pass intent along without absorbing it. When that happens at every boundary in an org, you get a game of telephone played by machines, with humans standing in as relay points who no longer listen to the message. Call it what it is: have your AI call my AI.
The telephone game has a real research pedigree
The “telephone” or “Chinese whispers” analogy is not just a party metaphor. It maps onto a documented phenomenon in psychology called serial reproduction, studied rigorously by Frederic Bartlett in the 1930s. Bartlett had people retell a story down a chain, and found that the message did not just lose detail — it got actively reshaped. Each teller reconstructed the story to fit their own expectations and schemas, so the narrative grew shorter, more coherent, and more conventional with every retelling, drifting steadily away from the original. The distortion was not random noise. It was systematic regression toward what each participant found familiar.
That is the key insight for engineering orgs. A handoff is not a lossless pipe. Every time intent crosses a boundary, the receiver reconstructs it according to their own priors. When the receiver is a language model, the priors are the statistical center of its training distribution — the most generic, most expected version of whatever it was handed. Ask an AI to turn a one-line desire into a PRD and it will confidently fill the gaps with plausible-sounding defaults. Ask the next AI to turn that PRD into code and it will fill its gaps the same way. The specifics that mattered — the edge case the PM was actually worried about, the constraint that made the whole feature necessary — get smoothed into the generic on each pass, because nobody re-injected them.
Why machine-to-machine handoffs compound instead of cancel
You might hope the errors would wash out. They do the opposite. They compound. The cleanest formal demonstration of this comes from AI research itself.
In 2024, Ilia Shumailov and colleagues published AI models collapse when trained on recursively generated data in Nature. They showed that when a generative model is trained on the output of a previous generation of models — synthetic data feeding synthetic data — quality degrades irreversibly. The mechanism they describe is precise: the tails of the original distribution disappear. The model forgets the rare, the unusual, the specific, and converges toward a blander and blander center. They called it model collapse, and it gets worse with each recursive generation.
The parallel to AI-to-AI artifact pipelines is hard to ignore. Each generated PRD, ticket, and diff is itself a kind of synthetic data, and the next agent in the chain trains its momentary “understanding” on the last agent’s output rather than on ground truth. The rare and specific — exactly the things that made the work worth doing — are the first to vanish. You are not building a feature. You are running a recursive generation loop and shipping whatever falls out of generation N.
There is an important caveat worth stating plainly, because the model-collapse result has sometimes been overstated. The collapse in the Shumailov experiments is most severe when models are trained indiscriminately on their own output with no fresh real-world data mixed back in. Subsequent work has argued that if real human data is preserved and accumulated alongside the synthetic, the worst-case collapse can be avoided. That caveat is not a reprieve for the telephone game — it is the whole prescription. The thing that prevents collapse in the research is the continued presence of ground truth. The thing that prevents the telephone game in your org is the continued presence of a human who knows the ground truth and re-injects it at each step. Remove that human and you are back in the indiscriminate-recursion regime the paper warns about.
The empirical record on code quality is already pointing the same direction. GitClear’s analysis of 211 million changed lines of code found that the share of lines classified as copy/pasted rose while refactoring fell sharply across the period AI assistants became mainstream — refactoring dropped from 25% of changed lines in 2021 to under 10% in 2024, while duplicated blocks rose several-fold. Duplication is what you get when nobody holds the whole system in their head and instead asks for a fresh local solution every time. It is the codebase-level signature of telephone.
Conway’s Law, run through a language model
There is an older law that explains why this metastasizes through an org rather than staying contained. In 1968, Melvin Conway published a paper titled How Do Committees Invent?, arguing that any organization designing a system “will produce a design whose structure is a copy of the organization’s communication structure.” Fred Brooks later popularized it as Conway’s Law in The Mythical Man-Month.
Conway’s point was that your architecture mirrors your communication. If two teams barely talk, the interface between their modules will be thin and brittle, because the design can only be as good as the conversation that produced it. Now insert AI at every communication boundary. The PM’s AI talks to the engineer’s AI talks to the reviewer’s AI. The communication structure of your org is increasingly machine-mediated handoffs between humans who are no longer the ones communicating. By Conway’s logic, the systems you ship will faithfully mirror that: loosely coupled, generically specified, internally inconsistent, full of seams where one agent’s assumptions never met another’s.
The org chart used to be a communication map. Increasingly it is a routing diagram for prompts. And the architecture will reflect that, whether you intend it to or not.
There is a darker corollary. Conway’s original argument was that interfaces between modules reflect the conversations between the people who designed them — and that modules whose designers never really talked produce brittle, mismatched seams. When the “designers” on both sides of a seam are language models prompted in isolation, there is no conversation at all, only two independent reconstructions of an intent that was never shared. Each agent invents a reasonable contract for its side. Neither one knows the other exists. The seam that results is not just thin; it is a coincidence. It works until the day two assumptions that were never reconciled finally meet in production. This is why “the code compiles and the tests the AI wrote pass” is such a treacherous green light: it tells you each relay node was internally consistent, and nothing whatsoever about whether the chain as a whole means anything.
See how developers track their AI coding
Explore LobsterOneThe accountability evaporates, and that is the actual danger
Bad architecture you can refactor. The harder problem is that nobody owns it.
Philosophers of technology have a name for this: the problem of many hands. The phrase traces to Dennis Thompson’s work on public officials and was extended to computing by Helen Nissenbaum in the 1990s. The structure of the problem is that when a mishap is the work of many hands, it is not obvious who is to blame, because the most immediate causes of the failure do not converge on any single locus of decision-making. And recent work makes the parallel to our situation explicit: machine learning, the same source notes, presents a recursive turn in the many-hands problem, because modern systems are built from pre-trained components that are themselves the product of many hands. Responsibility does not just diffuse across people; it diffuses across layers of machinery whose own provenance has already been blurred.
AI-to-AI handoffs are an accountability-gap machine. Ask, after an incident, “who decided this should work this way?” and trace the chain backward. The reviewer approved a summary, not the code. The engineer prompted an agent and accepted its output. The PM described an idea and approved a document an AI wrote. Each person can honestly say they did not author the thing that broke. Each one was, genuinely, just a relay. The decision was made by no one and by everyone, which is the same as saying it was made by nobody who can answer for it.
This is not hypothetical drift. Developers themselves sense it. In the 2025 Stack Overflow Developer Survey, more developers actively distrust the accuracy of AI output (about 46%) than trust it (about 33%). And the single most-cited frustration, named by 66% of respondents, was “AI solutions that are almost right, but not quite” — the precise failure mode of a relay that looks plausible enough to forward without checking. People half-know the message is degrading. They forward it anyway, because forwarding is the path of least resistance and the next AI will surely sort it out. It will not. It will forward too.
The seductive part: it feels fast
The reason this pattern spreads is that every individual handoff feels like a productivity win. The PM saved an hour not writing the PRD. The engineer saved a day not writing the boilerplate. The reviewer saved twenty minutes reading a summary instead of the diff. Locally, everyone is faster. Globally, the org may be slower and more fragile, because all the saved time is being borrowed against a debt that comes due later — in the incident, in the rework, in the feature that does almost-but-not-quite what anyone wanted.
The METR randomized controlled trial from 2025 is the cautionary data point here. Experienced open-source developers using early-2025 AI tools took 19% longer to complete tasks, even though they predicted and believed they were going faster. A meaningful chunk of the slowdown came from time spent cleaning up AI-generated code. The perception of speed and the reality of speed had cleanly diverged. That gap — feeling fast while being slow — is exactly what lets a telephone-game culture install itself unchallenged. Nobody is lying when they say AI made them faster. They just cannot see the system-level cost from where they stand. If you want to actually see it, you have to measure the outcomes that matter rather than the activity that feels productive.
How to break the chain: human checkpoints that re-inject understanding
The fix is not to ban AI from the pipeline. AI is genuinely useful at every one of those steps. The fix is to insist that intent and ownership get re-injected by a human at each boundary, rather than passed through untouched. A few concrete principles:
Make someone own the message at every handoff, not the artifact
The failure is not that an AI wrote the PRD. The failure is that no human committed to the PRD as theirs. The rule is simple and old-fashioned: whoever forwards something owns it as if they wrote it by hand. If you paste an AI-generated ticket to an engineer, you are vouching for it. If you approve a PR, you are vouching for the code — not the summary of the code. This is just the discipline that good reviewers already practice. A “LGTM” that follows real scrutiny is fine; a “LGTM” that replaces it is what one industry writer aptly called “compliance cosplay” — performing the ritual without the substance. Our own take on this lives in code review practices for AI-generated code.
Read the thing, not the summary of the thing
An AI summary of a diff is a second-order artifact: a model’s reconstruction of a model’s output. Approving based on the summary is two generations of telephone deep before a human even looks. Summaries are great for orientation and useless as a basis for accountability. The human checkpoint has to touch the primary artifact — the actual code, the actual data, the actual behavior — or it is not a checkpoint, it is another relay node.
Keep an audit trail of who understood what, when
When something breaks, you want to reconstruct the chain of intent, not just the chain of commits. Which human signed off on which assumption? Where did the constraint get dropped? A durable record of decisions and ownership at each AI-assisted boundary is what turns an accountability gap back into accountability. We have written about building that kind of audit trail for AI-assisted work, and it matters more, not less, as the number of AI hands in the pipeline grows.
Watch for the doom-loop signature
The recursive-generation failure has a tell: the same problem getting handed to AI again and again, each pass producing a slightly different but never-quite-right result, with no human ever stepping out of the loop to reframe the problem. That is model collapse wearing a hoodie. Recognizing it early — and forcing a human to break the loop with actual understanding — is the difference between a productive session and a coding doom loop that burns a day and ships nothing trustworthy.
What this is really about
Underneath all of it is a single shift in what a handoff means. For decades, passing work to a colleague carried an implicit guarantee: a human had thought about it. The thinking was the value; the document was just the container. AI lets us produce the container without the thinking, and produce it so fluently that the absence is invisible. The PRD looks like a PRD. The PR looks like a PR. The review looks like a review. Everything has the shape of understanding and none of the mass.
LobsterOne exists because we believe the way out is visibility — being able to see where AI is genuinely amplifying a team and where it has quietly turned into a relay race nobody is winning. That is a measurement problem before it is a policy problem. You cannot govern, reward, or fix a dynamic you cannot see, and “have your AI call my AI” is specifically a dynamic that hides inside individually reasonable-looking actions. It is model-agnostic, too: this happens regardless of which assistants your teams use, because the dysfunction is in the handoffs, not the models.
The Takeaway
AI is not the problem. The problem is using AI to skip the part of work where a human absorbs intent and takes ownership of it. When every boundary in an org becomes an AI-to-AI handoff, you get serial reproduction — Bartlett’s telephone game — running at machine speed, with the specific and the important degrading on every pass, exactly as model collapse predicts for recursive generation. Conway’s Law guarantees the result shows up in your architecture, and the problem of many hands guarantees nobody can be held to account for it.
The antidote is not slower, and it is not anti-AI. It is the deliberate placement of human checkpoints that re-inject understanding and ownership at each boundary — read the code, own the message, keep the trail, break the loop. Let the AIs do the typing. Do not let them do the knowing. The moment your org stops being a chain of people who understand the work and becomes a chain of relays forwarding plausible-looking artifacts, you have stopped building software and started playing telephone. The codebase keeps the score, and it does not grade on a curve.
Pierre Sauvignon
Founder
Founder of LobsterOne. Building tools that make AI-assisted development visible, measurable, and fun.
Related Articles

AI Code Provenance: The Five Questions an Auditor Will Ask
A practical git-trailer spec and retention table for proving AI code provenance during an audit or post-incident review. What to capture, what to keep, and how long.

Code Review Best Practices for AI-Generated Code
How code review changes when the author is an AI — what to look for, common failure patterns, and a review checklist for AI-assisted development.

How to Prevent AI Coding Doom Loops in Production Codebases
What doom loops are, how to detect them in your codebase, and the metrics-driven approach to breaking the cycle before it compounds.