MIT Researchers Propose Revolutionary 'Concepts and Synchronizations' Model to Fix Software Development's AI Problem

MIT researchers propose a new model for legible, modular software

Coding with large language models (LLMs) holds huge promise, but it also exposes some long-standing flaws in software: code that's messy, hard to change safely, and often opaque about what's really happening under the hood. Researchers at MIT's Computer Science and Artificial Intelligence Laboratory (CSAIL) are charting a more "modular" path ahead. Their new approach breaks systems into "concepts," separate pieces of a system, each designed to do one job well, and "synchronizations," explicit rules that describe exactly how those pieces fit together. The result is software that's more modular, transparent, and easier to understand. A small domain-specific language (DSL) makes it possible to express synchronizations simply, in a form that LLMs can reliably generate. In a real-world case study, the team showed how this method can bring together features that would otherwise be scattered across multiple services. The team, including Daniel Jackson, an MIT professor of electrical engineering and computer science (EECS) and CSAIL associate director, and Eagon Meng, an EECS PhD student, CSAIL affiliate, and designer of the new synchronization DSL, explore this approach in their paper "What You See Is What It Does: A Structural Pattern for Legible Software," which they presented at the Splash Conference in Singapore in October. The challenge, they explain, is that in most modern systems, a single feature is never fully self-contained. Adding a "share" button to a social platform like Instagram, for example, doesn't live in just one service. Its functionality is split across code that handles posting, notification, authenticating users, and more. All these pieces, despite being scattered across the code, must be carefully aligned, and any change risks unintended side effects elsewhere. Jackson calls this "feature fragmentation," a central obstacle to software reliability. "The way we build software today, the functionality is not localized. You want to understand how 'sharing' works, but you have to hunt for it in three or four different places, and when you find it, the connections are buried in low-level code," says Jackson. Concepts and synchronizations are meant to tackle this problem. A concept bundles up a single, coherent piece of functionality, like sharing, liking, or following, along with its state and the actions it can take. Synchronizations, on the other hand, describe at a higher level how those concepts interact. Rather than writing messy low-level integration code, developers can use a small domain-specific language to spell out these connections directly. In this DSL, the rules are simple and clear: one concept's action can trigger another, so that a change in one piece of state can be kept in sync with another. "Think of concepts as modules that are completely clean and independent. Synchronizations then act like contracts -- they say exactly how concepts are supposed to interact. That's powerful because it makes the system both easier for humans to understand and easier for tools like LLMs to generate correctly," says Jackson. "Why can't we read code like a book? We believe that software should be legible and written in terms of our understanding: our hope is that concepts map to familiar phenomena, and synchronizations represent our intuition about what happens when they come together," says Meng. The benefits extend beyond clarity. Because synchronizations are explicit and declarative, they can be analyzed, verified, and of course generated by an LLM. This opens the door to safer, more automated software development, where AI assistants can propose new features without introducing hidden side effects. In their case study, the researchers assigned features like liking, commenting, and sharing each to a single concept -- like a microservices architecture, but more modular. Without this pattern, these features were spread across many services, making them hard to locate and test. Using the concepts-and-synchronizations approach, each feature became centralized and legible, while the synchronizations spelled out exactly how the concepts interacted. The study also showed how synchronizations can factor out common concerns like error handling, response formatting, or persistent storage. Instead of embedding these details in every service, synchronization can handle them once, ensuring consistency across the system. More advanced directions are also possible. Synchronizations could coordinate distributed systems, keeping replicas on different servers in step, or allow shared databases to interact cleanly. Weakening synchronization semantics could enable eventual consistency while still preserving clarity at the architectural level. Jackson sees potential for a broader cultural shift in software development. One idea is the creation of "concept catalogs," shared libraries of well-tested, domain-specific concepts. Application development could then become less about stitching code together from scratch and more about selecting the right concepts and writing the synchronizations between them. "Concepts could become a new kind of high-level programming language, with synchronizations as the programs written in that language." "It's a way of making the connections in software visible," says Jackson. "Today, we hide those connections in code. But if you can see them explicitly, you can reason about the software at a much higher level. You still have to deal with the inherent complexity of features interacting. But now it's out in the open, not scattered and obscured." "Building software for human use on abstractions from underlying computing machines has burdened the world with software that is all too often costly, frustrating, even dangerous, to understand and use," says University of Virginia Associate Professor Kevin Sullivan, who wasn't involved in the research. "The impacts (such as in health care) have been devastating. Meng and Jackson flip the script and insist on building interactive software on abstractions from human understanding, which they call 'concepts.' They combine expressive mathematical logic and natural language to specify such purposeful abstractions, providing a basis for verifying their meanings, composing them into systems, and refining them into programs fit for human use. It's a new and important direction in the theory and practice of software design that bears watching." "It's been clear for many years that we need better ways to describe and specify what we want software to do," adds Thomas Ball, Lancaster University honorary professor and University of Washington affiliate faculty, who also wasn't involved in the research. "LLMs' ability to generate code has only added fuel to the specification fire. Meng and Jackson's work on concept design provides a promising way to describe what we want from software in a modular manner. Their concepts and specifications are well-suited to be paired with LLMs to achieve the designer's intent." Looking ahead, the researchers hope their work can influence how both industry and academia think about software architecture in the age of AI. "If software is to become more trustworthy, we need ways of writing it that make its intentions transparent," says Jackson. "Concepts and synchronizations are one step toward that goal." This work was partially funded by the Machine Learning Applications (MLA) Initiative of CSAIL Alliances. At the time of funding, the initiative board was British Telecom, Cisco, and Ernst and Young.

