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 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 dat opstarten Hoed wil dit probleem helpen oplossen met de lancering van zijn runtimecodesensor op woensdag. De gelijknamige sensor van het bedrijf werkt samen met de productiecode en houdt automatisch bij hoe elke functie zich gedraagt, waardoor ontwikkelaars inzicht krijgen in wat er daadwerkelijk gebeurt tijdens de implementatie.
“Elk softwareteam dat op grote schaal bouwt, staat voor 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, group tech lead bij Monday.com, houdt toezicht op 130 engineers en beschrijft een bekende frustratie met traditionele monitoringtools.
“Als je een waarschuwing krijgt, controleer je meestal een eindpunt met een foutenpercentage of een hoge latentie, en wil je dieper ingaan op de downstream-afhankelijkheden”, vertelde Eilon aan VentureBeat. “Vaak is het de daadwerkelijke applicatie, 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 toepassing deed. Voor nieuwe problemen die zich diep in een grote codebase bevinden, ontbreekt het teams vaak aan de exacte gegevens die ze nodig hebben.
Daniel Marashlian, CTO en mede-oprichter van Drata, zag zijn ingenieurs uren besteden aan wat hij een ‘onderzoeksbelasting’ 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 maakt de uitdaging nog groter. Het bedrijf integreert met tal van externe diensten om geautomatiseerde compliance te leveren, waardoor geavanceerde onderzoeken ontstaan wanneer zich problemen voordoen. Ingenieurs traceren gedrag in een zeer grote codebase die risico-, compliance-, integratie- en rapportagemodules omvat.
Marashlian identificeerde drie specifieke problemen die Drata ertoe brachten te investeren in runtime-sensoren. Het eerste probleem betrof de kosten van contextwisseling.
“Onze gegevens waren verspreid, dus onze ingenieurs moesten fungeren als menselijke bruggen tussen losgekoppelde tools”, zei hij.
Het tweede probleem, zo merkte hij op, is alerte vermoeidheid. “Als je een complex gedistribueerd systeem hebt, worden algemene waarschuwingskanalen een constante stroom achtergrondgeluid, 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 productiebug 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 agentische AI-ontwikkeling en moderne ontwikkelingsworkflows waren zowel Monday.com als Drata eenvoudigweg niet in staat om de vereiste zichtbaarheid uit de bestaande APM-tools te halen.
“Als ik deze informatie van Datadog of van CoreLogix zou willen krijgen, zou ik alleen maar tonnen logs of tonnen spans moeten verwerken, en ik zou veel geld betalen”, zei Eilon.
Eilon merkte op dat Monday.com vanwege kostenbeperkingen zeer lage samplingfrequenties gebruikte. Dat 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 binnen een grote, complexe codebase, mis je vaak de exacte gegevens die je nodig hebt.”
Drata evalueerde verschillende oplossingen in de categorieën AI-sitebetrouwbaarheid en geautomatiseerde incidentrespons en vond niet wat er 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 andere veel voorkomende mogelijkheid in sommige tools, waaronder foutmonitors zoals Sentry, is de mogelijkheid om uitzonderingen vast te leggen. De uitdaging is volgens Adler dat het prettig is om op de hoogte te zijn van uitzonderingen, maar dat dit geen verband houdt met de zakelijke impact en ook niet de uitvoeringscontext biedt die AI-agenten nodig hebben om oplossingen voor te stellen.
Hoe runtime-sensoren anders werken
Runtime-sensoren duwen 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 ziet elke functie-uitvoering, maar verzendt alleen lichtgewicht geaggregeerde 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 prestatiebasislijnen vast en kan waarschuwen voor zowel dramatische vertragingen als uitschieters die op percentiel gebaseerde monitoring over het hoofd ziet.
“Nu krijgen we al deze informatie voor alle functies, ongeacht het niveau ervan, zelfs voor onderliggende pakketten”, aldus Eilon. “Soms heb je een probleem dat heel diep zit, en we zien het nog steeds vrij snel.”
Het platform levert gegevens via vier kanalen:
-
Webapplicatie voor gecentraliseerde monitoring en analyse
-
IDE-extensies voor VS Code, JetBrains en Cursor die productiestatistieken direct naar voren brengen waar de code wordt geschreven
-
MCP-server die gestructureerde gegevens aan AI-codeermiddelen levert
-
Waarschuwingssysteem waarmee problemen worden geïdentificeerd zonder handmatige configuratie
De MCP-serverintegratie is van cruciaal belang voor AI-ondersteunde ontwikkeling. De engineers van Monday.com vragen nu rechtstreeks binnen Cursor het productiegedrag op.
“Ik kan Cursor gewoon een vraag stellen: Hé, waarom is dit eindpunt traag?” zei Eilon. “Als het de Hud MCP gebruikt, krijg ik alle gedetailleerde statistieken, en deze functie is 30% langzamer sinds deze implementatie. Dan kan ik ook de hoofdoorzaak vinden.”
Dit verandert de workflow voor incidentrespons. In plaats van te beginnen in Datadog en door de lagen heen te gaan, beginnen ingenieurs met het vragen van een AI-agent om het probleem te diagnosticeren. De agent heeft direct 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-incidenten 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 ingenieurs het zo snel hebben opgelost.”
Bij Drata is de gekwantificeerde impact dramatisch. Het bedrijf heeft een intern /triage-commando gebouwd dat technici ondersteunt die binnen hun AI-assistenten worden uitgevoerd om onmiddellijk de hoofdoorzaken te identificeren. Het handmatige triagewerk daalde van ongeveer 3 uur per dag naar minder dan 10 minuten. De gemiddelde tijd tot oplossing verbeterde met ongeveer 70%.
Het team genereert ook dagelijks een ‘Heads Up’-rapport van quick-win-fouten. Omdat de hoofdoorzaak al bekend is, 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 vastleggen zonder bedrijfscontext.
De technische vereisten voor het ondersteunen van AI-codeermiddelen verschillen van de menselijke waarneming. Agenten hebben gestructureerde gegevens op functieniveau nodig waarover ze kunnen redeneren. Ze kunnen onbewerkte logboeken niet ontleden en correleren zoals mensen dat doen. Traditionele waarneembaarheid veronderstelt ook dat je kunt voorspellen wat je nodig hebt om fouten te debuggen en dienovereenkomstig te instrumenteren. Deze aanpak mislukt met door AI gegenereerde code waarbij ingenieurs mogelijk niet elke functie diep begrijpen.
“Ik denk dat we een nieuw tijdperk van door AI gegenereerde code ingaan en deze puzzel, deze legpuzzel van een nieuwe stapel, ontstaat”, zei Adler. “Ik denk gewoon niet dat de observatiestapel van cloud computing netjes zal passen in hoe de toekomst eruit ziet.”
Wat dit betekent voor bedrijven
Voor organisaties die al AI-codeerassistenten zoals GitHub Copilot of Cursor gebruiken, biedt runtime-intelligentie een veiligheidslaag voor productie-implementaties. De technologie maakt wat Monday.com ‘agentisch onderzoek’ noemt mogelijk in plaats van handmatig tool-hopping.
De bredere implicatie heeft betrekking op vertrouwen. “Met door AI gegenereerde code krijgen we veel meer door AI gegenereerde code, en ingenieurs beginnen niet alle code te kennen”, aldus Eilon.
Runtime-sensoren overbruggen die 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, pakt runtime-intelligentie een fundamenteel probleem aan. 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 evalueren 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.
