Plan-modus is dood

Begin dit jaar geloofde ik dat planning het belangrijkste onderdeel zou worden van het bouwen van software met AI.

Mijn geloof in dit idee was zo sterk dat ik er een complete desktop-codingapp omheen heb gebouwd en gelanceerd. Nuanced ontstond vanuit de observatie dat AI de snelheid en het volume van codegeneratie radicaal had verhoogd, maar dat de interfaces die nodig waren om dit nieuwe werktempo te ondersteunen, nog niet waren meegegroeid.

De aanpak van Nuanced met betrekking tot planning is mislukt, maar het heeft me ook laten inzien dat plan-modi in bredere zin niet langer nuttig zijn. Historisch gezien dienden plan-modi twee doelen: (1) ze gaven instructies die nauwkeurig genoeg waren voor een agent, en (2) ze hielpen mensen te begrijpen wat ze aan het bouwen waren.

Ik denk dat punt 1 snel overbodig wordt naarmate modellen beter worden. Ik denk dat punt 2 belangrijker is dan ooit, maar plan-modi zijn de verkeerde abstractie hiervoor, zeker nu het aantal parallel draaiende agents toeneemt.

Waarom ik Nuanced bouwde

Het product dat ik wilde bouwen, beantwoordde uiteindelijk een vraag die volgens mij nog steeds relevant is en altijd relevant zal blijven: hoe behouden mensen een coherent mentaal model van een softwaresysteem terwijl machines het sneller veranderen dan mensen de wijzigingen kunnen inspecteren?

Modellen kunnen in enkele minuten duizenden regels code schrijven, wat betekent dat je een enorme onderhoudslast ervaart voordat je überhaupt hebt nagedacht over wat je bouwt of waarom. Dit maakte het moeilijk om na te denken over het gedrag en om onjuiste aannames te debuggen die voortijdig in code waren vastgelegd.

Hoewel het gemak van het genereren van code op deze manier een grotere dopamine-beloning triggerde, versluierde het het oncomfortabele werk van het begrijpen waarom het bouwen van iets ertoe deed, of het überhaupt wel zinvol was, en het rigoureus evalueren van product-, design- en infrastructuurdecisies. Vaak had ik een product voordat ik bewust enige productbeslissingen had genomen. Als ik de architectuur onvoldoende specificeerde, nam de agent de vrijheid om die gaten in te vullen, zelfs als de manier waarop hij abstractiegrenzen trok later problemen voor mij veroorzaakte. Deze misverstanden over bedoeld gedrag en ontwerp plantten zich voort via verschillende bestanden, diep onder het oppervlak van de chat, en konden gemakkelijk over het hoofd worden gezien. Zoeken naar problemen die ondoorzichtbaar waren onder dit oppervlak voelde minder efficiënt dan om vanaf het begin iets correct te hebben ontworpen.

Er was iets aan deze ervaring waardoor ik me mentaal gedistantieerd en zombie-achtig voelde, vooral nu coding-apps zoals Conductor en Codex de mogelijkheid boden om meer agents parallel te laten draaien. Ik had het gevoel dat ik me niet echt kon concentreren en niet dezelfde diepte of hetzelfde begrip kon bereiken over waar ik aan werkte als in vroeger. Dit maakte het ook moeilijker om te verifiëren of de gegenereerde resultaten correct waren.

Er was geen duidelijke, interpreteerbare trace die de verbinding toonde tussen: gebruikersprompt → beslissing van de agent → code → productgedrag.

Dit betekende niet dat ik wilde terugkeren naar de oude dagen van het bekijken van regels code of bestanden. Ik vond het redeneren over ideeën in natuurlijke taal juist makkelijker en efficiënter. Ik wilde vol vertrouwen boven de code kunnen zeilen zonder mijn begrip van hoe het systeem werkte op te offeren.

Bestaande plan-modi voelden niet collaboratief genoeg

Ik had het gevoel dat, hoewel er plan-modi bestonden, de juiste abstractie voor goed plannen nog niet bestond. Terwijl ik wisselde tussen de Claude Code CLI, Conductor en uiteindelijk Codex bij de lancering, merkte ik dat ik plannen nauwgezet aan het vormgeven en bijschaven was zonder een vaste plek om hierop te itereren. Ik deed dit door chat te gebruiken en vervolgens delen van een plan naar nieuwe berichten te kopiëren om ze te herzien (vóór de annotatiefuncties van Codex). Deze knip-en-plak-workflow voelde onhandig en maakte het zwaar om aan een idee te werken terwijl ik het huidige plan bijhield.

