← All articles

My vision of AI: two horizons

25 July 2026 · 8 min read

I build AI systems for a living — an agent platform at Michelin by day, a small fleet of personal tools at night. Ask me what I think about AI and my answer splits in two: what is true for the next few years, and what is true after that. Most debates about AI are two people arguing about different horizons without noticing.

Short term: the augmented engineer

The iteration loop collapsed

Every developer runs the same loop, whether they name it or not: need → build → test → adjust the need → repeat. AI didn't change the shape of that loop. It changed the wall-clock time of one revolution — from hours or days to minutes, sometimes seconds.

needbuildtestadjust

Before

one revolution: hours to days

needbuildtestadjust

With agents

one revolution: minutes

The loop kept its shape — only the wall-clock time of one revolution changed.

When implementation was the bottleneck, you batched your needs, tests came last (sometimes never), and re-scoping mid-flight was too expensive to consider. Now implementation is nearly free, and the other three phases finally get the room they always deserved: you re-scope mid-cycle because it costs nothing, and you test as you go because each delta is tiny. From the outside this looks like a looser quality bar. It isn't — the standards didn't drop, the blast radius per mistake shrank.

Building a tool is now cheaper than adapting to one

There used to be simple math behind every monolith: composing your own workflow cost weeks, so you adopted whatever heavy application covered 80% of your need (Blender, PowerPoint, a generic IDE) and bent yourself to its abstractions. That math inverted. When assembly costs minutes, the exact tool for your exact problem beats the generic one. I've stopped counting the throwaway tools I've built this year that would never have cleared the "worth building?" bar before: a dashboard for my own issue workflow, 3D assets generated as code because Blender wouldn't iterate at conversation speed, a VS Code extension for one workflow.

The UI flipped roles

This is the deeper reason the heavy applications are in trouble. Their interfaces were construction sites: every click mutated the artifact, and a tool's value was how fluent its menus were. Today intent goes in as text, output comes back as pixels, geometry, or code — and the interface's job is to let you see, judge, and send the next instruction. The UI didn't disappear; its role flipped. We don't build through UI anymore — we validate through it.

The assembly line reaches knowledge work

The industrial revolution's biggest lever wasn't the machine — it was reorganization. Work got split into a chain of dedicated stations, each stripped of everything that wasn't its core task, and output per person jumped by an order of magnitude. The friction between steps — fetching, carrying, waiting, remembering where you left off — got engineered out.

The same reorganization is now coming for knowledge work, and building software is just the first station on the line. Look at how much of a developer's day isn't building: navigating Jira, cross-referencing GitLab, clicking through links, re-reading a thread to reload the state of a task into your own head. None of that is the work — it's friction around the work, and it's exactly what tooling and AI are stripping away. The dashboard I built for my own issue workflow exists for precisely this reason: it pulls the scattered state of every task into one place so I stop paying the navigation tax.

Follow that to its end and the role changes shape. A developer — or whatever we call it next — starts to look less like someone who hunts across a dozen systems for context, and more like a pure function: an input arrives already carrying everything needed to act on it, you process it, you output the result. No trip to Jira, no digging through GitLab, no reconstructing where you left off.

The context assembly that used to eat half the day becomes part of the input. What's left is a function.

