The Mythical AI Minute
Who Needs a Man-Month?
In the book “The Mythical Man-Month” published 1975, Fred Brooks discussed the practice of software engineering and project management strategies for large software projects. Some of his insights have held true for decades:
“Adding manpower to a late software project makes it later”
“Plan to throw the first version away; you will anyway”
“The second system designed will be over-engineered”
“Nine women cannot give birth to a child in one month”
His main objection was to the project management practices prevalent in the days when IBM wrote OS/360, an effort he was part of. A team of Systems Analysts would design the system down to the single function level and would write a spec for the function. That spec was then programmed by a line level programmer, and the result was included in the larger system.
He found that traditional corporate command and control structures did not work for software development projects. He advocated the use of smaller groups of programmers, all vertically responsible for a larger part of the project, and many other changes.
The book was required reading for me in college. The success of the book, and the mere idea that the software development process was a strategy you could tinker with, may well have triggered the waves we have seen since then. Waterfall, XP, Scrum, etc have each had their years in the spotlight.
Overnight, it’s all obsolete.
AI Assisted Programming
AI Assisted Programming has gone from a decades-old dream to a daily reality for many programmers in less than a year. Dozens of companies are providing AI based extension modules to Integrated Development Environments (IDEs) like Microsoft Visual Studio Code and Eclipse, as well as entire AI based standalone solutions.
A year ago, these tools could write snippets of passable code, such as write a playable game of “Snake” in python. Today, given a reasonably detailed and well thought-out specification, they will write all the code for medium sized web apps in mere minutes, and the code quality is impressive. I discuss how to effectively use these tools in a Facebook group named AI Assisted Programming that I created for the purpose, but these tools improve radically by the week and the details will therefore shortly be obsolete, so I hesitate bringing such details to SubStack.
A few examples: I tell the AI “Write a React app with a Java backend, starting with a login screen with standard registration and recovery capabilities” and it does exactly that — it creates several new files in my source file directory, fixes compilation errors, and writes the complete frontend (in React, javascript, HTML, and css) and the required backend support (in Java and SQL to tie to a backend database).
When I did it, the frontend code compiled and worked perfectly on the first try. It added a registration page and a validated email based password recovery system without me even asking for it. I can see why this is easy for them because this is a standard project starting point that might be 90% boilerplate, but there is no question that the AI actually understands what it is supposed to be doing and makes the correct adaptations and corrections. For instance, the registration page might well contain non-standard fields, if the product specification so states.
It then proceeded to expand an entire backend according to standard Spring Boot project layout, again with adaptations.
A surprise to many is their ability to integrate with existing systems - Source control like git, sites like github, systems like maven, gradle, and jenkins, compilers and databases, cloud services, and thousands of libraries. They can produce excellent code in dozens of programming languages and can use many databases and web frameworks.
Programmers like myself follow these developments with mixed feelings. On one hand, our tools are rapidly improving, radically speeding up our work. On the other hand, much of the knowledge and skills we have developed over decades is now irrelevant, and many programming jobs will disappear. Or so it seems, at first, on both accounts.
All traditional software methodologies and strategies used by companies - Waterfall, Agile, Lean, TDD, FDD, RAD, DevOps, Scrum, XP, Benevolent Dictator, Mongolian Herd, or whatever process has evolved at a particular company over time, are now obsolete. The reasons for using these processes are all gone. The problems they were created to solve have all gone away.
The Stack Has Flipped
First and foremost, what used to be the most expensive part – writing the code – is suddenly very cheap. Some things that used to take months now take minutes. Tasks that used to take entire floors full of programmers can now be done by one skilled programmer using AI support, costing a few dollars a day.
This affects literally everything in software development. We need entirely new methodologies, and companies need to adopt them as soon as possible, because their competitors will.
Over the decades, I have been employed by companies using many different software development strategies, all with some local dialects with roots in corporate history. And I have now been using AI Assisted Programming continuously since mid-October 2024 and have experience with their amazing powers, surprising limitations, excellent code quality, amazing breadth of knowledge of available libraries, breathtaking rate of quality improvement, and a widely welcomed decline in cost.
I feel like I am in a position to make decent medium term predictions and provide some strategic advice.
Keep What Works
The AI based tool makers have understood that in order to be effective and reach rapid mass adoption, the AI assistance has to integrate with human developers – at least for the foreseeable future. So these AIs are quite competent users of git and other version management tools, and even know obscure ways to recover from mistakes made than what is required for daily use. Some use the same development environments we do, like VSCode, Eclipse, etc. and edit the code in their buffers. They write unit tests using the standard Mock libraries and use the same compilers we do. They document everything using MarkDown documents.
They make decent co-workers.
Deep Expertise
In theory, a company would only need one deeply knowledgeable expert on git and one expert that knows how to recompile the kernel, etc. Each deep specialty needs a dedicated expert, but one may be enough for a company for rarely needed tasks.
AIs can already provide deep expertise in many important subtasks where a larger company might have had to employ a dedicated expert. One example, surprising to some, is that I can give an AI “root” level access to a cloud based server and when told to create a web server for our new web app, it can do just that, pretty much from soup to nuts. It can set up https: support with scheduled automatic certificate renewal and sets up nginx as a reverse proxy router in seconds. I have not personally used them on AWS but it is an important enough platform that I expect current AIs to know it quite well. Which saves you the trouble of hiring an AWS expert or learning it yourself.
Many of our AIs are capable of adequate skills useful in many different situations. Their most impressive feats today are not necessarily brilliant. Rather, it is the sufficient mastery of every task required to complete a large project in mere minutes, or in a few days if humans need to be involved.
Great Programmers Ship. This requires good skill coverage.
The Boring Parts
Every industry project requires documentation, installation manuals, release packages, a README file, licenses, and several project configuration files. Some projects require Docker, Jetty, Apache, or fancy installers. Many companies use unit tests.
All of these can now be created with almost no human effort required, because the skills required are mostly at human and computer language level, or are well documented near-boilerplate framework requirements.
We can now expect up-to-date documentation accessible online the moment a new version of any software becomes available. Releasing software on multiple platforms is likely to be nearly trivial if AI manages the variants.
This quality-of-life improvement to all users of some app or software package will be obvious. Generating all of this support material rarely requires brilliance, just reasonable competence in many areas. Which means a software consultant can have all of this support material produced in minutes. The ability to offer quality documentation becomes a competitive advantage.
Programming By Specification
I claimed “Given a well thought out and complete specification, an AI can write a complete web app in minutes”.
We do notice the major first step. Writing the product specification. This suddenly becomes the majority of the work, since the code itself will be written in minutes by an AI.
On the other hand, AIs can write the project documentation based on just reading the code in the project. Including the cloud service maintenance manual that I asked it to write after it completed the cloud installation.
Well, a documentation is a lot like a specification, so to copy someone else’s app you can use their documentation as a specification. Or an AI can take a short, poorly written and nebulous specification you made, and explain its understanding in a new document to you, the systems designer and ideator. You read it in detail to see that it got things right, and either correct mistakes by editing or by conversing with the AI and asking for a new version.
This foreshadows what will follow.
A few rounds of specification, correction, and elaboration of details can create a very detailed spec in a short time.
And then you say “Make it so!” and break for lunch.
Expertise Improves The Odds
The experienced programmers have an edge in that when they write a product specification, they have a much better chance at avoiding expensive early design mistakes. They can guide the AI away from standard but inadequate solutions, A particular problem with today’s systems is that they were trained on a lot of excellent software. Large systems that had lots of features. So without asking, current AIs will attempt to add features we didn’t want and import libraries that make programming some aspect easier, but which creates a dependency on external code we could well do without. Especially now that an AI could just write the few functions that it needs from scratch, rather than including some bloated library.
At the front, experienced UX designers understand the trends in their community and what design elements will be seen as “modern enough” in the product’s lifetime. UX sometimes seems like fashion design to the backend designer which means AIs (with their corpus cutoff dates) may favor slightly outmoded designs and a well connected human could avoid that with, again, high level guidance. Things like “Use Material Design”.
Programming by Conversation
A surprisingly pleasant way to design a system is to use a phone and airpods or equivalent for a clear voice conversation with an AI. Several AIs already support this. OpenAI’s ChatGPT app can do this, and Hume.AI has their own app which can connect you to Anthropic Claude.
So you start talking to the AI about a problem you want to solve and maybe some app you want to design. It will happily provide lists of ideas and solutions and together you can explore many design alternatives and agree on which ones to use for various features and components.
After a while you can ask the conversational AI to write a product specification in the form of a prompt to give to the programming AI. It will be available in the transcript of the conversation.
Some Hints
Make that product spec the first document in a “SPEC’/” directory of specification files that you yourself maintain.
Your programming AI will create source and support directories. In addition, you may want to add a top level “DOCS/” directory for informal developer documentation that the AI keeps for its own continuity and context. This is extra important for AIs with limited token memory. Some people require the AI to document everything, creating a kind of external “memory bank” of key documentation. Sounds helpful, as long as the AI can find the right document and knows it needs to read it.
Working above your paygrade
An expert programmer can effectively use AI assistance in a medium-to-large project. They can create a comprehensive and effective product spec and then let the AI write most of the code, especially the simple and boring parts.
It will handle all the boilerplate and drudgery such as project files, as well as provide the non-coding parts of a project – documentation, unit tests, staging, and cloud deployment scripts.
Leaving for the programmer only the hardest problems – those that it cannot solve on its own.
And here we see the major limitation of AI Assisted Programming: It requires a competent programmer to guide it and get it out of these tough spots.
Somebody with no or little programming experience may be able to write simple programs with AI assistance, provided it is all simple enough that the AI can handle absolutely everything. In the industry, this is rarely the case.
AIs would not have knowledge of systems and APIs that appeared after the they stopped learning. They are unlikely (today) to handle subproblems that require significant de novo algorithm development experience. Projects may be based on proprietary research unlike anything in the AI’s corpus. In any sufficiently complicated project, human intervention will be required.
Experience is indispensable.
An experienced programmer may have to read a few manual pages to catch up, but since they have the base knowledge, they can handle the occasional stretch task if the AI gets stuck.
The novice programmer, however, is helpless. They cannot even understand half the words in the manual. Having the AI explain and teach them enough to allow them to solve the problem together will be time consuming, expensive, frustrating, and may be futile.
AI Assisted Programming reliably handles the easy parts. If this is the only thing you and your team know how to do, then current AIs will be adding speed but not competence, and you need to avoid taking on complicated projects.
“A” level programmers will still be employable.
Leveling Up
If I am not yet an “A” level programmer, what should I do?
One of the major pain points which turns many people off from programming is that there is too much to learn before they can even get started. When I was teaching Software Development in college, I started a lab session with a working program – a shell that did nothing, but did it well. It was a command interpreter that understood two commands: Help and Quit. There was also a compile-and-run script. The students had to take it from there and extend the code until it met some specification.
Lowering the threshold to get into the profession by starting with something that already works made sense then, and it makes sense now… except that today we need at least a React based frontend, a database, and a few built-in AIs, and perhaps a phone dev kit. There is even more to learn nowadays. We will have to use an AI to create the deep project structure that packages like React and Maven favor, as well as all config files, documentation, and release procedures. Not only in class, but in our daily work.
SuperTutor
What if we can make small React apps using an AI, but barely know what we are doing? Well, with a working system in place that already implements everything required (and which you yourself provided the product spec for) , we can examine one component at a time and learn from it. Such as databases, release procedures, git, etc. And we can talk about the component of the week with a voice based AI like GPT. “So, GPT, teach me the most important git commands”. We can immediately understand how they are used in our project, and we can now solve more advanced problems involving git.
Repeat until you have enough experience points to level up.
Major Refactoring
Small bugs will be discovered and corrected by the AI without even asking, and medium size problems can be straightened out with some programmer interaction.
But occasionally, the AI reaches its capacity to hold the useful context, such as the goal of the project and lists of things it should never do, and forgets those. The result may be that it starts looping, editing a small number of files over and over, or decides to create a feature we did not ask for, or to import some obscure open source package to implement something we did not want.
Using git and committing often will allow you to back out of many problems, just like if you are managing a project with some novice programmers.
Don’t Debug — Rewrite
But suppose some part of the project spec does not work out as expected, for any of a thousand reasons well known to programmers. Rather than attempt to refactor and debug your way out of the problem, why not just edit the specification to use a better approach and start the coding over in a new empty directory and a new git repository.
Because five minutes with an AI implementing the known part of a project may well be cheaper and easier than a day of refactoring, with or without AI support.
I have used the strategy to check out a previous version of the code that still had something the AI fumbled away, to a parallel directory to the current project and then I instruct the AI to import the relevant parts of from older version or other sample code to this project, and to adapt it to fit.
My favorite commands are “adapt it to fit” and “Make it so”.
Project Resurrection
Many companies have started projects they had to abandon after significant investment. These projects can now be resurrected relatively cheaply.
I would check out the failed project or legacy code (COBOL, perhaps) to one directory and create another directory next to it.
Then I would instruct some AI to analyze the old code, and to enhance it with comments, and to create up to date code documentation and summarize project status. Also make an inventory of missing parts of the project and sketch high level algorithms for missing parts. Create a separate report listing obsolete strategies in the old code and suggest modern replacement algorithms.
And then create a product spec and an implementation plan. And ask it to start writing the code from scratch in that empty directory.
And BTW rewrite the COBOL as Java, and add more AI wherever required.
Manage Expectations
AIs are improving at a rapid rate. Be prepared to switch to the latest master level programmer AI with the largest token memory, etc. on a monthly basis. You can switch AIs back and forth in the middle of the project, from input to input, which may be useful if different AIs excel at different tasks.
Two major timesinks in AI Assisted Programming remain stubbornly human-centric. First, creating detailed specifications – particularly for complex systems like, say, complete airport operations – may take months of careful human analysis and planning. This isn't a limitation of AI, but rather reflects the inherent complexity of fully understanding and documenting real-world requirements. Simple projects can be done because the AI understands the problem in sufficient detail, but airport operations systems may not have been discussed in its corpus.
Second, and perhaps more frustratingly, debugging remains time-consuming even with AI assistance. When an AI loses track of its context due to token limitations, or makes a sequence of compounded mistakes, untangling these issues can take days – just as it always has in traditional development. Token memory limitations can cause an AI to forget crucial constraints or project goals, leading to looping or superfluous searches for trouble.
AIs don’t really do debugging. They just read the code, spot the mistake, and rewrite the whole file. Why did they not create it correctly the first time? Something that changed impacted something else that was out of scope. Human programmers have the same problems. We can argue that AIs and novice programmers alike will “stumble forward, from error message to error message”. But AIs do that hundreds of times faster, which makes it effective.
AI assisted programming still has limitations but is absolutely worth using if you have a decent fit to a manageable project. One reason to start early (and spend more money on the current, more expensive models) is to gather the personal experience and familiarity with “Programming at the specification level” in order to remain employable.
And if AI today isn’t quite up to the task, start using it anyway and adapt your processes to those limitations.
By the time you ship, AI will be good enough.
I consult and run corporate workshops on this and other AI topics.
https://zerothprinciples.substack.com/p/monica-anderson-biography