Anton Onufriienko, Managing Director bij Devart – Interview Serie

Anton Onufriienko, Managing Director bij Devart, is een technisch directeur en operator met diepgaande ervaring in het opschalen van softwarebedrijven, het stimuleren van omzetgroei en het leiden van grote cross-functionele teams in SaaS, enterprise software en financiële diensten. In de loop van zijn carrière is hij gegroeid van het opbouwen van verkooporganisaties en het lanceren van startups tot het toezicht houden op volledige P&L-operaties voor grote bedrijfsunits, waaronder de grootste divisie van Devart met meer dan 130 medewerkers. Voordat hij Managing Director werd, was hij Chief Revenue Officer en Head of Sales bij Devart, waar hij de go-to-market-strategie, prijstransformatie en internationale groeistrategieën leidde. Hij is ook CEO van TMetric, een platform voor tijdsregistratie en winstgevendheid dat zich richt op het helpen van dienstgerichte bedrijven om operationele duidelijkheid te verkrijgen.

Devart is een softwarebedrijf dat gespecialiseerd is in databaseontwikkeling, dataconnectiviteit, integratie en productiviteitstools voor ontwikkelaars, DBA’s, analisten en enterprise-teams. Opgericht in 1997 is het bedrijf het beste bekend om zijn dbForge-suite van databasebeheertools, die grote databasesystemen ondersteunen, waaronder SQL Server, MySQL, Oracle (ORCL ) en PostgreSQL. Devart ontwikkelt ook dataconnectiviteitsoplossingen, zoals ODBC, ADO.NET, Python en Delphi-connectors, evenals Skyvia, zijn cloudgebaseerde no-code data-integratieplatform voor ETL, automatisering, back-up en workflow-orchestratie. Het bedrijf serveert meer dan 500.000 gebruikers wereldwijd, waaronder een groot deel van de Fortune 100-organisaties, en heeft zich steeds meer gericht op het integreren van AI-gebaseerde mogelijkheden in zijn producten via tools als dbForge AI Assistant, die ontwikkelaars helpt bij het genereren, optimaliseren, opsporen en verklaren van SQL-queries met behulp van natuurlijke taal.

U bent gegroeid van het opbouwen en leiden van verkoopteams tot het runnen van volledige P&L-operaties en nu het managen van de grootste businessunit van Devart. Hoe heeft die reis uw aanpak beïnvloed voor het integreren van AI in productstrategie en besluitvorming op grote schaal?

Verkoop heeft me geleerd om ROI te meten voor alles. Toen ik in een CRO-functie terechtkwam, heb ik die discipline uitgebreid naar alle functies. Het runnen van de BU heeft me gedwongen om dat toe te passen op AI zelf.

Ik heb een praktische kijk op AI. Het is niet dat ik er sceptisch over ben: drie van onze vier productinzetten voor 2026 zijn AI-natief. Maar ik geloof dat de hype in de weg staat van echte, duurzame resultaten.

Er is een meme die de rondte doet die samenvat waar de industrie vaak fout gaat. Bedrijven verwisselen $400 SaaS-abonnementen voor zelfgemaakte tools die $1.000 per maand kosten in API-kosten en constant onderhoud nodig hebben. Dat is geen echte verandering, het is alleen een dure show.

De les die ik heb geleerd in verkoop is eenvoudig: elke initiatief betaalt zijn weg, of het sterft. Ik run onze AI-uitrol op dezelfde manier als ik vroeger een verkoopgebied runde. Expliciete ROI-hypothese per workflow, een driedelige uitrol en gedocumenteerde impact voordat we opschalen.

Onze Noordster-metriek is Omzet per Medewerker, en ons doel is om die te verdubbelen tegen het einde van 2028. Je sluit die kloof niet door te huren. Je sluit die door het werkproces te veranderen, en AI is het enige realistische mechanisme om dat te doen.

