Almost since the dawn of programming (certainly since before the 1969 NATO Science Committee conference on software engineering techniques), software managers have been looking for ways to create programs without relying on programmers. In addition to being expensive to hire (at least if you are not asking about salaries in the direct aftermath of 1970s energy crisis, the dot-com crash, the Great Recession, or the post-COVID layoffs bubble), programmers have a habit of doing the wrong thing.
To quote from the aforementioned report, conference attendee Jules Schwartz says “Programmers must be controlled, so that they don’t invent beyond the requirements which are assigned to them.” This is such a big problem, that the software engineering memeplex has phrases that describe both its occurrence (“Gold-Plating”) and its avoidance (“You Aren’t Gonna Need It” or “YAGNI”); the latter being a technique that rightfully got labeled “Extreme” on its introduction.
In both theory and in practice, you do not need programmers to write programs. Once you have a description of your system’s capabilities and design, you can automatically generate a program that does what you need. No programmer to create features you do not need; to turn a quick design tweak into a general data-driven layout engine; to rewrite the whole application using a technique they just read about in a Yourdon Press book.
In practice, this approach has drawbacks. Firstly, the implementation that you mechanically derive from a specification probably is not optimised for your target platform; it does not use design idioms from that platform’s UI, it does not use all of the hardware facilities available, and so on. You either tweak the implementation for the platform (by hiring programmers), or you optimise the compiler for the platform (by hiring programmers). Ugh. Programmers.
Secondly, a specification that is precise enough to turn directly into a functional implementation has many of the features of a computer program anyway. You know who can work with computer programs? Ugh, that is right. Programmers.
So through a combination of coercion—managers weaponised Agile, throwing so many tasks into each short iteration that there is no time for gold-plating—and compromise—programmers stopped reading books about programming—programmers and managers reached an uneasy truce. Programmers would (mostly) only write the software that their employers needed (or pretend to, with gold-plating saved for “corporate open source”), in return for which managers would (mostly) tolerate the programmers’ continued presence (or pretend to, until the next software factory hype cycle).
But now, everything has changed. Now we have a new magic pixie dust we can sprinkle over our projects to make everything beautiful and to get rid of those pesky programmers: AI. Does AI now succeed where computer-aided software engineering (CASE) failed? Can we make a software factory out of LLMs?
Yes, and no. Firstly, I will quickly dismiss the idea that Spec-Driven Development takes us back to the CASE days. This is quick to do because I already made a video on it.
But a software factory is a specific kind of CASE product, and a specific application of specification to the software world. It is a collection of pre-made components, with templates and recipes that an implementor can use to adapt it on to their specific problem. That kind of thing is so much in the wheelhouse of an LLM-based coding assistant that there are two different technical ways to solve the problem.
A software factory vendor could package their factory as an Agent Skill. The SKILL.md file tells the LLM how the software factory is structured, and what to do. Recipes/playbooks are scripts in the scripts/ folder that the LLM runs to fulfil certain tasks. Pre-made components and templates are in the assets/ folder, and documentation, of course, goes in documentation/. To build an instance of the factory software, invoke the skill.
But they could also deliver it as an MCP server. This time, the recipes and playbooks are tools that the LLM uses, and the components, templates, and documentation are resources that the server makes available to the LLM. The server also shares prompts over MCP, providing the same templated interaction with the coding assistant that an Agent Skill would.
Now would this work? Yes, of course it would. The real question is: who would make it work? Who understands how to tweak the factory’s output to meet the specific demands of the organisation? Who knows how to integrate it into the existing system? Who knows how to tailor the configurable components to suit the goals of the specific system you are building? Who knows how to fix problems when the LLM does not quite generate the correct code? Ugh, that is right. Programmers.
Cover photo by Pavel Neznanov on Unsplash.