Coding with large language models (LLMs) holds huge promise, however it also exposes some long-standing flaws in software: code that’s messy, hard to vary safely, and sometimes 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 grasp. A small domain-specific language (DSL) makes it possible to specific 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 will 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 latest 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 unwanted effects elsewhere.
Jackson calls this “feature fragmentation,” a central obstacle to software reliability. “The way in which we construct software today, the functionality isn’t localized. You wish to understand how ‘sharing’ works, but you’ve gotten to hunt for it in three or 4 different places, and once 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 take. Synchronizations, alternatively, describe at the next level how those concepts interact. Fairly 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 principles are easy and clear: one concept’s motion can trigger one other, in order that a change in a single piece of state may be kept in sync with one other.
“Consider concepts as modules which can be completely clean and independent. Synchronizations then act like contracts — they are saying exactly how concepts are speculated to interact. That’s powerful since it makes the system each easier for humans to grasp and easier for tools like LLMs to generate appropriately,” says Jackson. “Why can’t we read code like a book? We consider that software ought to be legible and written by way of our understanding: our hope is that concepts map to familiar phenomena, and synchronizations represent our intuition about what happens after they come together,” says Meng.
The advantages extend beyond clarity. Because synchronizations are explicit and declarative, they may 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 unwanted 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 an alternative 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 develop into less about stitching code together from scratch and more about choosing the fitting concepts and writing the synchronizations between them. “Concepts could develop into a brand new type of high-level programming language, with synchronizations because the programs written in that language.”
“It’s a way of constructing the connections in software visible,” says Jackson. “Today, we hide those connections in code. But should you can see them explicitly, you may reason concerning the software at a much higher level. You continue to need to 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 grasp and use,” says University of Virginia Associate Professor Kevin Sullivan, who wasn’t involved within the research. “The impacts (resembling 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 vital direction in the speculation and practice of software design that bears watching.”
“It’s been clear for a few years that we’d like higher ways to explain and specify what we would like 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 option to describe what we would like from software in a modular manner. Their concepts and specifications are well-suited to be paired with LLMs to attain 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 develop into more trustworthy, we’d like 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.