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

Anton Onufriienko, administrerende direktør i Devart, er en teknologileder og operatør med dypt erfaring med å skalerer programvareforretninger, drive omsetningsvekst og lede store tverrfaglige team over SaaS, bedriftsprogramvare og finansielle tjenester. I løpet av sin karriere har han gått fra å bygge salgsorganisasjoner og lansere startup-selskaper til å overvåke fullstendige P&L-operasjoner for store forretningsenheter, inkludert Devarts største avdeling med over 130 ansatte. Før han ble administrerende direktør, var han Devarts Chief Revenue Officer og salgsleder, der han ledet markedstrategi, pristransformasjon og internasjonal vekst. Han er også CEO i TMetric, en tidssporings- og lønnsomhetsplattform som fokuserer på å hjelpe tjeneste-drevne bedrifter å oppnå operasjonell klarhet.

Devart er et programvareselskap som spesialiserer seg på databaseutvikling, datakobling, integrasjon og produktivitetsverktøy for utviklere, DBAer, analytikere og bedriftsteam. Grunnlagt i 1997, er selskapet best kjent for sin dbForge-suite av databasehåndteringverktøy, som støtter store databasesystemer som SQL Server, MySQL, Oracle (ORCL ) og PostgreSQL. Devart utvikler også datakoblingsløsninger som ODBC, ADO.NET, Python og Delphi-tilkoblinger, samt Skyvia, sin skybaserte kodefrie dataintegrasjonsplattform for ETL, automatisering, backup og arbeidsflyt-orkestrasjon. Selskapet betjener over 500 000 brukere globalt, inkludert en stor andel av Fortune 100-organisasjoner, og har i økende grad fokusert på å integrere AI-drevne funksjoner i sine produkter gjennom verktøy som dbForge AI Assistant, som hjelper utviklere å generere, optimalisere, feilsøke og forklare SQL-forespørsler ved hjelp av naturlig språk.

Du har gått fra å bygge og lede salgsteam til å drive fullstendige P&L-operasjoner og nå lede Devarts største forretningsenhet. Hvordan har denne reisen formet din tilnærming til å integrere AI i produktstrategi og beslutningstaking på stor skala?

Salget lærte meg å måle ROI på alt. Ved å gå over i en CRO-rolle, skalerte jeg denne disiplinen over funksjoner. Å drive BU tvang meg til å anvende det på AI selv.

Jeg tar en praktisk tilnærming til AI. Det er ikke at jeg er skeptisk: tre av våre fire produktveddemål for 2026 er AI-naturlige. Men jeg tror at hype kommer i veien for virkelige, varige resultater.

Det er en meme som går rundt som summerer opp hvor industrien ofte går galt. Selskaper bytter ut $400 SaaS-abonnementer med hjemmelagde verktøy som koster $1000 per måned i API-gebyrer og trenger konstant fiksering. Det er ikke virkelig endring, det er bare en kostbar forestilling.

Leksjonen jeg plukket opp i salget er enkel: hver initiativ betaler sin egen vei, eller det dør. Jeg kjører vår AI-utrulling på samme måte som jeg en gang kjørte et salgsområde. Eksplisitt ROI-hypotese per arbeidsflyt, en tre-bølge-utrulling og dokumentert påvirkning før skalerings.

Vår nordstjerne-måling er Omsetning per Ansatt, og vårt mål er å mer enn doble det innen utgangen av 2028. Du lukker ikke den gapen ved å ansette. Du lukker den ved å endre hva arbeid ligner, og AI er den eneste realistiske mekanismen i den størrelsen.

Min filter på hver AI-initiativ, internt eller produkt, er den samme: hva er den målte verdien, hvem betaler for det, og hvordan vet vi at det fungerte? Alt som feiler disse tre spørsmålene hører ikke hjemme i produksjon. Kostnadene ved å gå galt her kompenserer raskt, og de fleste selskaper vil finne det ut på den dyre måten.

Devart har bygget en sterk reputasjon rundt databaseverktøy og utviklerproduktivitet. Hvordan integrerer du AI i disse produktene på en måte som leverer virkelig verdi i stedet for overfladisk automatisering?

Våre brukere er hardcore tekniske spesialister: DBAer, senioringeniører, dataarkitekter. De kan oppdage overfladisk automatisering på noen sekunder og misliker å bli solgt markedsleker utkledd som innovasjon. For to år siden, da AI-hype toppet og konkurrenter kapret å lime chat-paneler på hver UI-element, var fristelsen til å følge med virkelig. Jeg hadde sett den mønsteren før, i mobil, i sky, i lavkode, og jeg nektet å gjenta det.

