Anton Onufriienko, administrerende direktør i Devart – Intervieuserie

Anton Onufriienko, administrerende direktør i Devart, er en teknologiuddannet leder og operatør med dyb erfaring i at skala softwareforretninger, drive omsætningsvækst og lede store tværfaglige teams inden for SaaS, enterprise-software og finansielle services. Gennem sin karriere har han udviklet sig 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, prisomlægning og international vækstinitiativer. Han er også CEO af TMetric, en tidssporings- og profitplatform, der fokuserer på at hjælpe servicebaserede forretninger med at opnå operationel klarhed.

Devart er et softwarefirma, der specialiserer sig i databaseudvikling, datakopling, integration og produktivitetstools til udviklere, DBA’er, analytikere og enterprise-teams. 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 og PostgreSQL. Devart udvikler også datakoplingsløsninger som ODBC, ADO.NET, Python og Delphi-tilkoblinger samt Skyvia, deres cloud-baserede no-code dataintegrationsplatform til ETL, automation, backup og workflow-koordination. Virksomheden betjener mere end 500.000 brugere globalt, herunder en stor andel af Fortune 100-organisationer, og har i stigende grad fokuseret på at integrere AI-drevne funktioner i deres 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 har udviklet dig fra at bygge og lede salgsteams til at køre 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. Ved at gå over i en CRO-rolle skalaerede jeg den disciplin over funktioner. At køre 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 rigtige, varige resultater.

Der er en meme, der cirkulerer, 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.

Lektien, jeg fik i salget, er simpel: hver initiativ betaler sin egen vej, eller også dør det. Jeg kører vores AI-udrulning på samme måde, som jeg engang kørte 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 Revenue per Employee, og vores mål er at mere end fordoble det inden udgangen af 2028. Du lukker ikke den lukning ved at ansætte. 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 hurtigt, og de fleste virksomheder vil opdage det på den dyre måde.

Devart har opbygget 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 kun overfladisk automation?

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

Disciplinen var ligetil: 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 især sandt, når dit publikum kan se forskellen med det samme.

Hvad ændrede sig i 2026, er, at AI bevægede sig 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 kapacitet. Vi kan nu løse problemer, der var ægte uløselige før: sikker enterprise-dataadgang til AI-agenter, kontekstuel database-intelligens inde i udviklerens IDE og autonome forretningsanalyser, der ikke kræver en dedikeret analyst.

Disse er nye produktlinjer, der eksisterer, fordi AI gjorde det underliggende problem løseligt. Det er den bar, vi holder os selv til: et rigtigt AI-produkt er et, hvor fjernelse af AI-laget ødelægger produktet. Industrien har brugt to år på at kalde chat-paneller “AI-produkter.” Det 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 det ændrer rollen for udviklere, der arbejder med databaser over 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 følgende: 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 produktionsikkerhed. Præmien på databaseekspertise forsvinder ikke; den flytter sig opad mod design, styring og dømmekraft, som er præcis det, AI ikke kan operere alene.

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

Nuværende AI er stadig fast i overfladisk automation. At generere en grundlæggende SELECT-forespørgsel eller kodelås 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 udførelsesplaner, 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 over for det på database-laget. En hallucineret JOIN kan langsætte produktions-systemer. En forkert UPDATE kan slette kritiske poster. På det niveau bliver selv små fejl meget dyre meget hurtigt.

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

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

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

En anden ændring er AI, der fungerer mere som en senior DBA i baggrunden. Kontinuerligt at analysere arbejdsbelastninger, identificere flaskehalse, foreslå indekser, spotte risikable forespørgsler og fange problemer, før systemer fejler.

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

Det er de udviklinger, der vil forme de næste fem års database-væ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 zero-click-realiteten. AI-søgning leverer svar direkte på resultatsiden og berøver websteder for trafik. Stærke rankings oversætter sig ikke længere 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 bare en 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, vil AI-systemer ikke fremhæve det konsekvent. Du mister ikke kun 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 har finansieret en generation af B2B SaaS, mister effektivitet hurtigt. Enhver, der stadig afhænger af dem som primær vækst-mekanisme, bør aktivt bygge alternativer lige nu: økosystem-distribution, fællesskab og partnerskaber.

