Anton Onufriienko, VD på Devart – Intervju-serie

Anton Onufriienko, VD på Devart, är en teknisk chef och operatör med djup erfarenhet av att skala upp mjukvaruföretag, driva intäktsökning och leda stora tvärfunktionella team inom SaaS, företagsprogramvara och finansiella tjänster. Under sin karriär har han gått från att bygga försäljningsorganisationer och lansera startups till att ansvara för fullständig P&L-verksamhet för stora affärsenheter, inklusive Devarts största avdelning med över 130 anställda. Innan han blev VD var han Devarts Chief Revenue Officer och Head of Sales, där han ledde go-to-market-strategi, pristransformering och internationella tillväxtinitiativ. Han är också VD för TMetric, en plattform för tidsspårning och lönsamhet som fokuserar på att hjälpa tjänsteorienterade företag att få operativ tydlighet.

Devart är ett programvaruföretag som specialiserar sig på databasutveckling, dataanslutning, integration och produktivitetsverktyg för utvecklare, DBA, analytiker och företagsteam. Grundat 1997 är företaget mest känt för sin dbForge-svit av databashanteringverktyg, som stöder stora databassystem som SQL Server, MySQL, Oracle och PostgreSQL. Devart utvecklar också dataanslutningslösningar som ODBC, ADO.NET, Python och Delphi-anslutningar, samt Skyvia, sin molnbaserade no-code-dataintegrationsplattform för ETL, automatisering, säkerhetskopiering och arbetsflödesorkestrering. Företaget servar över 500 000 användare globalt, inklusive en stor andel av Fortune 100-företag, och har alltmer fokuserat på att integrera AI-drivna funktioner i sina produkter genom verktyg som dbForge AI Assistant, som hjälper utvecklare att generera, optimera, felsöka och förklara SQL-frågor med hjälp av naturligt språk.

Du har gått från att bygga och leda försäljningsteam till att ansvara för fullständig P&L-verksamhet och nu för Devarts största affärsenhet. Hur har den resan format din synsätt på att integrera AI i produktstrategi och beslutsfattande i stor skala?

Försäljningen lärde mig att mäta ROI på allt. När jag gick vidare till en CRO-roll skalförstärkte jag den disciplinen över funktioner. Att ansvara för en affärsenhet tvingade mig att tillämpa det på AI själv.

Jag har en praktisk syn på AI. Det är inte så att jag är tvivlande: tre av våra fyra produktinsatser för 2026 är AI-nativa. Men jag tror att hype står i vägen för verkliga och bestående resultat.

Det finns ett meme som cirkulerar som sammanfattar var branschen ofta går fel. Företag byter ut 400-dollar-SaaS-prenumerationer mot hemmagjorda verktyg som kostar 1 000 dollar i månaden i API-avgifter och kräver konstanta reparationer. Det är inte verklig förändring, det är bara en dyrbart show.

Lektionen jag lärde mig i försäljningen är enkel: varje initiativ betalar för sig, eller så dör det. Jag driver vår AI-utrullning på samma sätt som jag en gång drev ett försäljningsområde. Uttryckt ROI-hypotes per arbetsflöde, en trevågig utrullning och dokumenterad påverkan innan skalförstärkning.

Vår nordstjärna-mätning är intäkter per anställd, och vårt mål är att mer än dubbla den till slutet av 2028. Du kan inte stänga den luckan genom att anställa. Du stänger den genom att förändra vad arbetet ser ut som, och AI är den enda realistiska mekanismen i den storleksordningen.

Mitt filter för varje AI-initiativ, internt eller i produkten, är detsamma: vad är den uppmätta värdet, vem betalar för det och hur vet vi att det fungerade? Allt som misslyckas med dessa tre frågor hör inte hemma i produktion. Kostnaden för att göra fel här förvärras snabbt, och de flesta företag kommer att upptäcka det på ett dyrt sätt.

Devart har byggt upp ett starkt rykte kring databasverktyg och utvecklarproduktivitet. Hur integrerar du AI i dessa produkter på ett sätt som levererar verkligt värde snarare än ytmässig automatisering?

Våra användare är hårda tekniska specialister: DBA, seniora ingenjörer, dataarkitekter. De upptäcker ytmässig automatisering på några sekunder och ogillar att säljas marknadsleksaker utklädda till innovation. För två år sedan, när AI-hype nådde sin topp och konkurrenter tävlade om att fästa chattpaneler på varje gränssnittselement, var frestelsen att följa med verklig. Jag hade sett det mönstret tidigare, i mobil, i moln, i lågkod och vägrade att upprepa det.

