Building at AI speed without lowering the bar

I’m going to build a significant software project with AI writing all the code. I’ll decide what to build, direct the work, and review the results. I want to find out whether I can use my experience to build an exceptional system and ship it much faster than I could otherwise.

I think AI is overhyped. I also want to test what it can do under conditions that give me a reason to take the results seriously. That means working on the same project for months, keeping my standards high, and showing what happens when things go wrong.

Can I build a complex system with AI, ship it fast, and keep it from going to shit? This blog will document my attempt to answer that question.

I want to see what happens after the demo

Developers are under pressure to use AI at work, whether they believe in it or hate it. I want to read honest accounts of how that work goes. Too often, the examples that I see stop before they answer the questions that would help me judge the result.

Recently I watched a video in which the creator demonstrated a “software factory” that made changes to his website. He talked about how impressive it was, but he didn’t show the results. I couldn’t tell whether the changes worked, whether they were good, or what problems they introduced.

Generating a change quickly tells me little on its own. I want to see whether the feature behaves correctly, whether it fits the rest of the system, and whether the next change becomes harder because of it. Those are the things that I intend to show here.

How I plan to work

I have high standards for software, and I don’t expect AI to meet them without direction. If I let it make every decision, I expect the code to become difficult to understand and change. It might implement similar behavior in several different ways or keep adding exceptions instead of fixing the design that makes those exceptions necessary.

Reviewing every change before it ships could catch some of those problems, but it would also make development wait for me. I want to test whether I can let AI build quickly and intervene at specific points where my experience can make a substantial difference.

For example, I might clarify which responsibilities belong in a subsystem before AI builds it. Later, I might review that subsystem as a whole and ask AI to correct its design. I’ll need to check whether the correction worked and whether later changes preserve it. If I have to keep giving the same instruction, I need to account for that effort.

I also want to review features and subsystems asynchronously. Instead of making every release wait for me to review its individual changes, I would examine a part of the system in depth while development continues. That would let me judge whether the feature still makes sense as a whole, including decisions that no single change would prompt me to reconsider.

Some work will still need checks before it ships. Changes that could expose private information, destroy data, or cause other serious harm shouldn’t wait for a later review. I’ll need to decide where those checks belong and whether they are sufficient.

What I’ll report

I’ll write about the decisions that I make, the instructions that I give AI, and the results that I inspect. When I intervene, I want to explain what concerned me, what I asked AI to change, and whether that change solved the problem. When I miss something, I want to show what happened and what it took to fix it.

I’ll count the time that I spend explaining, reviewing, correcting, and recovering as part of development. If AI generates a feature in an hour and I spend three days getting it to work properly, it didn’t take an hour to build.

The project needs to run long enough for earlier decisions to have consequences. I want to see what happens when requirements change, features interact, and we need to replace code that once seemed reasonable. I’ll keep examining whether we’re shipping faster and whether the system still meets the standards that I started with.