Nadat de agent de taak heeft overgenomen, is het eerste dat moet worden aangescherpt de werkeenheid.

Ik heb de laatste tijd veel discussies over Agent gelezen en uiteindelijk kom ik altijd op dezelfde vraag terug: aan wie moet een werkstuk worden gegeven, hoe moet het worden verpakt voordat het wordt overgedragen en hoe wordt het geaccepteerd nadat het is geretourneerd. Als dit probleem zich eenmaal in een project voordoet, zijn het eerste dat vaak toeneemt niet de kosten van het model, maar de complexiteit van de werkeenheid. Als de taak te groot wordt gemaakt, verschijnt het model “alsof het kan worden gedaan”; de echte problemen liggen meestal in het terugdraaien, reproduceren en accepteren.

De werkeenheid moet eerst geaccepteerd kunnen worden

De afgelopen dagen, na het samenvoegen van de gefragmenteerde aantekeningen van Martin Fowler en verschillende discussies tijdens de Thoughtworks Future of Software Development Retreat, was het meest voor de hand liggende gevoel dat het gesprek tijdens de bijeenkomst oppervlakkig verspreid was, maar dat het eigenlijk maar om één ding draaide: het overhandigen van een groot stuk werk aan Agent.

De afwerking van Kief Morris is het meest eenvoudig. In verschillende sessies werd gesproken over codebeoordeling, productieongevallen, taakverdeling binnen het team en modelroutering. Ze leken over verschillende dingen te praten, maar de conclusie bleek dezelfde: mensen hebben de omvang van het ‘eenheidswerk’ aangepast. Hoe groter de eenheid is, hoe gemakkelijker het zal zijn om deze over te dragen; hoe groter de eenheid is, hoe moeilijker het zal zijn om hem te accepteren nadat hij terugkomt. Het is niet zo dat het model het niet kan, maar dat de daaropvolgende bevestigingslink het eerst niet kan volhouden.

Dit is de reden waarom harnas steeds opnieuw wordt genoemd. Contextbeheer, computationele sensoren, op eigendommen gebaseerd testen, formele methoden, dit soort dingen klinken als aanvullende hulpmiddelen, maar ze verzamelen in werkelijkheid werkeenheden. Sommige mensen beperken de agents.md tot minder dan 200 regels, niet om de vorm netjes te houden, maar om het systeem te dwingen alleen dat deel van de informatie te ontvangen dat echt nuttig is en echt kan worden gecontroleerd. De context is te los, de agent kan natuurlijk rennen; maar na het rennen weet niemand welke laag van beperkingen hij heeft ingeslikt.

Zelfhosting brengt het bedieningsoppervlak naar voren

Discussies over zelfgehoste modellen wijzen ook op hetzelfde. Nadat tokens duurder worden, de compliance-eisen strenger worden en er geen gegevens kunnen worden uitgelekt, zullen open source-modellen en lokale modellen uiteraard aantrekkelijker worden. Maar als je het model eenmaal zelf draagt, heb je ook problemen: GPU, inferentieruimte, routing, rollback, fijnafstemming en modelselectie. Dit zijn niet de modelmogelijkheden zelf, maar zij zullen bepalen of het systeem uiteindelijk stabiel is.

Dergelijke kosten worden vaak onderschat. Veel teams concentreerden zich aanvankelijk op “of het model sterker is”, maar ontdekten later dat wat echt tijd kost de stabiele overdracht van werkeenheden tussen meerdere modellen is. Wanneer je een groot model moet gebruiken, wanneer je een licht model moet gebruiken, en wanneer je eenvoudigweg een lokaal model moet gebruiken, hangt het niet af van verbale voorkeur, maar van een laag controleoppervlak die kan worden gebruikt voor afleiding en verdoezeling. Zonder deze laag van zaken zal self-hosting verschuiven van ‘het initiatief nemen’ naar ‘het zelf overnemen van de complexiteit van de exploitatie en het onderhoud’.

