Anton Onufriienko, administrerende direktør i Devart – Interview-serie

Anton Onufriienko, administrerende direktør i Devart, er en teknologiuddannelses- og operatørserfaring med dyb erfaring i at skala softwareforretninger, drive omsætningsvækst og lede store tværfaglige hold på tværs af SaaS, enterprise software og finansielle tjenester. I løbet af sin karriere er han gået fra at bygge salgsorganisationer og lancere startups til at overvåge fuld P&L-drift for store forretningsenheder, herunder Devarts største afdeling med mere end 130 medarbejdere. Før han blev administrerende direktør, fungerede han som Devarts Chief Revenue Officer og Head of Sales, hvor han ledte go-to-market-strategi, prisomdanning og international vækstinitiativer. Han er også CEO af TMetric, en tidssporings- og profitplatform, der fokuserer på at hjælpe service-drevne forretninger med at opnå operationel klarhed.

Devart er et softwarefirma, der specialiserer sig i databaseudvikling, dataconnectivitet, integration og produktivitetstjenester til udviklere, DBA’er, analytikere og enterprisehold. Grundlagt i 1997 er virksomheden bedst kendt for sin dbForge-suite af databaseadministrationsværktøjer, der understøtter større databasesystemer, herunder SQL Server, MySQL, Oracle (ORCL ) og PostgreSQL. Devart udvikler også dataconnectivitetsløsninger som ODBC, ADO.NET, Python og Delphi-connectorer samt Skyvia, dens cloud-baserede no-code dataintegrationsplatform til ETL, automation, backup og workflow-koordinering. Virksomheden betjener mere end 500.000 brugere på verdensplan, herunder en stor andel af Fortune 100-virksomheder, og har i stigende grad fokuseret på at integrere AI-drevne funktioner i sine produkter gennem værktøjer som dbForge AI Assistant, der hjælper udviklere med at generere, optimere, fejlfinde og forklare SQL-forespørgsler ved hjælp af naturligt sprog.

Du er gået fra at bygge og lede salgshold til at løbe fuld P&L-drift og nu administrere Devarts største forretningsenhed. Hvordan har den rejse formet din tilgang til at integrere AI i produktstrategi og beslutningstagning i stor målestok?

Salget lærte mig at måle ROI på alt. Da jeg gik over i en CRO-rolle, skalaerede jeg den disciplin over funktioner. At løbe BU tvang mig til at anvende det på AI selv.

Jeg tager en praktisk tilgang til AI. Det er ikke, fordi jeg er tvivlende: tre af vores fire produktindsatser for 2026 er AI-naturlige. Men jeg tror, at hype kommer i vejen for virkelige og varige resultater.

Der er en meme, der går rundt, som summerer op, hvor industrien ofte går galt. Virksomheder bytter $400 SaaS-abonnementer ud med hjemmebyggede værktøjer, der koster $1.000 om måneden i API-gebyrer og kræver konstante reparationer. Det er ikke rigtig forandring, det er bare en dyrekøbt forestilling.

Lektionen, jeg fik i salget, er simpel: hver initiativ betaler sin egen vej, eller også dør den. Jeg løber vores AI-udrulning på samme måde, som jeg engang løb et salgsområde. Eksplizit ROI-hypotese per workflow, en tre-bølge-udrulning og dokumenteret påvirkning før skala.

Vores Nordstjerne-målepunkt er Omsætning pr. Medarbejder, og vores mål er at mere end fordoble det inden udgangen af 2028. Du lukker ikke den lukning ved at hyre. Du lukker den ved at ændre, hvordan arbejdet ser ud, og AI er den eneste realistiske mekanisme i den størrelsesorden.

Min filter på hver AI-initiativ, internt eller produkt, er den samme: hvad er den målte værdi, hvem betaler for det, og hvordan ved vi, at det fungerede? Alt, der ikke opfylder disse tre spørgsmål, hører ikke hjemme i produktion. Omkostningerne ved at gå galt her kompenserer sig hurtigt, og de fleste virksomheder vil opdage det på den dyre måde.

Devart har bygget en stærk rygte omkring databaseværktøjer og udviklerproduktivitet. Hvordan integrerer I AI i disse produkter på en måde, der leverer rigtig værdi og ikke blot overfladisk automation?

