Socrates and the Technical Debt

"I know that I know nothing." — Socrates as recorded by Plato, Apology, 21d.

Socrates's method — maieutics — is the art of asking questions in such a way that the interlocutor discovers the hidden assumptions in his own claim. Socrates asserted nothing himself. He only asked, and under the pressure of questions the interlocutor saw that what he had taken for knowledge was opinion resting on the unverified.

In modern software the same operation is called the audit of assumptions. Every architectural decision rests on dozens of silent assumptions: "load will not exceed N," "the data format will not change," "the partner will not leave," "requirements are stable." Most are never written down. When one stops being true, what engineers call technical debt appears: a gap between the world the system was designed for and the world it runs in.

Tech debt as a Socratic dialogue that never happened

Tech debt is not bad code. It is good yesterday's code in today's world. If we were writing the same system from scratch today, we would choose a different architecture — but we do not write from scratch, because rewriting is expensive and the assumptions the old architecture stood on shifted silently.

Socrates would have noted: this is not a technical problem, it is an epistemological one. The team thought it knew how requirements would evolve. Socrates would ask: how do you know? If the answer is "we were told," the next question is: and how do they know? Three or four "how-do-you-knows" later it turns out the chain of justification ends in someone's guess, never verified.

A regular audit of assumptions

A healthy engineering culture builds maieutics into the process. A review of architectural decisions every six months — not to revisit them, but to ask: which assumptions the decision stood on still hold? If all do, move on. If one shifted, that is the signal that part of the system has become tech debt, and it must either be closed or explicitly acknowledged.

Amazon does this through a document called "principles" for every major service: what the service promises, on what assumptions the promise rests, what will happen if the assumption fails. A Socratic dialogue framed as a corporate artefact.

Where this meets AI

With the arrival of large models a new category of especially slippery assumptions has appeared: assumptions about model behaviour. "The model will not generate this," "the model will answer in 200 ms," "the model will not inherit bias from data." Each is a candidate for tech debt, and Socrates would ask the same question: how do you know? Tests are not enough: the model is a function of a billion parameters, and behaviour is not derivable from spec.

This is why advanced AI teams build what one could call "evals" — continuously running checks of behaviour, an analogue of regression tests but built as a Socratic dialogue: "here is an input — what should the answer be, and why?" If the model evolved and the answer changed, that is a signal that the previous assumption no longer holds.

Tech debt does not come from bad work. It comes from good work under conditions that silently changed. Maieutics is the only regular way to make the silent explicit.

Why teams find this hard

A Socratic audit requires admitting the team does not know, and in corporate culture this often reads as weakness. Good teams, on the contrary, cultivate it as a norm: "we do not know, but we know we do not know" is a far more robust position than "we know" without checking.

Socrates paid for his method with his life — the public tired of a man stripping bare its ignorance. Modern teams rarely pay so high a price, but the social cost is always there: whoever asks "stupid" questions about architecture risks looking slow. Healthy cultures reward such questions; unhealthy cultures punish them.

Cheap maieutics

A Socratic audit is cheap to perform and expensive to skip. An hour of conversation, four or five "how do you know that?", and the team discovers three hidden assumptions that would otherwise have to be unearthed after an incident. The cost of the same discovery in production is orders of magnitude higher: service outage, data cleanup, explanations to customers.

And yet in many organisations the ritual resists adoption because it looks like a waste of time. The team already knows what it is doing; why ask questions that already have answers? Socrates would have answered: the questions are asked not for the answers but to test the quality of those at hand. Often it turns out the answer exists but rests on one person who left the company two quarters ago. That is already tech debt, only still invisible.

What to do

Adopt a quarterly "assumption audit" for every major system. On one page: ten assumptions the system stands on. For each: how will we know it has stopped being true? If you cannot answer for one, it is already tech debt, only still hidden. Socrates would have found nothing new in this exercise. He would have said: you have finally started to think.