October 1968. Garmisch, Germany.

More than fifty people from eleven countries meet at a conference sponsored by the NATO Science Committee. Computer manufacturers. Universities. Software houses. Users. The topic is software, and how hard it has become to build it reliably, on schedule, and to specification.

The title of the conference was a provocation. The report says so:

"The phrase 'software engineering' was deliberately chosen as being provocative, in implying the need for software manufacture to be based on the types of theoretical foundations and practical disciplines, that are traditional in the established branches of engineering."

Brian Randell, one of the report's editors, later put it more simply: the title described "a requirement rather than a reality."

Requirements. Foundations. Discipline. Verification. The name was a promise.

For most of the following decades, we didn't keep it. Not because we didn't want to.

We just weren't there yet.

---

Climbing the Layers

Software grows from the bottom up. Layer upon layer.

Assemblers freed us from opcodes. Compilers freed us from registers. Higher-level languages freed us from managing every byte. Libraries, frameworks and IDEs freed us from rewriting the same plumbing in every project. I wrote about this pattern in AI Is a Multiplier.

Each layer turned yesterday's craft into today's foundation. And each layer left the same job on top: someone still had to write the code. Lots of it. By hand.

Construction ate the day. Engineering got what was left.

Architects and Coders

When I started my professional career in the early 90s, the industry had an answer for that: split the work.

Architects designed. Coders implemented, working from specifications they had no part in writing. Back then, "coder" was not a compliment. Not in the demoscene sense, where it was a title of honour.

Taken one step further, the split crossed continents. Around 1995 at IBM, the plan was simple: replace five software engineers in Germany with ten coders in India. It ended with twenty coders in India, overseen by eight engineers in Germany.

The engineers didn't engineer. They supervised.

The split failed in two ways.

Latency. A question took a day. A misunderstanding took a week. A wrong assumption took a release. By the time the code came back, the reasoning behind the design was gone.

Ownership. "We built what you specified." Responsibility fell into the gap between the people who designed and the people who built. Nobody owned the whole.

None of that was about the people on either side. It was about the wall between them.

We just weren't there yet.

The Merge

The industry learned. Extreme Programming in the late 90s and the Agile Manifesto in 2001 pushed architects and coders closer together. "Working software over comprehensive documentation." The distinction between designing and building didn't disappear. It moved into the same team, and often into the same person.

That shortened the feedback loop. It also put two jobs on the same desk. The engineer and the mechanic.

The problem was never the work itself. It was the volume. Boilerplate. Glue code. Migrations. Plumbing between services. The mechanic work filled the day, and the engineering happened in between.

My own path went from code, to software design, to architecture. Each step up bought more time to think, and less contact with the code. For a long time, that felt like the only trade available.

In 2011, David Parnas wrote that the most accurate title for the people then called "Software Engineers" would be "Paid Software Developers". His argument was about professional standards and the difference between engineering and programming, not about the value of the work. Few of them had any education in software design. Harsh. But it points at the same gap the 1968 report named: a requirement, not yet a reality.

---

Keeping the Train of Thought

Engineering is a loop.

Understand the requirements. Come up with solutions. Verify them. Choose.

The second step was always the expensive one. Writing a solution took days. Writing a second one took another week. A third one, if anyone asked, took a sprint.

So nobody asked. We took the first solution that worked and locked it in. Not because it was the best. Because exploring further cost more than anyone could afford.

The hidden cost was never just time. Variants spread over weeks and months cost the train of thought. By the time variant B exists, the reasoning behind variant A is gone. The comparison happens between a memory and a diff.

AI doesn't just implement one solution faster. It makes exploring several of them affordable. That changes the shape of the loop.

Take a frame budget. At 60 frames per second, everything has to fit into 16.67 milliseconds. A particle system blows it.

The one-shot version: implement the most promising fix. Profile. If it fits, ship it. An alternative would cost another week, so there is no alternative.

The exploring version: understand where the time goes. Describe three approaches. Pooled CPU particles with tighter culling. A GPU compute path. Fewer particles with smarter level of detail. Let AI write all three. Benchmark them on target hardware. Compare frame time, memory, visual quality and maintenance cost. Choose.

For a contained problem like this, that can take hours or days instead of weeks. Not every problem is this contained. But the second and third variant are now affordable to attempt. Integrating and validating them can still be expensive.

The whole problem stays in one head, from requirement to decision. Variants run in parallel, or in rapid succession, instead of spread over months. Requirements can be questioned while the solutions are still fresh. Verification becomes the main work, not the afterthought.

That is not less engineering. It is the loop, finally fitting into a single train of thought.

The Mechanic Changed. The Ownership Didn't.

Now the honest part. We have seen this split before.

AI is a mechanic that works in minutes, in your editor, without time zones. Latency, the first failure of the old split, has collapsed.

The second failure is not.

It is easy to repeat the IBM story with a new mechanic. Engineers who no longer engineer, but supervise. Reviewing an endless stream of generated diffs. Approving what they did not design and do not understand. Twenty coders, eight supervisors. Only faster.

Vibe coding is the same failure, without even the supervision.

And this time there is no gap to hide in. No team on another continent. No "we built what you specified." The model cannot own the decision. Neither can the process. I wrote about how responsibility dissolves in rituals in The Merge Ritual.

The mechanic changed. The ownership didn't.

Checking generated code is not the same as owning the solution. Checking asks whether the code looks right. Ownership asks whether the solution meets the requirements. Under load. Under change. In the hands of users. And if it doesn't, it's yours to fix. Checking is part of the work. Ownership is the job.

---

Closer

In 1968, "software engineering" described a requirement rather than a reality.

For decades, most of us spent most of our time on the mechanics. Not for lack of ambition. The layers below us weren't tall enough.

Code is becoming the cheap part. What remains is the work most of us got into this profession for. Understanding the problem. Coming up with solutions. Proving which one is right. Owning the result.

Nobody knows where this ends. More layers will come. But for the first time in a long while, software engineers get to engineer software.

We just weren't there yet.

Now we're closer.