Deliberate Optimization

You are always optimizing. If you do not make the target explicit, it will form through convenience and the pressures around you — and what you build on it may be hollow all the way down. — from A Renaissance of Thought by Jake W. Casselman.

You are always optimizing. If you do not make the target explicit, it will form through convenience and the pressures around you — and what you build on it may be hollow all the way down.

You are always optimizing.

There is no neutral way to sit down to write, code, or think. Every act trades one thing against another: precision against speed, reach against accuracy, comfort against truth. The trade happens whether or not you notice it.

The previous chapters built a set of instruments: the workbench, the scaffolding, the audit, the duet. This chapter asks what those instruments are pointed toward. Each is a way of using the new tools well, but well is always relative to a target. The same machine can accelerate work you already understand, deepen your understanding, or replace the part of the process where understanding would have been built. The question that comes first is simple: what is this act for?

When the Target Forms Around You

A group can acquire a direction without anyone choosing it. Writers anticipate readers, readers adapt to platforms, platforms reward retention, and institutions copy what appears to work. Each adjustment is local, but together they bend writing toward reach, accessibility, volume, and cadence. Nobody needs to decide that volume matters most for the culture to behave as though it does.

Alone with the tool, convenience creates the same kind of drift. Whatever asks the least of you gains an advantage, so the target slides toward speed. The work can acquire a direction before you ever state what it is for. That is why an ambient target rarely feels like a target. It feels like reality: simply how serious writing, efficient work, or competent thinking is now done.

The poll from the fourth chapter is a small example. I asked whether people deliberately under-edit their writing so it will not look machine-made. A third said yes. They removed em dashes, roughened clean sentences, and introduced small imperfections by hand. No one had to invent that rule. Readers began treating certain features as evidence of AI, writers anticipated the suspicion and changed their prose, and the response hardened through repetition.

Some people may examine that pressure and decide the trade is worth making. Others may follow it without ever making the target explicit. The distinction is whether the pressure was examined before it became the reason.

If you would answer differently in an empty room, ask whether the difference is evidence or pressure.

The empty room is not automatically right, and a norm may be sensible. But repetition is not evidence. The point this chapter is after is therefore not optimization. Everyone optimizes. It is deliberate optimization: bringing the target into view before convenience or the surrounding pressure settles it by default.

Three Different Jobs

Every time you open the chat window, you are there for one of at least three things. Each calls for a different use of the same tool.

The first is speed. The idea and logic are already formed; what remains is the labor of turning them into a finished form. A meeting summary. A routine email. A structure you were going to revise anyway. Here, let the machine carry as much as it can. Nothing important was going to be built in the transcription.

The second is understanding. Here the friction is not in your way; the friction is the mechanism. When material feels easy to process, people can mistake that fluency for mastery. When a sentence refuses to cooperate, the difficulty of getting the words right is often inseparable from the difficulty of getting the idea right. Finding your own words is how the idea gets compressed until it becomes yours. Call that codification.

Outsource the codification and you do not merely skip labor. You skip the place where the understanding was going to be built. The machine should therefore explain, challenge, take the tangent, and ask the question that breaks your current version. It can expose the shape of the thing, but you must perform the compression.

The third is generative thought. You are not producing a finished piece or mastering settled knowledge. You are chasing a thought you do not yet have. Here the machine can hold the structure, remember the branches, and track the thread while your associative mode runs longer than working memory alone permits. Not offloading the thinking — offloading the holding. The last chapter called this the duet.

These modes can chain. A good duet may produce a phrase you did not have, a frame that feels useful, or a place to begin looking. But fluency is not knowledge. Ease of processing can make an idea feel more compelling before it has been tested. What surfaces in generative thought still has to pass through codification before it becomes understanding. The failure begins when an understanding task is run on a speed target.

What Vibe Coding Reveals

Coding has already named the failure. Vibe coding means describing what you want, accepting what the machine produces, and barely looking under the hood. You do not need to be a programmer to see the distinction it exposes. In software, syntax is the exact language the computer requires. Architecture is the deeper plan: what the parts are, how they connect, and which part is responsible for what.

For small things, letting the machine handle both can be miraculous. Push it far enough and the problem becomes clear. You did not merely let the tool translate your intention into code; you let it decide how the whole system should fit together. The result may work, more or less, but it is opaque to you. When it breaks, you cannot locate the failure because you never built a map of the parts. You can only ask for it to be fixed. Once you outsource the decisions rather than merely the execution, you also lose some ability to judge what comes back. The understanding needed to ask the right next question is the very thing you let the machine hold.

Coding makes the distinction visible. On one side, the tool carries the exact instructions while you retain the plan. On the other, it carries the plan and leaves you only with the visible surface: the buttons, the outputs, and the impression that the thing works.

Writing has the same line. The machine can carry transcription while the idea remains yours, or it can begin doing the logic, sequence, and load-bearing joints. What becomes opaque is not a codebase but your own argument. That is why surface debates about em dashes miss the point. The question is not whether a machine touched the prose. It is what part of the thinking the machine carried.

