Building the bridge, not tightening the bolts
How AI changed what I spend my time on as an engineer, and why I still need to be able to zoom back in.
Since 2025, a lot of my work as an engineer has moved up a level. I spend less time writing code line by line and more time deciding what should be built, how the pieces fit together, and how I will know that it works.
I think of it as building the bridge instead of tightening the bolts. Most of us have taken a step back. But I don’t think that means the bolts stopped mattering.
How we got here
This is not the first time engineers have stepped back. We moved from machine code to assembly, from assembly to compiled languages, and then to frameworks, libraries, and cloud services. Each step let us stop thinking about something that used to take a lot of our time. And each one probably looked, to someone, like the end of programming.
It never was. It changed which problems we worked on.
What feels different this time is what we stepped away from. Before, we moved further from the machine. Now we are moving further from the code itself. The new layer works in natural language, and it doesn’t always give the same answer twice. I will come back to that, because I think it is why the details still matter.
Building the bridge
The engineer who designs a bridge doesn’t tighten its bolts. Their job is to know what each bolt has to hold.
That is closer to how I work now. An agent can write most of a pipeline in minutes. What it can’t do on its own is know why the pipeline exists. Someone still has to understand the problem and its constraints: the budget, the access we have, how fresh the data needs to be. Someone has to decide how the pieces connect, what we are willing to trade off, and how we will check that the result is correct.
In a way, software is arriving where other engineering disciplines have long been. The work moves from building every part by hand to specifying, connecting, and verifying them.
Zooming in
Stepping back is not the same as letting go.
As Joel Spolsky put it, abstractions leak: sooner or later, a detail from the layer below shows through. A query costs ten times more than expected. A table ends up with duplicated rows. A number in a report doesn’t add up, and nobody can explain why. When that happens, someone has to go down a layer and look.
Say an agent writes an incremental load for you, and the tests you wrote pass. A week later, a total in a report is slightly higher than it should be. At first glance, everything looks fine: the pipeline runs, the schedule works, the tests are green. When you zoom in, you find a join on a key that isn’t unique. Your tests assumed it was, which is why they passed. Some records match twice and are counted twice.
Nothing in the high-level view would have told you that. You had to read the SQL.
As far as I can tell, there are only two reasons we write software in programming languages instead of simply describing what we want: scalability and predictability. Once the code is written, it can run millions of times for almost nothing, and it does exactly what it says every time. That includes counting some records twice. From a distance, you can see what a system is meant to do. Only up close can you see what it will actually do.
That matters more now than it used to. The agent that writes the code may not give the same answer twice. The code it writes has to.
What I find unusual about software is that almost every layer can be opened. You can read the generated code, the source of the library it calls, or the query plan the warehouse produced. A civil engineer can’t take a beam apart at three in the morning to see what went wrong. We can, often in a few minutes.
For me, going down those layers is what separates engineering from operating a tool. If you can never go below the top layer, you depend on the tool being right.
Zooming in is also a skill you lose if you don’t use it. That is the question I find hardest: how does someone learn it if they never had to tighten the bolts? I don’t have a good answer yet.
We were never paid to type. We are problem solvers, and programming languages remain the most scalable and predictable tools we have. The way we write code has changed. What we need from it hasn’t.
It is early days. I am not sure which bolts are worth checking every time, or how much of what I think now will hold in a year. Some of it I will probably understand better by getting it wrong first.
We took a step back to see the whole bridge. That is fine, as long as we remember where the bolts are and can still go and check them.