No silver bullet — why we need human engineers

I remember when AI coding first showed up and the code was not very good. We looked at it and said, ok, there is no way this replaces your job. Then the quality got better very quickly, good enough to handle real tasks quite confidently, and everybody around us started saying software engineers will be replaced by AI.

We are about a year into this surge now, and my observation is close to the opposite. The market value of software engineers, especially senior engineers and above, has increased a lot, contrary to what people predicted. A lot of companies that never used to have a real development or technical department decided to build one, either to use AI or to make their own systems, because they thought they could now. Those companies need real engineers to handle AI and implement plans. At least in Japan, I see a lot of job listings for exactly that.

My prediction is that as long as clients are human, shepherds need to be human as well. I went looking to see whether that was only my feeling. What I found was not about the job market. It was about the shape of the work, and it is much older than I expected.

The shepherd was described in 1983

Lisanne Bainbridge published a paper called Ironies of Automation in Automatica in 1983. Her argument is that when you automate most of a job, the human is left with exactly the parts nobody could work out how to automate, plus the new job of watching the automation run.

So the operator’s role does not get easier. It gets harder, and they need more training, not less.

That is the shepherd, described more than forty years before we started calling it that.

Brooks split the difficulty in two, in 1986

Fred Brooks wrote No Silver Bullet in 1986. He separates the difficulty of software into two kinds. Accidental complexity, which comes from our tools and languages, and essential complexity, which comes from the problem itself.

His point was that you could drive the accidental part all the way to zero and still not get anywhere near the improvement people hoped for, because the expensive part was always working out what to build.

AI coding has taken an enormous bite out of the accidental side. Boilerplate, syntax, the first draft of anything. It has not touched the essential side, which is the part where somebody has to decide what the business actually needs.

AI amplifies whatever you already are

The 2025 DORA report on AI-assisted software development surveyed close to 5,000 technology professionals, and their headline finding is that AI is an amplifier. It magnifies whatever an organization already is. Strong teams get faster. Struggling teams get their existing problems louder.

Their conclusion is that the return does not come from the tool. It comes from the system around it- the quality of the internal platform, how clear the workflow is, whether the teams are aligned.

Which is another way of saying a company cannot buy AI and skip the humans, because the humans are the part being amplified.

The translation is the cost

The layer between business goals and technical requirements is the hard one to replace. That translation is a cost, and it is a cost that is very difficult for AI to take over, at least for now.

Professional assistance from human engineers is absolutely required to make something that is going to be used inside a company in a true sense. Not built. Used.

Citations

• Lisanne Bainbridge, Ironies of Automation, Automatica, 1983
• Frederick P. Brooks Jr., No Silver Bullet: Essence and Accidents of Software Engineering, 1986
• Google Cloud, DORA State of AI-assisted Software Development, 2025