Vineet Arya

The Review Metrics Most Teams Don't Track

hello@vineet-arya.com (Vineet Arya) — Sat, 03 Oct 2026 00:00:00 GMT

Most engineering teams can tell you their velocity. Almost none can tell you their review quality. That gap used to be survivable. Once AI started writing a meaningful share of the code going into every PR, it stopped being survivable — and most teams don’t yet have a way to even see the problem, let alone measure it.

This is a field guide for the leader who already feels this gap and needs a concrete place to start.

The pattern nobody wants to say out loud: bigger MRs get less review, not more

I haven’t instrumented this formally yet, but the pattern is consistent enough to act on: the bigger the merge request, the less real review it tends to get. Not because reviewers are lazy — because a 45-file diff is cognitively expensive to hold in your head, deadline pressure doesn’t pause for its size, and “approve” is one click regardless of whether you read line 40 of file 38.

Here’s the rough shape of review time I’ve observed, by diff size:

1-5 files changed: 10-20 minutes
6-12 files changed: 30-45 minutes
12+ files changed: often an hour or more
40+ files changed: realistically 3-4 hours, if it gets the review it actually needs

Not instrumented — based on felt experience, not a formal benchmark.

That last number is the uncomfortable one. Almost nobody budgets 3-4 hours for a single review. So large AI-assisted MRs — exactly the ones most likely to contain something a smaller, hand-written change never would have — are often the ones getting the fastest, thinnest pass.

One practical mitigation worth trying: use AI to help review large AI-generated MRs. Ask it to draw a flow diagram of what the diff actually does, or to list edge cases the change should handle. This genuinely helps compress review time on big diffs. But it’s not free — querying AI for this kind of review assistance eats into the same token budgets and rate limits your team is already managing, which creates a real, underappreciated tension: the tool that helps you review faster is itself a constrained resource.

The actual metric: review-time-to-author-time ratio

(Worth being precise on naming — “build time” collides with CI/CD pipeline terminology. This is about authoring time: how long it took to write the change, not how long it takes to compile.)

Track this by MR size band, not as one blended number. If the ratio is shrinking — review time staying flat or dropping while MRs get bigger and more complex — that’s the concrete, measurable version of “our review capacity hasn’t kept pace with what AI lets us produce.” It’s a lagging indicator you can act on before it becomes an incident.

Three real bugs that made it through review — and what each one actually teaches

1. The environment-parity gap

An engineer on my team moved a heavy page’s data into a static JSON file generated at build time, specifically to cut page load time. Smart optimization. It worked perfectly in local development. It broke in production — because the static file needed to be added to a production-side access control allow-list, and that step never happened. Nobody caught it in review, because the review looked at the code, not at “what’s different between where this was tested and where it’ll actually run.”

The review question this adds: for any change touching build output, caching, or access configuration — what’s different between the environment this was verified in and the environment it’s shipping to?

2. The duplication that only showed up at 50+ files

Our team had an explicit rule: reuse an existing component if one already exists, don’t create a new one. While building a new site, AI generated multiple near-identical copies of a reusable component — a CTA button, used with the same functionality and theme but slightly different variants on different page sections — instead of parameterizing one shared version. It wasn’t caught at review time, because the MR touched 50+ files and the team was under real launch pressure. It became a real problem months later, when a new requirement meant updating that CTA’s label and behavior — and we had to find and fix it in every duplicated copy instead of one place.

The review question this adds: on any large AI-assisted diff, explicitly ask — did this create new components that duplicate something that already exists, or should exist as one shared thing?

3. The trailing whitespace that broke a lab integration

This one happened to a senior engineer, which is exactly why it’s worth including — this isn’t a juniority problem. We were integrating a third-party learning platform’s lab environments into an educational product, with lab URLs entered by content creators through a CMS. Weeks after launch, we started seeing failures. Root cause: a content creator had left a single trailing space at the end of a URL field. When the URL was read and authenticated against, the extra whitespace broke it. It passed code review. It passed QA. Nobody — not the developer, not the reviewer, not QA — had thought to ask what happens with malformed input on a human-entered field.

