The Fastest Way to Lose the Plot

One of the strangest experiences I’ve had with AI was building something I genuinely wanted to make for my kids. I let the LLM make most of the early decisions, and by the time the application worked, I barely felt like I had built it. Even for simple tasks, I had no motivation to really dig through what was generated. I just asked AI to make the updates for me.

I wanted to give my kids a safer way to watch media on the Internet. I wanted more control over the influences that reached them, but I also wanted it to feel creative and alive. Part of the point was that it could grow into something more playful, such as little games and experiments, built with my kids in mind rather than for a market.

We often had “meetings” in the car where they would pitch me ideas and game mechanics they thought were fun. This should have been the most personal project I’ve ever worked on, and yet I ended up feeling detached from it.

Now it is just sort of in maintenance mode. When my kids want something on it, I open up my coding agent and prompt it into existence. It wasn’t great quality and sometimes took a bit of prompting but it satisfied the need.

Prompting the whole project is the fastest way I know to lose the plot with any project. You can get to something functional before you ever get to something that feels like yours. The trade-off isn’t worth it. Building projects was never about speed. I like taking my time thinking through things, especially for side projects where all the work I’m doing is for myself. In our day-to-day, we already do enough coding to match someone else’s expectations and timeline. I want my own projects to be where my judgment, taste, and curiosity actually get to be free.

What I Actually Mean by “Vibe Coding”

When I say “vibe coding,” I do not mean “using AI at all.” I mean the version where you start with so little of your own shape in mind that the model ends up making the first important decisions for you. You give the model a vague prompt, it gives you back structure and momentum and a pile of decisions, and then you inherit an architecture you did not really choose.

The problem is not that the code was generated. The problem is that the learning got skipped. I mean the trade-offs, the data shapes, the small decisions that teach you how a project wants to be built. These are the very things I do not want to outsource on a side project. AI can be a productivity boost without doing all the thinking and work for you. AI gives us all an infinitely patient and knowledgeable tutor we can ask for help on any topic. It can pull together research, documentation, and examples for you. I often use it to generate my own personalized tutorials and use AI as a real time tutor.

Here is what it looks like in practice.

If I say:

“Build me a small application for managing videos with parental controls”

I’ll get something back that might work in some ways. I might need to prompt and finesse with a few prompts.

However, I inherited all of the structure, the naming, the trade-offs. It’s the same feeling as joining a company and inheriting their legacy code base. Who wants that in a side project?

Side projects are not just where I ship little things. They are where I practice my skills and learn new ones. They are where I remember how I like to build software. They are where my curiosity gets to matter more than throughput. It’s the same feeling as taking a leisurely stroll through the park to enjoy the scenery versus sprinting through the park to get your heart rate up. They are two very separate things.

The truth is that after spending all day programming for someone else’s priorities, I do not want my own projects to feel the same way. I want the leisure stroll where, if I want to stop and smell the flowers and enjoy the moment, I can. Let me refactor my own code to my heart’s content, try new patterns or just simply decide I’m not going to write tests for any of it.

On a side project, the thinking is part of the reward. The point is not only to end up with something useful, but to spend time inside the decisions that feel like mine. A lot of my side projects do not have a primary objective. It is whatever my brain thinks would be fun to build, fun to explore, or just fun to learn about. No pressure. No process. Vibe coding robs you of this.

What I Want Instead

There are a few simple rules I like to follow when it comes to using AI in my projects.

Rule 1: Hand first, AI second

Instead of AI having the first turn, take your turn first. The game is yours to play, so why give it up? Try to sketch or write something yourself even if it is rough. Own the “Bird By Bird” methodology and don’t be scared of “the shitty first draft” of your code. After that draft, use AI to tighten, refactor, or generate tests. With this method, the thinking reps (architecture, data shapes, control flow) remain yours.

Rule 2: Scope the ask