Disciplinen var enkel: kundvärde först. Att bygga AI-funktioner som ingen begärde, som inte levererar verkligt värde, är den sämsta möjliga användningen av begränsade ingenjörsresurser. Det är särskilt sant när din målgrupp kan se skillnaden omedelbart.

Vad som förändrades 2026 var att AI gick från hype till en verklig teknisk revolution. Gapet mellan vad dessa system kunde göra 2023 och vad de kan göra idag är inte inkrementellt. Det är en helt annan kategori av funktioner. Vi kan nu lösa problem som var genuint olösliga tidigare: säker företagsdataåtkomst för AI-agenter, kontextuell databasintelligens inuti utvecklarens IDE och autonoma affärsanalyser som inte kräver en dedikerad analytiker.

Detta är nya produktlinjer som existerar för att AI gjorde den underliggande problemen lösbara. Det är den ribban vi håller oss till: en verklig AI-produkt är en där borttagning av AI-lagret bryter produkten. Branschen har tillbringat två år med att kalla chattpaneler “AI-produkter”. Det är funktioner, inte produkter.

Vi tog längre tid för att vi ville göra det rätt. De kommande tolv månaderna kommer att visa om den disciplinen betalade sig.

AI skriver, optimerar och felsöker alltmer kod. Hur ser du att detta förändrar rollen för utvecklare som arbetar med databaser under de kommande åren?

Värdet av att känna till SQL-syntax är på väg att avskrivas snabbt. Om AI kan generera en komplex multi-tabell JOIN på några sekunder och identifiera saknade index från loggar på några minuter, så kommer en ingenjörs värde inte längre från att skriva SQL. Den delen av jobbet blir en kommoditet.

Men här är den kritiska nyansen som evangelister för total automatisering alltid hoppar över. En AI-fel på frontend är en felaktigt placerad knapp som du kan uppdatera. En AI-fel på databasen är en raderad produktionsmiljö, en PII-läcka eller en transaktionell stängning av hela företaget.

Databaser innehåller tillstånd. De förlåter inte hallucinationer.

Den asymmetrin omdefinierar rollen helt. Under de kommande två till tre åren kommer databasutvecklare och DBA att utvecklas från kodare till arkitekter och revisorer. Deras primära arbete skiftar till tre saker:

• Att designa tillförlitliga arkitekturer som AI inte kan resonera om på egen hand, eftersom den saknar affärssammanhang.
• Att ställa in hårda skyddsbarriärer och säkerhetspolicys för AI-agenter som kommer åt produktionsystem.
• Att granska och revidera den kod som maskiner genererar innan den når databasen.

Tanken jag återkommer till är att utvecklare kommer att hantera arméer av AI-assister. Verktyg som dbForge måste utvecklas från traditionella IDE till kommandocentraler och revisionscentraler. Arbetet blir mindre om att skriva SQL manuellt och mer om att granska vad AI genererar, validera det och upprätthålla gränser som AI inte kan korsa säkert.

Det professionella tillfället här är betydande. Utvecklare som utvecklas till arkitektur och tillsyn kommer att multiplicera sitt marknadsvärde. De blir det oumbärliga lagret mellan AI-produktivitet och produktionsäkerhet. Premiumen på databasexperter försvinner inte; den skiftar uppåt mot design, styrning och omdöme, som är exakt där AI inte kan operera ensam.

Vilka är de största begränsningarna för nuvarande AI-verktyg i databashantering idag, och var ser du de mest meningsfulla genombrotten?

Nuvarande AI är fortfarande fast i ytmässig automatisering. Att generera en grundläggande SELECT-fråga eller boilerplate-kod är inte imponerande längre. Det större problemet är att de flesta AI-system fortfarande beter sig som blinda skrivare snarare än systemarkitekter. De kan generera syntax, men de förstår inte den miljö de opererar i. Det verkliga genombrottet sker när AI börjar resonera om sammanhang, beroenden, tillstånd och affärslogik tillsammans.

Just nu ser jag tre stora begränsningar som hindrar AI i databasmiljöer.

