I sat down to build one feature.
I had a clear idea of what I wanted, and the AI agent had enough context to start. This was supposed to be a coding blitz, the kind of focused session where I could make a meaningful change in a day.
Then the agent came back with a familiar message.
“Oh, hey, by the way, I noticed this was a problem. You should probably know about it.”
It sounded useful. The agent was already looking at the code. I was already there. The current chat held the context, and I was not sure I could reproduce that exact situation later.
So I told it to fix the other problem too.
That problem turned out to be larger than it looked. While the AI worked on it, I kept working on the feature I had planned. One issue became several. Each answer changed something else.
Before I knew it, 12 hours had passed.
We had done a lot of work. We had also worked without a plan. I could barely remember what I had intended to build when the day started.
Some coding blitzes ended well. I walked away surprised by how much we had finished. Other days, I felt as if I had made the software worse. We had made decisions as we found problems, without stopping to decide how the product should work.
That uncertainty was worse than moving slowly.
Ninety percent of the code is not ninety percent done
An AI agent can make a product look close to finished very quickly.
The interface loads. The buttons work. A happy-path test passes. It feels as if the software is ninety percent done.
Programmers know how misleading that number can be.
The final part includes the work that makes the product safe to trust. Real users need to sign up. Forms need to save. Permissions need to hold. Subscriptions need to stay enforced. Errors need to leave enough evidence for somebody to understand what happened.
Every change can touch something you did not expect.
After enough surprises, you start to fear your own software. You can see that it works, but you do not know what is happening inside it. You are waiting for a customer to discover the problem you missed.
The AI remembers the chat. You remember the product.
An AI agent knows what sits in its current context. It does not remember yesterday unless you give that information back to it. It may forget a decision, repeat an old mistake, or contradict the answer it gave you the day before.
That forces you to remember more.
You become the person who holds the intent, the decisions, the exceptions, and the reasons behind them. The AI understands the code it just wrote. You understand what the product was supposed to do. Each side holds part of the story.
That is a familiar problem in software teams. When one programmer holds all the knowledge, the whole team depends on that person. The industry has spent decades building ways to share the load: small changes, written decisions, code review, tests, and clear handoffs.
AI lets one founder create the same problem much faster.
The moment you delegate part of the build to an agent, you are running a team of two. Speed does not remove the need to share context. It makes that work more important.
I did not want the old process back
I tried using the usual development process without changing it.
I wrote more documentation. I broke the work into smaller pieces. I used GitHub more carefully. I made smaller commits and reviewed more code.
It worked, but it was slow. The AI had taken the fun parts of coding and left me with the management. Work that I could finish in a day started taking weeks again.
I wanted the speed without the 12-hour chat.
The first change was to move the useful context somewhere durable. I stopped treating the chat as the place where the project lived. A chat could end without taking the product decisions with it.
The second change was to give each conversation one job.
Sometimes the job is discovery. The agent helps me understand the problem before we discuss a solution.
Sometimes the job is architecture. We decide how the parts should fit before the agent writes the full implementation.
Sometimes the job is execution. The decisions already exist, the boundaries are clear, and the agent can finish one defined piece of work without me steering every step.
I also built a shared language for discussing the system. Instead of arguing about individual lines of code, the agent can explain the design in patterns I understand. I can question an architectural choice before it becomes a large pile of code.
That is the part that changed my work.
I still show up for the decisions. I do not have to stay for every line the agent writes.
My chats are shorter. I hit usage limits less often. Smaller tasks can run on less expensive models. I can return weeks later without hoping I remember why the system looks the way it does.
Most important, I can trust what we built because I know how to check it.
The course I wanted when this started
I built Vibe Coding Products for Scrappy Founders to teach this process.
It covers discovery, architecture, task planning, GitHub, testing, review, safe release, and the point where a proof of concept needs a clean rebuild instead of another patch.
The course includes eight recorded lessons and downloadable guides written for your AI to read. I am keeping the founding group to 20 people, and each founding buyer gets a 30-minute product call with me.
The founding price is $299. The course opens November 2, and founding buyers get the lessons as I finish them.
If your AI can only keep moving while you sit there remembering everything for it, this course is for you.