Vibe Coding Strategies
It is interesting to me that, in many ways, it turns out that the same problems that are encountered without an LLM are encountered with an LLM when it comes to change management. I cannot say this for a fact, but it seems to me that, in an effort to be helpful, the LLMs try to make too many changes at once, with too few details on what exactly needs to be done. Not unlike an engineer.
I've had some success with Vibe coding by breaking it into a few phases and artifacts. The good thing to me about this is that, while it does not eliminate LLM orchestrated brain drain, it does make it quite explicit where the gaps are--and maybe even facilitate a roadmap for an early career engineer to a senior engineer, merely by solving problems further and further to the left.
Artifact One: A Project Description #
I start with a conversation with an LLM where I explicitly recommend not to build the thing I am describing, but to ask for clarifying details, and to generate a prompt for an LLM to consume to understand the context of a so described codebase.
Artifact Two: A Project Plan #
I should say that I try to keep my project description very focused. And I think the more focused it is, the more successful this phase is. This also carries out to the next phase. Which is to say that 'all we need is attention' was a statement true of LLMs, and of the humans coaching them.
In this phase, I take the context doc (or PRD if you will) and begin to break it down with the LLM. We begin to make some architectural decisions, such as relevant technologies, or to document those decisions as part of the plan. I am pretty explicit about the project or feature being built here, along with the timeline and work commitments. I will say, "I want to build this in the next 2 days". I also have the prompt emphasize immediate usability and testability.
The output of this part of the work is a plan. Usually broken up by day, with a number of discrete tasks that need to be completed that day to stay on target for the full scope of work. This plan tries to be very granular. I map each 'task' to one or more commits, as we'll see in a moment.
Artifact Three: Commits #
Once I have the project context, and the plan in place, I put both of these into a coding agent and ask it to identify the next thing that needs to be done on the plan that has not been done already. It will pick a thing and I will evaluate if that's the thing that makes the most sense. If so, I ask it to introduce a small (my custom instructions ask for 5-10 line code changes at most) that either solves the problem or makes progress against it. I also recommend ensuring that these changes are either transparent (that is, they do nothing in the codebase) or testable (that do something very explicit that can be observed)--again, the second is better than the first--add the hooks in and then propagate them down.
I take the changes one commit at a time, testing them, and then prompting for the next thing (usually, what's next) or throwing out those changes and making my own based on them, or completely different. Sometimes, this step is skipped entirely based on the response of 'what is next', when I think I can make progress faster than the bot.
A Roadmap for Engineering #
When an engineer is first getting started, they take a ticket and implement it. This aligns with artifact three as the point of entry. Mid and Senior engineers, begin to make and refine plans, with the more senior engineers writing full end to end plans in some cases.
I've found that all of this work simplifies some of my workflows, allows me to deliver code with substantial time savings, and keeps the LLM from getting lost. If it gets spun around on a bad solution, I can dump all context and start a new chat at the beginning of artifact three. I do this often.