I Stopped Coding With AI and Started Directing It

We've all had that moment with AI when you think: this is magic. You ask for a screen, and there it is. You ask for automated tests, and there they are. That first week feels like you just hired 3 people.

That happened to me, and it lasted months. I'd ask, the AI would write, I'd review, fix things, and ask again. I was faster than working alone. I won't pretend otherwise. Just nowhere near as fast as that first week had led me to expect, because I had to supervise it the whole time.

I wasn't really directing anyone. I was writing code alongside a very fast machine, and the slow half of that pair was still me.

When I used AI as a copilot

I used AI as a copilot. I'd talk through the code, ask for whatever came to mind next, and review what it wrote. It was fun and worked well enough. But it had a ceiling, and that ceiling was me.

Every request needed my full attention, so I could only handle one conversation at a time. If I stepped away for lunch, the work stopped too. That isn't delegation. The AI is writing the code, but I'm still driving every step.

There was another, less obvious problem. The questions that held up the work weren't about code:

• Does this contradict a decision we already made?
• Does what I'm building meet the goal we set, or just do what the request says?
• Could this change break something a teammate is building in parallel, or have a side effect nobody asked for?
• We already solved this elsewhere in the product. Why did we choose that approach?

With the context I was giving it, the AI couldn't answer any of those questions. Often, neither could I. The answer wasn't written down anywhere: someone on another team knew it, or it was buried in a chat thread nobody would find again.

So I had to track that person down, explain the situation and wait. Meanwhile, the AI was ready to work, but I had nothing for it to do.

The AI wasn't failing because it couldn't do the work. It was failing because it didn't have the context it needed.

Giving it that context took more than rewording my instructions. Writing the information down made it available to the AI, to the next person who joined the team, and to me 6 months later.

Why do we write things down before anyone starts coding?

Because writing down our decisions gives AI something to refer to before it starts coding. A decision that used to live in one person's head becomes something anyone can read: the AI, a new teammate next month, or me 6 months from now.

That sounds like paperwork. I get it. The difference is what you write and where. We use a series of short documents, each with a person responsible for it and one question to answer. Each builds on the previous one instead of repeating it.

At JobLeap, where I work, and in my personal projects, the process looks like this:

• PRD · written by the product team. Defines the whole product: what it is, who it serves, what problem it solves, and how we will measure whether it worked.
• PDD · written by the design team. The design for the product as a whole: the visual system and interaction patterns shared by every screen, so features look and behave consistently.
• FRD · written by the product team. One specific feature from the user's perspective, with acceptance criteria: the conditions it must meet to be considered done, each of which can be checked separately.
• FDD · written by the design team. How that feature looks and behaves, including empty, loading and error states. It isn't a mood board. It's a specification.
• Blueprint · written by the engineering team. The technical plan: components, the data model, how the pieces communicate, and the order in which they get built.
• Work orders · written by the engineering team. The instructions for carrying out the work: which files to change, which acceptance criteria each change meets, and how to check the result.

On their own, those 6 types of documents would be 6 opinions about the same project. They're useful because they're linked, and there's a written hierarchy that says which takes priority when 2 conflict. You can trace an acceptance criterion from the requirement, through the technical plan, to the work order that implements it.

For the AI, the difference is practical. When it opens a work order, it has the product decisions, the approved design, the data model and the criteria for checking its work. If something is missing, it can follow the references back to the source documents. It may find the answer, or discover that nobody has made that decision yet. That tells us something too.

With that context, it can make implementation decisions based on what we agreed and build what we intended. Someone still has to check that the code follows the plan.

A work order brings together the instructions and context needed to build and check one part of a product. Work orders that don't depend on each other can run in parallel.

I can then work on several orders at once. Before starting a feature, I check which orders depend on others and which can run independently. The number I can run in parallel varies by feature. Each runs in its own AI session.

Then I pause deliberately: I review the code, run the tests and check that the pieces fit together. Only then do I start the next batch. I decide where those checkpoints go. To me, that's the difference between having an AI assistant and leading a team of AI agents.