Researchers detail legible software, better than vibe coding

A pair of MIT researchers have detailed a proposed new model for software that would help both humans and AI code generators alike create better and more transparent applications. No more vibing! The approach is detailed in a paper authored by MIT's Eagon Meng and Daniel Jackson, titled "What You See is What it Does: A Structural Patten for Legible Software". They flag up the problem of "illegible" modern software, which lacks "direct correspondence between code and observed behavior". Modern software is often, also, "insufficiently modular" they continue, "leading to a failure of three key requirements of robust coding": incrementality, integrity, and transparency. These are not purely human flaws. In fact, they argue that the growing use of LLMs has "exposed deep flaws in the practice of software development, and how a reevaluation might be needed to capitalize on the benefits of LLMs and mitigate their failings." When LLMs are used to add code to an existing repo, "it can be hard to control which modules are modified, and to ensure that existing functionality is not broken." Moreover, "Programmers complain that LLM coding assistants recommend patches that often break previously generated functionality." And "whole app" builders are often unable to extend functionality before "certain (undefined) limits." This inability of LLMs to work incrementally while presenting integrity could ultimately limit the role of LLMs, the researchers suggest. That would be a crying shame of course for the tech giants who have poured billions into building LLMs and promising enterprises they will allow them to rationalize their dev teams. But it's also a concern for the development teams who are indeed increasingly reliant on LLMs. GitHub's latest figures show that LLM use is not just ubiquitous but has been instrumental in making TypeScript the number one language on the platform, in part because it plays nicer with agent assisted code. Meng and Jackson's answer is to break systems into "concepts," separate modules of "user-facing units of functionality that have a well defined purpose and thus deliver some recognizable value." Less abstractly, they say that concepts in a social media app could include "post", "comment", "friend", etc. At the same time, concepts should structure the underlying implementation of the app. The authors say this makes them similar to microservices, but without the sort of dependencies, such as the ability to call or query each other's state, that can lead to "a tangled web of connections." But, they add that concepts can still have dependencies on lower level services such as database or networking services. Concepts, in turn, would be orchestrated by an application layer. This would avoid "coupling... allowing concepts to be designed independently and then composed later into applications." The paper works through a few existing ideas for this, before settling on a proposed granular approach of synchronizations which "act like contracts" spelling out exactly how concepts are supposed to interact. "Why can't we read code like a book? We believe that software should be legible and written in terms of our understanding: our hope is that concepts map to familiar phenomena, and synchronizations represent our intuition about what happens when they come together," Meng said in an MIT post about the work. Because the synchronizations are explicit and declarative they can be analyzed, verified, and also generated by LLMs. In the paper, the authors suggest their approach would mean "LLM-based tools can offer more than 'vibe coding' in which results are unpredictable, limits of complexity are easily reached, and each new coding step risks undermining previous ones." "Distributed implementations might be achieved by allowing concept instances to run on different servers, with synchronizations as the mechanism to keep servers in step," it adds. Jackson and Meng suggest the architecture could lead to concept catalogs of "well-tested, domain-specific concepts." These could be incorporated by both human and AI coders. "You still have to deal with the inherent complexity of features interacting. But now it's out in the open, not scattered and obscured." Which sounds like a great idea. It's just a shame that it would make vibe coding redundant, just as the term made it into the dictionary. ®

Researchers propose a new model for legible, modular software

