Principal Dev’s Take On Vibe-Coding

DISCLAIMER: No AI was used in creating this article…for better or worse.

Vibe-coding in the CS community is highly controversial so I wanted to provide a very biased view of vibe-coding based on my anecdotal experiences.

The thing is, vibe-coding is so new and still developing so much that anecdotal experience is the best that we can get. The unfortunate thing is that Twitter, Blue Sky, and other social media is filled with misinformation, covert advertising, and rage-bait and it’s to the point that you can’t trust anyone with their view on vibe coding.

I’ve seen people I trust in the dev community retweet devs that say vibe-coding works and claim that this is a lie. It’s not. It can work and I’ve seen it. I’ve seen people I trust in the dev community retweet devs that say vibe-coding sucks and claim that this is a lie and vibe-coding is the god-sent tool we need. It’s not. It can work. It can’t do everything and it’s definitely not plug ‘n play.

The field is also evolving so quickly that opinions from yesterday hardly matter today. It means that even what I’m writing right now may not be true tomorrow. The kicker is that my own opinion on vibe-coding switched so many times this year that any opinions basically became fleeting thoughts more than anything.

With this article, I want to impart a few things on you:

  1. My personal “golden age” of vibe coding
  2. My personal “hell age” of vibe coding
  3. and what companies and other people seem to be doing
  4. just my own opinions overall

For the purposes of this article, I’ll mostly be referring to using Claude code as that’s been the most helpful tool overall for me. Wish Claude would give me some cash for mentioning them but alas, I’m writing this for the good of my soul (I guess).

The Good – When it works and why it works

First, I’ll tell you a fantastical tale. Such a fantastical tale that you may not believe it’s true because I’ll sound just like any other vibe coding grifter.

Earlier this year, I was responsible for setting up Claude/Agents md files and generally “vibe-coding” stuff for our entire company. I got this responsibility because we had a very stern all-hands meeting one day where our leadership made it clear that if you don’t use AI, you’re out. With the job market being what it is, I went all out to keep my job and then became our main top-dog AI coding developer at my job.

So here’s a real-life scenario of what vibe-coding was able to accomplish and how my work went:

  1. Grab a task from the backlog
  2. Ask claude-code to fetch all data about it
  3. Ask claude-code to read my bespoke markdown prompt for “working on tasks” and do the task
  4. Put Claude into YOLO mode (accept all changes) and wait
  5. review the output code for issues
  6. push code to Github for code review

Not even joking. The system was so well setup that I could grab a random task, ask Claude to do it, and it’d do it perfectly on most first tries. THIS was the dream. THIS is what vibe-coding should have been. Task in -> clean code out.

And it worked for a while. I’d say that most of Q1 and Q2 of 2025, I could write a solid task/ticket and get a very good result (with tests and everything). I thought the grifters may be onto something back then.

But then that changed. Claude released a couple of new models, anddddd everything went to shit after that. The old model somehow worked worse than ever before and the new models would switch from working really well to not being able to make the simplest changes.

How did it work?

Vibe-coding requires a good writer. Sounds kind of weird but it’s true. What improved my results for development using claude-code was writing a lot. I wrote a lot of documentation by hand (claude-code-generated docs were trash), I wrote a lot of prompts. I tested those prompts constantly until I found a great balance.

Then? Then I wrote really good tasks/tickets. I made sure to write in a way that the LLM could understand especially with the context of documentation. I also wrote a lot of good code by hand.

See, the thing is, vibe coding works really well with:

  1. well-documented codebases that are clear on architecture, on how to add new features, code style, conventions, etc.
  2. clean codebases with simple straightforward patterns that the LLM could understand
  3. lots of well-named and organized tests for the LLM rely on
  4. clear LLM docs (like CLAUDE.md or AGENTS.md) for the LLM to understand its job

If you take a developer-first approach where you focus on getting the most junior developer up to speed with the codebase, claude-code works phenomenally. For that, you need good developers that can create that environment.

Think of good developers as the parents of claude-code. They need to create a positive learning environment, teach it, update instructions if it gets confused, and so on. But that’s the thing no management/CEO/company wants to hear. To get the benefits of vibe-coding, you NEED good developers first. You can’t get rid of them as the first step.

What else can it do?

You see, after all of my accomplishments with coding, I decided to see what else claude-code can do:

  • AI can do code reviews. I tried the Github copilot at first and it worked ok. Then I created my own prompts for local reviews and they worked so well
  • Research. I used Claude-code to research architectural patterns, languages, database designs, etc. and had it spit out a summary, comparisons, and most importantly — original sources for its data
  • AI can write architectural docs — and review them. I used AI to take some of my ideas for a project and turn it into full architectural docs that could be read and understood by any engineer
  • AI can write mermaid graphs which is super cool and hella helpful
    ## The Bad – AI is hell on Earth

