Vibe Coding With Claude Opus 5: What Actually Changes

What vibe coding means once the model is good

Vibe coding is describing the outcome you want in ordinary language and letting the agent produce the implementation, without you specifying the structure or reading every line as it lands.

With a weaker model that approach caps out quickly. You get something that compiles for a small feature, then it falls apart on anything with more than a couple of moving parts, so you end up specifying more and delegating less.

A stronger model raises that cap. You can hand over a larger slice of work in one go, and the session holds a longer chain of reasoning without drifting off the task. More of what comes back is usable without correction.

What does not change is the input. The model still only knows what is in its training data plus what you put in front of it. Getting better at reasoning does not make it aware of the service you renamed last quarter, the pattern your team abandoned after an outage, or the reason a particular retry lives where it does.

The failure mode shifts rather than disappearing

This is the part people miss when they upgrade models and are briefly delighted.

With a weaker model, mistakes announce themselves. The code does not compile, the test fails, the API does not exist. Feedback arrives in seconds and costs you almost nothing.

With a stronger model, output is more often correct in isolation. It compiles, the tests pass, the approach is defensible in general. And it can still be wrong for you: it introduces a second way of doing something your codebase already handles one way, it adds a dependency you deliberately avoid, it reimplements a helper that exists three directories over, it handles errors in a style that contradicts everything around it.

Those mistakes do not announce themselves. They pass review because they look reasonable, and they surface months later as inconsistency, duplicated logic, and a codebase where three patterns coexist for no reason anyone can reconstruct. Cheap failures got rarer, and expensive ones got harder to see.

The gap that no model closes

Every project has knowledge that exists nowhere the model can see. Why the payments module has its own retry policy. Which of two similar utilities is the one you actually maintain. The naming convention that only makes sense once you know the domain. The approach the team tried, reverted, and does not want proposed again.

That knowledge lives in pull request discussions, in incident write-ups, in the heads of two people, and occasionally in a stale document. A better model does not have more access to it than a weaker one. Both are working from the code in front of them plus general patterns from training.

So the same three corrections happen in every session. You explain the convention. The model adapts. The session ends. Next week you explain it again, and you pay full token price to re-establish context that has not changed since the last time you explained it.

Ground the session instead of prompting harder

The usual response is a longer prompt file: more conventions, more warnings, more context pasted at the top of every session. It works for a while, and then it becomes a document nobody updates, sent on every request whether or not it is relevant, competing for attention with the actual task.

Retrieval is the better shape. RDK indexes your code, docs, decision records, and notes from local vaults as encrypted private chunks on the RDK network. The agent searches that index when it needs specific knowledge and pulls back only the relevant chunk, so context stays lean and current instead of long and stale.

The effect on vibe coding is direct. The model stops inferring your conventions and starts reading them. It finds the existing helper instead of writing a fourth one. It sees the decision record explaining why the retry policy is unusual, so it stops proposing the fix your team already rejected.

The cost side follows. With stacked retrieval, a private index answers 40 to 65 percent of queries, the public network of published chunks adds 15 to 20 percent, and the LLM handles the remaining 5 to 10 percent as fallback, so token spend drops 80 to 90 percent. Capable models are the expensive ones, which makes the saving larger precisely when you are vibe coding on the best model available.

A working setup

Delegate in slices you can still review. A slice is a change you can hold in your head after reading the diff once. That size grows with the model, but it never becomes the whole feature.

Make the constraints explicit, especially the non-obvious ones, and make the outcome verifiable. Tests, types, and a lint pass give the agent a signal to work against so it can close its own loop instead of waiting for you to be the compiler.

Index the knowledge that keeps coming up. When you find yourself explaining the same thing to a session for the third time, that is not a prompt problem, it is an unindexed document. Write it once, index it, and every future session starts with it.

Done that way, a stronger model is a real multiplier: you delegate bigger pieces, they come back matching how your system actually works, and the code that lands is code you can still stand behind six months from now.