Stop writing prompts. Write the brief.

The first time I used an AI coding tool properly, I did what everyone does. I typed a sentence describing what I wanted, the way you would ask a person, and I pressed enter.

What came back ran. It looked roughly right. It was wrong in a way that took longer to unpick than it would have taken to write from scratch, and I concluded, as most non-technical founders conclude, that these tools were built for engineers and I had been sold something.

I was wrong, but not about the output. The output really was unusable. I was wrong about what had caused it.

A prompt and a brief are not the same document

A prompt is a request. It assumes a reader who will fill in the gaps, ask you a question if something is ambiguous, and apply judgement about the parts you did not mention. That assumption is so deeply built into how we write that we do not notice we are making it.

A brief is a specification. It assumes a reader who will do exactly what it says, will not ask, and has no opinion about the parts you left out, because it cannot see that you left them out.

Every non-technical person’s first instinct is to write the first thing. And the reason that instinct is so hard to shake is that it has worked our entire careers. Write a loose brief for a designer and you get something reasonable back, because the designer quietly filled four gaps on your behalf and then, if you are lucky, told you about two of them.

An agent does not do that. It fills the gaps too (it has to, something has to go in the file), but it fills them with whatever is statistically ordinary, and it does not tell you.

What four years of not being able to build taught me

I co-founded Triisum in 2021 and ran it as CEO. I did the parts an operator does: fifty-plus customer interviews, ten-plus white-label agreements, two OTA partnerships, the NIC Islamabad cohort, a team of eight across engineering, QA and operations.

What I could not do was build any of it. Every idea I had went into a queue, and the queue was other people, and the queue was always full.

You learn a specific discipline running a company you cannot personally build. You get very good at writing specifications, because the specification is the only lever you have. You also get very good at watching a two-week estimate become six, and after enough of those you work out why: the thing in your head and the thing in the engineer’s head were never the same thing, and neither of you found out until the demo.

I thought that was a story about my limitations. It turned out to be four years of unpaid training in the exact skill that was about to matter.

The five things a brief has that a prompt does not

Here is the difference, concretely. Not “be more detailed”: that advice is useless because it does not tell you which details.

Constraints. What it must not do. Not the goal, the boundary. “Do not add a dependency.” “Do not change the public API.” “Do not touch anything outside this directory.” Most bad output is not a failure to hit the target; it is collateral damage somewhere you were not looking.

Edge cases. The empty state, the failure state, the too-many state. What happens when the list has zero items, when the request times out, when the user is logged out halfway through. An unspecified edge case is not omitted from the code: it is guessed at, and then it ships.

The location. Which file, which function, which layer. “Add this to the existing useInvoice hook” produces a fundamentally different result from “add this”, because the second one licenses a new file, a new pattern, and a second way of doing something you already had one way of doing.

A definition of done. What has to be true for this to be finished. Not “make it work”: “the form rejects an invalid email before submitting, shows the error inline, and the existing tests still pass.” Without this, “done” means “the model stopped generating.”

What it must not touch. Related to constraints but worth separating, because this is the one people leave out and then spend the afternoon on. The blast radius.

The uncomfortable part

Here is the thing I did not expect, and it is the reason this changed how I work rather than just what tools I use.

When I started writing real briefs, the output stopped being wrong. Same model that afternoon as that morning. Nothing about the technology had changed in the intervening four hours.

What had changed is that for the first time my specification was actually complete, and I only knew that because something had executed it literally enough to expose every single gap in it.

That is not a story about AI being good. It is a story about my briefs having been incomplete for years, and every engineer I ever worked with having quietly patched the holes without mentioning it. The tool did not make me better at specifying. It made me aware of how badly I had been specifying, which is a different and considerably less flattering thing.

What this does not fix

I want to be straight about the limit, because the version of this argument that gets sold on the internet does not have one.

You still need technical judgement. You need to be able to read the output and notice when it is plausible and wrong, which is the failure mode that actually costs you. You need to know enough to ask “why did it do it that way” and understand the answer. You cannot ship a production codebase with zero technical judgement, nobody can, and anyone telling you otherwise is selling you something.

What you do not need is to write the code.

Those are genuinely different requirements, and the gap between them is where I have spent the last stretch of my working life. Six products have come out of it (LittleOS, Liquid Finance, Safar, ThumbSnap AI, an autonomous publishing pipeline, and the Eco-Ambassadors app), and I still cannot write production code.

Try this today

Do not rewrite your prompt. The next time you get output you would throw away, write the brief you would have handed a contractor who cannot ask you a single question (constraints, edge cases, the file, what done means, what not to touch), and send that instead.

The difference is obvious inside an hour. You will not need to hire anyone to see it, and you will not need me either.