When AI writes the code, direction is the job

AI coding agents have changed where I spend my time. On my projects, there's little reason left to type code by hand. Agents write, test and refactor quickly and well. They can propose what to build, too.

But setting the goals and deciding whether the result serves the business is still my responsibility. That's direction, and because a wrong assumption now turns into working software within hours, it matters more than it used to. So the time I used to spend writing code goes into direction instead.

Implementation is no longer the slow part

A coding agent is an AI that works in your codebase: it reads the code, writes changes, runs them and fixes what breaks. With one, a small team ships in days what used to take weeks.

Tests get written alongside the code, which removes most of the wait. They don't remove the checking, though. Tests written with the code can share its mistaken assumptions, so someone still has to judge what they cover, how the pieces behave together, and whether the product does what it should.

Testing how an AI product behaves is its own problem, which I covered in how to test whether your AI agent follows instructions.

What hasn't sped up is deciding what to build and judging whether it's right. An agent will build whatever you point it at, quickly and confidently. If you point it in the wrong direction, you get the wrong thing quickly.

What direction means

Direction is everything the agent can't work out from the code alone:

• Vision and mission. Why the product exists and what good looks like.
• Audience. Who uses it, what they know, what they need.
• Requirements. What it must do, and for whom.
• Boundaries. What it explicitly includes, what it explicitly excludes, and the lines that can't move.
• Roadmap. Where it's going next, so today's choices don't block tomorrow's.
• Architecture. How the pieces fit together, and what each one is responsible for.
• Technology choices. The languages, frameworks and services you've committed to.

No one person holds all of this. Vision tends to come from leadership. Audience comes from whoever is closest to customers, in sales, support or research. Boundaries come from legal, finance and the people who know where the risks are. Architecture and technology come from engineering.

So direction is an organisation-wide contribution, not a document one person writes. And it builds over time. Every review that turns up a gap adds to it, so the direction behind your tenth feature is far richer than the direction behind your first. Someone still needs to settle disagreements and keep that shared direction current, or it fills up with guidance nobody believes any more.

Written down, this isn't paperwork. The agent reads it, so it's an input to the build.

Where bad results come from

When direction is missing, murky or wrong, the result often goes wrong in one of three ways:

• It doesn't do what you expected. The agent filled the gaps with its own reasonable guesses, and they weren't yours.
• It does what you wanted, badly. It works in the demo and slows to a crawl with real data, because nobody said what real data looks like.
• It boxes you in. It solves today's problem in a way that blocks next quarter's, because the agent never saw the roadmap.

These failures can start with missing direction. When they do, fixing the code without correcting the brief leaves the same misunderstanding ready to surface again.

Not every failure is a direction problem, though. An agent can be given a clear requirement and still get it wrong, and a good brief shouldn't have to spell out basic engineering.

When a result disappoints, ask which it was: did the direction leave something out, did the agent misread it, or did the implementation fail? Each needs a different fix.

Good direction answers questions. Great direction helps the agent make decisions.

Good direction answers the agent's questions before it has to guess: what to build, for whom, and within what limits. The result does what you asked, the way you'd expect.

Great direction pays more. When the agent knows why the product exists, who it's for, what it must never do and where it's heading, it starts making the calls you would have made without being asked.

It handles the case you forgot to mention. It structures things for the feature you're planning next. Now and then it does something better than you'd have thought of.

How I design screens for Atty

Clean interface design follows well-worn patterns, which makes it a good fit for AI. Instead of spending hours drawing one minimal layout, ask for five to ten working versions and pick.

Atty tells the story of a house, and its interface sits on a design framework I hold to an Airbnb level of polish: a set type scale, spacing, cards, photo treatments and components. That framework is the direction.

When Atty needs a new screen, such as the page that lists a home's appliances and their warranties, I don't draw it. I ask for several layouts built from the framework, put them side by side, and pick one. Every option already looks like Atty, so the choice is about what serves the homeowner, not whether it's on-brand.

For the warranties page, I picked the layout that put warranties ending soon at the top, ahead of the full list sorted by room. People open that page to find out what needs attention, not to browse their oven.

Design skill doesn't go away. It moves into the framework and into the choosing. The hard design work is deciding what the framework should be and knowing why one layout is right. Drawing the fifth variation of a list page is not where that skill is best spent.

How I approached billing

I've built billing systems many times. The mechanics are well established: billing records are never edited, corrections are new entries, and every charge traces back to what caused it. It's well-trodden ground, and on my projects agents have handled it without much steering.

What an agent can't know is your pricing strategy. When I added usage-based billing to Yak, the hard part was never the ledger. It was deciding what to charge for:

Given the murky version, one reasonable reading is to meter every model call. That would be accurate and well built, and wrong for the business.

Customers would pay for how hard the system worked rather than for what they got, and their bills would shift whenever the underlying model changed. The clear version carries the strategy, so the billing respects it. The code quality is the same either way. The direction isn't.

Where your time goes now

Writing code used to be the slow part, so it got most of my time. Now my time goes into a loop: setting direction, reviewing what comes back, and working out how the direction needs to grow so the same bad outcome doesn't happen twice.

When a result disappoints, "what did my direction leave out?" is the first question I ask. It's often the answer, and when it is, the fix carries into everything I build next.

That loop is about you. Not the model, and not the harness (the tooling that runs it), both of which will keep changing. The direction you've built up carries over to whatever model comes next.

All of this can look like more work, not less. It isn't. The whole loop runs far faster than writing the code ever did, so I ship more, sooner.

And because direction is written in plain language, the people who know the customers, the market and the product best can now work on the bottleneck directly, whether or not they write code.