AI in the Loop of CAD and Sim

AI in the Loop of CAD and Sim

Three ingredients have been sitting next to each other for a long time:

1. Physics simulators — game engines like Kerbal Space Program, but also serious tools: FEA, CFD, SPICE, molecular dynamics.
2. CAD and engineering software — anything that lets you assemble a thing before you build it.
3. A human iterating between the two.

The third ingredient is the bottleneck. A human can run maybe one design-test-fix cycle per evening on a non-trivial project. You build, you test, you read the result, you fix one thing, you go to bed.

The new ingredient — the thing that's actually changed in the last couple of years — is an AI agent that can drive both of the first two with continuity across a full cycle. Not faster typing. Not autocomplete. State held across "I designed this thing → I ran it in the sim → I read the output → I patched the design" without the agent forgetting which run produced which numbers.

That's the only interesting claim in this post. The rest is a worked example.

The example: a satellite, overnight

I went to sleep with a broken spacecraft.

I'd asked an automated craft generator to produce a small solar-powered satellite — call it M002-C, a "solar-stable payload bus." Two extra solar panels, a battery, a probe core, a small antenna. KSP refused to load it: one part had an identifier from a mod I don't have installed.

That's where a normal evening would end. Tomorrow's problem.

Instead, while I slept, the agent did roughly this:

• Opened the .craft file, found the offending part by its identifier prefix, recognized it as a mod-renamed component, and traced what stock part it should have been.
• Surgically removed the bad part definition and its link reference from the probe core. Verified that the part count, brace count, and staging were consistent. Synced both copies of the file (the one in the project repo and the one in KSP's Ships/VAB/ directory). Backed up the originals before touching them.
• Pulled the kOS control script — the one that actually flies the rocket — and ran a second-opinion review on it. Surfaced a list of latent bugs in the launch and circularization logic. Wrote them up as a punch list for the morning.
• Left a note explaining what it found, what it did, and what was still uncertain.

I woke up, ran the launch, and immediately lost the spacecraft.

The bug it caught and the one it didn't

The agent had flagged the bug. I didn't insist on patching it before flight. That's on me.

Here's what went wrong. The control script's circularization burn worked by repeatedly asking, "how much more burn do I need to circularize at my current apoapsis?" and stopping when that number reached zero. The function it called read the current apoapsis fresh every tick.

But the burn itself was raising the apoapsis. So every tick, the "target" moved further away, the answer never got smaller, the engine kept firing, and the apoapsis climbed from 86 km to over a thousand. By the time the script gave up, the periapsis had collapsed into the atmosphere.

It's a feedback loop. The thing measuring "how much more do I need?" was being moved by the thing it was measuring.

The fix is small: snapshot the target altitude once before the burn starts, and use that frozen value for the dV computation. Add a guard that aborts the burn if apoapsis runs more than 20% past target.

The agent read the telemetry log line by line, identified the runaway, wrote the patch, synced the script to the kOS volume, and handed the relaunch command back.

Second flight: stable orbit. Periapsis above the atmosphere. Solar panels deployed. Power gained over the 90-second post-deploy choreography — the battery went from 304.8 EC to 310 EC, meaning the panels are generating more than the bus is consuming. Which is exactly what a "solar-stable payload bus" is supposed to do.

M002-C in stable Kerbin orbit after the patched circularization burn. The terminal receipt shows STATUS ORBITING, EC 310, and solar_stable_payload_passed.

The loop, drawn out

Strip away the spacecraft and the loop looks like this:

generate a candidate design
   ↓
load it into the simulator
   ↓
run a scripted test
   ↓
read the telemetry
   ↓
diff against the spec
   ↓
revise the design or the control logic
   ↓
repeat

You and I can do that loop. We've always been able to do it. The question is how many times we can run it per night.

A human iterating attentively does one cycle in an evening. The same human, splitting attention between this and dinner and Discord and a tired brain, maybe does two cycles in a weekend.

An agent driving the same loop, with the simulator running at game-speed and the agent reading CSVs at machine-speed, can do many cycles in the time it takes you to sleep. The wall-clock bottleneck stops being "a human reading the log" and becomes "the sim running the test."

That ratio is the actual thing.

What we could have done, and didn't

This is the part that bugs me a little.

Last night's run was a single craft, fixed serially: load, fail, fix, load, fail, fix. One thread. The agent was doing the loop, but only one variant at a time.

The version of this that's actually interesting is: while I sleep, run twenty craft variants in parallel. Different panel counts. Different battery configurations. Different attitude-hold strategies during the eclipse pass. Different orbit insertion altitudes. Each one flown through the same mission script, each one logged.

I wake up not to "the one craft is fixed" but to a chart — a Pareto frontier of mass vs power-margin, or fuel-burn vs orbit-stability — and I pick. Or the agent picks and tells me why.

That's a different kind of morning. We didn't have it today. We could have.

The general claim

The reason this generalizes outside a video game is that the ingredients aren't unique to KSP.

• The "physics sim" can be any honest simulation: FEA for a bracket, SPICE for a circuit, a fluid solver for a coolant loop, a real-time controller-in-the-loop bench for an embedded system.
• The "CAD" can be any tool that exposes its file format or its API: SolidWorks, KiCad, OpenSCAD, Onshape, a parametric scripting layer over any of them.
• The "control script" can be any test harness that exercises the design under realistic conditions.
• The agent in the middle is what's new. The thing that connects the design tool to the simulator and holds the state of the experiment in its head across the whole cycle is what didn't exist before.

When the simulation is faithful and the intelligence is actually intelligent, you can build things — or discover that things are buildable — that you didn't realize were within reach. Not because the AI is doing the design, and not because it's doing the piloting. Because it's providing the continuity between design and test that humans can't sustain at scale.

The satellite in orbit is a small example. The framing matters more than the rocket.

What's next

The honest next step is to run that twenty-variant overnight. Then to do the same loop somewhere it actually matters — an embedded board, a printed part, a small chemistry sim. The KSP version is a sandbox. The sandbox is the point of the sandbox.

If a video of the launch shows up at the top of this post later, that's because I went back and captured one. The post stands on its own without it.