Mijn filter voor elke AI-initiatief, intern of product, is hetzelfde: wat is de gemeten waarde, wie betaalt ervoor, en hoe weten we dat het werkt? Alles wat die drie vragen niet doorstaat, hoort niet in productie te zijn. De kosten van het fout gaan zijn snel en de meeste bedrijven zullen dat op een dure manier ontdekken.

Devart heeft een sterke reputatie opgebouwd rond databasehulpmiddelen en ontwikkelaarsproductiviteit. Hoe integreert u AI in deze producten op een manier die echte waarde levert in plaats van oppervlakkige automatisering?

Onze gebruikers zijn harde technische specialisten: DBA’s, senior engineers, data-architecten. Ze detecteren oppervlakkige automatisering in seconden en zijn geïrriteerd als ze marketing-speelgoed verkocht krijgen dat zich voordoet als innovatie. Twee jaar geleden, toen de AI-hype op zijn hoogtepunt was en concurrenten haastten zich om chatpanels op elk UI-element te bevestigen, was de verleiding om te volgen echt. Ik had dat patroon eerder gezien, in mobiel, in cloud, in low-code, en ik weigerde het te herhalen.

De discipline was eenvoudig: klantwaarde eerst. Het bouwen van AI-functies waar niemand om gevraagd had, die geen echte waarde leveren, is het slechtste mogelijke gebruik van eindige engineeringsbronnen. Dat is vooral waar als uw publiek het verschil onmiddellijk kan zien.

Wat veranderde in 2026 is dat AI van hype naar een echte technische revolutie ging. De kloof tussen wat deze systemen in 2023 konden doen en wat ze nu kunnen doen, is niet incrementeel. Het is een compleet andere categorie van mogelijkheden. We kunnen nu problemen oplossen die eerder echt onoplosbaar waren: beveiligde ondernemingsgegevenstoegang voor AI-agents, contextuele database-intelligentie binnen de IDE van de ontwikkelaar en autonome bedrijfsanalyses die geen speciale analist nodig hebben.

Deze zijn nieuwe productlijnen die bestaan omdat AI de onderliggende problemen oplosbaar maakte. Dat is de lat waar we onszelf aan meten: een echte AI-product is een product waarbij het verwijderen van de AI-laag het product breekt. De industrie heeft twee jaar lang chatpanels “AI-producten” genoemd. Dat zijn functies, geen producten.

We hebben langer gewacht omdat we het goed wilden doen. De komende twaalf maanden zullen laten zien of die discipline heeft opgebracht.

AI schrijft, optimaliseert en debugt steeds meer code. Hoe ziet u dat de rol van ontwikkelaars die met databases werken de komende jaren zal veranderen?

De waarde van het kennen van SQL-syntaxis neemt snel af. Als AI een complexe multi-table JOIN in seconden kan genereren en ontbrekende indexen uit logs in minuten kan identificeren, komt de waarde van een engineer niet langer van het typen van SQL. Dat deel van de baan wordt een commodity.

Maar hier is het cruciale nuance dat evangelisten van totale automatisering altijd overslaan. Een AI-fout op het frontend is een misgeplaatste knop die je opnieuw laadt. Een AI-fout op de database is een gewiste productieomgeving, een PII-lek of een transactie-uitval van het hele bedrijf.

Databases bevatten status. Ze vergeven geen hallucinaties.

Die asymmetrie definieert de rol volledig opnieuw. In de komende twee tot drie jaar zullen databaseontwikkelaars en DBA’s evolueren van coders naar architecten en auditors. Hun primaire werk verschuift naar drie dingen:

• Het ontwerpen van betrouwbare architectuur die AI niet zelf kan begrijpen, omdat het de bedrijfscontext mist.
• Het instellen van harde beveiligingsbeleid voor AI-agents die productiesystemen aanraken.
• Het controleren en auditen van de code die machines genereren voordat deze de database bereikt.

Het mentale model dat ik steeds terugkom op: engineers zullen legers van AI-assistenten beheren. Tools zoals dbForge moeten evolueren van traditionele IDE’s naar commando- en auditcentra. De baan wordt minder over het schrijven van SQL-manueel en meer over het controleren van wat AI genereert, valideren en de grenzen afdwingen die AI niet veilig kan overschrijden.

