A liquid-fueled rocket engine was designed by software, printed in copper, and successfully fired on a test stand.

The sentence sounds like the beginning of a science-fiction story. It is not.

In June 2024, a team at the University of Sheffield tested a small rocket engine generated by Noyron, the computational engineering model from LEAP 71. The university says the design was produced autonomously, without human intervention during that specific execution, that the engine was printed in copper, and that it worked during its first hot-fire campaign.

But there is an important difference between that fact and the most spectacular version of the story: “AI is already a better rocket engineer than humans.”

That conclusion has not been demonstrated.

What is happening may be even more interesting: part of the engineering knowledge that once lived in specialists’ heads, spreadsheets, simulators, and CAD processes is starting to become executable logic capable of producing physical geometry directly.

And when that geometry can move almost immediately to a metal 3D printer, the bottleneck changes.

This article starts from the video El mejor ingeniero de cohetes del mundo no es humano, checks its main claims against technical sources, and separates three things that are often mixed together under the word “AI”:

  1. language models;
  2. physics-based computational engineering;
  3. automated cycles of design, manufacturing, testing, and learning.

The third is the one that could truly transform engineering.

The story that is actually documented

On June 28, 2024, the University of Sheffield published the results of a test carried out with LEAP 71 and other collaborators.

Its description is quite concrete:

  • the engine was designed using Noyron, LEAP 71’s Large Computational Engineering Model;
  • the design was produced autonomously during the model’s execution;
  • the component was manufactured through copper 3D printing;
  • less than two weeks passed from final specification to manufacturing;
  • a new design iteration can be generated in minutes;
  • the engine completed a successful hot-fire campaign.

The university also makes something clear that sometimes disappears from the headlines: its engineers provided practical feedback during development of Noyron’s code.

In other words, an artificial intelligence did not appear from nowhere, read the Internet, and independently discover how to build a rocket engine.

The real sequence looks much more like this:

human engineering knowledge
        ↓
physics + rules + manufacturing constraints
        ↓
Noyron computational model
        ↓
engine specification
        ↓
manufacturable geometry
        ↓
metal 3D printing
        ↓
hot-fire
        ↓
experimental data
        ↓
model refinement

That semantic difference matters because it tells us what kind of automation is actually advancing.

Noyron is not ChatGPT for CAD

When we hear “AI designed an engine,” the modern intuition is to imagine something like this:

Prompt: "Design a 5 kN rocket engine"
                 ↓
              model
                 ↓
             CAD file

That is not a good description of Noyron.

LEAP 71 presents it as a computational engineering model. Its goal is to encode first-principles knowledge and engineering logic: thermodynamics, fluid dynamics, heat transfer, materials, geometry, and constraints associated with how the part will be manufactured.

That changes the nature of the problem.

An LLM operates primarily on representations learned from large amounts of data and produces probabilistic sequences. A system like Noyron tries to turn an engineering intent into a coherent physical object by applying rules and models with explicit physical meaning.

A useful simplification would be:

LLM
text/data → learned representation → text/code/actions

Noyron
requirements → physics + engineering + manufacturing → physical geometry

That does not mean one architecture is “more intelligent” than the other. It means they solve different problems.

For a rocket engine, it is not enough for the shape to look correct.

It must simultaneously survive:

  • high pressures;
  • combustion temperatures of thousands of degrees;
  • cryogenic flows;
  • extreme thermal gradients;
  • vibration;
  • material constraints;
  • minimum wall thicknesses a printer can manufacture;
  • internal channels through which coolant must flow;
  • real tolerances of the manufacturing process.

A pretty render is useless.

The result has to obey physics and then survive when the valve opens.

Why 3D printing is the piece that makes the leap possible

There is another reason this story is happening now rather than twenty years ago: additive manufacturing removed many of the geometric constraints that defined traditional design.

In conventional manufacturing, an engineer does not design only what would be physically optimal. They also design what can be machined, cast, welded, and assembled at reasonable cost.

That introduces constraints such as:

can a tool reach here?
can we drill that channel?
how many welds do we need?
how do we assemble these parts?
can we inspect the joint?

Metal 3D printing changes the solution space.

NASA explains, for example, that parts that traditionally might require hundreds of welded components can be reduced to one or two printed pieces. That integration is not merely aesthetic: it reduces operations, interfaces, possible failure points, and manufacturing time.

SpaceX was already printing SuperDraco chambers a decade ago

