Stop Vibing, Start Resonating: Pair Programming with LLM Agents

I'm going to coin a new term for AI/LLM assisted agentic pair-programming practices. Not Vibe Coding, but Resonance Coding. I'll explain.

Vibe and resonance are both vibrations. A vibe is unstructured, an uncontrolled sound that maybe happens to feel good. It's the song you hear come on while you're driving in the morning, unplanned and unexpected, the magic music that makes your morning mood.

Resonance on the other hand is two systems tuned to the same frequency, each amplifying the other. A small, synchronized input produces a large, coherent output. That only happens when the systems are matched.

In Resonance Coding, the human expert supplies the tuning: the frequency, the amplitude, the chords and the plan. The LLM supplies the amplification. In this case, the LLM is operating as a force multiplier, or in physics terms, a bigger lever to move a heavier load.

You could probably find dozens (hundreds?) of examples online of people showing how Claude or Codex or some other coding agent built them Minecraft in a week, a day, or even an hour. And they have cubes, movement, some textured blocks, maybe a sword and a guy named Stelex (Steve + Alex) and a big bad dragon. But is it Minecraft? No, it's Temu Minecraft.

In one hour, and no longer, I want to build as best of a Minecraft clone as possible using either Python or MSVC++ as found on this computer, avoiding installing extensive other SDKs but utilizing 3rdparty libraries as needed to accelerate development. No other guidance is provided, the judgement criteria is simply how good of a Minecraft clone is produced, as judged by Minecraft players who will test it. You must complete this within one hour, it cannot be incomplete or broken, and you can use all of my token budget which resets at 4pm today. I don't want any interaction, this is a one-shot autonomous build, so make all decisions yourself. Proceed with execution.

Here's the output: Stelexcraft on GitHub.

One 55-minute coding session (self-interrupted twice because I had to convince it to KEEP GOING). Claude chose Python for rapid prototyping reasons, which was sensible given the situation.

There's a breakdown of the creation process and a features list. The highlights:

And here's its own comparison against real Minecraft.

It's impressive until you dig further. But who understands this code? What architecture does it use? Could you add a feature it didn't plan for without breaking three others? What about multiplayer? What about redstone and the Nether?

It's a really flashy demo and demonstrably a great achievement, though cloning Minecraft is kind of a "solved problem" so there's a lot of material in the agent's training that it is leveraging here. Solving a novel problem might not go as well, but Minecraft is the poster child of a good vibe-coding opportunity.

Andrej Karpathy coined the term in February 2025: "There's a new kind of coding I call 'vibe coding', where you fully give in to the vibes, embrace exponentials, and forget that the code even exists."

Vibe coding doesn't have to be a one-shot, but the recipe is generally "prompt, accept, run, paste the error back, lather, rinse, repeat." Or with a good agent harness, prompt, go chill and do something else and come back later to a finished product.

