Code is Cheap, Context is King: Why AI Is Pushing Engineers Toward Product Thinking

Reflections | Business Evolution

AI coding tools are speeding things up—but they’re also exposing a gap in how we build software teams.

We’re now firmly in the era of AI-assisted coding.

Tools like Copilot, Cursor, and Gemini are becoming standard across development teams, and their impact is hard to ignore. They can generate code quickly, handle repetitive tasks, and remove a lot of the friction that used to slow engineers down.

At first glance, this feels like a straightforward productivity win.

But as teams start to rely on these tools more heavily, a different kind of problem is beginning to surface. AI can build what you ask for—but it has no way of knowing whether what you asked for actually makes sense.

For a long time, one of the hardest parts of software development was translating ideas into working code. Engineers played the role of translator, turning messy human intent into something precise enough for machines to execute.

That’s no longer the main constraint.

AI is increasingly capable of turning clear instructions into functional code. It can scaffold applications, generate logic, and handle much of the boilerplate that used to take up time and attention. In many cases, the path from “idea” to “implementation” is shorter than it’s ever been.

But that only holds if the idea itself is well defined.

When the input is vague or incomplete, the output doesn’t just degrade—it fails in ways that are harder to spot. The code looks right. It runs. But it solves the wrong problem.

An AI assistant will quite happily build the wrong feature perfectly.

What this exposes is a shift in where the real difficulty lies. Writing code is becoming easier. Being clear about what should be built is not.

One way to understand this shift is to look at prompting for what it actually is.
When you give an AI instructions, you’re not just “asking for code”—you’re defining behaviour. You’re setting constraints, describing outcomes, and implicitly deciding what matters and what doesn’t.

In other words, you’re writing a form of requirements.

To do that well, you need to think beyond the immediate task. You need to consider edge cases, how this piece fits into a wider system, and what the user actually needs. None of this is new, but it’s work that engineers have often been able to treat as upstream—something handed to them rather than something they actively shape.

That separation is starting to break down.

When the quality of the output depends directly on how well the problem is framed, you can’t rely on someone else to do that thinking for you. If the requirements are unclear, the AI won’t fix them. It will simply execute them more efficiently.

For a long time, software development could be organised around well-defined tasks. Engineers would pick up tickets, implement them, and move on. As long as the scope was clear, this model worked reasonably well.

AI changes the economics of that kind of work.

Tasks that are already well-scoped and predictable are exactly the ones AI handles best. If a piece of work can be clearly described, there’s a good chance a large part of it can now be generated or accelerated.

That doesn’t eliminate the need for engineers, but it does shift where their value sits. Execution on its own becomes less of a differentiator. The harder—and more valuable—part is shaping the work in the first place: identifying what needs to be built, spotting gaps in the thinking, and asking questions before anything is implemented.

This shift doesn’t mean engineers are becoming product managers, or that product roles disappear. Product managers still own prioritisation, trade-offs, and the overall direction of the roadmap.

What is changing is the boundary between the two roles.

Engineers are no longer just implementing decisions made elsewhere. They’re increasingly expected to engage earlier in the process, to challenge assumptions, and to help refine what’s being built before it reaches the implementation stage.

That requires a different kind of involvement. It means being comfortable with ambiguity, understanding the context behind a request, and contributing to the “why,” not just the “how.”

Take something as straightforward as a login system.

If you ask an AI to build one, it will give you a working result—something with authentication, validation, and a basic user flow. On the surface, it looks complete.

But the moment you step outside that narrow definition, the gaps start to show. Should it support enterprise SSO? Are there compliance or audit requirements? How does it behave under failure conditions, or integrate with the rest of the product?

None of those questions are about code. They’re about context.

The AI didn’t get it wrong—it was never given the full picture to begin with.

This transition isn’t purely technical. It’s also cultural.

Many engineers were drawn to the field because it offered a degree of clarity—well-defined problems, logical systems, and a certain distance from the ambiguity of business requirements. What’s happening now pulls some of that ambiguity back into the role.

That’s not something you can address with a short training session. It requires a shift in how engineering work is understood and evaluated. Outcomes start to matter more than output. Clarity of thinking becomes as important as technical execution.

A lot of organisations are already investing heavily in AI tools, but tools alone won’t close this gap. In some ways, they make it more visible.

If expectations are changing, the way teams are supported needs to change as well. That means helping engineers build skills that haven’t always been emphasised:

understanding how features connect to real business outcomes

communicating clearly with stakeholders and asking better questions

thinking in terms of systems, not just individual components

These aren’t “soft” skills in this context—they’re becoming central to doing the job well.

The role of the engineer isn’t disappearing, but it is evolving.

Less time is spent writing code from scratch. More time is spent framing problems, making decisions, and guiding how solutions come together. The engineers who stand out won’t just be the fastest at implementation—they’ll be the ones who understand what actually needs to be built.

AI has made it easier than ever to produce code.

What it hasn’t done is make it easier to decide what’s worth building in the first place.