A little over a year ago, I wrote that AI had become my study buddy.

I was reading K&R and using AI to discuss the parts that were difficult, dry, or easy to misunderstand without additional context. After moving to Los Angeles, my conversations with my programming mentor became rare, so AI partially took his place. I could ask it basic questions without feeling that I was wasting anyone’s time, argue with its explanations, test its answers, and continue reading the book as a kind of conversation.

I wrote then that learning with AI was not only faster, but deeper. It may have been the first book I had ever read in dialogue with someone.

I also understood the main problem from the beginning: AI always wants to answer, including when it has no idea what it is talking about. It hallucinates, invents details, and confidently produces explanations that collapse as soon as you verify them. So I learned not to treat it as an authority. I checked its answers, ran the code, looked for confirmation, and kept responsibility for the conclusion myself.

At the time, AI was helping me learn how to write code.

Now it writes a significant part of the code with me.

I started programming by doing everything by hand: every function, every refactor, every architectural mistake, and every hour spent chasing some stupid bug. AI entered that workflow slowly. First it was a smarter search engine. Then it became a reviewer. Then someone I could discuss architecture with. Eventually it became an agent capable of opening the repository, reading the existing system, editing files, running tests, and reporting what changed.

Today I use different models and tools for different jobs. One helps me think through the product, challenge decisions, and turn an idea into a precise implementation task. Another works directly inside the codebase. I use stronger paid models when the problem genuinely requires them, cheaper or free models for routine work, and switch tools when one reaches a limit or begins producing garbage.

The model is replaceable.

The project, its architecture, its constraints, and the reasoning behind its decisions are not.

And apparently this means I’m a vibe coder now.

That still feels strange because I used to think coding was the work. The work was sitting at the keyboard and manually translating every decision into syntax. The more code I physically produced, the more it felt like I was building something.

Now I spend less time typing code and more time deciding what should exist, how it should behave, where it belongs, what it may depend on, what must remain compatible, what must never break, and whether the final implementation is actually correct.

The code still matters enormously. Architecture still matters. Tests matter. Reading the diff matters. Understanding the system matters. I am not pretending that implementation has become irrelevant simply because a model can generate it.

I have just stopped doing by hand the part that consumed most of my time and energy.

The same rule I learned while reading K&R still applies: AI is useful precisely because I do not trust it blindly. I inspect what it produces. I test it. I question its assumptions. I reject changes. I send it back into the repository. Sometimes it finds something I missed. Sometimes it confidently destroys a perfectly good design.

The difference is that the conversation has moved from individual lines in a book to entire systems.

AI was my study buddy.

Then it became my reviewer.

Then my pair programmer.

Now it can temporarily take the keyboard.

Right now, I need to build quickly and build well. So this is how it happened: I am still responsible for the product, the architecture, and the result.

But the keyboard is no longer entirely mine.