By Samarjeet Singh, Head of SAP and Digital Transformation, Happiest Minds
A few months ago, my 10-year-old nephew, Kiaan, had already decided what he wanted for his birthday: a Golden Retriever. My sister wasn’t quite as convinced, given her busy schedule and the question of who would take care of the dog. When she told him they couldn’t afford one, Kiaan looked at me and asked, “Do you have money?” while my wife encouraged his plan.
Kiaan then picked up Alexa and started asking about the breed, its cost, and where they could get one. That was when I realized I didn’t know the answers either. Within minutes, he was gathering information and building his case.
What caught me off guard was how quickly he moved past me. He wasn’t interested in the technology; he had a problem and wanted to solve it.
That interaction made me think about engineering. Many of us started with the tools and then applied them to problems. The next generation may start with the problem itself and ask, “What can I use to solve this?”
How Is AI Changing the Role of Engineers?
For most of my career, engineering has been closely associated with execution. We write code, fix bugs, design systems, write tests and turn requirements into software. Those skills aren’t disappearing, but AI is changing how much of that work needs to be done manually.
AI can generate code, write tests, explain unfamiliar systems, suggest fixes and help create prototypes quickly. Much of the conversation has focused on productivity, but I think there is a more interesting question: What do we do with the time we get back?
The answer may not always be as straightforward as simply moving faster. A 2025 randomized controlled trial by METR studied 16 experienced open-source developers working on 246 tasks in codebases they knew well. The developers expected AI to make them 24% faster, but the study found that they were actually 19% slower when AI tools were allowed. The finding is a useful reminder that generating code is only one part of engineering work. Reviewing, correcting, understanding and integrating that code still require time and judgment.
If AI takes some repetitive work away, perhaps the answer isn’t simply to produce more software. Maybe we spend more time understanding what the customer actually needs, challenging assumptions, looking for a simpler approach and thinking about what could go wrong.
Sometimes, we may even need to ask whether we need to build something at all.
Why Engineering Judgment Matters More With AI
The strongest engineers I’ve worked with were never simply the people who could write the most code. They understood the problem behind the requirement, challenged assumptions and thought about the customer, the business and what could go wrong.
That kind of judgment becomes even more valuable with AI. If a tool can give you several possible solutions in seconds, generating a solution is no longer necessarily the difficult part. The harder part is choosing the right one and understanding why it makes sense.
The question moves from “Can I build this?” to “Should I build this?” and then to “Which approach actually makes sense?”
This is also why strong technical fundamentals remain important. As AI generates hundreds of lines of code in seconds, someone still needs to understand architecture, security, performance, scalability and reliability well enough to decide whether that code belongs anywhere near production.
AI can produce an answer, but the engineer still has to decide whether it is a good one.
How AI Is Bringing Engineers Closer to the Problem
AI may also push engineers beyond the traditional boundaries of engineering. A customer problem might involve product, design, data, operations and technology, and sometimes the answer isn’t another piece of software at all.
It might be a better process, removing something unnecessary, or making an existing experience less complicated. Engineers don’t need to become product managers or business strategists, but they do need to understand the context around what they build.
Who are we solving for? What actually matters to them? What does success look like? How will we know whether what we built made any difference?
These questions move engineering beyond implementation and closer to the problem itself.
Should Engineering Productivity Be Measured by Impact?
For years, we’ve measured engineering productivity using things that are easy to count: features delivered, projects completed, tickets closed and bugs fixed. AI makes many of these measures less meaningful.
If an engineer can build something in half the time, the achievement isn’t that we now have twice as much code. The better question is what we did with the time we got back.
Did we solve something that mattered to a customer? Did we make something simpler? Did we reduce risk? Did we create a new opportunity?
Perhaps engineering productivity needs to move from measuring output to understanding impact.
What Will the Engineer’s Role Look Like in an AI-Driven Future?
I don’t think AI makes engineers less important. I believe it changes where their value comes from.
There will be less value in competing with machines on how quickly we can produce code. The opportunity is to let AI handle more of the work it is good at while giving engineers more time to understand context, ask difficult questions, challenge assumptions, make trade-offs and take responsibility for outcomes.
I keep coming back to Kiaan because he didn’t start with technology. He started with a Golden Retriever, and technology was simply a way to get closer to solving his problem.
Maybe there is something in that for engineers too. As AI becomes better at building things, perhaps our value will come less from knowing every tool and more from understanding which problems are worth solving in the first place.
The tools will change, as they always have. Our job is to keep asking the right questions, understand the problem, find a better way and build something that matters.