AI coding tools collapsed the cost of building software by as much as 90% in the last two years. Jason Alba built an entire HR learning management platform, dashboard, course catalog, AI chat tools, user accounts, through vibe coding. Two people, no engineering background, functional product.
My co-founder at BUILT, Robert Davis, as a side project, built a gaming productivity suite, backlog planner, schedule generator, interactive map maker, in two weeks of spare time. He wired it to WordPress authentication and a database and shipped it.
I built a WordPress plugin that reads the content of a blog post, generates a custom AI image, overlays formatted title text with a dark gradient for readability, and sets it as the featured image, all from a single button in the WordPress editor. No stock photo hunting, no opening a graphics editor, no manual cropping. The whole thing took me about 10 to 15 hours of conversation with Claude over 2 to 3 days. I am not a coder. I have a background in information systems and nearly 30 years of web design and UX experience, but I have never been the person who writes backend code. (I used to be a mean HTML coder before CSS came along. If you need old-fashioned HTML tables, I’m your guy.) Two years ago, that project would have required a full developer engagement for months.
This is what Andrej Karpathy was describing in February 2025 when he coined the term “vibe coding” in a tweet that got 4.5 million views: “There’s a new kind of coding I call ‘vibe coding’, where you fully give in to the vibes, embrace exponentials, and forget that the code even exists.” His year-end review put a sharper point on it: “2025 is the year that AI crossed a capability threshold necessary to build all kinds of impressive programs simply via English, forgetting that the code even exists.” His conclusion: “Vibe coding will terraform software and alter job descriptions.” Collins Dictionary named vibe coding its Word of the Year for 2025. (By February 2026, Karpathy was calling the term passé, proposing “agentic engineering” as the more accurate description for a maturing practice where AI agents handle implementation while humans provide architecture and oversight.)
The first time I heard about vibe coding, I scoffed. I mean, I actually made a scoffing noise and everything. “This is going to be a mess,” I thought. I was right, and wrong. It can be a mess, but after seeing what my friends are building and my own experience building a plugin, I’m convinced, and hooked.
Jason Calacanis put it in operational terms on a recent episode of the All In podcast. His team of 20 people spent a weekend getting trained on AI agents, and within 30 days they were building software they had wanted for a decade but never gotten to. “Every piece of software that we wanted to buy or build over the last 10 years that we never got to, my people are building in the last 30 days.” He added: “The barrier to start a company is no longer three or four million dollars. You could just have two or three people… you don’t even need a developer, you can just publish software.” In Y Combinator’s Winter 2025 batch, 25% of startups had codebases that were 95% AI-generated. That number was considered remarkable when it was reported. It will seem quaint within a few years.
The ROI inversion.
This is the part that matters if you’re thinking about business opportunities. There is an enormous category of software that was never built, not because nobody wanted it, but because the economics didn’t work. Development cost was too high relative to the addressable market.
Think about it as a simple equation. If it costs $200,000 to build something and there are 40,000 potential customers willing to pay $50 a month, you need years just to break even, assuming you could reach them all. No venture capitalist would fund it. No rational entrepreneur would attempt it. So nobody built it.
But if the build cost drops to $2,000 and a few weekends? That same market of 40,000 customers at $50 a month looks like $24 million a year against a near-zero cost base. The ROI didn’t improve because the market got bigger. It improved because the denominator collapsed.
There are thousands of these opportunities sitting out there right now, invisible, because people are still running the old math in their heads.
The cognition gap.
The cost structure has already changed, but most people’s mental models haven’t caught up. Fifty years of conditioning tells us what’s possible when it comes to building software. That conditioning doesn’t update overnight.
So right now there’s an asymmetry. A small number of people have realized that the economics of building software have fundamentally shifted, while the vast majority are still operating under the old assumptions. They’re still thinking “that would cost too much” about things that are now essentially free to build.
This gap won’t last forever. Every month, more people figure it out. Every month, the tools get better and easier. The fact that vibe coding became a household term in 2025 is itself a signal. The window is open. It is also, slowly, closing.
Chamath Palihapitiya has been making a version of this argument publicly for a while. He launched an incubator called 8090 built on the premise of delivering software that is 80% feature-complete at a 90% cost reduction. He wrote on X in early 2025: “The engineer’s role will be supervisory, at best, within 18 months.” On All In, he argued the enterprise software market will compress dramatically as companies realize they can build their own tools rather than buy them. The incumbent SaaS market is his target. Your opportunity is what’s below that, the markets too small for incumbents to notice.
Anthropic CEO Dario Amodei made a prediction in March 2025 that AI would be writing 90% of all code within three to six months. Most people assumed he was overstating it. By September he was saying the prediction had come true inside Anthropic and several companies it works with. The debate over exactly how to measure that claim misses the larger point. The CEO of the company building the tools believes the shift has already happened. That belief is itself a signal about where things are going.
This is where Clayton Christensen’s framework from The Innovator’s Dilemma is useful. Christensen’s research showed that companies entering small emerging markets generated 20 times the revenues, per firm, compared to those pursuing growth in larger markets. His insight was that disruptive innovations almost always start in niches incumbents ignore because those markets are too small to justify the attention of a company with shareholders to satisfy. The niche is the advantage, not the disadvantage. By the time the big players decide the market is worth pursuing, the early mover has users, brand recognition, and switching costs working in their favor.[1]
The moat-before-competition play.
In the current AI window, the proprietary angle isn’t the technology. Anyone can vibe code. It’s the timing.
If you build now, during the cognition gap, you accumulate users, brand recognition, content, data, and search engine presence before the market realizes these products are now trivially cheap to create. By the time everyone else catches on, you have an installed base and a moat, not because your code is better, but because you were there first and did a good enough job.
There’s a fair counterargument here. The same tools that let you build something in a weekend let someone else clone it in a weekend. Code is not a moat. The real moat is distribution, industry relationships, and the friction of switching away from a tool that already works.
This works especially well in micro-niches. A market of 50,000 self-storage operators or 80,000 marketing agencies isn’t big enough to attract venture-backed competitors. It’s plenty big enough to build a real business for a small team. And in a micro-niche, “good enough” loyalty is stickier than people assume. People don’t leave tools that work for tools that are marginally different.
David Sacks made a point on All In worth sitting with. Even if AI dramatically increases the productivity of software development, the unmet demand for software is so large that the total market expands rather than contracts. Fortune 500 companies currently allocate roughly 1 to 2% of costs to software. Sacks argues that number should be closer to 50%. If he’s even half right, the floor for demand hasn’t dropped. It’s about to rise. The people building now are getting in front of that wave, not chasing it.
What’s actually new.
Wil Reynolds, founder of Seer Interactive, shared something in his newsletter that cuts to the heart of this. A client told him: “Don’t ever show me time savings, that’s small thinking. Show me how you use AI to do stuff we love about Seer, but couldn’t scale. Net new capabilities are where I want your heads at.” Wil’s observation underneath it: most people are just doing the old job faster.
Both things are real. Faster and cheaper matters. But it’s the second category, the things you now can do that you simply could not do before, where the more interesting changes are happening.
Here’s what AI coding changes that nothing else has: the threshold for whether something is worth building just dropped through the floor. For most of computing history, software was infrastructure. You built it once, maintained it forever, and resisted change because change was expensive. That thinking shaped everything: which projects got funded, which tools got built, which niches went unserved. Nobody built for fifty people. Nobody built something they expected to use once and discard.
Now code can be disposable. Karpathy builds entire apps just to find a single bug, then throws them away. The app served its purpose; the cost of rebuilding from scratch next time is roughly zero. That’s a different relationship with software than anything that existed before. We’ve spent decades carefully washing out our Ziploc bags and reusing them because waste was expensive. What happens when the bags are free?
The question shifts from “can we afford to build this?” to “is this worth building at all?” Dream big, then ask whether it’s now possible. The website that was previously too expensive. The tool that served too small a market. The throwaway app that solves one specific problem for one specific week. The custom internal system that fits your team perfectly instead of the SaaS product that almost fits but charges you for a thousand features you never touch.
The one filter that still matters is whether you’re the right person to build it. Not technically, but strategically: do you already have access to the people who would use it? Building is no longer the hard part. Finding the right small group of people who need what you built, and who trust you enough to try it, that’s where the work is.
Robert put it well in a recent conversation. We used to have to build broad to appeal to a large enough audience to justify the investment. But if you can iterate quickly and solve very specific problems for very specific people, and do that over and over again, that’s actually plausible now.
The hard part isn’t building. The hard part is seeing what to build, rewiring assumptions about what’s worth attempting. The people who figure that out first have a window. It’s open now.
1 Clayton M. Christensen, The Innovator’s Dilemma: When New Technologies Cause Great Firms to Fail (Boston: Harvard Business School Press, 1997).
Leave a Reply