← Nieuwste papers
💻 computer science

Heterogeneous Prompting and Execution Feedback for SWE Issue Test Generation and Selection

Dit artikel introduceert e-Otter++, een nieuwe testgenerator die de uitdaging van ontbrekende of incorrecte code in software engineering-issues overwint door heterogene prompting en executie-feedback te benutten om automatisch reproductietests te creëren, waarbij een state-of-the-art fail-to-pass rate van 63% wordt bereikt op de TDD-Bench Verified benchmark.

Oorspronkelijke auteurs: Toufique Ahmed, Jatin Ganhotra, Avraham Shinnar, Martin Hirzel

Gepubliceerd 2026-01-26
📖 5 min leestijd🧠 Diepgaand

Oorspronkelijke auteurs: Toufique Ahmed, Jatin Ganhotra, Avraham Shinnar, Martin Hirzel

Oorspronkelijk artikel gelicentieerd onder CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). Dit is een AI-gegenereerde uitleg van het onderstaande artikel. Het is niet geschreven of goedgekeurd door de auteurs. Raadpleeg het oorspronkelijke artikel voor technische nauwkeurigheid. Lees de volledige disclaimer

Stel je voor dat je een detective bent die een mysterie probeert op te lossen in een enorme, rommelige bibliotheek (de softwarecode). Een bezoeker (de ontwikkelaar) komt naar je toe en zegt: "Er klopt iets niet met dit boek, maar ik kan niet precies uitleggen wat, en ik heb geen specifiek voorbeeld van waar de fout optreedt."

In de wereld van software wordt dit een SWE Issue genoemd. Normaal gesproken heb je om een bug te repareren een "reproductietest" nodig—een specifiek script dat zegt: "Als je X doet, moet de bibliotheek crashen." Dit bewijst dat de bug bestaat. Maar vaak bestaan die scripts nog niet.

Dit artikel introduceert een nieuw detectietool genaamd e-Otter++. Het doel ervan is om automatisch dat "crash-script" (de test) te schrijven door alleen de rommelige beschrijving van het probleem te lezen, nog voordat de eigenlijke oplossing is geschreven.

Hier is hoe e-Otter++ werkt, uitgelegd via eenvoudige analogieën:

1. Het Probleem: De "Blinde" Detective

Normaal gesproken, als je een slimme AI (een Large Language Model) vraagt om een test te schrijven, probeert het te gokken. Als je het één keer vraagt, kan het ernaast zitten. Als je het 10 keer vraagt met exact dezelfde instructies, geeft het je misschien wel 10 licht verschillende versies van dezelfde foute gok. Het is alsof je een vriend vraagt een film te beschrijven die hij slechts één keer heeft gezien; als je het hem 10 keer vraagt, herhaalt hij misschien gewoon steeds dezelfde fout.

2. De Eerste Truc: "Heterogene Prompting" (Het Kostuumfeestje)

Om betere gokjes te krijgen, vraagt e-Otter++ de AI niet simpelweg 10 keer hetzelfde. In plaats daarvan verandert het de manier waarop de vraag wordt gesteld, alsocht de AI in verschillende kostuums te steken of vanuit verschillende perspectieven te laten kijken.

  • De "Maskers": Stel je voor dat de AI naar een puzzel kijkt. Somser dekt e-Otter++ delen van de puzzel (de code-context) af, zodat de AI moet gokken op basis van minder informatie. Andere keren laat het juist specifieke stukjes zien. Dit dwingt de AI om het probleem op een andere manier te bekijken.
  • De "Morphs": Stel je voor dat de bugrapportage geschreven is in verwarrende jargon. e-Otter++ vraagt de AI om het rapport in verschillende stijlen te herschrijven:
    • De "Standardizer": Verandert een rommelige notitie in een formeel, gestructureerd rapport.
    • De "Simplifier": Verwijdert verwarrend technische jargon om het makkelijk begrijpelijk te maken.
    • De "Dropper": Verwijdert specifieke codefragmenten die misleidend kunnen zijn (zoals de AI vertellen een tool te gebruiken die de bibliotheek eigenlijk niet heeft).
    • De "Pre-Thinker": Vraagt de AI eerst een oplossing te raden, om die gok vervolgens te gebruiken om de test te schrijven.

