If you built it, so can I. Everyone can build software now. Need a small utility? Ask an agent. Need a component or a framework tailored to the peculiar way you think your application should work? You can probably have a first version before lunch.
We usually describe this as democratization. People who couldn’t build software before can build it now. Developers can solve small problems that would never have justified the time required to solve them properly. Companies can make internal tools for audiences too small to support a commercial product. That’s all real, but making software cheap to build has another consequence: if I can build my own, why should I use yours?
Why build yours?
Suppose you publish a useful little tool. I’ve never heard of you, and I don’t know how carefully you built or tested it. For all I know, you vibe coded it over the weekend after encountering the same problem I have today. I can install yours, or I can ask an agent to build mine. Mine will work exactly the way I think it should. I don’t have to learn your abstractions, accept your opinions, persuade you to add a feature or wait for you to fix a bug. More importantly, I don’t have to trust you.
Using your tool creates a dependency. I’m trusting you to maintain it and keep it safe. I’m also trusting you not to lose interest next month. If the tool becomes important to me, I’m at least partly at your mercy. Building my own trades that dependency for ownership.
Ownership is still expensive. When my tool breaks, its dependencies change or the platform moves, fixing it becomes my problem. Increasingly though, I have an agent to help me with those problems too. The choice isn’t obviously absurd anymore. That creates a strange problem for people building software: we can all make more things while having fewer reasons to use things made by somebody else.
Shared software accumulates learning
For a long time, software development benefited enormously from convergence. Lots of people used the same operating systems, languages, libraries and frameworks. At one point, seemingly everyone building for the web used jQuery. That convergence gave shared software something far more valuable than convenience.
Imagine that 90% of jQuery’s users simply used it. Another 9% occasionally reported a bug, asked a question or requested something its maintainers hadn’t considered. Perhaps 1% did the work of maintaining and advancing it. Whatever the actual percentages were, a small group maintained the project while a much larger group exposed it to reality.
Every strange browser and unusual application gave the project another opportunity to learn. Unexpected scale and unconventional use added more lessons, and those lessons accumulated in one place.
As a result, a developer joining years later inherited an artifact containing years of other people’s discoveries. We stood on each other’s work. Now consider the alternative. A thousand developers need roughly the same utility. Instead of adopting one, each asks an agent to generate their own. Each gets something closer to their exact needs, and each starts alone.
We could dismiss this as everyone reinventing the wheel, but duplicated code matters less when agents do the duplication. If an agent can generate my utility in two minutes for a few cents, who cares that another thousand agents generated almost the same thing? Our time and experience remain scarce.
You can spend your time only once. If everybody is building fishing rods, who’s fishing? Who’s finding better fishing grounds or discovering better techniques? More importantly, what happens when they do?
With a shared tool, someone’s discovery can become everyone else’s starting point. With a bespoke tool, the lesson can end where it started. I encounter a problem and my agent fixes my implementation. You encounter a different problem and your agent fixes yours. We both improved our tools, but neither of us necessarily advanced the other’s. Agents have made generating duplicate code cheap, but the experience gained from fixing each copy remains isolated. We are stranding what we learn.
Other people expose what you cannot anticipate
Generated software can look remarkably similar to mature software. Take a professionally built UI component. An LLM can generate something that looks almost identical in seconds. If that’s what I need, why would I pay for the professional component? For one, the professional component contains more than the pixels I can see. Its behavior reflects hundreds of lessons about accessibility and keyboard navigation. It accounts for localization, browsers, touch interfaces, strange content and ways developers tried to use it that its original authors never anticipated. A polished implementation can still represent only a convincing slice of a product.
The generated component might contain many of those lessons too. Models know an extraordinary amount about software. Whether those lessons appear in my component depends on the model recognizing that they apply. Will it decide on its own that my dropdown needs all of that complexity? Or will I have to steer it? If I don’t have the experience to know those problems exist, what exactly am I going to ask for? Make sure I’m not missing anything sounds like an answer. I’m increasingly convinced it’s the wrong question.
Some of the best ideas I’ve had in my career came from customers. Someone needed to use something I’d built in a way I hadn’t anticipated. Someone worked under a constraint I’d never encountered, or had a problem with what seemed to me like a perfectly reasonable design. Those constraints forced me to think. I had a goal, but I couldn’t solve it however I wanted. Reality had narrowed the space in which a solution could exist. Working inside that space sparked curiosity and creativity, and sometimes produced something I wouldn’t have considered without the constraint.
Asking an LLM What am I missing? creates a blank check. The model can give me twenty ideas. It can role-play an accessibility expert or enterprise administrator, then consider the perspective of a security engineer or novice user. It can tell me about requirements I hadn’t considered. But I still have to ask. Even choosing which perspectives to simulate assumes I know which realities might matter. On the other hand, a real customer shows up uninvited and tells me my thing doesn’t work.
That makes me wonder whether we’ve underestimated what shared software gave us. Other people’s opinions were annoying. Frameworks forced abstractions on us. Libraries didn’t quite work the way we’d have designed them, products contained features we didn’t need and maintainers rejected our pull requests. AI offers an incredibly appealing alternative: you don’t have to live with anyone else’s decisions. Describe what you want and get software shaped around your understanding of the problem. That gives each of us more control, while reducing our exposure to requirements and ideas that came from other people.
When I use something shaped by hundreds or thousands of other people, I encounter ideas that didn’t originate with me. One person added a capability I didn’t know I wanted. Another designed an abstraction differently. A bizarre requirement forced the maintainers to generalize something I would have hard-coded, while another user discovered a failure mode before I encountered it.
The tool saves me from writing code and exposes me to accumulated experience. My bespoke tool begins with my understanding and requirements. It reflects my preferences. The agent can be vastly more knowledgeable than I am, but I’m still providing the gravitational pull. Software perfectly tailored to us also risks keeping us perfectly inside our own bubbles.
Can models become the commons?
There’s an obvious objection: we might no longer need shared artifacts to accumulate knowledge. Perhaps models become the place where software knowledge accumulates. Millions of developers solve millions of problems. Their code and discussions eventually contribute to better models, which use that knowledge to generate better implementations for everyone. Instead of experience flowing into a shared project and then into better software, it could flow through the model. Maybe that’s even better. However, that story depends on some uncomfortable assumptions.
The lessons have to become available to the model. Private bespoke software might never leave someone’s laptop. A useful lesson has to stand out among millions of bad implementations and reach a future model update. Then, when I ask for my component, the model still has to decide that the lesson applies.
Knowledge can exist without appearing in the implementation. A mature shared artifact already has the lesson built in. This matters because today’s models can generate remarkably capable software partly because they exist in a world containing decades of shared software.
They know patterns created by people who built frameworks and APIs shaped by years of customer complaints. They know solutions discussed in issue trackers, refined through thousands of pull requests and turned into conventions because millions of developers converged on the same tools. We’re inheriting an enormous amount of accumulated software knowledge.
AI makes it easier than ever to consume that knowledge without consuming the artifacts in which it accumulated. That’s individually rational. Why buy the component when I can generate one? Why accept someone else’s opinionated tool when I can have one tailored to mine?
But what happens if enough of us make the same rational decision? The professional component vendor gets fewer customers and the shared framework gets fewer users. That means fewer weird environments and complaints, fewer constraints and fewer opportunities for lessons to accumulate in one place.
Perhaps the foundational tools will remain shared while AI replaces only the commodity layers above them. New mechanisms may emerge for feeding private lessons back into our collective knowledge. I hope so. Otherwise, we’re using the accumulated knowledge of generations of software builders to generate millions of private artifacts while weakening one of the mechanisms through which that knowledge accumulated.
Building was only the beginning
We’ve spent a lot of time celebrating how much AI has compressed the act of building. Something that took a month takes a day. Something that took a day takes ten minutes. Something that wasn’t worth building at all suddenly is. That’s extraordinary.
However, producing runnable code was never the whole process by which software gets good. The longer process looked more like build → share → adoption → collision with reality → constraint → adaptation → accumulated sophistication. AI significantly lowers the cost of the first step. But it doesn’t necessarily compress the rest. If cheap creation makes building another bespoke thing more attractive than participating in an existing one, it risks weakening the rest of the loop.
For each of us, bespoke software can be the obvious choice. We get exactly what we need and control it. We also avoid depending on a stranger. But collective advancement has always depended on something opposite: many people bringing different realities to fewer things. Maybe everyone having the power to build their own fishing rod is progress. I just wonder who’s going fishing.