If you watch a consultant wrestle with an AI coding tool for a while, the real issue becomes clear. The problem isn’t that they can’t use the tool. It’s that they’re trying to make it think, prompting it over and over, doubting the results, and redoing work the tool already handled correctly. The tool is working as it should. The real confusion is that they’re unsure what their own job is now.
That’s not an AI problem. That’s an engineering problem.
After more than ten years of building software teams, I’ve noticed the most costly mistake organizations make is mixing up coders and software engineers. On paper, they look the same. They often have the same job title, and both can write solid C#. But when you give them a real problem to solve, not just a ticket, the difference shows up quickly.
A coder asks: “What do I need to build?”
A software engineer asks: “Why are we building this, and what happens if it succeeds?”
That’s not a subtle difference. That’s the whole game.
The coder mindset is optimized for execution. Hand someone a well-defined task, and they’ll ship it. They’re fluent in syntax, patterns, and frameworks. Within a bounded problem space, they’re productive. The ceiling on that productivity, though, is low. Coders focus on the component in front of them. They fix what’s broken, build what’s asked, and don’t naturally zoom out to ask whether the feature makes sense, whether the data model holds at 10x load, or whether the architectural decision they’re making today will haunt the team in two years.
That’s not a character flaw. It’s a mode of thinking. And for well-structured teams with strong technical leadership, it can be exactly what you need. The problem is when you staff an entire team this way and expect engineering outcomes.
A software engineer thinks in systems. They’re asking “what if” before writing the first line of code. What if user volume doubles? What if this third-party API goes down? What if the product pivots and we need to swap out this core component? Engineers care about the why as much as the how. They push back on requirements that don’t make sense. They propose simpler solutions when complexity is being introduced for its own sake. They think about maintainability, observability, and failure modes — not because they’re told to, but because they’ve seen what happens when those things are ignored.
That ownership mindset is the real differentiator. A coder completes a task. An engineer takes responsibility for an outcome.
AI has made this gap dramatically more visible — and more consequential. AI coding tools are genuinely excellent at the coder layer right now. Give GitHub Copilot or Claude a well-specified task, and it produces functional code faster than most humans. Boris Cherny, who built Claude Code at Anthropic, said it plainly on the Lenny Rachitsky podcast in February: “Today coding is practically solved.”
He’s not wrong. The mechanical act of translating a requirement into syntax is increasingly automated, which brings me back to those consultants struggling with their AI tools. The ones who are thriving aren’t the ones who’ve memorized the best prompts. They’re the ones who already thought like engineers — who treat the AI as an execution layer while they focus on what the AI can’t do: question the requirement, model the system, make the call.
Those struggling are trying to outsource their thinking. That doesn’t work because the AI will confidently do exactly what you asked, even when what you asked was the wrong thing.
I work with .NET teams across Belgian enterprises. One pattern I keep seeing: organizations hire for coding skills and are surprised when they end up with a pile of code that doesn’t hold together as a system. When I’m evaluating someone for a senior role, I don’t spend much time on syntax. I ask them to walk me through a decision they made that they later regretted — and why. I ask what questions they’d ask before starting a greenfield project. I ask whether they’ve ever pushed back on a requirement and what happened when they did.
Those answers tell me whether I’m talking to someone who executes tasks or someone who takes ownership of outcomes.
If you’re a developer reading this, here’s the uncomfortable part. Being fast and fluent with a language or framework was never the end goal — it just felt like one for a long time because execution skill was scarce and valuable. It’s becoming less scarce. AI is absorbing the routine coding workload faster than most people expected.
The skills that actually compound over a career — systems thinking, architectural judgment, the ability to walk into a room and say “we’re solving the wrong problem” — those are exactly what AI struggles with most. Not because AI is dumb, but because those skills require context, judgment, and accountability that go beyond the task at hand.
The question worth asking yourself isn’t whether you can produce output. In 2026, that bar is low and getting lower. The question is whether you’re responsible for what that output is supposed to achieve.
That’s the engineer’s job. Always has been. The difference is that now, if you’re not doing it, everyone can tell.