Door deze "Masks" en "Morphs" te mengen, genereert e-Otter++ een enorme, diverse poel van potentiële tests. Het is alsof je 10 verschillende mensen vraagt een plaats delict te beschrijven, maar je geeft elk persoon een andere set aanwijzingen en een andere manier van spreken. Dit vergroot de kans dat ten minste één van hen het goed heeft.

3. De Tweede Truc: "Execution Feedback" (De Proefloop)

Zodra de AI een test genereert, vertrouwt e-Otter++ deze niet zomaar. Het voert de test uit op de oude code (de buggy versie).

  • Het Doel: De test moet falen. Maar het moet falen om de juiste reden.
  • Het Probleem: Soms faalt de test door een stomme fout (zoals een typefout), en niet door de eigenlijke bug.
  • De Oplossing: e-Otter++ heeft een "Critic" (een andere AI) die naar de fout kijkt. Als de test faalde om de verkeerde reden, zegt de Critic: "Nee, dat is niet de bug. Hier is de specifieke regel die fout is, en hier is extra code waar je naar moet kijken." Vervolgens herschrijft het systeem de test met deze nieuwe informatie. Het blijft deze lus herhalen totdat de test precies faalt zoals de bugbeschrijving dat zou moeten doen.

4. De Derde Truc: De "Surrogate" Patch (De Dummy Fix)

Hier is het moeilijkste deel: Om te weten of een test goed is, moet deze slagen op de nieuwe code (de fix). Maar de fix bestaat nog niet! Hoe kies je dan de beste test?

e-Otter++ gebruikt een slimme workaround:

  1. Het vraagt een ander AI-systeem (genaamd Agentless) om een heleboel nep-fixes (surrogate patches) te genereren. Deze zijn niet perfect, maar ze komen wel in de buurt.
  2. Het draait alle kandidaat-tests tegen deze nep-fixes.
  3. Als een test slaagt op de nep-fix, is het waarschijnlijk een goede test.
  4. Ten slotte kiest het de enkele beste test op basis van welke test de belangrijkste delen van de code het meest dekt.

De Resultaten: Een Grote Sprong Voorwaarts

Het artikel testte dit systeem op twee belangrijke benchmarks (TDD-Bench en SWT-bench).

  • Vorige Beste: De top-systemen konden een werkende test genereren in ongeveer 37% tot 38% van de gevallen.
  • e-Otter++: Door deze nieuwe trucs te gebruiken (het veranderen van de manier waarop vragen worden gesteld en het gebruik van nep-fixes om antwoorden te filteren), verhoogde e-Otter++ het succespercentage naar 63% op de ene benchmark en 52,5% op de andere.

Waarom dit Belangrijk Is

De auteurs zeggen dat dit op twee hoofdwegen helpt:

  1. Voor Mensen: Het automatiseert het saaie deel van "Test-Driven Development" (het schrijven van tests voordat bugs worden gerepareerd), waardoor het voor ontwikkelaars makkelijker wordt om bugs te bevestigen en te repareren.
  2. Voor AI Agents: Veel AI-coderingsagents vertrouwen op deze tests om te weten of ze een bug hebben opgelost. Door betere tests te bieden, helpt e-Otter++ ook andere AI-agents om hun werk beter te doen.

Kortom, e-Otter++ is een slimmere, creatievere en striktere manier om AI te vragen het "bewijs" te schrijven dat een softwarebug bestaat en is opgelost, zonder dat er eerst een mens nodig is om dat bewijs te schrijven.

Verdrinkt u in papers in uw vakgebied?

Ontvang dagelijkse digests van de nieuwste papers die bij uw onderzoekswoorden passen — met technische samenvattingen, in uw taal.

Probeer Digest →