Vore brugere er hårdkogte tekniske specialister: DBA’er, senioringeniører, dataarkitekter. De kan opdage overfladisk automation på få sekunder og resenterer at blive solgt markedsføringslegetøj klædt som innovation. For to år siden, da AI-hype toppede og konkurrenterne kapløb for atbolt chat-paneller på hver enkelt brugergrænseflade, var fristelsen til at følge med real. Jeg havde set det mønster før, i mobile, i cloud, i low-code, og jeg nægtede at gentage det.

Disciplinen var ligefrem: kunde-værdi først. At bygge AI-funktioner, som ingen bad om, som ikke leverer rigtig værdi, er den værste mulige brug af begrænsede ingeniørressourcer. Det er særligt sandt, når dit publikum kan se forskellen med det samme.

Hvad ændrede sig i 2026, var, at AI gik fra hype til en rigtig teknisk revolution. Gapet mellem, hvad disse systemer kunne gøre i 2023, og hvad de kan gøre i dag, er ikke inkrementelt. Det er en helt anden kategori af funktioner. Vi kan nu løse problemer, som var virkelig uløselige før: sikker virksomhedsadgang til AI-agenter, kontekstuel database-intelligens inde i udviklerens IDE og selvstændige forretningsanalyser, der ikke kræver en dedikeret analyst.

Disse er nye produktlinjer, der eksisterer, fordi AI gjorde den underliggende problem løselig. Det er den bar, vi holder os til: et rigtigt AI-produkt er et, hvor fjernelse af AI-laget ødelægger produktet. Branchen har brugt to år på at kalde chat-paneller “AI-produkter.” Disse er funktioner, ikke produkter.

Vi tog længere tid, fordi vi ville gøre det rigtigt. De næste tolv måneder vil vise, om den disciplin betalte sig.

AI skriver, optimerer og fejlfinder kode i stigende grad. Hvordan ser du, at dette ændrer rollen for udviklere, der arbejder med databaser i de næste få år?

Værdien af at kende SQL-syntaks er under udvinding hurtigt. Hvis AI kan generere en kompleks multi-table JOIN på få sekunder og identificere manglende indekser fra logfiler på få minutter, kommer en ingeniørs værdi ikke længere fra at skrive SQL. Den del af jobbet bliver en vare.

Men her er den kritiske nuance, som evangelister for total automation altid springer over. En AI-fejl på frontend er en misjusteret knap, du kan genindlæse. En AI-fejl på database er en slettet produktionsmiljø, en PII-læk eller en transaktionslukning af hele forretningen.

Databaser indeholder tilstand. De tilgiver ikke hallucinationer.

Den asymmetri omdefinerer rollen fuldstændigt. Over de næste to til tre år vil databaseudviklere og DBA’er udvikle sig fra kodere til arkitekter og revisorer. Deres primære arbejde skifter til tre ting:

• At designe pålidelige arkitekturer, som AI ikke kan forstå på egen hånd, fordi det mangler forretningskontekst.
• At fastsætte hårde retningslinjer og sikkerheds politikker for AI-agenter, der rører produktions systemer.
• At gennemgå og auditere den kode, maskinerne genererer, før den når database.

Tankemodellen, jeg vender tilbage til, er: ingeniører vil styre hære af AI-assistenter. Værktøjer som dbForge vil måtte udvikle sig fra traditionelle IDE’er til kommando- og auditcenter. Arbejdet bliver mindre om at skrive SQL manuelt og mere om at gennemgå, hvad AI genererer, validere det og påtvinge grænser, som AI ikke kan krydse sikkert.

Den professionelle mulighed her er betydelig. Udviklere, der udvikler sig til arkitektur og tilsyn, vil multiplicere deres markedsværdi. De bliver det uundværlige lag mellem AI-produktivitet og produktionssikkerhed. Præmien på databaseekspertise forsvinder ikke; den flytter sig opad mod design, styring og dømmekraft, som er præcis det, hvor AI ikke kan fungere alene.

Hvad er de største begrænsninger for nuværende AI-værktøjer i databasehåndtering i dag, og hvor ser du de mest meningsfulde gennembrud komme fra?

Nuværende AI er stadig fast i overfladisk automation. At generere en grundlæggende SELECT-forespørgsel eller boilerplate-kode er ikke længere imponerende. Det større problem er, at de fleste AI-systemer stadig opfører sig som blinde maskinister snarere end systemarkitekter. De kan generere syntaks, men de forstår ikke virkelig det miljø, de opererer i. Det rigtige gennembrud sker, når AI begynder at forstå kontekst, afhængigheder, tilstand og forretningslogik sammen.

