AI is getting ridiculously good at smashing out code. Not long ago it was a juiced-up autocomplete tool. Now it'll happily build an entire feature, write the tests, and explain what it just did.
Impressive? Absolutely. Surprising? Not anymore. Either way, it's made people wonder what happens to software engineers once the code writes itself.
Writing code has never been the thing most engineering teams struggle with. It's the one skill most of us have spent our careers sharpening. Projects usually stall for entirely different reasons. Someone has to figure out the problem worth solving. Product and engineering have to agree on what a good outcome looks like. Architects have to decide where a new feature fits into an existing system. Everyone involved has different priorities, and they rarely align.
Then there are the things nobody plans for. Undocumented legacy behaviour. Third-party APIs that don't do what the docs promised. Performance issues that only show up once real customer data hits the system. Security requirements nobody mentioned until the last minute.
None of this disappears because AI can whip up a React component in a few seconds. These are the problems that have always defined software engineering. AI can produce the code. It still can't sit in a room with product, engineering and design and work through a messy problem together.
From implementation to judgement
AI has shifted where engineers spend their time. Less time writing boilerplate, more time reviewing it. Less time trawling documentation, more time deciding which approach fits. A CRUD endpoint used to eat an afternoon; now that afternoon goes into figuring out how the feature fits the wider architecture.
The best engineers I've worked with have always known when not to write code. They spot problems before they happen and recognise patterns others miss. Cleverness loses to consistency, and they've always known it.
AI has freed engineers to focus on the decisions that actually shape good software. The value has changed from implementation to judgement, collaboration, and technical leadership.
Better context, better outcomes
There's an old saying that content is king. In software engineering today, context is king. As engineers spend less time writing code and more time deciding, the quality of that context carries more weight.
Clean architecture. A well-maintained design system. Documentation people actually want to read. None of this is new. AI has just raised the cost of getting it wrong.
Watch an AI assistant confidently generate code that ignores your team's conventions, or duplicates something that already exists, and you've seen this play out. The model isn't the problem. It doesn't have enough context to make the call an experienced engineer would make.
It's no coincidence that the organisations getting the most out of AI are also investing in architecture and technical leadership. They're building the strongest possible foundation for both engineers and AI assistants.
Great engineering still wins
It’s so easy to slip into the same old technology rollout thinking with AI. Pick a model. Give everyone access. Measure how much faster the pull requests come in. That might lift productivity for a while, but it's not where the real gains come from.
The organisations pulling ahead are using AI as a multiplier to improve how software gets built. They're developing practices that make good decisions easier, codebases people can actually understand and architecture that evolves with the product. They're not chasing whatever model sits at the bleeding edge. They're building the environment where engineers and AI can both make good calls, consistently.
AI has made writing code faster and more accessible than it's been before. That was never the hardest part of building software. Great software engineers navigate ambiguity, balance competing priorities and solve the right problems. That’s not going anywhere.
The AI will keep getting better. Great engineering will always matter.