← Back to context

Comment by apatheticonion

7 hours ago

Agreed. I've been "guide coding" in my editor (Zed / VSCode) for a while now and it's really enjoyable.

DeepSeek v4 flash has been dirt cheap and so fast that my development loop is;

- small prompt

- review

- small prompt

- review

I build software with the same quality I normally would but it's way faster to produce and I think more about architecture and flows than I do about implementation details. The small diffs let me accept / modify / veto diffs and if the model struggles, I just write it by hand. It prevents compounding defects from leading the model astray (like you see in vibe coding).

In some cases vibe coding is useful, like when the complete specification is available (e.g. creating a JavaScript engine that implements the standard) - but anything that requires iterative development sees vibe coding break down pretty quickly (you could argue that is the case for a JavaScript engine).

I feel energised by AI assisted coding rather than drained, as it's a force multiplier for my skills and it lets me build more than I could by myself.

That said, most of my team vibe codes and reviewing their work is like pulling teeth.

Basically how I feel, but I use the low-powered API models like Sonnet. I feel more energized and focused on the bigger picture than getting stuck on stupid implementation of micro-problems.

I think the muscle memory of doing those tiny problems is good for our minds, but solving larger-scale issues is also challenging.

I'm on vacation right now and getting claude to build a mostly-throwaway e2e testing harness (admittedly not small-prompt-review-repeat) for a backend API to speed up our existing e2e test suites which do click-ops to set up tests 8-10 years ago, we had a team who spent 3-4 months every year maintaining our E2E suite and people would do rotations on there to spread the knowledge.

I basically want an industry standard practice implemented on my team of 4 devs who are too busy doing other things.