[dead]
How do we stop vibe coding?
21–30 of 90 posts
Re: How do we stop vibe coding?
#22>Writing code by hand will always be around for bespoke and novel, complex work.
That sentence is probably the key.
There is zero chance of this stopping overall.
Much like with artists 90% of the commercial stuff - copy/ads with generic guy in suit picture - will be AI that is "good enough".
Less concerned about the code quality and more the labour market dynamics. If this goes anything like translation & creative space did then there is going to be a brutal shakeup where competition for remaining "real" seats gets intense
Re: How do we stop vibe coding?
#23Man, it's wild how I have no original thoughts. I've been pulling on this thought this morning, complete with checking in on how CodeSpeak and Tessl are doing.
I'll add this link to the pile: https://martinfowler.com/articles/exploring-gen-ai/sdd-3-too...
> spec-kit created a LOT of markdown files for me to review. They were repetitive, both with each other, and with the code that already existed. Some contained code already. Overall they were just very verbose and tedious to review. [...] To be honest, I’d rather review code than all these markdown files.
The hardest part of any of this extraction is that modern code is already an extremely dense representation of how the computer should work. You mostly can't change the code without changing behavior.
I bet Scryer works for his use case, and it's a joy to dogfood. I also bet it fully breaks down the moment a 2nd developer, who cares about different things, joins the team.
Re: How do we stop vibe coding?
#24This piece is more thoughtful than the title initially led me to believe. However, I feel like it's sort of like advocating for us all being able to read/write binary (using a bit of an extreme to prove a point). While there might certainly be benefits to understanding less abstract layers, I don't think it's necessary or even necessarily helpful. That said, I don't think the answer is "turn your brain off completely…
I'm making the case that we should make tools for the higher abstraction, not a lower one. You said it yourself: why should we read/write binary? We don't, we shouldn't. It might be useful in some cases, but working with assembly is much easier.
Intent is more natural to us than code, for the same reason assembly is more natural than binary.
Re: How do we stop vibe coding?
#25>Writing code by hand will always be around for bespoke and novel, complex work. That sentence is probably the key. There is zero chance of this stopping overall. Much like with artists 90% of the commercial stuff - copy/ads with generic guy in suit picture - will be AI that is "good enough". Less concerned about the code quality and more the labour market dynamics. If this goes anything like translation & creative s…
We now have more work, not less. Engineers can finally address security and tech debt! Surely businesses will see the value in that. Right?
Re: How do we stop vibe coding?
#26Earlier quoted context omitted.
> You don't _have_ to turn you brain off when coding with an LLM. It's not some intelligence dementor. If your brain turned off while you were vibe coding You have too, because that's the definition of vibe coding. If you use an LLM to assist you, but still keep your brain on, that's not vibe coding.
Feels like a No True Scotsman fallacy.
How so?
The property Scotsman is existing a priori and then a causality to behaviour is assumed. But here the term is defined by behaviour.
Re: How do we stop vibe coding?
#27>Writing code by hand will always be around for bespoke and novel, complex work. That sentence is probably the key. There is zero chance of this stopping overall. Much like with artists 90% of the commercial stuff - copy/ads with generic guy in suit picture - will be AI that is "good enough". Less concerned about the code quality and more the labour market dynamics. If this goes anything like translation & creative s…
> Much like with artists 90% of the commercial stuff - copy/ads with generic guy in suit picture - will be AI that is "good enough".
Eh, wouldn't be sure. Every time I see slop in such a context, it makes my day worse. And usually ensures I wouldn't go to that business, or at least unconsciously biases me against it.
Re: How do we stop vibe coding?
#28Earlier quoted context omitted.
> You don't _have_ to turn you brain off when coding with an LLM. It's not some intelligence dementor. If your brain turned off while you were vibe coding You have too, because that's the definition of vibe coding. If you use an LLM to assist you, but still keep your brain on, that's not vibe coding.
Feels like a No True Scotsman fallacy.
There's multiple ways to program using LLMs, so using different words for different styles is a useful distinction.
Of course, you absolutely can build a No True Scotsman argument on top of that distinction, but I don't think that's what GP was doing.
Re: How do we stop vibe coding?
#29While my CONTEXT.md's are a hodgepodge of general ideals and specific do's/dont's, my AGENTS.md are demonstrable. I can instrument to observe the instructions being executed. * Delegation * Execution (better rules than rtk) * Response * Logging When I want to turn off the printf style confirmations, manually editing saves the tokens. Using RFC 2119 (language) doesn't make a substantial difference. I'm in search of so…
[flagged]
Re: How do we stop vibe coding?
#30I think a big issue is that the companies pushing AI want it to replace people entirely. So the software around it is designed with that mindset.
I'd really like something that works more like pair programming. Where you share an editor session with the AI, and it's much more interactive. eg. It says "I'm thinking about doing X here, what do you think?". Then you give a response and it continues. Or you can see it doing something silly and immediately stop it and correct something either with a prompt or by manually editing yourself, before letting it rip again. Or just ask it "why are you doing it that way?". Maybe with some control over the speed it's going, for when you feel confident about what it's doing.
Claude has made some positive changes over time where it asks you more when there are different approaches it can take. But I feel like I'm not being brought along with my mental model as much as I would like. A lot of the time it spits out a whole pile of code and then I have to go and build up the mental model after the fact, and correct a lot of what it's done.
The current approach is good a lot of the time though, when you're not really changing anything architectural and just want it to bash out code while you do somehthing else.