De professionele kans hier is aanzienlijk. Ontwikkelaars die zich ontwikkelen tot architecten en toezicht houden, zullen hun marktwaarde vermenigvuldigen. Ze worden de onmisbare laag tussen AI-productiviteit en productieve veiligheid. De premie op database-expertise verdwijnt niet; deze verschuift naar boven, naar ontwerp, governance en oordeel, waar AI niet alleen kan opereren.

Wat zijn de grootste beperkingen van de huidige AI-hulpmiddelen in databasebeheer vandaag, en waar ziet u de meest betekenisvolle doorbraken?

Huidige AI zit nog steeds vast in oppervlakkige automatisering. Het genereren van een basis-SELECT-query of boilerplate-code is niet langer indrukwekkend. Het grotere probleem is dat de meeste AI-systemen nog steeds als blinde typisten gedragen in plaats van systeemarchitecten. Ze kunnen syntaxis genereren, maar ze begrijpen de omgeving waarin ze opereren niet echt. De echte doorbraak gebeurt wanneer AI begint te redeneren over context, afhankelijkheden, status en bedrijfslogica samen.

Op dit moment zie ik drie grote beperkingen die AI in database-omgevingen tegenhouden.

Ten eerste is er het contextprobleem. Grote taalmodellen kunnen schema’s, DDL en kolomnamen zien, maar ze begrijpen de uitvoeringsplannen, indexfragmentatie, gegevensdistributiepatronen of de werkelijke bedrijfslogica achter de gegevens niet. Zonder die diepere begrip wordt veel optimalisatieadvies statistisch gokken vermomd als expertise.

Ten tweede is er het hallucinatieprobleem, en ondernemingen hebben bijna geen tolerantie voor dit op het database-niveau. Een gehallucineerde JOIN kan productiesystemen vertragen. Een verkeerde UPDATE kan kritieke records wissen. Op dat niveau worden zelfs kleine nauwkeurigheidsfouten heel snel heel duur.

Het derde probleem is beveiliging en governance. Geen enkel serieus bedrijf zal productieschema’s of PII in een openbaar AI-hulpmiddel plakken zonder sterke garanties rondom gegevensisolatie en -controle. Tot leveranciers dit goed oplossen, zal AI-adoptie in gereguleerde industrieën beperkt blijven.

De betekenisvolle doorbraken zullen komen wanneer AI verder gaat dan syntaxisgeneratie en meer gaat functioneren als een achtergrondarchitect of analist.

Een deel daarvan is de semantische laag: van rauwe tabelnamen naar echte bedrijfsbetekenis. Niet alleen “table_users”, maar het begrijpen van concepten als klantgroepen, churn-risico of Q3-LTV-trends.

Een andere verschuiving is AI die meer als een senior DBA op de achtergrond werkt. Continue analyse van workloads, identificeren van bottlenecks, suggesties voor indexen, risicovolle queries identificeren en problemen opvangen voordat systemen falen.

En dan heb je machine-tot-machine-bewerkingen, waar autonome agents databasebelastingen monitoren, optimalisatie-strategieën testen in geïsoleerde omgevingen en verbeteringen implementeren onder menselijk toezicht.

Die zijn de ontwikkelingen die de komende vijf jaar van databasehulpmiddelen zullen vormgeven.

U heeft ervaring met het leiden van omzet en go-to-market-strategie. Hoe verandert AI de prijsmodellen, productverpakking en klantacquisitie in softwarebedrijven?

De traditionele go-to-market-playbook is gebroken. We zien het in onze eigen cijfers en in de hele dev-tools-categorie.

De dood van klassieke acquisitie. Ondanks significante verbeteringen in zoekresultaten voor onze producten in 2026, komen we in de zero-click-realiteit terecht. AI-zoek levert antwoorden rechtstreeks op de resultatenpagina en ontneemt websites van verkeer. Sterke rankings vertalen zich niet langer in leads zoals ze twee jaar geleden deden.