Coding with large language models (LLMs) holds huge promise, but it also exposes some long-standing flaws in software: code that's messy, hard to change safely, and often opaque about what's really happening under the hood. Researchers at MIT's Computer Science and Artificial Intelligence Laboratory (CSAIL) are charting a more "modular" path ahead. Their new approach breaks systems into "concepts," separate pieces of a system, each designed to do one job well, and "synchronizations," explicit rules that describe exactly how those pieces fit together. The result is software that's more modular, transparent, and easier to understand. A small domain-specific language (DSL) makes it possible to express synchronizations simply, in a form that LLMs can reliably generate. In a real-world case study, the team showed how this method can bring together features that would otherwise be scattered across multiple services. The paper is published in the Proceedings of the 2025 ACM SIGPLAN International Symposium on New Ideas, New Paradigms, and Reflections on Programming and Software. The team, including Daniel Jackson, an MIT professor of electrical engineering and computer science (EECS) and CSAIL associate director, and Eagon Meng, an EECS Ph.D. student, CSAIL affiliate, and designer of the new synchronization DSL, explore this approach in their paper "What You See Is What It Does: A Structural Pattern for Legible Software," which they presented at the Splash Conference in Singapore in October. The challenge, they explain, is that in most modern systems, a single feature is never fully self-contained. Adding a "share" button to a social platform like Instagram, for example, doesn't live in just one service. Its functionality is split across code that handles posting, notification, authenticating users, and more. All these pieces, despite being scattered across the code, must be carefully aligned, and any change risks unintended side effects elsewhere. Jackson calls this "feature fragmentation," a central obstacle to software reliability. "The way we build software today, the functionality is not localized. You want to understand how 'sharing' works, but you have to hunt for it in three or four different places, and when you find it, the connections are buried in low-level code," says Jackson. Concepts and synchronizations are meant to tackle this problem. A concept bundles up a single, coherent piece of functionality, like sharing, liking, or following, along with its state and the actions it can take. Synchronizations, on the other hand, describe at a higher level how those concepts interact. Rather than writing messy low-level integration code, developers can use a small domain-specific language to spell out these connections directly. In this DSL, the rules are simple and clear: one concept's action can trigger another, so that a change in one piece of state can be kept in sync with another. "Think of concepts as modules that are completely clean and independent. Synchronizations then act like contracts -- they say exactly how concepts are supposed to interact. That's powerful because it makes the system both easier for humans to understand and easier for tools like LLMs to generate correctly," says Jackson. "Why can't we read code like a book? We believe that software should be legible and written in terms of our understanding: our hope is that concepts map to familiar phenomena, and synchronizations represent our intuition about what happens when they come together," says Meng. The benefits extend beyond clarity. Because synchronizations are explicit and declarative, they can be analyzed, verified, and of course generated by an LLM. This opens the door to safer, more automated software development, where AI assistants can propose new features without introducing hidden side effects. In their case study, the researchers assigned features like liking, commenting, and sharing each to a single concept -- like a microservices architecture, but more modular. Without this pattern, these features were spread across many services, making them hard to locate and test. Using the concepts-and-synchronizations approach, each feature became centralized and legible, while the synchronizations spelled out exactly how the concepts interacted. The study also showed how synchronizations can factor out common concerns like error handling, response formatting, or persistent storage. Instead of embedding these details in every service, synchronization can handle them once, ensuring consistency across the system. More advanced directions are also possible. Synchronizations could coordinate distributed systems, keeping replicas on different servers in step, or allow shared databases to interact cleanly. Weakening synchronization semantics could enable eventual consistency while still preserving clarity at the architectural level. Jackson sees potential for a broader cultural shift in software development. One idea is the creation of "concept catalogs," shared libraries of well-tested, domain-specific concepts. Application development could then become less about stitching code together from scratch and more about selecting the right concepts and writing the synchronizations between them. "Concepts could become a new kind of high-level programming language, with synchronizations as the programs written in that language. It's a way of making the connections in software visible," says Jackson. "Today, we hide those connections in code. But if you can see them explicitly, you can reason about the software at a much higher level. You still have to deal with the inherent complexity of features interacting. But now it's out in the open, not scattered and obscured." "Building software for human use on abstractions from underlying computing machines has burdened the world with software that is all too often costly, frustrating, even dangerous, to understand and use," says University of Virginia Associate Professor Kevin Sullivan, who wasn't involved in the research. "The impacts (such as in health care) have been devastating. Meng and Jackson flip the script and insist on building interactive software on abstractions from human understanding, which they call 'concepts.' They combine expressive mathematical logic and natural language to specify such purposeful abstractions, providing a basis for verifying their meanings, composing them into systems, and refining them into programs fit for human use. It's a new and important direction in the theory and practice of software design that bears watching." "It's been clear for many years that we need better ways to describe and specify what we want software to do," adds Thomas Ball, Lancaster University honorary professor and University of Washington affiliate faculty, who also wasn't involved in the research. "LLMs' ability to generate code has only added fuel to the specification fire. Meng and Jackson's work on concept design provides a promising way to describe what we want from software in a modular manner. Their concepts and specifications are well-suited to be paired with LLMs to achieve the designer's intent." Looking ahead, the researchers hope their work can influence how both industry and academia think about software architecture in the age of AI. "If software is to become more trustworthy, we need ways of writing it that make its intentions transparent," says Jackson. "Concepts and synchronizations are one step toward that goal."