Getting vibe coding to work for me
I bounced off of Cursor a couple of months ago. It was good having code in context in the sidebar, a leg up from cutting and pasting, but I found its agent UI confusing and it made odd edits. In addition, when I left it open for a week, it’d progressively get less responsive to keystrokes. I ended up going with Zed for the editor.
When I tried Claude Code, I initially didn’t find it all that great. It could have been the domain I was working in (writing a DBSP implementation for incremental compute), but I found that its design and architectural choices were all wrong in subtle ways. In addition, I’d try reviewing every single edit. Which was all slow, time consuming, and I’d be out of $80 with no code to show for it.
What I found finally worked is just letting go and having the vibe wash over you. (I also changed over to a domain coding agents are more familiar with—web apps) Break down tasks to something a junior can tackle. If there’s something more complex, I chat with o3 on all the design questions and issues. Once satisfied, I tell it to write me a prompt for a coding agent in the form of a PRD.
Then, I take that and paste it into Claude Code, and have it churn on that til completion. Unlike before, I’d only review its edits after it was all done. I always use a clean commit (or git worktree) to have it work on something. If I didn’t like its result, I’d have it try to correct once or twice. But if it can’t get it, I’d just blow the entire commit away, and paste in the PRD and pull the casino lever all over again.
It takes a couple tries to get a sense of the type of task, the domain, and the granularity of task that works. While it feels like my number of commits have gone up, github commits say otherwise. I think it’s more that it’s expanded the type of things I can tackle and get immediate results to test some hypothesis or get some intuitive feel.
I think what’s often left unsaid is that devs have wildly different ways of working, and some of these work well as scaffolding for coding agents to do well, but people never mention it as part of their workflow. Some people write extensive comments on every group of code, which can be helpful for LLMs reading the code. Other people save their PRDs and tasks in the repo itself for the LLM to refer to. And having unit tests (and in some cases, formal verification), type checking, and other guardrails for the LLM to self-correct on their agentic coding spree.
I think some devs also have a different mental model of LLMs. Some inherently believe that if it doesn’t work, it’s because the LLMs aren’t good enough yet, so they bounce off of it easily. Others inherently believe that if it doesn’t work, then it’s how they’re holding it, and will invest time to think of different ways to prompt it or inject context into it to get it to work. I find that you need to be a bit of the latter.