Ik wilde mijn plannen een thuis geven, ze verankeren in mijn algemene workflow en ze transformeren van vluchtige tekstblokken die verdwenen in de geschiedenis van het gesprek, naar een levend, ademend en persistent document. Ik wilde de plan-modus omzetten in een eersteklas primitief dat de ontwikkeling leidde, om een paar redenen:

• Ik moest kunnen nadenken over wat er moest gebeuren.
• Ik moest er zeker van zijn dat ik het nauwkeurig genoeg beschreef.
• Ik moest begrijpen wat er was gedaan.
• Ik moest begrijpen wanneer dingen misgingen en waarom.

De droom realiseren

Ik dacht na over mijn ideale workflow en besloot deze tot leven te wekken door deze te coderen in een product. Nuanced stelde je in staat om threads op te starten, waarbij elke thread een chatgesprek was. Je besprak wat je wilde bouwen, het systeem bracht onduidelijkheden en beslissingen naar voren waar jouw input voor nodig was, en samen kwamen jullie tot een persistent plan voordat de implementatie begon. Daarna voerde Nuanced het plan uit, waarbij werd gewaarborgd dat de gegenereerde code voldeed aan je eisen.

Ik wilde een end-to-end pipeline die begon bij de intentie en doorliep tot aan de implementatie, review en verificatie. Ik zag het meer als een prothese voor de menselijke geest (of mijn ADHD-geest) dan simpelweg als nog een coding-app; het was ontworpen om zowel te instrueren als om me te helpen bijhouden wat er aan de hand was.

Waarom ik me vergiste

Het is niet zozeer dat mijn ideeën over de gaten in bestaande tools of hoe de SDLC (Software Development Life Cycle) veranderde onjuist waren, maar dat onze implementatie niet de oplossing leverde die we verwachtten. Dit kwam omdat:

1. Ik plannen (het proces) verwarde met een plan (het document).
2. Modellen echt goed werden.
3. Niemand AI-gegenereerde tekst wil lezen.
4. We plannen en bouwen op een manier scheidden die disruptief was.

Plannen $\neq$ een plan

Het eerste dat we leerden, was dat we plannen hadden verward met een plan. Dat zijn eigenlijk niet dezelfde dingen. Mijn aanname was dat de ruimte om grondig over iets na te denken voordat het werd geïmplementeerd waardevol was. Ik dacht ook dat het behouden van dat denkproces in een groot gestructureerd artefact waardevol zou zijn naarmate het project evolueerde. Maar vroege gebruikers hadden verrassend weinig behoefte aan die specificatie.

Modellen zijn echt goed geworden

Naarmate modellen beter werden in het begrijpen van grote codebases via context en geheugen, blonken ze uit in het verkennen van een repository en het maken van redelijke aannames. De noodzaak om hen expliciet te instrueren om een goed doordacht resultaat te produceren, was gekrompen.

Ik had oorspronkelijk niet gedacht dat modelcapaciteit in concurrentie zou staan met het ontwerpen van een betere interface voor menselijk denken, maar in veel opzichten was dat het geval. Elke beslissing die het model betrouwbaar zelf kon nemen, was namelijk één beslissing minder die naar boven gehaald hoefde te worden.

AI-gegenereerde tekst is pijnlijk om te lezen

De specificatie bevatte meer informatie zonder meer duidelijkheid te scheppen. Dit kwam omdat onze specificaties lang waren. Ze legden belangrijke beslissingen vast en bevatten veel context die nuttig leek, maar het probleem was: ze waren AI-gegenereerd. Er is iets aan het tempo en de overmatig gestructureerde aard van AI-gegenereerde tekst dat het erg moeilijk maakt om te lezen. Mijn ogen gleden er steeds overheen.

In plaats van te reageren op deze ontdekking door de specificatie te schrappen, bouwden we een 'Spec Tour' om dit op te lossen. We dachten dat Spec Tour, in plaats van iemand te vragen het hele document te absorberen, hen door de belangrijkste delen kon leiden. Maar dat voegde alleen een extra laag complexiteit toe: meer tekst op mijn scherm die om aandacht vroeg. Als we een kortere representatie van de specificatie moesten genereren om deze bruikbaar te maken, wat was dan het nut van het volledige document in de eerste plaats?

We splitsten een proces dat continu had moeten aanvoelen