The Hollow Heuristic

We move quickly by compressing repeated experience into patterns. You encounter something unfamiliar and at first process it slowly and deliberately. After enough passes, its shape becomes familiar. Familiarity compresses into recognition, and eventually you stop working through every component. That compressed pattern is a heuristic. It frees deliberate thought to go elsewhere, but it also runs faster, so it often answers before deliberate thought has begun.

I open an email structured like every email of its type and do not really read it. My eyes move, and I would swear I am reading, but recognition reports back before comprehension reaches the bottom. Most of the time that is useful. Then one sentence changes in a way that matters, and the same heuristic gives me a confident answer to a question I never examined.

An earned heuristic is a compression of passes you actually ran. Because you built what was compressed, you can run it backward. You can interrupt recognition, unpack the pattern, and inspect its parts. When the pattern fails, there is somewhere to go back down to.

Now return to the vibe coder — or to anyone using a tool whose output they can operate but not explain. They never ran a deliberate pass on the underlying structure, so there was nothing in them to compress. What they have is the feeling of a heuristic: ease, confidence, and familiarity with what the system appears to do. The compression happened elsewhere, and they imported the result. Call that a hollow heuristic.

A wrong heuristic can be decompressed and corrected. A hollow one cannot be decompressed from your existing understanding, because there is nothing in you to unpack. It can still be corrected, but only by building the missing understanding rather than recovering knowledge already present. Until then, deliberate thought has no components to work on when the heuristic fails: no assumptions, relationships, vocabulary, or model. That is the loss: the capacity to go back down.

The fifth chapter called the feeling borrowed: phrasing that is not yours, logic that feels accepted rather than verified. The test is simple. Can you reconstruct the thought with the tool out of the room? Not recite it. Rebuild it. Do not run that test with the machine present; it can supply the missing structure while you are trying to discover whether the structure is yours.

Declared Debt

None of this means you must understand everything from first principles. When I write in Python, I use packages other people made without reading all the code inside them. An import statement is simply an explicit declaration that part of the work came from somewhere else. Everyone relies on things this way. You can drive a car without knowing how to build an engine, follow a forecast without deriving the weather model, and use a calculator without designing its circuits. You do not need to rebuild each tool before you are allowed to use it.

The debt is declared: the import statement announces it. It was earned elsewhere: someone performed the work even if I did not. It is auditable: tied to a specific version, repeatable, and open to inspection. If it breaks, I can follow the trail backward until I reach ground I understand. Declared debt, with a ledger. That kind of dependency is necessary. It is not a hollow heuristic unless I mistake the imported result for understanding I possess.

An idea taken from a model without a codification pass is different. It does not arrive labelled as an import. It enters the texture of your own thought because its fluency resembles something you earned. There is no import statement at the top of a mind, and there may be no stable trail backward. Ask again and the answer may change. You may have no version, source, or sequence of reasoning to inspect: only the answer without the path that would let you repair it.

One recent preprint calls the accumulated effects of this kind of offloading cognitive debt. The useful part of the term is debt: something has been deferred, and will likely come due. The problem is not that the debt exists. The problem is forgetting that you owe it.

Why This Matters Now

Hollow heuristics are not new. People have always absorbed beliefs, habits, and judgments they could not reconstruct. What changed is the rate. A model can produce more fluent explanations in an afternoon than a person could once have encountered in years. Each one can be accepted before it is tested, and none arrives marked as unearned. The production of apparent understanding has accelerated. The work required to turn it into actual understanding has not.

The mechanism does not stop at the individual. The same acceleration affects targets at the scale of groups. Platforms can expose millions of people to the same proxy at once. Writers optimize for engagement because engagement is visible. Teams optimize for output because output fits on a dashboard. Nobody needs to endorse the proxy as the purpose. Once enough people react to it, it begins organizing the work.

That is why the first question matters. Without it, speed quietly governs tasks that required understanding, and group pressure quietly governs choices that were never examined.

Where Hollowness Can Live

You cannot earn everything. Most of what makes a life possible comes from elsewhere: language, mathematics, tools, institutions, and other people’s expertise. The question is not whether some of your knowledge will remain hollow. The question is where you allow the hollowness to live.

Some things can remain imports. You do not need to understand the inner workings of every tool you use or derive every fact you rely on. But some things must remain decompressible: the structure of your argument, the assumptions beneath your judgment, and the reasoning you will need when the familiar pattern fails.

Confidence cannot tell you which is which, because confidence is what the hollow heuristic counterfeits. Consensus cannot tell you either. A group can preserve real understanding, but it can also stabilize a pattern nobody has examined. The test is whether you can go back down: leave the fluent answer behind, recover the components, and rebuild the thought without the tool. Can you locate the assumption that failed? Can you tell where your understanding ends? If not, the machine carried the part of the process that would have made the thought yours.

Ask what the work is for before you reach for the tool. Then decide, deliberately, what you should be optimizing for. Otherwise, you may optimize for the wrong thing.

Written in Honolulu, July 2026