NASA documented in 2015 that SuperDraco engine chambers for Crew Dragon were 3D printed.

That matters because it shows additive manufacturing in propulsion did not begin with the current AI wave.

The industrial foundation had been maturing for years.

Rocket Lab industrialized the approach with Rutherford

Rocket Lab describes Rutherford as an engine whose primary components can be printed in about 24 hours.

The company took that idea into repeatable production and orbital flight.

We are no longer talking about an experimental part fired once in a laboratory. We are talking about a real production chain for a commercial launch vehicle.

Relativity pushed the idea to the full vehicle

NASA notes that Terran 1 was approximately 85% 3D printed by mass, including its body and engines.

Its March 2023 flight did not place its payload into orbit, but Relativity confirms that the vehicle passed through Max-Q, the point of maximum aerodynamic load.

That matters because it demonstrates something different: a rocket built largely through additive manufacturing can survive an extremely demanding part of real flight.

The conclusion is not that printing is automatically better.

The conclusion is that manufacturing has gained enough geometric freedom to accept designs that an algorithm can explore far more aggressively than a CAD process constrained by traditional tooling.

From CAD to an executable function

Here is the conceptual difference I find most interesting.

A traditional CAD design can be viewed as an artifact.

A model like Noyron tries to turn the process that produces that artifact into a function.

Conceptually:

engine = design(
    propellant="LOX/RP-1",
    thrust=5000,
    chamber_pressure=...,
    material="CuCrZr",
    manufacturing="LPBF",
    boundary_conditions=...
)

The function does not simply contain a frozen three-dimensional model.

It contains logic capable of producing a family of engines.

That is why Sheffield’s statement that a new iteration can take minutes is more important than the eye-catching fact that the first engine worked.

If the design were only a CAD file created quickly, we would have a one-off automation.

If what exists is a generalizable function that can regenerate geometry when thrust, propellant, pressure, material, or constraints change, then we have something closer to physics-based generative engineering software.

And software can run again.

And again.

And again.

The aerospike: a much more interesting test

LEAP 71 did not stop at the small conventional engine.

On December 18, 2024, it tested a 5 kN aerospike in Westcott, United Kingdom, fueled by liquid oxygen and kerosene. The company says it was autonomously generated by Noyron, printed as a monolithic copper-alloy piece, and worked on the first attempt.

Why is that interesting?

A conventional engine uses a bell-shaped nozzle optimized for a range of ambient pressure. As the vehicle climbs, outside pressure changes dramatically.

An aerospike attempts to adapt more efficiently to different altitudes through geometry that allows exhaust flow to expand against the surrounding atmosphere.

The attraction has existed for decades.

So has the problem.

The central spike is directly exposed to extremely hot combustion gases and needs difficult cooling. LEAP 71 designed a structure with internal channels in which cryogenic oxygen helps cool that region.

This is exactly the kind of geometry where both parts of the revolution meet:

geometry difficult for humans/conventional CAD
                    +
internal channels difficult to machine
                    ↓
computational engineering + metal 3D printing

It does not prove the aerospike problem has been “solved.”

It demonstrates that the combination makes it possible to explore design spaces that were previously expensive to investigate.

Then came a test that makes the story more credible, not less

In December 2025, LEAP 71 announced tests of two 20 kN methalox engines generated by Noyron: one conventional bell-nozzle engine and one aerospike.

According to the company, the conventional engine reached steady state at nominal pressure and thrust.

The aerospike, by contrast, encountered problems during startup transients and managed only one combustion, although it reached full chamber pressure.

That detail is valuable because it breaks an overly perfect narrative.

Real engineering looks like this:

model
  ↓
prototype
  ↓
test
  ↓
unexpected problem
  ↓
data
  ↓
updated model
  ↓
new iteration

Not this:

magic AI → perfect design → end of engineering

Failures appearing during scaling are exactly what we should expect.

The value of the approach will depend on how much it reduces the time and economic cost of learning from those failures.

“Without human intervention” needs a large footnote

Two statements can be true at the same time:

Noyron autonomously generated the geometry of a specific engine.

And:

Noyron exists because of a huge amount of human engineering.

There is no contradiction.

Humans:

  • designed the model;
  • selected equations and approximations;
  • decided which variables matter;
  • encoded manufacturing rules;
  • developed the printing process;
  • prepared the hardware;
  • instrumented the test stand;
  • defined success criteria;
  • interpreted experimental data;
  • modified the system based on those data.

