Coding with Large Language Models (LLM) holds tremendous promise, but it also exposes some long-standing flaws in software: code that is sloppy, difficult to change safely, and often unclear 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” path ahead.
Their new approach divides systems into “concepts,” separate parts of the system that are each designed to do a specific job well, and “synchronizations,” explicit rules that describe exactly how these parts fit together. The result is software that is more modular, clear and easier to understand. A small domain-specific language (DSL) allows synchronization to be simply expressed in a form that LLMs can reliably generate. In a real case study, the team showed how this method can combine features that would otherwise be scattered across multiple services.
The team, which includes Daniel Jackson, professor of electrical engineering and computer science (EECS) at MIT and associate director of CSAIL, and Eagon Meng, EECS graduate student, a division of CSAIL and designer of the new DSL synchronization, explore this approach in their paper “This is what you see doing: a structural pattern for readable software”, which they presented at the Splash conference in Singapore in October. They explain that the challenge is that in most modern systems, a single function is never fully self-contained. Adding a “share” button to a social platform like Instagram, for example, is not limited to a single service. Its functionality is split between code that handles posting, notifications, user authentication, and more. All of these elements, although scattered throughout the code, must be carefully aligned, and each change carries the risk of unintended side effects elsewhere.
Jackson calls this “feature fragmentation,” a major obstacle to software reliability. “Today we build software, the functionality is not localized. You want to understand how 'sharing' works, but you have to look for it in three or four different places, and when you find it, the connections are hidden in low-level code,” Jackson says.
Concepts and timings aim to solve this problem. The concept includes a single, consistent piece of functionality, such as sharing, liking, or following, along with its state and the actions it can take. Synchronizations, on the other hand, describe the interaction of these concepts at a higher level. Instead of writing sloppy, 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: the action of one concept can trigger another, so that a change in one state can be synchronized with another.
“Think of concepts as modules that are completely clean and independent. Synchronizations then act like contracts – they tell you exactly how the concepts should interact with each other. This is powerful because it makes the system easier for humans to understand and easier for tools like LLM to generate correctly,” says Jackson. “Why can't we read code like a book? We believe that software should be readable and written in a way that is consistent with our understanding: we hope that the concepts correspond to known phenomena, and the timings represent our intuitions about what will happen when they come together,” Meng says.
The benefits go beyond transparency. Since 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 mapped features like liking, commenting, and sharing each to a single concept—resembling a microservices architecture, but more modular. Without this pattern, these functions would be scattered across multiple services, making them difficult to locate and test. Using a concepts and timing approach, each function became centralized and readable, and timings precisely defined how concepts interacted.
The study also showed how synchronizations can address common issues such as error handling, response formatting, and persistent storage. Instead of embedding these details into each service, Sync can handle them once, ensuring consistency across the system.
More advanced courses are also possible. Synchronizations can coordinate distributed systems, keep replicas on different servers up to date, or enable clean interaction of shared databases. Weakening the synchronization semantics could enable eventual consistency while maintaining transparency at the architectural level.
Jackson sees the potential for a broader cultural shift in software development. One idea is to create “concept catalogues,” shared libraries of well-tested domain-specific concepts. App development could then be less about putting together code from scratch and more about selecting the right concepts and keeping the timing between them. “Concepts could become a new kind of high-level programming language with synchronization of programs written in that language.”
“It's a way to make connections visible in the software,” Jackson says. “Today we hide these connections in the code. But if you can see them clearly, you can think about the software at a much higher level. You still have to deal with the inherent complexity of how functions interact. But now it's visible, instead of scattered and obscured.”
“Creating software for human use from abstractions from basic computing machines has burdened the world with software that is too often expensive, frustrating, and even dangerous to understand and use,” says University of Virginia associate professor Kevin Sullivan, who was not involved in the research. “The effects (e.g. on 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 suitable for human use. This is a new and important direction in the theory and practice of software design that is worth following.”
“It has been clear for many years that we need better ways of describing and defining what we want from software,” adds Thomas Ball, an honorary professor at Lancaster University and a lecturer at the University of Washington, who was also not involved in the research. “The ability of LLM programs to generate code has only added fuel to the specification fire. Meng and Jackson's work on conceptual design provides a promising way to describe what we want from software in a modular way. Their concepts and specifications lend themselves well to combining with LLM to achieve the designer's intent.”
Looking to the future, the researchers hope that their work can influence the way both industry and academia think about software architecture in the age of artificial intelligence. “If software is going to become more trustworthy, we need ways of writing it that make its intentions transparent,” Jackson says. “Concepts and timings are one step towards that goal.”
This work was partially funded by the CSAIL Alliances Machine Learning Applications (MLA) initiative. At the time of funding, the initiative's board was British Telecom, Cisco and Ernst and Young.
