Engineering Still Matters
Software Engineers are not AI Prompters
The word going around is that engineering has become a mindless occupation. Ask the AI agent what to do, wait, give some feedback, wait, commit, get a PR. Then go read the AI-created PRs submitted by your colleagues, most of them large and complex enough that they are hard to understand. Open your laptop, read text and press enter in a loop, close your laptop. Not exciting.
I wrote a post about this situation, and one of my arguments was that software engineers cannot reduce their work to delivering code. Being an effective engineer means delivering value through software, whether that is using AI tooling or not. The post generated a great discussion but didn’t please a friend of mine, who said, in other words: this is just management speak and it doesn’t help an engineer know what to do. Tough crowd out there.
But my friend had a point. Saying that nothing changed and it’s all about value can be true and at the same time not useful. Clearly the job is changing in many ways and engineers need to understand how to make the most of this change. In the context of a software engineer, what does it mean to deliver value?
How does a software engineer deliver value?
When I discuss this topic with engineers I work with, I usually tell the story of a project I was part of as a consultant many years ago. In that project, I was working with a much more senior colleague, the technical lead, planning a financial system for a bank.
We went through the planning process, and presented our solution to the client. The plan we presented included affordances for performance, scalability, failure recovery, amongst other technical aspects we deemed necessary given this was a critical financial system. As we were going through it, the client asked “why do we need all of this?”, to which my colleague quickly replied “because I won’t build a system that wakes me up every night”. That was the end of that argument.
That moment became a core memory for me. It was our job as engineers to define where the quality bar for this system was. That was true for that system, and it is true for every system.
Maintaining the bar does not mean just getting the next task done or doing as it has always been done. It means both delivering software as quickly as possible now, but also ensuring the cost of maintaining and evolving that software is as low as possible. As Alistair Cockburn put it, the primary goal of the game is to deliver useful, working software, and the secondary goal is to set up for the next game. Building systems that will be efficient now and in the future.
“Every software project contains a carryover to the next project, and so the strategies to use in software development should pay attention to both this game and the next game” - Alistair Cockburn
In the current AI world, playing the current game has become easier. The engineer’s job has indeed changed meaningfully now that building something takes a few prompts. However, preparing for the next one has not.
We are in a moment where the whole industry is learning. In practice, that means companies and teams are throwing agents at every problem, hoping to redefine the speed a software team can move. For the engineer, that often shows up as pressure. “Can’t AI do that?” is the current version of the question my colleague was asked many years ago. And while it might be hard to resist the pressure to just push code as fast as possible in the current moment, it is clear that we are going to see the consequences of it soon.
Software will require tokens to be designed, built, run, and maintained. A poorly designed codebase will require more reasoning for agents to deliver high-quality code, as Giles Edwards-Alexander showed in a recent experiment published on Martin Fowler’s site. Effective software delivery will mean building systems that are cheap to build, cheap to run, and cheap to evolve, since that can be what makes or breaks a product.
In this experiment, the number of tokens needed to make a change decreases as the system is refactored (Chart: Giles Edwards-Alexander, The Economic Benefit of Refactoring)
For engineers, this crisis is also an opportunity, as technical quality will remain part of the software equation. This is not a matter of the amount of craft in engineering, it is a matter of time and money. We know that an agent can build a PoC very quickly. High-quality engineering means ensuring that the agent can build the 1000th feature in a large codebase with the same efficiency.
“You are the holder of the quality bar. Nobody is going to come here and tell you that your code is not good enough”. That is the advice I often give to engineers and tech leads I work with. In most (reasonable) technology companies, your technical perspective is going to be respected. But you need to raise it, since no one else has more context than you about the project you are leading and the code you are delivering.
The advice above is more important than ever now, as the pressure for speed grows and the usual guardrails for quality, like code reviews, are breaking. The engineers on the ground now are the ones defining how software will be built, both by creating the new guardrails and designing efficient architectures. The checks code must pass before a PR exists, the architecture rules written down for humans and agents to follow, the metrics to ensure agents remain efficient as the codebase grows. No one else will do it. This is your job.
Comments