Thoughts on Software Engineering in the Face of AI

There's no shortage of hot takes on when AI will mean the end of software engineering. Six months. A year. I'm not buying it.

Coding was never the most important part of the job. The true rockstar engineers are the ones who are great at solving problems. AI doesn't change that. If anything, it makes it more true.

The best engineers I've worked with don't jump to solutions. They sit with the problem first. They ask questions. They push back. They want to understand what's actually being asked before they write a single line of code.

I often to ask junior engineers: "What's the first thing you do when you pick up a ticket?" If the answer is coding, that's the wrong answer. You need to understand the problem. You need to understand the customer need behind the request. Because figuring out what code not to write is just as important as what code you do write.

In those conversations with junior engineers I frequently reference, Camille Fournier’s 2021 article “an incomplete list of skills senior engineers need beyond coding.” It's worth a read regardless of where you are in your career. Coding is the given. Navigating ambiguity, communicating across teams and stakeholders, collaborating under uncertainty are the real skills. And they're exactly the skills that become more valuable as AI handles more of the mechanical work.

The bar isn't getting lower. It's getting higher.

What AI actually changes is where engineering teams need to focus their energy. If AI is handling more of the mechanical work of coding, that frees up time and space to focus on the problem itself. To ask better questions. To push back on the wrong solutions before they get built. To more deeply understand the customer .

For engineers who have always led with problem solving, this is good news. The work you were already doing just became the most important thing on the team.

As for engineers who love code, the code is still really important. It just looks different than it used to. You won't be writing all of it by hand anymore. You're now an editor, not the writer. Knowing what good looks like, catching what's wrong, and shaping AI-generated code into something that actually holds up is still a skill.

This isn't just a philosophy; it's something I'm actively building into how my teams work.

The foundation is writing. Before any significant technical decision gets made, I ask my teams to write an RFC (Request for Comments) or an EDD (Engineering Design Document). The act of writing forces you to articulate the problem before you jump to the solution. You can't hide vague thinking in a document the way you can in a JIRA ticket. It surfaces assumptions, exposes gaps, and gets the team aligned on what problem we're actually solving.

The bi-weekly engineering sync to discuss open questions reinforce this skills. Engineers communicate across the team, navigate ambiguity, and connect their work to outcomes rather than just output. This is deliberate practice for the skills that matter most.

If you want engineers who can thrive in a world where AI writes more of the code, start by building a team that can articulate why the code needs to exist in the first place.

I'll be honest — I don't know exactly where all of this is headed. Nobody does. But if I had my say, AI would just be a fancy new IDE. A more powerful tool in the hands of engineers who already know how to think.

Because that's the job. It always has been: solving problems, understanding what customers need, knowing what to build, and communicating clearly. Those skills were valuable before AI and they'll be valuable whatever comes next.