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.
"Make me Minecraft"
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.
Here's my prompt.
> 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.
!Image 1: Stelexcraft terrain with the F3 debug overlay
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:
- Creative (default) and Survival modes
- Infinite world in X and Z, 128 blocks tall, sea level at y=62, random seed per world
- 51 block types
- Pigs, sheep, cows and zombies
- 14 crafting recipes
- 73 procedural textures and 71 synthesized sound clips
- Render distance adjustable from 3 to 16 chunks (default 10)
- 110–155 FPS in normal play on my laptop; the lowest measured was 56 FPS
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.
Why vibe coding can be fine. Sometimes.
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.
When the vibe gets harsh.
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.
Now let's tune the orchestra
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.
!Image 2: Violinists in a string ensemble playing together in a dim concert hall
_Photo by Larisa Birta on Unsplash_
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.
What's the breakdown of responsibilities between the roles?
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.
The Resonance loop
(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).
Elicit.
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.
Organize.
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.
Architect.
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.
Plan and orchestrate.
Break the work into small, verifiable tasks, plan tests, sequence steps, and farm out independent pieces to subagents. Designate milestones and issues.
Implement together.
Work in small batches through achievable milestones. The human reviews diffs, not dumps, and steers early, while course corrections are still cheap.
Verify.
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."
Refine.
Profile, refactor, document, and feed what you learned back into the project memory so the next loop starts smarter. Exhaustively review and error-check code and non-code assets.
The dark side of resonance
The Tacoma Narrows Bridge) collapse is the textbook example of destructive resonance. (Technically, engineers will tell you it was aeroelastic flutter, not forced resonance: the bridge's own twisting fed energy back into itself from the wind, a self-exciting feedback loop. That's an even better metaphor for what comes next.) So, how can Resonance Coding be destructive?
An LLM just amplifies what it is provided. People have already rabbit-holed down crazy psychoses and conspiracies boosted by sycophantic LLMs reflecting their energy back. So, destructive resonance is something to be wary of. In Resonance Coding, you can get out of your wheelhouse easily and over-extend your confidence. If you just rubber-stamp the LLM decisions, you are exiting resonance and entering vibing again. And you could seriously harsh your vibe.
Resonance Coding needs a damping mechanism for harmful wavelets. Tests, disagreements, second opinions, and the real world need to guide the decision making or it just goes free-form and vibe-y.
Resonance Coding is slower to start, there's not that instant magical dopamine rush of "Whoa, Look what I made!". It needs real expertise. Without an expert it's just vibe coding with more paperwork. And the realities of context and memory limits means the project memory artifacts on-disk are critical to keeping the agent(s) on track with the original or current directive and plan. My AI agent reviewing and editing this wants me to mention this is "load-bearing" (groan).
Resonance Coding isn't a religion
!Image 3: Hooded monks kneel before a glowing code altar in a golden cathedral
_The Cathedral of the Golden Code. Of course it's AI generated, but you knew that. Still, it's on my bucket list to visit. It looks like it's probably in Barcelona, down the street from the Sagrada Família somewhere._
It seems like every programming fad becomes a religion. I won't even name them all, but surely you've gotten swept up or stood on the sidelines of some fad. UML. AOP. TDD (either of them). NFTs. TLAs. Vibe coding still has a place. In fact, the output of a vibe coding session can easily become the input for Resonance Coding. It could be the prototype that gets reviewed for functional, architectural and use-case/need-fit requirements to BUILD the Resonance Coding specifications. Want to get your user stories and use-cases but nobody wants to jump in and document them? Vibe code a prototype and give it to them and let them try it and tell you all the things _wrong with it_.
And Resonance Coding isn't a new thing. Lots of us have been doing this all along. I'm only writing about it (and naming it) because there IS already a difference. People are already doing the thing I'm calling Resonance Coding, but the world just lumps it all in as "Vibe Coding" but it ain't. Let's start calling it a different thing, because it really does work differently. And there's for sure some kind of spectrum between vibe and resonance. Not all projects deserve the whole gamut of Resonance. Sometimes all you need is just a little resonance on your vibe, like a little chocolate in your peanut butter will hit the spot, am I right?
At the end of the day, if someone will pay for it or depend on it or maintain it, Resonance Coding is the direction to go with agentic development.
So, are all programmers obsolete? Yeah, no. If anything it gives us new superpowers. Resonance Coding focuses the things we're the best at, understanding the big picture and how to make programs that achieve the goals, and defocuses (lovely bokeh!) all the potentially distracting bits, like getting bogged down in writing templates, assembling build tooling, making and executing tests, and grunt work that saps our energy. Domain expertise becomes more valuable, not less because the LLM amplifies whatever signal you feed it. Juniors learn faster inside a Resonance loop than inside a Vibe loop, because they see the reasoning, not just the output. Your clients are still paying for, and getting, your expert's judgment, delivered at agentic speed.
Anyone can get a textured cube field. Building the real thing means getting human and AI onto the same frequency.
Got a vibe-coding horror story or a Resonance win? I'd love to hear it. And if you have a project that needs to be built for real, not just demoed, let's talk.