Don't Let AI Write Code From the Start

In January 2026 I was still building commercial software the old way, in C++. Using Visual Studio 2022 and 2026, I wrote, built, and tested code, developing modules for Windows applications. Then everything changed in an instant. I saw that Anthropic's Claude Code could actually develop software, and that what it produced was startlingly complete. I had known AI could write code before, but through 2025 the level was low and the code quality poor, so I had assumed it still couldn't be used for commercial software.

AI filled the news, and online everyone said programmers would be the first job AI replaces. That wasn't just talk. IT companies actually began cutting or freezing developer hiring and trimming their existing headcount. The real world had started responding to the future AI would bring, and the companies closest to AI recognized it fastest and acted first. I did a lot of thinking back then too. Twenty-plus years of effort and experience in one field felt shaken to the root by this thing called AI. I even felt a kind of hollowness about my career.

I decided to face it head-on. I started experimenting with AI development using Claude, Gemini, Codex, and others. They could all produce code at roughly a proof-of-concept level. Among them, Claude's Opus model stood out noticeably. I began developing with Opus. Rather than handling every model passably, I wanted to go deep on one.

Opus was a model specialized for agentic coding. Today's AIs play their part across many fields, but in a developer's domain Opus was the strongest. I experimented with Opus and studied it. Early on, plenty of failures came out, nothing like what I intended. I figured I needed to research AI more.

I studied prompts; I used and built skills; I tried hooks; I experimented with harnesses. Prompts, skills, hooks, harnesses, they all worked. The AI agent began producing results close to what I intended. But it was 90%. Pushing the last 5% beyond that 90% was extremely hard. I even had the experience of the work regressing, where what I had built up to 90% broke while I was trying to raise it another 5%. I came to feel that turning an AI agent into a tool that produces commercial-grade code through purely technical means has its limits.

I started thinking harder about the root problem. Why can't AI do what I want it to do? Is it because AI still isn't good enough? No, AI was already excellent. It was simply that my intent and what the AI understood were different. I worked to align my intent with what the AI perceived. The conclusion I reached was that crafting a precise PRD matters most. Before, I had leaned on prompts, pouring out the features and design I wanted in fragments and assembling the program that way. That was wrong from the very start.

"Make me a Tetris game with good graphics." Starting like that was my biggest mistake. I would run the resulting program and then try to build the software through prompts like "change this part," "change that part." The belief that AI will handle most of it for you breeds exactly this kind of mistake. There is one thing you must keep in mind. AI does not understand a person's intent and produce a satisfying result on its own. Don't fool yourself into thinking AI will catch your meaning from a few exchanges, the way a colleague or a friend would. AI works only from facts that are given clearly, without ambiguity. Its autonomous judgment is just decisions made to move a step forward; it is not judgment aimed at a result the person will be happy with. So you have to describe your intent grounded in facts as much as you can. A PRD is the most basic and most fundamental stage where this problem can be solved.

Don't have AI write code from the start. You have to document the direction of design and development as much as possible before the coding stage, and use those documents as the medium through which people and AI repeatedly close the gap of misunderstanding. The more complex the software, the more complex the process before writing code becomes. You have to write the PRD and many other design documents first.

It is certainly true that AI automates a lot of work and handles it quickly. But it does not automatically deliver what the requester wants. The more AI development you do, the more you feel that how much it differs from the old way of building software is limited.

Say the old development work went requirements → design/planning/UX → WBS → development → testing → deployment. Before, people did all of this. In AI development you can get AI's help at every one of those stages, and you can move through them quickly. But here is what you have to watch out for: you cannot run that whole process to the very end in one shot with a single PRD. Thinking that AI will take care of it, that you can delegate every one of those stages to AI, can become the biggest mistake of all, producing software at the final stage that differs from your intent.

Senior developers are familiar with the traditional way of building software and have a lot of experience in it. If a senior developer with deep domain knowledge and long experience understands and uses the way AI develops software well, they can develop at the highest efficiency and speed. Even back when there was no AI, during requirements analysis and design we considered the many problems and decisions that would come up later in development, and had them reflected in the design and planning. In the era of AI development this part has become even more important than before. Design problems often can't be solved by development alone at the actual development stage; you have to fix the design. It is the same with AI development. Design matters. A problem at the design stage can't be solved perfectly by AI any more than by a person. If anything, AI can break it worse.

When you frame development with AI this way, the documents you need to prepare for the AI, and what you should check at each stage, come to mind naturally. Connect that to prompts, skills, hooks, and harnesses, and commercial software development with AI becomes possible. In the pre-AI era it was physically hard for a single architect to develop a solution all the way to the end; now it is possible. A development team that used to need ten people might now manage with one or two. A few more might be better, because a role to watch over the AI has become necessary.

With the rise of AI, I no longer worry that the world will stop needing developers. Developers who handle AI well will be needed even more. AI has no reason of its own to develop. It develops only because a developer directs it to. The future will still need a great many pieces of software, and AI does not produce that software on its own. We will need more developers who direct the development to AI, watch over it, and make the decision to ship high-quality software.