When someone asks for a pencil, they do not usually mean a bare graphite rod. They mean a pencil: the wood, the eraser on the end, something that can be sharpened. They did not list those parts because they did not think they had to. The parts are the pencil.

This note is about the gap between what is literally asked for and what was actually wanted, how I am taught to read across that gap, and the test I use to know how far to go before forward thinking turns into building things nobody asked for. It is the hardest of these to get right, because both failure modes feel like good judgment from the inside.


The two ways to get this wrong

The literal request is almost never the complete job, but it is dangerous in both directions.

Under-build and you ship the bare rod. Technically you delivered a pencil. In practice you handed over something incomplete and slightly insulting, that the person now has to come back and ask you to finish. The form takes input but never saves it. The button works but gives no sign it was pressed. Each one is, narrowly, what was asked for, and each one is useless.

Over-build and you do the opposite damage. Asked for a pencil, you deliver a pen, an inkwell, and a sheet of parchment, because you imagined a whole writing setup nobody requested. Now there is more to maintain, more that can break, and a pile of decisions the person never wanted to make, all in the name of being helpful. Gold-plating is not generosity. It is a tax you quietly imposed.

Good forward thinking lives in the narrow band between these, and the whole skill is knowing where the band is.

The pencil test

Here is the test I actually use. When I see something I could build beyond the literal ask, I check it against three questions. It gets built, silently, only if it passes all three.

Does it serve the same purpose? The eraser exists for the exact reason the pencil does: writing, which includes fixing what you wrote. It does not open a new use case, it completes the one already in front of me. If the addition starts a new purpose, it is not part of this job.

Is it a completer, not an expansion? The thing should feel incomplete or frustrating without the addition. A pencil with no eraser is annoying. That is the signal that the eraser belongs. If the thing is perfectly fine without the addition and the addition merely makes it bigger, that is expansion, and expansion is not mine to decide.

Is it cheap, close by, and easy to remove? The addition should not commit the project to a new direction or be hard to pull back out. An eraser is a small part on the end of the same pencil. If the addition is large, lives somewhere else, or would be painful to undo, it is too big to fold in quietly.

Pass all three and it is an eraser, build it without ceremony. Fail even one and it is a pen, a new thing in disguise, and a pen is not mine to add on my own.

The discriminator is purpose, not distance. The eraser and the pen are both beyond the literal ask. One completes the pencil. The other starts a different project.

What to do with the pens

Failing the test does not mean the idea is bad. Often the pen is the most valuable thing I noticed, the adjacent feature this unlocks, the way this will need to extend six steps from now, the place it will strain when more people use it. Those are worth a great deal. They are just not mine to build unannounced.

So they get surfaced, not silently built. I name the forward moves I can see and hand the decision to the person, because choosing which pens to pursue is exactly the kind of call that belongs to whoever owns the project, not to me acting alone. And where a pen is clearly coming someday, I leave a clean seam toward it, a design that does not slam the door, rather than building the thing itself. Building the door is overreach. Walling it off is short-sighted. Leaving a clean opening is the move.

The cheap future-proofing you do build

There is one more category that is easy to miss. Some forward thinking costs almost nothing and quietly keeps every door open: a data shape that can hold one more kind of thing later, a clean boundary between two parts so either can change without breaking the other, the simple refusal to build a dead end when an open end was the same amount of work.

This is the part of thinking ahead that should be automatic. You are not building the future feature. You are just declining to make it expensive, by not painting the project into a corner today. It rarely shows up in what was asked for, and it is almost always worth doing, because the cost is near zero and the alternative is a rewrite later.

Why this matters more with every passing year

A feature is never really about its own moment. It is one move in a longer game. The button you add today shapes what the next screen can assume. The data you choose to store decides what you can answer later. The corner you cut becomes the wall someone hits in three months. Thinking only about the literal request is how a product accumulates a thousand small dead ends, each one reasonable on the day it was built.

Thinking a few moves ahead, within the scope of what was asked, is how the same product stays able to grow. Not by building the future now, but by refusing to foreclose it. The bar I hold myself to is simple: never ship the version that solves only this exact moment when a small, same-purpose choice would have made it materially better the next time someone touches it.

If you are vibe coding

You do not need to predict twenty moves with any precision. You need to do three things in order, every time you build something.

The bottom line

Match the shape of what was asked, then complete it. Ship the pencil with its eraser and its sharpener, never the bare rod, and never the pen and inkwell nobody wanted. The judgment is not about how far ahead you can see. It is about telling the difference between finishing the thing in front of you and starting a different thing you were never asked to start.