Principles over tools

A few years ago I kept walking into the same conversation.

Different project, different team, same argument. Angular or React. This state library or that one. Someone had read a benchmark, someone else had a favourite, and the room spent an afternoon on it. Meanwhile nobody had asked where state was supposed to live in this application, or what the browser was allowed to know that the server didn't.

It felt like watching people argue about which brand of hammer to buy before anyone had looked at the plans for the house.

I was moving between client projects at the time, and that's the thing about seeing a lot of them: you stop noticing the differences and start noticing what repeats. This one repeated everywhere.

What was actually missing

Nobody was talking about what a single page application is.

Routing. State that lives somewhere specific. A boundary between what the server knows and what the browser knows. Rendering that stays predictable while data shows up late. Those problems don't belong to a framework. They're there whether you solve them with Angular, with React, or with three hundred lines of your own code.

A framework is a set of answers to those questions. If you don't know the questions, you can't judge the answers. You can only follow whoever is loudest this quarter.

I said that out loud for the first time in June 2016, as an internal tech talk at Micromata. That talk is where the rest came from: a written version for heise Developer in early 2017, and the same talk at enterJS later that year.

Ten years on, almost everyone who won those arguments has switched frameworks at least twice. The applications that aged well weren't the ones that picked right. They were the ones where somebody had drawn the boundaries clearly enough that swapping a layer was still possible.

The same feeling, moving faster

I've got that feeling again, and this time it's quicker.

In the years since I've worked inside a lot of companies as a contractor, from marketplaces to fintech, and the pattern never went away. Only the vocabulary changed.

New AI tools show up faster than anyone can learn them. Every week there's a model, a framework, an agent runtime, a protocol that's going to change everything. The comparison tables are back. So are the battles.

And the same thing is missing. Not which tool, but what the problem actually is.

Retrieval is a search problem before it's a vector database problem. An agent that takes actions is a boundary problem: what is it allowed to touch? What happens when it's wrong? How would you find out? Deciding whether a system got better is a measurement problem, and measurement was hard long before anyone called it AI.

None of that is new. What's new is how cheap it's become to build something that looks like it works. The framework wars produced bad architecture slowly. AI produces it fast, and the result demos well enough that nobody asks the next question.

Routes and maps

Learning tools is like memorising routes. It works beautifully until one road is closed.

Principles are the map. Slower to acquire, and then you can get anywhere, including places you've never been.

Two kinds of map, and you need both:

Software. Where does state live? What's a boundary and who may cross it? What happens when a call fails? How would I know this is broken? None of that changed, and AI doesn't lower the bar. It raises it, because now the code arrives faster than anyone can read it.

AI. What retrieval really does and where it falls over. Why an agent that can act needs different guardrails from one that only answers. What an evaluation loop is for, and why a system that can't tell you it got worse eventually will.

With both, a new tool is a small question: does it answer a problem I have? With neither, every release is a decision you're not equipped to make, so you make it on vibes.

The one question

Before I put AI into anything, mine or a client's, I ask the same thing.

What problem does this solve, and how will I know it worked?

If there's no answer, the tool isn't the solution, however good it is. Sometimes the honest answer is that a scheduled script and a clear process beat an agent, cost nothing to run, and never hallucinate. I say that out loud even when it costs me the more interesting project, because the alternative is a system somebody has to maintain and nobody can explain.

Principles over tools was never about ignoring tools. I use plenty, and I swap them often. It's about knowing enough to choose, and enough to stop.

The tools have changed three times since that talk in 2016. The principles haven't.