DEV Community

Hassan Aziz
Hassan Aziz

Posted on Originally published at hassandev.me

I don't care if you use AI

The short version

  • Vibe coding goes wrong when you let the AI make the decisions about what you're building and how it should work.
  • The more decisions you make yourself, the better the project turns out. The fewer you make, the more it turns into slop that nobody wants to maintain or use.
  • I designed Jumprope Tracker by using it for several weeks and having the AI fix every extra tap and slow screen I found.
  • When I built Only Hiring, the model's defaults were wrong: it guessed details that posts didn't state and flagged half of Reddit as scams until I wrote rules against both.
  • If you can build an app in a few hours, so can everyone else, so shipping fast doesn't make it worth using.

So I've seen products built by humans and built by AI. I've seen ones that go viral and ones that go bankrupt.

I'm noticing that the biggest quality that separates the winners from the slop shitters is that the former actually give a damn about the thing they're building.

Most of y'all don't care. You're shitting out slop as fast as the latest Claude can write it. You're creating useless apps that even you yourself wouldn't wanna use. Instead of building something useful for weeks or months, you'll try to vibe code one-shot something in hours or days. And somehow it doesn't cross your mind that if you can build it in hours, so can everyone else. Which makes your thing utterly useless to begin with.

Is vibe coding bad?

Vibe coding is bad when you let the AI make your decisions for you. I build my own projects with AI and let it write a lot of the code, and I don't care if you do the same.

Andrej Karpathy, who came up with the term in February 2025, described it as giving in to the vibes and forgetting "that the code even exists". He meant throwaway weekend projects, and for those, forgetting the code is fine. It goes wrong when people forget about the product as well: what it's for and how it should feel to use. Every one of those calls then gets made by a model that picks the most average answer, and you end up with the most average app.

Meanwhile folks who actually care about what they're building will take their time building the right thing, and building it the right way.

They'll write proper tests, craft the perfect UI/UX, keep the codebase clean and readable (even if it is entirely AI-generated), and build something that people genuinely wanna use instead of just sloppy clones of popular SaaS apps.

Vibe coding vs AI-assisted coding

Most articles split these two by who writes the code. With vibe coding the AI writes it and you don't read it, and with AI-assisted coding you write it and the AI helps. The split I care about is who makes the decisions.

The people who care are making more decisions about the code than any vibe coders ever will. That's another big thing I noticed. The more decisions you make yourself, the more genuine and "tasteful" the project turns out. And the less decisions you make (and let the AI make those decisions for you), the more the project turns into complete slop that nobody wants to read, maintain, or even use as an end user.

The AI wrote a lot of the code in all three of these projects of mine, and I made the decisions.

Jumprope Tracker: I designed it by using it

Jumprope Tracker is a mobile app for logging jump rope workouts. I built it for myself when I took up jump rope for cardio.

The whole UI design and the UX are my own preference. I told the AI exactly how the app should look and how it should behave, and the rules were set before it wrote anything: offline-first, no accounts, no cloud sync, no subscriptions.

Then I used it for several weeks. Every time something took a tap too many or felt slow, or a screen worked in a way that annoyed me, I had the AI fix it. I found those problems by logging my own workouts, the same way anyone else would, without opening the code. The AI can't do that part for you, because it never uses the app, so it never gets annoyed by a screen that takes a second too long.

Only Hiring: the model's defaults were wrong

Only Hiring is a job board that reads Reddit's hiring subreddits and lists only the real jobs, each with a scam score. An LLM grades every post, and most of what makes it work came from me overruling what the model does by default.

Left alone, the model fills gaps. If a post doesn't say whether the job is remote, it guesses "remote", and that guess shows up on the site as a fact someone filters by. So the prompt says any detail the post doesn't state is null, because a wrong value is much worse than a missing one. Only the job title, the summary and the role category may be inferred.

It also flagged half of Reddit as scams. It had picked up generic job-scam advice written for LinkedIn, where a client with no company name who wants you to DM them looks suspicious. On r/slavelabour that's how most hiring works. The scores only started meaning something once I gave it a list of things that are normal on Reddit and not red flags on their own, like applying by DM, no company name, no pay stated and payment in crypto.

Then there were the summaries. At one point 65% of them had the word "suit" in them, and 44% had a sentence starting "It suits...". I only noticed because I read a page of them in a row. Banning the stock phrases and re-grading every job took the summaries mentioning "suit" from 171 to 1. And every answer the model gives goes through checks in code before it's stored, because I don't trust it to stick to the format.

The design was a set of decisions too. The site uses one shape, the square bracket from the [Hiring] tag, and one typeface. It has two colours, each with one meaning: mint for what it kept and pink for what it flagged. Its README says to keep new work inside those rules.

The prompt and the scoring are in how I score Reddit job posts for scams.

Phantom Editor: the AI broke my ffmpeg commands

Phantom Editor is the set of scripts that automates my video editing and content work, and it saves me 30 to 40 hours a week. A lot of it is ffmpeg commands, and the AI has broken them more than once. I've had videos come out with the audio drifting out of sync with the picture, and with frames dropped from the video stream.

The AI fixed each of those bugs once I found them. Then I had it build review checks so I'd never have to find the same kind of bug by hand again. After every render, a script scans the finished video for black and frozen frames with ffmpeg's own detection filters, and another one listens to the audio for coughs, throat clearing, mic thumps and clicks. When a new kind of problem shows up, it gets a check, so it's caught every time after that.

Deciding that a bug should never come back is your call. The AI will fix whatever you show it and move on.

Shipping fast means nothing if nobody uses it

Honestly speed of shipping code means nothing if nobody ever wants to use that code.

If you can build it in hours, so can everyone else. Weeks of using your own app and rules you only learn from reading a page of outputs are much harder to copy in an afternoon.

AI is a tool

AI is awesome, but it's just a tool. Not a solution. The solution comes by you using the tool. The tool itself is not the solution. Stop confusing the two.

It's how I work on client projects as well: the AI writes a lot of the code, and I make the decisions. Here's how I build AI automations for small businesses.

Anyway, rant over.


Originally published on hassandev.me.

Top comments (0)