Comment by SlowTao
2 days ago
I suppose the idea that it is based more on feeling of what needs to be done than intellectual construction of the code. That is a drastic simplification because even with the 'vibe code' you still need to have some form of overview.
It does lean into the idea that vibe code is 'Increased productivity, reduced understanding.'
The overall conclusion between me and my peers - all very senior devs - that know how to be productive with these systems is that it’s not “vibe coding” at all. You fist spend hours working out and reviewing and correcting and improving detailed specs and implementation plans, and then hand over the implementation to the LLM.
There are too many implicit contextual details that the LLM doesn’t know about that just make coding based on “vibes” not work at all. Eg the size of your organization heavily influences the types of tests you want to write and maintain.
So you still need a very solid understanding of engineering and your domain in order to get it to solve your problems properly.
But in the end, if you learn how to use it well, it’s an insane productivity boost. But you need to spend a month or two to learn how they really work, their limitations, and figure out a workflow.
> You fist spend hours working out and reviewing and correcting and improving detailed specs and implementation plans, and then hand over the implementation to the LLM.
Anyone that cares to actually do this does not save any time by going with an LLM instead of just coding. For any cases where time saving is actually done, I would argue that the thing coded should either be a framework, a library, or an editor macros (or extensions like JavaBeans generators in Java IDEs).