Voor ontwikkelteams · AI in de praktijk

Een AI-taak meten tot aan acceptatie

Een praktisch overzicht van modelgebruik, herstel en beoordeling helpt een ontwikkelteam werkstromen met programmeeragents te vergelijken en lacunes in het kostenbeeld te vinden.

DevmojosOngeveer 3 min leestijdGeschreven met ondersteuning van AI

Conceptuele illustratie, AI-gegenereerd: één werkonderdeel passeert een testpoort en een beoordelingsboog, gaat terug voor herstel en bereikt acceptatie. Geen gemeten procesverloop.

Een programmeertaak kan modelaanroepen verbruiken tijdens de implementatie, bij een nieuwe poging na een mislukte controle en bij verder werk tijdens de beoordeling. Het eerste gereedmeldingsbericht legt slechts één moment in dat traject vast. Een bruikbare vergelijking volgt het werk totdat de uitkomst bekend is.

Begin met een taak waarvan iemand het resultaat kan beoordelen. Maak voor een illustratieve API-wijziging een invoerveld verplicht en test geldige en ontbrekende waarden. Spreek de verwachte antwoorden af voordat u werkwijzen vergelijkt en houd de taakgrens en acceptatiecontroles gelijk. Het onderstaande voorbeeld bevat geen benchmarkcijfers.

Een illustratieve programmeertaak doorstaat tests, krijgt wijzigingsverzoeken bij de beoordeling, wordt hersteld en bereikt menselijke acceptatie.
Illustratief taakverloop. Modelgebruik, tests, onafhankelijke beoordeling en eventueel herstel horen bij dezelfde taakregistratie. Menselijke acceptatie blijft een beslissing.
Figuur 1 als tekst

Leg het gebruik tijdens de implementatie vast. Controles en onafhankelijke beoordeling toetsen het werk. Als de beoordeling een probleem oplevert, leg dan het herstel en de uiteindelijke menselijke beslissing vast; een niet-geslaagde taak blijft binnen de scope van de vergelijking.

Volg het werk, inclusief herstel

In de interne ontwikkelpraktijk van Devmojos stelt een operator een afgebakende werkinstructie op met relevante context en acceptatiecontroles. Automatische controles toetsen de instructie voordat een uitvoerende agent begint. Die voert de toegewezen wijziging uit in een geïsoleerde projectkopie en rapporteert wat is veranderd en gecontroleerd.

Onafhankelijke beoordeling en verificatie door de operator leveren informatie voor acceptatie. Als een controle of beoordeling een probleem oplevert, blijft het herstel onderdeel van dezelfde taakregistratie. Leg de bevinding, de volgende poging en de uiteindelijke uitkomst vast. Ook een afgewezen, gestopte of opgegeven taak hoort binnen de opgegeven scope van de vergelijking.

Deze structuur rond een agent is een harness: de taakinstructies, tools, context, overdrachten en beoordeling die het werk ondersteunen. Een geslaagde test levert onderbouwing over het gedrag dat is gecontroleerd. Mensen beslissen nog steeds of het afgesproken werk aanvaardbaar is en of het wordt uitgebracht.

Zes interne ontwikkelfasen leiden van een afgesproken taak via context, modelkeuze, werk en beoordeling naar menselijke acceptatie, met terugkeerroutes.
Vereenvoudigde illustratie van de interne ontwikkelmethode van Devmojos. Beoordeling kan werk terugsturen voor herstel; een niet-geaccepteerd resultaat kan aanleiding zijn de taak te heroverwegen. Dit onderbouwt de methode en is geen gemeten besparingsvoorbeeld.
Figuur 2 als tekst

Spreek de taak af, verzamel relevante context, kies een aanpak, voer het afgebakende werk uit, controleer en beoordeel onafhankelijk, en neem dan de menselijke acceptatiebeslissing. Feedback kan terugleiden naar implementatie; een niet-geaccepteerd resultaat kan terugleiden naar de taakdefinitie.

Leg verschillende meetwaarden afzonderlijk vast

Hieronder staat een voorgesteld werkblad voor de illustratieve API-wijziging. Het is geen dashboard met metingen die Devmojos al heeft verzameld. Laat een veld onbekend als de bron ontbreekt.