Vijf jaar geleden was een sterke contentstrategie genoeg om groei te stimuleren. Vandaag is het een vereiste. LLM’s wegen merksterkte, positieve vermeldingen en communitydichtheid af bij het vormen van antwoorden. Als uw merk niet zichtbaar en betrouwbaar is, zullen AI-systemen u niet consistent oppervlaken in de zoekresultaten. U verliest niet alleen verkeer, u verdwijnt helemaal uit de koopreis.

Dit heeft een negatief effect op traditionele dev-tools-bedrijven. SEO-gedreven acquisitiekanaal die een generatie B2B SaaS financierden, verliezen snel efficiëntie. Iedereen die nog steeds afhankelijk is van deze kanalen als primaire groeimotor, moet nu actief alternatieven bouwen: ecosysteemverdeling, community en partnerschappen.

Prijs-evolutie: van stoel naar PLG 3.0. We gaan de volgende fase van PLG in. Per-stoel-prijzen beginnen af te breken wanneer één AI-agent het werk van meerdere medewerkers kan doen. In die omgeving heeft het zinloos om per hoofd te rekenen. Bedrijven die hun producten niet herverpakken rondom waarde in plaats van per hoofd, zullen de komende 24 maanden veel MRR verliezen.

Het volgende stap is PLG 3.0: het moment waarop een autonome AI-agent, en niet een mens, een enterprise-software evalueert, test en koopt. Massale adoptie van dat patroon ligt nog een paar jaar in de toekomst, maar het ontwerpen van producten en prijzen voor de machinekoper is een taak voor 2026, niet voor 2028.

Veel organisaties worstelen om van AI-experimenten naar echte productie-impact te gaan. Wat zijn de belangrijkste factoren die bepalen of AI-initiatieven daadwerkelijk slagen?

De meeste AI-functies falen voordat ze zijn gebouwd. Ze falen in de kamer waar iemand zegt “we hebben AI nodig in dit product”, niet omdat gebruikers ernaar vroegen, maar omdat het bestuur een AI-verhaal wil of marketing denkt dat het een nieuwe doelgroep aantrekt. Dat is de oorspronkelijke zonde van de meeste AI-initiatieven, en het vormt alles wat volgt.

Ik zie steeds dezelfde fouten herhaald bij bedrijven die worstelen om AI van experimenten naar echte productie-impact te brengen.

De eerste fout is het bouwen van AI-functies waar niemand om gevraagd heeft. Zodra een AI-functie wordt opgelegd zonder echte gebruikersbehoefte, werkt het team achteruit van de technologie om een gebruiksscenario te verzinnen. Het resultaat is voorspelbaar: een chatpaneel bevestigd aan een bestaande UI, een autocomplete die in de weg zit, een “samenvatten”-knop die slechtere output produceert dan de gebruiker zelf had kunnen schrijven. Deze functies worden uitgebracht, krijgen een persbericht en presteren stilzwijgend onder de verwachte adoptie.

De tweede kwestie is dat teams enorm onderschatten hoe groot het verschil is tussen schone demogegevens en echte productiegegevens. AI-demos draaien op schone, gecurde voorbeelden. Productie draait op de echte rommel van klantgegevens: duplicaten, ontbrekende velden, tien verschillende manieren om dezelfde productnaam te spellen, vijftien jaar legacy-edge cases. Een model dat indrukwekkende nauwkeurigheid bereikt in evaluatie, kan ernstig degraderen op live-gegevens, en de meeste teams ontdekken dit pas als gebruikers klagen. De kosten van die ontdekking in productievertrouwen zijn zelden te herstellen.

