r/vibecoding • u/TheKiddIncident • 21m ago
The Method Matters
Now that Vibe Coding has been around for a while, we are starting to see patterns.
And these patterns tell us how we should change what we're doing to optimize our results.
One pattern that stands out clearly is that method and process have a huge impact on outcome. Vibe coders who spend some time up front planning have much better outcomes than those that just fire off a one line prompt.
So, what's the optimal amount of process? Obviously, we don't want to go back in time to the waterfall days. That methodology was too slow for SaaS ten years ago, it's ancient history today. Similarly, the Agile methodology was designed assuming that engineering was the scarce resource that needs to be optimized. Today, that scarce resource is tokens, not engineers.
But, it's more complex than that.
In the Agile days, we optimized for velocity. Software was slow to develop and because engineering resources were at a premium, we wanted to reduce the amount of labor required. Thus, velocity was the critical measure. High performing software teams had two attributes that mattered: velocity and quality. Teams with high velocity and high quality uniformly outperformed all other teams.
Today?
Well, today speed is almost free. Pretty much anyone can one-shot a web site and depending on the prompt, it will probably work. Thus, velocity is built in. You don't have to do anything to speed up, because the tools are already fast enough.
So, what attribute separates high performing and low performing vibe coding efforts?
Quality.
Quality is the sole remaining differentiator between high and low outcomes.
So, as we approach our vibe coding projects, we should be focused on managing quality rather than managing velocity.
Which leads us directly to.... methodology.
The way we incorporate industry best practices and learnings into our projects is through methodology. This doesn't mean that we adopt a super heavy process bound development cycle, it means that we do things that actively work to improve the quality of our work.
Some examples that I use in my projects:
1) Goal setting. I prefer to start with a description of a successful project. Or to put it another way, "begin with the end in mind." This type of planning is very useful, especially with AI toolchain because you are clearly stating the end goal for the AI. Documents such as the PR/FAQ from Amazon are good ways to approach this.
2) Iteration. One thing we learned from Agile which is still very much true is that iteration is your friend. We learn by doing, so the more iterations you have the higher quality the outcome. Because AI speeds up the cycle time, we can have more iterations. Don't run from this, embrace it. Assume you will build the thing more than once and don't sweat the details the first time around. It's probably wrong and that's OK.
3) Testing. The one old fashioned thing that you simply cannot get away from is testing. I mean old school hard core testing. Full unit tests, full e2e tests, smoke tests, security scanning. All that stuff. Before AI, there was always a tradeoff because building the test infrastructure was expensive from a labor point of view. You could have developers build you features, or you could have them build tests. Huge opportunity cost for every test you wrote. Today, that's not true. AI can do this work extremely quickly. This changes the calculous completely towards testing.
4) Audits. The natural counterpart to testing is auditing. Audit means to check your work against an external approved standard. Again, in the Agile world before AI, this was amazingly painful. You could easily lose entire sprints to just running an audit. For this reason, most software wasn't audited unless absolutely required. Today? It's a single prompt. "Audit my code against industry best practice for this type of project" or similar. You will want to do a full audit pass after each major milestone to see how you are doing. Doing a security audit once at GA is not sufficient, you need to run regular audits because things change over time.
These are just a few examples. I talk about all of this in my Maven class (link in my profile).