Lige nu ser jeg tre store begrænsninger, der holder AI tilbage i database-miljøer.

Først og fremmest er der kontekst-problemet. Store sprogmodeller kan se skemaer, DDL og kolonne-navne, men de forstår ikke virkelig kørselsplaner, indeksfragmentering, datafordelingsmønstre eller den virkelige forretningslogik bag data. Uden den dybere forståelse bliver meget optimeringsråd statistisk gætteri klædt som ekspertise.

For det andet er der hallucinations-problemet, og virksomheder har næsten nul tolerance for det på database-laget. En hallucineret JOIN kan langsætte produktions systemer. En forkert OPDATER kan slette kritiske poster. På det niveau bliver selv små fejl meget dyre meget hurtigt.

Tredje problem er sikkerhed og styring. Ingen alvorlig virksomhed vil indsætte produktions-skemaer eller PII i en offentlig AI-værktøj uden stærke garantier om data-adskillelse og kontrol. Indtil leverandører løser det ordentligt, vil AI-adoptionsgraden i regulerede industrier forblive begrænsket.

De meningsfulde gennembrud vil komme, når AI bevæger sig ud over syntaks-generering og begynder at fungere mere som en baggrundsarkitekt eller -analytiker.

En del af det er den semantiske lag: at gå fra rå tabelnavne til virkelig forretningsbetydning. Ikke bare “table_users”, men at forstå begreber som kunde-kohorter, churn-risiko eller Q3 LTV-tendenser.

En anden skift er AI, der fungerer mere som en senior DBA i baggrunden. Kontinuerligt analyserer arbejdsbelastninger, identificerer flaskehalse, foreslår indekser, spotter risikable forespørgsler og fanger problemer, før systemerne fejler.

Så har du maskine-til-maskine-operationer, hvor autonome agenter overvåger databasebelastning, tester optimeringsstrategier i isolerede miljøer og implementerer forbedringer under menneskelig overvågning.

Disse er de udviklinger, der vil forme de næste fem års databaseværktøjer.

Fra din erfaring med at lede omsætning og go-to-market-strategi, hvordan ændrer AI prissætningsmodeller, produkt-pakning og kundeanskaffelse i software-virksomheder?

Den traditionelle go-to-market-playbook er brudt. Vi ser det i vores egne tal og på tværs af hele dev-værktøjskategorien.

Døden af klassiskanskaffelse. Trods betydelige forbedringer i søge-rankings på tværs af vores produkter i 2026, rammer vi den nul-klik-realitet. AI-søgning leverer svar direkte på resultatsiden og berøver websteder for trafik. Stærke rankings betyder ikke længere føre til leads, som de gjorde blot to år siden.

For fem år siden var en stærk indholdstrategi nok til at drive vækst. I dag er det blot basis. LLM’er væger mærke-styrke, positive nævnelser og fællesskabs-tæthed, når de former svar. Hvis dit mærke ikke er synligt og troværdigt, stopper AI-systemer med at fremhæve det konsekvent. Du mister ikke blot trafik. Du forsvinder fra købs-rejsen helt.

Dette skift rammer traditionelle dev-værktøjs-virksomheder særligt hårdt. SEO-drevne anskaffelseskanaler, der finansierede en generation af B2B SaaS, mister hurtigt effektivitet. Enhver, der stadig afhænger af dem som primær vækst-læs, skal aktivt bygge alternativer lige nu: økosystem-distribution, fællesskab og partnerskaber.

Pris-evolution: fra sæder til PLG 3.0. Vi går ind i den næste fase af PLG. Pris per sæde begynder at bryde sammen, når en AI-agent kan gøre arbejdet for flere medarbejdere. I det miljø stopper det med at have mening at beregne prisen ud fra headcount. Virksomheder, der ikke genpakker produkter omkring værdi snarere end headcount, vil miste MRR over de næste 24 måneder.

Næste skridt er PLG 3.0: øjeblikket, hvor en autonome AI-agent, ikke en menneske, vurderer, tester og køber enterprise-software. Mass-adoptions-mønster er stadig et par år ude, men at arkitektur-produkter og prissætning for maskine-køberen er en opgave for 2026, ikke 2028.

Mange organisationer kæmper med at flytte fra AI-eksperimenter til rigtig produktion-påvirkning. Hvad er de nøglefaktorer, der bestemmer, om AI-initiativer faktisk lykkes?