Keep prompts small and concrete. Maybe you only ask about one function, one refactor, or one test at a time. If the request would overwhelm a junior developer with context, you’re probably asking too much for a single AI call. Lead your side project and give a tighter ask to your AI as you would lead any other junior developer.

Rule 3: Own every line

Take the time and care to read and edit AI-generated code. Nothing ships without passing through your tastes. If you can’t explain what is happening, then AI has done too much. Grow a relationship with what you’re building. Don’t let the journey pass you by.

Rule 4: Prefer refactor over generate.

Instead of asking for AI to generate greenfield features, ask AI for refactors, scaffolding, and explanations. If you want to improve your own refactoring skills, ask AI for suggestions on how things could be better. Make your own judgment using your taste and knowledge to accept or reject AI ideas.

The First Time the Balance Felt Right

The first time this balance really clicked for me was not with a greenfield AI-generated app. It was while I was building something I already understood and then letting AI assist inside the boundaries I had already chosen.

99.nvim was one of the first tools that made this balance feel practical to me. It is a Neovim plugin that lets me send a small, deliberate slice of code to the AI instead of handing over the whole project. In practice, that usually means selecting one single function and asking for something specific: refactor this, explain this branch of code, make it use this function signature, etc. What matters to me is the boundary. I choose the context, I review the response, and I decide what stays.

Small Context, High Control

The reason tools like 99.nvim interested me was not because I wanted AI to take over my editor. It was almost the opposite. I wanted a way to ask for help without surrendering the shape of the work.

Small context helps. Deliberate asks help. Being able to cancel, review, reject, and reshape the answer helps. The smaller and clearer the request, the easier it is for me to stay in relationship with the code instead of drifting into passive approval mode.

That principle matters more to me than any one tool. I do not actually think this chapter is about Neovim. I think it is about preserving enough control that the work still feels legible and alive.

The Rules I Keep Coming Back To

Hand First, AI Second

If I can, I want to touch the problem myself before I ask for help. Even a rough first pass teaches me more than starting from a complete answer I did not arrive at.

Scope the Ask

I try to keep the asks small enough that I can still hold the whole thing in my head. One function. One refactor. One test. One explanation. Not “build the feature for me” and definitely not “decide what this project should be.”

Own Every Line

If I cannot explain what the AI wrote in my own words, then it is already too much. At that point I am not really collaborating. I am just inheriting.

Prefer Refactor Over Generate

I trust AI most when it is tightening something I already understand. Refactor this. Explain this. Suggest tests for this. Help me see a cleaner shape in code that is already mine.

This Is Not Just About Neovim

The specific tools do not matter as much as the stance. This applies whether you are using Copilot, Claude Code, Cursor, JetBrains AI, or something else entirely.

The tool is not the point. The relationship is the point. Are you still thinking? Are you still choosing? Are you still practicing, or are you mostly reviewing somebody else’s momentum?

The Fair Counterargument

There is a fair counterargument here, and it is not a weak one. Letting AI do more can absolutely get you to a demo faster.

But speed is not the only thing I want from a side project. I also want reps. I want taste. I want the practice of debugging my own decisions. If AI takes all of that, I may ship faster while learning less, and for me that is too expensive a trade.

What AI Has Actually Been Good For in My Life

AI has genuinely helped me on low-energy days. It has helped me get past boilerplate, setup friction, and the activation energy that can keep a side project closed for a week longer than it needs to be.

That matters. I do not want to pretend that every meaningful line of code has to be typed by hand to count. I just want help that keeps me moving without quietly replacing the parts that teach me how to build.

The Kind of Companion I Want

The kind of AI companion I want is one that keeps me in motion without taking the steering wheel. I want help, not replacement. I want acceleration, not authorship by proxy.

If I had to reduce this chapter to one practice, it would be this: start one small part by hand, then ask AI to help inside boundaries you can still fully understand. That is where the tool becomes useful to me. That is where it still feels like learning.