Web Directions Year round learning for product, design and engineering professionals

The Software Engineer Who Don't Code

The job title hasn't changed, but the job itself is in the middle of a profound shift. Software engineers have always been problem-solvers, but the mix of skills and time allocation is rebalancing in ways that few predicted. The moment AI coding tools became good enough that they could generate working code consistently, the value of an engineer stopped being "the person who writes code" and started being something more subtle: the person who knows what code to ask for, who can evaluate what comes back, who can steer the direction when things go wrong.

This isn't to say engineers stop writing code. But increasingly, the time spent writing code is shrinking while the time spent on things that code-writing tools can't do is expanding. It's a shift in the ratio of craft to orchestration.

Consider what's actually happening on a good engineering team right now. An engineer needs to solve a problem. They might use AI tools to generate an initial implementation. But then comes the work that matters: understanding whether that implementation actually solves the problem. Is it efficient? Is it maintainable? Does it handle edge cases? Is it secure? These questions require judgment, and judgment requires understanding the problem deeply.

An AI-savvy engineer becomes someone who's very good at this evaluation phase. They write less code, but the code they do write is shaped by having rejected dozens of AI-generated options. They might spend more time thinking about architecture, about how different pieces fit together, about what constraints actually matter. They become less of a "coder" and more of a "problem-definer and solution-validator."

There's a second layer too: the orchestration layer. Systems are becoming more complex, not less. They have more pieces, more integrations, more surfaces where things can go wrong. The engineer's job expands to include orchestrating AI agents to solve parts of the problem, reviewing their outputs, catching where they fail, steering them in better directions. This is different from writing code. It's closer to architectural thinking.

The implications are worth sitting with. First, this might be a very good thing for software engineering as a profession. Engineers who spend less time on mechanical coding and more time on problem definition and solution evaluation tend to be more engaged. They're doing more of the interesting work. They're thinking about why we're building this, not just how to make it work. That's deeper.

Second, it requires a different kind of expertise. You need to understand the tools well enough to know what they're good at and where they'll fail. You need domain knowledge because you need to validate outputs. You need communication skills because you're not just implementing specs anymore, you're negotiating with AI agents about what's possible. You need taste: the ability to look at multiple valid solutions and recognize which one is genuinely better.

Third, there's a structural question: as the ratio of "code written by humans" to "code generated by AI" shifts, what happens to how we learn to be good engineers? Craft comes from practice. If junior engineers spend less time writing code, how do they build intuition? The answer probably involves intentional practice: deliberate focus on the parts that still require human skill, mentorship that emphasizes judgment over mechanics, and learning that comes from reviewing and evaluating code, not just writing it.

Fourth, there's a talent market question. If the job is changing, what does that mean for hiring? You can't just look for "people who are good at writing code" anymore. You need people who are good at problem-solving, evaluation, architectural thinking. Those are older, rarer skills. They're also more transferable. A great engineer in this model could move between domains more easily because they're not dependent on deep language-specific expertise.

The shift isn't complete and it's not inevitable. Some organizations will cling to the old model longer than makes sense. Some problems genuinely do require someone who loves writing code and has the depth to do it really well. But the center of gravity is moving. The engineer who doesn't code — or at least, codes much less — is starting to look less like an outlier and more like a preview of what the role is becoming.

Yasith Fernando, a Staff Software Engineer exploring the intersection of AI tools and engineering practice, will dive deep into this shift at AI Engineer Melbourne 2026 on June 3-4, examining what it means for how we build software and how we grow as engineers.