Hot TAIke One: Software Development is going back to its roots
There is no getting around it, we can bury our heads in the sand, but LLMs like Anthropic’s Opus 4.5 or OpenAI’s Codex can do a fair chunk of the job for us Software Developers. I belive this is cause for us to change our relationships with our careers of choice.
But what if we thought of this as a good thing? What if writing less code ourselves allows us to return to the roots of our profession? Two books that I read at University, and a number of times after come to mind: The Mythical Man Month and the Pragmatic Programmer.
These are two books that you would be mistaken as thinking are about programming. Well, they aren’t they describe the broader topic of the Software Development Lifecycle; the process that results in an artefact that we know as code.
They describe what I think is the social aspect of our jobs. The discussions with our stakeholders, the experience of producing requirements and defining those.
Whilst it has been a while, I regularly marveled at the artefacts discussed in the books. “Manuals” and “Functional Requirements”. Exhaustive lists of functional requirements:
- F1. Allow user to make a search from the home screen
- F1.1. When the user taps the search bar, it opens the search interstitial
- F1.2. yawn, these were so boring, even more annoying when QA told us our implementation was wrong
- F2. Allow users to see their past searches
- F2.1. …
Why was this the way? Well, code was expensive! Deploying accounting software to an IBM mainframe took time. Debugging took longer. You could say that code was expensive. A mistake could be costly, measuring twice with exhaustive requirements was a good thing.
This isn’t the case nowadays. Software Development has made a shift left. We have concepts such as Continuous Integration and Deployment. If you make a mistake, or miss a requirement it’s fine we can just push a new release. Code became cheaper. We don’t write the great technical documents of yesteryear.
But now, code has become incredibly cheap. It is now cheaper for my employer to ask Claude Code to resolve simple bugs. Let’s take a lifecycle issue, this does not require specialist knowledge. Claude Code just Googles the issue and finds a solution to the problem.
So, how do I as a Software Developer justify my and my team mates roles in two to three years?
What do all of those technical documents above have in common? They all exhaustively define requirements for a system. What do LLMs need to do a good job? Exhaustive requirements. They can’t Google what we need from them to satisfy our user requirements, but we can tell them that.
In cheapening the cost of code, we’ve returned to a time where code was expensive. The similarity between them is the requirement for manuals and well defined requirements.
So I think it is time to blow the dust off the covers of the books of our elders in order to rediscover the art of exhaustive definitions of requirements.