Onze workflow was te lineair en sequentieel. Ons proces zag er ongeveer zo uit: chat → verduidelijken door vragen te beantwoorden → specificatie genereren → specificatie reviewen → specificatie herzien → goedkeuren → implementeren → code reviewen.

Echt denken werkt niet op deze manier, en de scheiding tussen deze delen voelde artificieel en geforceerd. Meestal begrijp je een deel van het probleem, probeer je iets, de initiële generatie leert je iets nieuws, wat je van gedachten kan doen veranderen, waarna je iets anders probeert. Elke stap legt een nieuwe vraag bloot. Plannen en bouwen zijn met elkaar verweven en ontstaan organischer dan plan-modi toelaten, zeker zoals we het in Nuanced hadden gebouwd. Onze interface dwong gebruikers om voortijdig te "stoppen met denken" zodat ze konden beginnen met bouwen. Zodra de implementatie begon, voelde het terugkeren naar de eerdere chat-gebaseerde redenering als achteruitgaan in de workflow. Er was geen weg terug omhoog in de waterval.

Wanneer je kijkt naar hoe Codex momenteel werkt, verdwijnt de grens tussen planning en uitvoering omdat ze in één proces samenvloeien. Voorheen profiteerden coding-agents van een workflow waarbij mensen het volgende deden: plan → goedkeuren → uitvoeren.

In die tijd waren de kosten van het gaan in de verkeerde richting aanzienlijk hoger. Maar naarmate agents beter werden in het begrijpen van systemen, werden ze ook beter in het autonoom handelen en het testen van hun eigen werk. Ze zijn ook goed in het herzien van hun aanpak na het inspecteren van het resultaat. Dit maakt een andere loop mogelijk: begrijpen → handelen → inspecteren → verduidelijken → aanpassen → opnieuw handelen.

Er vindt nog steeds een enorme hoeveelheid planning plaats binnen die loop, maar dat hoeft niet noodzakelijkerwijs te verschijnen als een document genaamd "het plan". Ik denk dat de grootste fout die ik maakte, was het plan veranderen in een artefact in plaats van een proces te ontwerpen voor verbeterd menselijk begrip.

Plan-modus en bouw-modus waren een vreemde scheiding

Nuanced had een plan-modus en een bouw-modus, en gebruikers konden met beide beginnen. De plan-modus produceerde altijd een specificatie, terwijl de bouw-modus gebruikers niet dwong tot een specificatie en gebruikt kon worden voor kleinere taken waarbij een specificatie niet gerechtvaardigd was.

Maar de scheiding tussen deze modi was ongemakkelijk en vereiste dat de gebruiker zichzelf de meta-vraag stelde of een taak planning verdiende, en vervolgens onthouden om de plan-modus te activeren via een knop of sneltoets. Dit voelde als het soort onderscheid dat AI voor je zou moeten maken op basis van de context die het al heeft; het onthouden in welke modus je moest zijn, voelde als een toename van de cognitieve belasting.

Deze realisatie gaf me het gevoel van de 'midwit-meme': de eenvoud van een chatinterface waarin planning naar behoefte werd gedaan in plaats van standaard, was eigenlijk best geweldig.

We hebben het begrip-probleem nog geleden niet opgelost

Nadenken over wat er gebouwd moet worden, waarom het ertoe doet en het evalueren van beslissingen blijft belangrijk. Mensen moeten een coherent mentaal model opbouwen van wat er gaande is, maar ik denk niet dat een grote hoeveelheid AI-gegenereerde tekst de juiste interface is daarvoor. Beslissingen uitwerken in chat voelt intuïtiever, maar het bijhouden van dat begrip terwijl het systeem verandert, is nog steeds een open probleem.

Dat probleem wordt complexer wanneer je gaat van vijf agents naar honderden. Bijhouden kan niet betekenen dat je elk gesprek leest en probeert een uitleg voor elke codewijziging te prompten. Agents moeten de weinige plekken identificeren waar menselijke aandacht de grootste impact kan hebben, en voldoende context bieden om die aandacht nuttig te maken.

We hebben nog steeds niet opgelost hoe we mensen kunnen helpen georiënteerd te blijven terwijl honderden steeds capabelere agents tegelijkertijd een systeem veranderen. Maar ik denk dat het diepere probleem — hoe mensen systemen begrijpen, navigeren door complexe informatiehiërarchieën en krachtige tools gebruiken — een blijvend probleem is. Interfaces blijven veranderen samen met de technologie die ze aandrijft; de noodzaak om complexiteit begrijpelijk te maken, doet dat niet.