Purrx

Self-repair: let the model fix its own mistakes

Feed compiler problems back to Gemini and let it fix the deck, keeping a fix only when it has fewer problems, with a hard limit on repair rounds.

12 min+35 XPHands-on

Even with a good prompt, the model sometimes writes a slide the compiler rejects: a missing required prop, a card with so much text it overflows at 10pt, a component that doesn't exist. The compiler already describes each problem precisely. That's exactly what a model needs to fix it.

compile

3 problems

repairDeck

deck + problem list → model

compile again

1 problem

fewer? keep it

same or more? keep the old one

Repeat while there are problems, at most MAX_REPAIR_ROUNDS times.

Compile, and if there are problems, send them back with the deck. Keep a fix only if it has fewer problems, and stop after two rounds.

The loop

  1. Compile the deck. If there are no problems, you're done.
  2. Send the deck and a list of its problems ("Slide 3: <Card> needs a title prop") with repairDeck, written for you.
  3. Compile the fixed version.
  4. If it has fewer problems, keep it and loop. If not, stop and keep what you had.
  5. Never go round more than MAX_REPAIR_ROUNDS times.

Each trip round the loop is a .

Testing it on purpose

A good model often writes a perfect deck, so the repair path might never run while you test. That's why generateDeck accepts an options.compile function. The harness passes one that reports a made-up problem the first time, forcing a repair round. Swapping a dependency like this is a pattern you'll use a lot in module 11.

Key takeaways

  • Deterministic checks produce precise problems the model can act on.
  • Only keep a repair that has fewer problems, because fixes sometimes make things worse.
  • Cap the rounds: after two, more attempts cost more than they fix.

Sign in to run the exercise

Reading is free. Writing code here needs an account so we have somewhere to keep your Gemini key and the +35 XP you are about to earn.