So imagine my situation where I KNOW this can work. Where I know that AI can do a ton of my work — sometimes a whole week of work in just a couple of hours. All it needed was a guiding hand of a developer.

Then came an update to Claude-code. And then the other shoe dropped. You see, the update came, everything was setup the same way as before but the performance wasn’t there. Suddenly, my best buddy in my terminal couldn’t write a single test correctly. It couldn’t review my code. It couldn’t do research. It couldn’t figure anything out.

Prompt updates and my usual process didn’t work to improve the situation. I read a bunch of unhelpful twitter/linkedin posts for ideas. I asked friends in the industry what they’re doing (and the consensus with them was that nothing worked). And yeah, nothing helped.

Depending on the day, I’d have claude-code be a huge time suck to the point of starting over. And sometimes, its old abilities (from early 2025) would shine again…but only briefly.

Imagine this situation and then seeing claude-code get hung up in weird loops where it just runs up my credit usage. Or having claude-code use websites in its search that were irrelevant. It went from having a Senior developer buddy to having a protege who, seemingly, hasn’t written a line of code in their life.

And it got worse

So here I am, with months of prompts and work to get claude-code to be the ultimate tool be completely wasted. And by the way, that productivity hasn’t returned as of writing this article.

I switched between multiple codebases and things got worse and worse:

  1. one codebase was so incomprehensible to claude-code that it literally would stop execution and tell me that things just weren’t looking great and it tried to convince me to write the solution myself.
  2. one codebase was well-laid-out but claude-code had other ideas and started to ignore its prompts and built a huge mess. Imagine my surprise where I had to argue with claude code and claude code insisted it was right. No joke, I asked it to just do it if it thinks it’s right…and then it failed and apologized. I’m not kidding.
  3. one codebase was started by claude-code from scratch and it was so bad that I had to manually rewrite it. Claude code couldn’t even answer basic questions about its own code.

The tool has gotten so bad that I only use it as a “thought unblocker”. Like when I’m blocked on something so I ask claude to implement it just to hit a git reset --hard and write my own solution. Sometimes, getting that first line of code down for a complex problem can be hard. When claude-code would implement its own mess, I’d automatically start seeing all of the issue in its code and that would help me write my own code.

So what now?

These days, I still use claude-code for the “thought unblocker” usecase but my usage went from daily/hourly down to loading it up once a week or so. It’s just not that good.

And before you ask, I tried everything else — Codex, Gemini CLI, Cursor, VS Code with Copilot, etc. Claude-code is still the best one out there and that’s saying a lot. Gemini, despite its amazing specs, is so useless that I’d recommend against using it even for the “thought unblocker” idea.

The culture around it

The most surprising part about vibe-coding is the culture around it. As someone who’s been responsible for setting up AI dev workflows at multiple companies now, I’ve experienced a really interesting phenomena.

Vibe coders….seem to hate coding.

I’ve worked with several dozen vibe-coders and the consensus seems to be that the main reason they use these tools is to get away from coding.

I still vividly remember talking to a colleague about vibe-coding and he was flabbergasted that engineers actually enjoyed coding. Every vibecoder has given me the same answer — that they don’t want to deal with coding. It’s a nuissance. They want to “create” but they want to do so without writing any code at all. And then came the disbelief that anyone out there actually likes coding.

I like coding. It’s my favorite part of my job. I like organizing things, I like architecting solutions, and I like to write code that the next developer who has to work on it can look at and say “Oh ok, I see what’s going on” and they can extend my work. I love that collaboration.

But from CTOs, to management, to coders with heavy-duty experience coding, they fucking hate it. And they don’t understand why someone would like it.

Adoption

How does an engineer that likes coding reconcile the fact that AI is pushed everywhere and it takes away the best part of their job? And I’m not just talking about me. I’ve had to have this conversation a bunch of times at different companies.

You don’t really. You just keep pushing.

At one company, managers would check token usage each week and talk to developers who didn’t use AI enough. Didn’t matter how many tasks they did. Didn’t matter what their velocity was, their performance, how their colleagues saw them, etc. What mattered was that they didn’t burn through enough tokens. And at one company, this became part of annual performance reviews — are you using enough tokens? If not, why not?

At another company, it was suggested that if devs don’t meet some minimum (like using AI at least 2-3 times a week), that dev should be fired.

Adoption became a task of forcing people to use a tool they didn’t understand, a tool that didn’t work well, and a tool that took away what people liked doing. And as you know, AI has its own issues but the decline in code quality didn’t bother any vibecoder or their managers.

Is it productive though?

From my personal experience, vibecoding can get a task done quickly (and poorly) which leaves more time for more inefficient processes. Like yes, in some situations it was able to do one week of work in a day. In most situations (even when AI worked well), I would have been able to get the task done faster if I just had more uninterrupted focus time in my day.

