Atomic Design, Everywhere
One of the patterns I’ve gotten the most mileage out of in my career is Brad Frost’s Atomic Design. The idea was that user interfaces are best defined from a bottom-up series of design specifications: first, atoms, the core building blocks of any user interface — such as a button. Then, molecules — appropriately, a series of atoms stuck together as a coherent component, like a button dropdown. Next up are organisms, which chain together molecules, such as a search component featuring a text input and an appended button dropdown. Brad Frost phones it in a bit with the last two steps — templates, or structured assemblies of components, and pages, or specific implementations of templates.
Get Marc Gebeily’s stories in your inbox
Join Medium for free to get updates from this writer.
Some people prepend a level to the hierarchy to take the system sub-atomic: tokens, or the tiniest, most granular descriptors of a component’s visuals. Think spacing, borders, shadows, and the like. While it’s not part of the official, first party guidelines, I’d happily count it as the most important step for two reasons. First, I think it’s the step that best describes what most people think of when they describe what an application looks like (colors, shapes, whitespace, and so on), and second, it’s the step that most enables utility-first development, an implementation detail that I’ve had a tremendous amount of success with.
While writing my gut takes on AI and how prompting can become more precise, I couldn’t help thinking of atomic design — not just as a way to communicate a brand to an LLM, but as a way to describe output using a set of building blocks. Can developers describe their app’s operations using the same atomic breakdown? Can a product team use this mental model to build a requirements doc? Having different degrees of granularity in building a web application would be invaluable not just to building productively with AI, but to how a new-world software organization interfaces with the SDLC. My current role is my first in a large company, and the degree of bloat and spread in the interface isn’t just taxing on the engineers that have to maintain them — it’s gotten to the point where it’s been complained about by customers looking for the one, definitive path to performing some action on our platform.
Again, the common theme in all of this is predictability in the name of precision. I’m getting more and more confident that the immediate future of agentic development relies on confining an LLM’s output to this kind of paradigm. I’m struggling to zero in on an actual specification for a process or utility though. Do I want it as a skill? An MCP? Do I continue forward with the database of embedded behaviors that I tried for my TODO app experiment? Maybe I should go in order and start by narrowing down my proposal for product specification before wiring it into coding agents.
Hopefully my next article has practical advice, or a before and after. This is leaning a little too much into just publishing my scratchpad.
