Every few days, the same wave of content emerges, ‘ten skills to survive AI, tools you can’t afford to skip this year’. None of it is wrong. It’s just answering the easy question. The harder one and the one that actually matters, isn’t what engineers need to learn. It’s what they need to unlearn.
I’ve watched this play out across our own engineering teams. AI in India is no longer a pilot, it’s embedded in how production systems get built, tested and shipped. But look at how individual engineers are responding, and the picture gets messy fast. My own rough count, from a year of watching this up close is that maybe 10 to 15% of engineers are genuinely rewiring how they work. They are now experimenting and questioning habits they’ve never had to question before. The rest, on the other hand, are watching from the sidelines, waiting for someone else to prove it works first. That gap isn’t about capability. It’s about something harder to teach, relinquishing a way of working that has earned results, in favour of one that hasn’t earned anything yet. And there’s no single answer here. No certification that works for everyone, no skill that closes the gap at every stage of a career.
Most young engineers today are already fluent AI users. That’s an advantage, but only until it becomes the whole story. Knowing how to write a good prompt isn’t the same as knowing what to do with a genuinely messy, real-world problem. The engineers I’ve seen pick this up fastest, seem to treat every AI output as a first guess to be interrogated, not an answer to be accepted. They’re the ones actively figuring out where AI adds value, where it has limits, and why human expertise still matters.
Mid-experience engineers face a harder challenge. They carry real expertise, and expertise is really a combination of knowledge and its application, forming a set of habits reliable enough to run on autopilot. The ones who adapt aren’t the most experienced people in the room; they’re the ones willing to test their own process, experiment with new approaches, and adopt change. This is important as one cannot fully embrace a new workflow while still defending the old one.
For senior engineers, this shift is quieter, and honestly, more uncomfortable. For years, deep knowledge made you the person people came to. AI doesn’t erase that, but it changes what the knowledge is for. The senior engineers doing this well have stopped racing to be the fastest source of an answer. They’ve started focusing on something else altogether. They judge whether the AI’s answer is actually right and turn that judgement into something reusable, a validated workflow knowledge that outlives the one project it was built for. Most people don’t want to admit they still need to build that skill.
Leadership is a different problem altogether. Getting AI adopted across an engineering organisation was never really a technology question, or even a skilling one; it’s a mindset question, and an organisational one. I’ve watched a “my way or the highway” leader stall adoption faster than any technical roadblock ever could. The leaders getting this right make room for their teams to experiment, fail without consequence, and bring back what they learned even when it contradicts how that leader built their own career.
If there is one thing I would want every engineer to take from this, it is simple – working differently with AI does not start with a new tool, a new certificate, or a national target. It starts with being honest about which of your current habits, the ones you have earned, the ones you are proud of, are actually still worth keeping. That is an uncomfortable ask, and it should be. The day it stops feeling uncomfortable is probably the day it stops working. That is the instinct this moment is asking engineers to find again: question what you know, test it against what is actually in front of you. The tools have changed. The instinct should not.
Authored by Satish Pratapneni, System Development Director, Lenovo India