Pris-ændring: fra sæder til PLG 3.0. Vi går ind i den næste fase af PLG. Pris-sætning per sæde begynder at bryde sammen, når en AI-agent kan udføre arbejdet for flere medarbejdere. I det miljø stopper det med at give mening at belaste efter hovedantal. Virksomheder, der ikke genpakker produkter omkring værdi snarere end hovedantal, 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 menneskelig, vurderer, tester og køber enterprise-software. Mass-adopterings-mønster er stadig et par år ude, men at arkitektur-produkter og prissætning for maskin-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 brugerne 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 bad om. Når en AI-funktion bliver pålagt uden en ægte brugerbehov, arbejder teamet 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 holdene kraftigt undervurderer forskellen mellem ren demo-data og rigtig produktions-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 forringe betydeligt på live-data, og de fleste hold opdager det ikke, før brugere klager.

En anden almindelig fejl er bruger-undersøgelse. Standard-produkt-interviews fungerer ikke for AI-funktioner. Brugere kan ikke udtrykke, 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. Få produkt-hold har genopbygget deres forskningspraksis til dette. De kører stadig 2019-playbooks på 2026-problemer.

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 direkte 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 den AI-frie 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 direkte til den centrale oplevelse 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-tilslutning. 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-tilslutning 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.

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

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

Smerterne er rigtige. En typisk Fortune 500-kørsel kører otte til tolv forskellige database-motorer samtidigt: legacy Oracle til finans, PostgreSQL til nye tjenester, SQL Server til drift, Snowflake eller BigQuery til analytics og stadig en vektor-lager 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 lov til at røre det.

AI løser ikke den kompleksitet på egen hånd. Det forstærker blot den kontekst, det får. Otte ikke-tilsluttede databaser med ingen fælles metadata producerer otte ikke-tilsluttede 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 et kontekst-lag, der sidder mellem AI-agenter og de underliggende databaser. Et lag, der taler til alle, normaliserer metadata, gennemtvinger fælles styrings-politikker og eksponerer en ren MCP-grænseflade, så enhver AI-agent, enten Claude, GPT eller en intern model, kan arbejde på tværs af hele ejendommen med konsekvente regler.

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

Simplificering er ikke gratis. Nogen må stadig modelere det semantiske lag og fastsætte politik. Men det arbejde sker én gang, ikke gentaget for hver AI-agent, du tilføjer.

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

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

Ændringerne er praktiske og umiddelbare.

I produkt og ingeniør: en produkt-manager stiller et database-spørgsmål i almindelige forretnings-termer, “hvad er LTV-variansen på vores top tre prissætnings-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 en senior-ingeniør. Salgs-repræsentanten får et troværdigt teknisk svar i realtid, og deal-cyklen komprimeres.

Beslutninger flytter ind i samtalen snarere end i opfølgningen. Mønstret “lad mig vende tilbage til dig med det tal” dør. Møderne bliver kortere, fordi AI håndterer forlæsninger og sammenfattelser, der tidligere optog den første halvdel af hver session.

Dette kollaps af friktion tvinger en dybere ledelses-ændring, og det er den, de fleste ledelseshold undervurderer.

Hvert selskab påstår at være resultatorienteret. Kig under hood’en, og de fleste kører stadig på proxy-målepunkter: historier, kode-linjer, billetter lukket, timer logget. Vi brugte aktivitet som en proxy for værdi, fordi virkelig værdi var svær at måle. AI bryder 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 efter resultat 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å det.

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

Med opkomsten af AI-assisteret udvikling og ikke-kode-værktøjer, bevæger vi os mod en fremtid, hvor database-administration bliver tilgængelig for ikke-tekniske brugere?

Der er en farlig forvirring i industrien lige nu. Folk 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 database-administrations-erfaring. Hvis 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-realiteten er helt anderledes. Store arv-databaser står over for det samme problem som store 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, hallucinationer degraderer ikke smukt. De multiplicerer eksponentielt.

Risikoen, der underdiskuteres, er falsk tillid på stor 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-database-administration bliver ikke en legeplads for ikke-tekniske brugere.

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

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

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

Set fremad, hvad ser et “AI-nativt” udvikler-værktøj ud som, og hvordan bør holdene starte med at forberede sig på den ændring i dag?

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

Til mig kræver et rigtigt AI-nativt værktøj tre ting.

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

For det andet kræver værktøjerne at 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-revisor, osv. Model-Context-Protokollen bliver standard-laget her, med 97 millioner SDK-downloads per måned i Q1 2026, op fra 100.000 i slutningen af 2024. Det er den stejleste antagelses-kurve, jeg har set i udvikler-infrastruktur.

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

Hvordan forberede sig konkrekt.

Gennemgå din stack mod disse tre komponenter. Åbner hver 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. Holdene, hvis AI har det i 2027, er dem, der dokumenterer i dag.

Kør AI i produktion, før du tror, du er klar. 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. Skib det. Byg musklen.

Holdene, der tager disse beslutninger i dag, vil definere den næste årti, 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.