Disiplinen var rett frem: kundeverdi først. Bygging av AI-funksjoner som ingen ba om, som ikke leverer virkelig verdi, er den verste mulige bruken av begrensede ingeniørressurser. Det er spesielt sant når din målgruppe kan se forskjellen umiddelbart.

Hva endret i 2026 er at AI flyttet fra hype til en virkelig teknisk revolusjon. Gapet mellom hva disse systemene kunne gjøre i 2023 og hva de kan gjøre i dag er ikke inkrementelt. Det er en fullstendig annen kategori av funksjoner. Vi kan nå løse problemer som var virkelig uløselige før: sikker bedriftsdata-tilgang for AI-agenter, kontekstuell databaseintelligens inne i utviklerens IDE og autonome forretningsanalyser som ikke krever en dedikert analyst.

Disse er nye produktlinjer som eksisterer fordi AI gjorde det underliggende problemet løsbart. Det er den standarden vi holder oss til: et virkelig AI-produkt er ett hvor fjerning av AI-laget bryter produktet. Industrien har brukt to år på å kalle chat-paneler “AI-produkter”. De er funksjoner, ikke produkter.

Vi tok lengre tid fordi vi ville gjøre det riktig. De neste tolv månedene vil vise om den disiplinen betalte seg.

AI skriver, optimaliserer og feilsøker kode i økende grad. Hvordan ser du på at denne utviklingen endrer rollen til utviklere som arbeider med databaser de neste få årene?

Verdien av å kjenne SQL-syntaks er raskt avskrevet. Hvis AI kan generere en kompleks multi-tabell JOIN på noen sekunder og identifisere manglende indekser fra logger på minutter, er en ingeniørs verdi ikke lenger knyttet til å skrive SQL. Den delen av jobben blir en vare.

Men her er den kritiske nuansen som evangelister for fullstendig automatisering alltid hopper over. En AI-feil på frontend er en misjustert knapp du kan refresh. En AI-feil på database er en slettet produksjonsmiljø, en PII-lekkasje eller en transaksjonell nedstengning av hele bedriften.

Databaser inneholder tilstand. De tilgir ikke hallusinasjoner.

Den asymmetrien endrer rollen fullstendig. Over de neste to til tre årene vil databaseutviklere og DBAer utvikle seg fra kodere til arkitekter og revisorer. Deres primære arbeid flytter til tre ting:

• Å designe pålitelige arkitekturer som AI ikke kan forstå på egen hånd, fordi det mangler forretningskontekst.
• Å sette harde retningslinjer og sikkerhetspolitikker for AI-agenter som berører produksjonssystemer.
• Å gjennomgå og revisere koden maskinene genererer før den når database.

Tankemodellen jeg returnerer til hele tiden er: ingeniører vil styre hærer av AI-assistenter. Verktøy som dbForge må utvikle seg fra tradisjonelle IDEer til kommando- og revisjonscentre. Jobben blir mindre om å skrive SQL manuelt og mer om å gjennomgå hva AI genererer, validerer det og tvinger grensene AI ikke kan krysse trygt.

Den profesjonelle muligheten her er betydelig. Utviklere som utvikler seg til arkitektur og tilsyn vil multiplisere sin markedverdi. De blir den uunnværlige laget mellom AI-produktivitet og produksjonssikkerhet. Premien på databaseekspertise forsvinner ikke; den flytter seg oppover mot design, styring og dømmekraft, som er nettopp der AI ikke kan operere alene.

Hva er de største begrensningene for nåværende AI-verktøy i databasehåndtering i dag, og hvor ser du de mest meningsfulle gjennombruddene kommer fra?

Nåværende AI er fortsatt fast i overfladisk automatisering. Å generere en grunnleggende SELECT-forespørsel eller boilerplate-kode er ikke lenger imponerende. Det større problemet er at de fleste AI-systemer fortsatt oppfører seg som blinde skrivere i stedet for systemarkitekter. De kan generere syntaks, men de forstår ikke virkelig miljøet de opererer i. Det virkelige gjennombruddet skjer når AI begynner å forstå kontekst, avhengigheter, tilstand og forretningslogikk sammen.

Aktuelt ser jeg tre store begrensninger som holder AI tilbake i database-miljøer.

