For a long time, writing code was one of the biggest constraints in building software.
You could have a great idea, a clear customer problem and a strong business case but turning that into working software still took time.
Now, developers can generate boilerplate in seconds. Agents can implement features, refactor code, write tests, investigate bugs and scaffold entire applications.
The cost of producing software is falling.
But that doesn't necessarily mean we're going to build better products.
Because faster implementation exposes another constraint:
Deciding what is actually worth building.
The question becomes:
Should we build it?
And that requires a very different skill.
Because removing the time/speed constraint doesn't remove the need for judgment.
When implementation becomes cheaper, teams can develop and build more ideas.
Which means they also have the ability to build more bad ideas, faster.
This changes the job of the engineer
There's a version of the AI future where engineers become primarily supervisors of code-generating systems.
I think that's too narrow.
The engineers who become more valuable aren't simply the ones who can produce the most code with AI.
They are the engineers who understand why the code should exist in the first place.
They can look at a request and ask:
- What problem are we actually trying to solve?
- For whom?
- What evidence tells us this problem matters?
- What outcome are we expecting?
- What assumptions are we making?
- What happens if we're wrong?
- What are we choosing not to do?
Those aren't coding questions.
They're product judgment questions.
And historically, many organisations have treated them as someone else's responsibility.
"Product decides what. Engineering decides how."
Consider a familiar request
A stakeholder says:
"We need an AI assistant inside the product."
There are at least two ways an engineering team can respond.
Response 1
"What should it do?"
The requirements get written. Then they design the architecture and build the assistant within hours (with AI tools).
Perhaps it even works perfectly.
But six months later, hardly anyone uses it.
Technically successful. But a successful product failure.
Response 2
Before discussing implementation, someone asks:
"What problem would the assistant solve?"
Maybe the answer is: "Customers struggle to configure their accounts."
Good. Now we can keep going.
How do we know?
From Support tickets.
Where exactly do users struggle?
During initial setup.
What are they trying to understand?
Which configuration is appropriate for their organisation.
Now the conversation is very different.
Perhaps the right solution is an AI assistant.
But it might also be:
- better defaults
- contextual guidance
- a setup wizard
- improved documentation
- automatic configuration based on account type
- redesigning the workflow entirely
The engineer asking those questions hasn't stepped outside their role.
They've improved the quality of the decision before implementation even begins.
Product sense isn't about having better ideas
People sometimes describe "product sense" as intuition.
That definition isn't particularly useful.
Strong product judgment is less about magically knowing the right answer and more about being able to reason when the answer isn't obvious.
Especially when:
- the data is incomplete
- users contradict each other
- stakeholders want different things
- technical constraints exist
- commercial pressure is high
- several options look reasonable
That is normal product work, that is typically considered under the remit of a Product Manager.
But Engineers play a crucial part in this conversation, in asking the right questions and giving the right answers before even starting to build anything.
So this product sense isn't just a PM skill. It becomes essential for the entire team to develop, including, and most importantly, the engineers.
Start with three definitions of "good"
One model I use when making product decisions is simple: A good product decision usually has to work across three perspectives.
User:
Is this desirable?
Does it solve a meaningful problem?
Will someone actually use or value it?
Business:
Is it viable?
Does it support the organisation's strategy, economics or competitive position?
Technology:
Is it feasible?
Can we build, operate and maintain it responsibly?
Product decisions get interesting when those perspectives conflict.
A customer might desperately want something that creates massive long-term architectural complexity. A technically elegant solution might solve a problem customers barely care about. A commercially attractive feature might introduce significant reliability or security risk.
There often isn't one objectively correct answer.
There are trade-offs that need to be noticed and understood.
AI makes weak product decisions cheaper to execute
This is the part I think we underestimate.
When implementation is expensive, organisations are forced to choose.
When implementation becomes cheap, the temptation is: "Why don't we just build it?"
But every feature still has a cost. Even if generating the code takes ten minutes.
Someone still has to:
- review it
- test it
- monitor it
- maintain it
- explain it
- support customers using it
- integrate it with the rest of the product
- handle edge cases
- manage the additional complexity
- deal with the risks if something goes wrong
And every additional product capability creates another decision users might have to make.
Ask better questions before writing better code
One of the most useful habits engineers can develop is learning to interrogate the decision before jumping to implementation.
When someone asks for a feature, try asking:
What changed?
Why is this important now?
What problem are we solving?
Not "What functionality do we need?"
What is actually happening to the user or the business?
What evidence do we have?
Customer interviews? Usage data? Sales feedback? Support tickets? An executive assumption?
What would success look like?
What behaviour or outcome should change if we build this?
What are we assuming?
What must be true for this idea to work?
What happens if we're wrong?
A reversible experiment should be treated differently from a major architectural commitment.
What is the smallest thing we could learn from?
Sometimes the right first step reducing uncertainty before building a full solution.
AI should increase engineering leverage, not reduce engineering judgment
There is a danger in the opposite direction too. As AI tools improve, we can delegate more of the thinking process itself.
"Analyse these customer interviews."
"Suggest the most important problems."
"Prioritise these features."
"Recommend what we should build."
AI can be extremely useful for all of those tasks.
But there's a distinction between using AI to improve your reasoning and using AI to replace your reasoning.
If a model gives you a convincing recommendation, you should still be able to answer:
- Why is this the right decision?
- What evidence supports it?
- What evidence contradicts it?
- What assumptions is the recommendation making?
- What trade-off are we accepting?
- What new information would cause us to change direction?
If you can't answer those questions without pointing back to the AI output, you haven't made the decision.
You've delegated it.
The most valuable engineer may not write the most code
For years, developer productivity was often implicitly associated with output. Measured in the form of:
- Tickets completed.
- Pull requests merged.
- Code shipped.
- Not tokens burned.
But if one engineer uses an agent to generate 5,000 lines of code while another engineer asks one question that prevents the company from spending three months building the wrong thing, who created more value?
The second engineer might produce almost nothing you can count.
But their leverage is enormous.
That is why I think one of the most important skills engineers can develop in the AI era is product sense.
Because building great products has always required more than implementing requirements correctly.
It requires understanding what is worth building.
And as AI makes implementation faster, that distinction becomes more important, not less.
The advantage is for the engineers with product sense
Knowing how to prompt the latest coding agent will matter, but it probably won't remain a meaningful differentiator forever.
Judgment is harder to commoditise.
- Understanding customers.
- Recognising weak evidence.
- Seeing second-order consequences.
- Connecting technical decisions to business outcomes.
- Knowing when to challenge a request.
- Knowing when not to build something.
Those are the skills I would invest in.
Because in a world where almost anyone can build more software, the scarce capability will be knowing what deserves to be built.
I'm running a free live session on 1 October: AI can write code. Can you make the right decisions?, where I'll showcase exactly this kind of decision-making using real product scenarios.
We'll work through how to challenge feature requests, calculate the value of investments, and connect engineering decisions to user and business outcomes.
*If this is a capability you're trying to develop, you can find the live session here.
*
Top comments (0)