Technische teams genereren meer code met AI-agenten dan ooit tevoren. Maar ze lopen tegen een muur aan als die code in productie komt.
Het probleem is niet noodzakelijkerwijs de door AI gegenereerde code zelf. Het probleem is dat traditionele monitoringtools er over het algemeen moeite mee hebben om de gedetailleerde gegevens op functieniveau te leveren die AI-agenten nodig hebben om te begrijpen hoe code zich daadwerkelijk gedraagt in complexe productieomgevingen. Zonder die context kunnen agenten geen problemen detecteren of oplossingen genereren die rekening houden met de productierealiteit.
Het is een uitdaging om te beginnen Huid wil dit helpen oplossen met de lancering van zijn runtime-codesensor op woensdag. De gelijknamige sensor van het bedrijf werkt samen met de productiecode en houdt automatisch bij hoe elke functie zich gedraagt, waardoor ontwikkelaars op de hoogte zijn van wat er daadwerkelijk gebeurt tijdens de implementatie.
“Elke grootschalige softwareteambuilding wordt geconfronteerd met dezelfde fundamentele uitdaging: het bouwen van producten van hoge kwaliteit die goed werken in de echte wereld”, vertelde Roee Adler, CEO en oprichter van Hud, aan VentureBeat in een exclusief interview. “In het nieuwe tijdperk van door AI versnelde ontwikkeling wordt het niet weten hoe code zich in de productie gedraagt een nog groter onderdeel van die uitdaging.”
Waar softwareontwikkelaars mee worstelen
De pijnpunten waarmee ontwikkelaars worden geconfronteerd, zijn redelijk consistent binnen technische organisaties. Moshik Eilon, technisch leider van de groep bij Monday.com, houdt toezicht op 130 ingenieurs en beschrijft een bekende frustratie met traditionele monitoringtools.
“Als je een waarschuwing krijgt, controleer je meestal een eindpunt met een storingspercentage of een hoge latentie, en wil je dieper ingaan op de downstream-afhankelijkheden”, vertelde Eilon aan VentureBeat. “Vaak is het de applicatie zelf, en dan is het een black box. Je krijgt gewoon 80% downstream-latentie voor de applicatie.”
De volgende stap omvat doorgaans handmatig speurwerk met meerdere tools. Controleer de logboeken. Correleer tijdstempels. Probeer te reconstrueren wat de applicatie deed. Voor nieuwe problemen diep in een grote codebase missen teams vaak de exacte gegevens die ze nodig hebben.
Daniel Marashlian, CTO en mede-oprichter bij Drata, zag zijn ingenieurs uren besteden aan wat hij een ‘zoekschat’ noemde. “Ze brachten een algemene waarschuwing in kaart voor een specifieke code-eigenaar en doorzochten vervolgens de logbestanden om de status van de applicatie te reconstrueren”, vertelde Marashlian aan VentureBeat. “We wilden dit elimineren, zodat ons team zich volledig kon concentreren op de oplossing in plaats van op de ontdekking.”
De architectuur van Drata vergroot de uitdaging. Het bedrijf integreert met tal van externe diensten om geautomatiseerde compliance te bieden, waardoor geavanceerde onderzoeken kunnen worden ingesteld wanneer zich problemen voordoen. Ingenieurs volgen het gedrag binnen een zeer grote codebasis die risico-, compliance-, integratie- en rapportagemodules omvat.
Marashlian identificeerde drie specifieke problemen die Drata ertoe brachten te investeren in runtime-sensoren. Het eerste probleem waren de kosten van contextwisseling.
“Onze gegevens waren verspreid, dus onze ingenieurs moesten fungeren als menselijke bruggen tussen losgekoppelde tools”, zei hij.
Het andere probleem, merkte hij op, is alerte vermoeidheid. “Als je een complex gedistribueerd systeem hebt, worden algemene alarmkanalen een constante stroom achtergrondgeluiden, wat ons team beschrijft als een ‘ding, ding, ding’-effect dat uiteindelijk wordt genegeerd,” zei Marashlian.
De derde belangrijke drijfveer was de behoefte aan integratie met de AI-strategie van het bedrijf.
“Een AI-agent kan code schrijven, maar hij kan een productiefout niet repareren als hij de runtimevariabelen of de hoofdoorzaak niet kan zien”, aldus Marashlian.
Waarom traditionele APM’s het probleem niet eenvoudig kunnen oplossen
Bedrijven vertrouwen al lang op een klasse tools en diensten die bekend staan als Application Performance Monitoring (APM).
Met het huidige tempo van de ontwikkeling van agent AI en moderne ontwikkelingsworkflows waren zowel Monday.com als Drata eenvoudigweg niet in staat om de noodzakelijke zichtbaarheid te verkrijgen uit de bestaande APM-tools.
“Als ik die informatie van Datadog of van CoreLogix wil krijgen, zou ik alleen maar tonnen logs of tonnen spans moeten verbruiken, en ik zou veel geld betalen”, zei Eilon.
Eilon merkte op dat Monday.com vanwege kostenbeperkingen zeer lage samplingfrequenties gebruikte. Dit betekende dat ze vaak de exacte gegevens misten die nodig waren om problemen op te lossen.
Traditionele tools voor het monitoren van applicatieprestaties vereisen ook voorspellingen, wat een probleem is omdat een ontwikkelaar soms gewoon niet weet wat hij niet weet.
“Traditionele waarneembaarheid vereist dat je anticipeert op wat je moet debuggen”, zei Marashlian. “Maar als er een nieuw probleem opduikt, vooral diep in een grote, complexe codebase, ontbreekt het je vaak aan de exacte gegevens die je nodig hebt.”
Drata evalueerde verschillende oplossingen in de categorieën AI-site betrouwbaarheid en geautomatiseerde incidentrespons en vond niet wat nodig was.
“De meeste tools die we hebben geëvalueerd waren uitstekend in het beheren van het incidentproces, het routeren van tickets, het samenvatten van Slack-threads of het correleren van grafieken”, zei hij. “Maar ze stopten vaak met de code zelf. Ze konden ons vertellen dat ‘Service A uitvalt’, maar ze konden ons niet specifiek vertellen waarom.”
Een ander gemeenschappelijk kenmerk van sommige tools, waaronder foutmonitors zoals Sentry, is de mogelijkheid om uitzonderingen op te sporen. De uitdaging is volgens Adler dat gewaarschuwd worden voor uitzonderingen leuk is, maar deze niet koppelt aan de bedrijfsimpact of de uitvoeringscontext biedt die AI-agenten nodig hebben om oplossingen voor te stellen.
Hoe runtime-sensoren anders werken
Runtimesensoren sturen intelligentie naar de rand waar code wordt uitgevoerd. De sensor van Hud werkt als een SDK die kan worden geïntegreerd met een enkele regel code. Het houdt toezicht op de uitvoering van elke functie, maar verzendt alleen lichte, verzamelde gegevens, tenzij er iets misgaat.
Wanneer er fouten of vertragingen optreden, verzamelt de sensor automatisch diepgaande forensische gegevens, waaronder HTTP-parameters, databasequery’s en -reacties, en de volledige uitvoeringscontext. Het systeem stelt binnen een dag prestatiebaselines vast en kan waarschuwen voor zowel dramatische vertragingen als uitschieters die op percentiel gebaseerde monitoring over het hoofd ziet.
“Nu krijgen we gewoon al deze informatie voor alle functies, ongeacht het niveau ervan, zelfs voor onderliggende pakketten”, zei Eilon. “Soms kun je een probleem hebben dat heel diep zit en toch zien we het vrij snel.”
Het platform levert gegevens via vier kanalen:
-
Webapplicatie voor gecentraliseerde monitoring en analyse
-
IDE-extensies voor VS Code, JetBrains en Cursor, waarbij productiestatistieken direct worden weergegeven waar de code is geschreven
-
MCP-server dat gestructureerde gegevens levert aan AI-codeeragenten
-
Alarmsysteem dat problemen identificeert zonder handmatige configuratie
MCP-serverintegratie is essentieel voor AI-ondersteunde ontwikkeling. De engineers van Monday.com vragen nu rechtstreeks in Cursor het productiegedrag op.
“Ik kan Cursor slechts één vraag stellen: Hé, waarom is dit eindpunt traag?” zei Eilon. “Als het Hud MCP gebruikt, krijg ik alle gedetailleerde statistieken en deze functie is 30% langzamer sinds deze implementatie. Dan kan ik ook de oorzaak vinden.”
Dit verandert de workflow voor incidentrespons. In plaats van te beginnen in Datadog en door de lagen heen te boren, beginnen ingenieurs met het vragen van een AI-agent om het probleem te diagnosticeren. De agent heeft onmiddellijke toegang tot productiegegevens op functieniveau.
Van voodoo-incidenten tot minutenlange fixes
De verschuiving van theoretische mogelijkheden naar praktische impact wordt duidelijk in de manier waarop technische teams runtime-sensoren daadwerkelijk gebruiken. Wat vroeger uren of dagen speurwerk kostte, is nu binnen enkele minuten opgelost.
“Ik ben gewend aan voodoo-evenementen waarbij er een CPU-piek is en je niet weet waar die vandaan komt”, zei Eilon. “Een paar jaar geleden had ik zo’n incident en moest ik mijn eigen tool bouwen die het CPU-profiel en de geheugendump gebruikt. Nu heb ik gewoon alle functiegegevens en ik heb gezien dat technici het zo snel hebben opgelost.”
Bij Drata is het gekwantificeerde effect dramatisch. Het bedrijf heeft een intern /triage-commando gebouwd dat ingenieurs ondersteunt die hun AI-assistenten gebruiken om onmiddellijk de hoofdoorzaken te identificeren. Het handmatige triagewerk nam af van ongeveer 3 uur per dag naar minder dan 10 minuten. De gemiddelde tijd tot oplossing werd verbeterd met ca. 70%.
Het team genereert ook dagelijks een ‘Heads Up’-rapport van quick-win-fouten. Omdat de hoofdoorzaak al is ontdekt, kunnen ontwikkelaars deze problemen binnen enkele minuten oplossen. Ondersteuningstechnici voeren nu forensische diagnoses uit waarvoor voorheen een senior ontwikkelaar nodig was. De ticketdoorvoer nam toe zonder dat het L2-team werd uitgebreid.
Waar deze technologie past
Runtime-sensoren nemen een andere ruimte in beslag dan traditionele APM’s, die uitblinken in monitoring op serviceniveau, maar worstelen met gedetailleerde, kosteneffectieve gegevens op functieniveau. Ze verschillen van foutmonitors die uitzonderingen opvangen zonder bedrijfscontext.
De technische vereisten voor het ondersteunen van AI-coderingsmiddelen verschillen van de menselijke waarneembaarheid. Agenten hebben gestructureerde gegevens op functieniveau nodig waarover ze kunnen redeneren. Ze kunnen ruwe logboeken niet ontleden en correleren zoals mensen dat doen. Traditionele waarneembaarheid veronderstelt ook dat je kunt voorspellen wat je moet debuggen en dienovereenkomstig moet instrumenteren. Deze aanpak mislukt met door AI gegenereerde code, waarbij ingenieurs mogelijk niet elke functie diep begrijpen.
“Ik denk dat we een nieuw tijdperk betreden van door AI gegenereerde code en deze puzzel, deze puzzel van een nieuwe stapel die in opkomst is”, zei Adler. “Ik denk gewoon niet dat de observatiestapel voor cloud computing netjes zal passen in hoe de toekomst eruit ziet.”
Wat het betekent voor bedrijven
Voor organisaties die al AI-codeerassistenten zoals GitHub Copilot of Cursor gebruiken, biedt runtime-intelligentie een beveiligingslaag voor productie-implementaties. De technologie maakt wat Monday.com ‘agentisch onderzoek’ noemt mogelijk in plaats van handmatig gereedschap kopen.
De bredere implicatie heeft betrekking op vertrouwen. “Met door AI gegenereerde code krijgen we veel meer door AI gegenereerde code, en ingenieurs kennen niet alle code”, zegt Eilon.
Runtime-sensoren overbruggen deze kenniskloof door productiecontext rechtstreeks in de IDE te bieden waar de code wordt geschreven.
Voor bedrijven die het genereren van AI-code verder willen opschalen dan pilots, lost runtime-intelligentie een fundamenteel probleem op. AI-agenten genereren code op basis van aannames over systeemgedrag. Productieomgevingen zijn complex en verrassend. Gedragsgegevens op functieniveau die automatisch uit de productie worden verzameld, geven agenten de context die ze nodig hebben om betrouwbare code op schaal te genereren.
Organisaties moeten beoordelen of hun bestaande observatiestapel op kosteneffectieve wijze de granulariteit kan bieden die AI-agenten nodig hebben. Als het bereiken van zichtbaarheid op functieniveau dramatisch hogere opnamekosten of handmatige instrumentatie vereist, kunnen runtime-sensoren een duurzamere architectuur bieden voor AI-versnelde ontwikkelingsworkflows die al in de sector in opkomst zijn.