Een andere veelvoorkomende mislukking is gebruikersonderzoek. Standaard productinterviews werken niet voor AI-functies. Gebruikers kunnen niet articuleren wat ze van AI willen omdat ze niet weten wat mogelijk is. Vragen “zouden ze AI gebruiken om X te doen?” levert beleefde ja-antwoorden op die geen voorspellende waarde hebben voor adoptie. Effectief AI-productonderzoek vereist het laten zien van prototypes, observeren van echte gebruikerservaringen en meten of gebruikers terugkomen nadat de nieuwheid is verdwenen. Weinig productteams hebben hun onderzoekpraktijk hiervoor herschapen. Ze draaien nog steeds 2019-playbooks op 2026-problemen.

En ten slotte meten veel bedrijven AI-activiteit in plaats van bedrijfsimpact. “Twee honderd mensen gebruikten de AI-functie deze week” is een adoptiemetriek, geen impactmetriek. Echte impact is cyclusduur gereduceerd, kwaliteit verbeterd, omzet gegenereerd of kosten verwijderd. Als u geen rechtstreekse lijn kunt trekken van de AI-functie naar een getal op de P&L, heeft u geen productie-impact. U heeft een dure activiteit.

Er is een vijfde factor die steeds kritieker wordt en die de meeste productteams helemaal missen.

Compliance en de AI-vrije build-pad. Een aanzienlijk deel van de enterprise-gebruikers in financiën, gezondheidszorg, overheid, defensie en juridische diensten werkt onder beleid dat AI-functies in software van leveranciers verbiedt of beperkt. Als uw product AI hard in de core-ervaring integreert zonder manier om het uit te schakelen of te omzeilen, breidt u uw publiek niet uit door AI toe te voegen. U verliest een deel van uw bestaande publiek.

Dit is precies het probleem dat we oplossen met AI Connectivity. Compliance-teams in gereguleerde industrieën zijn niet tegen AI zelf, maar tegen gegevensoverdracht. De oplossing is niet om AI te verwijderen, maar om deze organisaties een AI-architectuur te geven die past bij hun beperkingen. Daarom wordt AI Connectivity als on-premise geleverd: de AI-capaciteit blijft, de gegevens verlaten nooit de infrastructuur van de klant, en inkoop gaat door bij de eerste ronde in plaats van de derde.

De teams die dit goed doen, ontwerpen voor compliance vanaf dag één. De teams die het verkeerd doen, ontdekken het probleem tijdens de inkoopbeoordeling, als de deal al verloren is.

Devart werkt op meerdere database-ecosystemen. Hoe kan AI helpen om de groeiende complexiteit van gegevensbeheer over verschillende platforms te vereenvoudigen?

De pijn is echt. Een typische Fortune 500 draait acht tot twaalf verschillende database-engines tegelijk: legacy Oracle voor financiën, PostgreSQL voor nieuwe diensten, SQL Server voor operaties, Snowflake of BigQuery voor analytics, en steeds vaker een vectorstore voor embeddings. Elk heeft zijn eigen dialect, zijn eigen tooling, zijn eigen governance-regime. Een ontwikkelaar die deze omgeving binnenkomt, kan drie maanden besteden aan het leren waar gegevens wonen en wie er toegang toe heeft.

AI lost die complexiteit niet op zichzelf op. Het versterkt elke context die het krijgt. Acht ongecouplede databases met geen unified metadata produceren acht ongecouplede sets van oppervlakkige suggesties. Dat is precies de foutmodus die we zien in de meeste enterprise-AI-rollouts op stacks.

De kans ligt in een contextlaag die tussen AI-agents en de onderliggende databases zit. Een laag die met allemaal spreekt, metadata normaliseert, unified governance-beleid afdwingt en een schone MCP-interface exposeert, zodat elke AI-agent, of het nu Claude, GPT of een intern model is, over de hele estate werkt met consistente regels.

Daar bouwen we naar toe met AI Connectivity: een on-premise MCP-server met multidatabase-ondersteuning, een semantische laag die bedrijfsdefinities eenmaal vastlegt in plaats van elke AI-agent te dwingen ze opnieuw te leren, rolgebaseerde toegangscontrole op SQL-niveau en volledige auditlogs.

