vibe coding: the tiktok of programming

well, shit happened. let me tell you about something that occurred recently that made me realize we might have a problem with this whole vibe coding trend.

vibe coding concept illustration

photo by bernd 📷 dittrich on unsplash

the refactoring nightmare that spawned this post

this whole post originated from my experience during the past two weeks. i had to refactor my react application, and i thought using large language models would make it faster. it did - way faster. what i expected would take a month took just two weeks. and i didn’t just refactor - i ended up changing the design, reworking all the imports, and switching to provider-based components instead of just using hooks directly in components.

everything seemed amazing. the app looked better, the code structure was cleaner, and i was feeling like a productivity god. i was ready to write another post about my quick deployment strategies after this fantastic refactoring experience.

then i actually tried using the app.

turns out, every time i tried to open a dialog with a form (like creating or editing an instructor), the entire page completely froze. and the worst part? i kind of knew something was wrong earlier but ignored it. i had noticed weird behavior during testing but dismissed it as issues with the development server.

why did i ignore these warning signs? that sweet, sweet dopamine rush.

vibe coding: the tiktok algorithm for developers

vibe coding has become exactly like using tiktok. i’m not exaggerating - the psychological mechanism is identical.

think about how tiktok works. the algorithm doesn’t show you dopamine-triggering content every single time. sometimes it’s once in 4 videos. sometimes it’s 2 great videos in a row. sometimes you have to swipe through 10 boring ones before hitting something that gives you that rush.

and that uncertainty - not knowing exactly when the next dopamine hit is coming - is precisely what makes it so addictive. it’s not the content itself; it’s the anticipation.

the same thing happens with claude, gpt-4, or deepseek. sometimes they spit out perfect code on the first try. sometimes they need three attempts. sometimes they give you something brilliant that makes you think “holy shit, this is better than what i would have written.”

the danger of coding on autopilot

when i was refactoring my app, i started out carefully checking what claude generated. the first few files, i reviewed line by line, made adjustments, and really understood what was happening.

but as i got deeper into the process, that changed:

  1. first file: careful review, understand everything
  2. second file: quick scan, looks mostly good
  3. fifth file: barely glancing, copy-paste
  4. by file #20: completely on autopilot, not even reading

i didn’t want to stop this dopamine rush of changing 200 files in a sitting. who cares if i don’t fully understand what’s happening? the large language model knows what it’s doing, right?

wrong. so fucking wrong.

when everything looks nice but nothing works

the worst part about my broken app was that visually, everything looked perfect. the design was improved, the structure was cleaner, it loaded fine - it just didn’t actually function. it looked nice but was completely broken.

and i couldn’t easily go back because there were so many interrelated changes. i had no clear rollback path.

so i tried to debug with the help of language models again. i asked claude what was wrong. it suggested three different points that were “surely responsible” for the infinite recursion error i was seeing. i implemented its suggestions. nothing worked.

frustrated, i switched to chatgpt. it “thought” for 20 seconds and gave me a completely useless answer. then i tried deepseek with its thinking mode enabled. after waiting 25 minutes, the connection timed out without any response.

the google solution vs. the vibe illusion

finally, in desperation, i did what i should have done from the start: i googled the specific error along with the components i was using: “recursing error shadcn dialog form components.”

the very first result was a github issue for the shadcn components describing exactly my problem. reading through the thread, i found someone who had fixed it by simply updating their dependencies, deleting node_modules, and reinstalling everything.

i tried it. it worked instantly.

all that time spent with large language models suggesting complex state management solutions, when the actual fix was a simple dependency update. claude was telling me i needed to completely restructure my component state management when all i needed was “npm install” with updated versions.

what’s really happening to our brains

the scary thing is how vibe coding is rewiring our development approach. we’re becoming less like engineers and more like product managers who just describe what we want and let the language models build it.

this is fundamentally changing what coding is. the most valuable part of programming isn’t typing code - it’s thinking through problems, understanding systems, and finding elegant solutions. when we outsource that thinking to claude or gpt-4, what exactly are we doing? copy-pasting without understanding?

it’s a dangerous trap because:

  1. the dopamine cycle makes us want to keep vibe coding even when it’s not helping
  2. we stop developing our own problem-solving skills
  3. when things break, we don’t have the deep understanding needed to fix them
  4. we become dependent on tools that aren’t always reliable

finding a balance

i’m not saying large language models are useless for coding. they can be incredibly helpful for certain tasks. but we need to approach them differently:

  1. use them to help brainstorm approaches, not to write entire features
  2. never copy-paste without understanding every line
  3. test frequently, don’t wait until you’ve changed 200 files
  4. remember that google and direct problem-solving are still powerful tools
  5. recognize when you’re in the dopamine loop and break out of it

the hard truth

coding is thinking. it’s problem-solving. it’s understanding systems.

if we’re just copy-pasting language model output without understanding it, we’re not really coding anymore - we’re just operating a fancy text generator. and when things break (which they will), we won’t have the skills to fix them.

i learned this lesson the hard way. maybe you can learn from my mistake instead of making your own.

the next time you feel that rush from rapidly generating code with claude or gpt-4, ask yourself: do i understand what’s happening here? or am i just chasing the next dopamine hit?

because that’s exactly what they’re designed to deliver - just like tiktok.

krtffl.dev

physicist → chemist → dev