Coding with large language models (LLMs) holds huge promise, nevertheless it also exposes some long-standing flaws in software: code that’s messy, hard to vary safely, and infrequently 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 latest 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’s software that’s more modular, transparent, and easier to know. A small domain-specific language (DSL) makes it possible to precise 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 might 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 brand new synchronization DSL, explore this approach of their paper “What You See Is What It Does: A Structural Pattern for Legible Software,” which they presented on the Splash Conference in Singapore in October. The challenge, they explain, is that in newest systems, a single feature isn’t fully self-contained. Adding a “share” button to a social platform like Instagram, for instance, doesn’t live in only 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, should be fastidiously aligned, and any change risks unintended uncomfortable side effects elsewhere.
Jackson calls this “feature fragmentation,” a central obstacle to software reliability. “The best way we construct software today, the functionality is just not localized. You wish to understand how ‘sharing’ works, but you have got to hunt for it in three or 4 different places, and whenever you find it, the connections are buried in low-level code,” says Jackson.
Concepts and synchronizations are supposed to tackle this problem. An idea bundles up a single, coherent piece of functionality, like sharing, liking, or following, together with its state and the actions it may well take. Synchronizations, alternatively, describe at the next level how those concepts interact. Slightly than writing messy low-level integration code, developers can use a small domain-specific language to spell out these connections directly. On this DSL, the foundations are easy and clear: one concept’s motion can trigger one other, in order that a change in a single piece of state could be kept in sync with one other.
“Consider concepts as modules which might be completely clean and independent. Synchronizations then act like contracts — they are saying exactly how concepts are imagined to interact. That’s powerful since it makes the system each easier for humans to know and easier for tools like LLMs to generate appropriately,” says Jackson. “Why can’t we read code like a book? We imagine that software needs to be legible and written when it comes to our understanding: our hope is that concepts map to familiar phenomena, and synchronizations represent our intuition about what happens once they come together,” says Meng.
The advantages extend beyond clarity. Because synchronizations are explicit and declarative, they could be analyzed, verified, and naturally generated by an LLM. This opens the door to safer, more automated software development, where AI assistants can propose latest features without introducing hidden uncomfortable side effects.
Of 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. As a substitute 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 on 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 grow to be less about stitching code together from scratch and more about choosing the appropriate concepts and writing the synchronizations between them. “Concepts could grow to be a brand new sort of high-level programming language, with synchronizations because the programs written in that language.”
“It’s a way of creating the connections in software visible,” says Jackson. “Today, we hide those connections in code. But should you can see them explicitly, you’ll be able to reason in regards to the software at a much higher level. You continue to should cope with the inherent complexity of features interacting. But now it’s out within the open, not scattered and obscured.”
“Constructing software for human use on abstractions from underlying computing machines has burdened the world with software that’s all too often costly, frustrating, even dangerous, to know and use,” says University of Virginia Associate Professor Kevin Sullivan, who wasn’t involved within the research. “The impacts (akin to in health care) have been devastating. Meng and Jackson flip the script and demand on constructing interactive software on abstractions from human understanding, which they call ‘concepts.’ They mix 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 brand new and essential direction in the speculation and practice of software design that bears watching.”
“It’s been clear for a few years that we want higher ways to explain and specify what we wish software to do,” adds Thomas Ball, Lancaster University honorary professor and University of Washington affiliate faculty, who also wasn’t involved within 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 technique to describe what we wish from software in a modular manner. Their concepts and specifications are well-suited to be paired with LLMs to realize the designer’s intent.”
Looking ahead, the researchers hope their work can influence how each industry and academia take into consideration software architecture within the age of AI. “If software is to grow to be more trustworthy, we want 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. On the time of funding, the initiative board was British Telecom, Cisco, and Ernst and Young.