De fleste AI-funktioner fejler, før de er bygget. De fejler i rummet, hvor nogen siger “vi har brug for AI i dette produkt,” ikke fordi brugere bad om det, men fordi bestyrelsen ønsker en AI-historie eller marketing mener, det vil tiltrække en ny publikum. Det er den oprindelige synd af de fleste AI-initiativer, og det former alt, der følger.

Jeg ser de samme fejl gentaget i virksomheder, der kæmper med at flytte AI fra eksperimenter til rigtig produktion-påvirkning.

Den første fejl er at bygge AI-funktioner, som ingen virkelig bad om. Når en AI-funktion er pålagt uden en ægte brugerbehov, arbejder holdet baglæns fra teknologien for at opfinde en brugs-sag. Resultatet er forudsigeligt: en chat-panel boltet på en eksisterende brugergrænseflade, en autocomplete, der kommer i vejen, en “samlet”-knap, der producerer dårligere output, end brugeren selv kunne skrive.

Den anden fejl er, at hold massive underestimerer forskellen mellem ren demo-data og rigtig produktion-data. AI-demos kører på ren, kurateret data. Produktion kører på den virkelige rod af kunde-data: duplikater, manglende felter, ti forskellige måder at stave det samme produkt-navn på, femten års legacy-kant-sager. En model, der opnår imponerende nøjagtighed i evaluering, kan degradere kraftigt på live-data, og de fleste hold opdager det ikke, før brugere klager.

En anden almindelig fejl er bruger-undersøgelse. Standard produkt-interview fungerer ikke for AI-funktioner. Brugere kan ikke articulere, hvad de vil have fra AI, fordi de ikke ved, hvad der er muligt. At spørge “ville du bruge AI til at gøre X?” får høflige ja-svar, der ikke har nogen forudsigelig værdi for adoption. Effektiv AI-produkt-forskning kræver at vise prototyper, observere rigtig brug og måle, om brugere vender tilbage, efter nysgerrigheden er forsvundet.

Og endelig måler mange virksomheder AI-aktivitet i stedet for forretnings-påvirkning. “To hundrede personer brugte AI-funktionen denne uge” er en anskaffelses-målepunkt, ikke en påvirknings-målepunkt. Rigelig påvirkning er cyklus-tid reduceret, kvalitet forbedret, omsætning genereret eller omkostninger fjernet. Hvis du ikke kan tegne en lige linje fra AI-funktionen til et tal på P&L, har du ikke en produktion-påvirkning. Du har en dyrekøbt aktivitet.

Der er en femte faktor, der bliver mere og mere kritisk, og som de fleste produkt-hold overser helt.

Overholdelse og AI-fri bygge-vej. En betydelig andel af enterprise-brugere i finans, sundhed, regering, forsvar og ret opererer under politikker, der forbyder eller begrænser AI-funktioner i vendor-software. Hvis dit produkt binder AI-funktioner sammen med kerne-oplevelsen uden en måde at deaktivere eller omgå det på, udvider du ikke dit publikum ved at tilføje AI. Du mister en sektor af dit eksisterende.

Dette er præcis det problem, vi løser med AI-Connectivity. Overholdelses-hold i regulerede industrier modsætter sig ikke AI selv. De modsætter sig data, der forlader deres perimeter. Løsningen er ikke at fjerne AI; det er at give disse organisationer en AI-arkitektur, der passer deres begrænsninger. Det er derfor, AI-Connectivity leveres som on-premise: AI-kapaciteten bliver, data forlader aldrig kundens infrastruktur, og indkøb passer gennem revision på første runde i stedet for tredje.

Hold, der får det rigtigt, arkitektur for overholdelse fra dag én. Hold, der får det galt, opdager problemet under indkøbs-gennemgang, når aftalen allerede er tabt.

Devart opererer på tværs af multiple database-økosystemer. Hvordan kan AI hjælpe med at simplificere den voksende kompleksitet ved at håndtere data på tværs af forskellige platforme?

Smerterne er rigtige. En typisk Fortune 500-kunde kører otte til tolv forskellige database-motorer samtidigt: legacy Oracle til finans, PostgreSQL til nye tjenester, SQL Server til operationer, Snowflake eller BigQuery til analytics og stadig en vektor-lagring til indlejring. Hver har sin egen dialekt, sin egen værktøjs-samling, sin egen styrings-regime. En udvikler, der tilslutter sig det miljø, kan bruge tre måneder på bare at lære, hvor data bor og hvem der har tilladelse til at røre det.

