There Is No Time Left to Understand What We Are Building

The doubt arrives a few steps in

A few weeks ago I put together a new POC: an agent that acts as a beer sommelier, with a RAG behind it feeding it the answers. I finished it, it works decently and I kept it, so this is not the usual story of a project started and thrown away. It is the story of a doubt that showed up too early: the feeling that I would have to redo it hit me when I was still halfway through.

I had chosen the technologies with some care: everything local with Ollama and llama3.1, LanceDB as the vector index, a classic RAG with a system prompt that keeps the model hooked to the sources. Then, within a few days: a paper, “Don’t Retrieve, Navigate”, proposing to skip retrieval and let the agent navigate the documents directly, an approach that works best precisely when the documents are few and well organized, like mine; graphify, which turns a folder of documents into a navigable graph instead of a list of vectors; the latest open Qwen, which runs locally just like llama3.1 and on the benchmarks makes it look like it belongs to another era. None of these three things changed the outcome my project would produce; it was simply that while I was writing it I already felt like I was looking at something old.

I also have a note on my phone called “to look at”. It collects the things I promise myself I will go through properly, which of course never happens. At some point I stopped treating it as a to-do list (I have never emptied it, I never could) and started treating it for what it is: a counter of how far behind I am, updated every evening.

The cycle got shorter

That in this trade you keep up or fall behind is nothing new. I have seen plenty of frameworks, paradigms and fashions go by. Every time we adapted. The difference is that the loop used to last long enough to fit a whole project inside it: you picked something, worked with it for weeks, saw what its weak points were and in the end you formed an opinion of your own. Next time you chose better.

The benchmark I have always used for deciding a technology was “done” is the rewrite. You rewrote a piece of software after years: it had been in production for a long time, it had piled up patch on patch and incremental changes that made it painful to maintain, while in the meantime libraries and versions had come out that were too far from the ones it was born on. By that point, asking “should we redo it?” was legitimate: you had to weigh what every change cost, how long a release took and which things it could no longer do at all.

Today that question shows up while I am still writing the first release. Not about code weighed down by years of maintenance, but about something nobody has ever put in production and that does not carry a single day of technical debt. The reasoning is the same as always; it is the time scale that went mad. The moment of the rewrite has slid on top of the moment of the writing. In between there is no longer the space where I used to form my own opinion.

Impostor syndrome, senior edition

After a good few years in the job you expect to have your own body of knowledge. You do not know everything, but you know enough never to feel completely lost. Well, that is not enough anymore. More and more often I am in a conversation where someone names a thing I have never heard of and I put on the face of someone who knows it while thinking “I will look that up tonight”. Then it goes into the “to look at” note and we know how that ends.

The odd part is that it is experience that makes it weigh. Someone starting now does not know what they do not know, and the question never even comes up. I know very well what it means to really understand something. That is exactly why I can see how far from it I am on most of the new tools I am using.

On top of that, the way information reaches you has changed over the last few years. Ten years ago, to find out something new had come out, you had to go looking for it: a blog you followed, a conference, a colleague who had heard about it somewhere. If you did not look, you did not know. Maybe you got along fine anyway. Today I look for nothing, it all lands on me while I scroll on my phone and every item that goes by is a reminder of something I do not know. I am not sure more tools come out now than ten years ago, but I am sure that back then I could comfortably fail to notice. Now I cannot.

I console myself with the thought that nobody else is up to date either. It works for a few minutes. Whoever seems expert perhaps read a thread half an hour before I did and put together a demo that runs on their laptop; how that code behaves in a real project, with real constraints and other people who will have to touch it, they do not know either. Showing that something works has become easy. Finding out whether it holds in production takes as long as it did ten years ago.

Nothing has time to settle

Everything I really know, I learned the same way: by using a technology long enough to watch it break and then go obsolete. Not in the demo, but in production, maybe fixing a bug on a Friday evening with someone waiting. The things I can explain well, I can explain because at some point they blew up in my hands and I had to work out why.

That step cannot be compressed. Time to read up on it is not enough, it takes time to experiment: weeks in which a choice shows its strengths and its weaknesses and eventually forces you to go back over it. It is what separates a senior from a less experienced developer who has only read the documentation, and it is exactly what I can no longer afford.

Today, before a technology shows its weaknesses, it has already been replaced by the next one. What is left is a paper thin layer of everything and a thick layer of almost nothing. I can get things done and for shipping a project that is enough. But if someone asked me to explain why a given choice works, or worse why it does NOT work, in plenty of cases I would have nothing to say. Since a coding agent writes the code, the distance between what I know and what I have to take on trust has grown: I read it, I try it and I approve it, but I no longer go through the mistakes, which were how I used to understand. And this is one of the hardest things for me to accept.

Back in July, in the post about getting my excitement back, I wrote that the risk was for the people starting now: skip the struggle and you skip the learning. It was easy to accept, because it was somebody else’s risk. What I have realized is that it applies to me too, it just shows less: I have the foundations underneath, so the gap is smaller.

Wrapping up

I do not have a strategy. A direction, maybe. It comes from something I had already written in the July post: over the years I moved from how things are built to the value of what I build. If I really believe that, the consequence is uncomfortable but acceptable: what counts is the result, not having taken the best route with the most efficient tool of the month.

In that same post I said I had made peace with letting go of the wheel on the how, as long as I kept the destination. What I had not factored in is that the how also includes the claim of having done it well. Giving that up is a lot harder than giving up writing the code line by line. Yet it is probably the part I need to let go of: if something works, holds up and I can maintain it, whether it was also the optimal solution is a question only I am asking.

The thing is, it bothers me; it is how my mind works. A discomfort that does not go away even when I know that letting go is the rational choice. I built myself on the idea that understanding how things work is the job, not a bonus you allow yourself when there is time left over. Letting that go feels like giving up, even when the results say otherwise.

Building new things, though, is as much fun as before, maybe more: that part is off limits. What changed is my relationship with what I build and I have not yet decided whether this discomfort is a leftover to get rid of or the only sensible thing I have left to listen to.

How are you handling it? Of everything you have used this year, how much could you really explain to someone who asks you why? Or have you stopped trying too?