You need to calm down
AI isn’t changing the fundamentals of building software. It’s changing the speed. Don’t confuse the two.

If you work in software, you’ve seen this AI craze firsthand.
You’ve probably heard your leaders hyperventilate about the “transformative nature” of AI. Heard them panic about making sure everyone is “making the most” of AI. Heard them say things like, “engineers who don’t use AI will be replaced by those who do.” And it’s probably exhausting.
Ten years ago, you could have replaced “AI” with “the cloud”. Twenty years ago, it was “mobile”. Thirty years ago, it was “the internet”.
Yes, generative AI promises to be a transformative technology on par with the above. But that doesn’t mean we should lose our heads.
Rushing to use a new tool without carefully considering its tradeoffs and downstream effects is a recipe for building unsustainable things nobody actually needs.
What never changes
What never changes is the need to solve real problems for real people.
Discovering unmet needs. Forming hypotheses for how to address them. Testing those hypotheses with real people. Scaling the hypotheses that worked, killing the ones that didn’t. Repeating.
AI can absolutely make many of these steps easier: identifying patterns in customer feedback, rapid prototyping, and coding the mundane parts of the implementation. But as a partner in decision-making, not as a replacement for human judgment and taste.
Put another way: use AI to move up the abstraction ladder, not replace it.
What AI actually changes
AI doesn’t invalidate many of the best practices we’ve learned the hard way over the years.
You still need to ask the right questions in product discovery. You still need to optimize your delivery lifecycle for learning over shipping. AI makes shipping faster, but shipping was never the point. Meeting customer needs is.
Shipping the wrong thing 10x faster still means you’re shipping the wrong thing.
Used thoughtfully, AI can help you spend more time on higher-leverage work:
- Use AI to synthesize customer feedback so you can spend more time crafting better hypotheses.
- Use AI to build prototypes faster so you can learn what you should build more sustainably.
- Use AI to fill in the more mundane details of a thoughtful architecture so you can focus on higher-leverage design decisions.
Where teams get into trouble
Where teams get into trouble is treating AI as a substitute for judgment instead of a force multiplier for it.
- Don’t use AI to do things non-deterministically when a deterministic interface would be superior. Sometimes a button with a dumb workflow is better than an AI chatbot.
- Don’t use AI to write more code than you would have written by hand. Code is a liability, and every piece of code you don’t read or understand is code that you will have to maintain indefinitely.
Ask yourself: if this AI-generated code was completely wrong, how would I know? What would the blast radius be?
The goal isn’t to maximize AI-generated output.
The goal is to solve meaningful problems sustainably.
Don’t lose the plot
The companies that survive technology shifts aren’t the ones that panic the hardest. They’re the ones that stay focused on fundamentals while everyone else is losing their minds.
So yes: use AI. Learn it. Experiment with it. Find where it genuinely creates leverage. But software history is full of teams that became obsessed with the tool instead of the outcome.
The goal was never to maximize lines of code written, story points shipped, or now, AI-generated output. The goal is still the same as it’s always been: solve meaningful problems for real people.
Just don’t lose sight of that in the process.
You do not need to calm down because AI isn’t important.
You need to calm down because it is.