Technische teams produceren meer code met AI-agenten dan ooit tevoren. Maar ze liepen tegen een muur aan toen de code in productie kwam.
Het probleem is niet noodzakelijkerwijs de door AI gegenereerde code zelf. Traditionele monitoringtools hebben doorgaans moeite om de gedetailleerde gegevens op functioneel niveau 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 verbeteringen aanbrengen die rekening houden met de productierealiteit.
Dit is een uitdaging voor startups Kap wil dat helpen oplossen met de lancering van de runtimecodesensor 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.
“Elk softwareteam dat op grote schaal bouwt, staat voor dezelfde fundamentele uitdaging: het bouwen van een kwalitatief hoogstaand product dat goed werkt 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 steeds groter deel van de uitdaging.”
Waar softwareontwikkelaars mee worstelen
De problemen waarmee ontwikkelaars worden geconfronteerd, zijn redelijk consistent in alle technische organisaties. Moshik Eilon, groepstechnologieleider bij Monday.com, houdt toezicht op 130 ingenieurs en beschrijft de frustraties die vaak voorkomen bij traditionele monitoringtools.
“Wanneer u een waarschuwing ontvangt, zoekt u doorgaans naar een eindpunt met een hoog foutenpercentage of een hoge latentie, en wilt u dieper ingaan op de downstream-afhankelijkheden ervan”, vertelde Eilon aan VentureBeat. “Vaak is het de daadwerkelijke applicatie, en dan wordt het een black box. Je krijgt slechts 80% van de downstream-latency voor die applicatie.”
De volgende stappen omvatten meestal handmatig speurwerk met verschillende tools. Controleer het logboek. Correleer tijdstempels. Probeer te reconstrueren wat de applicatie deed. Voor nieuwe problemen die zich diep in grote codebases bevinden, beschikken teams vaak niet over de exacte gegevens die ze nodig hebben.
Daniel Marashlian, CTO en mede-oprichter van Drata, ziet zijn ingenieurs urenlang bezig zijn met wat hij ‘onderzoeksbelasting’ noemt. “Ze brengen algemene waarschuwingen in kaart voor specifieke code-eigenaren en graven vervolgens in de logboeken om de status van de applicatie te reconstrueren”, vertelde Marashlian aan VentureBeat. “We willen dat elimineren, zodat ons team zich volledig kan concentreren op verbetering in plaats van op ontdekking.”
De architectuur van Drata draagt bij aan de uitdaging. Het bedrijf integreert met een verscheidenheid aan 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 zijn de kosten van contextwisseling.
“Onze gegevens zijn verspreid, dus onze ingenieurs moeten fungeren als een menselijke brug tussen losgekoppelde tools”, zei hij.
Het tweede probleem, zei hij, is alerte vermoeidheid. “Als je een complex gedistribueerd systeem hebt, worden gemeenschappelijke waarschuwingskanalen een constante stroom achtergrondgeluid, wat ons team beschrijft als een ‘ding, ding, ding’-effect dat uiteindelijk wordt genegeerd”, aldus Marashlian.
De derde belangrijke drijvende factor is de noodzaak om te integreren met de AI-strategie van het bedrijf.
“Een AI-agent kan code schrijven, maar hij kan geen productiefouten oplossen als hij de runtimevariabelen of de hoofdoorzaak niet kan zien”, aldus Marashlian.
Waarom traditionele APM het probleem niet eenvoudig kan oplossen
Bedrijven vertrouwen al lang op tools en diensten die bekend staan als Application Performance Monitoring (APM).
Met het huidige tempo van de AI-ontwikkeling van agenten en moderne ontwikkelingsworkflows konden Monday.com en Drata eenvoudigweg niet de zichtbaarheid krijgen die ze nodig hadden uit de bestaande APM-tools.
“Als ik deze informatie van Datadog of CoreLogix wilde krijgen, zou ik alleen maar tonnen logs of tonnen spans moeten verwerken, en ik zou veel geld hebben betaald”, zei Eilon.
Eilon merkt op dat Monday.com vanwege kostenbeperkingen een zeer lage samplingfrequentie hanteert. Dit betekent dat ze vaak de exacte gegevens missen die nodig zijn om een probleem op te lossen.
Traditionele tools voor het monitoren van applicatieprestaties vereisen ook voorspellingen, wat een probleem is omdat ontwikkelaars soms niet weten wat ze niet weten.
“Traditionele waarneembaarheid vereist dat je anticipeert op wat moet worden opgespoord”, zei Marashlian. “Maar als er nieuwe problemen ontstaan, vooral binnen grote, complexe codebases, verlies je vaak de gegevens die je nodig hebt.”
Drata evalueerde verschillende oplossingen op het gebied van AI-site-betrouwbaarheidstechniek en geautomatiseerde incidentresponscategorieën en vond niets nodig.
“De meeste tools die we hebben geëvalueerd waren uitstekend in het beheren van incidentprocessen, het routeren van tickets, het samenvatten van Slack-threads of het verbinden van grafieken”, zei hij. “Maar ze kennen de code zelf vaak niet. Ze kunnen ons vertellen dat ‘Service A uitvalt’, maar ze kunnen ons niet specifiek vertellen waarom.”
Een andere veel voorkomende mogelijkheid in verschillende tools, waaronder foutmonitors zoals Sentry, is de mogelijkheid om uitzonderingen op te vangen. De uitdaging is volgens Adler dat het kennen van uitzonderingen een goede zaak is, maar dat het deze niet in verband brengt met de bedrijfsimpact en niet de uitvoeringscontext biedt die AI-agenten nodig hebben om verbeteringen voor te stellen.
De manier waarop runtime-sensoren werken is anders
Runtime-sensoren duwen intelligentie naar het hoogste punt waar code wordt uitgevoerd. Hud Sensor werkt als een geïntegreerde SDK met één regel code. Het ziet elke functie-uitvoering, maar verzendt alleen lichte, verzamelde gegevens, tenzij er een fout optreedt.
Wanneer er een fout of vertraging optreedt, verzamelt de sensor automatisch diepgaande forensische gegevens, waaronder HTTP-parameters, databasequery’s en -reacties, en de volledige uitvoeringscontext. Het systeem stelt op één dag een prestatiebasislijn vast en kan waarschuwingen geven voor dramatische vertragingen en uitschieters die bij percentielgebaseerde monitoring over het hoofd worden gezien.
“Nu krijgen we al deze informatie voor alle functies, ongeacht het niveau, zelfs voor de onderliggende pakketten”, zegt Eilon. “Soms heb je een heel diep probleem, en kunnen we het toch snel oplossen.”
Dit platform verzendt gegevens via vier kanalen:
-
Webapplicatie voor gecentraliseerde monitoring en analyse
-
IDE-extensie voor VS Code, JetBrains en Cursor die productiestatistieken direct weergeeft waar de code is geschreven
-
MCP-server die gestructureerde gegevens aan een AI-codeeragent voedt
-
Waarschuwingssysteem die problemen identificeert zonder handmatige configuratie
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 alleen maar een vraag stellen: Hé, waarom is dit eindpunt traag?” zei Eilon. “Als ik Hud MCP gebruik, krijg ik alle gedetailleerde statistieken, en het is 30% langzamer sinds de implementatie hiervan. Dan kan ik ook de hoofdoorzaak vinden.”
Dit verandert de workflow voor incidentrespons. In plaats van in Datadog te beginnen en de lagen te doorlopen, begonnen ingenieurs met het vragen van een AI-agent om het probleem te diagnosticeren. Agenten hebben directe toegang tot productiegegevens op functieniveau.
Van voodoo-incidenten tot minutenlange reparaties
De overgang van theoretische mogelijkheden naar praktische impact wordt duidelijk in de manier waarop technische teams runtime-sensoren gebruiken. Recherchewerk dat vroeger uren of dagen in beslag nam, kan nu binnen enkele minuten worden voltooid.
“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 maken die een CPU-profiel en een geheugendump gebruikte. Nu heb ik gewoon alle functiegegevens en ik heb gezien dat technici het heel snel hebben opgelost.”
Bij Drata was de gemeten impact dramatisch. Het bedrijf heeft een intern /triage-commando gebouwd dat ingenieurs ondersteunt bij het uitvoeren van hun AI-assistent om de hoofdoorzaken onmiddellijk te identificeren. Het handmatige triagewerk daalde van ongeveer 3 uur per dag naar minder dan 10 minuten. De gemiddelde doorlooptijd nam met ongeveer 70% toe.
Het team genereert ook dagelijks “Caution”-rapporten over quick-win-fouten. Omdat de oorzaak bekend is, kunnen ontwikkelaars het probleem binnen enkele minuten oplossen. Ondersteuningstechnici voeren nu forensische diagnostiek uit waarvoor voorheen senior ontwikkelaars nodig waren. De ticketdoorvoer neemt toe zonder dat het L2-team wordt 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 ter ondersteuning van een AI-codeeragent verschillen van de waarneembaarheidsmogelijkheden waarmee mensen te maken krijgen. Agenten hebben gestructureerde gegevens op functieniveau nodig waarmee ze rekening kunnen houden. Ze kunnen onbewerkte logboeken niet ontleden en correleren zoals mensen dat kunnen. Traditionele waarneembaarheid veronderstelt ook dat je kunt voorspellen wat er moet worden opgespoord en dat je dienovereenkomstig kunt instrumenteren. Die aanpak is niet consistent 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 en deze puzzels binnengaan, een hele nieuwe stapel puzzels die in opkomst zijn”, zei Adler. “Ik denk gewoon niet dat de observatiestapel van cloud computing in het beeld van de toekomst zal passen.”
Wat dit betekent voor het bedrijf
Voor organisaties die al AI-codeerassistenten zoals GitHub Copilot of Cursor gebruiken, biedt runtime-intelligentie een beveiligingslaag voor productie-implementaties. Deze technologie maakt wat Monday.com ‘agentonderzoeken’ noemt mogelijk in plaats van handmatig tussen tools te schakelen.
De bredere implicaties hebben betrekking op vertrouwen. “Met door AI gegenereerde code krijgen we meer door AI gegenereerde code, en beginnen ingenieurs 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 schalen dan alleen testen, kan runtime-intelligentie fundamentele problemen aanpakken. AI-agenten genereren code op basis van aannames over systeemgedrag. De productieomgeving is complex en verrassend. Gedragsgegevens op functieniveau die automatisch uit de productie worden verzameld, bieden de context die agenten nodig hebben om betrouwbare code op schaal te produceren.
Organisaties moeten evalueren of bestaande observatiestapels op een kosteneffectieve manier de granulariteit kunnen bieden die AI-agenten nodig hebben. Als het bereiken van zichtbaarheid op functieniveau aanzienlijk hogere opnamekosten of handmatige instrumentatie vereist, kunnen runtime-sensoren een duurzamere architectuur bieden voor de AI-versnelde ontwikkelingsworkflows die al in de sector in opkomst zijn.