Autonomy appears inside a concrete boundary of the process.

We can visualize it like this:

┌───────────────────────────────────────────────────────┐
│                    HUMAN SYSTEM                       │
│                                                       │
│  physics → rules → materials → process → validation  │
│                       │                               │
│                       ▼                               │
│              ┌────────────────┐                       │
│              │     NOYRON     │                       │
│              │                │                       │
│ requirements▶│ autonomous     │─▶ geometry            │
│              │ design run     │                       │
│              └────────────────┘                       │
│                       │                               │
│                       ▼                               │
│              manufacturing + test + data             │
└───────────────────────────────────────────────────────┘

Saying “no human designed that engine” can be correct if we mean the design execution itself.

Saying “humans are no longer needed to design engines” would be a conclusion the evidence does not support.

Project Prometheus confirms the idea goes far beyond rockets

Another element of the video that initially sounded exaggerated also turned out to have substantial backing.

Project Prometheus, co-founded by Jeff Bezos and Vik Bajaj, began with about $6.2 billion in funding and in 2026 announced a $12 billion round at a $41 billion valuation.

Bezos has publicly described the objective as building an “artificial general engineer.”

He is not talking simply about another chatbot.

The ambition is to apply models to creating physical objects and compress design and manufacturing processes that today require large teams and cycles that can last years.

Bezos compared it, simplifying somewhat, to a radically modern version of CAD.

The existence of Prometheus does not prove that vision will work.

It does show the market is beginning to treat the automation of physical-engineering knowledge as its own category, important enough to attract tens of billions of dollars.

That brings the topic close to what is often called Physical AI, although the term covers many different technologies.

SpaceX: from “basically no AI” to internal infrastructure

There is another interesting contrast.

In May 2024, Elon Musk publicly said SpaceX and Starlink used “basically no AI” because the available tools were not especially useful for their needs.

Two years later, SpaceX job listings show a very different picture.

The company is hiring engineers for an internal high-performance inference platform and describes a team called SpaceX Internal AI Infrastructure. It also lists Applied AI roles explicitly aimed at designing, evaluating, deploying, and integrating language models and agentic systems into SpaceX products and infrastructure.

In addition, in July 2026 Musk publicly said that SpaceX’s large internal corpus of engineering data —excluding ITAR-restricted material— would be incorporated into Grok’s supplemental training.

The strategic direction is clear:

2024
current AI → little usefulness for SpaceX

2026
models + agents + internal infrastructure
         +
institutional engineering knowledge
         ↓
tools integrated into real workflows

That does not mean Grok will autonomously design Raptor tomorrow.

It means one of SpaceX’s most valuable assets —years of decisions, tests, failures, telemetry, and accumulated knowledge— is starting to be treated as machine-readable capital.

The real shift: closing the loop

So far we have discussed separate pieces.

The powerful hypothesis appears when they are connected:

     requirements
         │
         ▼
┌────────────────────┐
│ engineering model  │
└─────────┬──────────┘
          │
          ▼
       geometry
          │
          ▼
┌────────────────────┐
│ metal 3D printing  │
└─────────┬──────────┘
          │
          ▼
       hot-fire
          │
          ▼
      sensors/data
          │
          ▼
┌────────────────────┐
│ analysis + models  │
└─────────┬──────────┘
          │
          └───────────────► next iteration

SpaceX made famous a culture of build → test → fail → learn → repeat with humans coordinating the cycle at high speed.

The new question is what happens when growing parts of that cycle can be executed computationally.

An engineer may spend days or weeks rebuilding CAD, rerunning thermal analysis, modifying channels, checking manufacturability, and preparing documentation.

An engineering function can be run again.

The printer can manufacture a variant without rebuilding molds or tooling.

The test stand can capture thousands of signals.

A software system can incorporate that data into the next decision.

The potential economic leap is not only about “removing people.”

It is about dramatically increasing the number of learning cycles a team can complete per unit of time.

From two iterations a year to a hundred a day

The video uses a provocative comparison: a human might iterate a design a few times, while a model could do so hundreds of times.

The exact number depends entirely on the problem. But the intuition matters.

In traditional engineering, every iteration carries coordination costs:

requirement change
→ meeting
→ CAD
→ analysis
→ review
→ manufacturing
→ inspection
→ test
→ report
→ new meeting

If part of that knowledge is encoded, some steps stop being manual activities and become reproducible execution.

This transformation looks a lot like what happened in software with CI/CD.

Before:

