Trade-offs stay human work
Everything is a trade-off, says the First Law of Software Architecture. Why the judgment call matters more in the AI era than command of a programming language.
When a model writes the code, how well someone commands a programming language matters less. What matters more is whether someone can judge what ought to be built. Mark Richards and Neal Ford put it in Fundamentals of Software Architecture as the First Law of Software Architecture: everything in software architecture is a trade-off.
What is a trade-off?
A trade-off is a judgment call in which you knowingly accept a disadvantage to get an advantage. Not a solution that does everything, but one that knows what it gives up. In architecture there is rarely right or wrong, only what makes the most sense in the specific situation.
That sounds harmless and is not. It means the question “what is the best architecture” is not a useful question. Best for what, measured how, paid for with what? Any answer that does not address those three follow-ups is a recommendation without a basis.
An example from the AI world: a system that logs every response is easier to audit. The same system creates another place where client data sits. Both are true. The choice between more auditability and less data retention does not follow from the technology. It depends on which risk the firm is willing to carry and which it is not.
Why this marks the limit of the machine
That weighing up is exactly what AI is, by its nature, less good at: evaluating and deciding in the context of real use. A model returns the statistically most likely answer. An architecture decision is often precisely not the most likely one, but the one that fits the budget, the team, the timeline and the business model.
The reason is unspectacular. The decisive variables are not in the prompt and mostly are not written down anywhere else. That a firm has three people and none of them restarts a system at night. That a matter runs out in eighteen months and the solution has to last that long, but no longer. That a partner rejects a particular piece of software based on experience. A model can work with all of it if you tell it. On its own it knows none of it, and the answer it gives without those inputs is the average across every situation, not yours.
What this means for a law firm
For firms the idea is more familiar than it first appears, because legal work consists in large part of exactly this activity. A draft contract is a series of trade-offs between negotiating position, risk and effort. A litigation strategy trades prospects of success against cost and duration. In both cases, asking for the objectively best solution would miss the point.
Introducing AI in your own firm means the same kind of decision, just on unfamiliar ground. Your own cloud account or a finished application. One vendor or several. The choice between them is an architecture decision with a nameable price. Far-reaching automation or sign-off at every step. Logging with content or without. None of these questions has an answer that holds for every firm, and each has consequences that admitted lawyers will have to answer for later, to clients, to the bar and to the supervisory authority.
There is a practical consequence for working with service providers: anyone who recommends an architecture without naming the advantage it gives up has either not finished thinking or is selling. The counter-question is always the same and always fair. What am I giving up with this decision?
The judgment call needs a memory
A second idea from the book deserves more attention in practice than it usually gets. A trade-off is only worth something as long as you can still reconstruct why it came out that way. Come across a decision two years later and the conditions that made it right are gone. Without those conditions, every deliberate trade-off looks like an oversight, and the obvious response is to reverse it.
For the law firm context that simply means the load-bearing decisions of an AI rollout belong in writing: a few sentences per decision, with the date, the alternative and the advantage given up. It is not a big exercise, but it is the difference between an architecture you can explain and one you eventually just find in place.
What I take from this
Building with AI does not require perfect command of a programming language. The trade-offs you do have to understand and answer for yourself. That stays human work, and it is good news for a profession practised in weighing things up.
The content of this blog was created partly with the support of AI.