Conversation: LLMs and Building Abstractions
Conversation: LLMs and Building Abstractions
26 August 2025
Unmesh Joshi
Unmesh is a Distinguished Engineer at Thoughtworks, based in Pune,<br>India. He is the author of Patterns of Distributed Systems.
Martin Fowler
Martin is the host of martinfowler.com, the author of Refactoring, and the<br>Chief Scientist at Thoughtworks.
generative AI
A few weeks ago, we exchanged some emails sharing how we were thinking about how<br>programmers work with LLMs. We found the conversation to be stimulating,<br>and thought it would be worth sharing with a wider audience. We switched<br>from emails to building up this conversation in a file, and doing some<br>editing to improve the flow (and make us sound more coherent).
Unmesh
I am always a bit annoyed with all the claims happening around the<br>world with the role of LLMs in software development. I was re-reading some of<br>the articles and write-ups from the early days of agile to structure my<br>thoughts. I thought Fred Brooks classic “No Silver<br>Bullet” articulation can be helpful
Martin
When I got into my first job, early mentors of mine<br>encouraged me to read Fred Brooks's The Mythical Man Month. One of the themes of this<br>was importance of conceptual integrity.
I believe that large programming projects suffer management problems<br>different in kind from small ones, due to division of labor. I believe the<br>critical need to be the preservation of the conceptual integrity of the<br>product itself.
-- Frederick P. Brooks, Jr
Shortly afterwards “No Silver Bullet” was published, and we felt it was<br>one of the most important articles thus far in our profession. The<br>distinction he made there between accidental and essential complexity has been in the<br>front of my mind ever since.
Following Aristotle, I divide them into essence, the difficulties<br>inherent in the nature of software, and accidents, those difficulties that<br>today attend its production but are not inherent.
The essence of a software entity is a construct of interlocking<br>concepts: data sets, relationships among data items, algorithms, and<br>invocations of functions. This essence is abstract in that such a<br>conceptual construct is the same under many different representations. It<br>is nonetheless highly precise and richly detailed.
I believe the hard part of building software to be the specification,<br>design, and testing of this conceptual construct, not the labor of<br>representing it and testing the fidelity of the representation.
-- Frederick P. Brooks, Jr
Unmesh
Understanding the difference between essential and accidental complexity provides clear guidance on where to apply LLMs for simplification.
I find this distinction between accidental and essential complexity<br>very useful. I think it is a good way to think about the difference<br>between the complexity of a system and the complexity of the process of<br>building a system. I think this distinction is also useful for thinking<br>about the role of LLMs in software development. Programming language syntax,<br>complexity of integrating various frameworks. All the boilerplate required just to get<br>the software running is all the accidental complexity. I think LLMs are good<br>at reducing accidental complexity. Need a Spring Boot service that talks<br>to Kafka and logs with OpenTelemetry? An LLM can spit out a working template<br>in seconds. But real software work is more than making code compile.<br>The very act of writing software is a complex process.<br>While currently a lot of focus is on using LLMs to generate code,<br>it's important to think about what the act of 'writing code' really means.
Programming isn't just typing coding syntax that computers can understand and execute;<br>it's shaping a solution.<br>We slice the problem into focused pieces, bind related data and behaviour together,<br>and—crucially—choose names that expose intent. Good names cut through complexity<br>and turn code into a schematic everyone can follow.<br>The most creative act is this continual weaving of names that reveal<br>the structure of the solution that maps clearly to the problem we are trying to solve.
Programming isn't just typing coding syntax that computers can understand and execute;<br>it's shaping a solution.
Yet no one sees the whole design on day one.<br>Progress comes from a back-and-forth rhythm: think a bit, write a bit,<br>step back, and refine what you see. Each iteration sharpens both the code<br>and your understanding of the bigger picture, allowing us to<br>guide the next steps. The very act of “writing code” is often where design<br>decisions crystallize.
In the software world, 'Impossibility Results' are a way to keep us grounded.<br>They help us focus on solutions once we know what the real constraints are,<br>instead of assuming that constraints don't exist.<br>Understanding the basic nature of building software systems and<br>the activity commonly known as 'coding' can happen better if<br>we know 'impossibilities' better.
I like to think of this problem of 'upfront design' in terms of an...