The review question this adds: for any field populated by a human (not just API input), what happens with leading/trailing whitespace, empty values, or slightly malformed input? This is a negative-case question, and negative cases are exactly what both AI-generated code and fast reviews tend to skip.

The one that isn’t a bug: when a “codegen ticket” is actually a judgment ticket

This is the subtlest lesson, and I think it matters more than the three bugs above.

We had a ticket that looked, on the surface, exactly like something to hand to an AI agent: wire up catalog cards to link through to their product pages, generate the routes, map the slugs. A launch date was real, so we let the agent take the bulk of it.

What the ticket actually was: two separate content records representing the same underlying program — one used by the catalog card, a different one used by the product page — connected only by a naming convention, not a real reference between them. That’s not a routing problem. That’s a judgment call about data modeling that happened to be disguised as a routing problem.

Before you hand it to AI, ask which one this is.

We didn’t put a junior engineer on it. If we had, they’d have been the person who hit the first slug mismatch, who understood why a specific validation safeguard existed in our codebase, and who could tell a content-ops person “these two records aren’t actually the same entry, even though they look like they should be.”

Instead, the gap surfaced weeks later, on a different team, who needed a knowledge-transfer document to understand the system. The first line of that document had to be “read this if you take away nothing else.” That sentence is the missing ramp. The code shipped. The owner didn’t.

The practical test before handing a ticket to AI: is this actually a codegen task, or is it a judgment task wearing a codegen task’s clothes? If reconciling two systems, two data models, or two teams’ assumptions is part of the real work, that’s exactly the kind of rep a junior engineer should still be getting — not because AI can’t do the typing, but because nobody develops the judgment to catch the next version of this problem without having done it once, by hand, under supervision.

Accountability, as it honestly stands today

Right now, on my team, the default accountability model is simple: the engineer is responsible for development, review, and QA of anything they ship, AI-assisted or not. If it breaks, that’s on the engineer — the expectation was always that AI-generated code gets reviewed and regression-tested like any other code.

I want to be honest that this is a starting point, not a finished governance model. It doesn’t yet answer the harder question underneath it: what happens when you use AI to review AI-generated code.

Two real problems sit inside that, not one. The practical one: querying AI to help review large diffs (flow diagrams, edge-case prompts) draws on the same token budgets and rate limits your team is already managing — a genuinely expensive habit to build at scale, not a free upgrade. The deeper one: an LLM reviewing another LLM’s output is notoriously better at catching localized syntax issues than organizational context or architectural drift. If neither the model that wrote the code nor the model reviewing it has the context to question a flawed underlying assumption, you can get two confident passes and still miss the thing that actually mattered. The tool that helps you approve code faster can quietly become a co-signer on a bad decision.

Both of these are real and, as far as I can tell, not well-solved anywhere yet.

If you only take three things from this

Track review-time-to-author-time ratio by MR size band, not as one number. Watch for it shrinking as diffs grow.
Ask two questions on every review, regardless of size: what’s different between where this was tested and where it’ll run, and what happens on malformed or negative input?
Before a ticket goes to AI, ask whether it’s actually a judgment task wearing a codegen task’s clothes — not every routing or data-mapping ticket is one, but when reconciling systems, data models, or assumptions is the real work, that’s a rep worth protecting, not just work worth automating.

A note on who this is for

This is written for the engineering manager or lead who’s in the work daily and feels this gap already. If you’re a Director or VP a layer removed from day-to-day review, your real need is different — a dashboard view across sprint velocity, burndown, bug-fix-vs-reported rate, SLA breaches, bug categories (security, compliance, data integrity), and repeat-bug rate. That’s a genuinely different piece, and one worth writing once I have the same kind of real, specific material behind it that made this one worth publishing.