Rond één taak staan modelgebruik, tools en infrastructuur, doorlooptijd, beoordeling en herstelwerk, en het geaccepteerde resultaat.
Illustratief meetkader zonder getoonde resultaten. Gebruik, infrastructuur, doorlooptijd, beoordeling en resultaat hebben verschillende eenheden. Een geldelijk totaal vereist een eigen prijs- of toerekeningsgrondslag zonder dubbeltelling.
Figuur 3 als tekst

Lees modelgebruik, tools/infrastructuur, doorlooptijd, beoordeling/herstelwerk en resultaat afzonderlijk. Het werkblad bij het artikel stelt een volledigere kostenregistratie voor; het is geen verslag van alle metingen die momenteel worden verzameld.

Registratie voor de taakEenheid of vormOpnemen
Uitkomst en acceptatiecontrolesVastgelegde status en bevindingenGeaccepteerd, afgewezen of opgegeven; de controles en beoordeling achter die status
ModelgebruikGebruikscategorieën die de aanbieder rapporteertAanroepen voor implementatie, herstel en beoordeling; benoem cachecategorieën waar die worden gerapporteerd
Geldelijke kostenValuta, met facturerings- of toerekeningsgrondslagBekende kosten van aanbieders/tools en toerekenbare infrastructuurkosten; vermeld uitsluitingen
DoorlooptijdTijd van toewijzing tot de opgegeven uitkomstWachttijd, pogingen en beoordeling, met consistente definities voor begin en einde
Menselijk werkVastgelegde tijd en activiteitVoorbereiding, beoordeling, verificatie en ondersteuning bij herstel
HerstelwerkPogingen en redenenMislukte controles, beoordelingsbevindingen, vervolgpogingen en heropend werk
Voorgestelde registratie voor de illustratieve API-wijziging. Vul velden in vanuit benoemde bronnen, maak onbekende gegevens expliciet en neem niet-geslaagd of opgegeven werk op in de opgegeven scope van de vergelijking.

Tokens, minuten en statussen beschrijven verschillende zaken. Reken geldelijke componenten om op basis van een expliciete prijs- of toerekeningsgrondslag voordat u ze optelt en voorkom dat dezelfde kosten tweemaal worden geteld. Abonnementen of lokale hardware vereisen een toerekeningsbeslissing; ontbrekende kostengegevens zijn geen bewijs van nul kosten.

Verander één onderdeel van een vergelijkbare taak

De context moet de agent de benodigde eisen, relevante code en controles geven. Een werkinstructie die een randvoorwaarde weglaat, kan herstelwerk veroorzaken. Extra materiaal moet zijn plaats verdienen door de taak te helpen. Anthropic biedt richtlijnen voor context-engineering die dit selectieprobleem bespreken.

Ook de modelkeuze hoort bij de taak. Mogelijkheden, responstijd, operationele randvoorwaarden en de moeilijkheid van het werk tellen allemaal mee. Vergelijk de pogingen en beoordelingsbevindingen naast het gebruik. Neem caching waar beschikbaar op in de gebruiksregistratie; alleen een cachetrefferpercentage toont geen verandering in de factuur aan.

Geef bij een vergelijking aan welke voltooide en niet-geslaagde taken zijn opgenomen, wat vergelijkbaar bleef en wat veranderde. Leg uitgesloten of onbekende kosten vast. Als een aanpak een bruikbaar resultaat oplevert maar meer beoordeling vraagt, moet de registratie die afweging zichtbaar maken in plaats van die terug te brengen tot een tokentotaal.

Wat onze interne praktijk aantoont

Onze interne rapportage over routering bevat geverifieerde doorlooptijden tot acceptatie, mislukte verificaties en herstelwerk. Ze toont geen volledige geldelijke kosten per geaccepteerde functionaliteit of herhaalbare besparingen bij klanten aan. Het uitgebreidere werkblad hierboven is een meetadvies. Anthropic biedt onderzoek naar harnesses dat nuttig is om verder te lezen, maar geen resultaten van Devmojos onderbouwt.

Breng één terugkerende ontwikkeltaak mee, met de huidige tools en acceptatiecontroles en het punt waarop beoordeling of herstel lastig wordt. De dienst AI Engineering van Devmojos kan beginnen met een procesbeoordeling en een afgebakend experiment met AI-gebruik, zodat uw team kan beslissen wat het behoudt.

Uw volgende stap

Ontdek AI Engineering

Bronnen

← Terug naar het gidsenoverzicht