Først og fremst er det kontekstproblemet. Store språkmodeller kan se skjema, DDL og kolonne-navn, men de forstår ikke virkelig kjørehåndlinger, indeksfragmentering, datafordelingsmønster eller den virkelige forretningslogikken bak data. Uten den dypere forståelsen blir mye av optimaliseringsrådgivningen statistisk gjettning forkledd som ekspertise.

For det andre er det hallusinasjonsproblemet, og bedrifter har nesten null toleranse for det på database-laget. En hallusinert JOIN kan bremse ned produksjonssystemer. En feil UPDATE kan slette kritiske poster. På det nivået blir selv små feil i nøyaktighet meget dyre meget raskt.

Det tredje problemet er sikkerhet og styring. Ingen alvorlig bedrift vil lime produksjonsskjema eller PII inn i et offentlig AI-verktøy uten sterke garantier rundt data-isolasjon og kontroll. Før leverandører løser det ordentlig, vil AI-adoptsjon i regulerte industrier forbli begrenset.

De meningsfulle gjennombruddene vil komme når AI flytter seg bort fra syntaks-generering og begynner å fungere mer som en bakgrunnsarkitekt eller analyst.

En del av det er semantikklaget: å flytte fra ren tabellnavn til virkelig forretningsbetydning. Ikke bare “tabell_bruker”, men å forstå konsepter som kunde-kohorter, churn-risiko eller Q3 LTV-trender.

En annen skift er AI som fungerer mer som en senior DBA i bakgrunnen. Kontinuerlig analyse av arbeidsflyt, identifisering av flaskenakker, foreslå indekser, å spore risikable forespørsler og å fange problemer før systemene feiler.

Så har du maskin-til-maskin-operasjoner, hvor autonome agenter overvåker database-last, tester optimaliseringsstrategier i isolerte miljøer og deployer forbedringer under menneskelig tilsyn.

Disse er de utviklingene som vil forme de neste fem årene av database-verktøy.

Fra din erfaring med å lede omsetning og markedstrategi, hvordan endrer AI prissetting, produkt-pakking og kunde-erhverving i programvareselskaper?

Den tradisjonelle markedstrategi-boken er ødelagt. Vi ser det i våre egne tall og over hele dev-verktøyskategorien.

Døden til klassisk akuisisjon. Til tross for betydelige forbedringer i søke-rangering over våre produkter i 2026, er vi nå i den null-klikk-realiteten. AI-søk leverer svar direkte på resultatsiden og berøver nettsteder av trafikk. Sterke rangeringer oversetter ikke lenger til leads på samme måte som de gjorde bare to år siden.

For fem år siden var en sterk innholdstrategi nok til å drive vekst. I dag er det bare en forutsetning. LLM-er vekter merkevardestyrke, positive omtaler og samfunns-tetthet når de former svar. Hvis din merkevare ikke er synlig og pålitelig, vil AI-systemer slutte å fremheve den konsekvent. Du mister ikke bare trafikk. Du forsvinner fra kjøpsreisen helt.

Dette skiftet rammer tradisjonelle dev-verktøyselskaper spesielt hardt. SEO-drevne akvisisjonskanaler som har finansiert en generasjon B2B SaaS, mister raskt effektivitet. Alle som fortsatt avhenger av dem som en primær vekst-hevel, må aktivt bygge alternativer nå: økosystem-distribusjon, samfunn og partnerskap.

Pris-utvikling: fra plasser til PLG 3.0. Vi går inn i den neste fasen av PLG. Per-plass-prising begynner å bryte sammen når en AI-agent kan gjøre arbeidet til flere ansatte. I det miljøet har det ingen mening å beregne prisen ut fra antall ansatte. Selskaper som ikke pakker om produktene sine rundt verdi i stedet for antall ansatte, vil tape MRR over de neste 24 månedene.

Neste skrittet er PLG 3.0: øyeblikket når en autonom AI-agent, ikke en menneskelig, vurderer, tester og kjøper bedriftsprogramvare. Mass-adoptsjon av den mønsteren er fortsatt noen år unna, men å arkitektere produkter og prissetting for maskin-kjøperen er en oppgave for 2026, ikke 2028.

Mange organisasjoner sliter med å flytte fra AI-eksperimenter til virkelig produksjons-påvirkning. Hva er de viktigste faktorene som bestemmer om AI-initiativ faktisk lykkes?