None of the incidents above are hypothetical. Details have been genericized to protect confidentiality, but the failure modes, the review gaps, and the lessons are real.

Your Emails Are Becoming Assembly Language

hello@vineet-arya.com (Vineet Arya) — Tue, 22 Sep 2026 00:00:00 GMT

Someone writes an email with AI. The recipient’s inbox summarizes it with AI.

Someone writes a newsletter with AI. The reader skims an AI summary of it.

Someone writes code with AI. The reviewer reviews and understands it with AI.

Someone writes a resume with AI. The recruiter screens it with AI.

So, who actually read it?

Nobody did. And once you notice this loop, you can’t stop seeing it everywhere.

The pattern

Here is the exact shape of modern knowledge work:

A person starts with an intent. AI expands that intent into a polished, wordy artifact — an email, a strategy doc, a slide deck, a resume. They hit send. On the other side, the receiver’s AI compresses that artifact back into a neat summary. The receiver reads the summary and makes a decision.

The humans at each end touch the process for a fleeting moment. The machines own everything in the messy, high-frequency middle.

And it isn’t confined to one corner of work. It’s happening at every layer, at every cadence:

Resumes: Written with AI, screened and summarized by AI. Once a year.
Docs and decks: AI-drafted, then AI-summarized by whoever is too busy to read them. Every week.
Email: Three bullet points go in, “make it professional” gets typed, four polished paragraphs come out. Then the recipient’s assistant boils those four paragraphs back down to three bullet points. Every hour.

The artifact in the middle — the thing someone spent real time formatting, tuning, and pretending to write — was never actually read by a human. It was just a transport format between two machines.

It reminds me of something

If you’ve written code for long enough, this will feel deeply familiar.

We used to write closer to the machine. Then compilers arrived, and we stopped. Now we write our intent in a high-level language, a compiler translates it into machine code that almost nobody reads, and we interact with human-friendly inputs and outputs at the edges. The machine code in the middle is real, essential, and — to most of us — invisible.

The email, the doc, the resume are heading the same way.

Human intent vs. machine artifact — writing communication that reads like x86 assembly.

They’re becoming a kind of assembly language for human intent: generated by a machine, parsed by a machine, and skimmed by no one. The polished paragraphs aren’t the message anymore. They’re the compiled artifact sitting between two systems that speak “fluent prose” the way compilers speak x86.

There’s even a satisfying, almost comedic absurdity to it. I compress my meaning into three bullet points, hand them to a model that inflates them into four paragraphs, and ship it. Your model deflates those four paragraphs back into three bullet points, which you read.

We are literally spending computing power and tokens on both sides — expansion and compression — to arrive at almost exactly where we started. The prose was pure overhead. Carbon-emitting ceremony with a word count.

Where the analogy breaks — and why that’s the real story

Here’s the part that should make an engineer deeply uneasy.

A compiler is deterministic and lossless. The same source code compiles to the same binary every time. The translation preserves meaning exactly; that guarantee is the entire point. You can trust the layer you never look at, because it was built to be trustworthy.

The Human → AI → AI → Human pipeline offers no such guarantee.

Every hop is a probabilistic, lossy translation.

My intent becomes an AI-written artifact — and something shifts, because the model fills every gap I left with its most plausible guess.
That artifact becomes an AI-written summary — and something shifts again, because summarization is compression, and compression inherently discards nuance.

The Silent Drift — individually reasonable translations resulting in a collectively distorted outcome.

By the time it reaches the other human’s understanding, the meaning has passed through multiple black-box transformations, none of which promised to preserve it.

It’s less a compiler and more a high-tech game of telephone. Each translation is individually reasonable and collectively distorting. And the distortion is quiet — the output at every stage looks clean, confident, and correct. Nothing errors out. Nothing flags a syntax warning.

A compiler that mangled your code would fail loudly at build time. This pipeline mangles your meaning and hands you back something that reads beautifully.

