What Developers Get Wrong About Building with AI
For the developer who wants to become a founder.
Disclaimer: The views expressed here are my own and are not related to or reflective of my work or any organization I am affiliated with.
I’ve been thinking about what it means to build software right now.
Not the mechanics of it. The models are capable. The tools are there. The barrier to shipping something has never been lower.
I mean the thinking behind it.
Because here’s what I keep coming back to. A generation of talented developers is about to build products shaped entirely by what AI can do today. They will look at the current state of the models, the current interfaces, the current capabilities and build for that. Ship fast, get users, feel the momentum.
And then the models will evolve. Faster than the roadmap expected. And the product built for today becomes the wrong answer for tomorrow.
That’s the trap the moment sets.
The mistake is building for the model, not the problem
When you pick up a powerful new tool, the temptation is to build something that shows off what it can do. This isn’t new. Early mobile apps were just desktop websites made smaller. Early cloud software was just on-premise software moved online.
The same thing is happening now. Products that are, at their core, a UI around a prompt. Clean. Functional. Sometimes impressive. But the value lives entirely in the model underneath and that model is not yours.
When the next model ships, and it will ship sooner than you think, what you built becomes a feature someone else offers for free.
If the model getting stronger makes your product weaker, you were never building a product. You were building a demo.
Ask a different question before you start
Most founders start with: what can I build with AI?
The better question is: what problem gets harder to solve as the world gets more complex and how do I sit in the middle of that in a way that compounds over time?
That question changes everything.
It moves you away from the interface and toward the workflow. Away from the feature and toward the process. Toward what the model cannot do alone, which is understand the specific, messy, human context of a particular industry.
The model knows everything about the average. It knows almost nothing about your specific customer’s specific situation. That gap is where you build.
What loses value. What doesn’t.
Software that manages lightweight engagement, scheduling, email workflows, basic coordination, is easy to migrate and easy to replace. An AI-native competitor can move that data in days and offer something better on top of it.
What keeps its value is software sitting inside complex workflows where the data is hard to replicate and built up over years of real operational use. Construction scheduling. Manufacturing supply chains. Property maintenance logs. The kind of data that doesn’t exist anywhere else because it was never meant to be shared. Because it lived in a process, not a database.
That’s the line.
You already have the advantage
Here’s what I think developers underestimate about this moment.
You already think in systems. You understand how things connect, where things break, what happens at scale. That instinct, applied not just to code but to how an industry actually operates, is exactly what this era needs.
The most defensible products being built right now are not the most technically impressive. They are the ones where someone understood a domain deeply enough to encode how it actually works. The exceptions. The edge cases. The judgment calls that happen between the steps. Into a system that gets smarter every time someone uses it.
That is builder’s work. Not just engineering. Thinking.
Build something that learns
Your product is not the features. It is what the system learns as people use it.
When a user corrects the output, that’s signal. When the system handles an edge case it hasn’t seen before, that’s signal. When a decision gets made inside the platform, that’s signal. That accumulated understanding of how a specific domain operates, that is the asset. Not the code.
No foundation model trained on the average of the internet will ever have it.
Own the workflow where the real work happens. Make your system the place where the truth of the business lives. And then let it learn.
What you build on day one matters less than what your system knows on day one thousand.
A generic agent can book the plumber. Only your system knows which plumber showed up last time, what it cost, and whether the problem came back. That memory is the moat. Not the capability.
The models will get stronger. Build for that.
A stronger model should make your product more powerful, not obsolete.
If the AI is the product, if the value is the generation, the summarization, the interface, a stronger model replaces you. That is a fragile position to be in.
But if the AI is the engine, if the value is the proprietary context, the workflow, the domain knowledge you have built up, a stronger model makes your engine more powerful. You get better without doing anything.
Build with the model. Not on it.
Don’t marry the engine either
One more thing, because this is where even careful builders get it wrong.
Treating AI as the engine is right. But don’t bolt yourself to a single engine.
The gap between the leading models has narrowed faster than most people expected. OpenAI, Anthropic, Google, they are closer to each other than they have ever been. And open-source models have caught up in ways that also give you something proprietary models don’t: full control of your data, no dependency on someone else’s pricing or terms.
Build a layer between your product logic and the model. Route the right tasks to the right model. Swap them out as the landscape shifts. The ability to always use the best tool at the right cost, without being locked in, is itself a competitive advantage.
Build the engine room, not the engine.
And if the inference cost is slowing you down right now, don’t let it stop you. There is no world where token costs stay this high. Every wave of compute has gotten cheaper faster than anyone expected. Build the right system. The economics will catch up.
Go where the model was never taught
The sharper version of “go where AI adoption is slow” is this: go where the training data never existed.
The plant manager who knows which supplier runs late in Q4. The process refined over twenty years on a specific floor. The supply chain nuance that lives in phone calls and institutional memory. That knowledge was never written down, never online, never in any training set.
The SMB running three shifts has heard of ChatGPT. They just don’t know how to make it work for their operation. Nobody has built for them. The big platforms are chasing enterprise. The funded startups are chasing legal and healthcare. The manufacturing floor is not in any of those conversations.
That is the opening. Go there first.
At the end of it
You are building something that helps a person simplify a hard process and you are using the most powerful tool in the history of software to do it.
Keep it that simple in your head.
Not “I am building an AI product.” Not “I am disrupting a vertical.” You are making something hard, easier. For a real person. In a specific situation. That the model alone cannot solve.
And when the AI gets it wrong and it will, your product needs to be the system that’s accountable. In manufacturing, in property management, in any operation where mistakes have real consequences, the winner isn’t the smartest model. It’s the one the customer trusts to own the outcome.
The developer who stays anchored to that, who doesn’t get seduced by what the model can do and loses sight of the actual human on the other side, is who builds something that lasts.
Go build. But build for the person, not the prompt.