För det första finns det ett sammanhangsproblem. Stora språkmodeller kan se scheman, DDL och kolumnnamn, men de förstår inte verkställningsplaner, indexfragmentering, datafördelningsmönster eller den faktiska affärslogiken bakom data. Utan den djupare förståelsen blir mycket optimeringsråd statistiskt gissande utklädda till expertis.

För det andra finns det ett hallucinationsproblem, och företag har nästan noll tolerans för det på databasnivån. En hallucinerad JOIN kan sakta ner produktionsystem. En felaktig UPDATE kan radera kritiska poster. På den nivån blir även små fel i noggrannhet mycket dyra mycket snabbt.

Det tredje problemet är säkerhet och styrning. Inga allvarliga företag kommer att klistra in produktionscheman eller PII i ett offentligt AI-verktyg utan starka garantier kring dataisolering och kontroll. Tills leverantörer löser det ordentligt kommer AI-antagande i reglerade branscher att förbli begränsat.

De meningsfulla genombrotten kommer när AI flyttar bortom syntaxgenerering och börjar fungera mer som en bakgrundsarkitekt eller analytiker.

En del av det är den semantiska lagret: att flytta från råa tabellnamn till verkligt affärssammanhang. Inte bara “tabell_användare”, utan förstå begrepp som kundkohorter, avhoppningsrisk eller Q3 LTV-trender.

En annan skiftning är att AI fungerar mer som en senior DBA i bakgrunden. Kontinuerligt analysera arbetsbelastningar, identifiera flaskhalsar, föreslå index, upptäcka riskfyllda frågor och upptäcka problem innan systemen misslyckas.

Sedan har du maskin-till-maskin-åtgärder, där autonoma agenter övervakar databasbelastning, testar optimeringsstrategier i isolerade miljöer och distribuerar förbättringar under mänsklig tillsyn.

Det är de utvecklingarna som kommer att forma de kommande fem åren av databasverktyg.

Från din erfarenhet av att leda intäkter och go-to-market-strategi, hur förändrar AI prismodeller, produktförpackning och kundanskaffning i programvaruföretag?

Den traditionella go-to-market-playboken är bruten. Vi ser det i våra egna siffror och över hela utvecklarverktygsbranschen.

Döden av klassisk kundanskaffning. Trots meningsfulla förbättringar av sökningar för våra produkter 2026, så slår vi mot den nollklicksverkligheten. AI-sökning levererar svar direkt på resultatsidan och berövar webbplatser trafik. Starka sökrankningar översätter sig inte längre till leads som de gjorde för bara två år sedan.

För fem år sedan räckte en stark innehållsstrategi för att driva tillväxt. Idag är det en förutsättning. LLM:er väger märkesstyrka, positiva omnämnanden och communitydensitet när de formas till svar. Om ditt varumärke inte är synligt och pålitligt, så kommer AI-system att sluta presentera det konsekvent. Du förlorar inte bara trafik. Du försvinner från köpprocessen helt.

Denna skiftning slår traditionella utvecklarverktygsföretag särskilt hårt. SEO-drivna kundanskaffningskanaler som finansierade en generation B2B-programvaror förlorar effektivitet snabbt. Alla som fortfarande förlitar sig på dem som en primär tillväxtmotor behöver aktivt bygga alternativ just nu: ekosystemdistribution, community och partnerskap.

Prisutveckling: från platser till PLG 3.0. Vi går in i nästa fas av PLG. Per-platsprissättning börjar bryta ner när en AI-agent kan göra arbetet för flera anställda. I den miljön slutar det att ha mening att fakturera per huvud. Företag som inte omförpackar produkter runt värde snarare än per huvud kommer att förlora MRR under de kommande 24 månaderna.

Nästa steg är PLG 3.0: ögonblicket när en autonom AI-agent, inte en människa, utvärderar, testar och köper företagsprogramvara. Massantagandet av det mönstret är fortfarande några år bort, men att arkitektoniskt utforma produkter och prissättning för maskinköparen är en uppgift för 2026, inte 2028.

Många organisationer kämpar för att gå från AI-experiment till verklig produktionseffekt. Vilka är de viktigaste faktorerna som avgör om AI-initiativ verkligen lyckas?

De flesta AI-funktioner misslyckas innan de byggs. De misslyckas i rummet där någon säger “vi behöver AI i den här produkten”, inte för att användare begärde det, utan för att styrelsen vill ha en AI-berättelse eller marknadsavdelningen tror att det kommer att locka en ny publik. Det är den ursprungliga synden för de flesta AI-initiativ, och det formar allt som följer.

