Or: How I Got Claude to Transplant Gesture Controls from a 3D Visualizer Into My Chat App
Let me tell you about the development pattern that’s completely changed how I build features. Last week, I had a broken chat application with a settings modal that wouldn’t close. I also had this completely unrelated 3D dimensional visualizer with killer gesture controls — you know, wave your hand to navigate, pinch to select, that sort of thing.
The old me: Would’ve spent days extracting, refactoring, and building a proper gesture library.
The new me: Threw both files at Claude and said, “Take the gesture controls from file B and weld them into file A. Don’t break anything else.”
Twenty seconds later, I had a fully functional chat app with gesture controls.
Welcome to Code Welding — the art of using LLMs to merge features from completely unrelated codebases.
The Pattern That Changes Everything
Code Welding isn’t about asking an LLM to write new code. It’s about using AI to perform surgical feature transplants between codebases that have absolutely nothing in common.
Here’s the mental model:
- Traditional Development: Build features from scratch or carefully refactor shared code
- Copy-Paste Programming: Grab code and hope it works (spoiler: it doesn’t)
- Code Welding: Use an LLM as your surgical assistant to transplant working features between alien codebases
Think of it like organ transplants, but for code. The LLM is your surgeon, handling all the complex vascular connections while keeping both patients alive.
How Code Welding Actually Works
Step 1: The Donor and Recipient
You need two things:
- The Donor — A working codebase with the feature you want
- The Recipient — The codebase that needs the feature
In my case:
- Donor: A 3D visualizer with MediaPipe gesture controls (1,500 lines of wild Three.js code)
- Recipient: A React-ish chat application (5,000 lines of messaging logic)
These files shared literally nothing. Different frameworks, different purposes, different everything.
Step 2: The Prompt Engineering
This is where the magic happens. You don’t ask the LLM to “add gesture controls.” You give it surgical instructions:
Take the gesture detection system from iframe-tunneler-10.html,
specifically the detectGesture() and hand tracking logic.
Transplant it into index.html's chat application.
Map these gestures to these existing functions:
- Point up → scroll up
- Point down → scroll down
- Peace sign → new chat
- OK sign → send message
Keep ALL existing functionality intact.
Output the COMPLETE modified index.html.Step 3: The Weld Points
The LLM identifies where to attach the foreign code. It finds the natural connection points — what I call “weld points” — between two completely different architectures.
Watch what happened with mine:
javascript
// The LLM created this bridge class
class GestureManager {
constructor(uiController) {
this.ui = uiController; // Weld point #1: Existing UI
// ... gesture setup code from visualizer
}
executeGesture(gesture) {
// Weld point #2: Map gestures to existing methods
switch (gesture) {
case 'point-up':
document.getElementById('chat-messages').scrollBy({
top: -200,
behavior: 'smooth'
});
break;
case 'peace':
this.ui.createNewChat(); // Using existing method!
break;
}
}
}The LLM understood both codebases well enough to create perfect adapters between them. It’s like it built custom surgical shunts between incompatible organs.
Why This Is Revolutionary
1. Speed That’s Actually Insane
I went from idea to implementation in minutes, not days. Not because I’m fast, but because I’m not doing the work. The LLM is handling thousands of micro-decisions about integration.
2. Cross-Pollination of Ideas
You can grab features from ANYWHERE:
- Want the smooth scroll from that Apple marketing page? Weld it into your docs.
- Love the particle effects from that game? Weld them into your dashboard.
- Need voice commands from a smart home app? Weld them into your spreadsheet.
3. No Sacred Cows
Traditional development makes us precious about architecture. Code Welding doesn’t care. That gesture system was built for 3D visualization? So what. It works in a chat app now.
The Code Welding Playbook
Here’s my exact process:
1. Identify the Feature
Find something cool that works. Don’t worry about how it’s implemented. Just make sure it actually works in its current context.
2. Document the Behavior
Write down exactly what the feature does:
- “Detects hand gestures using webcam”
- “Maps specific gestures to specific actions”
- “Shows visual feedback when gesture is recognized”
3. Map the Integration Points
Tell the LLM exactly how to connect the features:
When peace sign detected → call createNewChat()
When pinch detected → call archiveCurrentChat()
When fist detected → call toggleSidebar()4. Preserve Everything Else
This is crucial. Your prompt must emphasize:
Keep ALL existing functionality.
Do not remove any features.
Only ADD the gesture system.5. Test the Weld Points
The LLM will create connection points. Test them individually:
- Does gesture detection work?
- Do the mapped functions fire?
- Did anything else break?
Real Examples That Shouldn’t Work (But Do)
Music Visualizer → Email Client
- Welded audio reactive animations into Gmail
- Emails now pulse to background music
- Why? Because reading email is boring
Game Engine Physics → Todo App
- Tasks now have gravity and collision
- Completed tasks literally fall off the screen
- Overdue tasks get heavier and sink
3D Shader Effects → Markdown Editor
- Text now has real-time ray marching effects
- Code blocks look like they’re carved from marble
- Headers cast actual shadows
These aren’t jokes. These are real welds I’ve done. They work.
The Gotchas (Learn From My Pain)
Version Conflicts
- The donor uses React 16, recipient uses React 18
- Solution: Tell the LLM about version differences upfront
Hidden Dependencies
- That cool feature needs THREE.js but your app doesn’t have it
- Solution: Let the LLM inline just the needed parts
Event System Conflicts
- Both codebases want to own window.onload
- Solution: Prompt the LLM to namespace everything
Performance Bombs
- That particle system runs at 60fps, your form doesn’t need that
- Solution: Add throttling instructions to your prompt
When NOT to Code Weld
Let’s be real — this isn’t always the answer:
Don’t weld when:
- You’re building critical infrastructure
- Performance is more important than features
- You need deep integration with existing systems
- The feature needs to be maintained long-term
Do weld when:
- You’re prototyping
- You need to test if users even want the feature
- The feature is for fun/delight
- You need something NOW
The Prompt Template That Always Works
I have two files:
1. [DONOR FILE] - Contains [FEATURE DESCRIPTION]
2. [RECIPIENT FILE] - Needs the feature added
Take the [SPECIFIC FEATURE] from the donor file.
Integrate it into the recipient file by:
- Creating a new [CLASS/MODULE] to contain the feature
- Mapping these donor functions to these recipient functions: [MAPPING]
- Preserving ALL existing functionality in the recipient
- Adding these integration points: [INTEGRATION POINTS]
Output the COMPLETE modified recipient file.
Maintain all existing code structure and functionality.The Future Is Already Here
I’m seeing developers use Code Welding for things I never imagined:
- Feature Shopping: Browse GitHub, find cool features, weld them into your app
- Cross-Platform Welding: iOS feature → Web app, no problem
- Time Travel Welding: Modern features into legacy codebases
- Language Welding: Python ML model → JavaScript frontend (yes, really)
We’re entering an era where features are portable. Where any code that works anywhere can work everywhere.
Your First Weld
Want to try this? Here’s a starter challenge:
- Find any app with a feature you love
- View source, copy the whole file
- Take your current project
- Ask Claude/GPT-4 to weld them together
Start small. Maybe grab a tooltip implementation and weld it into your CLI tool. Or take a loading animation and weld it into your terminal.
The Philosophical Shift
We’ve been taught that code should be modular, reusable, properly abstracted. Code Welding says: “What if we just… didn’t care?”
What if, instead of building perfect architectures, we just grabbed working features and welded them wherever we needed them?
What if every piece of working code became a potential feature for every other piece of code?
What if the LLM could handle all the messy integration details while we focus on what we actually want to build?
This is the future I’m building toward. Where every developer becomes a curator of features rather than a writer of code. Where the question isn’t “How do I build this?” but “Where has this already been built?”
What will you weld first?
