← Essays /Post · 01 of 26 · Philosophy

Making What I Don't Fully Understand

I don't fully understand the products I make. We always used things we couldn't see into, for reasons we trusted. As those reasons fade, what remains?

·5 min read · · · #philosophy#maker#ai-agents#solo-founder

Lately I sometimes feel like a stranger in front of the things I make. I clearly made them, I shipped them under my name, and when they break I am the one who has to fix them. Yet if you asked me to explain everything inside, there are places where I would run out of words. Not one or two. Many. I do not mean something I missed by mistake. A thing I missed, I can understand if I look again. I mean the kind I cannot understand even when I look. I do not know TypeScript, for example. Yet I ship TypeScript code that AI wrote, under my name. The code is all right there in front of me, and I cannot read it. Since I started making things alone with AI, this has become common. So the question will not leave me. If I do not fully understand what I made, is that a problem?


My first thought was that it had always been this way. I use chips without knowing what is inside them. People say there is no one in the world who can make a single pencil from start to finish alone. The person who fells the tree, the person who mines the graphite and the person who makes the eraser rubber each know only their own share, and the shares come together into a pencil. People have always used, and made, things they did not fully understand.

Nor did I understand more back then. If I looked at code I wrote a few years ago together with AI today, it would probably be full of bugs, with edge cases I never thought of scattered all through it. At the time I believed I knew my code. Knowing and believing you know were already quite different things before AI arrived.

So maybe not understanding is not the problem in itself. If a thing runs well, and someone can fix it when it breaks, and it does not matter whether that someone is a person or an AI, that is enough for most things. An IoT device in the corner of the living room that stalls now and then and starts again does not need a philosophy. But there are things this leniency does not reach. If it were a board controlling a nuclear power plant, I would accept no repair at all. Not because I do not know what is inside, but because no one could say it is safe enough. For things that lives depend on, “we can fix it later” does not hold. There is no later.


But if most of the time it really was fine, what made it fine? I do not know what is inside a chip, and still I do not doubt it. When I ask myself why, the answer is almost dull in its shortness. Because the chip has a company. Stretched a little further: others use this code too. This code is maintained. By someone. What I trusted was not the inside of the chip. It was that someone somewhere knows that inside, and that a great many people used the same chip before I did.

The way I trusted my junior’s code was a little different. At first I reviewed it line by line, and after we got through a project or two together, I found myself looking less. In the end it went this far: I trust code I asked my junior to write even when I do not understand it. Even if he leaves the company. That trust came from the time we worked together. And there was one condition I never said out loud. If I set my mind to it, I could read that code and understand it.

What about my own products? Looking back, what let me trust them was no great understanding. Tests and company procedure, and a shallow, meager understanding of the range I was responsible for. That was about it. Even so, things went out into the world and mostly ran well. Maybe what people need to trust and use something is not to know everything inside it, but a few reasons to trust it.


Those reasons are exactly what started to shake when I began making things alone with AI. The first to go was “I can read it and know.” Code that AI wrote may stay opaque even when I sit down and read it. When I first felt this clearly, the thought I had, written down as it came, was this: if I could not understand my junior’s code, maybe I am the junior and the AI is the senior. We easily assume the one who gives the work sits above. But can we really say someone sits above if they cannot read the results of the work they asked for?

Company procedure was gone too. When you build alone, no one sets the procedure for you. That turned out easier than I expected. Even building alone, I can make enough procedure through a harness. I set the tests, run the reviews, and keep a period of using it myself before release. What changed was somewhere else. Building alone, the range I am responsible for moved up. Before, I only had to answer for the part I owned; now the whole product is mine. For now, like a team lead. Like a CEO.

So I think the question of senior and junior can be answered this way. In the seat where the code is read, I may be the junior. The seat where someone answers for it is still mine. Even at a company, the one above in skill and the one above in seat were often different people. A team lead who could not follow every line of an expert’s code was still the team lead.


The trouble is that this seat will not last long either. Once I say that my range of responsibility moved up, I find myself trailing off: in the future even that will go. When the day comes that AI decides what to make, makes it, checks it, and even answers for it when it breaks, both the seat that decides and the seat that answers will leave people. Most people will become consumers then. I write this down as a prediction, not a wish.

Then this question cannot be avoided. If AI decides better and answers better than people, why should a person stay in that seat at all? Isn’t it right to leave it to whoever does it better?

I am not confident I can win this question with logic. Measured by who does it better, I can only lose. So from here on I write down a choice, not a proof. Even when that time comes, I want to be a builder who answers for things, decides, and makes them.

If you ask why, I can only answer first: because I want to. It is no different from why I play tennis. Even if a machine comes along that hits the ball more precisely, I will not put down my racket. Work that is good in itself remains, whoever does it better.

And I believe one more thing. That people will think there is value in it. It is not only a groundless hope. Even now many people choose what is cheaper and faster, but some buy a knife a craftsman made, or handmade things with uneven shapes, or works of art. What they buy is not only the knife’s performance. They buy something that holds that person’s care, effort and philosophy. Buying the thing, they also buy the person who made it.

If that world comes, the meaning of the word work will change too. Today work is earning money. By then earning money will no longer be work, and either only the hobby will remain or the hobby will become the work. Of course that time is not here yet. I still need to earn money, and what I make now has to sell and hold up by today’s standards. The choice in this essay is about that future.


Coming back to where I started, I think I set the question a little wrong. Not fully understanding what I made was not the problem. People have always lived that way. What I really needed to ask was what we trust when we use the parts we do not understand. We used chips trusting the company and the users, and a junior’s code trusting the time worked together. Those reasons disappearing one by one: that is the problem.

The more things there are that no one fully understands, the more it will be, in the end, the person who made a thing that lets us trust it. I want to stay that person.

ecro
Written by ecro

Created an LLM benchmark for firmware. EmbedEval →

Building a project-shaped agent harness for Claude Code, Cursor, and Codex. harness-maker →

Building a serial and SSH terminal where coding agents work on the board beside you. NeuroTerm →

Comments

Loading comments...