Coding with large language models (LLMs) holds huge promise, but it also exposes some long-standing flaws in software: code that’s messy, difficult to change safely, and often opaque about what’s really going on under the hood. Researchers at MIT’s Computer Science and Artificial Intelligence Laboratory (CSAIL) are charting a more “modular” way forward.
His new approach breaks the system down into “concepts”, separate pieces of the system, each designed to do one thing well, and “synchronisations”, explicit rules that describe how those pieces fit together. The result is software that is more modular, transparent and easier to understand. A small domain-specific language (DSL) makes it possible to express synchronization simply, in a form that LLMs can reliably produce. 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, MIT professor of electrical engineering and computer science (EECS) and associate director of CSAIL, and Egon Meng, EECS PhD student, CSAIL collaborator and designer of the new synchronization DSL, explored 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, he explains, is that in most modern systems, no single feature is ever completely self-consistent. For example, adding a “share” button to a social platform like Instagram doesn’t just stay in one service. Its functionality is divided into code that handles posting, notification, authenticating users, and more. Despite being scattered throughout the code, all these pieces must be carefully aligned, and any change risks unintended side effects elsewhere.
Jackson calls this “feature fragmentation”, which is a central barrier to software reliability. Jackson says, “The way we build software today, functionality is not localized. You want to understand how ‘sharing’ works, but you have to find it in three or four different places, and when you find it, the connections are buried in low-level code.”
Concepts and coordination are meant to deal with this problem. A concept bundles a single, coherent piece of functionality, such as sharing, liking or following, as well as its status and the actions it can perform. Synchronization, on the other hand, describes at a high level how those concepts interact. Instead of writing messy low-level integration code, developers can use a small domain-specific language to directly describe these connections. In this DSL, the rules are simple and clear: the action of one concept can trigger another, so that changes in one part of the state are kept in sync with the other.
Jackson says, “Think of concepts as modules that are completely clean and independent. Synchronizations then act like contracts – they describe how the concepts should interact. This is powerful because it makes the system easier to understand for humans and easier for tools like LLM to generate correctly.” Meng says, “Why can’t we read code like a book? We believe software should be legible and written according to our understanding: our hope is that concepts map onto familiar phenomena, and synchronicities represent our intuition about what happens when they come together.”
The benefits go beyond the obvious. Because synchronizations are explicit and declarative, they can be analyzed, verified, and of course generated by 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 combined features like liking, commenting, and sharing, each in the same concept – like a microservices architecture, but more modular. Without this pattern, these features were spread across multiple services, making them difficult to trace and test. Using the concepts-and-synchronization approach, each feature became centralized and legible, while synchronization explained precisely how the concepts interact.
The study also revealed how synchronization can address common concerns such as error handling, response formatting, or persistent storage. Instead of embedding these details in each service, synchronization can handle them once, ensuring consistency throughout the system.
More advanced directions are also possible. Synchronization can coordinate distributed systems, keep replicas on different servers in order, or allow shared databases to interact cleanly. Weakening the synchronization semantics can ultimately enable consistency while maintaining clarity at the architectural level.
Jackson sees potential for broader cultural change in software development. One idea is the creation of “concept catalogs”, shared libraries of well-tested, domain-specific concepts. Then application development can be less about piecing together code from scratch and more about selecting the right concepts and writing synchronization between them. “Concepts could become a new kind of high-level programming language, with synchronization with programs written in that language.”
“It’s a way to make connections visible in the software,” Jackson says. “Today, we hide those connections in the code. But if you can see them clearly, you can reason about software at a much higher level. You still have to deal with the underlying complexity of features interacting. But now it’s out in the open, not scattered and obscured.”
Kevin Sullivan, an associate professor at the University of Virginia who was not involved in the research, says, “Building software for human use over abstractions from the underlying computing machines has burdened the world with software that is too expensive, frustrating, even dangerous to understand and use.” “The effects (such as in health care) have been devastating. Meng and Jackson flip the script and emphasize 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, provide the basis for verifying their meanings, compiling them into systems, and refining them into programs suitable for human use. This provides a new paradigm in the theory and practice of software design. And there is an important direction that needs to be addressed.”
“It has been clear for many years that we need better ways to describe and specify what we want software to do,” says Thomas Ball, professor emeritus at Lancaster University and affiliated faculty at the University of Washington. “LLM’s 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 way. Their concepts and specifications are suitable to be paired with LLM to achieve the designer’s intent.”
Looking ahead, the researchers hope that their work can influence the way 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,” Jackson says. “The concepts and coordination are a step toward that goal.”
This work was partially funded by the Machine Learning Applications (MLA) Initiative of the CSAIL Alliance. At the time of funding, the initiative boards were British Telecom, Cisco and Ernst & Young.