Worst of all: nobody is checking the middle layer, because nobody is reading the middle layer. The layer we’ve stopped inspecting is precisely the layer where meaning drifts.

So where did the humans go?

Not into the center. We got pushed out to the absolute edges.

Intent at one end. Decision at the other. The craft that used to live in between — the writing and the reading, the actual construction and comprehension of the thing — is being automated away. We’re becoming the endpoints of a pipeline whose interior we no longer see.

That’s not automatically bad. Compilers pushing us up the abstraction ladder was one of the best things that ever happened to software. Nobody sane wants to hand-write assembly for a web app. Abstraction is how we build bigger, more complex systems.

But compilers earned that trust with mathematical determinism. We handed them the middle because they proved they’d preserve our meaning perfectly, every time. We’re now handing an entire category of human communication to a middle layer that has made no such promise — and we’re doing it not because we verified it’s safe, but because it’s convenient and the output looks good.

The part worth keeping

If the writing and the reading are both getting automated, then the scarce, human, valuable thing is no longer producing the artifact or consuming it. Producing prose is nearly free now. Skimming a summary is nearly free too.

What’s left — what skyrocketed in value, not less — is judgment about what actually matters, and verification that the meaning survived the trip.

Which means the uncomfortable question isn’t “should I use AI to write this?”

It’s: “does anyone in this loop still know what the original point was — and would they notice if it quietly changed?”

If two AIs are the real author and the real audience, and the humans only touch the endpoints, then the human’s remaining job is not to write well or read fast. It’s to be the one person in the loop who checks whether the middle still means what the beginning meant.

That was always the actual work. We just used to do it by reading.

Where are you seeing 🧑 Human → 🤖 AI → 🤖 AI → 🧑 Human show up in your own workflows? Drop a line in the comments — are you still in the loop, or just standing next to it?

Who Captures the Value of AI?

hello@vineet-arya.com (Vineet Arya) — Mon, 14 Sep 2026 00:00:00 GMT

In May 2026, while foreign capital pulled roughly $30 billion out of Indian equities and the Nifty IT index slid toward its worst year since 2008, India’s largest actively managed equity fund did something that looked completely reckless on the surface.

It doubled down on IT.

Parag Parikh Flexi Cap Fund — managing ₹1.4 lakh crore in assets — quietly raised its IT allocation from under 7% to over 9% in a single quarter, buying aggressively into a sector the broader market was fleeing.

To the casual observer, it looked like a standard “buy the dip” contrarian play. But look closer at the portfolio’s architecture, and a deeper strategy emerges. The fund’s two largest holdings are Amazon and Alphabet — 16% of the entire portfolio. These are the hyperscalers building the core infrastructure layer of the AI economy: AWS and Google Cloud.

By adding Indian IT services to the mix, the fund wasn’t changing its mind about AI. It was making a second, distinct wager on a completely different layer of the exact same story.

One bet is on the infrastructure giants. The new bet is on the adapters — the companies that will absorb AI as a tool to expand margins rather than get disrupted by it.

As engineering leaders, this exact portfolio split exposes the mechanism that actually decides how budgets get allocated, how systems get architected, and which engineers keep their seat — not on some fixed timeline, but as this plays out in real time, starting now.

Two bets, two layers

Here’s the fear that drove the sell-off in the first place: that AI would let companies build software in-house, gut the outsourcing model, and shrink the work Indian IT firms get paid to do. PPFAS’s bet is the opposite of that fear. The thesis, as best I can characterize it: software still has to get built and maintained, AI or not. The firms good at delivering that work will use AI themselves — to cut costs, move faster, and improve margins — rather than be replaced by it.

The distinction between the two positions matters more than the fact that both exist. Amazon and Alphabet are diversified giants — AI is one growth driver among several, alongside e-commerce, search, and advertising. Holding them is broad exposure, not a single-thesis wager on “AI wins.” The new IT position is the opposite: a concentrated, specific bet on one outcome, in a sector the market had already declared dead.

