A rocket is an awkward product to develop. It combines delicate electronics, extreme temperatures and enormous quantities of propellant, then attempts to leave the planet before anything important melts. Customer support opportunities during this process are limited.
Yet modern rockets increasingly develop through a familiar software rhythm: model, test, inspect, revise. Designs come in versions. Automated checks expose problems. Measurements feed the next iteration. Aerospace engineers have worked this way for decades; more powerful computing and faster manufacturing are tightening the connections between each step.
Software itself has meanwhile discovered vibe coding: describe what you want to an AI and, in its most carefree form, accept the result without examining the machinery underneath. Agentic AI goes further, operating tools to write, test and revise code. The capabilities are substantial; even their developers emphasise verification. A hypothetical launch review ending with “the agent says it fixed everything” would nevertheless benefit from a second agenda item. Possibly an evacuation plan. Anthropic on evaluating coding agents
Rocket engineering makes the value of verification particularly tangible.
Take the digital twin: a digital representation connected to data from its physical counterpart. For an engine, this can combine models of pressure, temperature and mechanical behaviour with measurements from actual tests. As the hardware reveals its peculiarities, engineers can improve the model. A handsome computer rendering becomes considerably more useful when it starts admitting where its predictions were wrong. NASA on digital twins
Suppose an engine takes longer to start than expected. Comparing measured pressures and temperatures with simulated behaviour helps engineers investigate why. An RL10 modelling study validated an engine model against firing-test data before connecting it to a simulated launcher mission. This allowed investigation of how conditions during flight could affect subsequent engine starts. The computer gets to explore the uncomfortable possibilities first. Rocket Engine Digital Twin
Computational fluid dynamics, or CFD, supplies another part of that virtual laboratory. It approximates how fluids move and interact: air rushing around a rocket, exhaust expanding from a nozzle, propellant flowing through an engine. Each problem demands suitable assumptions, numerical methods and computing resources. “Run the simulation” can conceal quite a substantial electricity bill.
NASA used CFD to build aerodynamic databases for the Space Launch System, including surface pressures, structural loads and forces during booster separation. One detailed simulation modelled 22 exhaust plumes interacting during that manoeuvre. This is the sort of group project in which absolutely everyone must leave in the correct direction. NASA’s SLS simulation work
The calculations still need comparison with experiments. Wind tunnels, engine firings and flight measurements reveal where predictions hold up. A simulation with incorrect assumptions can produce an extremely detailed picture of something that will never happen.
Then comes hardware-in-the-loop testing. Real flight computers and avionics are connected to a simulator that supplies realistic flight signals. The computers issue commands; the simulated vehicle responds; updated signals return to the computers. This happens with the timing the actual control system expects.
Engineers can introduce a sensor failure or disturbance and watch how the system reacts. Faults in timing, interfaces and integration become visible while the expensive machinery remains conveniently indoors. NASA’s Integrated Avionics Test Facility uses this approach to verify SLS avionics and flight software. The rocket’s computers can have a thoroughly unpleasant flight without the rocket leaving the building. NASA’s testing facilities
Eventually, hardware must encounter actual physics. Rapid prototyping makes those encounters more frequent and focused. An injector, tank or valve can answer a specific engineering question before an entire vehicle depends on the answer.
Additive manufacturing helps by reducing the time and tooling required for certain components. ESA’s Prometheus engine programme, developed by ArianeGroup, uses it extensively to reduce part counts, production time and waste. Inspection and testing still follow. A printer announcing that the job is complete has no authority over combustion stability. ESA on Prometheus
SpaceX has made this iterative approach unusually visible through Starship. Its account of changes after the first integrated flight test describes revisions to the vehicle and launch infrastructure, including a new stage-separation system. Flight results directly informed subsequent hardware. Each version becomes an experiment from which the next can learn. SpaceX’s development updates
Failures still require scrutiny. A destroyed prototype is useful when its data identifies a problem and supports an effective correction. Otherwise, it is an unusually expensive way to confirm that rockets are flammable.
The comparison with traditional aerospace companies therefore needs more care than the usual contest between daring innovators and people allegedly paid by the meeting. Programmes built around successive experimental vehicles can accept different risks from those preparing scarce hardware for operational missions. Suppliers, review processes and mission requirements all influence the pace of change.
Established organisations also iterate. ESA explicitly describes agile management in Themis, its reusable-stage demonstrator led by ArianeGroup. SpaceX, meanwhile, secured NASA certification for its operational crew transportation system through ground tests, simulations and demonstration flights. Both speed and formal verification have their place. ESA on Themis, NASA on SpaceX certification
The useful software lesson is to make learning repeatable: track versions, automate checks and connect every result to the next decision. AI can participate in that process. Confidence still has to survive measurement.
Gravity does not care who wrote the code. It reviews every launch in production.
No comments yet