AI Observability in ontwikkelworkflows: wat recent onderzoek echt laat zien

AI is stilletjes onderdeel geworden van het dagelijkse ontwikkelwerk. U komt het tegen in code reviews, pull requests, documentatie en al die kleine beslissingen die het werk gaande houden. Wat in veel gevallen nog ontbreekt, is helder inzicht in wat het daar nu precies doet.

Een recent paper, AI Observability for Developer Productivity Tools: Bridging Cost Awareness and Code Quality, zoomt in op dat gat. In plaats van AI te benaderen als iets dat u "gebruikt" of "niet gebruikt", laat het zien hoe u het goed kunt bijhouden—met kosten, gedrag en output inbegrepen—en hoe die data past in ontwikkelworkflows.

Teams vertrouwen tegenwoordig vaak op meerdere AI-tools tegelijk. Sommige zijn ingebed in IDE’s, andere in reviewsystemen, weer andere als losse tools. Elk genereert data, maar die komt zelden op één plek samen. Dat leidt tot een bekend beeld: u weet dat AI wordt gebruikt, maar niet wat het totaal kost, hoe vaak het wordt getriggerd, of hoe betrouwbaar de outputs echt zijn. Er is geen nette manier om gebruik aan uitkomsten te koppelen.

Het paper benadert dit als een observability-probleem. Niet in de traditionele infrastructuurzin, maar in de bredere betekenis van begrijpen hoe een systeem zich onder reële omstandigheden gedraagt.

Om dat te onderzoeken, bouwden de auteurs een systeem dat twee normaal gescheiden onderdelen combineert:

• een developergericht dashboard dat werk volgt zoals pull requests en AI-ondersteunde reviews

• een observability-laag die modelgebruik, tokens en kosten vastlegt

In plaats van naast elkaar te draaien, voeden beide hetzelfde datamodel. Juist die gedeelde laag maakt het mogelijk om AI-activiteit in context te bekijken in plaats van geïsoleerd.

De implementatie zelf is vrij rechttoe-rechtaan—FastAPI op de backend, een eenvoudige frontend en integraties met meerdere AI-providers—maar de structuur is belangrijker dan de stack.

Een van de nuttigste delen van het paper is een set patronen die uit de implementatie naar voren kwamen. Het zijn geen abstracte ideeën; ze weerspiegelen wat gebouwd moest worden om het systeem te laten werken:

• werkelijk tokengebruik rechtstreeks uit provider-API’s ophalen

• een prijsoverzicht voor verschillende modellen bijhouden

• een gedeeld telemetrieformaat definiëren

• kosten aggregeren in dashboards

• modeluitvoer valideren voordat die wordt gebruikt

• samenvattingen genereren met LLM's

• rapporten genereren op basis van verzamelde data

Gezamenlijk schetsen deze patronen hoe “AI observability” er in de praktijk uitziet. Geen enkele tool, maar een combinatie van onderdelen die verschillende stukken van het plaatje invullen.

Dit bleef niet bij een kleine demo. Het systeem is maandenlang gebruikt bij echte ontwikkelactiviteiten, inclusief AI-ondersteunde reviews en algemeen gebruik over tools heen.

Data kwam uit meerdere bronnen:

• directe API-integraties

• CLI-logs van lokale tools

• handmatige invoer waar automatisering niet mogelijk was

Die mix is het vermelden waard. Zelfs met een werkend systeem is niet alles automatisch vast te leggen.

Enkele resultaten springen eruit, vooral omdat ze cijfers geven bij zaken die vaak gegokt worden.

Token-tracking bleek zeer betrouwbaar wanneer het rechtstreeks uit provider-API’s werd gehaald. Het gerapporteerde gebruik kwam overeen met de facturatiegegevens, waardoor kostenberekeningen als nauwkeurig in plaats van benaderd konden worden behandeld.

Tegelijkertijd vertelde de outputkwaliteit een ander verhaal. Een opvallend deel van de antwoorden—29%—vergde opschoonwerk voordat ze bruikbaar waren. Dat maakt AI niet ineffectief, maar het verandert wel hoe u de bijdrage moet duiden.

Aan de performancekant handelde het systeem queries en dashboardupdates snel genoeg af om bruikbaar te zijn in het dagelijks werk. Belangrijker: het verlaagde de inspanning om gebruikspatronen te begrijpen. In plaats van alles handmatig bij elkaar te puzzelen, stond de data er al.

Een ander, meer impliciet punt in het paper is dat één enkele databron nooit genoeg is. API’s dekken een deel van het beeld, logs een ander deel, en sommige gaten vragen nog steeds om handmatige input.

Het paper poetst de scherpe randjes niet weg.

Sommige tools maken hun gebruiksdata helemaal niet zichtbaar, waardoor geautomatiseerde meting onmogelijk is. In die gevallen moeten kosten handmatig worden ingevoerd.

Validatiepipelines werken goed wanneer outputs een gestructureerd formaat volgen, maar worden minder betrouwbaar bij vrije tekst.

Prijsinformatie wordt niet automatisch bijgewerkt, dus die moet u in de tijd onderhouden. En alles wat op het parsen van logs leunt, hangt af van formaten die zonder aankondiging kunnen veranderen.

Geen van deze punten breekt het systeem, maar ze begrenzen wel hoe compleet het beeld kan zijn.

Het paper maakt één ding duidelijk: AI is geen bijzaak meer in development. Het is onderdeel van hoe werk gedaan wordt, en het gedraagt zich als elk ander component in uw leveringssysteem—het produceert output, verbruikt resources en introduceert variatie.

Dat heeft consequenties.

De meeste teams volgen hun leveringsprestatie via bekende signalen—cycle time, throughput en deployment frequency. Die blijven belangrijk, maar ze vertellen u weinig over hoe AI het werk daarachter beïnvloedt. U ziet misschien snellere reviews of kortere feedbacklussen, maar zonder zicht op AI-gebruik is het lastig te bepalen of die verbetering echt is, waar die vandaan komt of wat die kost.

De aanpak uit het paper wijst een andere richting op. Door AI-activiteit—tokens, kosten, outputs—direct te koppelen aan ontwikkelworkflows, kunt u dingen in context bekijken. Niet alleen hoe snel iets bewoog, maar ook wat aan die snelheid bijdroeg en of dat het waard was.

Dat opent concretere vragen:

• Verlagen AI-ondersteunde reviews daadwerkelijk de inspanning, of verschuiven ze die naar opschoonwerk?

• Welke delen van de workflow profiteren van AI, en welke niet?

• Hoe beïnvloedt AI-gebruik de kosten op het niveau van een team, een feature of een sprint?

Hier gaat observability praktisch tellen: niet als nog een dashboard, maar als een manier om signalen te verbinden die nu los van elkaar staan.

Voor teams die met Agile Analytics werken, is de implicatie vrij direct. Als AI de levering beïnvloedt, hoort het in dezelfde analytische ruimte als de rest—naast DevEx signals, flow metrics en operationele data. Doet u dat niet, dan ziet u maar een deel van het systeem.

Het paper presenteert geen kant-en-klare oplossing, en dat probeert het ook niet. Het laat zien dat, zodra u AI-gebruik goed gaat meten, veel aannames toetsbaar worden. Kosten stoppen met schattingen te zijn. Outputkwaliteit stopt met anekdotisch te zijn. Patronen worden zichtbaar. En dat verandert hoe beslissingen worden genomen.

Gerelateerde artikelen
· AI-adoptie en toolgebruik meten — wat u moet bijhouden voordat u gaat coderen
· Meet wat uw AI-codetools u daadwerkelijk hebben opgeleverd