Software engineering in the age of AI

AI coding tools handle boilerplate, scaffolding, tests and repeated implementation well, and I use them every day. The engineers who get the most from them have strong fundamentals. The teams that gain most have senior engineers who set the tools up to work well for everyone.

What AI does well, and what it cannot decide

Given a clear problem with clear boundaries, AI writes working code quickly. CRUD operations, test scaffolding and repeated patterns all move much faster.

It cannot decide what to build, how to structure it or which trade-offs to accept. Those decisions are as hard as they ever were. You can now build the wrong thing faster.

Architecture matters more

I've been contracting for over ten years, across a lot of codebases, teams and companies. The pattern is consistent.

Projects that work well have solid architecture: clean boundaries, sensible data models and a clear path for growth. The code might be rough in places, but the structural decisions are right.

Struggling projects often have fine code and broken architecture. Services are tangled together. Data moves through the system in ways nobody fully understands. Every new feature means changes in six places.

Good code cannot fix bad architecture, and good architecture survives mediocre code. When AI generates code quickly, you build on bad foundations faster.

AI amplifies what a team already does

The DORA report on AI found that AI amplifies what a team already does. It gives a team more tests, more documentation and more code, and also more confusion. Teams with good habits got more of the good. Teams with weak habits got more trouble.

On well-run teams, senior engineers put the coding standards, architecture rules and conventions into the files that shape how the AI tools behave. Their knowledge then reaches everyone. It works like a linter. A mid-level developer benefits every time the editor flags a rule, even without knowing why the rule exists.

The teams where AI caused problems had no such guidance. No standards fed into the tools, no architecture conventions and nobody checking whether suggestions fit the system. Speed went up, and so did subtle bugs and architectural drift.

Mike Spitz, who runs engineering at PFF, made the same point in Agents Don't Do Standups. He suggests putting a team's patterns into small agent skills, such as branch naming, feature flags and the pattern every API follows. He also warns against adopting other people's skills when their opinions clash with how your team builds.

What breaks when output grows

A Google engineer's talk, "Software Engineering at the Tipping Point", asked what happens when every part of a developer ecosystem has to handle ten times more work. Generating code ten times faster is not engineering ten times faster. The talk listed what strains first:

Code. Code is a liability, and more code means more liability. Agents write code without always thinking long term.
Builds and tests. More code and more agent runs mean more compiling and more tests. The talk argued the test load grows faster than the codebase, because the dependency graph does.
Code review. Review is human. With many more changes, reviewers start cutting corners, and nobody keeps track of how the codebase is changing.
Token spend. If everyone uses ten times more tokens, most teams could not say where the money goes.
Releases and rollbacks. If you release faster than you can spot a problem, a rollback has to deal with several changes landed on top of each other.
Attention. There are more agents and more things asking for a human to look at them.

The talk's advice was to keep asking why a practice exists and what if it changed. Practices are not fixed. If you know why your team tests and releases the way it does, you can change it with confidence.

Audit the process against the new bottleneck

Fiona Fung, who leads engineering for Claude Code at Anthropic, said in Running an AI-native engineering org that coding is no longer the bottleneck on her team. A lot of team process exists to protect engineering time, so it needs checking once that changes.

Fiona's team has explicit permission to drop old processes. Every manager starts as an individual contributor and keeps shipping code. Most discussion happens in pull requests and prototypes. Mike's team replaced daily standups with short huddles every other day that include product and design, and let tickets update from pull request status.

The test I take from both is simple. If a meeting exists to share out scarce engineering time, it probably needs to change. If it is about alignment, product sense or how to verify the work, it probably matters more.

Two other points from those talks are worth keeping. Check the guardrails before letting agents run alone: security boundaries, feature flags and automated QA. And make sure the result still feels like your product. Product taste is something agents do not have.

What makes a strong engineer now

Systems thinking over syntax. I've known engineers who barely remembered their language syntax but could look at a design and spot the three places it would break under load.
Naming trade-offs. AI can suggest solutions, but it does not know your business constraints, team size or timeline.
Explaining decisions. If the value is in the decisions, you need to explain them, defend them and change them when the evidence shifts.
Knowing when simple is enough. AI will happily build an elaborate system for an elaborate description. Recognising when you do not need one is the human part.

What this means for careers and hiring

If you are early in your career, learn to code. You need to understand how things are built before you can make good decisions about them. Then learn system design, data modelling and the domain you work in. Guardrails on a well-led team will steer you towards better code, but learn why the rules exist.

If you are senior, more of your role is putting your expertise into the systems and tools your team uses. Done well, that makes everyone around you more productive.

For anyone hiring or leading a team, hiring cheaper and letting AI close the gap is tempting. That only works with strong senior engineers setting the standards the tools follow. Without them, everyone has a powerful tool and no guardrails.

For what happens to developers who resist this change, see what happens to developers who don't adapt to AI.