Stop met geld verspillen aan AI-codingtools die niet werken

U gebruikt een AI-codingassistent om software sneller te bouwen. Maar de code die het schrijft, faalt vaak bij de eerste poging. U hebt een menselijke ontwikkelaar nodig om het te repareren. U denkt dat het antwoord is om de AI meer macht te geven, zoals geautomatiseerde testtools. U hebt het mis. U bent op het punt om veel geld te verspillen.

Wat onderzoekers ontdekten

Een nieuwe studie, Reasoning effort, not tool access, buys first-try reliability in agentic code generation: an observational study, testte een veelvoorkomende veronderstelling. Zorgen extra tools ervoor dat AI-geschreven code betrouwbaarder wordt? Het antwoord is een duidelijk nee.

Het geven van AI-agents toegang tot geautomatiseerde testtools (zoals Playwright voor UI-testing) verhoogde de kosten met 42-68%. Het verbeterde niet de functionele betrouwbaarheid of kwaliteit van de uiteindelijke software. Zelfs voor interfaceproblemen waarvoor deze tools zijn ontworpen om ze op te vangen, faalden ze om te helpen.

Denk hierbij aan het inhuren van een dure proeflezer die alleen typefouten opvangt, maar belangrijke plotgaten in een roman mist. U betaalt meer, maar de fundamentele problemen blijven bestaan.

De echte oplossing was anders. De onderzoekers vonden dat het verhogen van de AI's redeneerinspanning - het geven van meer tijd om na te denken voordat het begint met schrijven - de sleutel was. Deze eenvoudige verandering verhoogde het percentage perfecte, eerste-pogingcodegeneratie van 28% naar 89%. Het reduceerde de behoefte aan menselijke interventie met vijf keer. En het voegde slechts 9-29% toe aan de kosten.

Dit is als een architect die een extra uur besteedt aan het controleren van blauwdrukken voordat de bouw begint. Het voorkomen van fouten is veel goedkoper dan ze later te repareren.

Andere kritische bevindingen:

• Eenvoudige ontwerpaanwijzingen werken. Een instructie van één alinea (bijv. "maak de UI er modern en premium uitzien") verbeterde de visuele kwaliteit evenveel als complexe, technische aanwijzingen.
• De meeste fouten zijn implementatieproblemen. 55% van de eerste-pogingfouten waren omgevingsproblemen (zoals Docker-instellingen), niet interfacebugs die testtools targeten.
• Nieuwere AI-modellen lossen dit niet op. Het upgraden naar een nieuwere versie veranderde alleen welke omgevingsfouten optreden. Alleen meer denktijd voorkwam fouten.

U betaalt waarschijnlijk voor tools die de verkeerde problemen oplossen. De meest effectieve oplossing zit al in uw AI-instellingen.

Hoe u dit vandaag kunt toepassen

Stop met het najagen van glimmende, dure tools. Begin met het optimaliseren van hoe u de AI gebruikt die u al heeft. Hier zijn vijf concrete stappen om deze week te implementeren.

1. Maximaliseer de "denktijd" van uw AI

Dit is uw meest belangrijke actie. In de configuratie van uw AI-codingassistent (zoals Claude Console, GitHub Copilot-instellingen of Cursor IDE), vindt u de parameters die de redenering of overweging controleren.

• Zoek naar instellingen zoals: temperatuur, max_tokens, redeneerinspanning of denkbudget.
• Stel ze in op hun maximale toegestane waarden voor kritieke codegeneratietaken. Dit zegt de AI dat het grondiger moet plannen voordat het een enkele regel schrijft.
• Voorbeeld: Wanneer u Anthropic's Claude in een agente workflow gebruikt, configureert u expliciet een hogere max_tokens voor de redeneerfase. Accepteer niet zomaar de standaardwaarde.

Geschatte inspanning: 15 minuten configuratie. Impact: U kunt zien dat de eerste-pogingsuccesratio verdrievoudigt.

2. Vervang complexe ontwerpaanwijzingen door eenvoudige richtlijnen

Stop met het schrijven van lange, technische specificaties voor UI-esthetiek. Het is een verspilling van tijd.

• Voor elke visuele of ontwerptaken, schrijft u een doel van één alinea in gewoon Nederlands.
• Slechte aanwijzing: "Gebruik een CSS-grid met flexbox voor uitlijning, implementeer een samenhangend kleurenschema met HSL-waarden met een primaire tint van 220, zorg ervoor dat de afstand volgt een 8px-baseline..."
• Goede aanwijzing: "Maak deze gebruikersinterface er schoon, modern en premium uitzien. Gebruik een professioneel kleurenschema, veel witruimte en zorg ervoor dat alle elementen visueel zijn uitgebalanceerd en gemakkelijk te lezen."

