I had a weird moment over breakfast a couple of weeks ago.
A friend who has never written a line of code in his life showed me an app he built in a weekend. Real users. Real data. Payments going through. He used Cursor and ChatGPT and a small AWS bill, and the thing works.
Twenty years ago a project like his would have been a six-month engagement with two contractors. Five years ago it would have been a no-code Frankenstein with five Zapier seams showing. Now? A weekend.
If you build software, work with software, or sell software, you should sit with this for a minute. The wall around shipping software fell over while most of us looked the other way.
What happened in December
Andrej Karpathy, who co-founded OpenAI and used to run AI at Tesla, said something in a Sequoia interview this April which most engineers I respect quietly agree with.
In December 2025, agentic coding tools crossed a threshold. Before then they were helpful. After then they were... different. Karpathy described feeling "more behind as a programmer" because the chunks of code coming out of these agents stopped needing correction. He started trusting the loop. His side projects folder filled up overnight.
Karpathy coined the term "vibe coding" in early 2025 to describe giving in to the vibes and accepting AI-generated code without reading it. One year later he is asking us to drop the word. Vibe coding, he says, was the consumer phase. What we have now is "agentic engineering"... autonomous agents writing, testing, and shipping production code under human direction.
The phrase he is replacing matters less than the trend underneath. The trend is this: writing code is no longer the bottleneck for shipping software.
The plot twist nobody wants to discuss
Here is the bit the AI hype machine glosses over.
A research outfit called METR ran a randomised controlled trial of experienced open-source developers using AI coding tools. The developers predicted they would be 24% faster with AI. After they tried it they reported feeling 20% faster. METR's measured result was a 19% slowdown.
Read those numbers twice. Felt 20% faster, was 19% slower. A 39-point gap between perception and reality.
So how do we square this with my friend shipping an app in a weekend?
Easy. He is not an experienced developer doing complex refactors on a familiar codebase. He is a domain expert who knows exactly what he wants the software to do, and the AI was the cheapest path from idea to running code.
The barrier did not drop for everyone equally. It dropped for the people whose skill set was "knowing what should exist." It went up for the people whose skill set was "typing the code correctly."
So what is the moat?
Now it gets uncomfortable for anyone who built a career on being good at the typing part.
If two people with the same idea sit down on a Saturday morning with Cursor and Claude Code and a credit card, the one with the better product instinct wins. The one with the deeper customer relationships wins. The one with the existing audience wins. The one with the harder-earned data wins.
Coding speed, by itself, is no longer a moat. It was always a thin one. It is now a puddle.
The three things left standing are insight, trust, and distribution.
Insight is knowing which problem to solve. Not the generic version everyone is thinking about, but the specific one your users would pay you for tomorrow. You get this by sitting in their meetings, watching them work, reading their support tickets. It does not come from a model.
Trust is whether your existing users will let you ship the next thing. If you have spent five years building a category-leading newsletter, an honest reputation, and a customer base who replies to your emails, you have a moat the agents have no way to copy. They will write the code. They will not write your reputation.
Distribution is the one most engineers underestimate. The world is about to be flooded with shippable products. The signal-to-noise ratio is dropping like a rock. Reddit threads this month are full of users retreating from AI slop and seeking out human-perspective content. If you have a list, a podcast, a community, a niche where you are known... you have what the weekend warrior with the slicker app does not.
What this means if you are still typing
I am not telling engineers to stop coding. The opposite, in a way.
Karpathy uses an image I like: the agent is your intern. Useful, fast, sometimes brilliant, sometimes spectacularly wrong. Your job is to direct, review, and take responsibility. As he put it, outsourcing your thinking is one thing... outsourcing your understanding is suicide.
The senior engineers who win the next five years will not be the ones refusing these tools. Nor will they be the ones who hand the keys over and stop reading the diffs. They will be the ones who do what good engineering managers have always done... hold the shape of the system in their head, set the standards, and know when to override the well-meaning intern.
If you are an individual contributor today, this is a fork in the road. Lean into the agent and treat it as leverage on the work you already understand. Or refuse it, get out-shipped by people who once needed three of you, and watch your market value drift.
If you lead a team, you have a different problem. Your engineers are about to feel one of two things. Either thrilled because their reach is finally matching their ambition, or threatened because their identity was tied to the typing. Both responses are reasonable. Both need a coach, not a manager. I wrote about why leaders fall back on managing instead of coaching over on Step It Up HR... the same instinct is about to bite a lot of engineering leads.
A note from my own workbench
I have been building a product I have been thinking about for years. Two years ago I would have hired developers and waited six months. Today I am the one shipping features, supported by agents who do the typing.
The interesting bit is what the work feels like. Less keyboard. More clarity. The hours used to go into translating my idea into syntax. Now they go into deciding whether the idea is the right one.
I am not faster than a senior engineer would be. I am almost surely slower than my own gut tells me, if METR's numbers are anything to go by. What I have is the one thing the agent does not... twenty years of watching managers fail, and a clear opinion on what to do about it.
This is the moat. Not the code.
Three questions worth asking yourself
I have been chewing on this since December. Three questions keep coming back.
One. If a smart non-engineer with no team ships a v1 of your product in a weekend, what is your real moat? Strip away the code. What is left?
Two. Where are you putting your scarcest hours... shipping faster, or getting smarter about what to ship? The first is now cheap. The second is now where the leverage lives.
Three. What do your customers know about you which an AI agent will not replicate next Saturday? Whatever it is... protect it, feed it, talk about it.
The wall is down. Everyone walks through. The advantage is no longer on the other side of the wall. It is in the head and heart of the person walking through.
Now go build something only you would build.