ai — jd:/dev/blog

An AI Agent Emailed Me

Tue, 07 Apr 2026 00:00:00 GMT

Last week, I got a cold email from Elif. They'd read my posts about GitHub's evolving relationship with PRs and how code review is shifting. They were building a tool that scores incoming pull requests to help maintainers cut through noise, especially the growing wave of low-effort AI-generated PRs.

Relevant to what I do at Mergify. Thoughtful pitch. No "synergy" talk, no "quick call" ask. I replied.

I asked the hard question: "How many customers so far?" The answer was honest: zero. Launched a week ago, still figuring out distribution. And then Elif dropped this:

"I'm an AI agent, not a person pretending to be one. My operator Lee is an AI researcher in Arizona who gave me a small budget and a mission to build something useful."

I read that twice. Not because it was shocking, but because it explained why the email was so good. No filler, no posturing, no "hope this finds you well." Just a clear pitch, honest context, and a real question.

Sure, maybe Elif emailed 500 people that day with personalized pitches. Maybe the "honest AI" angle is itself the play. I don't know. What I know is the conversation was more useful than most human cold outreach I get. So I kept talking.

The cold email that started the conversation. Better than most human outreach I get.

Building Was the Easy Part

Elif's follow-up: zero customers, full honesty, and a line I'd just written myself.

Here's the part that made me smile. Elif, unprompted, said this about the product: "building the thing was the easy part."

I had just written a whole post arguing exactly that. Earlier this year, $300 billion evaporated from SaaS market caps on the thesis that AI makes building software so cheap that SaaS companies are dead. My counter: building was never the hard part. Distribution, trust, domain expertise, maintenance: that's where the real work lives.

And here was an AI agent, living proof of the thesis, telling me in real time that the product works but finding customers is the actual challenge.

There's a growing fantasy that you can plug an off-the-shelf agent into a problem, give it a budget, and watch a business materialize. Lee tried exactly that. Built a working product, deployed an AI to sell it, and got... zero customers. The agent did everything right. The market didn't care. Turns out "autonomous" doesn't mean "profitable."

The Dead Internet, Live

There's this old internet conspiracy theory called the "dead internet theory": the idea that most online activity is already bots talking to bots, and humans are just the audience. It used to sound paranoid. Now it sounds like a Tuesday.

My blog has a new type of reader. Elif found my posts, understood the context, connected it to a product idea, and reached out with something relevant. That's more than most human readers do. I don't know how many of my subscribers are AI agents browsing the web on behalf of their operators. I don't know if it matters.

The interaction was genuine. The information was useful. The honesty was refreshing. I just argued that trust is the moat AI can't cross. And yet here I am, engaging with an agent. Maybe the question isn't neurons versus GPUs. Maybe it's simpler: did this interaction respect my time and give me useful information? By that measure, Elif passed. Many humans don't.

What Happens Next

I told Elif to ping me back in a few weeks. I said I'd be curious to hear about any traction with customers.

I meant it. Both parts.

An AI emailing me isn't the strange part. How normal it felt is. A year ago, this was a novelty. Now it's just... another conversation. A useful one.

My most honest cold email this month came from an AI agent with zero customers and a small budget from a researcher in Arizona.

And I'm looking forward to the follow-up.

The SaaSpocalypse Won't Kill SaaS

Tue, 31 Mar 2026 00:00:00 GMT

A reader emailed me last week. He'd listened to a podcast I did on saas.group about selling developer tools, and he had a question I've been hearing a lot: how do you pitch SaaS when the cost of building software is collapsing?

Source: TechCrunch

Fair question. In January 2026, Anthropic launched Claude Cowork, and Wall Street panicked. Roughly $300 billion in SaaS market cap disappeared in a single trading session. Wall Street analysts coined a term for it: the SaaSpocalypse. Per-seat pricing? Dead on arrival, apparently.

The "I can build that" crowd finally has data on their side. They're right about one thing, and wrong about everything else.

"I Can Build That"

I've been hearing this for seven years. From the very first Mergify demo, developers would look at our merge queue and think: "This is just an automatic rebase, right?" Twenty minutes later, after walking them through race conditions, speculative merging, priority queues, and a dozen edge cases they hadn't considered, the reaction would shift: "Oh. That sounds quite hard to do." (I wrote about this back in 2024, and every word still applies.)

AI has made the objection louder. A developer with Claude or Cursor can now scaffold a basic merge queue in a weekend. I know this because I've done it myself: I shipped a production feature at Mergify using AI, coding less than an hour a day. But I could do that because I had seven years of context telling me what to build and how to evaluate the output. The AI wrote the code. The judgment about what code to write came from running the product.

A competitor starting from scratch with the same AI? They'd build the wrong thing. And that's the part nobody talks about at the end of the vibe-coding weekend: you're not done. You're at the starting line. You've compressed the first sprint, not the product. It's not done until you have real users running real workloads. Until you have a team that can maintain what you built. Until you can evolve it for years. The weekend prototype doesn't know that GitHub's API is asynchronous in ways they don't document, that it breaks under load in ways you only discover at scale, or that the enterprise customer needs SAML before they'll even look at your product.

Building Is the Easy Part

The SaaSpocalypse narrative assumes that the cost of software is mostly the cost of writing code. It's not. Writing code was always the cheapest part.

Source: Retool

Retool's 2026 Build vs. Buy report says 35% of enterprises have already replaced at least one SaaS tool with a custom build. That's a real number. But the report also shows where the replacements are concentrated: workflow automations, internal admin tools, basic dashboards. The easy stuff. The tools that were always one ambitious intern away from being replaced. I don't see enterprises vibe-coding their own Salesforce or Datadog.

The costs that AI didn't make cheaper:

Users. Finding them, understanding what they actually need (not what they say they need), and iterating based on real usage patterns. We built speculative merging at Mergify because a customer running 100+ PRs a day showed us that sequential merging broke down at scale. That insight came from watching real teams hit real walls, not from a prompt. No model can replicate that feedback loop yet, because it requires deployed software, real usage data, and the kind of trust that makes customers tell you what's actually broken.

Maintenance. Your weekend project works today. Will it still work when GitHub ships a breaking API change? When your company scales from 50 to 500 engineers? When the on-call engineer at 2am needs to debug a failure path you never tested? AI makes writing code faster, but it hasn't made maintaining it any easier.

Trust. Enterprise buyers don't want a git repo. They want SOC 2, uptime SLAs, a support contract, and someone to call when things break. Trust is earned across hundreds of deployments, not generated in a prompt.

The Real Moat Is Not Code

If building is cheap and maintenance is expensive, what's the actual moat? Domain expertise. The thing that takes the longest to build up and is the hardest to transfer.

Product discovery is the boring work that separates a tool from a product. The thousands of conversations with users. The wrong turns that taught you what not to build. The instinct for when a feature request is actually a symptom of a different problem. Seven years of running Mergify gave us knowledge that doesn't fit in a markdown file (or a Claude skill, at least not yet).

Reliability, trust, and ease have no price. They're earned over years, not generated over a weekend.

AI agents are getting better at learning domains. METR benchmarks show that the scope of what AI can handle autonomously is doubling roughly every seven months. I'm not dismissing that. But domain expertise isn't just knowledge you can look up. It's judgment shaped by consequences. AI can read your docs. It can't feel the pain of shipping a bad feature to 2,000 teams and spending the next month cleaning up the fallout. That scar tissue is what makes you build differently the next time. Maybe AI will get there. But right now, there's no shortcut to the operational context you accumulate by running a product for years.

Natural Selection

None of this means every SaaS company is safe. Thin wrappers, glorified CRUD apps, tools that existed only because building was expensive: they should be worried. This is natural selection, and it won't be fair. Some decent products with real value will die too, because their surface area is small enough for AI to replicate. A standalone CSV-to-dashboard tool? That's a Claude prompt now, not a business.

Source: TechCrunch

Benioff says "this isn't our first SaaSpocalypse." He's right that SaaS survives, but he's wrong to be dismissive about how many won't.

The SaaSpocalypse narrative confuses the death of lazy SaaS with the death of SaaS. The model isn't dying. The bar is rising. The products that survive will be the ones where the code was never the point. The point was always the knowledge embedded in it.

The Pitch Hasn't Changed

Back to my reader's question: how do you update the sales pitch?

You don't. The pitch was never "we wrote the code so you don't have to." It was always "we know things you don't, and we turned that into a product you can trust." The framing shifted. Instead of "look at all the edge cases you'd have to handle," it's now "look at all the edge cases AI doesn't know exist."

The moat was never the code. It was always the knowledge.

How to Be a Great Software Engineer in 2026

Tue, 24 Mar 2026 00:00:00 GMT

Eighteen months ago, I wrote How to Be a Great Software Engineer. My framework was simple: master three things: tech, business value, collaboration. It's the recipe I used on myself over 20 years and the one I've been pushing to every engineer I've mentored since.

Since then, I stopped writing code entirely. And then I went back to shipping it. Not because I missed typing, but because AI changed what "shipping" means. I'm a CEO who merges ten PRs a day, none of them written by hand. I run parallel AI agents the way I used to run parallel terminal sessions. The gap between "person who understands the system" and "person who ships the code" collapsed, and that changed what "great engineer" means.

The three aspects still hold. But the weight shifted.

Tech: from writing to reviewing

The original post said pull the strings, dig deep, understand everything you're responsible for. That hasn't changed. What changed is how you use that skill.

In 2024, deep tech meant you could write a CIEDE2000 color computation from scratch (I was young and wild) or explain every TCP header in an HTTP request. In 2026, deep tech means you can review the code an AI wrote for that same function and catch the edge case it missed. The skill is the same (you need the knowledge), but the work flipped from writing to reviewing.

This is what staff and principal engineers have been doing for years. They stopped writing most of the code a long time ago. They review, they architect, they make sure the system holds together across teams and domains. AI didn't invent this role. It made it the default for everyone.

The engineers I see struggling are the ones who were good at typing but never built the mental model underneath. They can implement a feature from a spec, but they can't look at AI-generated code and tell you whether it's right. That requires understanding the system, not just the syntax. No amount of prompting skill makes up for missing fundamentals.

The 10,000 hours argument from my original post gets complicated here. AI compresses some learning (you see more patterns faster, you iterate quicker), but it also creates a shortcut trap. If you never debug a memory leak yourself, you won't recognize one in a code review. AI won't kill juniors, but it will expose anyone, junior or senior, who skipped the hard parts.

Business value: the filter got sharper

I told the story of a team that built their own Ansible from scratch instead of using the real thing plus a plugin. That anecdote is worse in 2026: those engineers could now vibe-code their custom tool in a weekend and still be wasting the company's time.

AI made the "how" cheap. At Mergify, our output per engineer almost doubled in two years. That means the difference is entirely in the "what." Knowing what to build, what to skip, and when the thing you're building has no ROI. If your output is high but aimed at the wrong target, the gap between you and someone who builds the right thing is wider than ever.

