{"slug": "podcast-formal-methods-for-every-engineer-in-an-ai-powered-future", "title": "Podcast: Formal Methods for Every Engineer in an AI-Powered Future", "summary": "Gabriela Moreira, a formal methods expert at Informal Systems, discussed on the InfoQ Engineering Culture Podcast how AI is lowering barriers to formal specification and model-based testing through the Quint language, while emphasizing that defining correct system behavior remains essential human work. The conversation highlighted that AI can generate specifications and glue code, but engineers must still determine what constitutes correct or incorrect behavior.", "body_md": "In this podcast, Shane Hastie, Lead Editor for Culture & Methods, spoke to Gabriela Moreira about making formal methods accessible through the Quint specification language, how AI is dramatically lowering the barrier to entry for formal specification and model-based testing, and why defining correct system behaviour remains essential human work in an AI-driven world.\n\n### Key Takeaways\n\n- Formal methods are a practical solution to the challenge of reasoning about all edge cases in complex distributed systems, not merely an academic discipline.\n- In 2026, AI makes getting started with formal specifications far easier — engineers can ask an AI to generate a Quint or TLA+ spec for their system and immediately begin running it.\n- Model-based testing connects formal specifications directly to real code, allowing engineers to replay modelled behaviours against their implementations and catch divergence early.\n- AI removes the biggest historical barrier to model-based testing by generating the tedious \"glue code\" needed to link specifications to implementations.\n- Defining which system behaviours are correct or incorrect is essential human work that AI cannot replace — formal methods give engineers a precise, executable language to capture that judgment.\n\n### Subscribe on:\n\n## Transcript\n\n**Shane Hastie**: Good day folks, this is Shane Hastie for the InfoQ Engineering Culture Podcast. Today I'm sitting down with Gabriela Moreira. Gabriela, welcome. Thank you for taking the time to talk to us.\n\n**Gabriela Moreira**: Thank you. Thank you for having me.\n\n**Shane Hastie**: My normal starting point in these conversations is, who's Gabriela?\n\n## Introductions [[01:16](javascript:void(0);)]\n\n**Gabriela Moreira**: I am a formal methods person, I think that's the first thing I should say, and I'm very passionate about this field and I've been working on trying to make formal methods more accessible for like about eight years since I was starting to have to decide what I was going to do for my bachelor thesis.\n\nI was introduced to compilers, and I was very passionate about compilers, specifically like type systems. So I did some research work on type systems, some stuff for Haskell. And then, when I was trying to figure out what to do for my bachelor thesis, someone introduced TLA+ to me, which is a formal specification language. This was a person that worked with me, and he was like, \"I saw this TLA+ thing and I think you will like it. You should take a look\". I still don't know why he thought that, but I'm glad he did, because I really, really loved it.\n\nTLA+ is this very like mathematical specification language where you can define what your system can do and the properties. And I was really like in love with it, and I started doing tooling for TLA+ for my bachelor thesis, and then I went into my my master's, continued developing tooling for TLA+ and doing research there.\n\nAnd at the same time, I was working in the industry, I was working with like event-driven distributed systems, and understanding how difficult it is to handle all of the corner cases, all of the scenarios, and how it's expected that us developers just come up with everything in our heads. I was like, this TLA+ thing should be used more, like this is perfect for what I'm doing. At the same time, doing my master's, and then I was presenting at a TLA+ conference, and this company Informal Systems, where I work for, were there at the conference as well, and they found me. We were basically doing the same kind of tooling for TLA+.\n\nNaturally, they wanted to hire me, and I joined Informal Systems then four years ago.\n\nStarted building like more tools for making formal methods more accessible. And the tool that I've been building for the last four years is called Quint, which is a new specification language based on TLA+. The parts of TLA+ that were too difficult for new people to learn, we tried to fix that and have Quint make this more accessible version of TLA+, bringing all the good stuff while just making it easy to use.\n\nSo, yes, that's my background. And now Informal Systems is making Quint a spin-out, so we are spinning out Quint, and I'm CEO in this new initiative because this Quint has been my baby since day one, so naturally like I've transitioned into this lead developer role into CEO like over this last month.\n\n## Why Software Engineers Should Care About Formal Methods [[03:30](javascript:void(0);)]\n\n**Shane Hastie**: Cool. So why should software engineers care about formal methods?\n\n**Gabriela Moreira**: I think we already care, we just—I think formal methods is more of like a solution. I think people do think like, \"Oh, I should get into this formal methods thing. I should learn\". Like they feel this responsibility, but I don't really like that. I prefer to see formal methods as a solution to a problem they already have.\n\nA large part of the software engineering community has this problem of like not being able to think about all of the edge cases, all of the corner cases of the complex systems we are developing. It's true that some systems are fairly trivial, but most systems have this degree of complexity where different sequences of events can lead to different outcomes, and it's super hard to think about all of the possible sequences. And sequences can be like the scheduler of your operational system and when do you get the lock, or it can be the sequence of what the users intend to do on your interface, right? It can be at very different levels.\n\nSo all of us are thinking about these things all the time, and formal methods really help us think about that. It helps us define what are the sequences, what are the behaviors, and what are the properties about those behaviors, and then check things and actually find corner cases, which might be problems or not, but it helps us find those corner cases and understand better the systems we are building. So I think it's more of a solution than like a responsibility or something you have to learn.\n\n## Getting Started with Formal Methods and AI in 2026 [[04:52](javascript:void(0);)]\n\n**Shane Hastie**: All right. So if I am a software engineer facing one of these complex environments where sequence of events is likely to have an impact on me, what should I do?\n\n**Gabriela Moreira**: Well, right now, in 2026, you should try to ask your favorite AI to write some formal specification for you. Things are much easier now than it was like a year ago even, right? Where you had to like learn a new language, learn how to use this new tool, how to think in state machines. Right now you can get a much easier start, so like describing your problem or your solution, describing your system to some AI and asking, \"Come and write like a Quint specification for me\", or even a TLA+ specification if you are really into math, and you want to see the math symbols.\n\nJust getting the AI to write something for you and then not just like reading the specification it produced, but running it. Because running it is where you get most value. So you go and like, \"Okay, now run it, like model check it or give me some behaviors\". Because the specification, the model is a state machine, in which we are talking about the kind of formal methods I'm into. So you're going to define some state machine and therefore you can see the behaviors of that state machine. You'll start in some initial state and you go here, here and there, and you can see how it behaves. And like, \"Oh, now give me a behavior that does this. Now give me a behavior that reaches that\". And you can start understanding your system.\n\n## How Formal Methods Differ from Standard Test Design [[06:12](javascript:void(0);)]\n\n**Shane Hastie**: How is this different from just good test design?\n\n**Gabriela Moreira**: Test is hard and maybe it's getting a bit easier now with some tools, but when you are talking just about high-level user interactions with the system, and like maybe REST APIs, that's fairly easy to test, and then you can get some like clean tests that you can read and look at. But in most cases, or in complex cases where you actually get most value out of this, it's hard to write tests. It's hard to control when your computer scheduler is going to decide when someone gets a lock or not. It's hard to control time. It's hard to control a bunch of things on like messages delays and and all of that.\n\nSo when you have a distributed system or concurrent system, it's hard to write tests for the things you are mostly worried about. And when you are on a formal methods specification, you are actually on a much more abstract level where you can reason about these things. The tools can also help come up with the scenarios for you, while in most tests you are the ones that have to like define the scenarios, right? In formal methods, you can say like, \"Give me one scenario where I reach that super rare thing\", and then the tool will come up with the scenario for you, and then you can leverage that for testing, which you should do. You should not just leave the formal methods there in a corner and then forget about it when you're doing testing. The formal methods should be part of your testing, should be part of your even like production monitoring and everything else you do in your developer lifecycle.\n\n## Workflow Integration and Model-Based Testing [[07:35](javascript:void(0);)]\n\n**Shane Hastie**: So how do we integrate this into our workflow?\n\n**Gabriela Moreira**: Again, in 2026 it's much easier, and you can get first like generate your first spec, okay. Now when you're happy with your specification, you have seen the behaviors, you are happy with the type of properties you define, and you are kind of confident that it's a faithful representation of whatever you want, your solution or the system you already have, then you can integrate that for testing, and this is called a model-based testing. So you're taking your model, your spec, and based on that you're writing tests.\n\nAnd this requires you to write some sort of code that replays behaviors from your model against your code, your actual implementation. So this replay code we often call like glue code or even harness code. This is annoying to write. It's very boring code, like everything you change either on the model or in the implementation you have to like go and update that code, and it's like it's annoying to maintain, and I think that's the main reason why like model-based testing didn't become a thing so far.\n\nBut like with AI it really becomes something completely different because then you can just delegate that part of—because it's a very trivial piece of code also to write, so it's easy to generate. We actually last like December we developed this open-source library called Quint Connect, which is specific to Rust, but the community already developed several different ones, I think there is one for TypeScript for sure, one for Zig, and then I think there's also one for for Go, but this one I think it's not open source yet. Anyway, we we did one for Rust first, and then people can could base themselves on that and write different ones.\n\nAnd this library, it allows you to define this glue code with a very nice interface that also works as like guardrails for AI, in the sense of like it's very easy for AI to generate the code there without having to like invent anything, just fills the interfaces and it works. So this testing code becomes much easier to generate and to maintain across changes, and therefore be more integrated into the environment.\n\nWe are now working more into how to also leverage the model for runtime monitoring, so for the data from production, right? Because what you test is not always the same thing that your users do. So I we believe that like the input that comes from production from runtime is super important, and then there is this technique called trace validation, which is also like something that's hard to make feasible because you have to orchestrate your code, there's a bunch of challenges there, but we do believe that like with AI that would become easier and we are going to focus on developing infrastructure for that, so it's also connected to your like runtime monitoring, your your formal specification is also connected to that.\n\n## Precision in the Age of Generative AI [[10:07](javascript:void(0);)]\n\n**Shane Hastie**: You made the point when we were chatting earlier of precision in defining behaviour is crucial, even more crucial today in the in this realm of generative AI. How do we get that right?\n\n**Gabriela Moreira**: With a lot of understanding. Unfortunately, I think people do sometimes come to techniques like formal methods in search of like an answer, like an easy way out, that does just gives you like some check mark and say like hey, yes, go, your code is correct, just ship it. There is no such thing, I don't believe in such thing. I think you only can get closer to that check mark if you have lots of understanding.\n\nSo when you understand your system more and more, you are able to then define things like properties of your system and and really like see one behaviour and say like oh, this is good or this is not good. So you have to define this either like by defining your state machine itself in the model or by defining properties about your state machine and then refining your state machine, and you have those properties that determine which behaviours are important and which ones are correct, then that can be leveraged for testing and for defining whether your behaviours from production are correct or not too, because even if you can observe the behaviours, if you don't have anything to tell if it's correct or not, then you're not getting much usefulness out of it.\n\n## Failure Modes, Witnesses, and Understanding Your System [[11:25](javascript:void(0);)]\n\n**Shane Hastie**: So you're giving me what sounds almost like an abstraction. Is it just another layer of abstraction? At a practical level, as an engineer who's thinking about getting into formal methods, who's looking at, okay, I need to build my first state machine, I need to understand this, I'm now hitting a complex problem, where do I start? What do I do?\n\n**Gabriela Moreira**: So you have to start defining what your system is or what your solution is in some formal language, right? If you're going to use formal methods. And then, in order to understand things, you start running or model checking your specification, right? So first of all, if you just have your model, you can get some random execution of your model, that's the best thing you can get, and that can give you some insight, right? You see some random behaviour of your model. Start in this initial state and you go here, go there. And then you are going to look at that and say, \"Hmm, I don't like this. I actually don't think I can go from this state to that state. This sounds wrong\". So you go and like, either refine your model or you define some properties saying, \"I don't want this to happen\". And then you run again, and then you run with your property and verify your property.\n\nAnd then there are some different techniques we can use to get more insight. For instance, when you're thinking about distributed systems, we often define failure modes, which is not common like when you're just writing the code or just writing some pseudo-code, you're not going to define the failures, right? The failures are something that happens in the external world and you are going to handle those failures. But if failures are important to you, if the point of your software is to recover from failures or act in certain way upon failures, then you have to define what those failures are and what's your response to those failures, and this helps us understand better how your system behaves and what are the failures and what other properties of your system upon failures. So if you have more failures than you tolerate, what happens?\n\nWhich ways does your software break? Because if you have more failures than you tolerate, then you do expect your software to break, right? So you go and you define that, and then you ask the again, the model checker to run or the some simulator to run, and it will give you some behaviour like, \"Oh, so that's how my system breaks. Okay, now I understand. This makes sense. This is according to my expectation\", or, \"No, this is different from my expectation\".\n\nYou can also define what we call witnesses, and these are properties that you expect to break in order to witness some behaviours, to see something interesting happen. So if you want to challenge the tools and see how useful the tools are for you, you can say like, \"What is the rarest, most difficult thing that I can come up with? The most edgy edge case, the most cornery corner case that I can I, I'm a smart person, I developed the system, what can I come up with?\" And then you come up with this super rare scenario, and you see if the tools can find it. And that gives you like some level of confidence. If the tools are finding the scenario that you find is super rare, then it means that probably the tools are is at least as good as finding corner cases as you are.\n\nSo, this is one technique you can do. You can also use like these witnesses in combination with properties in ways to check that your properties are not being checked in a vacuum, and you can also define specific behaviours that matter to you the most. When you're defining a solution to a problem, you usually have behaviours in mind, like some specific behaviours, right? So like, what if process B tries to access this while process A holds the lock? You're thinking about these sequences in your mind, so when you write those down in a reproducible way, they become really valuable documentation that you can like send to your colleagues and communicate, and they can run the same scenarios.\n\nSo those things that we usually draw in whiteboards, they can become something executable without sacrificing abstraction, because when you're in a formal language you're saying the same abstraction level as your whiteboards or a very close level of abstraction to whiteboards, differently than testing, where you have to like set up all of these mock things and addresses and data. So this is also like one way of making those abstraction something concrete that you can look at, that you can execute, then you can put in your PR description that's checked on CI and becomes like documentation in your software, so I'm really excited about that part about the reproducible behaviours.\n\nLet me tell you about my experience in Informal Systems. Informal Systems has a bunch of like PhDs and people that are really smart in like distributed systems. And I was working with distributed systems, I've struggled to understand the most basic protocols in the past, so I did struggle with that. And everyone at Informal Systems was like, \"Oh, of course, Byzantine fault tolerance. Yes, consensus\", and they would talk about these things so naturally, and I was behind.\n\nAnd at some point, like I sat down and I wrote a formal specification for one of the algorithms, and when I was writing the formal spec, I still didn't understand. Just by writing it was not sufficient, nearly sufficient for me to understand the algorithm, but when I started running it, then I started like having those witness for those corner cases, and then I understood what the steps that led to the corner cases were. When I finally managed to write like one reproducible example for the most corner case of the entire algorithm, that's when I felt like I understood it, and I still feel like I understood that algorithm. So it felt really amazing for myself, and that's why I'm so excited to talk about it and I want everyone to try it out, so I really think that helps with understanding and confidence.\n\n## Keeping the Model and Codebase in Sync [[16:25](javascript:void(0);)]\n\n**Shane Hastie**: What's the relationship between the model and my codebase?\n\n**Gabriela Moreira**: That's a very good question. So the relationship is usually like the model should be more abstract than your code, otherwise like you lose this power of abstraction and you're basically just reasoning about the code itself, although in some cases it still makes sense because the code is harder to test than this like, because you're at least abstracting away the hardware and stuff. But how do you keep them in sync?\n\nThere are basically two techniques: the model-based testing technique that I talked about already, like you replay traces from your model against the code and check that the resulting state in your code matches the resulting state from your model step-by-step, and you can do model-based testing with like random behaviours, or you can tune it to like, \"Do you remember that witness that I wrote that was super rare scenario? Let me test that\". \"Remember that reproducible example that I wrote? Let's test that\". So that's model-based testing, and the other technique is trace validation, which is you somehow log, register your production executions, there's instrumentation things or you can just log, but you have to log some information and then based on that information, that behaviour from production, you are going to try and ask the model like, \"Is this compliant with what you said?\"\n\nAnd it's really important that you keep them in sync, and historically people sometimes write models and then leave them in like specs folder in GitHub and it just goes there to die, and no one looks at it again, and that is a problem because I've heard people, and I think it's very painful to hear those stories, but I've heard people that had a spec that was correct and the design was correct and the initial version of the code was also correct, but over time the code deviated from the spec and they had a bug in production that was not present in the model. I think that's a very sad outcome for the person who put effort in to write a specification, even before AI and everything.\n\nThere's actually a case from AWS where this happens, in October last year. In that case, the specification that they had was not a formal one, it was just like some documentation, and they had this DNS outage in October. It was actually not a design flaw. The original code was correct, and there was this bug that happened was not a bug in design, and just the code diverged from the design over time, and they found a bug. So what they did, and this was presented at a Re:Invent conference from AWS, what they did was make that model formal, and then they used their AI tool to compare like the new version of the model with the code, and they actually found a divergence just by AI looking at the code and reading the code and reading the model, it found a divergence, then they fixed the code, and they said, \"Okay, now they're not divergent anymore\". So they learned the lesson of like when things don't stay in sync, then you might the deviate from your very careful and well-thought original design, and that's very sad.\n\n## An Age-Old Problem with a Better Solution [[19:13](javascript:void(0);)]\n\n**Shane Hastie**: But that's been the case in software engineering from time immemorial. I recall, as a COBOL programmer, the problem with keeping the design and the code in sync.\n\n**Gabriela Moreira**: Yes, definitely it's not a new problem. I think it's more like a new solution. Not that formal methods are new, I think these techniques like model-based testing, trace validation, they are not new. I cannot tell you how old they are, but they are at least ten years old because when I was in doing my bachelors I was already looking at this, so they are at least 10 years old, probably much older.\n\nThe thing is the solution that comes with AI is a much better solution than the solution without AI, because now you almost like don't have an excuse, because you can just so easily connect that spec with the code now by having AI generate this like glue code or this instrumentation, or even like if you have logs, how do you parse those logs to get extract the behavior and check it against the spec? All of these things are things that AI is great at, and like with LLM code generation. If we use LLMs to parse logs, it's it's so good at that, and it's so boring to do that ourselves.\n\n**Shane Hastie**: So a new solution to an age-old problem and then layering formal methods in there.\n\n## The Future of the Software Engineering Profession [[20:30](javascript:void(0);)]\n\n**Shane Hastie**: What's the important question I haven't asked you?\n\n**Gabriela Moreira**: I think what does this mean for our profession? Yes, so I think there is some discussion going on online, and some overall concern about what do we do now? What's left for our profession if AI is writing the code, and of course none of us know how much AI is going to write code, like at what level of code it can take away from us, but regardless I think this part of the profession of like thinking about edge cases and defining what behaviours are correct or not, it has to be ours to take, like it's not—AI is not taking that away from us.\n\nAnd when we are able to define what we want and what behaviours we want to see, and what behaviours we do not want to see in our code, and that's not like for everyone, I think in some cases it's like product people that are not non-technical, they will be able to leverage AI, and this this is already happening, right? They're leveraging AI to generate some sort of products, and when like safety and when there are no like big concerns, that works super well, and I'm glad it does.\n\nBut still, there is a lot of software where the behaviours you have to worry about are super complex, and those product people that don't have a technical background, they will struggle, or they would have to learn this technical part in order to do that. But we know about concurrency issues, we know about how difficult these things are and thinking about all the possible orderings of events, so if we are able to define that well, it can both help us understand better and have a continued understanding even if AI is writing the code, we still understand what the system is doing because we are interacting with the system, and it can also help us assert that the AI-generated code is correct via this techniques that I've been telling you about.\n\n**Shane Hastie**: So confidence in the product and value in the profession.\n\n**Gabriela Moreira**: Yes, and they are not taking away the fun part from us. AI is not taking that away.\n\n**Shane Hastie**: Gabriela, a lot of interesting stuff there. If people want to dive deeper, if they want to continue the conversation, where can they find you?\n\n**Gabriela Moreira**: I'm on LinkedIn, I'm very active there, so if you want to follow me there or connect, LinkedIn is the way.\n\n**Shane Hastie**: I will make sure those links are in the show notes. Gabriela, thank you so much for taking the time to talk to us today.\n\n**Gabriela Moreira**: Thank you. Thank you for having me and for the great questions.\n\n**Mentioned**:\n\n- Gabriela Moreira on\n[LinkedIn](https://www.linkedin.com/in/bugarela/)\n\n**More about our podcasts**\n\nYou can keep up-to-date with the podcasts via our [RSS Feed], and they are available via\n\n[SoundCloud](https://soundcloud.com/infoq-engineering-culture),\n\n[Apple Podcasts](https://itunes.apple.com/gb/podcast/engineering-culture-by-infoq/id1161431874?mt=2),\n\n[Spotify](https://open.spotify.com/show/5YAzpmLjbNhQVVg7HkfIHP),\n\n[Overcast](https://overcast.fm/itunes1161431874/engineering-culture-by-infoq)and\n\n[YouTube](https://youtube.com/playlist?list=PLndbWGuLoHeYaFgbuLnvO5Qab2pFBaSWX&si=CbKqeKewkXZSXYW-). From this page you also have access to our recorded show notes. They all have clickable links that will take you directly to that part of the audio.", "url": "https://wpnews.pro/news/podcast-formal-methods-for-every-engineer-in-an-ai-powered-future", "canonical_source": "https://www.infoq.com/podcasts/formal-methods-ai-powered-future/?utm_campaign=infoq_content&utm_source=infoq&utm_medium=feed&utm_term=global", "published_at": "2026-07-10 09:00:00+00:00", "updated_at": "2026-07-10 09:12:32.548731+00:00", "lang": "en", "topics": ["artificial-intelligence", "developer-tools"], "entities": ["Gabriela Moreira", "Shane Hastie", "Informal Systems", "Quint", "TLA+"], "alternates": {"html": "https://wpnews.pro/news/podcast-formal-methods-for-every-engineer-in-an-ai-powered-future", "markdown": "https://wpnews.pro/news/podcast-formal-methods-for-every-engineer-in-an-ai-powered-future.md", "text": "https://wpnews.pro/news/podcast-formal-methods-for-every-engineer-in-an-ai-powered-future.txt", "jsonld": "https://wpnews.pro/news/podcast-formal-methods-for-every-engineer-in-an-ai-powered-future.jsonld"}}