Not Every Problem Is Worth Solving—and AI Doesn’t Know That

When I hear people say we can move faster with AI, I find myself asking: should we be moving this fast in the first place?

The question usually gets skipped. Speed has become its own justification. We can turn an idea into a prototype in an afternoon, ship a feature before the end of the week, and automate work we were doing manually yesterday. The pressure is to keep up. If you’re not using AI to move faster, you’re being left behind.

But left behind on the way to what?

I wonder whether vibe coding will eventually prove to have caused more harm than we currently recognize. I can’t establish that today, and the ability to build more easily has real value. People can now test ideas they previously lacked the skills or resources to explore.

My concern is what happens when the ease of producing a solution starts to substitute for the work of understanding a problem.

The benefits of speed are immediately visible: a working demo, a launched product, a task completed. Some of the costs take longer to appear. Someone has to maintain what we build. Other people have to adapt to it. Decisions that looked harmless in isolation become dependencies.

We should pay attention to those breadcrumbs, even before we know where they lead.

Time does more than slow us down

We often treat the time between an idea and its execution as waste. Sometimes it is. But time also gives an idea opportunities to meet reality.

A conversation changes our understanding of the problem. A recurring frustration turns out to be a temporary inconvenience. A workaround reveals a need that the original request didn’t capture. Something we thought was urgent becomes less important after we understand what else is at stake.

None of this means slow work is automatically thoughtful. You can spend six months building the wrong thing.

It means that when we shorten the process, we should understand what we’re removing. Was it repetitive work? Unnecessary coordination? Or was it the period in which we would have discovered that our first idea was wrong?

AI can help us question an idea, identify tradeoffs, and explore alternatives. But it cannot independently know everything that makes an intervention worthwhile: the history nobody documented, the competing commitments, the consequences people will have to live with.

A system can help us reason about those things. We still have to decide what matters.

These are five things I try to think through before solving a problem.

1. Cadence: how often does this actually need attention?

A problem that happens once a year may not deserve a system that requires attention every week.

Before automating or building, I want to understand the rhythm of the work. How often does the problem occur? How quickly does it need a response? Is it persistent, seasonal, or temporary?

The speed at which we can deliver a solution should not determine the pace at which people are expected to use it.

Sometimes the right answer is a tool. Sometimes it is a monthly conversation. Sometimes it is waiting to see whether the problem happens again.

2. Nuance: which differences matter?

Two people can describe the same frustration and need different things.

“I need this to be faster” might mean the process takes too long. It might also mean the person has too much work, doesn’t understand the process, or is being measured against an unreasonable deadline.

Those are different problems.

If we accept the first description too quickly, we may make a bad process more efficient while leaving the reason it feels bad untouched.

3. Context: why does this problem exist here?

A solution that works in one environment may fail in another.

A manual step might exist because nobody has automated it yet. It might also exist because someone needs to exercise judgment, take responsibility, or notice an exception.

That doesn’t make the existing process sacred. It means understanding its purpose is part of changing it responsibly.

Before asking what we can remove, we should ask what that step is doing—and for whom.

4. Order of priorities: what deserves attention first?

Being able to solve something does not make it the most important thing to solve.

AI makes it easier to act on whichever idea is easiest to describe. But a feature we can build this afternoon may matter less than a difficult conversation we’ve been avoiding for weeks.

Even cheap solutions consume attention. They need review, adoption, maintenance, and sometimes explanation.

The question is not only “Is this worth doing?” It is also “What will receive less attention if we do this now?”

5. Influence: what changes because we intervene?

A solution changes the environment it enters.

A dashboard can change what people optimize for. An automated reminder can change expectations about availability. A faster workflow can become the justification for a higher workload.

We don’t need a time-travel story to recognize that small changes can have consequences beyond their original purpose. We see it whenever a useful metric becomes a target or a convenience becomes an obligation.

We cannot predict every consequence. But we can ask who benefits, who absorbs the cost, and how easily we can reverse course.

The decision before the build

I’m not arguing that we should stop building with AI. I’m arguing that the ability to build faster makes these questions more important.

Some friction deserves to disappear. Some problems deserve an immediate response. Others need observation, a better question, or a decision to leave them alone.

AI can participate in that judgment. It should not become our excuse for skipping it.

Before I ask, “How quickly can we build this?” I want to be able to answer, “Why does this deserve to exist?”