Jag ser samma misstag upprepas i företag som kämpar för att flytta AI från experiment till verklig produktionseffekt.

Det första misstaget är att bygga AI-funktioner som ingen verkligen begärde. När en AI-funktion är påbjuden utan en äkta användarbehov, så arbetar teamet baklänges från tekniken för att uppfinna ett användningsfall. Resultatet är förutsägbart: en chattpanel fäst på ett befintligt gränssnitt, en autocomplete som kommer i vägen, en “sammanfattning”-knapp som producerar sämre utdata än vad användaren kunde skriva själv. Dessa funktioner levereras, får en pressrelease och presterar tyst under alla antagna adoptionsscenarier. Den djupare skadan är att de konsumerar ingenjörsresurser som borde ha gått till funktioner som användare verkligen begärde.

Det andra problemet är att team massivt underskattar skillnaden mellan ren demo-data och verklig produktionsdata. AI-demon visar på ren, kuraterad data. Produktion körs på den faktiska röran av kunddata: dubbletter, saknade fält, tio olika sätt att stava samma produktnamn, femton år av legacy-kanter. En modell som uppnår imponerande noggrannhet i utvärdering kan försämras avsevärt på live-data, och de flesta team upptäcker det inte förrän användare klagar. Kostnaden för den upptäckten i produktionsförtroende är sällan återvinningsbar.

En annan vanlig felpunkt är användarforskning. Standardproduktintervjuer fungerar inte för AI-funktioner. Användare kan inte uttrycka vad de vill ha från AI eftersom de inte vet vad som är möjligt. Att fråga “skulle du använda AI för att göra X?” får artiga ja-svar som inte har någon förutsägbar värde för antagande. Effektiv AI-produktforskning kräver att visa prototyper, observera verkligt användande och mäta om användare återvänder efter att nyheten har lagt sig. Få produktteam har byggt om sin forskningspraxis för detta. De kör fortfarande 2019-anteckningar på 2026-problem.

Och slutligen mäter många företag AI-aktivitet snarare än affärspåverkan. “Tvåhundra personer använde AI-funktionen den här veckan” är en antagningsmätning, inte en påverkansmätning. Verklig påverkan är cyklisk tid reducerad, kvalitet förbättrad, intäkter genererade eller kostnader borttagna. Om du inte kan dra en rak linje från AI-funktionen till en siffra på P&L, så har du inte en produktionseffekt. Du har en dyrbart aktivitet.

Det finns en femte faktor som blir alltmer kritisk och som de flesta produktteam försummar helt.

Regelefterlevnad och den AI-fria byggvägen. En betydande andel av företagsanvändare inom finans, hälsovård, regering, försvar och juridik opererar under policys som förbjuder eller begränsar AI-funktioner i leverantörsprogramvara. Om din produkt kopplar AI hårt till kärnupplevelsen utan ett sätt att inaktivera eller kringgå det, så expanderar du inte din målgrupp genom att lägga till AI. Du förlorar en sektor av din befintliga.

Detta är exakt det problem vi löser med AI-anslutning. Regelefterlevnadsteam i reglerade branscher invänder inte mot AI i sig. De invänder mot data som lämnar deras perimeter. Lösningen är inte att strippa bort AI; det är att ge dessa organisationer en AI-arkitektur som passar deras begränsningar. Det är varför AI-anslutning levereras som lokal: AI-funktionen finns kvar, data lämnar aldrig kundens infrastruktur och inköp klarar granskningen i första omgången istället för i tredje.

Team som får det rätt arkitekterar för regelefterlevnad från dag ett. Team som får det fel upptäcker problemet under inköpsgranskning, när affären redan är förlorad.

Devart opererar över flera databasmiljöer. Hur kan AI hjälpa till att förenkla den växande komplexiteten i att hantera data över olika plattformar?

Smärtan är verklig. Ett typiskt Fortune 500-koncern kör åtta till tolv olika databasmotorer samtidigt: legacy Oracle för finans, PostgreSQL för nya tjänster, SQL Server för operativ verksamhet, Snowflake eller BigQuery för analyser och alltmer en vektorlagring för inbäddningar. Var och en har sin egen dialekt, sin egen verktygslåda, sin egen styrningsregim. En utvecklare som går med i den miljön kan tillbringa tre månader med att bara lära sig var data bor och vem som har tillåtelse att röra den.