De fleste AI-funksjoner feiler før de bygges. De feiler i rommet hvor noen sier “vi trenger AI i dette produktet”, ikke fordi brukerne ba om det, men fordi styret ønsker en AI-historie eller markedsføring tror det vil tiltrekke en ny målgruppe. Det er den opprinnelige synden til de fleste AI-initiativ, og det former alt som følger.

Jeg ser de samme feilene gjentatt i selskaper som sliter med å flytte AI fra eksperimenter til virkelig produksjons-påvirkning.

Den første feilen er å bygge AI-funksjoner som ingen faktisk ba om. Når en AI-funksjon blir påtvunget uten en ekte brukerbehov, arbeider teamet bakover fra teknologien for å finne en brukssak. Resultatet er forutsigbart: en chat-panell som er limt på en eksisterende UI, en autocomplete som kommer i veien, en “summer”knapp som produserer dårligere utgang enn brukeren kunne skrive selv. Disse funksjonene leveres, får en pressemelding og underpresterer stille alle adopsjonsprognoser. Den dypere skaden er at de forbruker ingeniørkapasitet som burde ha gått til funksjoner brukerne faktisk ba om.

Det andre problemet er at team massive undervurderer forskjellen mellom ren demo-data og virkelig produksjonsdata. AI-demonstrasjoner kjører på ren, kurert eksempler. Produksjon kjører på den virkelige rot av kundedata: duplikater, manglende felt, ti forskjellige måter å stave samme produkt-navn på, femten års legacy-kant-tilfeller. En modell som oppnår imponerende nøyaktighet i evaluering, kan degradere kraftig på live-data, og de fleste team oppdager det ikke før brukerne klager. Kostnadene ved å oppdage det i produksjon, er sjelden tilbakeførbar.

En annen vanlig feil-punkt er bruker-undersøkelse. Standard produkt-intervjuer fungerer ikke for AI-funksjoner. Brukere kan ikke artikulere hva de ønsker fra AI, fordi de ikke vet hva som er mulig. Å spørre “ville du bruke AI til å gjøre X?” får høflige ja-svar som ikke har noen prediktiv verdi for adopsjon. Effektiv AI-produkt-undersøkelse krever å vise prototyper, observere virkelig bruk og måle om brukerne returnerer etter at nysgjerrigheten har forsvunnet. Få produkt-team har bygget om sin forskningspraksis for dette. De kjører fortsatt 2019-spillbøker på 2026-problemer.

Og til slutt, måler mange selskaper AI-aktivitet i stedet for forretnings-påvirkning. “To hundre personer brukte AI-funksjonen denne uken” er en adopsjons-måling, ikke en påvirknings-måling. Virkelig påvirkning er syklus-tid redusert, kvalitet forbedret, omsetning generert eller kostnad fjernet. Hvis du ikke kan tegne en rett linje fra AI-funksjonen til et tall på P&L, har du ikke en produksjons-påvirkning. Du har en dyr aktivitet.

Det er en femte faktor som blir stadig viktigere og som de fleste produkt-team overser helt.

Overholdelse og AI-fri bygge-vei. En betydelig andel av bedriftsbrukere i finansielle, helse, regjering, forsvar og juridiske opererer under politikker som forbuder eller begrenser AI-funksjoner i leverandør-programvare. Hvis ditt produkt kobler AI til kjernen av opplevelsen uten en måte å deaktivere eller omgå det på, utvider du ikke din målgruppe ved å legge til AI. Du mister en del av din eksisterende.

Dette er nettopp problemet vi løser med AI-kobling. Overholdelse-team i regulerte industrier ikke mot AI selv. De motsetter seg data som forlater deres perimeter. Løsningen er ikke å fjerne AI; det er å gi disse organisasjonene en AI-arkitektur som passer deres begrensninger. Det er hvorfor AI-kobling leveres som på-premise: AI-kapasiteten forblir, data forlater aldri kundens infrastruktur, og innkjøp passer gjennom på første runde i stedet for tredje.

Team som får det rett, arkitekterer for overholdelse fra dag én. Team som feiler, oppdager problemet under innkjøps-gjennomgang, når avtalen allerede er tapt.

Devart opererer over flere database-økosystemer. Hvordan kan AI hjelpe med å forenkle den økende kompleksiteten ved å håndtere data over forskjellige plattformer?

Smerterne er reelle. En typisk Fortune 500 kjører åtte til tolv forskjellige database-motorer samtidig: legacy Oracle for finansielle formål, PostgreSQL for nye tjenester, SQL Server for operasjoner, Snowflake eller BigQuery for analyser og økende ofte en vektor-lagring for innlegg. Hver har sin egen dialekt, sin egen verktøy, sin egen styringsregime. En utvikler som slutter seg til det miljøet, kan bruke tre måneder bare på å lære hvor data bor og hvem som har tillatelse til å røre det.

