The Real Skill in Building With AI Is Writing the Brief · Hanh D. Brown

There is a job now where the whole task is describing to a machine what to build. The person doing it has never written code. Not a line. Artificial Intelligence (AI), meaning software that generates work rather than storing it, made that possible.

I keep turning it over, because it breaks the order I grew up with. You earned the right to build by learning the craft first. The craft has not vanished. It moved.

Speed is no longer scarce. These tools now return a working screen faster than a person can describe one. No typist beats that. The question underneath the work changes shape. It stops being how fast the thing gets made, and becomes whether the right thing got made at all.

That problem does not live in the machine. It lives in the person holding the request, and most requests are vague. Ask for a dashboard and a dashboard arrives, just not the one in your head. Yours carried details that never reached the page.

Like a genie who grants three wishes and not three million, the tool works from a fixed budget of attention. Every word it reads spends from that budget, and so does every file it opens and every step it thinks through. Spend that budget guessing what you meant and less remains for the build. Much less.

Researchers tested how models handle long inputs. The result was plain. Accuracy runs highest when the needed fact sits at the very start or the very end of what a model reads, and it sags in the middle, even in models built for long inputs (Liu et al.).

Position changes whether a fact lands. The constraint was never the machine. It is your ability to say what you want, in an order a machine can hold. This is where the difference between vibe coding and agentic engineering starts to bite. That is a writing problem wearing an engineering costume.

How much time should you spend planning versus executing?#

Roughly four fifths planning, one fifth executing. That ratio sounds absurd to anyone raised on the idea that shipping means typing. It stops sounding absurd the first time you lose a day. Undoing a build that went sideways from the opening prompt costs more than the build.

Consider what executing now costs. Almost nothing. A screen. A form. A whole small application, back in minutes. When the doing gets cheap, every hour belongs to the deciding, because a wrong decision now costs a rebuild rather than an afternoon.

Planning here does not mean a document with a cover page. It means talking the idea through until you can say plainly what good looks like. It means digging out the reference you keep gesturing at. It means naming what you do not want, which is easier to say and just as useful.

Skipping this saves nothing. You pay it back later, in a worse currency.

What documents should you write before you build anything?#

Write five, and put one plan above them. This is the change that separates a weekend toy from something that survives real users.

The shape matters as much as the list, so here it is drawn.

One master plan sits on top. It names the thing and its reader. Five documents sit under it, and each one answers a question the tool would otherwise guess at.

• Build plan. The stack, the order, what ships first.
• Design rules. What good looks like, carried in links and screenshots the tool can actually copy.
• User journeys. Who does what, step by step, including the unhappy path.
• Task list. Every task and subtask, in the order they get done.
• Rules file. How the tool behaves while it works.

That last one earns its keep. Read the plan, do the next task, report back. One file turns a scattered conversation into a routine, and your role changes with it. You stop prompting. You start reading output.

Tidiness is not the reason. Without those documents a growing project forces the tool to spend most of its budget rediscovering context it had yesterday. Hand it the map instead. The budget goes to the work.

I learned this the slow way. For a week I explained the same project again every morning, until I wrote it down once and the machine stopped needing me to.

Something better happens too. Context stops living in one person’s head. Step away, hand the project to a colleague, and the machine still knows what the project is. That is the line between one builder and a practice.

What is the parallel build method for a vague idea?#

Start the same idea four ways at once. It sounds wasteful, and it is the opposite, because the truly expensive path is committing to one wrong direction and then defending it for a week.

Make the four starts different in kind, not different in wording. Talk the idea out loud and drop in the transcript. Write one careful typed prompt. Add a screenshot of something you admire. Paste a snippet from a component library, because these tools read code more precisely than they read adjectives.

Now compare them by hand, because you will not pick a single winner outright. Lay all four on the table and you finally see the thing you were reaching for. Usually in pieces. One good idea here, a better layout there. Clarity arrives by comparison, which is how most of us find our taste in anything.

Like a singer who runs a phrase four ways before choosing one, you did not waste the other three. You learned what you actually wanted. You learned it before anything got built on top.

How do you debug when you cannot read the code?#

Use a fixed routine, and try each move once. The failure here is not the bug. It is the loop where you ask the same tool the same way over and over, and collect the same wrong answer every time. The order is the whole discipline, so here is the routine end to end.

First, let the tool fix it. Sometimes that ends the matter.

Second, add logging so the tool can watch the failure instead of guessing at it. Most stuck bugs are not hard, they are invisible, and the fix is giving the machine eyes.

Third, bring in a different tool. Another model reads the same problem with different habits. A fresh pair of eyes is a technique, not a superstition.

Fourth, revert to a clean state and ask again. This feels like defeat. It is usually the fastest road out, because you stop fixing a fix of a fix.

Here is the uncomfortable part. Most bugs trace back to the request. A vague ask produced a confident wrong answer, and the machine did its job. So after a fix lands, ask the tool how you should have asked. Write that lesson into the rules file. The routine gets better at working with you.

Which skills gain value when everyone can produce good enough?#

Judgment gains. Everything scarce only because it was slow is about to become ordinary. Ordinary is cheap. Cheap is not where value sits.

Watch what happens when the floor rises. Once every team can produce a competent version of anything, competent stops being worth paying for. What stays scarce is the ability to tell competent from excellent, and to point a fast tool at the second one. That is taste. Taste is built from exposure, not tutorials.

The economics already show up in measured work. Across more than five thousand customer support agents, a generative assistant raised issues resolved per hour by fourteen percent on average, and by thirty four percent among the newest and least skilled, while the most experienced barely moved (Brynjolfsson, Li and Raymond).

Read that number twice. It cuts both ways. If your edge was being quicker at routine work, that edge is thinning. If your edge is knowing which work deserves doing, it just appreciated. That is where the longevity test for a job lands from the other direction, and it runs through where your real advantage sits as well.

So here is where it settles at my kitchen table. My daughter will not compete on how fast she produces something. That race is finished, and a machine won it. She will compete on whether she can look at four versions of a thing and know which one deserves a person’s attention.

I cannot teach that with a tutorial. I can only put good work in front of her, again and again, and talk about why it is good. The brief is the job now. Writing a good one starts with knowing what good is.

Source: Lazar Jovanovich, a professional vibe coding engineer at Lovable, on Lenny’s Podcast.