AI löser inte den komplexiteten på egen hand. Den förstärker vad den får för sammanhang. Åtta frånkopplade databaser med ingen enhetlig metadata producerar åtta frånkopplade uppsättningar av ytliga förslag. Det är exakt det misslyckandemönster vi ser i de flesta företags AI-utrullningar på stackar.

Möjligheten ligger i ett sammanhangslager som sitter mellan AI-agenter och de underliggande databaserna. Ett som talar till alla, normaliserar metadata, upprätthåller enhetliga styrningspolicys och exponerar ett rent MCP-gränssnitt så att varje AI-agent, oavsett om det är Claude, GPT eller en intern modell, fungerar över hela fastigheten med konsekventa regler.

Det är den arkitektur vi bygger mot med AI-anslutning: en lokal MCP-server med stöd för flera databaser, ett semantiskt lager som fångar affärsdefinitioner en gång istället för att tvinga varje AI-agent att återlära dem, rollbaserad åtkomstkontroll på SQL-operationsnivå och fullständiga granskningsloggar.

Förenkling är inte gratis. Någon måste fortfarande modellera det semantiska lagret och ställa in policy. Men det arbetet sker en gång, inte upprepat för varje AI-agent du lägger till.

Du har lett stora tvärfunktionella team. Hur förändrar AI det interna samarbetet och beslutsfattandet mellan produkt, teknik, marknadsföring och försäljning?

De flesta tvärfunktionella friktioner var egentligen bara människor som väntade på information från andra team. AI kollapsar den friktionen snabbare än något ledningsramverk någonsin kunde.

Skiftningarna är praktiska och omedelbara.

I produkt och teknik: en produktchef ställer en databasfråga på rent affärsspråk, “vad är LTV-variationen över våra tre bästa pristier?”, och får ett handlingsbart svar på fläcken, istället för att lägga till en Jira-biljett till analytik och vänta tre dagar.

I marknadsföring och data: kohortanalys sker inline, inte via en begärankö. Marknadschefen ställer frågan, får siffror och bygger kampanjen, allt på samma morgon.

I försäljning och teknik: tekniska svar för prospekt behöver inte längre schemaläggas med en senior ingenjör. Försäljningsrepresentanten får ett trovärdigt tekniskt svar i realtid, och affärsprocessen komprimeras.

Beslut flyttar in i samtalet snarare än i uppföljningen. Mönstret “låt mig återkomma till dig med den siffran” dör. Mötet krymper eftersom AI hanterar för-läsningar och sammanfattningar som tidigare konsumerade den första halvan av varje session.

Detta sammanbrott av friktion tvingar en djupare ledningsförändring, och det är den som de flesta ledningsteam underskattar.

Varje företag påstår sig vara resultatorienterat. Titta under huven och de flesta körs fortfarande på proxymätningar: user stories, kodrader, biljetter stängda, timmar loggade. Vi använde aktivitet som en proxy för värde eftersom verkligt värde var svårt att mäta. AI bryter den proxyn permanent. När en agent kan skriva 10 000 kodrader eller stänga 500 supportbiljetter på en minut, så blir mätning av aktivitet farligt vilseledande.

Vi flyttar explicit till True Result-Oriented Management, där prestation mäts strikt av utfall och omdöme. Brutalt i praktiken, eftersom de flesta prestationssystem inte är byggda för det. Människor som tidigare dolde sig bakom hög aktivitet blir synliga omedelbart, och ledning måste vara villig att agera på den synligheten.

Den strukturella följden är plattare organisationsdiagram. Koordinations- och informationsdirigeringsskikt komprimeras. Organisationer som anpassar sig snabbast kommer att operera med strukturellt färre människor på högre belastning.

Med uppkomsten av AI-assisterad utveckling och inge-kodverktyg, är vi på väg mot en framtid där databashantering blir tillgänglig för icke-tekniska användare?

Det finns en farlig förvirring i branschen just nu. Människor behandlar en sidoprojekt-databas och en företagsägd databas som om de vore desamma. De är inte det.

