AI is going through a new phase at the moment. The initial wave of hype and fear is starting to settle into a more grounded, honest evaluation of AI: how will it impact the software industry? Does the value justify the cost? How can we bridge the gap between our existing workflows and the alluring promise of flashy demos and vibe coding?
It’s been a wild ride for GenAI, but for me personally it’s gone a bit like this: big initial enthusiasm, soured as usual by big-tech involvement and marketing hype. My decision to return to work was driven partly by the risk of not just my skills but my entire profession becoming obsolete - a desire to remain employed while I’m still employable. That’s still a possibility, but I’ve since taken a more optimistic outlook: AI is going to change software development, not make it obsolete, and has the potential to improve our productivity and capability in significant ways. It’s still very early in terms of understanding how to leverage AI to amplify human ability, and software engineers have an excellent opportunity now to build skills that will be lucrative in future.
AI is extremely good at coding now. That’s no longer in doubt. But coding has always been the easy part, which is why the amount of time a software engineer spends coding (usually) decreases as they become more senior. There’s a lot more emphasis on deciding what to code, communicating technical direction, operating code in production and so on. The importance of getting the design right has long been known - mistakes during the design phase become harder to correct later in the development process. But arguably the most important part happens after the code is written, when it gets released to production, because that’s when customers actually get the value from the code you’ve written. And crucial to this part succeeding is the understanding of the code: so you can devise an appropriate release strategy, reason about it, and later maintain it. All this means that while the coding part has become much faster, the design and release phases have become much more important, and these phases still require human understanding.
AI is also very good at writing documentation, which leads many people to lean on AI for writing planning and design documents. I strongly believe that using AI for planning is an anti-pattern. The main reason is the gap of understanding - if the human “author” doesn’t thoroughly understand the design, the risk of mistakes during development increases. And there’s the issue of consistency: being non-deterministic, the AI is not guaranteed to produce the same design again when asked. It can’t explain the rationale or answer questions related to the design like a human could. Another important but underrated issue is the value of human creativity and originality. If an AI is designing your software, it could design it for your competitors, or anyone. Rather than think “if we don’t use AI, our competitors will have an advantage”, ask “if we only use AI, where’s our competitive advantage?”. It comes from the minds of your best people, and it’s important not to lose that.
Another very common practice which I think is actually an anti-pattern is the desire to standardise agent skills and prompts, so everyone on a team gets similar responses from their AI agents. I think this is misguided and think that developers should be encouraged to build their own personalised prompts and workflows instead. The reason goes back to the importance of understanding. Everyone has their own preferred ways of working and learning, and it’s much easier to understand what’s going on when the workflow follows your own preferences and expectations. This is the reason why so much legacy code gets rewritten by default when a new team takes over: not always because the code is bad per se, but because it’s very difficult to understand code without being involved in the decisions and context behind it. I find the default language of LLMs in responses to be unnaturally formal, in pull request descriptions, documents, code reviews etc, so much that it’s difficult to read. If I’m going to be reading that all day, it makes sense that I should personalise it to a format that I enjoy reading, or at least find it easy to understand.
We can look at the game of chess to support the need for personalisation. Computer players surpassed humans in terms of chess skill long ago, and computer-analysed moves are memorised by every top player. But there is also the concept of “human moves”, which are easier and more natural for human players to understand. Often, given several candidate moves, the right move for a human to make is not the absolute best computer move, but the strongest move that is natural for a human to play. If the human doesn’t understand the meaning behind the moves they’re playing, they will quickly find themselves in deep waters when the opponent makes a novel move that wasn’t analysed by the computer. So is the risk when blindly accepting computer-generated code: the human will face difficulty when making decisions or reasoning about that code later on.
As for the agentic coding phase, I have experimented with running many agents in parallel to understand just how much “productivity” can be potentially gained here. I found that there are a lot of challenges with this: technical problems such as build capacity (even modern macbooks aren’t made to run 4-8 builds in parallel) and code conflicts are a limiting factor. But more importantly, it’s very difficult to effectively divide your attention between multiple parallel coding sessions. Leaving agents to run unchecked and unreviewed is definitely going to lead to bugs and rework - they need steering. Right now, I think running 3-4 parallel threads is the absolute maximum, and the quality is still likely to be degrade even then. For most teams, I believe single-threaded approach (one human supervises one agent at a time) is going to give the best results in terms of balancing productivity and quality, and this is likely to remain optimal in the short to medium term.
The counter-argument to heavy “steering” of agents is often that you should give the agent enough context so that it can work uninterrupted. This is true; good prompting and up-front context can reduce the need for rework, but it’s important to be clear about why this works. It is not merely about compressing as much knowledge into the prompt as possible. I try to minimise the number of decisions that the AI has to make in order to carry out a task. Each decision that the AI makes independently has a risk of taking it off course and either missing the original requirements or adding technical debt. If possible, these decisions should be surfaced during the initial planning phase and encoded into the prompt (or design spec, etc), or otherwise the agent should block itself and wait for a human decision. This is hard to do reliably though, which is why steering is still necessary for now.
AI models will continue to increase in power and capability, but I think we’re already past the point where these increments make a meaningful difference to the actual impact on software development. For now, the focus for companies has shifted towards how to get value out of AI in a sustainable way: optimising workflows, building evaluations, using models efficiently. And for software developers, now is the best time to understand how AI is changing our work - there will be plenty of adaptation, but also plenty of opportunities.