By André van der Walt, Solutions & Software Engineer at Insight Consulting. Blog post 1 of 4 in the Prompted series.
I can’t remember where I heard that, but the line stuck with me. At the time it didn’t really make sense to me. I have since seen it play out in our own team. We now produce code at a pace we couldn’t have imagined a few years ago. In isolation, for a dev, this seems like the magic bullet: the thing that closes the gap between 10x devs and everyone else. Instead, we saw the focus of our work shift.
The code is cheap and fast but that is not the product. The software that fits the business and solves the problem is the product, and the code is just a means to an end. The parts of the process wrapping the code (understanding the business, framing the problem, and knowing what not to build) have not got cheaper, but the tools help here too, and more of our work sits in these areas than ever before.
In effect, fast devs are less important; reasoning about the business and system, planning the solution and directing tools well matter more.
Where AI massively accelerated our output, it brought new ways to go wrong too. AI tools are easy to use and very easy to use badly. Understanding the difference is the challenge. The hard part is not producing the code, it’s the judgement you must exercise when making sure what was produced is accurate, correct and fit for purpose. It’s a bit like the adage about fire being a “good servant but a bad master”. AI is much the same. Control it, you will move in leaps and bounds. Let it control you, you will get burnt.
So, if the code got faster, why didn’t the software get cheaper and what is the benefit? The software didn’t get cheaper because the hard part was never the code, it is knowing what to build, and we can now do more of that. We’ve seen that we can get a much clearer picture of what we are building and why, much faster than we used to. With cheap code and AI to help plan and investigate we can afford to build proof of concept demos to answer questions, find more questions to ask and consider more aspects of the problem. Where requirements may have been missed in the past, these explorations of the problem and solution allow us to identify these requirements early. We also naturally find solutions the client had not even considered.
The result is faster delivery, much less risk of building the wrong thing and fewer issues arising during user acceptance testing and post-launch.
If understanding the problem is the expensive part, being close to the client is more important than producing a lot of code quickly. Kodelab operates as a delivery division for Insight Consulting. Being inside a consulting business (which naturally has a focus on client relationships), we had the opportunity to lean into that with the new way of doing things, and it feels like a gap has been closed between our team and the client. I am curious where traditional dev houses and others in this space see the value concentrating.
This article first appeared in Insight Edge, our newsletter on LinkedIn.