| ▲ | How Do We Stop Vibe Coding?(alexklos.ca) |
| 49 points by prohobo 5 hours ago | 41 comments |
| |
|
| ▲ | throwaway6977 2 hours ago | parent | next [-] |
| Disagree with so many assertions put forth here. 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 thats honestly just a you problem and I wish everyone would stop boogeymanning an obvious improvement in the ability to better yourself just because a lot of people don't choose the betterment route. I've never been more informed or understood more about my code, pipelines, and stack than now- and its 100% due to AI reasoning about my projects, and me making an effort to learn. |
| |
| ▲ | bentobean 10 minutes ago | parent | next [-] | | > I've never been more informed or understood more about my code, pipelines, and stack than now... Would you mind clarifying if this includes code, pipelines, stacks, etc... on which many other people are simultaneously working on in a group setting? Or are these all things that you alone are working on as an individual? My experience has been that AI makes me tremendously more productive as an individual working alone. Put 20 people (all empowered by AI) on a project however, and it quickly falls to shit. | | |
| ▲ | cyanydeez 3 minutes ago | parent [-] | | I've running local models; before having a coding harness, i'd basically do the same misteps the AI does; add the same logging lines, and trace with the errors are, etc. This was exhausting so no docs and tests were rarely if ever created. Now, to actually get the AI to do anything complex, it's basically required to both write docs and write tests because solidifying behavior only works when there's AI tests it can run to verify some behavior I've verified once. Then there's things I'm never going to remember the AI had to do; recenly it was "blitting" to /dev/fb0 and it was trying to remember which encoding was which and what order, etc. Things I simply do not want to have to get a detail account of nor is it something I need to remember above the statement "some video drivers have their own RGB, BGR encoding standards" and "an image has a bit depth and size" etc. These things I would have learned doing it myself, but I would also had to learn where it all breaks and how to interoperate between pillow and video drivers, etc. If I ever do this again, i'll still point the LLM at it with or without this library, and it'll do the same abstract reasoning. So my knowledge is compact because I don't need to know the implementation for this video display code; I just need the tests and docs and I'll point the LLM at it if I need to extend it. |
| |
| ▲ | fidotron 39 minutes ago | parent | prev | next [-] | | The people struggling with this most are also the ones that never got to grips with human delegation either. At least in my circle it's the classic leads/seniors (that predate the scrum "everyone's the same" thing) that are managing to get the most real mileage out of this. | |
| ▲ | svara 4 minutes ago | parent | prev | next [-] | | You're not wrong, but there are levels to understanding. For example, when studying maths or physics, it is very common to feel like you've understood everything, until you get to the exercises, and need to apply that understanding, and it's only then that you consolidate the knowledge and begin to truly understand in depth. I like AI enhanced coding, but I do sometimes worry that we're not getting enough of that depth anymore. | |
| ▲ | lelanthran 5 minutes ago | parent | prev | next [-] | | > If your brain turned off while you were vibe coding thats honestly just a you problem No. There are multiple studies showing that skills atrophy is an actual thing. If your brain does not turn off while you are vibe-coding, keep it up and it soon will. | |
| ▲ | 1718627440 2 hours ago | parent | prev | next [-] | | > 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. | | |
| ▲ | zeroxfe an hour ago | parent | next [-] | | > because that's the definition of vibe coding. That's _your_ definition of vibe coding. | | |
| ▲ | danlitt 4 minutes ago | parent | next [-] | | > Karpathy described it as a form of coding where you "fully give in to the vibes, embrace exponentials, and forget that the code even exists" If that's not "turning your brain off", what is? | |
| ▲ | 1718627440 22 minutes ago | parent | prev [-] | | That's the definition I am aware of, yes. It's also in the term, that you let a vibe (a force coming from the outside) decide what your work lead to, as opposed as to deciding where it should arrive at and leading into that direction. |
| |
| ▲ | jubilanti an hour ago | parent | prev | next [-] | | Feels like a No True Scotsman fallacy. | | |
| ▲ | danlitt 6 minutes ago | parent | next [-] | | By that logic every appeal to the truth is a No True Scotsman fallacy. | |
| ▲ | 1718627440 an hour ago | parent | prev | next [-] | | 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. | |
| ▲ | pdpi an hour ago | parent | prev [-] | | 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. |
| |
| ▲ | alostpuppy an hour ago | parent | prev [-] | | I agree. It’s actually more exhausting in some ways. |
| |
| ▲ | _verandaguy 36 minutes ago | parent | prev | next [-] | | You're technically right on your first point, but I think this is missing a broader issue... this entire technology incentivises its users to put as little effort (and cognitive effort, at that -- so, thought) as possible to go from a vague idea of something they want to a somewhat-working thing. That's how it's being sold, that's how it's being marketed, and that's how it's arguably being built from an interface point-of-view. Is it possible to use it in a more involved way? Certainly. I try to do that. But it's challenging, because ultimately even taking a more collaborative approach, this thing puts out a lot of slop, and then I have to deal with going over the output and just spending most of my day in code review mode vs an author that doesn't ever learn from feedback. The most frustrating thing for me beyond the feedback black hole is that when things do inevitably go wrong, trying to point out the concrete issue and instructing the LLM to do better around it is challenging; a lot of the time directives (even those in a global CLAUDE.md!) are just ignored either outright or as the context grows, or fail to be passed down to subagents; negative prompts are discouraged because of the pink elephant effect, so I have to jump through hoops to try and frame a "never do $thing" constraint as an affirmative prompt (which is then often ignored). That aside, english is a godawful language for specifying things compared to programming languages. It's just a really frustrating experience overall. | |
| ▲ | lardosaurusrex 21 minutes ago | parent | prev | next [-] | | So like I get what you're saying but an LLM helping you code is just a personal search engine/autocomplete. "Vibe coding" to me and others is just going "claude program me a wife that didn't leave with the kids and make no mistakes" and just rawdogging the output. but that's just me. | |
| ▲ | prohobo 2 hours ago | parent | prev [-] | | I never said you have to turn your brain off to feel the limitations. Actually, for more complex work I think it's pretty common to spend a long time crafting some elaborate prompt, and then arguing with the agent for 10-20 turns, getting a "passable" plan, accepting it then arguing with the agent every step of the way because it's doing it wrong. It's incredibly frustrating, even with models like Fable. Even after that, I'll often find out during later sessions that some feature that was supposed to be deprecated was actually silently left in "because I wasn't sure you wanted it completely gone" or something. I agree that exploring a codebase through prompts is actually quite nice! But the mental model you get from that is almost always warped - you have to supplement that with reading the code, where 9 times out of 10 you will find some kind of discrepancy that you're unhappy with. Why not optimize that process? | | |
| ▲ | resonious 31 minutes ago | parent | next [-] | | This sounds like not the best workflow. If your prompt is that long, you may not be spending your time very efficiently. Splitting problems into smaller problems is huge. You want a concrete idea that you still own. Only tell an agent to do something you know it can nail - this will likely be one subsystem. The subsystems and how they talk is on you. | | |
| ▲ | prohobo 12 minutes ago | parent [-] | | I agree, I tend to give a high-level concept for what I want done first, and then break it into smaller tasks. That said, there's almost always a misunderstanding within the smaller tasks anyway, which I have to test to find out about, then ask the agent to fix. |
| |
| ▲ | HappySweeney an hour ago | parent | prev [-] | | Your experience is night-and-day from mine. Both myself and the AI correct and remove each other's gaps in understanding. There is never what I would call arguing. Disagreements are resolved by back and forth discussion and reaching consensus. |
|
|
|
| ▲ | didroe an hour ago | parent | prev | next [-] |
| I 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. |
|
| ▲ | Havoc an hour ago | parent | prev | next [-] |
| >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 |
| |
| ▲ | bitexploder an hour ago | parent | next [-] | | We now have more work, not less. Engineers can finally address security and tech debt! Surely businesses will see the value in that. Right? | | |
| ▲ | KronisLV 2 minutes ago | parent [-] | | > Engineers can finally address security and tech debt! I’ve been gradually moving test coverage up, updating packages with CVEs (even if in some cases it’s more like a migration), fixing more bugs, writing load testing solutions, fixing badly made architectural choices and recently even migrated a codebase away from Oracle onto PostgreSQL and figured out some pretty good settings for the DB itself with the aforementioned test tool. Oh and introduced Testcontainers to actually do proper DB tests. None of this would have happened without agents that churn even while I sleep, but somehow that is still more work cause I have to iterate on their output a lot and come up with additional ProjectLint rules whenever something new comes up. It’s like burnout². Obviously I also bear the blame when the slop inevitably goes wrong despite efforts to keep it manageable, so maybe touching nothing would be better. |
| |
| ▲ | Hoodedcrow an hour ago | parent | prev [-] | | > 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. |
|
|
| ▲ | Towaway69 2 hours ago | parent | prev | next [-] |
| Howabout: just turn off AI. I scanned the article, never made it to the bottom, didn’t find the point the author was trying to make. Howabout just learning to code better as a human without using AI. Just like learning a craft. Just refuse to use AI. Not possible because of peer pressure? Well then stop worrying and continue to vibe. Either stop or stop complaining but don’t make excuses or write long articles that ramble and rant … sorry but I don’t understand what’s so hard about stopping. |
| |
| ▲ | boguscoder an hour ago | parent | next [-] | | It might not be so much of a peer pressure than “industry pressure” soon. You can keep hand-crafting it all you want as a hobby, but selling your crafts will be totally different matter | |
| ▲ | krater23 4 minutes ago | parent | prev [-] | | The fear that I have that I end up in a team that don't care that I hand code my stuff and let their shit everywhere in the code, so that hand coding isn't possible anymore in a team. It's the same with frameworks. Building a webinterface with a framework is really easy, but the result is just bullshit compared to plain php. It looks good, but your load und wait time goes straight up. |
|
|
| ▲ | trjordan an hour ago | parent | prev | next [-] |
| Man, 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. |
|
| ▲ | nadis an hour ago | parent | prev | next [-] |
| This 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" but I think that there should be tools that facilitate thoughtful ways of vibe coding with natural language, which is basically another abstraction layer from writing the code and tests yourself. |
| |
| ▲ | prohobo an hour ago | parent [-] | | 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. |
|
|
| ▲ | jamal-kumar 2 hours ago | parent | prev | next [-] |
| I enjoyed the article, I think you're right that the tooling to get out of making things too automatic is definitely lacking. AI coding is cool if you have something in a certain valley of simple enough for it to get but not so complex or low level that it will screw it up, but commercial models don't really do the following yet: 1. malware development 2. anything security tooling related 3. reliable assembly 4. reliable and somewhat more obscure programming languages like blockchain programming langs or distributed programming with elixir I feel that https://maldevacademy.com has been keeping my skills relatively fresh, it's fun in the discord where sometimes we try using models to do this stuff and it just chokes On the other hand I "vibe coded" (Although I've heard more nuanced distinctions in terminology here about doing it right rather than just letting it rip automatically or without much thought) a fairly large and profitable software project in about a month recently that would have probably taken me over three if I hadn't used claude. In the end and as you mentioned, these things are just tools and if you're busy complaining about them rather than finding what they can't do yet and having a bit of fun with working within those limits, you might be able to find a good niche to make better use of your time and avoid the skill atrophy |
| |
| ▲ | prohobo 41 minutes ago | parent [-] | | Thanks, yeah I just went with the most controversial term as the catch-all which just means: you prompt an agent as your core workflow. For me as well, I do projects for clients that would have taken me months, and I deliver them in a fraction of the time. It's amazing and totally helped cure my burnout (which I had for over a year before I found Claude Code.) |
|
|
| ▲ | thenatureboy 2 hours ago | parent | prev | next [-] |
| Economics will dictate that working bespoke on coding will simply not be profitable anymore. Great article but there is no stopping this trend at this rate. |
|
| ▲ | ethagnawl 5 minutes ago | parent | prev | next [-] |
| > ... why would we even want to do this manually? All it did was lead to burnout and cynicism. Speak for yourself. If anything is leading _me_ to burnout, it's this bullshit hype cycle. |
|
| ▲ | Supermancho an hour ago | parent | prev | next [-] |
| While 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 something better. |
|
| ▲ | arisAlexis an hour ago | parent | prev | next [-] |
| We can also go back to the telegraph |
|
| ▲ | ls-a 2 hours ago | parent | prev [-] |
| Vibe coding is the new way forward. Please adapt or you will lose so much |
| |
| ▲ | Supermancho 2 hours ago | parent [-] | | > Vibe coding is the new way forward. Please adapt or you will lose so much This is a reaction to the title, by someone who did not read the article. | | |
|
