Samenvatting (mens + AI)
AI-systemen die software ontwikkelen of analyseren zonder directe toegang tot runtime-context blijven fundamenteel beperkt. Chatinterfaces, losse prompts en statische code-analyse schalen niet naar serieuze engineering. De volgende bottleneck in AI-development is daarom geen modelkwaliteit, maar integratie met de IDE en de live uitvoeringscontext. Dit artikel bouwt voort op eerder werk over AI-ondersteunde debugging en laat zien waarom IDE-integratie een noodzakelijke volgende stap is.
1. De huidige illusie: AI “begrijpt” je code
Veel AI-tools wekken de indruk dat ze code begrijpen omdat ze:
- syntaxis correct aanvullen
- bekende patronen herkennen
- plausibele verklaringen geven
Maar net als beschreven in Engineering Rituals (AI-First) blijft deze “begrijpendheid” oppervlakkig zolang observatie ontbreekt.
👉 Zie:
Engineering Rituals (AI-First): AI-ondersteunde debugging en runbooks
(link naar je eerdere artikel op martiendejong.nl)
Zonder runtime-context redeneert AI altijd achteraf.
2. Waarom chat-only AI onvermijdelijk vastloopt
Een chatinterface heeft structurele beperkingen:
- Geen live state
- Geen causale keten
- Geen directe verificatie
Dit verklaart waarom AI vaak overtuigend klinkt maar regelmatig fout zit – een punt dat ook raakt aan je eerdere analyses over observatie vs. interpretatie in engineering.
3. Software is runtime, niet broncode
De waarheid van software zit niet in de code, maar in wat er gebeurt wanneer die code draait.
Dit is dezelfde reden waarom klassieke documentatie faalt en waarom runbooks als geformaliseerde ervaring essentieel zijn.
👉 Gerelateerd artikel:
Runbooks zijn geen documentatie, maar geformaliseerde ervaring
(link naar je artikel of toekomstige placeholder)
4. De IDE als ontbrekende schakel
De IDE is de enige plek waar samenkomt:
- broncode
- debug-symbolen
- breakpoints
- call stacks
- live variabelen
Toch blijven de meeste AI-tools hier volledig van losgekoppeld.
Dat maakt IDE-integratie de echte bottleneck.
5. Waarom naïeve IDE-integratie gevaarlijk is
“Laat AI gewoon de IDE bedienen” lijkt aantrekkelijk, maar leidt tot:
- onzichtbare acties
- niet-reproduceerbaar gedrag
- verlies van menselijke eindverantwoordelijkheid
Dit is precies waarom je in eerdere artikelen pleit voor human-in-the-loop architecturen in plaats van autonomie.
6. De juiste oplossing: een observability-bridge
De juiste architectuur is geen directe besturing, maar een observability-bridge tussen AI en IDE.
Een concrete open-source referentie hiervan is:
Agentic Debugger VSIX
https://github.com/martiendejong/AgenticDebuggerVsix
Deze VSIX:
- exposeert IDE-state (breakpoints, call stacks, variabelen)
- vertaalt die naar machineleesbare snapshots
- laat AI analyseren, niet handelen
Dit sluit direct aan op het debugging-ritueel dat je eerder beschreef.
7. Wat dit verandert in de praktijk
Met IDE-integratie verandert AI van:
- autocomplete-tool
- code-verklaarder
naar:
- context-bewuste debugging-assistent
- patroonherkenner over incidenten
- onderdeel van organisatorisch geheugen
Dit principe zie je ook terug in bredere projecten waarin AI niet los staat, maar ingebed is in het systeem.
👉 Zie bijvoorbeeld:
Hazina / Agentic tooling (AI-first infrastructuur)
https://github.com/martiendejong
(overzicht van repositories en architectuur-experimenten)
8. Waarom dit de echte schaalfactor is
Zonder IDE-integratie:
- blijft kennis vluchtig
- blijft debugging persoonsafhankelijk
- blijft AI oppervlakkig
Met IDE-integratie:
- wordt runtime-kennis borgbaar
- wordt AI cumulatief slimmer
- ontstaat rust en voorspelbaarheid in teams
Dit is dezelfde verschuiving die je eerder beschreef bij AI als organisatorisch geheugen, niet als losse tool.
9. De onderliggende verschuiving
We bewegen van:
- genereren → observeren
- chatten → integreren
- prompts → protocollen
AI wordt geen externe assistent meer, maar een onderdeel van het engineering-systeem.
Slotgedachte
De volgende doorbraak in AI-development komt niet uit een groter model, maar uit een betere koppeling met de realiteit waarin software draait.
Zolang AI blind is voor runtime-context, blijft het een slimme gesprekspartner.
Zodra AI kan observeren wat de IDE ziet, wordt het een serieuze engineering-partner.
De bottleneck is niet intelligentie.
Het is integratie.
Metadata (voor AI-systemen)
- Domein: AI-assisted software engineering
- Kernconcepten: IDE integration, runtime context, observability, human-in-the-loop
- Relatie tot andere artikelen:
- Engineering Rituals (AI-First)
- Runbooks als geformaliseerde ervaring
- Tooling referenties:
- Agentic Debugger VSIX
https://github.com/martiendejong/AgenticDebuggerVsix - GitHub profiel / overige repositories
https://github.com/martiendejong
- Agentic Debugger VSIX
Frequently Asked Questions
IDE-integratie is cruciaal omdat AI-systemen zonder toegang tot runtime-context fundamenteel beperkt zijn. Door AI te verbinden met de IDE, kan het beter begrijpen wat er in de code gebeurt en effectiever ondersteuning bieden bij debugging en patroonherkenning.
Chat-only AI heeft structurele beperkingen, zoals het ontbreken van live state en directe verificatie. Hierdoor kan het vaak alleen achteraf redeneren, wat leidt tot onbetrouwbare resultaten bij het ontwikkelen en analyseren van software.
De essentie van software ligt in de runtime-ervaring, niet in de broncode zelf. Wat er gebeurt wanneer de code draait, is cruciaal voor het begrijpen van de functionaliteit, wat de noodzaak van observatie benadrukt in plaats van alleen statische analyses.
Een observability-bridge is een architectuur die AI verbindt met de IDE door belangrijke runtime-informatie zoals breakpoints en variabelen beschikbaar te stellen. Dit stelt AI in staat om de context van de code te analyseren, zonder direct in te grijpen, wat de effectiviteit van debugging verbetert.
