Vibe code isn't meant to be reviewed
monadical.com
Vibe code isn't meant to be reviewed
1–10 of 27 posts
Re: Vibe code isn't meant to be reviewed
#2After some vibe coding frustrations, ups and downs, I found that splitting the code explicitly into well-curated, domain-heavy guidance code and code marked “slop” can solve a lot of frustration and inefficiency.
We can be honest in our PR, “yes, this is slop,” while being technical and picky about code that actually matters.
The “guidance” code is not only great for preserving knowledge and aiding the discovery process, but it is very strong at creating a system of “checks and balances” for your AI slops to conform to, which greatly boosts vibe quality.
Helps me both technically (at least I feel so) with guiding claude code to do exactly what I want (or what we agreed to!) and psychologically because there's no detachment from the knowledge of the system anymore.
Re: Vibe code isn't meant to be reviewed
#3Great stuff here. I've also found that doing all the architecture and interface work manually, then having Cursor write plans that follow that architecture to implement specific features is an ideal place to separate the human from the vibe coding.
Then, it's easy to revise the plan itself or have Cursor do that, then re-run it to make individual implementation changes or fixes that don't affect your architecture or invent new interfaces.
Re: Vibe code isn't meant to be reviewed
#4After some vibe coding frustrations, ups and downs, I found that splitting the code explicitly into well-curated, domain-heavy guidance code and code marked “slop” can solve a lot of frustration and inefficiency. We can be honest in our PR, “yes, this is slop,” while being technical and picky about code that actually matters. The “guidance” code is not only great for preserving knowledge and aiding the discovery proc…
What is the measured LoC ratio of well-curated to "slop" code?
Re: Vibe code isn't meant to be reviewed
#5This reminds me of the old idea that you could get some architecture astronauts to specify a system and then offload the implementation of the individual modules to the cheapest developers one could find. Which didn't always work well in practice...
Re: Vibe code isn't meant to be reviewed
#6This is certainly not engineering. Maybe I’m finally a curmudgeon after years of chasing everything in this industry and getting burned enough times but vibe coding without manual review and testing is antithetical to contemporary study on software engineering and development. Are we really gluttons for punishment like this? Like writing a novel on a Nokia 6630, it’s a fun oddity but not really a scalable way to create value.
Re: Vibe code isn't meant to be reviewed
#7Be honest: do people vibe code because they simply can’t imagine all the complexity and details of what they’re trying to achieve, or is it simply because it’s faster than typing it all out?
If it’s the latter, perhaps it’s a sign that we are making languages too verbose, and there’s a lot of boilerplate patterns that could be cut down if we give ourselves wider vocabulary (syntax) to express concepts.
In the end, if we can come up with a language that is 1 to 1 with the time and effort spent to write equivalent prompts, there will be no need for vibe coding anymore unless you really don’t know what you’re doing, in which case you should develop your skills or simply not be a software engineer. Some may say this language already exists.
Re: Vibe code isn't meant to be reviewed
#8After some vibe coding frustrations, ups and downs, I found that splitting the code explicitly into well-curated, domain-heavy guidance code and code marked “slop” can solve a lot of frustration and inefficiency. We can be honest in our PR, “yes, this is slop,” while being technical and picky about code that actually matters. The “guidance” code is not only great for preserving knowledge and aiding the discovery proc…
What is the measured LoC ratio of well-curated to "slop" code?
Just feeling and experience, really. For me, if I spent time with the vibe code snippet and improved it until I can say "yes I would've written this" it's not slop anymore, even if it was written by Claude initially.
On the contrary, if I glanced over the code and could say "ok it doesn't look terrible, no obvious `rm -rf` and all", even if I changed a couple obvious mistakes, I still consider it vibe.
Re: Vibe code isn't meant to be reviewed
#9After some vibe coding frustrations, ups and downs, I found that splitting the code explicitly into well-curated, domain-heavy guidance code and code marked “slop” can solve a lot of frustration and inefficiency. We can be honest in our PR, “yes, this is slop,” while being technical and picky about code that actually matters. The “guidance” code is not only great for preserving knowledge and aiding the discovery proc…
Lately I've been thinking "there is no such thing as an application, there are only screens" in the context of HTMX-enhanced web applications.
If your persistence layer and long-term data structures are solid you can accept shoddy coding in screens (e.g. a small bundle of http endpoints.) From that viewpoint you modernize an application a screen at a time and if you don't like a shoddy screen you create a new screen. From that viewpoint you vibe code screens but schemas and updating are carefully handwritten code, though I think deterministic code generation from a schema is the power tool for that.
Re: Vibe code isn't meant to be reviewed
#10This sets up a pointless strawman about reviews for the headline that distracts so much from the point that I only caught it on second read:
Restrict agentic workflows to implementation details, hand-write the higher-level logic and critical tests, and only pay attention to whether those human-written tests pass or fail. Then you don't have to worry about reviewing agent-generated code as long as the human-written tests about the functionality pass.
(Still not sure I agree, not least of which for security and performance reasons at existing orgs; this assumes very good test coverage and design exist before any code is written. Interesting for greenfield projects though.)