Articles
Faster typing isn't a strategy
You should fire your entire engineering team today.
That’s what I keep hearing from a lot of opinionated people with big followings. Most of them haven’t had to ship something on a date a customer was counting on.
I’ve spent the last few years running engineering teams through this shift, and my view is less dramatic and more uncomfortable. You probably don’t need fewer engineers. You probably need different ones.
The profile of a good engineer has changed. When writing code was the bottleneck, we hired for how well someone wrote it. That bottleneck is going away. The hard part now is deciding what to build, knowing when the output is wrong, and owning the result all the way to the customer.
So experience matters less than it used to. I’ll take an engineer with two years and an entrepreneur’s instinct over one with fifteen who waits for a ticket. The ones who do well act like owners. They ask why a feature matters before they ask how to build it, and they notice a customer struggling before anyone files a bug.
It also changes what passion looks like. For a long time we celebrated people who loved technology for its own sake: the new framework, the clean architecture, the rewrite. Those engineers are having the hardest time right now, because AI handles a lot of that well. The ones pulling ahead care about the product and the person using it. The technology is just how they get there.
Don’t get me wrong, we still need engineers who understand security, performance, reliability and how data actually moves through a system. AI writes code that works in the demo and fails under load, leaks something it shouldn’t, or falls over at three in the morning. Someone on the team has to see that before a customer does. The difference is that this knowledge now serves the product instead of being the point.
And handing everyone an AI coding license isn’t a plan. I’ve watched teams get the tools and change nothing, because planning, code review and the definition of done were all built for a world where code was slow to write. If the process around the tool stays the same, you’ve paid for faster typing.
So no, don’t fire your team. Look hard at who’s on it, what you reward, and whether your process fits the way the work gets done now.
This is a lot of what I’m working on at Loch Vale Consulting. If it’s on your mind, I’m happy to compare notes.