One huge blow to my productivity with AI has been non-coders using AI. From product managers to CEOs, they’re all happy to:

  1. build a prototype in 4x the time it would take you with no usable code where a short doc would have been better
  2. have ChatGPT/Gemini generate a 30-page PRD for devs to read through
  3. have ChatGPT/Gemini do “research” on technology only to recommend something that doesn’t work at all
  4. have ChatGPT “review” a codebase and write a 40-page paper on how it could be improved. Except it’s wrong from the first sentence onward.

These aren’t exaggerations by the way. These are real-life situations that continue happening to this day.

Dealing with happy-go-lucky managers with AI access has been a nightmare. They don’t even read their own work. They’ll ask ChatGPT to summarize their own output and give them wrong answers.

The second huge blow has been the increase in inefficient processes since “AI can do all of the coding”. Suddenly, your day is filled up with meetings where participants share links to their own AI-generated papers that no one will read. Suddenly, your day is filled up with Teams/slack messages because no one understands the product — because no one can understand the generated documentation and no one is bothering to learn.

Suddenly, your protected focus time to do deep work is exposed to everyone. After all, it’s the AI coding, not you. So why should you get any time to focus building the product you were hired to build?

The blame

Lastly, the biggest blow to my productivity has been blame. If you’re not finishing tickets fast enough, it means you’re not using AI enough amidst rising demands. If the work is taking the AI too long, that means you’re not using AI well. If you push back around issues, you get asked why you didn’t use AI to figure it out. But, what if AI can’t figure it out? You’re using it wrong. Use another AI tool.

It’s honestly a cesspool. It’s become a tool of abuse in the workplace. An excuse to fire people. An excuse to burn people out. And an excuse for people to do shitty work.

Tools

Let’s talk tools real quick. Someone will bring this up. So here’s my quick overview of the major tools out there:

  1. Codex isn’t ready at all. It will make mistakes from the first steps. It’s not production ready. And I’m not sure when it will be. It misunderstands tasks, writes bad code, and, just overall, it’s useless.
  2. Gemini CLI. Better than Codex but Gemini likes to hallucinate. Sometimes it’ll hallucinate entire files existing but won’t build them. I’ve also noticed that Gemini will say it did something when it didn’t. eg. “I checked file XYZ, and didn’t see the method you were referring to” but I’ll notice that Gemini never read the file, or that the file never existed in the first place.
  3. Claude-Code. The best in the industry so far. It takes hard work but it can be a helpful tool.
  4. VSCode Copilot (with any model — including Claude). Don’t even touch it. Sure, it’ll work for a bit and write some good code occasionally but more likely than not, it’ll misunderstand your directions, your codebase, and fail its task
  5. Cursor. Almost on par with claude-code but not as powerful. I’d say this is the only true competitor to claude-code despite being a full editor.
  6. using any model without code integration. ChatGPT/Gemini/etc. are actually not bad to talk to about architecture but then you need to apply your own thinking. I’d never copy/paste code from it though.
    ## My personal view on all of this

I told you the good and the bad. So how do I see these tools holistically?

What you need

In order for claude-code to work well, you need to have good developers using it and a codebase setup for it:

  1. make sure you have a clean codebase with easy-to-follow patterns, use most popular coding conventions
  2. create in-depth documentation on architecture, testing, conventions, etc. and make sure to ask Claude-code to read it when working
  3. create prompts to map against the work you want done. I just create md files to “create a test” or “implement a feature” or “extend a feature”. This is super helpful
  4. make sure to have robust code reviews
    1. this means self-reviewing code
    2. having other devs review your code in-depth
    3. using AI to review your code as well (on top of the other steps)
  5. iterate on the AI setup
    1. tweak your prompts frequently to avoid mistakes or push the AI toward a better path
    2. tweak your own workflow with the AI depending on what it can do

What you get

Depending on the codebase, you may get a Principal Engineer in your terminal or a Junior Developer. That’s just the toss up that you can’t avoid. Especially when tools and underlying models change. You can’t rely on your workflow forever.

But what you can get is quite a bit. You can get any, all, or some of the following:

  • a smarter Google search for code-related questions
  • rubber-ducking buddy
  • a helpful pairing developer who may not be the best but helps out
  • a robust developer that can take your job
  • a code researcher that can explain codebases and issues
  • a code reviewer friend

Depending on the day, you’ll get different results. Even depending on the hour. Sometimes you get the genius, sometimes not.

In the end, claude-code (and similar tools) are tools. They aren’t self-contained. Claude-code agents aren’t your reports. They’re a bunch of toddlers running around. Hopefully, you child-proofed your codebase enough that the toddlers eventually get their task done.

These tools also require time investment. They’re not plug-and-play.

Leave a Reply