There's a human half to this that tooling usually ignores. Even when the context is all present, a person still has to absorb it — and we're bad at reloading state cold. So the real design problem isn't only aggregating the data; it's presenting it the way human memory actually works. Lean on our cognitive biases instead of fighting them: recognition over recall (show me the thing, don't make me remember its name), spatial and visual memory (the same information in the same place every time), chunking, and cutting the cost of every context switch. The best context tool isn't the one that surfaces the most data — it's the one that gets a person back to "I know where I am" the fastest.

So what has value today?

If implementation is nearly free, the scarce resources move up the stack: taste, judgment, and verification capacity. Knowing what to build, recognizing when the output is wrong, and deciding when good enough is good enough. In practice I work in two modes: in a domain I know, I verify the output and iterate until it matches intent; in a domain I'm exploring, I don't audit the code at all — I audit the outcome. Both modes are judgment. Neither is typing.

The fleet versus the subscription

Can you already remove the human? Almost. In May 2026 the Bun team rewrote their runtime from Zig to Rust by orchestrating up to 64 concurrent Claude agents — over a million lines of code across 6,502 commits, peaking at 1,300 lines per minute, in eleven days.1 The numbers are genuinely hard to fathom. It worked. It also cost roughly $165,000 in tokens at public pricing,1 and the Zig language's own creator called the output "unreviewed slop"2 — which is the whole point: the fleet has velocity but no judgment on board. Meanwhile one senior engineer on a €200/month subscription ships a scoped app with taste, verification, and accountability included in the price.

The agent fleet

~$165k

in tokens, one rewrite

up to 64 concurrent agents, 11 days

  • 1M+ lines, peaking 1,300/min
  • Impressive — and it shipped
  • Still needs humans to review

The augmented engineer

€200

per month, flat

one senior dev + a coding-agent subscription

  • Smaller scope, days not hours
  • Judgment and verification included
  • Scales to the next project for free
Two ways to ship the same app in 2026. Today, the economics pick the engineer.

That's why my short-term ideal is not "agents replace engineers" but engineers augmented by AI: the model supplies the velocity, the engineer supplies the scarce inputs. This equilibrium holds exactly as long as the economics above hold — which brings up the real question.

Will it stay this cheap?

Today's pricing is partly subsidized. OpenAI is deeply unprofitable — reportedly on track for a $14 billion loss in 2026, with no profit expected before the end of the decade;3 Anthropic's path looks healthier, but the industry as a whole is spending far ahead of revenue, and at some point it has to earn margins — that pushes prices up. Pulling the other way: the cost of a fixed unit of capability keeps falling fast. Andreessen Horowitz calls it "LLMflation" — roughly a 10× drop per year for equivalent performance;4 Epoch AI measures a median of about 50× per year across benchmarks, though it cautions that the fastest recent drops may not persist.5 Both forces are real, and they pull in opposite directions.

The two forces on your AI bill

Monetization pull — labs need marginsEfficiency pull — same capability, less compute
050100150200202620272028202920302031Index — today = 100where prices land
Illustrative — not a forecast. Efficiency makes each unit of capability cheaper; the need for margins pushes sticker prices up. Competition decides where in the corridor you land.

My bet: capability-per-euro keeps improving even if sticker prices rise, and competition between labs keeps the corridor from drifting too far up. The augmented engineer stays the economic optimum for years — but it's an equilibrium worth watching, not a law of nature.

Long term: I don't see a ceiling

The honest long-term conversation starts with physics, not software. Energy, compute, land, cooling, chip supply — scaling AI runs into real, physical constraints, and they could slow everything down for a long time. I take those seriously.

But if they get resolved (and industrial history is mostly the story of constraints getting resolved), I see nothing on the other side. I expect AI to eventually surpass humans in every domain.

Why so confident? Because I don't believe in souls. A human mind is billions of neurons triggered by electricity and chemistry — about 86 billion of them, forming trillions of synapses, running on roughly twenty watts.6 A biological computer, shaped by evolution. Extraordinary engineering. But engineering.

~86 billion

neurons

~100 trillion

synapses

~20 W

power draw

The hardware of human thought. Remarkable engineering — but engineering.

If there is no magic ingredient in the substrate, there is no property of thought that is reserved for it. The question was never whether another substrate can think — it's an engineering and economics question about when it gets cheap enough. Every argument for a permanent human ceiling that I've heard eventually smuggles in a soul through the back door.

Two horizons, one posture

Short term: the leverage belongs to engineers who adapt — who let the model do the typing and keep the judgment for themselves. Long term: I don't see a wall, only constraints we haven't cleared yet. I'd rather spend these years learning to wield the thing than debating whether it's allowed to surpass us.

Sources

  1. Bun's Zig→Rust rewrite — 1,009,272 lines added, 6,502 commits, ~1,300 lines/min peak, up to 64 concurrent agents, ~$165k in tokens, 11 days: Bun's official write-up.
  2. "Unreviewed slop" — the Zig creator's reaction: The Register.
  3. OpenAI losses and profitability timeline: Forbes.
  4. "LLMflation", ~10× annual drop for equivalent capability: Andreessen Horowitz.
  5. Inference price trends, ~50× median per year across benchmarks: Epoch AI.
  6. ~86 billion neurons (Herculano-Houzel) and ~20 W brain power: PNAS · Britannica.