Software Engineering 2.0

Every industry names its jobs long after it already has them.

The masons who built the great cathedrals were not called structural engineers. Nobody had named what they actually knew, and the title came centuries later.

We are sitting in that gap right now.

A NATO conference in 1968 put the words software engineering in its title, on purpose and to provoke. For the nearly sixty years since, our industry has had many jobs and one promise. Whatever you wrote, the machine followed exactly, and every practice we built, every test, every review, every standard, rested on that exactness.

The exactness is what changed. The machine still executes exactly, but what it executes now is a model whose behavior nobody wrote down, and a system that decides cannot be instructed the way a system that executes can.

Software engineering did not just gain a new tool. It gained a whole stack, and no one engineer stands at every level of it, which is why so many good engineers now feel they have quietly become bad ones.

Altitude

Every role in this new profession has an Altitude, and Altitude in its essence is the layer of the stack where that person creates value, nothing more or less. It is not their seniority, not their years, and not how difficult their work is, it is simply where they stand.

The floors run from the metal upward, so the higher the floor, the closer the work sits to a person’s purpose and the farther it sits from a computation.

Altitude is not exactly a ranking. The floors carry numbers, but an engineer writing a CUDA kernel and an engineer designing an agent’s authorization model are not junior and senior to one another, they are not even doing the same kind of thinking.

In 2021 I wrote Coders, Programmers, Developers & Engineers, and that ladder still stands. It measures how much of a floor you can carry, from a single component to an end-to-end solution, and Altitude measures which floor.

This matters because we keep having one argument under many names.

Is prompting real engineering? Do you need to understand transformers? Is an AI engineer a real title?

Those are all the same question asked badly. The real question is what Altitude someone operates at, and whether they understand enough of the Altitude below them that the machinery stops looking like magic.

The Building

Think about everyone it takes to put up a building.

Someone smelts the steel. Someone else calculates the loads. Someone runs the electrical.

Someone decides where the walls go so a family will actually want to live there. And someone, long before any of them, decided a building should exist on that lot at all.

None of them can do each other’s jobs. None of them is the real one. The person choosing the kitchen layout is not a lesser engineer than the person who milled the beam, and the person who milled the beam cannot tell you whether anyone wants to live there.

A crew still spans the whole building, and a crew of engineers can still span this stack. As I wrote in Meatware in 2021, engineering crews carried a product from requirement gathering all the way to delivery, and the stack I described then was the software, the infrastructure, and the people. This one starts at Silicon, and it runs deeper than that one did.

Building intelligent software is like putting up a building, it takes a different trade on every floor, and no single trade is the building. We understood that about buildings a very long time ago, and we are only now relearning it about intelligence.

The Floors

The stack, as I see it today, runs from Silicon to the decision that software should exist at all. For each floor there is an objective, the skills that serve it, and the role it produces.

Our industry already names some of these roles. It is still spelling out others. One I am adopting from an older trade, and only one I am naming myself, because naming a job that does not exist yet is how a profession admits what it needs.

Where I say a floor is undersupplied, or valuable, or where the work is going, that is my read and not a measurement. Nobody is counting these roles yet.

0/ Silicon. The objective is to make mathematics physical. The skills are compute architecture, memory bandwidth, and VRAM, then interconnects and precision formats, then the thermal and power ceilings that decide what is possible. The role exists, it is called hardware engineering, and almost no software engineer will work here.

1/ Bare Metal. The objective is to turn a file of weights into words on a screen. The skills are kernels, quantization, and the KV cache. Our industry is still settling on a name for it, inference engineering is the closest, and it is the most undersupplied role on this list.

2/ The Forge. Here the objective is to create or reshape the intelligence itself. The skills are datasets, tokenization, and embeddings, then architecture, pretraining, and fine-tuning, then LoRA, distillation, and the optimizer mathematics underneath all of it. The roles are machine learning engineer and research engineer, and they are older than anything I am naming here.

3/ Assembly. The objective is to make a model useful inside real software. Tool calling, structured output, and agents live here, then orchestration, RAG, and memory, then context, routing, fallbacks, and evaluation. Our industry calls this AI engineering, and it is where most software engineers will spend the next decade.

4/ The Seam. The objective is to fit a probabilistic component into a deterministic organization without destroying the guarantees that organization already provides. The skills are identity, authorization, and auditing, then reversibility and human approval, then exposing existing capability through tool interfaces rather than rebuilding it.

The title Integration Architect already exists in enterprise integration, and I am adopting it for this floor because the Seam is where that job was always headed. What is new is the material being integrated, a component whose behavior is model-driven rather than written down. Of everything on this list, this is the most valuable job in the profession we are about to have.

“A perimeter that authorizes each act before it happens, not a log entry after.” That is what I wrote in LLooMA 2.0, Rebuilt on The Standard Agent, and it is what belongs on this floor. Give an agent hands without that perimeter and you have built a sandcastle.

5/ The Hand. The objective is to get real work out of intelligence you did not build. The skills are context, decomposition, and model selection, then delegation and verification, then knowing when not to reach for it at all.

Prompt engineer is the closest title, and it names the smallest part of the job, so I call the rest of it Usage Engineering. Being good at a tool is a skill, but being able to say in advance what you will get from it, and to prove it afterward, is engineering, and the reflex to dismiss that is the same reflex that once dismissed the people who were good at search.

