This is something that really needs to be formally studied.
I'm inclined to say that this matches my own experience, but I can't rule out confirmation bias on my part.
As a meticulous person generally looking for a very specific code outcome, I prompt in a way intended to get exactly the thing I have in mind, and my results reflect that. But on the other hand, I have coworkers who type ten-word prompts with very limited specificity, and they seem to get results that way as well, and that makes me wonder.
It would certainly be beneficial for my career and financial well-being for the assertion to be true, because it means I don't have to worry about being pushed out of my job by an army of $15/hr vibe coders. But the convenience of that assumption is exactly why I think it's important to be skeptical.
Meanwhile all I do is vibecode. I get the outcomes I want though.
I see vibe coded apps as requirement documents. Rarely do I have to engineer.
If my job gave me some actual tasks, then maybe I'd engineer something. But at home? Vibe coding all the way. I'm open to engineering, but I need a compelling reason such as: the app is fundamentally broken and an LLM is going in circles. When the only user is me, there are not many performance issues to think about or fix, so that helps. Moreover, certain systems don't need to exist (though they might soon since now I have a smattering of apps that I need to manage).
I suck at writing code, so strictly speaking: Everything I do is vibecoded.
The stuff that I produce in this way would probably be considered by many to be unusable trash. But it solves the problems I have, and it does so with exactly the amount of precision that I demand.
When I built a PWM fan controller for a pro audio amplifier, I was very particular about some aspects. I wanted maximum resolution from the DS1820B temperature sensors (which is a relatively slow mode where reads take ~750ms, and often the bot is primarily interested in fast), and resolutely-consistent PWM output (so software PWM was a non-starter).
It was very important to me that the fan speed ramp smoothly and without audibly-discernible steps, so the target output goes through a low-pass filter to smooth things out and the final PWM value gets recalculated at a completely-overkilled rate of 1KHz.
Power consumption was a very deliberate non-concern: The power used by the MCU is ~nothing compared to that of the whole of the system, so optimizing towards reducing it was never my goal.
At the end, it's a rewarding little project that is all wrapped into a state machine that burns clock cycles like they're free (they are free!), and it works very well.
There's parts of this thing that I do not understand at all, and that I have no desire to understand.
But if I hadn't been so particular about the parts I did care about, then: An underspecified one-shot prompt seems like it would probably have just produced a loop with a lazy 1-second sleep at the end, since being sleepy and power-efficient was a feature that the bot kept working to reintroduce.
I spent a lot of time working to dismantle the bot's proclivities to be this way, and I probably would not be happy with the end result if I had just let it do its thing.
Differently-stated: It could have been an unsupervised one-shot prompt, and the result almost certainly would have done the job of keeping the amplifier cool. (I just would not like it.)
I’m a hardware engineer and there’s many ways to solve this problem but I’m not sure I understand yours at all haha.
Hah. I'm not any kind of engineer. If you feel like it, I'd be appreciative of any evaluation you might have for what I came up with and how I came to rationalize it.
I wanted the thing to be as quiet as possible at all times, and to always minimize the ways in which it can annoy.
Fans, as frequently implemented, are often annoying. They're often noisy all of the time because they lack controls.
Sometimes, they have dynamic controls that suck. Like a Juniper switch that runs the fans at a screaming 100% that you can't have a conversation near during its minutes-long boot process, and then quiets down to only a dull roar (but never any quieter).
Sometimes they suck in other ways: It starts quiet, but then it ramps up in audible quantized steps as cooling demands increase. The very definition of these steps is distracting.
Sometimes, they're just too responsive to be tolerated in the company of humans. The fan speed is always hunting and changing the pitch of the noise it produces, and sometimes this adjustment happens at a discernible and very regular interval that just makes it maddening to be around.
Sometimes, they're arguably even worse than any of that: The fan cycles on and off. It is a jet turbine, or it is silent. There is no in-between.
Sometimes, they're very clever in the worst ways: They ramp up instantly in response to dynamic events, and then slowly wind back down. That's awful in a power amplifier but it happens anyway, wherein: Every loud amplified sound is punctuated by the dying roar of a fan, even when the dynamic event was actually a short-lived nothingburger.
---
Anyway, this one is buttery-smooth. It responds to temperature on a curve. It has no perceptible steps as speeds increase or decrease. It's deliberately lazy and smoothed-out in its response; this amplifier has several pounds of aluminum heatsinks so instant response just isn't ever useful, and it's also least-annoying to deliberately eliminate rapid speed changes altogether.
The fan is a big Nidec screamer that I got from a late-century, grossly-overbuilt Dell Precision desktop. It can reliably spin so slowly that it's essentially silent (as is useful for an engineering workstation like that Dell), and it can also move enough air to fly itself right up and off of the bench.
The controller automatically finds the minimum viable speed for the installed fan, so it avoids being stalled at low duty cycles. In this way, some air is moving regardless of which make/model of 4-wire PC-style PWM fan is used down the road, making potential bush fixes more practical and functional. (It also does stall detection and recalibrates if that's ever necessary for some reason.)
And there's no lookup tables, because lookup tables imply steps and steps are bad. Besides, I'm not trying to save a million nickles on a million units here; shaving pennies isn't part of the program and a single $3 MCU board is cheap for my [qty. 1] application, so that what it gets. By extension, it has way more than enough grunt to get everything done and it just computes it all over and over again.
Like the output %, which gets rejiggered at a rate of 1KHz: I could have probably been happy with 100Hz. Or 10Hz. But the MCU is already chosen and it can do 1KHz just fine, so... that's what it do. It doesn't matter that it is inefficient; efficiency wasn't a goal. :)
And, because it's vibe coded: Of course this big rack-mount power amp from 1986 has a wifi-accessible web interface for its cooling system. It seemed like a pocket computer would be best way to provide a way to twist some of the cooling-related knobs when used in the field, since this is a functional prototype that sometimes gets used in literal fields. (It was dead simple to to get the bot to put that part together. The networking stuff might have been the easiest part.)