It could be said that a software engineer spends a whole career learning to cross a very specific bridge. It is usually when confronted with the real world that we learn there were always two.
The bridge we teach is the one that runs from a specification to working code. You are handed a problem, more or less well defined, and you learn to turn it into something a machine will actually run, in a particular language, with particular tools and libraries. Years of courses go into it, and then more years of real work. It is genuine craft, and it is mostly a matter of form. Given a clear enough description, there tends to be a right way to build the thing, and a good engineer comes to know the way. A more disciplined engineer also learns to write it in a way it will be maintainable, for his future self and others. Semantics to syntax.
The other bridge sits before that one, and we mostly cross it without quite noticing we are on it. It runs from a wish to a specification. Someone, the business, a client, a visionary, and often enough yourself, holds a picture that is still a little out of focus, and does not always know exactly what they want, or how to say it. Turning that into a description precise enough to build from is not really a technical act. It is understanding the domain, and what the technology can honestly do, and what is worth building at all, and what people actually reach for once it is in front of them. It is the harder of the two crossings, and it is the true craft of an experienced engineer, the kind who has watched many projects reach maturity and knows, almost in the hands, what holds and what quietly comes apart. Pragmatics to semantics.
For most of the history of the field these two ran together, and we rarely bothered to tell them apart. Then the assistants arrived. With the right framework around it, an AI coding assistant turns out to be very good at the first bridge, the one from specification to code. Give it a clear, bounded description and it writes valid, idiomatic code faster than you can read it, and it does not tire, and it does not cut the corner at two in the morning. The crossing that took us years to learn, it has mostly learned too.
What it cannot do, at least not on its own, is the other one. It cannot sit with a half-formed wish and feel which parts really matter, or which of them will not survive contact with a real user, or what a person actually needs as against what they first thought to ask for. That still wants a human, working with an aligned team, with the sort of communication that seems to grow only between people who have built things together. And here is the part I find quietly hopeful. The bridge the machine took over is the one we already knew how to teach. The one it leaves us is the one that was always more a matter of judgment than of typing, and judgment is not a thing you regenerate by spending more tokens.
So the work does not disappear. It moves, and it moves upward, toward the harder crossing. I have come to think of it as a sort of elevation of the engineer and enabling of the uninitiated, though I say that carefully, because it is not true for everyone and certainly not overnight. The ceiling of what you could build on your own used to be set by how fast your hands could produce correct code. That ceiling seems to be lifting, slowly, toward how well and how completely you can describe what you actually want. If you can specify a system fully and correctly, more and more you can simply have it. Implementation times are collapsing.
None of this points to fewer people who understand software deeply. If anything it asks for more of them, and asks more of them. Someone still has to stand on that first bridge and say, plainly, this is what correct means here, before a single line exists. That was always the hard-won part of the job. It is only becoming, now, most of it.
We were taught to cross one of these bridges with great care. The other we mostly learned by living, project after project, and rarely named out loud. It seems a good time to pay it the attention it always quietly deserved.
---
*The white paper, the field guide, and every experiment behind this are open access:* https://doi.org/10.5281/zenodo.21726017 · https://pragmaworks.dev