code → manual integration → manual build → release

After:

commit → pipeline → tests → artifact → deploy

In physical engineering we may be seeing the first blocks of something equivalent:

spec → model → geometry → manufacturing → test → telemetry

The analogy is not perfect because atoms are much more expensive than bits.

A rocket test consumes propellant, degrades hardware, requires facilities, safety protocols, and real manufacturing time.

But that is precisely why removing weeks of work between two tests can have enormous impact.

What is still NOT demonstrated

It is worth setting clear limits because this area is especially prone to grand headlines.

1. A 5 or 20 kN engine is not a Raptor

Scaling an engine is not a matter of multiplying dimensions.

Different problems appear in combustion, cooling, stability, feed systems, turbomachinery, vibration, acoustics, and structure.

The fact that Noyron can design functional small thrusters does not yet show that it can autonomously produce an orbital engine generating millions of newtons.

2. Hot-fire is not flight qualification

A successful firing is an important signal.

But a flight engine must survive multiple conditions, margins, thermal cycles, vibration, manufacturing tolerances, acceptance testing, and reliability requirements.

3. Manufacturing still introduces reality

Even a mathematically correct design can fail because of:

  • porosity;
  • internal roughness;
  • heat treatment;
  • distortion during printing;
  • tolerances;
  • contamination;
  • imperfect inspection.

The model must understand not only ideal physics but the statistics of the real industrial process.

4. The loop is not fully autonomous yet

Today we can observe individual parts of the cycle being automated.

We do not have public evidence of a general chain where a system:

detects failure
→ diagnoses cause
→ modifies its physical model
→ designs the correction
→ sends it to manufacturing
→ runs the test
→ decides whether to accept the result

without significant human supervision.

That would be a much larger leap.

5. Encoded knowledge can encode mistakes too

An engineering function reproduces its assumptions with extraordinary consistency.

That is an advantage when the assumptions are correct.

And a risk when they are not.

Automation does not remove the need for independent validation; it may make it more important.

The most important asset may stop being the CAD file

For decades, an engineering company accumulated value in:

  • drawings;
  • CAD files;
  • simulations;
  • procedures;
  • spreadsheets;
  • documentation;
  • and, above all, the tacit experience of its engineers.

The new paradigm attempts to move part of that value into executable models.

That changes what intellectual property means.

The asset would no longer be only:

engine_v37_final_FINAL.step

It could be:

engine_model_v37(specification) → manufacturable_engine

The first describes an object.

The second describes a capability to generate objects.

That difference is enormous.

A new version of “software is eating the world”

For years, digitalization mainly meant converting administrative or information processes into software.

Then generative models began producing text, images, audio, and code.

The frontier shown by Noyron and similar projects is different:

software starts producing engineering decisions directly, and those decisions end up converted into metal.

We are not talking only about a copilot recommending which button to press in CAD.

We are talking about turning part of the act of design into a computable function.

And that shift can extend far beyond rockets:

  • heat exchangers;
  • turbines;
  • electric motors;
  • cooling systems;
  • structural components;
  • semiconductors;
  • chemistry and materials;
  • industrial machinery.

The more complex the interaction among physics, geometry, and manufacturing, the greater the potential value of encapsulating that logic in a reusable model.

So is Noyron “the best rocket engineer in the world”?

We do not have evidence to say that.

It has not designed and operated a system comparable to the sector’s highest-thrust, most mature engines. It does not have decades of flight history. It has not demonstrated that it can replace an entire propulsion team.

But that is not the useful comparison.

The useful comparison is this:

What happens when a good engineering team can turn a growing part of its knowledge into an executable model that generates new solutions in minutes?

There we are dealing with something real.

Sheffield verified a functional engine generated by Noyron. LEAP 71 later advanced toward aerospikes and higher-thrust methalox engines. NASA, Rocket Lab, and Relativity show that additive manufacturing is already mature enough to carry complex geometries into real hardware. Bezos is financing a huge bet on an “artificial general engineer.” And SpaceX, which in 2024 said it used practically no AI, is now building internal infrastructure for models and agents.

Individually, each signal is interesting.

Together they point to a deeper transition:

engineering as document
        ↓
engineering as software
        ↓
engineering as executable loop

The future does not have to look like an AI sitting in the engineer’s chair.

It may be something much more radical: human teams designing the systems that design the machines.

And in that world, the important metric will not be who draws the part.

It will be who can build the best learning loop between model, metal, and reality.

Sources