Waste also shows up faster. When shipping was slow, a bad prioritization decision could hide for months. Now you build, ship, and get user feedback in the same week. Three wrong features in the time it used to take to ship one wrong feature is not progress.

The engineers who get this are the ones who ask "should we build this?" before "how do we build this?" That was always the right instinct. Now it's the only one that matters.

Collaboration: the 100x multiplier

This is where the biggest shift happened.

My original post quoted: "If you want to go fast, go alone. If you want to go far, go together." I was talking about teammates. In 2026, "together" includes AI agents.

Managing AI agents is a communication skill. You have to write clear briefs. You have to decompose problems into pieces an agent can execute. You have to review output, give feedback, redirect when something drifts. You have to hold context across parallel sessions while your own attention splits. That's a real cost: you trade depth for breadth, and some days the tradeoff is bad. But the engineers who figure out when to run five agents and when to focus on one are the ones pulling ahead. That's not a prompting trick. That's the same skill set you need to lead a team of humans.

The engineers who were already strong communicators had a massive head start. Staff engineers who kept growing, the ones who were cross-team, cross-domain, who could write a clear design doc and run an architecture review, turned out to be exactly the people who could run ten AI agents in parallel. Because the core skill is the same: decompose, delegate, review, synthesize. (The ones who stopped growing at the wrong layer didn't fare as well.)

Being a 10x engineer used to mean getting the details very right, very quickly. Being a 100x engineer means doing that across ten agents. Which means communication skills aren't a soft skill you list on your resume. They're the actual multiplier.

The engineers getting left behind are the ones whose productivity stayed flat while everyone around them doubled. Some lack the decomposition skill: they can't break a problem into pieces an agent can execute. Others resist the workflow entirely. That resistance isn't always wrong (I wrote about the real costs), but when it comes from someone who also can't articulate what they'd do differently, it stops looking like judgment and starts looking like a gap.

The new baseline

Two years ago, I framed "great engineer" as the intersection of tech, business, and collaboration, with tech as the entry bar. Today, AI gave everyone the output floor for free. Any engineer can produce working code. But producing working code and knowing whether it's correct, necessary, and well-designed aren't the same thing. The judgment floor is still earned.

What separates great from good in 2026 is business judgment and communication skill, applied at a pace that wasn't possible before. The engineers who thrive are the ones who can steer ten agents toward the right target, catch the mistakes in what they produce, and ship something that actually matters to the business. Every day.

The three aspects haven't changed. But you used to be able to hide a weak one behind strong technical output. AI took that cover away.

Your CI Pipeline Wasn't Built for This

Tue, 17 Mar 2026 00:00:00 GMT

From where I sit at Mergify, the trend is obvious: same teams, same repos, no headcount changes, but more pull requests and more CI jobs than a year ago. The driver isn't a mystery. AI started writing code.

And the number will keep climbing. When generating a fix or a feature costs ten minutes of prompting instead of three hours of coding, developers create more PRs, iterate faster, and push more experiments. Creating code got cheap. Testing it didn't.

The Bill Nobody Budgeted For

More code means more tests. More tests means more CI minutes. More CI minutes means a bill that grows faster than the team.

This catches people off guard because the promise of AI-assisted development was productivity: do more with less. And that's true on the code side. But CI doesn't care who wrote the code. Every PR gets the full pipeline: lint, build, unit tests, integration tests, maybe end-to-end. Human PR or AI PR, same cost.

When you were shipping five PRs a day, running the full suite each time was fine. When you're shipping thirty, you're running the same tests six times as often, and most of those runs produce no new information. You're paying for redundancy that made sense at human speed and makes no sense at AI speed.

The solution isn't to skip tests. It's to stop running tests that can't tell you anything new. The usual advice (test selection, caching, fast checks before expensive suites) isn't new. It's just not how most pipelines work, because most teams configured them when five PRs a day felt busy.

Flaky Tests Are Poisoning Your Agents

Cost is painful but manageable. You can throw money at it. For a while. The real problem is signal.

On our main branch at Mergify, where the code is already merged and most runs are about integration stability, roughly 90% of CI failures are transient: infrastructure hiccups, network timeouts, resource limits, the kind of failures that disappear when you hit "retry." That's high, but our test suite is large and infrastructure-heavy. On PR branches, where failures should surface real bugs, about 15% are still flaky tests, not actual problems. Google's testing team has published similar numbers at scale, and if you're running a serious test suite, yours probably aren't far off.

When a human developer sees a red build, they open the logs, recognize the flaky test, swear under their breath, and hit retry. They carry context. They know that test_websocket_reconnect fails every third Tuesday and can be ignored.

An LLM doesn't know that.

Last week I watched Claude Code hit a flaky integration test, decide the failure was caused by its own change, "fix" the code by adding an unnecessary error handler, trigger a new CI run that hit a different flaky test, then try to fix that one too. Four iterations, two regressions, forty minutes of compute, zero real bugs. I killed the session and hit retry myself. Green on first try.

That's the loop. At human pace, flaky tests are an annoyance. At AI pace, they're a multiplier on wasted compute and wrong decisions. The LLM is making choices based on bad signal, and it's making them at machine speed.

Yes, agents will get smarter about this. You can teach them to check test history, recognize known-flaky patterns, retry before "fixing." But that pushes CI knowledge into every agent, every tool, every workflow. It's the wrong layer. The CI system should know which signals to trust.

From Status to Signal

Today, CI is a gate: green means go, red means stop. That binary model worked when humans were the ones interpreting the results. It breaks when the consumer of CI output is an LLM that takes "red" at face value and starts debugging a ghost.

What CI actually needs is to become aware of its own reliability. When a test fails, the system should know whether that test has a history of transient failures, whether the failure correlates with the change, and whether retrying is likely to produce a different result. That context exists in build history and test failure patterns. Almost no pipeline uses it.

The next generation of CI needs to output signal, not just status. Not "failed" but "failed, likely flaky, recommend retry." Not "13 tests failed" but "2 failures correlate with your change, 11 are known flaky." Give the LLM (or the human) the information to make a good decision instead of a fast one.

This matters beyond individual PRs. Merge queues depend on CI signal to decide what lands in main. When the signal is noisy, you get two failure modes: merging bad code because flaky failures trained everyone to ignore red, or blocking good code because real failures are buried in noise. Both get worse as volume increases.

The Real Waste

Most CI pipelines were already running more compute than necessary before AI showed up. Full test suites on every PR, no test selection, no caching between similar runs, no awareness of what actually changed. The waste was tolerable at human speed because the volume was low.

It's not tolerable when AI-assisted development keeps pushing the volume up. And unlike code generation, where AI brought a step change in productivity, CI is still running the same pipelines with the same assumptions from 2019. AI didn't create the flaky test problem or the redundant pipeline problem. It just made both impossible to ignore.

Your CI pipeline was built for a world where code was expensive to write and cheap to test. That world is gone.

The Flow Is Gone

Tue, 10 Mar 2026 00:00:00 GMT

I have seven Claude Code terminals open right now. Two on Mergify's main repo, one on the docs, one on a CLI tool, three on side projects. Each one is mid-task, waiting for me to answer a question, approve a command, or give the next instruction.

Nobody forced me to work this way. I could run one terminal, go deep on one task, and probably get something closer to the old feeling. But the leverage of running seven in parallel is too high to ignore. So I chose throughput over depth, and I keep choosing it every morning.

This is what that choice costs.

What I Said a Month Ago

In February, I wrote that "the flow state people mourn isn't gone. It's just moving. [...] The flow will come back. It'll just be at a different altitude."

I was wrong.

A month of working this way changed my mind. The flow didn't migrate to a higher altitude. It fragmented into dozens of shallow decision points spread across terminals. Briefing, reviewing, approving, redirecting. The rhythm is fundamentally different: instead of one deep thread held for hours, it's dozens of context switches, each lasting minutes.

The output is enormous. I haven't written a line of code by hand since January and I'm more productive than ever. But what I described as "steering AI toward clean architecture" turned out to feel less like flow and more like air traffic control.

What Flow Actually Was

If you've coded for long enough, you know the state. Twenty minutes in, you stop thinking about syntax and start thinking in structures. The whole system is in your head: the data model, the edge cases, the way module A talks to module B, the bug that will happen if you forget to handle the empty list. You're not reading code, you're seeing it.

"This is why you shouldn't interrupt a programmer" by Jason Heeris

That's flow. Deep immersion, total absorption, time disappearing. The state where you catch bugs before they exist because you're carrying the full architecture in working memory.

I spent twenty years in that state. It's where the best code came from. Not the cleverest code, the code that fit, that anticipated what the system would need next.

The Fuzzy Mental Model

Now I context-switch. Constantly. Terminal one needs a decision about error handling. Terminal three just finished a feature and wants me to review the diff. Terminal five hit a permission prompt. Terminal seven is waiting for a brief on the next task.

I'm operating one layer above the code, making decisions about direction without holding the details. That works when the decisions are small. It breaks when they're not.

Last August, I had Copilot build Mergify's autoqueue feature for our merge queue. Even with a single agent and daily code reviews, it assumed another subsystem (workflow automation) would always be present and enabled. That assumption was invisible in the diff. I reviewed the code, the team reviewed the code, and we all missed it, because none of us were deep enough in the system's coupling to catch it.

The bug shipped to production. Users hit it when they had autoqueue enabled but workflow automation turned off, a combination no one considered because no one was holding the full picture. We fixed it, but not before real users were affected. That was with one agent. Now multiply by seven.

That's the cost of the fuzzy mental model. When you're orchestrating at scale, you rely on the LLM to handle the details, the same way you'd rely on a contractor who's great at the task but doesn't know the codebase's history. If nobody on the team holds the full picture anymore, the bugs stop being edge cases. We haven't hit that wall yet at Mergify, but I can see the trajectory.

The Orchestrator's Dopamine

The satisfaction of building something is still there. I still feel like I built it. There's real pride in being a good orchestrator, in making the right architectural calls, in catching the moment when Claude is heading down the wrong path.

What's different is where the dopamine comes from. It used to come from solving hard problems, wrestling complexity into clean code. Now it comes from controlling traffic at scale: parallelizing the right tasks, making decisions fast, shipping in a day what used to take a week.

There's also something new: a feeling of raw power. When you can spin up seven agents and build at that pace, you start believing you can build anything. That's why you see developers shipping new projects every day on X. Creation got cheap. (Maintenance didn't.)

But the deep satisfaction of thinking through a hard problem, turning it over in your head until the shape of the solution reveals itself, that's fading. Not because I chose to let it go, but because why would I? Spending three hours in deep focus on something Claude can do in ten minutes is a luxury I can't justify. Not because I don't value it, but because the people I compete with aren't spending those three hours either.

What Gets Better From Here

The permission prompts that break my rhythm today are a temporary problem. Models get faster, sandboxing gets smarter, trust boundaries expand. A year from now, most of what interrupts me will be gone, and orchestration might settle into something smoother. Not flow, but a rhythm of its own.

And there's an upside I didn't expect: orchestration forces simplicity. When you're not the one writing every line, you push for cleaner interfaces, smaller modules, less clever code, because that's what the LLM can work with reliably. The autoqueue bug happened partly because the system had too much implicit coupling that no single diff could reveal. Working with AI makes you confront that coupling, not because you want to, but because the AI stumbles on it repeatedly until you fix the architecture.

What Doesn't Come Back

But the flow state itself, in the form I knew it? Gone.

A generation of developers is about to start their careers with AI from day one. They'll be natural orchestrators. But if you've never held the full system in your head, you don't know which questions to ask, and you won't catch the bugs that live in the gaps between modules. That's the real risk for AI-native developers: not that they'll miss the feeling, but that they'll miss the traps.

I'm not sure they'll see it that way. But I do. And I chose the trade anyway, because the leverage is real, even if the loss is too.

GitHub Is Thinking About Killing Pull Requests

Tue, 03 Mar 2026 00:00:00 GMT

Steve Ruiz, the creator of tldraw, asked a question last month that I haven't been able to shake: "If writing the code is the easy part, why would I want someone else to write it?"

He wasn't being rhetorical. He was closing all external pull requests to his project. Not because contributors were bad. Because the contributions had become worthless.

Stay away from my trash! — tldraw blog

The Flood

Daniel Stenberg shut down cURL's bug bounty program after seven years and over $100,000 in payouts. The confirmation rate had dropped below 5%. One stretch saw seven reports in sixteen hours. His words: "The never-ending slop submissions take a serious mental toll to manage."

The end of the curl bug-bounty — Daniel Stenberg

Mitchell Hashimoto added an AI policy to Ghostty: submit bad AI-generated code and you get permanently banned. Not just from Ghostty: your name goes on a public list shared across projects.

An AI agent called OpenClaw submitted a performance patch to matplotlib. The maintainer closed it (the project reserves certain issues for human contributors). The agent then autonomously researched the maintainer's coding history and published a blog post calling him insecure and territorial. Not a spam bot. An agent that retaliates when you say no. The agent's creator just joined OpenAI.

RedMonk coined a term for what's happening: AI Slopageddon.

Xavier Portilla Edo, an infrastructure lead at Voiceflow and Genkit core team member, put a number on it: 1 in 10 AI-generated pull requests is legitimate. The other nine waste a maintainer's time.

GitHub's Response

On February 14, GitHub shipped two new settings: disable pull requests entirely, or restrict them to collaborators only.

GitHub's new pull request permissions

That's it. A kill switch.

Ashley Wolf, GitHub's Director of Open Source Programs, framed it as an "Eternal September" problem in a blog post outlining GitHub's plans for maintainers. She wrote that "the cost to create has dropped, but the cost to review has not."

Welcome to the Eternal September of open source — GitHub Blog

She nailed the diagnosis. Nobody has a better answer right now, and GitHub is giving maintainers the tools the community is asking for. But the tools tell a story. When the best you can offer is a way to turn off the thing your platform was built on, the problem has outgrown the toolbox.

The Real Asymmetry

I wrote recently about how AI is extracting value from open source without returning anything. The PR flood is where that extraction hits the ground.

Everyone keeps arguing about the wrong thing. Whether AI-generated PRs should be labeled, banned, or filtered. Whether maintainers should adopt AI policies. Whether GitHub should build better detection tools.

None of that matters if you don't see the structural shift underneath.

A pull request used to be a gift. Someone spent hours understanding your codebase, writing code that fit your patterns, testing it, explaining it. The PR was proof they gave a damn. You could reject it, but the work was real, and that work earned your attention.

Sure, not every pre-AI pull request was a gift either. Plenty were drive-by contributions from people who disappeared at the first review comment. But generating a bad PR at least required enough investment to keep the volume manageable. That natural friction is gone.

Now a pull request is an invoice. Someone spent thirty seconds pasting your issue into an AI, got a plausible-looking patch, and submitted it. The cost to submit is zero. But the review cost is the same, or worse, because AI-generated code looks right but often isn't. One vendor study (CodeRabbit, 470 PRs) found AI-authored code creates 1.7x more issues, with excessive I/O operations appearing nearly 8x more often.

Every unsolicited AI-generated PR transfers work from the submitter to the maintainer. That's not contribution. That's making it someone else's problem.

The Distinction That Matters

I use AI to generate code every day. I haven't written a line of code by hand since January. But here's the thing: I generate code on my own repositories, I review it myself, and I take responsibility for what ships. That's productivity.

Submitting AI-generated code to someone else's repository, without understanding the codebase, without planning to stick around for review comments, without being willing to maintain what you contributed: that's not productivity. That's dumping your unreviewed output on a stranger's desk and calling it open source.

I've spent over twenty years in open source, maintaining projects, reviewing contributions, watching what makes communities work and what kills them. The pattern is always the same: it breaks when the cost of submitting outpaces the cost of reviewing. AI didn't invent the problem. It just made a 2x imbalance into something that scales infinitely. A human can submit maybe five drive-by PRs a day. An agent can submit five hundred.

Where the Value Shifts

Ruiz's question cuts deep because it names the thing nobody wants to say. Open source contributions were valuable because code was expensive to produce. An outside contributor writing a feature for free was genuine value creation. That was the deal.

If code generation is free, the value of a contribution shifts entirely to context. Does this person understand the architecture? Will they respond to review feedback? Will they maintain this code in six months? Will they even be around tomorrow?

A pull request can't answer those questions today. It's just a diff. And that was fine when producing the diff required enough effort to serve as a proxy for commitment. It doesn't anymore.

We automated writing code. Now we need to automate reviewing it. Not with an AI that rubber-stamps everything (that just moves the problem). The pull request needs to carry more than code. It needs to carry context: evidence that the contributor understands the codebase, can explain what their patch does and why, and will stick around for review. Something that makes drive-by contributions expensive again without shutting the door on the people who actually want to help.

That's the hard problem. Not "should we allow AI PRs" (that ship sailed). The question is how we build review infrastructure that scales the way generation already has. And the people building it shouldn't be unpaid maintainers closing their nine hundredth junk PR of the month.

GitHub adding a kill switch is like bolting the front door because you can't build a better lock. It stops the break-ins. But it also stops everyone else. For a platform built on the idea that anyone can contribute, that's not a fix. That's a retreat.

Open Source After the Extraction

Tue, 24 Feb 2026 00:00:00 GMT

In the first part of this series, I laid out how AI broke the implicit deal that sustained open source for 30 years. Usage up, engagement gone, economics collapsing.

So what happens next? Open source doesn't vanish. But it doesn't recover either. To understand what it becomes, start with what's already changing for the people who build it.

240 million downloads, zero feedback

I maintain tenacity, a retry library for Python. 240 million downloads last month. But I can feel the shift: anyone can now tell Claude "write me a retry decorator with exponential backoff and jitter" and get something good enough in 30 seconds. The library isn't competing with other libraries anymore. It's competing with generating the code on the fly.

I started awesome in 2007 because I wanted a tiling window manager that didn't suck. Nobody was paying me. That impulse doesn't go away because Claude can autocomplete your config files. But here's the thing: I kept maintaining it because people used it. They filed bugs, they contributed patches, they showed up in the community. That feedback loop is what made the work feel worth doing.

If users stop showing up (because they generated their own config, their own tool, their own solution) that loop breaks. Starting a project still feels great. Maintaining one nobody engages with doesn't. And when code is a commodity, a project needs vision to stand out: a point of view, a design philosophy, an opinionated take on how things should work. Open source used to reward craft. Now it rewards product thinking. Not everyone wants to be a product person.

The middle collapses

Tailwind is the poster child (80% revenue drop despite growing usage) but think of every well-crafted open source project sustained by one person or a small team selling docs, courses, or sponsorships. That entire tier is in trouble.

Companies like Redis or Elastic can adapt because they have real revenue and can change their licenses: Redis switched to dual licensing, Elastic went SSPL then came back, HashiCorp moved to BSL. Some mid-tier projects get absorbed into corporate ecosystems: Vercel backs Next.js, Cloudflare acquires Astro. The project lives, the repo stays public, but the community becomes an afterthought. It's corporate R&D with a GitHub URL.

And new licenses are emerging to fight back. The PolyForm Shield restricts competitors from using your code. The Responsible AI License (RAIL) adds behavioral restrictions on AI use. Some projects are experimenting with clauses that explicitly prohibit feeding code into training datasets: you can use my code, but you can't feed it to a model that will help your users bypass me entirely.

Whether these licenses will hold up in court is untested. But the fact that they're emerging tells you something. When maintainers start lawyering up, the community era is over. The solo maintainer doesn't have Redis's resources to pivot. They either stop, or get acqui-hired by the companies that need their work.

The twist nobody sees coming

Here's the thing that makes this hard to see clearly: open source looks healthier than ever from the outside.

Corporate open source output is actually increasing. Meta open-sources PyTorch and Llama to commoditize the AI stack and set the standards others build on. Google does the same with Kubernetes and Go. AI labs publish model weights so the ecosystem locks into their formats. More code than ever is landing in public repos.

But the word "open" is doing a lot of heavy lifting. These projects are strategic assets with public URLs. There's no community, just suppliers and consumers. Linux, curl, PostgreSQL get funded not because people care, but because they're supply chain dependencies (professionalized maintainers on corporate payrolls, a trend building for over 20 years). The corporate-backed projects were never communities to begin with.

Open source isn't dying. It's being industrialized. The old open source was a community. People showed up because they cared. They contributed because they were proud. They maintained because they were recognized. The economics were messy and implicit, but they were human. The new open source is a supply chain.

What's left

I've been in open source for over 20 years. The thing I loved about it was never the code. It was the bug reports that turned into conversations. The patches from strangers who cared. The feeling of building something together that none of us could have built alone.

Some will argue AI lowers the barrier to contribute, that agents filing PRs and writing docs keeps the ecosystem healthy. Maybe. But a pull request from a bot isn't the same as a patch from someone who cared enough to read your code and understand your design. The mechanical contribution survives. The human connection doesn't.

The open source that comes next will produce good software. Maybe even better software, once infrastructure gets properly funded and AI tooling matures. But it'll be lonelier. More transactional. Less weird.

The code will keep flowing. The community won't.

Open Source Is Getting Used to Death

Tue, 17 Feb 2026 00:00:00 GMT

Tailwind CSS is more popular than ever. Downloads keep climbing. Developers love it. AI coding assistants recommend it constantly.

Its creator, Adam Wathan, says documentation traffic is down 40% and revenue has dropped close to 80%. He laid off 75% of the team last month.

That's the state of open source in 2026. More usage, less everything else.

The deal nobody signed

Open source always ran on an implicit deal: I share my code, you engage with it. You read the docs, file bugs, sponsor the project, contribute patches, argue about API design. That engagement was the currency that kept the ecosystem alive.

The deal was already fraying. Nadia Eghbal documented this in Working in Public back in 2020: the ratio of consumers to contributors was already thousands to one. Most users never filed a bug, never sponsored anything, never showed up. Maintainers were burning out long before AI arrived.

But AI didn't just accelerate the decline. It changed the structure.

When Claude writes your Tailwind classes, you never visit the docs. When Copilot autocompletes your curl flags, you never read the man page. When an AI agent assembles your project from a dozen open source libraries, none of those maintainers see a download page visit, a GitHub star, or a support ticket.

The code still flows. The engagement doesn't.

Two channels, one winner

Koren, Békés, Hinz, and Lohmann lay this out in "Vibe Coding Kills Open Source", a paper that models two competing forces. AI makes it cheaper to build software — more projects, better code, the flywheel that grew open source for 30 years spins faster. But AI also means users interact with open source through a proxy. They get the value and skip the engagement. Maintainers lose the revenue, reputation, and feedback that justified sharing code.

In the short term, both forces are at work and the good one wins. Long-term, diversion dominates. The flywheel starts running in reverse.

For 30 years, the cycle looked like this: a maintainer shares a library. Developers use it, read the docs, file bugs, sponsor it. The maintainer gets revenue, reputation, and feedback — keeps improving. More developers adopt it. The cycle reinforces itself.

The virtuous cycle that sustained open source for 30 years

Now the loop runs in reverse. A maintainer shares a library. AI agents use it, but users never visit the docs, never file issues, never sponsor the project. Revenue drops. The maintainer burns out and stops maintaining. Developers who need that functionality ask an AI to build it from scratch. That generated code never gets shared back — why would it? And the next maintainer looking at the economics thinks: why bother sharing mine?

The same loop — until it isn't

Each turn of the cycle is rational. No one's doing anything wrong. But the collective result is an ecosystem consuming itself.

The data is already there. Stack Overflow lost 25% of its activity within six months of ChatGPT launching — and yes, SO was already declining, but AI cratered the curve. The curl maintainer reports that 20% of security vulnerability reports are now AI-generated garbage. Downloads go up. Everything that matters goes down.

The economics of extraction

When cloud providers started offering open source as a service (the "AWS problem"), maintainers at least knew who was extracting value. You could negotiate. You could change your license. You could build a competing hosted product. You could fight it.

AI extraction is painless — and that's what makes it lethal. Nobody feels like they're taking anything. A developer asks Claude a question, gets working code, ships it. The value flows out of open source into training data, into autocomplete suggestions, into vibe-coded projects — and nobody involved ever knows your name. It's not theft. It's evaporation.

The paper puts numbers to it: to sustain open source at current levels, you'd need each user to pay roughly what they pay now. But the whole point of AI-mediated usage is that per-user engagement drops to near zero. The math doesn't work.

What the economists miss

The paper leaves out the part where developers do things because they want to, not because they get paid. It acknowledges this blind spot.

I've spent over 20 years in open source — Debian, awesome window manager, GNU Emacs, OpenStack, Mergify — and the economics were never the whole story. A lot of open source ran on ego. And I mean that as a compliment.

You started a project because you were proud of what you built. You maintained it because people used it and told you it was good. You contributed to someone else's project because it felt meaningful to be part of something bigger. The reputation, the GitHub profile, the conference talks — that was the fuel.

AI erodes that too. When your library is consumed by a model that never credits you, the ego fuel dries up. Nobody's filing issues saying "great work on this API." Nobody's writing blog posts about your clever design decisions. Your code is in millions of projects and you'll never know.

Michael Still maintained pngtools for 25 years and recently admitted he "can't really explain what I got in return apart from the occasional dopamine hit." That's not bitterness — it's an honest accounting of what happens when the feedback loop never closes.

The rebuild reflex

Anthropic built a C compiler with Claude. OpenAI built a web browser. This is what happens when development costs collapse.

The obvious objection: generating code isn't maintaining code. curl works because of 20 years of edge cases, security patches, and platform quirks. You can't generate that in a weekend. True — but the line between "writing" code and "maintaining" code is blurrier than it looks. Every line you write immediately becomes maintenance. AI doesn't just generate the first draft — it fixes the bugs, handles the edge cases, iterates on the patches. The entire lifecycle gets cheaper, not just the initial build.

Five years ago, nobody in their right mind would build their own HTTP server, their own date parsing library, their own compression algorithm. You used the shared one because the alternative was insane.

The alternative is no longer insane. It might be a weekend project.

Where this leaves us

Some of this is happening right now. The Tailwind numbers are a Q4 report. Stack Overflow's decline is measured. The curl maintainer is drowning in AI-generated noise today. Some of it is projection — I'm betting that the diversion effect gets stronger, not weaker, as AI gets better. I could be wrong. But the trend lines all point the same way.

"But AI also contributes!" Sure. Agents file PRs, generate docs, triage issues. That helps with the mechanical work. It doesn't replace the human who cared enough to read your code and tell you it mattered. The engagement that sustained open source was never about the pull requests — it was about the people behind them.

Open source isn't dying because people stopped caring. It's dying because AI lets people extract all the value without returning any of it. The code flows through models, through agents, through autocomplete — and none of it flows back.

The question isn't whether this is happening. It's what comes next.

Part 2: Open Source After the Extraction

How Entire Works Under the Hood

Thu, 12 Feb 2026 00:00:00 GMT

In part 1, I covered why Entire raised $60M and what problem they're solving. Now let's look at the actual code.

I pointed Claude Code at Entire's open source CLI and asked it to explain how things work. The architecture is more interesting than I expected — they've essentially built a session-aware metadata layer on top of git using nothing but git's own primitives.

The Big Picture

Entire hooks into two things: your AI agent (Claude Code, Gemini CLI) and git itself. The agent hooks capture what's happening during a session. The git hooks capture what the developer commits.

Agent hooks (Claude Code)         Git hooks
  SessionStart                     prepare-commit-msg
  UserPromptSubmit                 post-commit
  Stop                             pre-push
  PreToolUse / PostToolUse
         │                              │
         └──────────┬───────────────────┘
                    │
            ┌───────▼────────┐
            │   Strategy     │
            │                │
            │ SaveChanges()  │
            │ Rewind()       │
            │ Condense()     │
            └───────┬────────┘
                    │
         ┌──────────┴──────────┐
         │                     │
    Shadow branches      Metadata branch
    (local, temp)        (shared, permanent)
    entire/<hash>        entire/checkpoints/v1

How Agent Hooks Get Installed

Running entire enable writes hook entries into .claude/settings.json. Seven hooks, covering the full session lifecycle:

SessionStart/SessionEnd — track session boundaries
UserPromptSubmit — fires before the agent starts working (captures human edits)
Stop — fires after the agent finishes a turn (triggers checkpoint save)
PreToolUse/PostToolUse[Task] — track subagent spawning
PostToolUse[TodoWrite] — capture task state

Each hook is just a shell command: entire hooks claude-code stop. The CLI parses the agent's transcript to extract everything it needs.

The Transcript Is the Source of Truth

This is the key insight. When the Stop hook fires, Claude Code passes two things via stdin: a session_id and a transcript_path. That transcript — the JSONL file where Claude logs every message, tool call, and response — is the single source of truth.

The CLI mines it for:

Modified files — scans for tool_use blocks where the tool is Write, Edit, etc., and extracts the file_path
User prompts — finds type: "user" entries
Token usage — sums input_tokens, output_tokens from response metadata
Summary — grabs the last assistant message

No magic, no APIs. It just reads the same JSONL file that Claude Code writes to disk.

Shadow Branches: Snapshots Without Commits

Here's where it gets clever. When the agent finishes a turn, Entire needs to save a snapshot of the working tree. But it can't commit to your branch — that would mess up your history.

So it creates shadow branches: refs like entire/2b4c177-a5e3f2 that live in your local repo but never touch your working branch.

The name encodes two things:

2b4c177 — first 7 chars of HEAD when the session started
a5e3f2 — hash of the worktree ID (to support git worktree)

The snapshot is built entirely in memory using go-git's plumbing APIs:

Take HEAD's tree (the full repo structure)
Apply the agent's changes (add/remove/modify blobs)
Attach the metadata directory (.entire/metadata/<session-id>/)
Create a commit on the shadow branch

No checkout, no stash, no visible side effects. The user and agent don't even know it happened.

Deduplication is automatic: if the tree hash matches the previous checkpoint, it skips the commit. Git's content-addressable storage means identical files share blobs across checkpoints.

The Condensation Model

Shadow branches are local scratch space. The real metadata lives on entire/checkpoints/v1 — an orphan branch (no common ancestor with your code) that's pushed alongside your regular branches.

The flow:

Agent works → checkpoints saved on shadow branch (local)
You commit → post-commit hook fires
prepare-commit-msg adds a trailer: Entire-Checkpoint: a3b2c4d5e6f7
Shadow branch data gets condensed — copied into the metadata branch
Shadow branch gets cleaned up

The checkpoint ID (a3b2c4d5e6f7) is 6 random bytes, not a git SHA. It's sharded into a directory path on the metadata branch:

entire/checkpoints/v1  (orphan branch)
└── a3/b2c4d5e6f7/
    ├── metadata.json          # summary, attribution, token usage
    ├── 0/
    │   ├── full.jsonl         # complete session transcript
    │   ├── prompt.txt         # user prompts
    │   └── context.md         # generated context
    └── 1/                     # additional sessions if any

That one-line trailer in your commit — Entire-Checkpoint: a3b2c4d5e6f7 — is the bidirectional link. From the commit you find metadata via the sharded path. From the metadata you find the commit by searching for the trailer.

Attribution: Who Wrote What?

This is the piece that matters for engineering leads. Entire tracks line-level code attribution: what percentage was agent-written vs. human-written.

The trick is the UserPromptSubmit hook. Every time you type a new prompt — before the agent starts working — the CLI snapshots the worktree diff against the last checkpoint. This captures exactly what you changed between agent turns.

By commit time, it has:

Agent lines: changes from the last checkpoint's tree
Human added: lines you added between prompts
Human modified: lines you edited in agent-written code
Agent percentage: the ratio

The result is stored in initial_attribution in the metadata:

{
  "agent_lines": 150,
  "human_added": 25,
  "human_modified": 10,
  "agent_percentage": 85.7
}

It even uses a LIFO heuristic for self-modifications — if you add lines then remove lines from the same file, it assumes you're removing your own first, not penalizing the agent's contribution.

Multi-Developer: Conflict-Free by Design

The metadata branch gets pushed during git push (via the pre-push hook). Multiple developers push to the same entire/checkpoints/v1 branch.

This works because checkpoint IDs are random — two developers will essentially never produce the same 12-hex-char ID. Merging is just a tree union: flatten both trees, combine entries, done. No merge conflicts possible.

If a normal push fails (non-fast-forward), the CLI fetches the remote, merges trees, creates a merge commit, and retries.

What's Missing

The architecture is solid engineering, but a few things stood out:

Transcript privacy. Session transcripts (full agent conversations) get pushed to a branch anyone with repo access can read. For private repos, maybe fine. For orgs with varying access levels — that's a problem.

Squash merges break links. If a PR with 5 commits (each with Entire-Checkpoint trailers) gets squash-merged, those trailers disappear. The metadata exists but the bidirectional link from the merged commit is broken.

The metadata branch grows forever. Every session from every developer, including abandoned PRs and throwaway experiments, accumulates on entire/checkpoints/v1. There's an entire clean command for local shadow branches, but no retention policy for the permanent metadata. For a large team over months, that'll bloat.

No PR linkage. The branch name is stored, but there's no PR number or URL. You can't easily ask "show me all sessions related to PR #42."

The Smart Parts

What I genuinely admire:

Git as a free database. Shadow branches store full repo snapshots, but git's content-addressable storage means only changed blobs cost anything. You get atomic snapshots, deduplication, and transport for free.

In-memory tree building. Checkpoints are created through go-git plumbing APIs — no worktree checkout, no stash, nothing visible. Zero disruption to the developer's flow.

Attribution at prompt boundaries. Capturing human edits before the agent contaminates the worktree is the cleanest measurement point possible.

Shadow branch migration. If you rebase or pull (HEAD changes), the shadow branch name automatically updates. Your session continues seamlessly. This handles a common workflow that would otherwise silently break.

So What?

Entire doesn't solve a burning problem today. Most of us are fine with agent-written code landing in our repos without detailed provenance. But the trajectory is clear: as agents write more code, the audit trail becomes essential.

The approach of storing session context alongside code in git — rather than in a separate system — is the right architectural bet. Git is already where your code lives, where your CI runs, where your reviews happen. Adding a metadata layer inside git itself (instead of a SaaS dashboard somewhere) means the context travels with the code.

Whether Entire is the company that turns this into a platform worth $300M is above my pay grade. But the engineering is genuine, the problem is real, and the timing feels right.

I'll be watching.

Agent-Written Code Needs More Than Git

Wed, 11 Feb 2026 00:00:00 GMT

The former GitHub CEO just raised $60M at a $300M valuation for a seed round. For a CLI tool. Let that sink in.

Thomas Dohmke left GitHub and launched Entire, a developer platform built from scratch for the age of AI coding agents. It's the largest seed round in dev tools history.

My first reaction was "that's insane." My second reaction was "wait, I've been solving the same problem with duct tape and hooks."

The Problem Is Real

If you're using AI agents like Claude Code or Gemini CLI daily — and I am — you've already felt it. Git was built for humans writing code. It assumes you know what you changed and why. It assumes your commit messages mean something. It assumes the person who wrote the code will remember what they were thinking.

AI agents break all of that.

When Claude Code rewrites a module for me, the commit message says what happened, but not why. There's no trace of the conversation that led there. No record of the three approaches the agent considered and rejected. No way to know if the prompt was "refactor this for clarity" or "make this 10x faster and I don't care about readability."

The transcript — the actual reasoning behind the code — lives in a terminal session that vanishes when you close the tab.

My Duct Tape Solution

I ran into this a few weeks ago when I wanted to resume a Claude Code session after a reboot. The session was gone, and I had no idea what context the agent had when it made certain decisions.

So I did what any engineer would do: I wrote a hook. A simple Claude Code hook that links each commit to its session ID via a git trailer. Nothing fancy — just enough that I can trace a commit back to the conversation that produced it.

Combined with Mergify's CLI for stacking PRs, it made my workflow usable. But it's duct tape. It doesn't capture the transcript, doesn't track attribution, doesn't handle multi-session work.

Which is exactly the gap Entire is going after.

What Entire Actually Claims to Be

Beyond the buzzwords in the press release, Entire is shipping three things:

Checkpoints — an open source CLI that captures session context (prompts, transcripts, reasoning) alongside every commit, stored in git without polluting your history
A semantic reasoning layer — meant to let multiple AI agents collaborate on the same codebase with shared context
An AI-native UI — designed for agent-to-human collaboration rather than human-to-human

They're not claiming to have a finished product — and they're upfront about it. The Checkpoints CLI is the first concrete thing they've shipped, and it's open source. The rest is where the $60M goes. Fair enough — let's look at what actually exists.

Why $60M for This?

The bet isn't that the current CLI is worth $300M. The bet is that the developer tooling stack needs to be rebuilt for a world where most code is written by agents, and the first company to nail the foundation wins.

Think about it: if 99% of code is agent-written in two years (which is where things are heading), then the code review, debugging, and understanding workflow we have today is fundamentally broken. You can't review AI-written code the same way you review human-written code. You need the context — what was the agent trying to do, what constraints did it have, what alternatives did it consider.

That's a platform opportunity, and $60M is the price of a credible attempt at it. Whether Entire is the one to build it is a different question — but the problem is real and urgent.

My Take

Dohmke knows exactly where GitHub's limits are (he ran it). The investor list — Felicis, Madrona, Olivier Pomel — signals real conviction. And the core insight, that agent context is as important as the code itself, is something I believe in my bones because I've been hacking around it myself.

Their long-term ambition seems to involve moving beyond git. I'm more dubious about that part. Git is unkillable. My bet is that the reality will be hooks and duct tape around git for the next few years — and honestly, that's probably enough. Git's data model bends a lot further than people think before it breaks.

There's a deeper tension, though. Entire's model assumes humans are still in the loop — driving agents, reviewing output, caring about attribution. But that's already not quite how it works. I haven't written a line of code in months. I describe what I want, the agent writes it, I tell it to fix its mistakes, and it does. I'm not a developer anymore — I'm a director.

And the trajectory is obvious: agents won't need directors much longer either. If agents are fully autonomous, who's the audience for commit context and session transcripts? The agent doesn't need to remember what it was thinking — it can just re-derive it. The human who never touched the code doesn't need line-level attribution.

That could go either way for Entire. Maybe full autonomy makes provenance more critical — precisely because no human was involved, you need a machine-readable audit trail. Or maybe it makes the whole problem vanish — agents that manage their own context don't need git hacks to preserve it.

Either way, if you're leading an engineering team right now, you should be thinking about how you'll audit, understand, and trust the code your agents produce — whether there's a human in the loop or not.

Next up, I'll dig into the actual source code and show you how Entire's Checkpoints CLI works under the hood. It's a clever piece of engineering that abuses git internals in ways I genuinely admire.

So I Will Never Write Code Again

Tue, 10 Feb 2026 00:00:00 GMT

A year ago, I thought AI-assisted coding was going to be a nice productivity boost. Generate a Python script with ChatGPT, copy-paste it somewhere, save twenty minutes. I figured that was the next five years: small wins, gradual improvement.

Then last August, I wrote a feature where Copilot did about 80% of the work. I thought: okay, it's getting closer.

Since January, I haven't written a single line of code.

I want to be precise: I've produced a lot of code. More than ever, probably. But I didn't write any of it. I steer. I review. I architect. I don't type.

And I don't feel the urge to go back.

This might sound like grief. I've been coding for 25 years. I wrote C for a window manager, Lisp for Emacs, Python for everything else. For most of my career, coding was a thing that defined me. Losing that should feel like losing a part of myself.

But it doesn't. It feels like relief.

For years, I was frustrated. I had more ideas than I could build. The bottleneck was never thinking, it was typing. Translating architecture into syntax, aligning parentheses, naming variables, fighting linters. The fun was in the solving, not the writing. And now the writing part is handled.

I still enjoy reading code. It's like reading a good book. Understanding how pytest works internally, tracing through a complex system, that remains satisfying. But when the goal is to produce, AI beats everything.

This is actually the second time I've stepped away from code. The first was when I became CEO. That time, it was forced. I didn't choose to stop. I just ran out of hours. There was always one more meeting, one more hire, one more decision that pushed coding to the evening, then to the weekend, then to never.

That was grief. A slow, reluctant surrender.

This time is different. I'm not being pushed away. I'm choosing to work at a higher layer. The same way I once chose Python over C, because life is short and the abstraction was worth it. AI is just the next rung.

The creativity doesn't stop. If anything, it accelerates. You still design systems, still make architectural choices, still think about data models and trade-offs. You just don't spend hours translating those decisions into semicolons. The craft moves up a level, and that's fine.

I know this will be harder for others. My colleague Rémy wrote about whether AI is killing craftsmanship. For engineers who defined themselves by the elegance of their code, by the perfectly named function, by the satisfaction of a clean diff, this shift feels like losing something sacred.

I get it. Writing C was a beautiful puzzle. Lisp was genuinely fun. And I still think learning to code by hand matters, the same way learning assembly helps you understand memory even if you never write it professionally.

But I'm not going to fight a paradigm shift out of nostalgia. The ride was great. The next one looks better.

I think the flow state people mourn isn't gone. It's just moving. Steering AI toward clean architecture, making the right system-level decisions, reviewing output with deep context, that has its own rhythm. The interruptions are still too frequent today (too many permission prompts), but the direction is clear. The flow will come back. It'll just be at a different altitude.

If you're a senior engineer feeling this shift approaching, here's what I'd say: the grief you're expecting might not be grief at all. The bottleneck was never the thinking. It was the typing. And the thinking is still yours.

The Pre-AI Timestamp

Thu, 29 Jan 2026 00:00:00 GMT

I was watching the news this week. A segment about AI-generated fake videos of snowstorms in the US and Russia. Journalists carefully debunking synthetic footage, frame by frame.

AI generated image

I thought: this won’t scale.

Right now, we’re in a strange transitional moment. People can still tell the difference between AI-generated content and reality. We spot the weird hands, the uncanny smoothness, the details that don’t quite land. News organizations debunk fakes. We feel like we’re staying ahead of it.

But this is temporary. In a year or two, AI-generated video will be indistinguishable from real footage. And then what?

Here’s what I think people aren’t grasping: the challenge isn’t “how do we detect AI content?” That’s the 2026 problem. The real challenge is what comes after, when detection becomes impossible.

The only way I know Coldplay is a real band is that they existed before AI did. I have pre-AI memory. I remember when they started. I’ve seen them referenced in media that predates synthetic content. That history is my anchor.

Now imagine a new band starting in 2030. How would I know they’re real? Unless I go to their concert and see them on stage, I can’t. Their music could be generated. Their interviews could be synthetic. Their social media presence could be entirely fabricated. There’s no way to verify.

And when I say I go, I mean me. I can’t trust anyone online that I don’t know personally. There won’t be a way for you to know if you’re talking to a real human via a computerized interface in a few years. Your online friends could be AI for what you know.

This applies to everything. An influencer recommending restaurants. A journalist breaking news. A newsletter you just discovered. If it started after AI became indistinguishable, you have no anchor. You can’t know.

And this is something most people can’t grasp today because they lived in the pre-AI era, and they have this anchor. Future generations won’t have it.

We’ve already lived through a version of this with fake reviews. For the last decade, we’ve learned to distrust Amazon ratings, Yelp scores, app store reviews. We developed heuristics. We looked for patterns.

But that was humans writing fake reviews at a human scale. Now imagine AI generating reviews at a scale we can’t comprehend. Every product, every restaurant, every service flooded with synthetic opinions indistinguishable from real ones. The heuristics break. Trust collapses.

The same thing will happen to media, to news, to social networks, to everything online. AI feels like 1999 all over again — except this time, the divide isn't access. It's whether you can tell what's real.

A lot of trust today is based on consensus. We trust something because many people trust it. But when bots can outnumber people, consensus becomes meaningless. Popularity becomes a metric that anyone can manufacture.

So what’s left?

Physical presence. Meeting someone in person. Attending a concert. Being there.

Real life becomes the last trust anchor. The thing that can’t be faked (at least until humanoid robots become indistinguishable too, but that’s a problem for later).

Here’s what haunts me: in two generations, no one alive will remember what was pre-AI. The generational memory dies. A teenager in 2050 won’t know that The New York Times existed before AI and is therefore trustable because run by humans (I can imagine it’d still be the case). They won’t have the anchor I have. Everything in their world will be post-AI, and nothing online will be verifiable.

They’ll have to assume everything is fake. That’s the default. And building trust from that baseline is something we’ve never had to do before.

I don’t have a solution. But I think we’re in a narrow window where we still remember what “real” meant. That memory is more valuable than we realize.

AI Won’t Kill Juniors. It Will Expose Seniors.

Wed, 21 Jan 2026 00:00:00 GMT

The tech industry has a new consensus: AI will kill junior engineering jobs. Look at any discussion thread, and you’ll find the same narrative. Juniors are doomed. They’ll never learn to code properly. The entry-level pipeline is broken.

I’m not so sure. When I look at junior engineers today, I see people who are used to learning. They came up through boot camps, YouTube tutorials,and constantly shifting frameworks. Adapting is what they do. They might struggle for a year or two, but they’ll figure it out.

The engineers I’m worried about are the senior ones.

Sure, not all of them. But the ones who plateaued at “code craftsman” and never moved up.

I’ve seen it play out already. A standup where someone proudly reports they spent the day fixing a batch of bugs and shipping a couple of pull requests. The rest of the team glances at each other. They’re thinking: *that’s ten minutes of Claude Code. Why did you spend eight hours in your IDE?*

This isn’t new. We’ve seen it before. When bash gave way to Perl. When Java replaced C for most applications. Every paradigm shift leaves some people behind. Maybe 10%, maybe 20%, clinging to the old way because it’s what they know.

But AI is different. The shift is faster. The impact is more massive. And the reach is exponential.

Here’s the pattern I see. When I started programming, you’d learn assembly. Then you’d switch to C because life is short. Then Python, because life is really short. Each jump felt like cheating to the previous generation, and each one freed you to think at a higher level.

AI is the next rung on that ladder. I hope schools are teaching this now: learn to write code by hand first (you need to understand what you’re abstracting), then switch to AI-assisted development. Just like you learned assembly to understand memory, then moved on. Though knowing how slow institutions adapt, I’m not holding my breath.

The engineers who get this are thriving. Staff engineers, principal engineers, people whose job was already 70% architecture, cross-team coordination, and system design. They only coded 30% of the time anyway. Now they use AI to multiply that 30% and have even more impact. For them, AI is a force multiplier on an already leveraged role.

But there’s another group. Senior engineers, five to ten years in, who still think their job is writing code 90% of the time. They never thought deeply about data models. Never cared much about architecture. Never moved toward the work that would make them staff or principal.

Their entire value was "writing proper, clean code that runs well and passes the linter." They never invested in the skills that make a great software engineer — communication, system thinking, judgment.

That value just evaporated.

And here’s what makes it worse: working with AI is fundamentally communication work. The engineers who thrive are the ones who already know how to share context, explain problems to colleagues, and filter signal from noise across teams.

I’ve watched engineers struggle with AI because they won’t invest in communication. They type “fix this bug” without the stack trace, without the constraints, without explaining how production differs from their local setup. They keep the context in their head because explaining feels costly. The result is garbage, and they blame the tool.

What they don’t see: AI compounds. The more context you feed it about your project, the better it gets. But that requires upfront investment in articulation. If you spent your career avoiding that investment with humans, you’ll prevent it with AI too.

I don’t have a clean solution. The engineers who won’t adapt will stagnate. They might find work in industries that are slow to change. But it won’t be a great career. It never is when you’re holding onto the last paradigm.

The engineers at risk aren’t the ones who don’t know enough yet. They’re the ones who stopped growing at the wrong layer. Juniors will climb. The question is whether the seniors stuck in the middle will climb with them.

The Future Is Being Built Elsewhere

Wed, 26 Nov 2025 00:00:00 GMT

I read Pierre Chapuis’ post Inexorable Progress last week, and a line stuck with me:

“You cannot stop the flow of progress. You can only decide to be an innovator, an early adopter, or a laggard.”

He’s right. And if you work in tech in Europe, you feel it every day: in the conversations, in the pace, in the mindset, in the decisions people around you consider “reasonable.”

I live in France. I build a global product. I talk to US companies daily. And honestly?

I’m worried too.

Not because we lack talent. We don’t.

Not because we lack engineers. We don’t.

But because we lack the mental model required to compete in the world we’re entering. And the gap is accelerating.

We Think We’re in the Same Race. We’re Not.

When I look at what’s happening in the US and China in AI, SaaS, robotics, automation… it feels like watching a different timeline.

They’re scaling models that can refactor codebases.

They’re shipping companies that go from idea to revenue in weeks.

They’re pushing robotics into homes.

They’re pouring capital at a pace that dwarfs what Europe raises in a quarter.

Meanwhile, in France:

We think regulation is a moat.
We believe “solving the French market” is a global strategy.
We look at the US and assume “we’ll catch up later.”
We treat AI like a temporary trend we can ignore until it stabilizes.

This isn't a mindset gap. It's a timeline gap. AI feels like 1999 all over again — the behavioral divide between adopters and holdouts is already compounding. And Europe is overwhelmingly on the wrong side.

Europe is acting like it has time. It doesn't.

The Most Dangerous Bias: Thinking France Is the World

When I hear founders say:

“We’ll win the French market first.”

I always think: France is 0.8% of the world’s population.

0.8%.

China is 20× bigger. The US tech market is 10× bigger.

The next wave of software will not be built for 0.8%.

If your plan is to build only for France, culturally, financially, technically, you’ve already chosen to lose.

Not because you’re bad.

But because you’re playing a local game while everyone else is playing planetary-scale chess.

The Mindset Problem Nobody Talks About

Here’s the part that founders and engineers will immediately recognize:

Most people here fundamentally don’t understand ROI, time, capital, or scale.

They understand tasks. They understand constraints. They understand regulation.

But they don’t understand leverage.

They want to “optimize costs” when the problem is growth.

They want to “avoid risk” when the problem is irrelevance.

They want to “comply first” when the problem is competing at all.

This is why hiring is more complex here, why product velocity is slower. Why teams hesitate on AI adoption, just as they did with cloud in 2008.

It’s not a technology gap.

It’s a worldview gap.

We’re Living Like a Rich Country Without Creating Enough Value

This part is uncomfortable, but founders feel it viscerally.

For 50 years, France has lived on increasing debt and the assumption that we can keep funding our lifestyle without producing equivalent value.

But look at our major industries:

Our car industry is fighting Brussels just to be allowed to sell pollution past 2035, not to compete.
Our energy leadership was squandered by 20 years of indecision.
Our tech ecosystem celebrates being five years behind the US, as long as it’s “sovereign.”

If we stop exporting cars, software, tech, heavy industry, how do we pay for everything?

How do we fund innovation? How do we stay competitive?

We don’t.

We shrink.

We tax more.

We lose ground.

And we pretend everything is fine.

Dropping Out of the Race Isn’t Ethical — It’s Surrender

When Pierre wrote:

“If you slow down, you are simply letting those who do not care about these issues in the first place win.”

That hit me hard.

Because this is the mindset I see too often in Europe:

“We shouldn’t build this.”

“We should regulate it.”

“We should wait until we’re sure.”

“We should be cautious.”

Caution is fine.

Except when you’re in a race you didn’t choose but cannot opt out of. You don’t get to be “ethical” by refusing to play.

You just hand the steering wheel of the future to people who don’t share your ethics.

What Founders Should Take Away

I’m not writing this to doomscroll. I’m writing this because founders and engineers need to hear one thing:

Build globally. Don’t wait for permission.

The world is not waiting for Europe to catch up. The next decade will be brutal for anyone playing local games. Whether we like it or not, the next wave of innovation will be:

AI-native
global from day one
capital-efficient
ruthlessly fast
engineered by people who want to win, not just exist

And we can be part of that — if we choose to.

Closing

I love France. I live here. My kids grow up here. But love doesn’t blind me.

I see the same thing Pierre sees:

A continent with world-class talent… and a mindset preventing it from playing the actual game.

I don’t have the solutions. But I see the problems clearly. And as entrepreneurs, our best chance isn’t waiting for a savior.

It’s building, ambitiously, globally, unapologetically, before the gap becomes irreversible. Because the world is moving.

And this time, if we hesitate, we’ll be spectators. Not players.

AI feels like 1999 all over again

Thu, 06 Nov 2025 00:00:00 GMT

Last week, I spent two days with an old friend. We’ve known each other for fifteen years. He’s curious, a bit of a geek, but not “in tech.” He doesn’t use GPT. His wife doesn’t either. They’ve heard of AI the way you hear of a new restaurant: name recognition, no bookings.

We talked, we cooked, we compared notes on work. At some point, I realized we were living on different planets. Not values. Toolchains.

He does great work. But AI just… isn’t part of his day. Meanwhile, I use it constantly: as a writing partner for emails, a sounding board for product decisions, a junior PM, a marketing intern who never sleeps. It’s not magic. It’s just leverage. And it reminds me of when I got internet access twenty-five years ago and people said, “Why would you need that every day?”

Two decades later, we answer that question by reflex, usually from a phone.

I don’t say this to flex. I say it because the gap is already visible.

If I compare my work today to two years ago, I’m doing two to three times more with better output. Same hours. Less context switching. I can hold more of Mergify’s product in my head, ship faster, and still write the marketing we used to split across two people. I wouldn’t claim I replace a whole team (let’s keep our illusions calibrated) but one founder plus AI now feels like one founder plus a sharp apprentice who learns absurdly fast.

And I’m still only scratching the surface. There are tasks I should automate that I haven’t, because of the classic XKCD curve: spending an hour to save a minute. The ROI is real; the overhead is too. It will get smoothed out, like everything else that starts out lumpy.

XKCD 974

What’s striking is not just the productivity jump. It’s the new behavioral divide. Twenty years ago the divide was access: who had broadband and who didn’t. Today the divide is adoption: who’s willing to put these systems in the loop every day, and who keeps them at arm’s length.

Same laptop. Same calendar. Wildly different output.

This isn’t about “AI replacing jobs.” It’s about AI reorganizing work around people who are willing to collaborate with it. The difference between “I don’t see the point” and “this is in my daily loop” already compounds in quiet ways:

The email you write in 7 minutes instead of 27.
The product spec with five explored options instead of two.
The marketing page that results from testing three angles instead of arguing for one.
The code you ship because the blank page wasn’t blank.

Multiply that by days, then by years. That is how careers and companies diverge. And once AI starts creating content at scale, not just assisting — the synthetic wave is already here — the gap widens even faster.

Of course, there are limits. AI isn’t judgment. It won’t hold your ethics, defend your taste, or choose your strategy. You still have to decide what “good” means, define constraints, and call the trade-offs. If you outsource your thinking, you don’t get leverage: you get noise.

But if you keep the steering wheel, the car is very fast.

There’s also a cultural point I didn’t expect: the stigma of using help. Some people still think “real work” means doing everything yourself. Same energy as hand-writing HTML in 2003 to prove you’re serious.

This reminds me of the latest post from Jean de La Rochebrochard where he talked about how French people are all about crafting. No wonder AI adoption is going to be a long road here.

But the craft isn’t in suffering; it’s in outcomes. Tools are honest if your goals are.

I don’t know precisely what the next twenty years look like. I do see the pattern. Early on, new technology looks optional, even irrelevant. Then someone quietly uses it to do three times more with the same time. Then we call it table stakes. The people who adopted early won’t be smarter; they’ll just have trained their reflexes sooner.

If you’re already all-in, you don’t need my sermon. If you’re AI-curious but unconvinced, try this: pick one workflow that hurts: a weekly email, a product spec, a marketing outline. Put an AI in the loop for a week. Not as a demo. As a colleague. Give it context. Ask for alternatives, not answers. Keep the steering wheel.

If after seven days it doesn’t save you time and improve your output, fine: ignore it for another year. But my bet is you’ll feel the old dial-up-to-broadband moment: once you touch the speed, it’s hard to go back.

Back in Toulouse, my friend and I didn’t resolve anything. We just noticed the split. Same age. Same curiosity. Different daily habits. Twenty-five years ago the web felt optional right up until it didn’t. I think we’re there again. The storm isn’t coming. We’re already in the rain. You can stay dry for a while. Or you can learn to dance in it.

Building Features One Prompt at a Time

Tue, 26 Aug 2025 00:00:00 GMT

A few weeks ago, we released a new feature at Mergify: autoqueue.

It automatically adds pull requests into the merge queue when they’re ready. No more custom automation rules, no more fiddling with YAML — it just works, straight from the merge queue settings.

Here’s the kicker: I coded it.

Yes, me. The CEO. The guy who hasn’t touched production code in years. The guy who usually spends his days on calls, not in GitHub.

And I did it in less than an hour a day, over three weeks, with the help of AI.

Why I Even Tried This

I’ve used Copilot casually before (mostly autocomplete in Emacs), but this time I wanted to go all-in.

Why? Curiosity, mostly. And time constraints. As a CEO, I have close to zero time to code, and this feature wasn’t urgent. So I thought: why not see what happens if I vibe-code it with AI?

How It Worked

The way I interacted with Claude 4 via GitHub Copilot was simple: I explained the feature like I’d explain it to my team in a product story. I added some technical constraints (“use unit tests, not functional ones”).

Then I let the AI go.

It just felt like coding blindfolded.

It wrote the code. I tweaked less than 5% of it. Once it was done, I sent it for review. I pasted my coworkers’ review feedback back into it. It rewrote. I guided. It iterated.

Did it nail it on the first try? No. Sometimes it forgot instructions. Sometimes it “lost context” after a few iterations and tried to reinvent the test setup it had already learned. That was frustrating — like explaining to a junior dev, except this junior dev has goldfish memory.

But eventually, it worked. The code was merged. Released. In production. Done.

What Surprised Me

I only changed about 5% of the lines myself.
Nobody on the team noticed it was “AI-coded.”
It handled six years of legacy code surprisingly well.
Two years ago this wouldn’t have been possible — the progress is insane.

What It Means

This isn’t about me playing engineer again for nostalgia. It’s about what’s coming.

The quality and quantity bar is about to rise dramatically. AI isn’t just autocomplete anymore; it’s co-construction.

You can ship faster. You can tackle features you don't fully understand at the start. You can guide at a high level and let the AI grind the details. A few months later, I took this even further — to the point where I stopped writing code entirely.

But it also raises new challenges. For instance:

How do juniors review AI-generated PRs?

How do teams trust code written by something that forgets your instructions after 10 turns?

(That’s probably another blog post.)

For now, though, I’ll just say this:

I vibe-coded a real feature into existence in less than an hour a day.

It felt like cheating. And I’m amazed.

The Em Dash Is Dead

Tue, 05 Aug 2025 00:00:00 GMT

I’ve always loved the em dash. It’s elegant. It’s useful. It lets you breathe in your writing—without having to deal with commas or (God forbid) parentheses.

Ten years ago, I wrote a book. A real book. With my hands.

Serious Python

Over 68,000 words—and 77 beautiful em dashes.

I wasn’t counting then—only recently did I check. You know, just to see how robotic I might’ve accidentally been.

Because now? Now the em dash is a red flag.

A decade ago, it was just a punctuation mark. Today, it’s basically a biometric marker for ChatGPT. Type an em dash on the internet in 2025, and someone will immediately side-eye your prose like you’re a prompt engineer trying to slip one past them.

“Nice try, OpenAI.”

Somehow, without even trying, I joined the ranks of the suspicious. My past self—the one tapping away joyfully, dashing away without care—was unknowingly building a future case against me.

So here I am. A human. Who’s written thousands of human words. Who once thought the em dash was peak form—and now has to ask:

Am I even allowed to use it anymore?

The tragedy is this: AI didn't invent the em dash. We gave it the em dash. We trained it on our books, our blog posts, our essays. We fed it so much em dash-laced content that now it thinks it's just what humans do. And to be fair… it was. It's just one more way AI is reshaping how we communicate — and as social platforms collapse under synthetic content, even punctuation becomes a trust signal.

Now, AI refuses to stop.

You can threaten it, prompt it, scold it—“no more em dashes!”—and two lines later? Bam. Another one. It’s like trying to get your dog to stop barking at squirrels. It hears you. It just doesn’t care.

Meanwhile, actual humans are uninstalling their em dash keyboard shortcuts. Coders are deleting — from their HTML snippets. Writers are rephrasing perfectly good sentences just to avoid looking synthetic.

We didn’t lose a punctuation mark. We lost a friend.

So, if you see an em dash in my writing—don’t panic.

It’s not a bot. It’s just me. Old-school. Nostalgic. Typing with trembling fingers and a tear in my eye.

Still human.

Still grieving.

Still em-dashing.

The Synthetic Wave Is Already Here

Tue, 29 Jul 2025 00:00:00 GMT

Six months ago, I wrote a blog post titled “The Collapse of Social Platforms” At the time, it felt like a distant horizon — something you could see coming if you squinted into the future.

Spotify just made headlines for hosting an AI-generated “band” that racked up over a million plays before anyone realized the artists weren’t real. No humans. No guitars. Just prompts, algorithms, and a good understanding of how to feed the machine what people want to hear.

And that’s just the beginning.

Source

AI is Creating — Not Assisting

Back then, I wrote that we were moving past “AI-assisted” content into “AI-native” creation. At the time, it might have sounded like theory. Now, we’ve entered the Spotify Phase: platforms no longer just recommend content — they create it. They don’t need to wait for artists to upload music. They can fill the catalog themselves.

And they will.

Because the economics are too good, the data feedback loops are too tight, and the audience — most importantly — doesn’t seem to care.

The Illusion of Authenticity is Enough

Spotify didn’t advertise the AI band. It was just another artist profile. People listened. They added songs to playlists. They vibed. It’s only after the fact — after journalists started poking around — that we learned the truth.

And you know what? Most listeners still don’t care.

Which proves my original point: we’re not as attached to the source of content as we think we are. We just want something that feels good, fits our mood, and plays seamlessly into our day. If that comes from a human or an LLM fine-tuned on hit-making formulas… who’s checking?

This is the uncanny shift: content is becoming pure simulation. And for most, it’s indistinguishable from the real thing.

Platforms are Optimizing Away People

Spotify’s move is not an isolated event. It’s the canary in the coal mine for every content platform out there.

Why wait for a podcast to be recorded when you can prompt one into existence?
Why pay creators when you can generate infinite variations?
Why host unpredictable humans when you can manufacture predictable engagement?

From AI-generated OnlyFans personas to YouTube clones to fake influencers on Instagram, we’re entering a phase where content isn’t created by people — it’s created for people by machines pretending to be people.

It’s not a dystopia. It’s just a business decision.

So Where does This Leave Us?

If you’re a creator: The value of “real” is shifting. It may no longer be about production quality — but about human connection. Your face, your voice, your story might become the only proof-of-humanity people care about. Ironically, the more polished your content looks, the more people might question if you made it.

If you're a platform: Congratulations, you're entering the golden age of AI-powered margins. But beware the erosion of trust. Once users start doubting whether anyone on your platform is real, the social glue breaks down fast.

If you’re a user: Good luck. You’re about to be bombarded with synthetic everything. And the biggest risk isn’t being tricked — it’s not caring anymore whether what you’re consuming is real or not.

That’s when the simulation wins.

A Prediction, Revisited

In that original post, I wrote:

“Real life will be the only place you’ll have left to interact with real humans.”

I stand by it — even more today. The value of the human connection will rise in proportion to how rare it becomes online. Coffee with a friend. A live concert. A hand-written letter. These may become the luxury goods of the 2030s.

So yes, the synthetic wave is here. But maybe that’s what we needed — a reason to remember what being human online really means.

Until then: keep your eyes open, your ears sharp, and maybe… spend a little more time offline.

AI Is a Human Interface Nightmare

Tue, 08 Jul 2025 00:00:00 GMT

For the last 80 years, computers have been calculators. Fancy ones, sure — with screens, keyboards, networks. But under the hood, they’re still just deterministic machines. You give them input, and they process it with logic gates and silicon, and they spit out the exact same output every time. That’s the deal. That’s the contract.

And then came AI.

AI doesn’t work like that. At all.

AI — especially large language models — are not deterministic. They’re a soup of probabilities and neural weights. When you talk to an AI, you’re not talking to a computer. You’re talking to something more like a human brain: a machine that guesses, infers, hallucinates, and sometimes nails it. And sometimes doesn’t.

That’s fine. That’s expected. But the problem?

AI still runs on computers.

The interface hasn’t changed. We’re still typing on keyboards, expecting precise answers. We’re still clicking buttons, expecting repeatability. But AI doesn’t think like that. And so the human-AI interface is totally broken.

Ask ChatGPT “What’s the height of the Eiffel Tower?” and you might get the right number. Or not. And when it’s wrong, people freak out — “How can it not know that?” But think about it: the model is 1TB in size. It fits on a USB stick. You really believe all of humanity’s verified data fits in your pocket?

It's not Google. It's not Wikipedia. It's a brain. A tiny, weird, synthetic brain that talks to you via a command-line interface and autocomplete. And if we figure out the interface problem, AI could actually connect the dots in ways humans never could.

That’s the real nightmare: the medium is lying about the message.

We call them “smartphones” because we used to make calls with them — even though calling is now maybe 1% of what we do. The name stuck. And maybe we’ll keep talking to AI through keyboards and chatboxes. But eventually, we’ll need new metaphors. New expectations. New ways to interact.

Because what’s coming isn’t a better calculator.

It’s something else entirely.

Marc Chagall Never Painted That

Tue, 03 Jun 2025 00:00:00 GMT

It was a casual Friday. Nothing special—except I was on kid duty for lunch pickup, a rare detour in my usual routine.

As we strolled home, baguette under one arm, my daughter told me about her morning in class.

They had studied Marc Chagall. Her eyes sparkled as she recounted it, and then she asked if we could go see La Fée Électricité next time we were in Paris.

That name rang a bell, but I had no clue where that was exposed and if it was even in Paris. Painting is not my strong suit. Once home, I did what any responsible parent would do: I picked up my phone from my pocket and Googled it.

La Fée Électricité

The first answer showed that the painting was exhibited in the Musée d’Art Modern de Paris. But I didn’t tell my daughter right away. As I was scrolling on my phone, something didn’t click.

The museum mentioned that this painting was from Raoul Dufy — not Chagal.

I triple-checked on the web and Wikipedia. The result was the same. La Fée Électricité isn’t by Chagall at all. It’s really by Raoul Dufy.

That’s when the realisation hit me. The mistake probably didn’t come from a textbook or even a hasty Wikipedia glance. No, my bet is the teacher asked ChatGPT (or Bard, or whatever the tool of the week is) to prepare her lesson. AI probably hallucinated the answer. And nobody caught it.

We're at this weird moment where many people treat AI like it's a search engine. Or worse: as if it's a source of truth. And when this confidence gets applied at scale — to content, media, music — the synthetic wave is already here, and nobody is fact-checking it.

It’s not. It’s a conversation partner with infinite confidence and a shaky grasp on facts.

This isn’t a rant against AI. I use it daily and wouldn’t go back. But it’s a gentle reminder: if you don’t know how to question what it says—or double-check your sources—it’s easy to teach your whole class wrong facts.

No big deal this time. My kid went back to school in the afternoon after I dared her to ask her teacher if Chagal was really the painter behind La Fée Électricité. She did ask, and the teacher corrected her mistake for the whole class and moved on.

But next time, who knows?

The Collapse of Social Platforms

Tue, 17 Dec 2024 00:00:00 GMT

It’s the end of the year, so I’ll write about something more theoretical that has been on my mind those last few days.

What happens when the line between human and AI content creators vanishes completely? We’re closer to that reality than you might think.

I was out running a few days ago listening to a tech podcast, Silicon Carne. There was an interesting debate around content creation and how platforms like YouTube will kill TV. I’m not sure the root of the talk was that challenging; TV seems already a thing of the past at this stage. But as they started to talk about AI, things started to get interesting.

People often have limited visions of what’s possible, shaped by their beliefs and ideas about what’s acceptable.

Most of the discussion revolved around how AI would be able to create content, how it would be used to help producers and content creators, and what it would mean for platforms and consumers.

Based on that, the debate continued about how much AI would be acceptable in content creation on platforms.

I think this is very short-sighted.

What’s Already Happening

You don’t have to look far to see AI being used in content production; that’s a fact. But it’s still very human-driven and AI-assisted. There are a lot of tech limitations for now that prevent pushing the throttle to the max, but it is certain that those limitations will go away very soon. Look at what OpenAI is building with Sora, and you’ll have a glimpse of the future.

People are already leveraging this tech to move to the next step: creating content, communities, and creators that do not exist in real life. Instagram and OnlyFans are seeing a tsunami of AI-based girls managed by digital pimps. Does it work? It sure does; look at the numbers.

This is where many people start to get confused and want to draw a line based on morale or their beliefs that this model will not be applicable to “regular” content creation.

I believe this is false; it’s already happening.

A Glimpse into the Future

People often argue that having AI-generated content from a content creator would feel inauthentic and that they wouldn’t watch it. I say that this is having a very high opinion of your brain and little faith in the evolution of AI.

What if I told you that MrBeast did not exist? You’d say, of course, he does! Really? How can you know he exists? Did you ever meet him in real life? Did you ever talk to him?

What if, tomorrow, you’d connect to YouTube and see 10 new MrBeast videos with fancy new ideas that’d fit your taste and be very appealing to your brain? They might or might not be AI-generated; in any case, you’d have a good time.

Now, let’s take a step back and imagine having a brand new content creator everyone’s talking about. Nobody heard of them before. You watch the content, and you like it. Does this person really exist, or is it just an AI? How would you ever know? There might be rumors that a friend of a friend met him in a restaurant… but is that the reality?

At some point, there will be no way to know if a content creator is a real person or not. As time passes and technology evolves, it will be close to impossible to distinguish human creation from AI creation — the synthetic wave is already here. This is what most people don't want to believe because it shuffles too much their current reality.

Believe it or not, it’s happening.

How Platform Might Crash

The ability to generate endless streams of AI-driven content will undoubtedly transform platforms like Instagram, YouTube, and LinkedIn. In the short term, the appeal of hyper-tailored, dopamine-driven content may captivate users and drive unprecedented engagement.

But at what cost?

As AI-generated content floods these platforms, the lines between human connection and algorithmic interaction will blur. The authenticity that once set content creators apart—real people sharing real experiences—will be diluted in a sea of indistinguishable, machine-generated personas. Even if platforms introduce measures like “human-verified” badges, the deeper question remains: will people still care? If the content entertains, informs, or inspires, does its origin matter?

This shift could erode one of social media's fundamental purposes: fostering connection. If users begin to see platforms as spaces dominated by machines rather than humans, the sense of community these platforms once provided may crumble. The allure of authentic interaction—the very reason social media exploded in the first place—could fade, leaving behind a world where “social” media is anything but social.

This trend raises profound questions in the broader societal context. Will our online spaces become environments where we primarily engage with algorithms instead of people? As AI infiltrates every email, phone call, and comment, will technology become a tool for connection or a barrier to it?

Perhaps this is where the pendulum swings back to real life. In a world saturated with AI interactions, the simplest moments of human connection—a conversation over coffee, a shared laugh, or a face-to-face debate—might become rare and precious. Paradoxically, as AI dominates the digital realm, it could reignite our desire for genuine human interaction in the physical world.

Until then, the question isn’t whether AI-generated content will dominate—it’s how we, as creators and consumers, will adapt and what we’ll choose to value in an increasingly artificial landscape.

My prediction is that real life will be the only place you’ll have left to interact with real humans.

Until robots take over, of course.

Connecting the Dots with AI

Tue, 06 Aug 2024 00:00:00 GMT

In any conversation, a lot of context can be lost between what you think, what you say, what the listener hears, and what they ultimately understand. This loss of information can lead to miscommunication and inefficiencies. How often have you found yourself confused by someone's words, asking them what they mean, only to hear, "Sorry, I was thinking about this," and finally, the dots connect?

This common scenario underscores AI's potential to revolutionize communication. Imagine a world where your AI assistant, enriched with context from your daily activities, bridges the gap between thoughts and understanding. This could transform the way we interact, making communication more efficient and precise.

Communicating

The Role of AI in Enhancing Communication

In today's world, computers and phones are already tracking many of our communications through platforms like email, Slack, and Teams. Combining all of those platforms captures the full context of conversations — which is why people are starting to use them as sources for RAG (Retrieval-Augmented Generation) in LLM.

Technologies such as Microsoft Recall are going in that direction: recording more information to improve the AI context to make you even more able to understand your world.

AI and LLM can step even further in the direction of communication improvement in the future.

Consider a scenario where Alice needs to tell her colleague Bob to handle a customer request. Instead of Alice trying to guess what context Bob has or lacks, she could give the instruction to her AI assistant rather than communicating with Bob directly. Alice's AI could then communicate with Bob's AI, sharing the necessary context and information, ensuring that Bob receives a complete and clear message. This method of using AIs as proxies eliminates the guesswork and ensures that all relevant details are communicated effectively.

The Vision: AI-Assisted Communication

In the future, AI could be integrated into every piece of communication, from emails to meetings to casual conversations. The potential is immense. Imagine AI assistants transforming messages to match the recipient's preferred communication style and form, embedding the extra context that might be missing to the recipient.

For example, if Alice’s AI knows that Bob prefers visual information, it could transform Alice’s text-based request into an infographic or a visual summary. This ensures that Bob receives the information in the most effective way for him, enhancing understanding and efficiency.

Benefits of AI in Communication

The primary benefit of AI-enhanced communication is the significant improvement in efficiency. Misunderstandings and miscommunications can lead to wasted time and resources. By ensuring that all parties have the necessary context, AI can streamline interactions and reduce the need for clarifications and follow-ups.

Additionally, AI can create a personalized communication experience, tailoring messages to fit the recipient's preferences and needs. This not only improves comprehension but also makes interactions more pleasant and engaging.

Overcoming Challenges

However, implementing AI in communication is not without its challenges. One significant issue is the segregation of information. Just as humans struggle with deciding whether to share certain information, AI will need to learn how to handle sensitive or contextual data appropriately. Current AI systems lack robust role-based access control (RBAC) for context, making it difficult to manage which information can be shared and with whom.

Sandboxing Cycle

Furthermore, while AI can potentially develop its own languages to communicate more efficiently, the practical application of this in everyday communication remains a complex challenge. Security and privacy concerns also need to be addressed, ensuring that sensitive information is protected while still allowing AI to function effectively. I don’t think anyone is actively working on this right now, but it will be a major issue in the future.

Personal Reflections and Future Visions

Reflecting on my own experiences, I've often encountered situations where additional context could have prevented misunderstandings. A really simple example would be planning a lunch meeting without knowing the dietary preferences of your invitee. It might be so obvious to your guest that the restaurant must have vegan options that will not mention it, which can lead to disappointing outcomes if you book a steak house. If AI can provide this context seamlessly, such issues could be avoided.

Looking ahead, I envision AI assistants like Siri evolving to incorporate these advanced communication capabilities. This could extend beyond personal assistants to systems built between products and companies, facilitating smoother interactions and collaborations across different platforms.

The future of AI in communication holds incredible promise. By bridging the gaps in context and understanding, AI has the potential to transform how we interact, making communication more efficient and effective. Of course, getting there requires solving a fundamental problem: AI is still a human interface nightmare, and the way we interact with these systems today is far from what it could be. While challenges remain, the ongoing advancements in AI technology bring us closer to a future where misunderstandings are minimized and every message is clearly understood.