AI is going through a new phase at the moment. There’s still plenty of hype, but there’s more honest evaluation happening as well. Perhaps that’s a result of the reality-check of bills landing, in turn caused by the hastily revamped pricing models of LLM providers. Either way, it’s a good thing - and it’s led me to do some thinking as well.
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 concistency: 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.
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. Junior engineers are still required, and the industry has seemingly realised this with the return of jobs to the market.
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.