It’s been over 1.5 years since I last posted anything about “AI” so I felt it was time to share a few more thoughts. That last post explored how LLMs can be used in customer solutions. Today, I’ll focus on how LLMs will impact software development. The number of writings on this subject increase by the day, so one more text may not be that wished for. But who knows, perhaps someone will find something here worth reflecting on. And considering the speed of everything right now in this space, it’ll be fun for me to reread this in six months’ time. Never pass up on a chance to laugh at yourself! :)

So, should we care about using coding agents?

Of course we should care about what’s going on. As always, it’s important to stay curious and try new things. Relearning is what we live for, isn’t it?

When it comes to using AI in software development, there seems to be just as many positive as negative voices in the community right now, and some of the debates are getting quite polarised. So, who’s right? In my opinion, it doesn’t really matter. We should do as we’ve always done: giving it a real try, again and again, in a responsible way. Worst case scenario, we learn something – and that’s actually a pretty good outcome. Most likely, there will be more impact than that.

I was pretty active early on, but ended up disappointed over and over. Then came a period of not experimenting that much, but now I’m eager to dive back in. Kent Beck said it the other day that it feels like having an exoskeleton. I could definitely use one of those! :)

Another iteration on an old problem

Twenty years ago, a common solution to finding enough development speed and power was to outsource the work to people far away. I remember Charles Simonyi saying it would be a thousand times quicker (and cheaper), if a machine could do the job instead.

Manually writing 3GL code is sometimes simply too much effort for the value it delivers. Inspired by Charles, I thought meta-programming might solve the problem. Like most solutions, it had its place, but it didn’t revolutionise the industry at its core.

Over the years, I’ve had this nagging feeling that we as a community are not actually making that much progress. At times, it’s felt like we’ve not done that much progress ever since the Visual Basic-days. :) I started wishing for a new and good “VB” fifteen years ago. Coding agents might actually be the answer, though definitely not what I had in mind back then.

Not all developers would like to

Not everyone will want to use coding agents, even if they prove to be genuinely useful. And that’s totally fine, of course. Some people will prefer to write all code manually forever, even if there are faster options.

If you’ve come across the metaphor of forest and desert by Beth Andres-Beck and Kent Beck, I think that applies well to this subject too. Speed and improvements simply aren’t priorities for companies living in the desert. One indication of this is that, even after all these years, practises like TDD, DDD and continuous delivery are still only used by a small minority.

So why aren’t improvements important in the desert? One reason is that any gains would just be drowned out by all the other pressing problems. What does matter to those companies, though, is reducing cost, so change will still happen in one way or another.

Cost

One common assumption is that AI-accelerated coding could allow companies to cut down on the number of developers while achieving similar results. That will probably happen in some places. In others, the goal won’t be to maintain the status quo, they’ll be aiming for more, and better, results.

This shift also puts a new cost on the table in the form of tokens and GPU-time. Developers have always benefited from fast hardware for development and pipelines‚ but this operates at another level entirely. It might become quite visible in the bigger picture.

Another major cost to consider is energy use and CO2e emissions. At least some of the increased gains made possible by coding agents will have to be redirected towards lessening the problem, for example by drastically reducing the burning of fossil fuels.

Inexperienced or experienced developers?

There have been some comments suggesting that inexperienced developers will outperform experienced ones when it comes to learning and using these new possibilities.

Thinking about this reminded me of the concept of leaky abstractions, which Joel Spolsky coined 20+ years ago. To be effective as a developer working at any given level of abstraction, you need to understand the level beneath it. It also reminded me about the value of knowing who to ask and when...

I assume it will as most often be good with a mix of different backgrounds and experience levels.

Another dimension regarding experience level

Amount of experience as a developer is only one dimension, of course. Persona is another one. Already today, entrepreneurs who don’t see themselves as developers are beginning to create executable prototypes on their own, without involving developers at all. Something that simply wasn't possible earlier.

It reminds me of something from 30 years ago, when I was a subcontractor at an IT-department. People there were very concerned that business people had started building application-like things in Excel. "This must be forbidden", they said, probably for good reasons. They knew who would ultimately have to take responsibility when the apps were put into production. But still, it was definitely very helpful input for developing something production-worthy.

At the other end of the spectrum, we have senior, super-skilled, passionate developers working in an extremely slim codebase, carefully crafted and maintained for a decade or two. At the moment, many of them are struggling with coding agents that go rogue, or at least don’t do exactly what they want.

I expect the entrepreneurs are just the beginning of a bigger movement. The brilliant developers will continue evaluating AI to discover where and when the gain is bigger than the pain.

Guessed effects after a while

In my opinion, the speed of writing code hasn’t been the real bottleneck that often, not even in the forest. It was rather architecture, teamwork, domain understanding, organisational culture, UX, … But if we do increase the speed of writing code, it will free up some time for more value-adding work in the other areas I mentioned. It will also make it possible to try out many more ideas and experiments, increasing the chance for even earlier feedback than before.

I think all this could lead to more people embracing a long-held message of mine, but now sharpened. Development teams don’t need to be big. In fact, quite the opposite. Two-three developers might be all you need, but now they could achieve even faster time to market and better long-term outcomes.

Or, worst case, we learned something.

Again, these are for sure exciting times to live in! Stay curious and keep re-learning!

This article was originally published on LinkedIn. Join the discussion and read more here.