De loop sluiten: productielogs in je AI-IDE

De typische AI-workflow van vandaag: je bouwt een feature met een agent, deployt, en verlaat dan de editor. Je opent een logging-dashboard, grept een container, of wacht tot een error tracker (of een gebruiker) meldt dat er iets stuk is. Vervolgens kopieer je een stacktrace, plakt die terug in de agent en vraagt hem een bug te fixen die hij niet in context kan zien.

De agent is blind op precies de plek die er het meest toe doet. Hij kent elke regel code die hij schreef, maar weet niets over hoe die code zich in productie gedraagt. Elke rondgang via een dashboard is handmatige lijm tussen twee helften van dezelfde taak: code schrijven en code zien draaien.

De loop sluiten betekent de coding-agent dezelfde feedback geven als een senior engineer: directe toegang tot productielogs, foutpatronen en service-health. Met die toegang dekt één sessie de hele cyclus:

1. De agent schrijft de code en jij deployt.
2. De agent doorzoekt de productielogs op nieuwe fouten sinds de deploy.
3. Hij leest de echte stacktraces en legt ze naast de wijziging die hij net maakte.
4. Hij schrijft de fix, jij deployt opnieuw, en hij verifieert in de logs dat de fouten weg zijn.

Geen tabbladen wisselen, geen stacktraces kopiëren, niet wachten op een bugmelding. De feedbackloop die vroeger tools en dagen omspande, draait binnen de editor in minuten.

MCP (Model Context Protocol) is het open protocol dat standaardiseert hoe AI-agents met externe systemen verbinden. Een logplatform met een MCP-server biedt getypeerde tools die de agent rechtstreeks aanroept, in plaats van een UI te scrapen of zelf API-calls te schrijven. De remote MCP-server van LogPulse is één HTTPS-endpoint waarmee Claude Code, Cursor, Codex of elke andere MCP-client één keer verbindt; daarna kan de agent tools aanroepen zoals:

• search_logs: productielogs doorzoeken met een gewone vraag of een LPQL-query.
• count_patterns: fouten groeperen in patronen en zien welke nieuw zijn sinds een deploy.
• compare_timeranges: vóór en na een release vergelijken om regressies te vinden.
• timeline_analysis: zien wanneer een fout begon en hoe die zich verspreidde.
• get_service_health: controleren of latency, foutpercentage en KPI's na de fix weer normaal zijn.

Omdat de tools binnen het platform draaien, komen antwoorden in seconden terug, begrensd tot jouw tenant en jouw rechten. De agent redeneert over echte data in plaats van te gokken op wat jij plakte. De volledige toolcatalogus en setup staan op de MCP-serverpagina en in de documentatie.

• Post-deploy-verificatie: vraag de agent na elke deploy om productie te controleren op nieuwe fouten. Hij doorzoekt de logs sinds de release, vergelijkt foutpatronen met het vorige venster en rapporteert alles wat nieuw is, vóór je gebruikers dat doen.
• Foutgedreven debuggen: in plaats van één geplakte stacktrace haalt de agent elke occurrence van de fout op, met de omliggende logregels en de request-context. Hij ziet de failure zoals productie die zag, en fixt daarna de code die hij al kent.
• Regressies opsporen: vraag "is er iets trager of luidruchtiger geworden sinds v0.8?" en de agent vergelijkt tijdvensters over releases heen, met foutvolume en latency naast je changelog.
• Van fout naar alert: is een klasse bugs gefixt, dan kan de agent er een alertregel of detectie voor voorstellen, zodat dezelfde fout nooit meer stilletjes shipt. Voorstellen komen in een wachtrij voor menselijke goedkeuring; de agent wijzigt nooit rechtstreeks configuratie.

Hoe sneller code geschreven wordt, hoe meer het zwaartepunt van engineering verschuift van schrijven naar opereren. Apps die voornamelijk met AI-agents gebouwd zijn ("vibe coding") maken dat acuut: wie de app shipt heeft de code misschien nooit gelezen, en gaat ook geen ruwe logbestanden lezen of Grafana-dashboards bouwen.

Het praktische antwoord is de agent ook het opereren laten doen. Stuur de logs van de app naar een platform dat de agent via MCP kan bevragen, en "waarom is mijn app stuk?" wordt een vraag die de agent met bewijs beantwoordt: de echte fouten, wanneer ze begonnen, welke deploy ze veroorzaakte en wat er moet veranderen. Logging wordt het ontbrekende feedbackorgaan van AI-gebouwde software, geen ops-klusje dat er later bij komt.

Een autonome agent koppelen aan productiedata verdient dezelfde zorg als het onboarden van een nieuwe engineer. De regels die het veilig maken:

• Standaard read-only: de agent kan zoeken en analyseren, niets wijzigen.
• Gescopete tokens: een personal access token met alleen de scopes die de workflow nodig heeft (voor de dev-loop is log-zoeken meestal genoeg).
• Schrijfacties achter menselijke goedkeuring: alles wat de agent voorstelt (een alertregel, een pipeline) komt als uitgeschakeld concept in een reviewwachtrij.
• Audittrail: elke toolcall wordt gelogd, gerate-limit en is herleidbaar tot het token dat hem deed.

De risico's (prompt injection via loginhoud, te brede scopes) en hoe een goed ontworpen MCP-gateway ze afvangt, staan uitgebreid in MCP for security: connecting AI agents to your logs.

1. Stuur je applicatielogs naar LogPulse (HTTP-endpoint, agent of OTLP; de quickstart kost zo'n vijf minuten).
2. Verbind je AI-IDE met de LogPulse MCP-server via one-click OAuth of een gescopet personal access token.
3. Vraag de agent na je volgende deploy: "check productie op nieuwe fouten sinds de deploy".
4. Laat hem vinden, fixen en verifiëren. De loop is gesloten.