Vereenvoudiging is niet gratis. Iemand moet nog steeds de semantische laag modelleren en beleid instellen. Maar dat werk gebeurt eenmaal, niet herhaaldelijk voor elke AI-agent die je toevoegt.

U heeft grote cross-functionele teams geleid. Hoe verandert AI de interne samenwerking en besluitvorming tussen product, engineering, marketing en sales?

De meeste cross-functionele wrijving was gewoon mensen die op informatie van andere teams wachtten. AI collapseert die wrijving sneller dan enig managementkader ooit kon.

De verschuivingen zijn praktisch en onmiddellijk.

In product en engineering: een productmanager stelt een databasevraag in gewone bedrijfs-termen, “wat is de LTV-variatie over onze top drie prijsniveaus?”, en krijgt een actiebaar antwoord op hetzelfde moment, in plaats van een Jira-ticket in te dienen bij analytics en drie dagen te wachten.

In marketing en data: cohortanalyse gebeurt inline, niet via een aanvraagqueue. De marketingmanager vraagt, krijgt cijfers en bouwt de campagne, allemaal in dezelfde ochtend.

In sales en engineering: technische antwoorden voor prospects hebben geen senior engineer meer nodig. De salesrep krijgt een geloofwaardig technisch antwoord in real-time, en de dealcyclus wordt ingekort.

Beslissingen verhuizen naar het gesprek in plaats van naar het follow-up. Het “ik kom terug bij je met dat nummer”-patroon is dood. Meetings worden korter omdat AI pre-reads en samenvattingen doet die eerder de eerste helft van elke sessie in beslag namen.

Deze collapse van wrijving dwingt een diepere managementverschuiving, en dat is de verschuiving die de meeste leiderschapsTeams onderschatten.

Ieder bedrijf claimt resultaatgericht te zijn. Kijk onder de motorkap en de meeste draaien nog steeds op proxy-metrieken: storypoints, code-regels, tickets gesloten, uren gelogd. We gebruikten activiteit als proxy voor waarde omdat echte waarde moeilijk te meten was. AI breekt die proxy permanent. Wanneer een agent 10.000 regels code kan schrijven of 500 support-tickets kan sluiten in een minuut, wordt het meten van activiteit gevaarlijk misleidend.

We gaan expliciet naar True Result-Oriented Management, waar prestaties strikt worden gemeten door outcome en oordeel. Brutal in de praktijk, omdat de meeste prestatiesystemen niet zijn gebouwd voor dit. Mensen die vroeger achter hoge activiteit konden schuilen, worden onmiddellijk zichtbaar, en leiderschap moet bereid zijn om op die zichtbaarheid te handelen.

De structurele consequentie is platte organisatiekaarten. Coördinatie- en informatieroutingslagen compressen. Organisaties die het snelst aanpassen, zullen opereren met structureel minder mensen op hoger niveau.

Met de opkomst van AI-geassisteerde ontwikkeling en no-code-tools, gaan we naar een toekomst waarin databasebeheer toegankelijk wordt voor niet-technische gebruikers?

Er is een gevaarlijke verwarring in de industrie op dit moment. Mensen behandelen een kleine groene-veld-database en een enterprise-legacy-database alsof ze hetzelfde zijn. Ze zijn het niet.

Voor kleine groene-veld-projecten is democratisering al hier. Ik heb zelf kleine applicaties van scratch gebouwd zonder diepe databasebeheer-skills. Als uw hele schema past in het contextvenster van een LLM, werkt AI als magie. Citizen-ontwikkelaars die interne tools bouwen op kleine schaal, zullen een echte en groeiende categorie zijn.

Enterprise-reality is compleet anders. Grote legacy-databases hebben hetzelfde probleem als grote monolithische codebases: de contextmuur. U kunt vijftien jaar ongedocumenteerde schema-evolutie, cross-database-afhankelijkheden en aangepaste trigger-logica niet in een prompt stoppen. Wanneer AI context verliest op een grote database, hallucinaties degraderen niet elegant. Ze vermenigvuldigen exponentieel.

