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

Anton Onufriienko, administrerende direktør i Devart, er en teknologileder og operativ leder med dypt erfaring i å 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 startups 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 go-to-market-strategi, pristransformasjon og internasjonal vekstinitiativer. Han er også CEO i TMetric, en tidssporings- og lønnsomhetsplattform som fokuserer på å hjelpe tjenestedrevne 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 større databasesystemer, inkludert SQL Server, MySQL, Oracle 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?

Salg lærte meg å måle ROI på alt. Ved å gå over til 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 sånn 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 og 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 $1 000 i måneden i API-gebyrer og trenger konstant fiksering. Det er ikke virkelig endring, det er bare en kostbar forestilling.

Leksjonen jeg plukket opp i salg 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. Uttrykt ROI-hypotese per arbeidsflyt, en tre-bølge-utrulling og dokumentert påvirkning før skaleringsforbedring.

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.

Mitt filter på hver AI-initiativ, intern eller produkt, er det 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 kompenserer raskt, og de fleste selskaper vil finne det ut på den dyre måten.

Devart har bygget en sterk rykte 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 oppdager overfladisk automatisering på sekunder og resenter å 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 enkel: kundeverdi først. Bygging AI-funksjoner ingen ba om, som ikke leverer virkelig verdi, er den verst mulige bruken av begrensede ingeniørressurser. Det er spesielt sant når din målgruppe kan se forskjellen umiddelbart.

Hva endret seg i 2026, er at AI gikk 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 bedriftsdatatilgang for AI-agenter, kontekstuell databaseintelligens innenfor utviklerens IDE og autonome forretningsanalyser som ikke krever en dedikert analytiker.

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 et produkt hvor fjerning av AI-laget bryter produktet. Industrien har brukt to år på å kalle chat-paneler “AI-produkter”. Disse 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 for deg at dette 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å sekunder og identifisere manglende indekser fra logger på minutter, er en ingeniørs verdi ikke lenger å 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 transaksjonsavslutning av hele bedriften.

Databaser inneholder tilstand. De tilgir ikke hallucinasjoner.

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 skifter til tre ting:

• Design av pålitelige arkitekturer som AI ikke kan resonnere om på egen hånd, fordi det mangler forretningskontekst.
• Fastsettelse av harde retningslinjer og sikkerhetspolitikk for AI-agenter som berører produksjonssystemer.
• Gjennomgang og revisjon av koden maskinene genererer før den når databasen.

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

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

Hva er de største begrensningene til 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. Generering av 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 å resonnere om 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 eksekveringsplaner, indeksfragmentering, datafordelingsmønster eller den virkelige forretningslogikken bak data. Uten denne dypere forståelsen blir mye optimaliseringsråd statistisk gjettning forkledd som ekspertise.

For det andre er det hallucinasjonsproblemet, og bedrifter har nesten null toleranse for det på database-laget. En hallucinert JOIN kan bremse ned produksjonssystemer. En feil UPDATE kan slette kritiske poster. På det nivået blir selv små feil i nøyaktighet ekstremt dyre svært 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 dataisolering og kontroll. Før leverandører løser det ordentlig, vil AI-tilpasning i regulerte industrier forbli begrenset.

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

En del av det er semantikklaget: flytte fra rå 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 seniordba i bakgrunnen. Kontinuerlig analyse av arbeidsflyt, identifisering av flaskehalser, foreslå indekser, oppdage risikable forespørsler og fange problemer før systemer feiler.

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

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

Med stigende AI-assistert utvikling og kodefrie 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 akkurat 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 dyp databasehåndteringsekspertise. Hvis hele skjemaet ditt passer innenfor en LLMs kontekstvindu, fungerer AI som magi. Borgerutviklere som bygger interne verktøy på et lite nivå vil være en virkelig og voksende kategori.

Bedriftsrealiteten er fullstendig annerledes. Store arv-databaser møter det samme problemet som store monolittiske kodebasier: kontekstveggen. Du kan ikke lime femten års udokumentert skjemautvikling, cross-database-avhengigheter og tilpasset triggerlogikk inn i en prompt. Når AI mister kontekst på en stor database, forverres hallucinasjoner ikke nedad. De multipliserer eksponentielt.

Risikoen som diskuteres for lite er falsk tillit på stor skala. Naturlige språk-grensesnitt er unikt gode til å produsere plausibelt utseende men subtilt feilaktige svar. Hvis en SQL-forespørsel har en syntaksfeil, får du en feilmelding. Hvis et naturlig språk-grensesnitt misforstår “aktive kunder” fordi dine 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, bedriftsdatabasehåndtering blir ikke en lekeplass for ikke-tekniske brukere.

Borger-DBA er en myte på stor skala.

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

Den strukturelle løsningen er semantikklaget: en kontrollert vokabular hvor forretningsdefinisjoner er fikset en gang og gjenbrukt over hver AI-interaksjon. Det er kjernen i arkitekturen vi bygger inn i Insightis. Uten det blir tilgjengelighet en belastning.

Seende fremover, hva ser et “AI-naturlig” utvikler-verktøy ut som, og hvordan bør team starte å forberede seg på den skiftet i dag?

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

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

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

For det andre må verktøyene kommunisere ordentlig med hverandre. Ditt IDE må snakke med din database, databasen til din observasjonstack og CI/CD til din AI-revisjon, osv. Modellkontekstprotokollen blir standardlaget her, med 97 millioner SDK-nedlastinger per måned i Q1 2026, opp fra 100 000 i slutten av 2024. Det er den bratteste adopsjonskurven jeg har sett i utvikler-infrastruktur.

For det tredje krever produksjonsklar AI alvorlige sikkerhetsretningslinjer. Forhåndsvisning av blast-radius før destruktive operasjoner. Avhengighetsanalyse. Automatiske rollback-planer. Audit-trails som standard. AI uten disse er fin for prototyper og farlig i produksjon.

Hvordan forberede seg, konkret.

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

Bygg kontekst-infrastruktur nå. Dokument skjema, forretningsdefinisjoner og arkitektur-beslutninger i maskin-læsbare formater. Rik kontekst bygges ikke i en kvartal. Teamene hvis AI 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 sender, vil være atten måneder bak team som allerede lærer fra virkelig produksjonsfeil. Velg en lav-risiko-bruksfall. Send det. Bygg muskelen.

Teamene 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.