On this floor the human owns the decision and the model proposes. As I wrote in Robots & Monkeys, “The distinction is whether AI is extending human thought or replacing it.” Usage Engineering is the first of those, or it is not engineering at all.

The person who lets the model do the thinking and carries the result is not practicing Usage Engineering, they are what I called an AI Monkey.

6/ The Room. The objective here is to change how people work, not how software runs. The skills are workflow design, process, adoption and training, and the judgment to tell the tasks worth automating from the ones worth protecting. The names our industry is trying cluster around the word enablement, and none of them has won yet.

7/ The Ask. The objective is to decide what should be built at all. The skills are problem framing, scoping to what a probabilistic system can actually promise, and the honesty to say when a deterministic system was the correct answer. This is product, and the old title no longer covers it.

8/ The Ledger. The objective is to decide whether any of it is worth doing, and the skills are the economics of tokens, latency, and hardware, then privacy, then the constant tradeoff between quality and cost.

FinOps already sits closest to this floor, and its AI practice prices tokens, weighs GPUs, and routes the simple questions to a smaller model.

It does all of that from outside the engineering loop. What is missing is not the discipline, it is the owner: the engineer who prices an agent loop before it runs and owns the tradeoff at the moment it is made.

The tooling is ahead of the title. The Standard Agent already bounds every run with a budget, so the primitive exists even if the owner does not, and I expect the first companies to lose real money to an agent loop will create the role.

Back in the building, the beam is Silicon and Bare Metal, the loads are the Forge, the electrical is Assembly and the Seam, the kitchen is the Room and the Ask, and the lot is the Ledger.

The Hand is the one trade the building never had, because no tool on a building site ever decided anything, and this one does.

The Loop

The same three questions appear at every floor.

What do I know? What should I do? How do I make it happen?

Those three are Data, Decision, and Direction, and this is the Tri-Nature I wrote about in 2021, the same one that gives The Standard its dependencies, purposes, and exposures.

I already published this form of it in The Standard for Agents, where Data is what the agent has, Decision is what the agent thinks, Direction is what the agent does, and Orchestration is what binds them into agency.

Data gives a system knowledge. Decision gives it intelligence. Direction gives it reach.

None of the three alone gives it agency, the loop that binds them does.

At the Forge, Data is a training corpus, Decision is the reasoning being shaped into the model, and Direction is the training run that does the shaping. At Assembly, Data is retrieval and memory, Decision is the agent choosing, and Direction is the tool call. At the Hand, Data is the repository and the error you paste in, Decision belongs to you, with a model you did not train proposing over context you did give it, and Direction is the shell you let it run.

Direction is the one people miss. A model that can only produce text acts through a person, and a person can still say no. Give it a shell, an API, a filesystem, a browser, and it acts on real things with nobody in between.

And the three are a loop, not a line. A thermostat runs that loop, and a rule a person wrote is computation, not Decision. When the thing choosing the next step is a model rather than a rule you wrote, that loop is what an agent actually is.

Every Floor

A floor is where one person is accountable. A vertical is what every floor is accountable for, and burying one inside a single floor is how teams get hurt.

Data is the first. It trains the model at the bottom, grounds the application in the middle, and becomes the context you paste at the top, the same substance at a different Altitude.

Evaluation is the second, and it is the one most often missing.

Training loss is an evaluation. A benchmark is an evaluation. An agent success rate is an evaluation.

Checking whether the answer you were just given is actually correct is an evaluation too. AI engineering without evaluation is like programming without tests, it does not work.

Security is the third. Prompt injection, data leakage, tool authorization, sandboxing, and model behavior belong to every Altitude at once.

Economics is the fourth. Tokens cost money, context costs memory, latency costs customers, and a larger model is very often the wrong answer to a problem a smaller one already solved.

The Address

A map earns its keep only if it tells you where the next thing goes.

To place a role, ask which floor it creates value on, then which of the three questions it owns there.

An engineer tuning a retrieval index sits at Assembly, on Data. An engineer designing what an agent is permitted to execute sits at the Seam, on Direction. A person who has become extraordinary at getting work out of a coding agent lives at the Hand, on Decision, and reaches into all three.

Those are the two coordinates. A role has a home there and reaches into the cells around it, the way the electrician touches every wall without owning one. Every role in this profession, present and future, has a home.

That is what makes the map expandable. When a job appears that none of us has seen yet, and several will, you do not need a new framework. You need to ask the same two questions.

The Future

You do not have to learn these nine floors from the bottom up, and I would not advise it.

Start at the Altitude where you want to create value. Then learn enough about the floor beneath you that it stops being magic, and enough about the floor above you that you know who you are building for.

Enough about the floor beneath you is not a license to lose your own. You must be able to do the work you are delegating with the machine switched off, or you are not standing on your floor, you are being carried.

The engineers who struggle in the next ten years will not be the ones who never wrote a kernel. They will be the ones who never figured out which floor they were standing on, and so kept answering questions that belonged to someone else.

We are early enough that the names are still open. Cathedrals were built for centuries before anyone said the words structural engineer, and the masons kept building without the name.

We will keep building too. But this time we get to choose the words, and I look forward to seeing the next generation of engineers choose them on purpose and build a profession worth standing in, a profession worth being excited about.