Two different bets, one portfolio — infrastructure exposure vs. a concentrated adapter thesis.

That second bet is where this story connects to something much larger.

The same mechanism, at the scale of an entire economy

Wharton economists Brett Hemenway Falk and Gerry Tsoukalas published a paper this year modeling exactly the dynamic PPFAS’s IT bet depends on: companies using AI to cut costs and improve margins.

Their finding is uncomfortable. Workers aren’t just an expense line — they’re also the customers who buy what the economy produces. When one company automates aggressively, it captures the full cost savings but bears only a fraction of the resulting hit to consumer demand, because that hit gets spread across the whole economy, not just its own former employees. Every individual company benefits from moving first. If every company does it at once, the underlying demand that made the whole enterprise profitable starts to erode.

This is precisely the mechanism PPFAS is betting on working out well — for the specific companies it holds. The fund isn’t wrong to bet on it; the Wharton paper’s own conclusion is that this behavior is individually rational, not that it’s doomed. But it’s worth naming plainly: a fund manager profiting from Indian IT firms cutting costs via AI, and a Wharton paper warning that widespread cost-cutting via AI could destabilize demand at scale, are describing the same underlying behavior from two different vantage points — one as an opportunity, one as a risk.

Zoom into any one of those firms, though, and a third question appears, one neither the fund manager nor the economists are positioned to answer.

Who actually keeps their seat

If an IT services firm succeeds by using AI to cut costs and headcount, which engineers survive that transition, and which become the number that got cut?

Andrew Ng’s recent writing on “AI Engineering” gives the clearest answer I’ve read. His argument: the old split — a product manager specifies, a developer implements — is dissolving. The developers who thrive aren’t the ones who type code fastest. They’re the ones who can shape what gets built in the first place: driving the build loop, making product decisions the spec doesn’t cover, communicating across functions, and taking high-agency ownership of outcomes rather than waiting for precise instructions.

That’s a genuinely useful framework. It’s also, I’d guess, good marketing for a company that sells AI engineering courses — worth being aware of, without dismissing the substance, which holds up on its own merits regardless of who’s saying it.

Here’s what “high-agency ownership” actually looked like for me, concretely, not as an abstraction. I once noticed a database reader instance sitting almost completely idle — every read and write was hitting the writer instance instead. I proposed two things: actively distribute read traffic to the idle instance, and separately, right-size the instance itself, since it was clearly oversized for how little it was doing. The team declined the first idea — a legitimate reliability call, keeping the reader as a pure failover rather than live traffic. They adopted the second. Real result: a 75% cost reduction, shipped.

Neither idea came from waiting for someone else to specify the work. Both came from actually looking at the system and asking what it needed, independent of what I’d been asked to build that sprint. That’s the skill Ng is describing — and it’s exactly the skill that determines who becomes a cost an AI-native strategy cuts, and who becomes part of the margin improvement the strategy is chasing.

The same question, at three altitudes

Line these three up and the pattern repeats with almost uncomfortable precision:

The economy: AI lets a company cut costs. It captures the savings; the demand hit gets spread across everyone else.
The portfolio: A fund bets real money that specific companies will execute that exact move well, and profit from being early.
The career: Inside those very companies, the engineers who shape decisions rather than just implement them are the ones who convert that same AI-driven cost-cutting into their own advantage.

The same mechanism, repeating at three altitudes.

Same mechanism. Three altitudes. At every level, the question is identical: who captures the value AI creates, and who absorbs the cost of it?

What’s still genuinely uncertain

None of this is a settled prediction, and it’s worth being honest about exactly where the uncertainty sits.

PPFAS’s IT bet is live and unproven — Thakkar’s own letter to unitholders is explaining two hard years, not declaring a win. The Wharton paper is a theoretical model of incentives, not a confirmed forecast of what will actually happen to the broader economy. And Ng’s framework, however useful, is also a pitch for a discipline his company happens to teach.