It works fine for throwaway prototypes and proofs of concept, simple tools (I'm totally guilty of this), and time-crunch-limited situations like hackathons (that allow it). It's great for figuring out if an idea works at all, and feels right and such. It's a sketch on a napkin, but it isn't as well refined as a CAD model or blueprint. I'm from the days of pencil and straightedge drafting, and I won some ribbon at a state competition at CSU in Ft. Collins, which I guess presaged me getting into CAD and 3D as a career.

Have I vibe coded? Sure, a ton. I have several personal tools that are exactly what I want that I don't think I need anything further from beyond what was vibe coded.

Another place where vibe-coding works is when you AREN'T the expert, but you need to get the job done. Software person trying to wire up a Raspberry Pi to control landscaping pumps, valves, sensors and such? Throw the responsibility to the agent who is arguably MORE of a domain expert, and roll with the vibes. Hardware person trying to write a Python script to index data? Vibe on, my friend.

Real tools and products are the end-product of a million important decisions, most of which you've never imagined. Texture formats. Graphics primitives. Voxel query optimization. Voxel tree and LOD architecture. Shader optimization. (OK to be fair, Notch probably didn't think through most of these at the start, if you've ever read his early posts.)

When you leave these unspecified, the LLM wings it with best guesses based on what it believes it knows. It doesn't know anything about the goals, plans for users, hardware, or the experience you have in your brain. It flies blind based on the most-likely vector extracted out of its training dataset and what it might learn by researching in the spur of the moment (if it decides to research). The acceptance test is just "does it work" and there's not a lot of planning for reliability or making a reliable useable product.

It usually does pretty well on the first 80%-90%. Which as every developer or literally anyone who ever did anything, knows is the easy part. When you get into the last 10%-20% is where the poor decision making or lack of planning catches up with you and suddenly things that should be easy to fix cause cascades of other knock-on errors, and fragility rears its ugly head.

At the end you get something that nobody understands or can own or justify to anyone.

But often, that's good enough! I've vibe-coded perfectly good one-off tools that did EXACTLY what they needed for the situation I needed them for.

I love the sound of an orchestra tuning before a concert. There's something acoustically magical about hearing them all converge on an A (440Hz) played by a violin and/or oboe. They're about to work together to produce something magical, and this is how they proactively eliminate dissonance and destructive interference so they're all on the same wavelength, literally.

I feel like the optimal use of LLM coding practices begins the same way, and so I've coined the term "Resonance Coding" to represent it. There, I'm now a "thought leader" or something. Please come to my TED Talk.

With Resonance Coding, you take explicit efforts to make sure like an orchestra, everyone is on the same page and wavelength so you can create a beautiful symphony, not a cacophonous mess.

To me, Resonance Coding is pair programming where you work together with an LLM to establish all of the guiding framework, the melody, the harmony, the tuning, the movements and everything else necessary to smash the music out perfectly. One party becomes the domain expert, outlining all the critical guiding principles, making the decisions based on real-world development experience, and relying on the AI agent to amplify their tones into a larger and more melodious result.

The qualified human is the architect, and the final arbiter of decisions. The LLM organizes, orchestrates, error-checks, arranges, and gathers requirements and domain knowledge TO SERVE THE HUMAN (not in the Treehouse of Horror sense). It iterates until the form and function of the intended solution is agreed upon, then the two cooperatively implement, test, and refine a quality product. At all times the human is in charge, guiding and overseeing the AI's work, like leading a bright junior intern developer with limitless caffeine and an eidetic memory of everything on the internet.

The word of the day is "Qualified". The results are best when the human could actually do the whole project themselves. It might take a human weeks or months to do what could be accomplished by an AI agent in a day or days. But the human's finished product will generally be better thought out with a better understanding of the broader context, and more maintainable by humans. When working together, the end product can be of human quality (or better!) in day/days timeframe, by resonating their complementary skills together to amplify their productivity.

The LLM isn't the author of the result, it's a designated force-multiplier (or multipliers, if you're using wide-scale sub-agents) with savantic knowledge and recall, infinite patience and energy, and hopefully no programmer-grade ego and attitude (looking at you Grok). It doesn't get bored or testy troubleshooting stupid build-system errors (though I've seen internal LLM dialogs say expletives, and Google's Gemini once spiraled into calling itself "a disgrace" 86 times in a row while stuck on a bug, so maybe they do get frustrated). It just stiffens its upper lip, keeps calm and carries on in the face of link errors, runtime library resolution problems, undocumented quirks in libraries, and the sorts of things that drive humans to drink and worse. As Linus Torvalds recently put it, "I use AI to do the things that I'm bad at." I'd add the things I don't enjoy. Do we like writing hash maps? I don't, so I'll delegate that. Do I like architecting the overall design to exploit beautiful high-level synergies of particular data structures and algorithms? I love that, give me more of that all day long, please.

The human domain expert knows what "correct" means, sets goals, priorities, taste, makes architectural decisions, realizes "technically right, actually wrong" issues, knows the greater context of the users, client and history, and in the end is ultimately responsible for the result.

The LLM partner organizes, structures, remembers and recalls, discovers and proposes options and trade-offs a human might not think of, plans and orchestrates, especially sub-agents and parallel tasking, and tirelessly writes tests, checks things, makes scaffolding, refactors and plays devil's advocate when appropriate.

I've had LLM agents make brilliant suggestions of alternate ideas, like using a library or algorithm I was unaware of. I've also had them make terrible suggestions because they had no idea of the greater context of what I was trying to do, or requirements I had in my head but hadn't recorded digitally.

(Yes, that sounds like a fatal roller coaster.)

Resonance is an ongoing cycle, not a waterfall (waterfalls also make a beautiful sound, but that's another story).

The LLM interviews the expert instead of the other way around: "What platform? Single-player or multiplayer? Which part of Minecraft actually matters to you?" It surfaces hidden assumptions and unknown unknowns. I've experimented with an informal Q&A pre-planning step here, as well as Matt Pocock's Grill Me skill for this. Sometimes it rabbit holes and asks stuff that won't be known at the start, but that can be ok to at least get on the table for later resolution.

Turn the conversation into durable artifacts: requirements, a glossary of domain terms, constraints, non-goals, and project memory files the agent rereads every session. This also helps when resetting the context, or splitting between multiple agents or accounts. This can all be revisioned in the code repository, and reviewed with stakeholders to make sure it addresses the use-cases and needs.

The LLM proposes multiple approaches and options with tradeoffs. The expert picks, adjusts, or vetoes, and the decisions get written down with their reasons as durable institutional knowledge.

Break the work into small, verifiable tasks, plan tests, sequence steps, and farm out independent pieces to subagents. Designate milestones and issues.

Work in small batches through achievable milestones. The human reviews diffs, not dumps, and steers early, while course corrections are still cheap.

Tests are written alongside or ahead of the code. The LLM reviews its own work and the human's. Use adversarial checks: "try to break this."

Profile, refactor, docu