How Do We Stop Vibe Coding?(alexklos.ca) |
How Do We Stop Vibe Coding?(alexklos.ca) |
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.
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.
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.
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.
That's _your_ definition of vibe coding.
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?
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.
Intent is more natural to us than code, for the same reason assembly is more natural than binary.
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
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.
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
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.)
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.
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.
This is a reaction to the title, by someone who did not read the article.
The property Scotsman is existing a priori and then a causality to behaviour is assumed. But here the term is defined by behaviour.
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.