11–20 of 27 posts
This 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...
This 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 crea…
Fundamentally, we acknowledge that AI writes crappy code and there's no visible path forward to really change that. I realize that it's getting incrementally better against various benchmarks, but would need a large step function change in code quality/accuracy to be considered "good" at software engineering.
I get the appeal of trying to provide it stricter guardrails. And I'm willing to bet that the overall quality of the system built this way is better than one that is just 100% vibe coded.
But that also implies a spectrum of quality between human code and vibe code..where the closer you get to human code the higher the quality, and vice versa. The author says this as well. But is there really an acceptable quality bar that can be reached with a significant % of the codebase being vibe coded? I'm pretty skeptical (speaking as some who uses AI tools all the time).
> “Does it work? Does it pass tests? Doesn’t it sneak around the overseer package requirements? Does it look safe enough? Ship it.”
If this type of code review were sufficient, we would already be doing it for human code. Wouldn't we?
> The business logic is in the interface packages - here’s exactly how it works. The implementation details are auto-generated, but the core logic is solid.
I don't understand how to separate "business logic" from "implementation details". These things form a venn diagram, but the author seems to treat them as exclusive.
I think testing and reviewing LLM-generated code remains just as important. Hopefully they will get better, and it will be easier (and hopefully LLMs can also assist with reviews).
This 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 crea…
To me, coding is a process of learning and discovery, of perpetually preparing me to develop something even better next time. Just as a developer wouldn't be using libraries if they weren't well written, the same logic extends to applications.
I can definitely see poor programmers rely on unreviewed vibe code, and I guess they have nothing to lose, but I don't imagine anyone actually using their output. It's like trying to resell an AI generated image; there is just no market for it after the initial generation.
After 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…
When they built Citicorp Center, the contractor bolted the steel insstead of welding it. It was thought to be an implementation detail. Bolting was cheaper, and nobody thought it actually mattered. Until the actual engineer who designed it looked more carefully and discovered that as a result the building was more vulnerable to wind loads. Expensive rework was required to open up the interior walls and weld all the bolted connections.
There's a lot of precedence for excluding "generated" code from review and linting but it's a bit weird when that is a large portion of the application and you can't rely on the correctness (non-LLM generated code is typically very mechanically generated so you just need to ensure the inputs are correct, not outputs). I think testing and reviewing LLM-generated code remains just as important. Hopefully they will get…
This 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 te…
Does it? In the olden days when hand-coding everything was the only way, you'd write a single test, implement what is necessary for it to pass, and then repeat until you have the full set of functionality covered. Your design would also emerge out of that process.
Which, conveniently, is also how AI seems to work best in this role. i.e. Give it a minimal task and then keep iteratively expanding upon it with more and more bits of information until finally reaching completion. So, in theory, I'm not sure anything has changed.
But the roundtrip time on the agents today is excruciatingly slow, so the question is: Does the typical developer have enough fortitude to stick with it from start to finish without looking for shortcuts to speed up the process? It may not be practical for that reason.
Earlier quoted context omitted.
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.
So the question really is: in your experience how much code requires careful review and re-prompting vs leaving it as "not terrible".
Asking because my experience is that in practice LLMs are no better than juniors - ie. it is more effective to just write the thing by myself instead of multiple rounds of reviewing and re-prompting which does not really achieve what I really want.