Every AI Panic Point Has a Precedent. One Doesn't — Mary Shaw at ICSA 2026

Mary Shaw co-wrote the book that gave software architecture its name, with David Garlan, thirty years ago. Her ICSA 2026 keynote in Amsterdam spends most of its length on history, which turns out to be the setup: she uses it to sort the current anxieties about AI into the ones the field has already survived and the one it has not.

The pattern she is drawing on

Her historical section is not nostalgia. It establishes a shape: a new idea arrives, is oversold as universal, and is then absorbed as one useful abstraction among several. She is explicit that objects went through exactly this:

“There came a time at which everybody was talking about how objects are going to solve all our problems, which has a flavor kind of like AI is going to solve all our problems. But I kept realizing that there were problems that objects weren’t going to solve.”

That is what produced architectural styles in the first place — noticing that pipes and filters were not objects, and that the field had a folklore of organisations nobody had catalogued. Her summary of progress in the discipline is the sharpest one-line definition of abstraction we have heard:

“The mark of going upward to the right is how big is the conceptual chunk that you don’t look inside of.”

The panics that are re-runs

Applied to the current moment, she takes the standard list of AI concerns one at a time and finds precedent for each.

Concern	Shaw’s precedent
Huge, complex data	”We dealt with terabytes of data before. We dealt with complex structured data before.”
Opacity of reasoning	Third-party components: “in practice it’s opaque. We dealt with practical opacity even if we didn’t really believe it was opaque.”
Non-determinism	”We’ve had non-determinism ever since we have had software that controlled physical objects.”

Her conclusion from the list is deliberately calming:

“The properties that people are concerned about have analogs in software engineering. Software engineering can evolve from the analogs to deal with the AI versions of the same thing. It’s not something we need to freak out over.”

And earlier, more bluntly: “We don’t need to be scared of AI. We’ve dealt with them before. We know how to make treaties with them. They give us new concepts. We incorporate them. We forget where they came from.”

The one that is not a re-run

Then the exception, and it is not on the usual list:

“The real issue for us is that software has relied on our roots in formal symbolic reasoning. Even if we know we can’t prove something, we still have this itch to write down a specification and show that it really is correct… And that rigorous symbolic reasoning is fundamentally different from statistical prediction.”

“The big thing that we should be thinking about… is understanding how we can come to deal with probabilistic reasoning rather than [purely] symbolic reasoning. That shift, I think, is the fundamental one that we should be working on.”

Her characterisation of what these systems actually do is the least sentimental in circulation:

“There is no semantics there. There’s no intent. There’s predictive replication of similarity. If you’re looking for that, I’ll give you something that looks like something that I’ve seen before.”

Note that she does not treat this as a complaint. Her next line is that a great deal of what software work consists of really is similarity.

The most usable thing in the talk

The function points analogy is the part to take back to work. Shaw recounts objecting to function-point effort estimation on the grounds that “obey the laws of physics” and “when you see this signal, turn the green light on” are not the same amount of work — and then concedes the method works well in one specific domain:

“Function points work really well in relational databases… because adding a new transaction to a relational database is just like adding the last transaction to a relational database. That’s the kind of thing that AI is going to be helpful with, rather than inventing and conceptualizing new things.”

That is a test you can apply to a task before you hand it to an agent. Does this task resemble the last one of its kind? If yes, prediction from similarity is exactly the right tool and you should expect it to work. If the task’s whole content is that it is unlike anything you have done, you are asking a similarity engine to do the one thing it is defined not to do.

It also explains the lopsided results teams report. Scaffolding, CRUD endpoints, test fixtures, migrations, another integration like the last four — high similarity, high hit rate. Novel domain modelling, a first-of-its-kind concurrency design, deciding what the system should be — low similarity, and the tool produces something that looks right, which is worse than producing nothing.

Where to push back

Shaw’s calm is well earned and it is also selective. She is candid that she has not worked in software architecture for ten or fifteen years, and the reassurance rests on a discipline absorbing new abstractions at conference-and-journal speed. The current adoption is not running at that speed, and her own exception is the reason it matters: if the symbolic-to-statistical shift is genuinely unprecedented, then “we’ve handled disruptions before” is evidence about the wrong reference class.

She also notes speed and scale remain the open problems, and moves on quickly. Those are the two that are hardest to absorb through process maturity.

Worth watching

Fifty-seven minutes, and the AI section starts around 33 minutes if you want the argument without the history. The history is better than the argument, though. Watching someone who was present at the creation of a discipline explain how the last universal solvent got absorbed is the most useful preparation available for watching it happen again.