What doesn’t depend on any of those three specific claims turning out to be right is the pattern itself: AI is reliably relocating where value and risk land, at every scale from a single database instance to a national economy. The specific bets — a fund’s allocation, a paper’s policy proposal, an individual’s choice to propose beyond their ticket — are how each of us answers, in practice, which side of that split we’re actually standing on.

That's not a comfortable question. It's the right one.

Sources: Rajeev Thakkar's letter to Parag Parikh Flexi Cap Fund unitholders (August 2026); "The AI Layoff Trap" by Brett Hemenway Falk and Gerry Tsoukalas, Wharton School Research Paper (2026); Andrew Ng, "AI Engineering Skills Map: Shaping the Build."

The AI Estimation Framework

hello@vineet-arya.com (Vineet Arya) — Tue, 01 Sep 2026 00:00:00 GMT

A few months ago I wrote about a habit I’d fallen into and had to break: asking AI how long a task would take, and trusting the number that came back.

The number was always huge. It never mentioned headcount. And for a while, I couldn’t figure out why.

The problem with asking AI to estimate

Here’s the answer, once I actually sat with it: an AI model has no idea who’s on your team, how well they know the codebase, or what “done” means in your specific context. Ask it for an estimate and it defaults to a padded, generic, worst-case guess — because that’s the safest answer it can give without any of the information that actually determines a real timeline.

Your own judgment, built from your team’s actual context, is more reliable than anything a model will hand you. The fix isn’t a better prompt. It’s a better method — one where your judgment is the engine, and AI is a multiplier you apply to it, not an oracle you defer to.

The method, briefly

The framework has four moves:

Estimate the work as if there were no AI. This is your anchor — the number you’d trust from experience alone.
Split the work into three tiers, because AI does not speed up every kind of work equally:
- Mechanical / boilerplate — scaffolding, CRUD, wiring a component from a clear mockup. AI is genuinely fast here, often 3-5x.
- Integration with existing code — matching your patterns, working around your stack’s quirks. AI helps, but you’re spending real time reviewing and correcting. More like 1.5-2x.
- Novel, ambiguous, or judgment-heavy work — the spec isn’t fully decided, the design isn’t settled. AI barely moves the needle here. Roughly 1x — sometimes slower, because the bottleneck is thinking, not typing.
Add back what AI does not compress: code review (which grows, since more code gets produced faster), scoping and discovery, and the friction of integrating with a system nobody fully mapped out in advance.
Convert effort into a timeline separately. Engineer-weeks is not calendar-weeks until you know what can actually run in parallel — and even then, apply an efficiency factor, because two engineers rarely deliver twice the throughput of one.

The honest result, most of the time, is a real 1.5-2x speedup on the whole project. That’s excellent. It’s just nowhere near the “AI makes this instant” fantasy that sets teams up to look like they’re failing at succeeding.

Why I turned it into a tool

The first version of this was a spreadsheet — genuinely useful, downloaded and used by a fair number of people. But a spreadsheet has friction built in: download it, open it, trust that the formulas are intact, figure out which cells to touch.

So I rebuilt it as something you can just open and use. No download, no email wall, no signup. Enter your baseline, adjust the tiers and multipliers to match your own team’s reality, and watch the estimate — and the honest calendar range — update as you type.

Try the AI Estimation Framework →

What to actually do with the number it gives you

Two things, regardless of what the tool outputs:

Report a range, not a single number. A single number gets treated as a promise the moment it leaves your mouth. A range signals, correctly, that this is an estimate grounded in judgment, not a guarantee extracted from a formula.

Recalibrate the multipliers as you gather real data. The defaults (4x, 1.75x, 1x) are starting points from general experience, not laws. If your team’s actual numbers look different after a few sprints, change them. The tool is a calculator for your judgment, not a replacement for it — and it gets more accurate the more honestly you feed it what’s actually happened on your team.

