I spend a fifth of every project before I write the first prompt

The last substantial thing I built was answer-engine and generative-engine optimisation for my own site — the work of making a site legible to models rather than only to search crawlers. The first thing I did was not open an editor, and it was not open a chat window either.

I went and found out what the thing actually required. That took a couple of days. The prompt that started the build took about twenty minutes to write and the first working version arrived shortly after. Those proportions are not an accident and they are not unusual for me — they are the method.

#Generating is the cheapest phase

If I break a project into its parts, it comes out roughly like this every time:

Sit with the middle row for a moment, because it is the row that changes how you should work. The part everybody optimises is already the fastest part. Getting something standing up is close to free now. That means speed of generation is not the constraint on the quality of what you ship — judgement is, at both ends of it.

Research is judgement applied before the work. Auditing is judgement applied after. The prompt in the middle is just the moment those two meet, and it is the part that gets all the attention because it is the visible one.

#What the research actually is

Not asking a model to explain the topic to me. That produces a summary I have no way to evaluate, which is precisely the position I am trying not to be in.

I download the real material — specifications, documentation, published guidance, whatever the primary sources are for the thing I am about to build — and I read it myself. For the optimisation work that meant reading how answer engines actually select and quote content, rather than reading somebody's listicle about it.

I do not keep a checklist, a scratch file or a planning document. People are sometimes surprised by that. The downloaded material is the artefact — I read it, and what I need from it ends up in the prompt. Adding a document between those two steps would be process for its own sake, and I would stop maintaining it inside a month.

#Then the prompt, written once and written long

Only after that do I write the prompt, and it is long. Four things are always in it:

• Context — what this system is, what already exists around it, what it has to fit into.
• The goal — what the finished thing has to do, stated as an outcome rather than as an instruction.
• Examples — worked ones, showing the shape of what I want rather than describing it.
• Constraints — what it must not do, which is usually the half that gets left out.

None of this came from a disaster, and I want to be straightforward about that because process advice is usually trauma-shaped — somebody lost a week, and the habit is the scar. Mine came from courses. I went and learned prompting and context engineering deliberately, before I had built anything worth losing, and I have written prompts this way since.

I mention it because "I learned this the hard way" is a more satisfying story and it would not be true. The dull version is that this is a learnable skill and it was available to learn.

#What skipping it looks like

On the occasions I have gone straight to the prompt, the failure is consistent and it is not dramatic. Nothing crashes. What happens is:

• The output is not wrong, exactly — it is not what I wanted.
• It is confused, in the specific sense of having merged two approaches that should not have been merged.
• I spend the next hour steering it, which costs tokens.
• And it costs time, which is the one I actually mind.

That last hour is always longer than the research would have been. That is the whole argument, and it is arithmetic rather than philosophy.

A vague prompt does not produce an obviously bad answer. It produces a confident one you then have to argue with.

#The habit this pairs with

Research at the front only pays off if there is review at the back, and the review half is the one I would defend hardest. I do not let the coding agent run on its own. No auto-accept. I read the diffs before they land, I read the summaries it writes, I read the commit messages.

Some of that is control — it is a codebase I did not type, and reading is how I keep an accurate model of what is in it. Most of it is learning. Nearly everything I know about building I learned from reading a change carefully enough to decide whether to accept it, which is a slower and considerably better teacher than reading a tutorial.

So the shape of a project, for me, is: read a lot, write one careful prompt, then spend the majority of the time on everything the prompt did not get right. The middle step is the one that looks like the work. It is the one that matters least.