Unless you live under a rock, you’ve been hearing and seeing a lot about the introduction of AI into software development processes. I’ve seen it happen myself – the impetus can come from both developers wanting a better way to automate drudge code conversions as well as upper management wanting to reduce headcounts.
AI-assisted software development is here to stay, and can definitely make developers faster at their jobs. But we have to keep in mind that the practice of generating appropriate correct prompts into useful code is, at its core, just the next evolution of computer languages. Instead of explicitly writing out your algorithms and UX support, you’re directing software building via a mostly-deterministic NLQ prompt. The LLM tool acts as one more layer between the coder and the bare metal, just like the interface of writing in Java, C, etc. act on top of layers leading downwards eventually to machine language and microcode.
A key structural difference is that the resolution of the prompt-to-software volume ratio can be much more variable when using AI tools to write software – you can generate an entire application or just a small code snippet with a similar volume of typed prompts, but conservation of information theory suggests (much simplified) that if you’re generating a big and a small thing from the same input, either some chicanery happened or else the big thing will suffer in quality vs. the small one.
Apart from the technical issues around LLMs and mis-generation of code, such as hallucinations, incomplete generation, etc. – which deserve extra articles on their own – I want to talk about the upper management view of AI code generation, as some kind of magic black box which will finally let them control what they consider to be the ravenous pit of ongoing expenses in software product development – the software dev headcount.
It was faddish in the late 90’s and early 2000’s to talk about off-shoring and contracting out – replacing permanent headcount with the variable cost of contractors. Temp workers have their place when trying to rapidly grow capacity, but they are always more expensive, both short-term in terms of cost per hour, as well as long-term in terms of lost in-house knowledge about whatever product or tool one is trying to build, as well as a drag on limited senior project engineering resources.
In a similar fashion, AI code generation to replace headcount is faddish today, with the thinking that a company can reduce headcount all around with the introduction of AI code tools and thereby become successful. Introducing the new tools causes up-front disruptions to the development team, and it’s really easy to mess up. One company I’ve seen seemed determined to do all the wrong things:
- Reduced QA staffing. Even before reducing dev headcount, the QA staff were slashed, with the understanding that the remaining QA group would somehow build QA automation tools while servicing the existing code development. AI code generation exacerbates the problem as AI code at this point in time always has more problems requiring human inspection, not less.
- Inappropriate AI software strategy. AI code is best for new code generation (eg, database ecosystem migration, green-field development, etc), but 99% of efforts were around modifying legacy code. Also, as with the QA headcounts, dev headcounts were reduced before the AI migration efforts got to any stage of maturity.
- Missing product strategy. Not only was there no overall corporate product strategy, the product management staffing was drawn down to a single product manager overseeing more than a dozen different product lines, essentially the company’s entire B2B software output.
Bringing tools into your development process without a strategy for your company around productization is cargo cult thinking – you’re hoping that if you have the tools in place that magic will happen and great products will appear. Like the workbench picture, you can spend all the money in the world on new power tools, but success hinges on being a great craftsperson, not on how shiny your tools are.