AI løser ikke den kompleksitet på egen hånd. Det forstærker bare den kontekst, det får. Otte ikke-tilkoblede databaser med ingen fælles metadata producerer otte ikke-tilkoblede sæt af overfladiske forslag. Det er præcis fejl-mønsteret, vi ser i de fleste enterprise-AI-udrulninger på stacks.

Muligheden ligger i en kontekst-lag, der sidder mellem AI-agenter og de underliggende databaser. En, der taler til alle, normaliserer metadata, gennemtvinger fælles styrings-politikker og eksponerer en ren MCP-grænseflade, så enhver AI-agent, uanset om det er Claude, GPT eller en intern model, kan arbejde på tværs af hele ejendommen med konsistente regler.

Det er den arkitektur, vi bygger mod med AI-Connectivity: en on-premise MCP-server med multi-database-understøttelse, en semantisk lag, der fanger forretnings-definitioner en gang i stedet for at tvinge hver AI-agent til at genlære dem, rolle-baseret adgangskontrol på SQL-operation-niveau og fulde audit-logs.

Simplificering er ikke gratis. Nogen skal stadig model-lægge den semantiske lag og fastsætte politik. Men det arbejde sker en gang, ikke gentaget for hver AI-agent, du tilføjer.

Du har ledt store tværfaglige hold. Hvordan ændrer AI intern samarbejde og beslutningstagning mellem produkt, ingeniør, marketing og salg?

De fleste tværfaglige gnidninger var bare mennesker, der ventede på information fra andre hold. AI kollapser den gnidning hurtigere, end nogen ledelses-ramme nogensinde kunne.

Skiftene er praktiske og umiddelbare.

I produkt og ingeniør: en produkt-manager stiller en database-spørgsmål på rent forretnings-sprog, “hvad er LTV-variansen på vores top tre pris-niveauer?”, og får et brugbart svar på stedet, i stedet for at indsende en Jira-billet til analytics og vente tre dage.

I marketing og data: kohort-analyse sker inline, ikke gennem en anmodning-kø. Marketing-manageren stiller spørgsmål, får tal og bygger kampagnen, alt på samme morgen.

I salg og ingeniør: tekniske svar til kunder kræver ikke længere at planlægge et opkald med en senior-ingeniør. Salgs-repræsentanten får et troværdigt teknisk svar i realtid, og salgs-cyklen komprimeres.

Beslutninger flytter ind i samtalen i stedet for at flytte ind i opfølgningen. “Lad mig vende tilbage til dig med det tal” mønsteret dør. Møderne bliver kortere, fordi AI håndterer forhånds-læsninger og sammenfattelser, der tidligere optog den første halvdel af hver session.

Dette kollaps af gnidning tvinger en dybere ledelses-skift, og det er det, de fleste ledelseshold undervurderer.

Hver virksomhed påstår at være resultatorienteret. Kig under huden, og de fleste kører stadig på proxy-målepunkter: historier, kode-linjer, billetter lukket, timer logget. Vi brugte aktivitet som proxy for værdi, fordi virkelig værdi var svær at måle. AI brækker den proxy permanent. Når en agent kan skrive 10.000 kode-linjer eller lukke 500 support-billetter på et minut, bliver måling af aktivitet farligt misvisende.

Vi bevæger os eksplicit til sandt Resultat-Orienteret Ledelse, hvor præstation måles strengt af udfald og dømmekraft. Brutalt i praksis, fordi de fleste præstations-systemer ikke er bygget til det. Mennesker, der tidligere gemte sig bag høj aktivitet, bliver synlige med det samme, og ledelse må være villig til at handle på den synlighed.

Den strukturelle konsekvens er fladere organisations-diagrammer. Koordinations- og informations-routings-lag komprimeres. Virksomheder, der tilpasser sig hurtigst, vil operere med strukturelt færre mennesker på højere gevind.

Med opkomsten af AI-assisteret udvikling og no-code-værktøjer, bevæger vi os mod en fremtid, hvor databasehåndtering bliver tilgængelig for ikke-tekniske brugere?

Der er en farlig forvirring i branchen lige nu. Mennesker behandler en side-projekt-database og en enterprise-arv-database, som om de var det samme. De er ikke.

For små grøn-felt-projekter er demokratisering allerede her. Jeg har personligt bygget små applikationer fra bunden uden dyb databasehåndtering-erfaring. Hvis hele dit skema passer inden for en LLM’s kontekst-vindue, fungerer AI som magi. Borger-udviklere, der bygger interne værktøjer på små skala, vil være en rigtig og voksende kategori.

