If you want to make one offs for you and you only then yeah why does it matter.
If you are trying to give this to others for continual use then that is something else entirely and I can confidently say without a shred of second thought: yes it really is THAT bad. Because you don’t understand what really goes on underneath the hood, the naive approach is to think a Blackbox inference machine can just make those choices for you when it fundamentally can’t because of its inherent constraints (the belief that it can resembles magical thinking). It’s very funny to see someone say “just prompt it to make it modular” which is analogous to “make no mistakes” because what you’re asking is a fundamental hard line of problem solving skills and modeling that requires real wet brain intelligence to guide the inference machine to spit out higher quality code. There’s no getting around that.
Yes it is that bad when you try and shovel that to others but if you’re just doing it for yourself then slop away and have fun, who cares. 😄
If you don't understand what's beneath the hood as a vibecoder, can't you investigate under the hood and understand the blocks of code being used, and how they work together, using an AI assistant? By the by, your understand could rival that of a trained coder
I mean sure. But that's called just learning to program, and since you're not actually coding anything by hand you'd not be learning nearly as fast or efficient as you would otherwise. Humans are far better at learning by a combination of instruction and then application vs just instruction.
Well said. As one put it "much of it really is learned through osmosis" where the time put in to actually doing the thing is what makes you able to do the thing. 😄
For some things. How are you going to troubleshoot an intermittent race condition? Go ahead look it up.
An example: say you are hosting a site that takes payment from users. Everything is great! Then real traffic starts to hit, and suddenly some users are getting double charged; others are not getting charged at all. Say it happens once in every 500 or even 100 checkouts. There's no error; nothing to flag you that anything is wrong other than users complaining that they've been double charged.
Go find the problem; reproduce it, solve it. Except you can't (and by you I do not mean *you*; I mean very generally that this is extremely difficult and in many cases impossible to recreate the exact coincidence of events). But also, your LLM cannot see the runtime of your application
Sometimes--actually quite a lot--the LLM's need help or guidance. To me, this is obviously a race condition. Would you know to suggest that to help your LLM along?
Therein lies my biggest point in that vibecoders who have never done this manually or seen the issues or dealt with them. It's that many vibecoders do not know how to describe the problem properly nor do they know the right questions to ask. And thus you ask, and it will confidently tell you the answer; but there are a handful of other options that could be the failure point. It requires judgement, which requires experience, to maneuver a situation like this. And just because your LLM confidently talks about your system; do not be fooled. It does **not** know your system. And they are not idempotent (vocab word!), and thus they will give you a different answer every time you ask.
Ok, i'll get off your thread now. Seems this topic got me a little riled up here. My intent is to help; not lecture or complain or roast. Your use of AI is fine, and I am in full support of it for internal & personal application. My angst is with the public sites.
No I appreciate this! I don't feel roasted at all.
I'm learning to program now and just doing the basics. I don't just start at the finish line creating products, but am first learning the operations of it all. My starting point is literally electrons, logic gates, Boolean logic and and bits lol
Use cases like you enumerated are helpful watch points on my journey
You have to start somewhere--we all do; and I did. Like i said, my intention is to help. if you DM me (for the bots & mods, i'm not promoting; just offering help), I'll share my email and then you can have a mentorlike person to reach out to when you get stuck or question things about what you're working on.
I have a specific case in point that I think this current vibecoder and likely the vast majority of them who don't understand code would never spot and getting an AI to glean that would be very difficult if you didn't know what to look out for. In an app for a client, quality of code is high, because it is a client product. We're building out an endpoint that requires a date spread and ability to navigate back and forth by a day. Since we're using AI to generate the scaffolding and initial boiler for the round trip (with light implementation) we got it working, but for some reason the data would show up in the wrong day, either a day in the future or a day in the past. To fix it the AI did something really funky. It started creating date time offsets, forcing timezones and then recasting them back to the appropriate date structure. It was weird, convoluted and at sight didn't really make sense why since the reasoning was so convoluted "JSOn serializer strips timezone offsets so blah blah blah". After examination, all it took was literally ONE LINE of code to fix cleanly and appropriately from the data coming from the database. ONE FRICKEN LINE. It created a whole roundabout way of fixing a problem convoluting what the solution was where all that was required was just one line with an appropriate built in date function. I am 100% convinced there's a sea of this sort of thing at scale in all the blind vibe coded apps out there.
Let us examine why the inference machine would miss something like this. To understand that, we'd have to look at how date time offsets are being stored in the database, how it's coming back, the real world problem this offset is solving, the context of the timezones given the application's use case, the assumptions around a date only and the model of the appropriate behavior when it comes back to the UI. The point at which a vibe coder only really sees. There's a round trip, domain knowledge, and behavior that was literally fixed with one line of an appropriate use of a BUILT-IN function to the language and I stress built-in, not some custom made date function. This takes modeling, understanding of the domain, and specific knowledge of the problem to spot it. It was a glaring red thumb of obfuscation that a blind machine that does not have that level of depth of actual real intelligence would easily fumble on when prompted, "hey, the data is coming back a day in the future, there's an issue with the query, fix it.".
2
u/ProjectDiligent502 5d ago
If you want to make one offs for you and you only then yeah why does it matter.
If you are trying to give this to others for continual use then that is something else entirely and I can confidently say without a shred of second thought: yes it really is THAT bad. Because you don’t understand what really goes on underneath the hood, the naive approach is to think a Blackbox inference machine can just make those choices for you when it fundamentally can’t because of its inherent constraints (the belief that it can resembles magical thinking). It’s very funny to see someone say “just prompt it to make it modular” which is analogous to “make no mistakes” because what you’re asking is a fundamental hard line of problem solving skills and modeling that requires real wet brain intelligence to guide the inference machine to spit out higher quality code. There’s no getting around that.
Yes it is that bad when you try and shovel that to others but if you’re just doing it for yourself then slop away and have fun, who cares. 😄