Deze eenvoudige verschuiving leverde een verbetering van 50% in visuele kwaliteitsscores (van 3,0 naar 4,5 op een schaal van 5 punten) in de studie.

3. Audit uw geautomatiseerde testtools voor echte ROI

U heeft waarschijnlijk geautomatiseerde testing in uw AI-workflow of ontwikkelingspijplijn. Stel uzelf een moeilijke vraag: Vangen ze de fouten die daadwerkelijk de implementatie stoppen?

• Bekijk uw laatste 10 buildfouten. Categoriseer ze: waren het functionele/UI-fouten of omgevings/implementatieproblemen (Docker, afhankelijkheden, machtigingen)?
• Als de meeste fouten in de tweede categorie vallen (zoals de studie vond), voegen uw UI-testtools kosten toe zonder uw hoofdprobleem op te lossen.
• Overweeg om te stoppen of te verminderen de investering in AI-toegankelijke testtools voor nieuwe prototypes. Wijs in plaats daarvan die begroting toe aan een robuustere omgevingsinstelling en validatiescripts.

4. Splits uw teststrategie: functionaliteit vs. omgeving

Gebruik geen enkel tool voor alles. Behandel functionele correctheid en omgevingsstabiliteit als afzonderlijke problemen.

• Voor functionele/UI-testing: Gebruik lichtgewicht, prompt-gebaseerde controles. Vraag de AI: "Lijst drie potentiële randgevallen voor deze loginfunctie." Laat het dan de test schrijven voor alleen die.
• Voor omgevings/implementatie-testing: Bouw een afzonderlijk, eenvoudig validatiescript. Dit script moet controleren op de 55% foutgevallen: zijn alle afhankelijkheden geïnstalleerd? Kan de vereiste poort worden toegankelijk gemaakt? Zijn omgevingsvariabelen ingesteld? Voer dit script voordat de AI-generate code wordt uitgevoerd.

5. Meet de eerste-pogingbetrouwbaarheid, niet de eindscore

Uw huidige metrics liegen tegen u. U meet of een functie uiteindelijk werkt na menselijke reparaties. Meet in plaats daarvan hoe vaak het perfect werkt bij de allereerste AI-poging.

• Track deze metric: (Eerste-poging geslaagde implementaties) / (Totaal AI-generatietaken)
• Stel een doel: Streef ernaar om dit percentage te verhogen door de redeneerinspanning te configureren (Stap 1). De studie toonde aan dat deze metric kan springen van 28% naar 89%.
• Deze metric vertelt u de echte kosten van AI-ontwikkeling. Een lage score betekent hoge menselijke toezicht en langzame snelheid, ongeacht hoe goed het eindproduct eruitziet.

Waar u op moet letten

Dit onderzoek is krachtig, maar heeft beperkingen. Houd deze in gedachten:

• Omvang van de studie: Het richtte zich op het bouwen van een specifiek type toepassing (een retrospectief bord). Extreem complexe, multisysteementerpriseprojecten kunnen andere patronen laten zien.
• Modelspecifieke: De kernbevindingen gebruikten Claude-modellen. Het principe van redeneerinspanning is universeel, maar de exacte configuratie-instellingnamen kunnen verschillen voor GPT-, Gemini- of open-sourcemodellen.
• Afnemende rendementen: Het verdubbelen van de redeneerinspanning zal de kwaliteit niet altijd verdubbelen. Monitor uw eerste-pogingbetrouwbaarheidsmetric om de sweet spot voor uw projecten te vinden.

Uw volgende stap

Deze week, koop geen nieuwe tool. Schrijf geen complexe aanwijzing.

Begin met 15 minuten in de instellingen van uw primaire AI-codingassistent doorbrengen. Vind en maximaliseer elke parameter die verband houdt met redenering, denken of plannen. Voer vervolgens één niet-kritieke codegeneratietaken uit en noteer of de eerste versie meer complete is.

Deze kleine, zero-kostverandering is de meest effectieve manier om de AI-betrouwbaarheid te verbeteren. Waarom betaalt u nog steeds voor tools die het echte probleem niet oplossen?

Vraag voor uw team: Wat percentage van uw AI-generate code implementeert en draait daadwerkelijk succesvol op de allereerste poging? Deel uw nummer hieronder.