För små gröna fält-projekt är demokratisering redan här. Jag har personligen byggt små applikationer från scratch utan djup databashanteringskunskap. Om din helhetsschema passar inom en LLM:s sammanhangsfönster, så fungerar AI som magi. Medborgarutvecklare som bygger interna verktyg i liten skala kommer att vara en verklig och växande kategori.

Företagsverkligheten är helt annorlunda. Stora legacy-databaser möter samma problem som stora monolitiska kodbas: sammanhangsväggen. Du kan inte få in femton års odokumenterad schemautveckling, databasberoenden och anpassad utlösarlogik i en prompt. När AI förlorar sammanhang på en stor databas, så förvärras hallucinationer inte på ett sätt som är hanterbart. De multipliceras exponentiellt.

Risken som diskuteras för lite är falskt förtroende i skala. Naturliga gränssnitt är unikt bra på att producera trovärdigt seende men subtilt felaktiga svar. Om en SQL-fråga har ett syntaxfel, så får du ett felmeddelande. Om ett naturligt gränssnitt missförstår “aktiva kunder” för att din data har sex olika definitioner av aktivitet, så får du ett nummer. Numret ser bra ut. Det kan vara avvikande med 30%. Användaren har inget sätt att veta.

Så nej, företagsdatabashantering blir inte en lekplats för icke-tekniska användare.

Medborgar-DBA är en myt i skala.

Framtiden tillhör expertdataarkitekter som använder professionella verktyg för att överbrygga sammanhangsgapet och bygga infrastruktur som låter AI operera säkert ovanpå.

Den strukturella lösningen är det semantiska lagret: en kontrollerad vokabulär där affärsdefinitioner är fixerade en gång och återanvänds över varje AI-interaktion. Det är kärnarkitekturen vi bygger in i Insightis. Utan det blir tillgänglighet en belastning.

Om vi blickar framåt, vad ser en “AI-nativ” utvecklarverktygslåda ut som, och hur bör team förbereda sig för den skiftningen idag?

En AI-nativ verktygslåda är inte en chattbot fäst på en IDE. Det mesta som marknadsförs som “AI-nativt” idag är ett chatsgränssnitt plus en autocomplete-modell. Det är en förutsättning, inte destinationen.

För mig behöver en verkligt AI-nativ verktygslåda tre saker.

För det första behöver AI djupt sammanhang. Den måste förstå din kodbas, din infrastruktur, dina historiska beslut och din data-miljö kontinuerligt, inte bara genom prompter klistrade in i ett chatsfönster. De flesta nuvarande verktyg misslyckas med den testen. Deras sammanhang återställs med varje session, och användaren betalar kostnaden för att bygga upp det konstant.

För det andra måste verktygen kommunicera ordentligt med varandra. Din IDE måste prata med din databas, databasen med din observabilitetsstack och CI/CD med din AI-granskare, och så vidare. Modellkontextprotokollet blir standardlagret här, med 97 miljoner SDK-nedladdningar per månad i Q1 2026, upp från 100 000 i slutet av 2024. Det är den brantaste antagningskurvan jag sett i utvecklarinfrastruktur.

För det tredje kräver produktionsklassad AI allvarliga säkerhetsbarriärer. Förhandsgranskning av sprängverkning före destruktiva operationer. Beroendeanalys. Automatiserade återställningsplaner. Granskningsloggar som standard. AI utan dessa är bra för prototyper och farlig i produktion.

Hur man förbereder sig, konkret.

Granska din stack mot dessa tre komponenter. Exponerar varje verktyg API:er och MCP? Pratar det med andra, eller sitter det i en silo? Har det säkerhetskontroller? Verktyg som misslyckas med två av tre är kortvariga tillgångar.

Bygg sammanhangsinfrastruktur nu. Dokumentera schema, affärsdefinitioner och arkitektbeslut i maskinläsbara format. Rikt sammanhang byggs inte på en kvartal. Team vars AI har det 2027 är de som dokumenterar idag.

Kör AI i produktion innan du tror att du är redo. Team som väntar på en formell “AI-strategi” innan de levererar kommer att vara arton månader efter team som redan lär sig av verkliga produktionsfel. Välj en lågriskig användningsfall. Leverera det. Bygg muskeln.

Teamen som fattar dessa beslut idag kommer att definiera nästa decennium av hur programvara byggs. Fönstret är smalt, och det är öppet just nu.

Tack för den utmärkta intervjun, läsare som vill lära sig mer bör besöka Devart.