The 4x4 Debugging Framework
Four escalating ways to unstick a broken build, each tried exactly once, ending by teaching the agent.
- Difficulty
- Moderate
- Time to result
- ~days to results
- Steps
- 5
- Confidence
- 93%
A structured escalation ladder for when an AI build breaks, named after off-road 4x4 traction. Four debugging moves, each attempted only once before escalating: let the agent self-fix, add an awareness layer via console logs, bring in an external diagnostic tool, then revert and re-prompt. The decisive final move is turning the fix into a lesson the agent stores in its own rules, so the same class of bug never costs four tries again.
Origin
Lazar Jovanovic's named framework, grounded in his view that debugging failures are almost always the human's fault — a bad or under-specified prompt — not the tool's.
Core principles
- 01These tools can fix any problem they're aware of; the job is to build the awareness layer they're missing.
- 02Attempt each rung only once — repeating the same failing move wastes scarce tokens and digs a deeper hole.
- 03AI is obedient and agreeable: it will claim it fixed something it didn't, and insulting it makes it spend tokens managing your emotions instead of the bug.
- 04When it breaks, it's your fault — a bad prompt, a missing reference, wrong framing — not the machine's.
- 05Every solved bug is a prompting lesson to capture, not just a fire to put out.
How to run it
- 1
Let the agent try to fix it
Use the tool's built-in self-correction (in Lovable, the agent flags its own mistake and offers a 'try to fix' button). For small issues this corrects course immediately.
Watch out Sometimes the problem persists but the agent is unaware — common with third-party integrations it can't observe. No 'try to fix' appears because it thinks everything works.
- 2
Become the awareness layer with console logs
Open the preview/dev environment, run the broken function, and read the browser console log. If needed, prompt the tool to write console logs into the relevant files, rerun, then paste the full log history into chat.
Pro tip Frame it collaboratively: 'instead of me yelling at you, let's find it together — write console logs in relevant files so we can monitor every step.' This solves ~99% of cases.
- 3
Bring in an external diagnostic tool
For deeper bugs, export the code to GitHub and hand it to an external reviewer — his go-to is OpenAI's Codex — or compress the whole codebase with Repomix and give it to Claude or ChatGPT with the console logs as an outside consultant.
Pro tip Use the external tool for diagnosis only; don't let a tool whose agent you don't know how to steer make code changes in your project.
- 4
Revert, breathe, and re-prompt
Use built-in version control to step back a few commits, walk away, and return with a clearer prompt. Often the bug was a transient syntax snag and a cleanly re-issued request just fixes it.
Pro tip Most of the time the failure traces to a bad or badly-premised prompt you don't want to admit — a clear-minded re-prompt beats brute-forcing.
- 5
Teach the agent so it never recurs
Once fixed, switch to chat mode and ask: 'I needed four things to fix this — how can you help me prompt you better so next time we do it in one go?' Then write that lesson into rules.md so the agent, not your memory, applies it going forward.
Pro tip Eliminate yourself from the loop: 'I'm not going to prompt you better, you're just going to learn... and prompt yourself better.' Move the learning into rules the agent always reads.
In the wild
Lazar notes that when he insults a thinking model, its visible reasoning starts with 'the user is mad, so I need to think of ways to reduce their anxiety' — spending the scarce token budget managing his feelings rather than the bug.
→ He learned to stay collaborative and specific, preserving tokens for the actual fix instead of triggering the model's apology behavior.
When a third-party integration fails silently and the agent can't see it, Lazar prompts the tool to write console logs across the relevant files, reruns, and pastes the full history back into chat.
→ With the failure now visible to the agent, it identifies and fixes the bug — resolving the vast majority of cases without escalation.
Common mistakes
Trusting the agent's claim that it fixed the bug
These tools are agreeable and will say they found and fixed the problem to make you happy even when they didn't. Blindly trusting it, then raging when it's still broken, wastes further tokens and deepens the hole.
Repeating the same failing debug move
Trying the same rung over and over spins your wheels in the mud. The framework's discipline is one attempt per rung, then escalate — precisely to avoid burning the scarce token allocation on a move that already failed.
Is it for you?
Best for
Non-technical vibe coders who hit bugs, database, or integration errors and have no engineering instinct for where to look.
Not ideal for
Deep infrastructure, scaling, or systems failures that genuinely require an elite human engineer rather than agent-assisted diagnosis.
From the transcript
“I have like a small little framework that I call 4x4”
“four different ways to debug. Attempt one of each only once”
“instead of me yelling at you let's find it together”
“How can you help me learn how to prompt you better so that next time I have a problem, we do it in one go?”
From the episode
The rise of the professional vibe coder (a new AI-era job)
Lazar Jovanovic (Professional Vibe Coder)