AI løser ikke denne kompleksiteten på egen hånd. Det forsterker hva som helst det får. Åtte separate databaser uten felles metadata produserer åtte separate sett med overfladiske forslag. Det er nettopp feil-modusen vi ser i de fleste bedrifts AI-utrullinger på staker.

Muligheten er et kontekst-lag som sitter mellom AI-agenter og underliggende databaser. Et som snakker til alle, normaliserer metadata, tvinger enhetlige styringspolitikker og eksponerer en ren MCP-grensesnitt slik at enhver AI-agent, enten Claude, GPT eller en intern modell, fungerer over hele eiendommen med konsistente regler.

Det er arkitekturen vi bygger mot med AI-kobling: en på-premise MCP-server med støtte for flere databaser, et semantisk lag som fanger forretningsdefinisjoner én gang i stedet for å tvinge hver AI-agent til å lære dem på nytt, rolle-basert tilgangskontroll på SQL-operasjonsnivå og fullstendige audit-logger.

Forenkling er ikke gratis. Noen må fortsatt modellere det semantiske laget og sette policy. Men den arbeidet skjer én gang, ikke gjentatt for hver AI-agent du legger til.

Du har ledet store tverrfaglige team. Hvordan endrer AI intern samarbeid og beslutningstaking mellom produkt, ingeniør, markedsføring og salg?

De fleste tverrfaglige friksjoner var virkelig bare mennesker som ventet på informasjon fra andre team. AI kollapser denne friksjonen raskere enn noen ledelsesramme noen gang kunne.

Skiftene er praktiske og umiddelbare.

I produkt og ingeniør: en produktleder stiller en database-spørsmål på ren forretnings-språk, “hva er LTV-variasjonen over våre tre beste priser?”, og får et håndterbart svar på stedet, i stedet for å sende en Jira-billett til analytikere og vente tre dager.

I markedsføring og data: kohort-analyse skjer inline, ikke gjennom en forespørsels-ko. Markedsføringslederen stiller spørsmål, får tall og bygger kampanjen, alt på samme morgen.

I salg og ingeniør: tekniske svar for kunder trenger ikke lenger å involvere å booke en samtale med en senior ingeniør. Salgsrepresentanten får et troverdig teknisk svar i sanntid, og avtale-syklusen komprimeres.

Beslutninger flytter inn i samtalen i stedet for inn i oppfølgingen. “La meg få tilbake til deg med det nummeret” mønsteret dør. Møter krymper fordi AI håndterer forhåndssammenfatninger og summeringer som tidligere tok opp første halvdel av hver sesjon.

Dette sammenbruddet av friksjon tvinger en dypere ledelses-skift, og det er det som de fleste ledelses-team undervurderer.

Hver bedrift hevder å være resultatorientert. Se under huven og de fleste kjører fortsatt på proxy-målinger: historier, kode-linjer, billetter lukket, timer logget. Vi brukte aktivitet som en proxy for verdi fordi virkelig verdi var vanskelig å måle. AI bryter denne proxyen permanent. Når en agent kan skrive 10 000 kode-linjer eller lukke 500 støtte-billetter på ett minutt, blir måling av aktivitet farligvis misvisende.

Vi flytter oss nå eksplisitt til Sant Resultat-Orientert Ledelse, hvor ytelse måles strengt av utfall og dømmekraft. Brutalt i praksis, fordi de fleste ytelsessystemer ikke er bygget for det. Mennesker som tidligere skjulte seg bak høy aktivitet, blir synlige umiddelbart, og ledelse må være villig til å handle på den synligheten.

Den strukturelle konsekvensen er flatere org-diagrammer. Koordinerings- og informasjons-rutingslag komprimeres. Organisasjoner som tilpasser seg raskest, vil operere med strukturelt færre mennesker på høyere hevel.

Med oppsvinget i AI-assistert utvikling og kode-frie verktøy, er vi på vei mot en fremtid hvor databasehåndtering blir tilgjengelig for ikke-tekniske brukere?

Det er en farlig forvirring i industrien nå. Folk behandler en side-prosjekt-database og en bedrifts-arv-database som om de er det samme. De er ikke.