This is the same estimation method I originally shared as a spreadsheet, now rebuilt as a live tool. If you use it and your team’s real multipliers end up looking different from the defaults, I’d genuinely like to hear about it — that’s exactly the kind of data that makes a framework like this better over time.

Download the spreadsheet version →

The AI Layoff Trap: Why Even the Smartest CEO Can't Escape It Alone

hello@vineet-arya.com (Vineet Arya) — Sat, 22 Aug 2026 00:00:00 GMT

Imagine an economy where every company has successfully automated its workforce. Costs are down. Efficiency is up. Every product rolls off the line faster and cheaper than ever.

There’s just one problem: almost nobody has a job anymore, which means almost nobody can afford to buy any of it.

That’s the uncomfortable paradox at the center of new research out of Wharton. In a 2026 paper called “The AI Layoff Trap,” economists Brett Hemenway Falk and Gerry Tsoukalas model something every CEO already senses but rarely says out loud: workers aren’t just a cost line. They’re also the customers who keep the economy’s engine running. Replace them fast enough, and you don’t just cut expenses — you quietly cut the demand for whatever you’re still selling.

The unsettling part of their finding isn’t that this is possible. It’s that knowing it doesn’t save you from it.

The math behind the trap

Here’s the mechanism, stated plainly: when a company automates a job away, it captures 100% of the savings. But the lost paycheck that used to circulate through the economy — buying groceries, phones, rent — gets spread thin across every company in the market, not just the one that did the firing. In a market with, say, twenty competitors, each firm only feels about a twentieth of the demand it just helped destroy.

That’s a textbook case of what economists call a demand externality — a cost your decision creates that mostly lands on someone else’s balance sheet, not yours. And when a cost is externalized like that, rational actors tend to ignore it, even when they can see it clearly. The finding isn’t a failure of individual judgment. It’s what happens even when every CEO in the room is doing the math correctly.

A few analogies make this click faster than the equations do.

Picture one giant company that makes all the widgets in the world and employs almost everyone. A brilliant new AI arrives that could automate 90% of the workforce overnight.

Would the CEO do it?

Almost certainly not — not out of generosity, but out of self-interest. That CEO knows their own laid-off employees are their customer base. Fire 90% of them, and 90% of your buyers vanish along with your payroll. The monopolist internalizes the full cost of automation, because there’s nowhere else for that cost to hide. So they automate carefully, keeping enough workers employed to keep the whole system solvent.

Now shatter that monopoly into a hundred competing widget companies. Each CEO now reasons differently: my own workers are just a sliver of the total market. If I lay them off, sure, they’ll buy less — but that’s a rounding error against total industry revenue. Each individual company’s incentive to automate aggressively goes up exactly as the market becomes more competitive, because each one now bears only a fraction of a cost the group is creating together.

The tragedy of the commons, updated for the AI economy

That “shared cost, private gain” structure has a name in economics, and it predates AI by centuries: the tragedy of the commons.

The classic version — a village shares one pasture. Every herder benefits fully from grazing one more cow on it, but the cost of an overgrazed, ruined pasture is shared by everyone. So each herder, acting rationally, keeps adding cows, right up until the field is stripped bare and nobody can graze anything.

Consumer demand, in the Wharton model, is the new commons. Every company benefits fully from automating its own workforce. The damage to the shared pool of purchasing power gets split among everyone. No single firm is destroying the economy on its own — they’re all quietly overgrazing the same field, certain that their own herd is too small to matter.

The prisoner’s dilemma: automate or be automated

This is also, structurally, a prisoner’s dilemma — the Nobel Prize–winning framework for situations where individually rational choices produce a collectively worse outcome for everyone involved.

In the classic version, two suspects are interrogated separately. Each is better off betraying the other, regardless of what the other one does, so betrayal becomes the “dominant strategy,” even though mutual silence would have gotten both of them a better result.

