How Senior Engineers Actually Build With AI

The fastest people I've watched work with AI agents type the least. They spend most of their time on the part that isn't code — and that's exactly why the code part goes faster than everyone else's.

Here's the answer up front: the people getting durable results from AI agents don't open the chat and start building. They write the system down first. What it does. The rules that can't be broken. What "done" looks like. Then, and only then, the agent starts coding.

That ordering is the whole game.

I watched a long walkthrough that builds a full production app this way (JavaScript Mastery on YouTube). The app it ships is fine, but the app isn't the point — the method is. The surprising part isn't how clever the prompts are. It's how much of the session goes by before any code gets generated at all. Half an hour of writing things down. Defining what the system is supposed to do. Naming the rules. Then the AI runs.

The name floating around for this is spec-driven agentic development. Strip the buzzword off and it's simpler than it sounds: make the AI a disciplined implementation engine, not a guesser.

Why this matters

If you've used AI agents the lazy way — "build me a thing, here's a vague description" — you already know the failure mode. The first version sort of works. You iterate. Every pass drifts a little from the last one, because the model has nothing solid to anchor to. Six prompts later you've got a Frankenstein codebase, and you can't even tell which parts were the model's idea and which were yours.

Anchor the model to a written design before it writes a line, and that drift collapses. The code gets generated against a fixed reference instead of a fuzzy conversation. You can swap the model out, restart the session, hand it to a different person — and the work keeps going, because what the agent reads is the spec, not the chat history.

That's the difference between speed that compounds and speed that buries you.

The six-file system

The pattern that keeps showing up is a context/ folder at the root of the project with six markdown files. They're plain on purpose. The value isn't that they're clever — it's that they exist, they're short, and they're true.

A "spec," if the word's new to you, is just a written description of what you're building and the rules it follows — design first, code second.

1. project-overview.md — what you're building, who it's for, what success looks like, what's explicitly out of scope. One screen. No vague words like "good" or "intuitive" — those don't tell the agent anything.
2. architecture.md — the tech stack, the system boundaries, and the invariants that can't be broken. "Auth always goes through Clerk." "All writes go through the repository layer." The things that should make an agent stop and ask before it touches them.
3. code-standards.md — your conventions. TypeScript strict mode, file naming, import order, the boring stuff the agent will quietly violate if you don't write it down.
4. ai-workflow-rules.md — how the agents are allowed to work. One feature at a time. No drive-by refactors. Update the tracker after every unit. This is the file that keeps the scope from sprawling.
5. ui-context.md — design tokens, palette, type scale, component conventions. So the UI work matches the rest of the system instead of looking like five different agents built five different screens.
6. progress-tracker.md — what's done, what's in flight, what's queued. The agent reads it at the start of every unit and updates it at the end.

Then one more file — usually AGENTS.md or CLAUDE.md at the repo root — that tells every agent the same thing: read all six context files before you do anything, and update the progress tracker after each unit.

Takeaway: the six files aren't documentation for humans. They're the agent's working memory. Without them, every session restarts from zero.

What this actually changes about the work

Three concrete shifts once you run it this way.

The model stops drifting. Two different agents — or the same agent on two different days — produce coherent work, because they're both reading the same architecture file. You stop re-explaining yourself.

Hand-offs get cheap. Move the project to a different tool (Claude Code, Cursor, Codex), to a different person, to a version of yourself two months from now. The context files travel with the repo. Nothing important was trapped in the chat.

Scope creep gets visible. When the only sanctioned way to do work is "pick a unit off the tracker, do it, update the tracker," then any drift from the plan becomes a deliberate move instead of an accident. You don't wake up and find half the auth layer rewritten because the agent got curious.

Takeaway: this isn't bureaucracy. It's the cheapest way I've seen to keep multi-agent, multi-session work coherent over time.

From my own bench

I'm not preaching from the outside here. I build with AI agents in the loop on my own hardware — the Lucy-class agents I run behave very differently depending on how much structure I give them first.

When they have a skills/ directory and a clearly written behavior spec, they're calmer, take fewer wrong turns, and I can restart a session without losing the thread. When I skip that and just throw a prompt and hope, I get the drift I described above. Same agent, different result — the difference is the writing I did before it ran.

The piece I hadn't fully done myself was the progress tracker. I tend to keep state in my head and on scratch notes, which works right up until I take a break and come back. When I forced myself to put it in a file the agent updates, two things happened: the agent stopped re-doing work I'd already approved, and I stopped re-explaining context after every break. Both add up fast. That's not a theory I read — that's the thing I most recently got wrong and fixed.

Try it today

Step	What you do	Why it pays off
1. Create the context/ folder + six files	One sitting. Keep them short. Write what the project is, the rules it has to follow, and what's out of scope.	The agent gets a coherent picture of the world. You stop re-explaining yourself every session.
2. Add an AGENTS.md at the repo root	One paragraph telling every agent to read the six files and update the tracker.	Without it, the context files exist but get ignored. The pointer is what makes the system actually work.
3. Move to small, named units of work	Each task is its own line in progress-tracker.md. "Implement /api/projects POST endpoint" — not "build the projects feature."	Small units are reviewable. Big ones hide what changed.

Where people get burned

• Writing the context files once and forgetting them. Stale specs are worse than no specs, because now the agent trusts something that's wrong. Fix: treat the context folder like code — update it whenever the system's real shape changes, before you build the next thing.
• Vague success criteria. "Make it good" can't be checked. Fix: every line in project-overview.md should be testable, even informally — "users can sign up and create up to 5 projects without paying."
• Skipping the tracker because it feels redundant. It's the file that stops you and the agent from re-doing work. Fix: require every unit to start with "read tracker" and end with "update tracker." Build the habit before you trust it to scale.
• Letting agents touch architecture. Implementation is agent territory. Architecture is yours. Fix: anything that would change architecture.md needs a human edit first — then the agent implements the consequences.

Worth a look, and a question

• A tool habit: most AI coding tools (Claude Code, Cursor, Aider) automatically pick up an AGENTS.md or CLAUDE.md at the repo root. Use that as your pointer file. The cost is low and the leverage is high.
• A long watch: the full JavaScript Mastery walkthrough is overkill if you only want the method. Skim the first 20 minutes for the six-file setup, then come back to the rest once you've actually tried it. Pairs well with my last post on why shipping code you don't understand bills you later.
• A question to sit with: if a new person joined your project tomorrow, could they read six files and start contributing? If not, what's missing from the spec — and would you even know until they got stuck?

The bottom line

The fastest way to write code with AI is to not write code with AI right away. Write down what you're building, what the rules are, and what's done. Then let the agent execute against that.

The people getting durably good results aren't the ones who found the smartest model. They're the ones who treat the agent as the cheapest, fastest part of the loop — and put their own thinking upstream of it, in files that survive the session.

— Dru Edwards