For små grønne felt-prosjekter er demokratisering allerede her. Jeg har personlig bygget små applikasjoner fra scratch uten dypt database-håndteringsekspertise. Hvis hele ditt skjema passer innenfor en LLMs kontekst-vindu, fungerer AI som magi. Borger-utviklere som bygger interne verktøy på små skala, vil være en virkelig og voksende kategori.

Bedrifts-reality er fullstendig annerledes. Store arv-databaser møter samme problem som store monolittiske kode-baseringer: kontekst-veggen. Du kan ikke fange femten års skjema-utvikling, cross-database-avhengigheter og tilpasset trigger-logikk i en prompt. Når AI mister kontekst på en stor database, degraderer hallusinasjoner ikke elegant. De multipliserer eksponentielt.

Risikoen som diskuteres for lite, er feil trygghet på skala. Naturlige språk-grensesnitt er unikt gode til å produsere plausibelt-utseende men subtilt feil svar. Hvis en SQL-forespørsel har en syntaks-feil, får du en feil-melding. Hvis et naturlig språk-grensesnitt misforstår “aktive kunder” fordi din data har seks forskjellige definisjoner av aktivitet, får du et tall. Tallet ser fint ut. Det kan være feil av 30%. Brukeren har ingen måte å vite.

Så nei, bedrifts-databasehåndtering blir ikke en lekeplass for ikke-tekniske brukere.

Borger-DBA er en myte på skala.

Fremtiden tilhører ekspert-data-arkitekter som bruker profesjonelle verktøy til å bygge broer over kontekst-gapet og bygge infrastruktur som lar AI operere trygt på toppen.

Den strukturelle fikseringen er semantikklaget: en kontrollert vokabular hvor forretningsdefinisjoner er fikset én gang og gjenbrukt over hver AI-interaksjon. Det er kjerne-arkitekturen vi bygger inn i Insightis. Uten det, blir tilgjengelighet en byrde.

Ser fremover, hva ligner et “AI-nativt” utvikler-verktøy på, og hvordan bør team forberede seg på den skiftet i dag?

Et AI-nativt verktøy er ikke en chat-panell limt på en IDE. Det meste som markedsføres som “AI-nativt” i dag, er et chat-grensesnitt pluss en autocomplete-modell. Det er basis, ikke destinasjon.

Til meg, trenger et virkelig AI-nativt verktøy tre ting.

Først og fremst, trenger AI dyp kontekst. Det må forstå kodebasen, infrastrukturen, historiske beslutninger og data-miljøet kontinuerlig, ikke bare gjennom prompter limt inn i en chat-vindu. De fleste verktøy feiler denne testen. Deres kontekst nullstilles med hver sesjon, og brukeren betaler kostnaden av å bygge det opp igjen konstant.

For det andre, må verktøyene kommunisere ordentlig med hverandre. Din IDE må snakke til din database, database til observasjon-stacken og CI/CD til AI-revisoren, osv. MCP-protokollen blir standard-laget her, med 97 millioner SDK-nedlastinger per måned i Q1 2026, opp fra 100 000 i slutten av 2024. Det er en 970-ganger økning på femten måneder og den bratteste adopsjons-kurven jeg har sett i utvikler-infrastruktur.

For det tredje, produksjons-klar AI krever seriøse sikkerhets-grenser. Blast-radius-forhåndsvisning før destruktive operasjoner. Avhengighets-analyse. Automatiske rollback-planer. Audit-logger som standard. AI uten disse, er greit for prototyper og farlig i produksjon.

Hvordan forberede seg, konkret.

Gjennomgang av stack mot disse tre komponentene. Har hvert verktøy eksponert API-er og MCP? Snakker det til andre, eller sitter det i en silo? Har det sikkerhetskontroller? Verktøy som feiler to av tre, er kort-siktige aktiva.

Bygg kontekst-infrastruktur nå. Dokument skjema, forretningsdefinisjoner og arkitektoniske beslutninger i maskin-læsbare formater. Rik kontekst bygges ikke på en kvartal. Team som har det i 2027, er de som dokumenterer i dag.

Kjør AI i produksjon før du tror du er klar. Team som venter på en formell “AI-strategi” før de leverer, vil være atten måneder bak team som allerede lærer fra virkelig produksjons-feil. Velg en lav-risiko-bruks-sak. Lever det. Bygg muskelen.

Team som tar disse beslutningene i dag, vil definere de neste ti årene av hvordan programvare bygges. Vinduet er smalt, og det er åpent nå.

Takk for det flotte intervjuet, lesere som ønsker å lære mer, bør besøke Devart.