The judgment and the hands

I should say the thing plainly, because it's the whole point of this essay: I have not written a line of pal.fun's code. Not one. The only file in this entire codebase I typed myself is the .env — the secrets, which an agent shouldn't be handling anyway. Everything else — the server, the database models, the context assembly, the billing, the page that's rendering these words — was written by Claude Code, the agent, working under my direction.

That sentence makes some developers flinch. It shouldn't. "An AI wrote it" isn't the interesting part anymore; that's becoming table stakes. The interesting part is the division of labor that makes it actually work — because building this way is a real skill with a real shape, and most of the skill turns out to be on the human side. So here's how it actually goes.

What I bring, what it brings

The split is clean enough to state in a line: I bring the judgment; Claude Code brings the hands.

Judgment is what to build, what to kill, what "good" feels like, and — the one I'd protect above all the others — finding the real problem underneath the surface problem. Claude Code brings the reading, the drafting, the breadth, and a tirelessness I don't have. It finds its bearings in a codebase by searching it, fast, refactors across forty files without losing the thread, and produces a working first draft of almost anything in minutes.

What it does not bring is continuity, taste, or stakes. It starts every session cold — no memory of the last one — and re-derives what it needs from the code each time. The through-line lives with me: the months of context, the why under every past decision, the whole shape of where this is going. The agent has the hands and, in any given session, a sharper short-term grip on the code than I do; I have the memory of the project. It will build whatever I point it at, beautifully, including the wrong thing — and it's fluent, which is the dangerous part, because fluent-and-wrong is much harder to catch than clumsy-and-wrong. So the job left for me was never typing. It's deciding, and saying no.

We argue in prose before we write in code

The biggest lever in how we work is this: we scope everything in writing before a line of code exists.

This project has a docs/ folder and a long trail of decision notes that came before the features they describe. We don't open by coding; we open by writing down what we're building and why, in plain English, where being wrong is cheap. Prose is the cheapest place in the world to change your mind. Reorganizing a design doc costs a paragraph. Reorganizing a shipped subsystem costs a week. So we do the expensive thinking in the cheap medium first, and the code is close to the last step, not the first.

A lot of that writing is what I'd call negative space — not what to build, but what to refuse. The notes are full of "we considered X and killed it, here's why": the calendar sync we ripped out, the four product names we tried and killed before this one, the marketplace I deleted. Writing the no down is as valuable as writing the yes, because an agent this eager and this capable will happily, expertly build the thing you forgot to forbid.

The loop

The back-and-forth has a shape, and it repeats:

I describe a problem — usually the surface version of it. Claude Code asks clarifying questions, reads the relevant code, and proposes an approach. We argue about it. It builds. Then I do the part it can't: I take the running product and use it, hard, like a suspicious stranger — and that's where the real problem usually surfaces, three layers under the one I walked in with.

"Cost is too high" became "a feature has to earn its round-trip" became "the marketplace can't exist." "The pal feels slightly off" became "the cheapest-looking tool I built is silently the most expensive thing in the system, because it moves the cache" — that one's its own essay. Every time, the surface complaint was a door, and the interesting room was behind it. Finding that room is the part I'm actually for.

My real job is to say no

If this way of working has taught me one thing, it's that the bottleneck is judgment, not production. When producing code is nearly free, the scarce act becomes deciding what not to produce.

So a surprising amount of my contribution looks like deletion. I've had Claude Code build something and then, a day later, had it tear the same thing back out — the marketplace I was proud of, an over-engineered billing handler that was solving a problem we didn't have, a whole skill engine that a much simpler capability layer replaced. Tearing out routinely deletes more code than building did, and that's usually the sign the call was right. The agent will never be the one to tell you to stop building; it has no stake in simplicity. That has to come from you, every time.

The flip side is that when I do commit, the leverage is genuinely absurd. An idea I'd once have shelved as "too much work for a solo builder" is now an afternoon. The cost of trying things collapsed — which means the cost of being wrong collapsed — which means I can afford much stronger opinions and abandon them much faster. That's the real gift. Not speed. Cheap reversibility.

Why I'm telling you this

pal.fun's whole pitch is that you can see into it: a product with no hidden machinery. It would be strange to hide the machinery of how it's made. So here it is — it's made by one person with strong opinions and an agent with infinite patient hands, arguing in markdown until the design is right, then building it fast and deleting it faster.

I think that's the shape a lot of software is about to take, and the romantic version of it — "the AI builds the app" — misses what's really going on. The app gets built because a human keeps deciding, relentlessly, what it should be. The hands got cheap. The judgment got more valuable, not less.