Automation follows the same cold logic. If your competitors hold back on AI and you don’t, you win big. If they automate and you don’t, you go bankrupt. If everyone automates together, the whole market ends up worse off than if nobody had. But no matter what any other firm chooses, your best individual move is still to automate as fast as possible. As Tsoukalas puts it: no matter what the other companies are doing, the rational strategy is to adopt as much of the technology as you can.

The nuclear arms race — and why handshake deals don’t work

If this all sounds like it needs treaties, not trust, you’re thinking about it the right way. It resembles nothing so much as a nuclear arms race.

During the Cold War, both superpowers understood, in the abstract, that mutual disarmament would leave everyone safer. But neither side could risk disarming first, because a unilateral head start for the other side was catastrophic. The only thing that ever slowed the buildup wasn’t a friendly agreement to “just be reasonable” — it was binding, verifiable treaties with real enforcement teeth.

The Wharton paper reaches the same conclusion about AI. Voluntary pacts between tech giants to “slow down” on automation look reassuring in a press release, but the incentive to quietly break ranks the moment a competitive edge is on the table is enormous — and once everyone knows that, the pact was never really credible to begin with. It only survives as long as everyone believes everyone else is actually keeping it.

Odysseus and the sirens

There’s an older story about exactly this kind of self-control problem, and Tsoukalas reaches for it directly: Homer’s Odyssey.

Odysseus wants to hear the sirens’ song — famous for being so beautiful it lures sailors to their deaths — without dying for it. His solution isn’t willpower. He has his crew bind him to the ship’s mast and orders them, in advance, to ignore any pleading he does once the singing starts.

He doesn’t trust his future self to resist. So he removes the choice entirely, before temptation arrives.

Tsoukalas argues companies today are sailing straight at their own sirens, and shareholder duty makes self-restraint nearly impossible once the song starts playing. The paper’s conclusion is essentially Odysseus’s solution scaled up to an economy: firms need an external force — government policy — playing the role of the rope and the mast, because asking them to resist unaided is asking for something structurally difficult to deliver.

What the rope could actually look like

The researchers are specific about which policy tools work and which ones don’t, in their model. Capital income taxes, worker equity stakes, universal basic income, and upskilling programs all sound reasonable — but none of them address the actual incentive that’s driving the behavior. They treat the symptom, not the trap.

What their model says does work is a targeted tax on full automation — replacing a worker outright, not merely augmenting one with AI tools. The parallel is deliberate: a carbon tax doesn’t tax energy use in general; it taxes the specific externality — pollution — that markets otherwise ignore because no single polluter bears the full cost of a warmer planet. An automation tax would work the same way, making a company account for the demand it destroys rather than letting that cost land on everyone else.

If “tax” is politically radioactive, the researchers offer a gentler mirror image: subsidize the companies that choose to keep their human workforce, rather than penalizing the ones that don’t. Different lever, same underlying goal — nudge the incentive back toward the outcome the whole market actually wants.

What happens if nobody pulls the lever

Left alone, the researchers argue the trajectory bends toward historic wealth inequality, and the kind of political instability that echoes, or exceeds, the aftermath of 2008. That’s a prediction, not a certainty — models simplify the world to make a point legible, and real economies are messier than any equation. It’s also worth being honest that the scale of AI-driven job losses the model assumes hasn’t yet clearly shown up in broad labor-market data, which doesn’t invalidate the mechanism, but does mean the timeline is genuinely uncertain.

What the paper gets right, regardless of exact timing, is the shape of the trap: this isn’t a story about villains making short-sighted choices. It’s a story about a race where every individually rational sprint drags the whole field toward a finish line nobody actually wanted to reach. Odysseus needed the mast because he knew his own judgment wouldn’t hold once the music started. The real question the researchers are putting in front of policymakers is whether anyone is willing to be the rope before the singing begins.

No single CEO can out-judgment their way out of a shared trap. That's exactly why it takes a rope, not a resolution.

Sources: "The AI Layoff Trap" by Brett Hemenway Falk and Gerry Tsoukalas, Wharton School Research Paper (2026), arXiv:2603.20617.