Vibe or Agentic coding, I do neither!

Intro

If you’re here, I guess you’ve already done some “vibe coding.” And if you’re a developer, you’ve probably done some spec-driven or agentic coding too. To be honest, I tried both, and I hate them both. Maybe I still don’t know how to do it properly. So I came up with my own setup, especially for my own projects, which haven’t grown past a certain point yet. Let me explain.

Why I hate it

I hate it all. I hate reviewing plans. I hate reviewing them twice. I hate reviewing specs, especially several times. Why should I even have to come up with a plan first, and then specs? I hate letting AI work for hours and only then seeing the result. I also don’t like reviewing code. Well, I like reviewing well-written code that teaches me something, but I hate big PR reviews. I hate spending hours understanding them, and then, when I propose changes, doing it all over again. This is the usual agentic coding cycle. I tried it as well, but in the end I wasn’t happy with it.

The problem is that I got lost and tired after a few rounds. Unlike LLMs, we humans have limited context. We get tired, and we get decision fatigue. And yet we sit in front of a laptop, open Claude, and think we’ll do a brainstorming session, answer some questions, and then relax and watch it do the job. That’s not how it works. Not yet.

Where agentic coding does work

I think agentic coding can be useful in big projects and codebases. With a good AGENTS.md file and a mix of skills, you can build a pretty good agentic setup that you barely need to review deeply. Established projects have enough standards in place to keep the agent from drifting. Often the agent just needs to copy some code from one place to another, keep the existing style, or clean things up. You don’t expect optimization there; you expect the same quality, because the project’s standards already guard it. With a proper test setup, some of that doesn’t need review at all.

A fresh project is different

On a fresh project, it’s a waste of time to set up all those boundaries when things aren’t even clear to you yet. Say you’re working on a side project or a startup idea: the point is to keep things as simple as possible at the beginning. And you don’t want to get lost from day one. You want to sit in the middle of each step and know what’s going to be done before it’s too late.

So for a new project, you have roughly three options:

Pure vibe coding

I’m pretty sure you can’t build a scalable project with pure vibe coding, so I’ll pass on that. Even Karpathy, who coined the term, hand-wrote his own nanochat project.

Agentic coding

Agentic coding can be good, but I didn’t find it useful for new projects. You have to act like a PO: read a lot of plans and specs, re-read them, and in the end the code might still do some shady stuff that you need to review. It’s too much, and you lose track somewhere in the middle. You think you’re fast, but you aren’t.

Assistant coding: how I do it

When you’re starting fresh, you want your setup to evolve with the project, because each project has its own needs. You’ll probably bring some things in at the beginning, but you have to keep maintaining them as the project grows.

So I said, OK: I want to sit in the middle. I want to review or write each piece of code before it goes into my codebase, not after. This way I’m more in control, and I don’t need to review anything afterwards, because it has already been reviewed.

The first line of my AGENTS.md file is “Do not write any code until I say so.” Both parts matter: I do want it to write some code, just not all of it. The rest of the file has similar rules. The point is to take steps as small as possible. That makes me slower, but I understand and learn every step; I know the code by heart, and I can change anything I want without asking my agent to do it.

The most important part is your business logic. That’s what you want to understand, review, or even write yourself. In my opinion, the frontend can be written by an agent, but ask it to keep things as simple as possible so it stays maintainable by humans.

Besides that, I use my agent for investigation, brainstorming, research, explaining, and teaching, which saves a lot of time.

I only code when I’m sitting at my desk, and I’m productive for 4–5 hours a day at most.

The goal is to minimize your waiting time in each session. You can do that by keeping tasks and steps as small as possible and always taking care of your agent’s context window.

After a while, you can delegate more tasks to your agent, but still review everything before each commit. Ask it to do as little as possible in each round, and commit as soon as a task is done, so you always review a fresh diff.

My setup

• Ponytail is a good skill to keep your code simple, and it saves you some tokens.

Some tips

• If you’re using Claude Code, use /btw for side questions mid-session, so your agent doesn’t drift off its current task.
• I mostly use Opus 5.5 on medium effort, and it does a pretty good job.
• Watch your context. Start a new chat once around 15–20% of the context window is filled. If you need to keep some context, use a handoff, or ask the agent to write one for you.
• Use abbreviations like NS (next step), FR (final review), and DI (do it) to save some time.

Conclusion

On a fresh project, agentic coding and vibe coding make you slow, and you don’t learn anything. Try assistant coding instead.