How to build software with AI agents: a starting guide

Building software used to mean writing every line yourself. It doesn't anymore. With an AI coding agent, the job shifts from typing the code to directing the work — and that shift is what lets a business person who decided to start shipping actually ship, alongside the developers who've done this for years.

But "the agent writes the code" is where most people stop, and it's why most people end up with a mess. The difference between shipping and flailing isn't the model. It's a handful of habits. Here's the starting set.

What changed: you direct, the agent builds

The first reframe is the whole game. You are not the person hauling rope anymore. You're the one setting the course.

An agent can write the boilerplate, run the tests, wire up the API, and chase the typo. What it can't do is decide what's worth building, judge whether the result is actually right, or own the standard the work is held to. That's your half — and it's the half that was always the hard part.

So stop measuring yourself by lines written. Start measuring by decisions made and outcomes shipped. The agent is the crew. You're the pilot.

The build loop

Almost all good work with an agent runs the same small loop. Coding agents even show it to you as it happens — Anthropic describes capable agents as running exactly this kind of gather, act, verify loop until the work is done:

1. Brief. Say what to build, what not to build, and what "done" looks like.
2. Act. The agent reads the relevant context, makes the change, runs the tests.
3. Review. You check the result against your standard — not just "does it run" but "is it right."
4. Capture. Write down anything learned, then go again.

Most of your leverage is in step one. A vague brief gets a plausible, drifting result. A sharp brief — here's what to build, here's what to leave alone, here's how I'll know it worked — gets something you can actually trust. The brief quality is the bottleneck, not the agent's capability.

The Pilot model in one minute

It helps to hold a single mental model: you're a pilot, not a crew member.

A crew member writes the boilerplate. A pilot writes the brief that constrains the boilerplate. A crew member chases a bug for three hours. A pilot sets a time limit and escalates. A crew member updates the docs after the fact. A pilot writes the session note as part of the work.

Stuart Leo

The crew measures output in lines written. The pilot measures it in decisions made and outcomes shipped.

The reason this matters isn't motivational — it's practical. The pilot's work (clear briefs, clear standards, clear records) is exactly the work that makes the agent good. Do the pilot's job well and the crew gets dramatically better. Skip it and no model will save you.

The one habit that compounds

If you take one habit from this, take this: at the end of every session, write a few lines about what changed, why, what's verified, and what's next — and commit it to git.

It feels almost too small to matter. It's the most important thing you'll do. An agent has no memory between sessions — close the laptop and everything it understood is gone. That note is the memory. Tomorrow's session (and tomorrow's agent, and your collaborator next week) reads it and starts ahead instead of from zero.

Do this for a few weeks and the effect is striking. The decisions, the gotchas, the reasons — they accumulate into a written record of how your project actually works. That record is a contextbase, and it's the thing that turns building-with-agents from a treadmill of re-explaining into work that compounds.

Avoiding the vibe-coding trap

There's a failure mode that catches almost everyone, and it has a name now: vibe coding — letting the agent build from a vague feeling instead of a spec.

It's seductive because it's fast, and it's genuinely fine for a throwaway prototype. The danger is using it for anything you intend to keep. With no brief and no way to check the result, the agent produces code that looks right, drifts a little further from what you meant with each change, and quietly rots as the project grows. You don't notice until you're deep in a corner you can't see the edges of.

The fix is cheap. Before a real change, write the short brief — and include at least one acceptance criterion you can actually run ("the form rejects an empty email", "the test suite passes"). If you can't state how you'd know it worked, the agent can't either, and you've just authorised it to guess. A brief with runnable criteria is the cheapest insurance you'll buy.

Where to go next

Three habits carry the whole thing: direct instead of type, run the brief-act-review loop, and write down what each session learned. Get those and you're building with agents, not just generating code.

Building with agents isn't about better prompts — it's about giving the agent context worth acting on, every time.

Start here: run your first session, learn context engineering, or read the method underneath it all.