veel leden van ons engineeringteam zijn begonnen met het gebruik van @AmpCode binnen en buiten cursor. het is objectief beter dan alle andere die vandaag de dag beschikbaar zijn. we hebben het ook draaien binnen de pre-commit hook (met Playwright mcp enz.) en het doet pr review assists. met orakels en subagenten zou het een van de meest indrukwekkende multi-agent systemen kunnen zijn die ik heb gezien.
Quinn Slack
Quinn Slack25 jul 2025
Veel coderingsagenten hebben een "modi"-functie die (soort van?) logisch was in een RAG of vroege agentische periode. Nu voegen ze subagenten toe zoals Amp (zoeksubagent, algemene subagenten, de orakel) en Claude Code (dat net een echt coole functie voor aangepaste subagenten heeft gelanceerd). Modi zijn zware, niet-samenstelbare UI-dropdownmenu's. Subagenten worden opgeroepen via natuurlijke taal ("gebruik het orakel om ...", "gebruik de probleemsubagent om ...", of impliciet), zijn perfect samenstelbaar en passen netjes in het conceptuele model van agentisch tool-aanroepen. Het blijkt dat modi en subagenten in wezen hetzelfde doel dienen. Subagenten zijn een strikt betere oplossing. Dus, vorige generatie coderingsagenten die een bestaande "modi"-functie hebben, staan nu voor een moeilijke keuze wanneer ze subagenten toevoegen: zowel modi als subagenten behouden (wat verwarrend en complex is), modi verwijderen (wat pijnlijk is voor hun gebruikersbasis omdat ze veel moeite hebben gestoken in het creëren van modi), of proberen het concept "modi" uit te rekken om ook subagenten op te nemen (wat ook verwarrend zal zijn). Ik ben niet jaloers op hen. Bij het Amp-team leven we in doodsangst om in deze benarde positie te belanden wanneer we verkeerd hebben ingeschat waar agentisch coderen in de toekomst zal zijn en pijnlijke productwijzigingen moeten aanbrengen. We hebben al deze fouten gemaakt met producten die we hebben gebouwd voordat Amp (en we maken en zullen veel fouten maken met Amp). Dit is waarom we een ongelooflijk hoge lat hebben om nieuwe UI-concepten toe te voegen, waarom we teamleden met sterke intuïtie prioriteit geven, en waarom we bouwen voor waar modellen en de gemiddelde ontwikkelaar over 6-12+ maanden zullen zijn, niet vandaag. In dit geval geloof ik dat deze oriëntatie ons naar de juiste beslissing heeft geleid (geen modi, alleen samenstelbare subagenten). We hebben het geluk te kunnen bouwen voor ongelooflijk slimme en open-minded/vooruitdenkende ontwikkelaars die vaak hun feedback delen en via praktisch elk kanaal behalve postduiven. We hebben zoveel van jullie goed leren kennen en begrijpen. We konden simpelweg niet zien dat een van jullie of wij echt van "modi" zouden houden. Maar toen @thorstenball subagenten en vervolgens het orakel bouwde, en zei dat je ze gewoon moest zeggen ("gebruik het orakel om ...") in plaats van ze uit een of ander dropdownmenu te selecteren, voelde het goed voor ons en voor jullie allemaal, en het voelde alsof het ook de richting was waarin de modellen gingen. Props aan hem daarvoor, en dank aan onze geweldige gebruikers voor het zien van de toekomst. Ik wilde gewoon een beetje achter de schermen delen over hoe we over deze dingen denken en waarom we misschien extreem of rigide lijken op bepaalde zaken. ...en blijf op de hoogte voor dit weekend, wanneer ik zal toegeven dat ik het verkeerd had over een van onze meest controversiële Frequently Ignored Feedback (FIFs) en het zal veranderen, dankzij een hoop feedback die het blijkt dat ik niet heb genegeerd.
8,09K