(Large Language) Model-Based Design
Old ideas, new tools, and a shift in how we work
I spent close to ten years at MathWorks working on Stateflow, a key part of the Model Based Design (MDB) toolset. My time there was a front row seat to how engineers in the automotive, aerospace, and industrial automation industries build software for safety-critical systems.
What stood out to me was how these tools changed where people spent their time. Engineers using these tools tended to be domain experts on the systems and they were modelling. They focused on behaviour, edge cases, system design and verification. Our tools enabled fast design exploration, and when they were confident, the tools generated the code.
That model works because the complexity of these systems and the cost of mistakes in these contexts is high. Writing code by hand does not scale. With Model Based Design, the model became the spec. You can run it to understand the behaviour of the system and catch problems before they made it into code or hardware. The result is trust and confidence in the system being built.
Jack Little’s (MathWorks co-founder and CEO) talk about the history and impact of Model-Based Design is a must-watch. What MathWorks tools enabled control system engineers to do has some parallels with the benefits we’re starting to get from the use of LLMs and agents in traditional software development.
Here’s a slide from the talk, which if looked at in isolation, might have come from a presentation about the benefits of LLMs for code generation (except for the “executable specification” part - for now!):
Fast-forward 8 years
Over the past few weeks and months, I’ve increasingly been a part of conversations about the effects of AI on the software engineering profession.
How does it benefit engineers at different stages of their careers? How does it affect roles that are software engineering “adjacent”? How do we help software engineers - particularly those early-in-career - build judgement and expertise on technical systems? Are we moving to a higher abstraction level of building software?
With LLMs and agents as our code generators, we’re spending less time typing out code. The focus has shifted to:
Being clear about what the system should do.
Understanding the domain - Necessary, because a lower understanding of the domain makes it harder to verify if generated code only looks right, or is actually right.
Thinking about testing and validation to guarantee the correct behaviour for the operating conditions (inputs, context) we are designing for.
Maintaining context - markdown files containing an overview of the system, sequence diagrams, coding standards, security and quality preferences etc. - that help constrain LLMs.
Since code generation speed isn’t a bottleneck anymore, you can try variations of your designs and implementations in minutes - pushing on performance, adding constraints and exploring tradeoffs.
It starts to feel a bit like working with MBD tools instead of writing everything from scratch.
This is where some of the old ideas from Model Based Design start to matter again. Clear specs. Early validation. Tests that reflect real behaviour. Ways to verify what was generated. Strong security boundaries.
Marc Brooker wrote a great post recently on spec driven development that gets at this from a software angle - about specifications being at the core of an iterative software development and design loop.
Software engineering isn’t turning into Model Based Design overnight. The tools and workflows are different. But the direction feels familiar. We are moving toward a world where we shape behaviour at a higher level and rely more on systems to fill in the details.