Simon Willison zei dat sterkere modellen kleinere modellen moesten kiezen om het werk te doen. Dit idee lijkt ook erg op wat het besturingsvlak doet. Het model zelf kent niet noodzakelijkerwijs de kostengrenzen van het team, maar het systeem wel. Het model behandelen als een bemiddelaar en het gebruiken om taken toe te wijzen, staat dichter bij echte resultaten dan het blindelings nastreven van één enkel model voor alomvattende levering.

Acceptatie en doelstellingen kunnen niet worden uitbesteed

Sam Ruby’s ‘Bring me a Rock’ bracht een ander probleem aan het licht. Het werk aan het model geven komt neer op het toevoegen van een executeur; de verantwoordelijkheid verdwijnt niet. Managers kunnen LLM gebruiken voor verkenning, en ze kunnen het eerst een aantal kandidaat-oplossingen laten uitspuwen, maar de uiteindelijke acceptatiecriteria moeten nog steeds in menselijke handen vallen. Verborgen doelen zijn het lastigst. Machtigingen, privacy, destructieve acties en contextlekken zijn vaak niet opgenomen in de oorspronkelijke vereisten.

Conformiteitstesten zijn dus vaak nuttiger dan specificaties. Specificaties zijn goed in het beschrijven van ‘wat nodig is’, en tests zijn beter in het blootleggen van ‘wat niet kan gebeuren’. Dit geldt vooral voor Agent-systemen. Het model kan de expliciete doelen heel goed compenseren, maar de impliciete grenzen moeten worden geverifieerd door middel van hardere verificatie. Zolang de acceptatievoorwaarden vage beschrijvingen blijven, zal het systeem er steeds meer uitzien alsof het op waarschijnlijkheid gokt, hoe meer de Agent doet.

Daarom beginnen codebeoordeling, incidentafhandeling en taaktoewijzing, die vroeger zeer mensachtige taken waren, nu andere vormen aan te nemen. Managers gebruiken het model rechtstreeks. Op het eerste gezicht lijkt het de efficiëntie te verbeteren, maar op het onderste niveau veranderen ze feitelijk een managementmethode: van het beheren van methoden naar het beheren van doelen. Als het doel duidelijk is beschreven, krijgt het model de kans om te werken; als het doel onduidelijk is, zal het model de dubbelzinnigheid voor anderen alleen maar versterken.

Ervaring en leesvaardigheid verbeteren nog steeds

De door Dan Davies genoemde interactie-expertise en bijdragende expertise zijn ook zeer relevant voor deze verandering. Het model kan veel materialen lezen en een goed oordeel vellen, maar om het systeem stabiel te laten zijn, moet er nog steeds iemand zijn die de specificaties kan lezen, de resultaten kan zien en weet wat er mis is. De sleutel hier is niet dat mensen met het model moeten concurreren om te zien wie slimmer is, maar dat mensen in een positie moeten blijven staan ​​die de grenzen afbakent.

Deze kwestie is eenvoudiger als het gaat om de levering van software. Nadat Agent het overneemt, zal het menselijke werk minder gericht zijn op handmatige uitvoering en meer op taaksegmentatie, grensdefinitie, acceptatieontwerp en afhandeling van uitzonderingen. Of taken kunnen worden overgedragen, bepaalt duidelijk of het daaropvolgende contextbeheer, modelrouting en toolorkestratie de moeite waard zijn. Als de eenheid niet helder is, ongeacht hoeveel lagen er zijn, zal het probleem alleen maar teruggedrongen worden.

Na het lezen van deze fragmenten de afgelopen dagen is wat mij bijblijft niet een bepaalde modelnaam, noch een nieuw raamwerk, maar een eenvoudiger oordeel: het eerste dat het Agent-systeem moet aanscherpen is niet de modelcapaciteit, maar de werkeenheid. Als de eenheid kleiner is, de acceptatie strenger en de toestemmingen strenger, krijgt het systeem de mogelijkheid om de complexiteit binnen beheersbare grenzen te houden.