Het risico dat onderbelicht wordt, is vals vertrouwen op grote schaal. Natuurlijke taalinterfaces zijn uniek goed in het produceren van plausibele maar subtiel verkeerde antwoorden. Als een SQL-query een syntaxisfout heeft, krijgt u een foutbericht. Als een natuurlijke taalinterface “actieve klanten” verkeerd interpreteert omdat uw gegevens zes verschillende definities van activiteit hebben, krijgt u een nummer. Het nummer ziet er goed uit. Het kan 30% verkeerd zijn. De gebruiker heeft geen manier om het te weten.

Dus nee, enterprise-databasebeheer wordt geen speeltuin voor niet-technische gebruikers.

De Citizen-DBA is een mythe op grote schaal.

De toekomst behoort aan expert-data-architecten die professionele tools gebruiken om de contextkloof te overbruggen en infrastructuur te bouwen die AI veilig laat opereren.

De structurele oplossing is de semantische laag: een gecontroleerde vocabulaire waar bedrijfsdefinities eenmaal worden vastgelegd en hergebruikt over elke AI-interactie. Dat is de core-architectuur die we in Insightis bouwen. Zonder dat wordt toegankelijkheid een aansprakelijkheid.

Kijkend naar de toekomst, wat ziet een “AI-natief” ontwikkelaarstool eruit, en hoe moeten teams zich nu voorbereiden op die verschuiving?

Een AI-natief toolkit is niet een chatbot bevestigd aan een IDE. Het meeste dat vandaag als “AI-natief” wordt gemarkeerd, is een chat-interface plus een autocomplete-model. Dat is een basisvereiste, niet de bestemming.

Voor mij is een echt AI-natief toolkit drie dingen nodig.

Ten eerste heeft AI diepe context nodig. Het moet uw codebase, uw infrastructuur, uw historische beslissingen en uw gegevensomgeving continu begrijpen, niet alleen via prompts in een chatvenster. De meeste huidige tools falen deze test. Hun context reset met elke sessie, en de gebruiker betaalt de prijs van het constant opnieuw opbouwen.

Ten tweede moeten de tools zelf goed met elkaar communiceren. Uw IDE moet met uw database praten, de database met uw observatie-stack, en de CI/CD met uw AI-reviewer, enz. Het Model Context Protocol wordt de standaardlaag hier, met 97 miljoen SDK-downloads per maand in Q1 2026, omhoog van 100.000 eind 2024. Dat is een 970x-toename in vijftien maanden en de steilste adoptiecurve die ik ooit heb gezien in developer-infrastructuur.

Ten derde vereist productieklare AI serieuze veiligheidsbarrières. Blast-radius-preview voor destructieve bewerkingen. Afhankelijkheidsanalyse. Automatische rollback-plannen. Audit-trails standaard. AI zonder deze is prima voor prototypes en gevaarlijk in productie.

Hoe te voorbereiden, concreet.

Controleer uw stack tegen deze drie componenten. Heeft elke tool API’s en MCP? Praat het met anderen, of zit het in een silo? Heeft het veiligheidscontroles? Tools die twee van de drie falen, zijn korte-termijnactiva.

Bouw context-infrastructuur nu. Documenteer schema’s, bedrijfsdefinities en architectonische beslissingen in machine-leesbare formaten. Rijke context wordt niet in een kwartaal gebouwd. De teams waarvan AI die in 2027 heeft, zijn de teams die vandaag documenteren.

Run AI in productie voordat u denkt dat u er klaar voor bent. Teams die wachten op een formele “AI-strategie” voordat ze uitbrengen, zullen achttien maanden achter teams liggen die al leren van echte productiefouten. Kies een laag-risico-use-case. Breng het uit. Bouw de spiermassa.

De teams die deze beslissingen vandaag nemen, zullen de komende tien jaar van software-ontwikkeling definiëren. Het venster is smal, en het is nu open.

Bedankt voor het geweldige interview, lezers die meer willen leren, moeten Devart bezoeken.