Model the part, not the cut
Software Architecture
October 23, 2026
4 min read
Koen Mannaerts
Chief Software Architect ยท Process and Design Lead

Building Software in the AI Era, Part 1

Topics Covered:
  • From Doing the Work to Designing It
  • The Model Does Not Document the Fighter
  • Lose the Model, and You Take the Product Apart
  • The Architect Updates the Plan, Not the Brief
SCROLL TO ARTICLE

From Doing the Work to Designing It

Everyone is asking the same question: how will we build software now that AI can write it? The answers change every week. Assistants, specs, agents, swarms, dark factories. Before guessing where software is going, it helps to look at the industries that already went through this. They automated how things get made long before we did. And they all ended up in the same place.

Start with the machine shop.

First, an operator turns the handwheels of a lathe and cuts the part by feel and skill. One slip, and the part goes in the bin. Then the machine gets a readout. You enter the coordinates and the machine holds them. Still manual work, but the slips are gone. Then someone writes the steps down as a program. Now you can review it before you run it, optimise it, and run it again tomorrow.

Then CNC and CAD. You describe the part, and the machine works out the best way to cut it. At no stage did the machinist disappear. The unit of work got bigger each time.

The human moved from doing the work, to instructing the work, to designing the work.

Four stages in the machine shop: manual lathe, mill with readout, CNC machine, CAD to CNC. The unit of work grows from one cut to one assembly.
Four stages in the machine shop: manual lathe, mill with readout, CNC machine, CAD to CNC. The unit of work grows from one cut to one assembly.

The Model Does Not Document the Fighter

The F-16 first flew more than fifty years ago. It is still flying, in many variants, with decades of repairs and modifications behind it. That is only possible because of the plans: detailed plans of every component. They let the US Air Force trace the configuration of each aircraft, manage the variants, and produce replacement parts. Changes are validated against the model before anyone touches the aircraft.

The plans are meant to outlive the people who drew them. Some of the original suppliers no longer exist, and the model is what is supposed to remain.

The model does not document the fighter. It keeps the fighter operational.

Lose the Model, and You Take the Product Apart

It didn't always. Suppliers went out of business, and drawings were lost with them. So the Air Force commissioned two F-16s to be taken apart and scanned, part by part, to rebuild the model: a digital twin of the structure, the hydraulics, the fuel system and the environmental controls. The aim: try a modification virtually (more armour, a bigger engine) before building anything, and manufacture replacement parts from the model.

An earlier F-16 repair shows what that is worth. Engineers built a digital model of a damaged tail section, used it to decide where to drill and mill, and returned an asset worth roughly $600,000 to $1 million to inventory. The cost of not maintaining the model is rebuilding it from the finished product.

Software teams pay that cost every day. When the design isn't kept, we work out the system from the code upwards: reading files, tracing calls, asking whoever still remembers. AI can now do some of that reading for us, and soon it will read all of it. But even then, the code only tells you what the system does, not what it is supposed to do.

To control software, we need a model layer on top of the code.

The F-16 digital twinConstruction: one blueprint kept current

The Architect Updates the Plan, Not the Brief

Anyone who has built or remodelled a house knows the next part. You go to the architect with questions, examples and a sketch on a napkin. Two weeks later you get a plan. You look at it and say: that's roughly what I meant, but the kitchen needs to be bigger, and that window wider.

The architect doesn't go back to your first notes and rewrite your requirements. They update the plan. They move the kitchen, enlarge the window, and show you the new revision. Nobody says: go read the history of our conversations and work out where we ended up. Everyone looks at the plan. And what gets built matches revision C of the drawing, not the original brief.

Nobody Tests Every Bolt

On an assembly line, nobody checks that every bolt was fastened. Nobody tests every weld. At that speed, inspecting everything would stop the line.

Instead, manufacturing builds quality into the process. That is Lean Six Sigma: tune the line until it produces only a few defects per million parts, and check samples along the way. When a defect does get through, trace it to its root cause and design it out of the process, so it doesn't come back on the next run.

Lean Six Sigma: spot checks along the line, root cause traced and designed out
Lean Six Sigma: spot checks along the line, root cause traced and designed out

Quality is a property of the line, not of the inspection.

What If Software Isn't Different?

Machining, aviation, construction, manufacturing. Different industries, same pattern. There is a model. They keep it current. They build from it. The people didn't leave. They moved up, to the model. We like to say software is different. Maybe. But what if it isn't? What if it works exactly the same way, and we just haven't made the jump yet?

Next in this series: software is climbing the same curve without a drawing, and the LLM isn't the machine we think it is.

Read Part 2: The Code Is a Side Effect

Related Articles