We didn't invent that process. We took it from 8090, a platform that organizes the development cycle into requirements, blueprints and work orders. We adopted the process rather than the tools. Our documents are text files in a repository, and we review them just like code: through pull requests, which let someone review a proposed change before it's merged.

Rules, comments and handoff notes

The documents say what to build. There's another question to answer: how do we want it built?

The answer is in the engineering rules the AI reads before writing any code: how to name things, what needs tests, which data to validate, what's off limits, and when to stop and ask me. In my own software factory, that's 122 criteria I established once and apply to every project. Those rules keep the code consistent across sessions, rather than making it look like 6 people wrote it without ever talking to each other.

Then there are code comments. I used to believe that good code didn't need them. I changed my mind. I don't write comments that repeat what the next line does. I explain the reasoning and the constraints: why the order matters, what breaks if someone changes a value, or which unusual case required this approach. The comment preserves that context long after the conversation ends.

Finally, there's the handoff note. When an AI session finishes a work order, it records what it built, the decisions it made, what's still pending, and what the next session needs to know. The note stays in the repository alongside the code.

A handoff note records what an AI session built, the decisions it made, and what remains to be done. It gives the next session the context to continue the work.

A repository that acts as the company's memory

All of this lives in one place. At work, we have a repository that acts as the company's memory: who we are, who we serve, how we make money, how to write each document, our engineering standards, and the decisions we've made, including the reasoning and the alternatives we ruled out.

Everyone contributes. Changes go through the same process as code: a branch, a pull request and a review. Once approved, they become the reference we work from.

That changed my day-to-day work more than I expected. I no longer had to track down the right person every time I needed an answer. If I need to know why something has a particular name, it's written down. If I need to make a product decision, the criteria are there. I can make decisions about both engineering and product because I have access to everyone's reasoning, not because I've become the smartest person in the room.

That was when AI really started to pay off. With the context already available, I could approve the work instead of explaining every request. My role shifted from writing code to reviewing it.

I use the same approach in my personal projects. This site, including the blog you're reading, has a product specification, 8 requirements documents, 20 work orders and a log of more than 120 decisions. A personal site doesn't need all that. But I wanted to direct the work, rather than write all the code myself.

AI does the heavy lifting, but someone has to sign off

You might reasonably ask: if all those documents and rules are there to guide the AI, why does someone still need to review the result?

Because documents and rules guide its decisions. A review checks whether the code actually follows them.

A written plan gives AI the context to understand what to build, how to build it and why. We still need to review the code to check that it follows the plan.

Even with that context, I've seen errors for 2 reasons:

• Something we didn't document. An edge case, the kind of unusual situation nobody thinks of while writing acceptance criteria. The AI has nothing to refer to, so it makes its own decision, quickly.
• Something we documented but lost along the way. As a task goes on, the model can lose track of what it read at the beginning. The plan is still there, but the AI is no longer referring to it.

The second problem came up while I was working on a feature at work. We'd written and approved the plan before starting, but the AI still built the opposite of what it called for, passing tests and all. I threw the work away, and we went back to planning. I told the full story in my post about when to throw out AI-written code.

A review can catch an undocumented case or code that contradicts a written decision. That's why the process has checkpoints where work stops until a person approves it. Those checkpoints aren't negotiable.

The product team approves the FRD and design before coding starts. An engineer reviews the full blueprint: the data model, acceptance criteria, architecture and choice of libraries. A person always approves the release to production.

Someone caught that error in an afternoon by comparing the code with the plan. That gave us time to go back to planning before the work reached production.

If you're still using AI as a copilot, writing code together and checking its work as you go, you're not doing it wrong. I spent a long time working that way and learned a lot. But you may eventually hit the same ceiling I did. For me, getting past it took more than better instructions. I had to write down the context I'd been carrying around in my head.

Thanks for reading this far. 🙂