Early in my career I worked on a program where the analysis group was blamed, repeatedly and formally, for schedule slip.
The complaint was reasonable on its face. Stress sign-off was the last gate before release, and stress sign-off was late. So the program did the obvious thing and bought more compute.
It changed nothing. The solve had never been the problem.
I have thought about that program many times since, because it illustrates something that took me years to say clearly: in aerospace structures, the metric that governs is time to first article, and almost none of that time is spent solving equations.
What the clock is actually measuring
“First article” is the first production part built to the released design, the one that gets inspected against the drawing and either passes or sends everyone back to work. Time to first article is the interval from a design intent existing to a physical, conforming, defensible part existing.
Between those two points sits a structural analysis cycle that looks, in practice, roughly like this.
You wait for a loads deck. You get one, and it is preliminary. You wait for geometry. You get one, and it is not the configuration the loads were built for. You reconcile the two, or more often you build the model anyway with a note about it. You clean geometry that was created by someone with no idea it would be meshed. You idealize. You mesh. You apply a load case matrix, and somewhere in that matrix is a case that nobody can tell you the origin of. You solve, and this part takes twenty minutes. You post-process. You find something. You go back three steps. You solve again. You write the report. The report goes to review. Review produces a finding, sometimes about the physics and often about the traceability. You go back four steps.
Then the configuration changes, and a meaningful fraction of that work is done again.
If you have ever tried to account honestly for where an analyst’s month went, you know the shape of the answer. A small slice is modeling judgment, the part that requires an experienced engineer and could not be done by anyone else. A slightly larger slice is real interpretation of results. Everything else is preparation, reconciliation, repetition, and documentation.
The last category is the one nobody puts on a chart, and it is the one that sets time to first article.
Why this is the interesting problem for AI
I have been skeptical, in public and at some length, about AI in simulation. My skepticism has never been about capability. It has been about placement.
Most of what gets pitched aims at the wrong slice. Surrogate models that replace the solve are attacking the twenty minutes. Tools that suggest modeling approaches are attacking the part that should stay with the engineer, because that is the part nobody can verify after the fact.
The connective tissue is different. Fetching the current configuration. Reconciling a loads deck against a geometry revision and flagging the mismatch instead of quietly proceeding. Applying a documented cleanup and meshing recipe. Running a load case matrix from a controlled source. Extracting the same twelve quantities you always extract. Assembling the report in the template your organization has used since 2014.
That work is repeatable, deterministic, and checkable. It consumes a large share of the calendar. And it is where an agentic system can take real time off the clock without asking you to trust it about anything that matters.
The aerospace-specific catch
There is a reason aerospace has been slower than other industries here, and it is not conservatism for its own sake.
Our output is not a number. It is evidence. A stress report is an artifact that has to survive a certification review, potentially years after the person who wrote it has moved on. Every value has to trace back to an input, an input version, a method, and a decision, and the trace has to be legible to someone who was not in the room.
This makes automation harder, not easier. A tool that produces the right answer with no defensible provenance has produced nothing usable. Automation in this domain has to generate the trail as a first-class output, not as an afterthought, and that requirement rules out a great deal of what is currently being marketed.
It also means that when organizations like NASA and Airbus have actually put this into production work, the interesting part is not that it worked. It is what they had to do to make it defensible.
Which is why I am recommending this session
On September 29, Synera and Aviation Week are running a joint session titled Time to First Article: NASA, Airbus and Agentic AI, with speakers from both organizations walking through their aerospace engineering use cases.
The format is what makes it worth your ninety minutes. It is not a panel about the future of AI. It is engineers from two of the most process-constrained organizations in the industry describing projects they actually completed, with technical detail attached.
I have written a lot in this newsletter about the gap between what simulation tools promise and what they deliver on a real program. This is a chance to close some of that gap with evidence rather than opinion, from people whose evidence standard is higher than most.
Speakers:
Patrick Kunert - Head of Cost & Value Engineering, Airbus Aerostructures.
Mike McClary – Moderator - Writer and Editor, Aviation Week.
Ryan McClelland - AI Infusion Lead, NASA Goddard Space Flight Center.
Wallace Scott - Head of US Business Development, Synera
As always, register even if the time does not work. Registration gets you the recording.
The question I will be asking
If I get to ask one, it is this.
Not “how much faster was it,” because that number is easy to produce and hard to trust. The question is: what did you have to change about your process to make the output defensible in a certification context?
That answer is the one that tells you whether this is a tool or a toy. I will report back on what I hear.
Disclosure: I write about the sessions I think are worth your time, and my assessment of them stays my own.
The twenty-minute solve time is rarely the actual problem. You hit it right, the schedule gets set by what happens before the fix, or what prevents it from being discovered in the first place. For security, we spend too much effort optimizing response when the detection mechanisms themselves are failing. The real cost comes from not seeing the breach for months, not from the time it takes to patch a single vulnerability once identified. That initial blind spot, that's where the damage accumulates.
https://cyrilsimonnet.substack.com/p/shinyhunters-keeps-getting-let-in?utm_source=substor&utm_medium=substack&utm_campaign=comment
"Surrogate models that replace the solve are attacking the twenty minutes"
I don't share the same feeling. Surrogate models are here mostly to address HPC intensive calculations, where the time unit is the hour (if not the day), not the minute.