Enterprise-reality er helt anderledes. Kæmpe-arv-databaser står over for det samme problem som kæmpe-monolitisk kode-baser: kontekst-væggen. Du kan ikke få 15 års udokumenteret skema-udvikling, cross-database-afhængigheder og brugerdefineret trigger-logik inden for en prompt. Når AI mister kontekst på en stor database, degraderer hallucinationer ikke smukt. De multiplicerer eksponentielt.

Risikoen, der underdiskuteres, er falsk tillid på skala. Naturlige sprog-grænseflader er unikt gode til at producere plausibelt udseende, men subtilt forkerte svar. Hvis en SQL-forespørgsel har en syntaks-fejl, får du en fejl-meddelelse. Hvis en naturlig sprog-grænseflade misforstår “aktive kunder”, fordi din data har seks forskellige definitioner af aktivitet, får du et tal. Tallet ser fint ud. Det kan være forkert med 30%. Brugeren har ingen måde at vide det på.

Så nej, enterprise-databasehåndtering bliver ikke en legeplads for ikke-tekniske brugere.

Borger-DBA’en er en myte på skala.

Fremtiden tilhører eksperter i data-arkitektur, der bruger professionelle værktøjer til at brobygge kontekst-gabet og bygge infrastruktur, der lader AI operere sikkert oven på.

Den strukturelle løsning er den semantiske lag: en kontrolleret vokabular, hvor forretnings-definitioner er fastsat en gang og genbrugt på tværs af hver AI-interaktion. Det er den kerne-arkitektur, vi bygger ind i Insightis. Uden det bliver tilgængelighed en byrde.

At se fremad, hvad ligner et “AI-naturligt” udvikler-værktøj, og hvordan skal hold forberede sig på den skift i dag?

Et AI-naturligt værktøj er ikke en chatbot boltet på en IDE. Det meste, der markedsføres som “AI-naturligt” i dag, er en chat-grænseflade plus en autocomplete-model. Det er basis, ikke destination.

Til mig behøver et virkelig AI-naturligt værktøj tre ting.

Først og fremmest behøver AI dyb kontekst. Det må forstå din kodebase, din infrastruktur, dine historiske beslutninger og din data-miljø kontinuerligt, ikke blot gennem prompts indsendt i en chat-vindue. De fleste nuværende værktøjer fejler denne test. Deres kontekst nulstilles med hver session, og brugeren betaler omkostningerne ved at genopbygge det konstant.

For det andet må værktøjerne selv kommunikere ordentligt med hinanden. Din IDE må tale med din database, din database med din overvågnings-stack, og din CI/CD med din AI-analytiker, osv. Model-Context-Protocol bliver standard-laget her, med 97 millioner SDK-downloads om måneden i Q1 2026, op fra 100.000 i slutningen af 2024. Det er en 970-gangs øgning på femten måneder og den stejleste adoptions-kurve, jeg har set i udvikler-infrastruktur.

For det tredje kræver produktions-klar AI seriøse sikkerheds-værker. Blast-radius-forhåndsvisning før destruktive operationer. Afhængigheds-analyse. Automatiske rollback-planer. Audit-logs som standard. AI uden disse er fin til prototyper og farlig i produktion.

Hvordan forberede sig, konkrekt.

Gennemgang din stack mod disse tre komponenter. Åbner hvert værktøj API’er og MCP? Talere de til hinanden, eller sidder de i en silo? Har de sikkerheds-kontroller? Værktøjer, der fejler to af tre, er kort-sigtede aktiver.

Byg kontekst-infrastruktur nu. Dokument skema, forretnings-definitioner og arkitektur-beslutninger i maskin-læsbare formater. Rig kontekst bygges ikke på en kvartal. Hold, hvis AI har det i 2027, er de, der dokumenterer i dag.

Kør AI i produktion, før du tror, du er parat. Hold, der venter på en formel “AI-strategi”, før de udskiber, vil være atten måneder bagud på hold, der allerede lærer af rigtige produktion-fejl. Vælg en lav-risiko-brugs-sag. Udgiv det. Byg musklen.

Hold, der tager disse beslutninger i dag, vil definere den næste årti af, hvordan software bliver bygget. Vinduet er smalt, og det er åbent lige nu.

Tak for det gode interview. Læsere, der ønsker at lære mere, skal besøge Devart.