The Internal Software Factory
Put software engineers on architecture and let domain experts vibe-code their own tools.
- Difficulty
- Advanced
- Time to result
- ~months to results
- Steps
- 6
- Confidence
- 78%
Hardware companies quietly run on software they refuse to call software: complex spreadsheets with scripting inside them, sitting on individual laptops, handed between disciplines by email, with no source control and no automated testing. This framework re-cuts who writes what. Software engineers stop writing features and start writing architecture: the frameworks, data flows, division of concerns and repeatable pipelines that domain work will run on, because that is what their training in systems and algorithms is actually for. Domain experts then vibe-code their own pieces inside that architecture, because they hold the physical knowledge the model needs and now have an interface to express it. The output is a collapse in the cost of iteration. Analysis that took one engineer a day per part becomes a real-time tool, and a very small team covers work that previously needed a department. A side effect is that the enterprise tools you used to buy become internal builds.
Origin
Extracted from Naval, where Blake Scholl describes how Boom Supersonic turned traditional hardware engineering workflows into software and then split the roles once agents arrived.
Core principles
- 01Most hardware engineering is already software, just badly versioned software.
- 02Architecture is the scarce skill; implementation is not.
- 03The person with the domain knowledge should hold the keyboard.
- 04Cost of iteration is the real productivity metric.
- 05If you can build the tool internally this week, you should not buy it.
How to run it
- 1
Inventory the hidden software
Walk the engineering org and list every spreadsheet, script and manual conversion that carries real analysis. Treat each one as untracked, untested production software, because that is what it is.
Pro tip Ask where a handoff happens by email. That is almost always where an automated interface belongs.
- 2
Move software engineers up a layer
Reassign your software people from building features to building the architecture: systems design, data flow, division of concerns, source control, automated testing. They are the only ones who will get these right.
Pro tip Judge them on whether the framework they built multiplies other people's output, not on what they shipped directly.
Watch out If you keep them on feature work you will never have enough of them, which was the original constraint.
- 3
Hand the keyboard to the domain expert
Let aerodynamicists, structures engineers, technicians and operators build their own pieces with agents inside the architecture. Their domain knowledge is the input the model cannot supply.
Pro tip Start with the analysis each person already runs manually every week; the spec is already in their head.
Watch out Without the architecture layer first, this produces a new generation of unversioned silos.
- 4
Automate the cross-discipline conversion
Wherever two disciplines exchange results, replace the manual conversion with code so the loop runs continuously instead of once per request.
Pro tip Real-time feedback in the loop changes behaviour more than raw speed does, because engineers start exploring.
- 5
Instrument the cost of iteration
Track how long one full design change takes end to end. That number, not headcount or ticket throughput, is what this restructuring is meant to move.
Pro tip Re-measure after each new model generation, since the same tooling gets cheaper to extend.
- 6
Audit what you no longer need to buy
Review the collaboration and analysis tools you license. Once internal builds are cheap, most category tools are worse fits than what you can generate on demand.
Watch out Do not extend this to infrastructure and standards where compatibility with the outside world is the point.
In the wild
A turbine blade is cold when installed and hot when running, so it changes shape. Designers must reconcile the cold shape and the hot shape while converting between structural and aerodynamic analysis. Classically this took one engineer one day, for one blade, for one piece of the analysis, and a jet engine has around a thousand blades. Boom's software and hardware people together built a tool where blade geometry can be changed with structural and aerodynamic results visible immediately.
→ Two engineers can design an entire jet engine, work that previously scaled with headcount per blade.
Spreadsheets won originally because nobody could get custom software written, so a grid plus scripting was the closest available approximation. Once agents make custom software cheap, teams move their models into real code, typically Python, where simulations are believable and testable, and the spreadsheet stops being the system of record.
→ Analysis moves under source control and automated testing instead of living on laptops.
Common mistakes
Hiring more software engineers instead
The old failure mode was never having enough software headcount to automate hardware workflows. Adding headcount to the same structure just makes the bottleneck more expensive.
Letting domain experts build without architecture
Agent-generated tools without a shared framework recreate the silo problem in a new format, with no source control, tests or interfaces between disciplines.
Calling the spreadsheet layer not-software
Treating complex scripted spreadsheets as documents rather than code is what keeps them outside testing and version control in the first place.
Is it for you?
Best for
Hardware, deep-tech and other physical-product teams that could never afford enough software engineers to automate their engineering workflows.
Not ideal for
Pure software teams where the domain experts already are the software engineers, so there is no split to make.
From the transcript
“there's a lot of engineering hardware engineering that happens in Excel spreadsheets on engineers laptops in a silo”
“the software engineers actually create the architectures because they understand systems, they understand algorithms”
“you can change blade geometry you can see in real time the structures and aerodynamics results”
From the episode
Full Episode: The AI Industrial Revolution