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 division 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, datakoppling, 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 (ORCL ) och PostgreSQL. Devart utvecklar också datakopplingslösningar som ODBC, ADO.NET, Python och Delphi-anslutningar, samt Skyvia, sin molnbaserade no-code-dataintegrationsplattform för ETL, automatisering, säkerhetskopiering och arbetsflödeskoordinering. 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 över till en CRO-roll skalförstärkte jag den disciplinen över funktioner. Att ansvara för en affärsenhet tvingade mig att tillämpa den 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 kommer i vägen för verkliga, bestående resultat.

Det finns en 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 behö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 sin egen väg, eller så dör det. Jag kör vår AI-utrullning på samma sätt som jag en gång körde ett försäljningsteam. Uttrycklig 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 stänger inte 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 att besvara dessa tre frågorna 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 ytanlig automatisering?

Våra användare är hårda tekniska specialister: DBA, seniora ingenjörer, dataarkitekter. De upptäcker ytanlig 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 chatskärmar på varje gränssnittselement, var frestelsen att följa med riktigt. Jag hade sett den mönster 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 levererade verkligt värde, var den sämsta möjliga användningen av begränsade ingenjörsresurser. Det var särskilt sant när målgruppen kunde 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 tidigare var verkligt olösliga: säker företagsdataåtkomst för AI-agenter, kontextuell databasintelligens inuti utvecklarens IDE och autonom affärsanalys 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 chatskärmar “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 lönade sig.

AI skriver, optimerar och felsöker alltmer kod. Hur ser du att detta kommer att förändra rollen för utvecklare som arbetar med databaser under de närmaste å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, 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 AI-evangelister alltid hoppar över. Ett AI-fel på frontend är ett missat button du kan uppdatera. Ett AI-fel på databasen är en raderad produktionsmiljö, en PII-läcka eller en transaktionsstoppning av hela företaget.

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

Den asymmetrin omdefinierar rollen helt. Under de närmaste 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 riktlinjer och säkerhetspolicys för AI-agenter som rör produktionssystem.
• Att granska och auditera den kod som maskiner genererar innan den når databasen.

Tanken jag återkommer till är att ingenjörer kommer att hantera arméer av AI-assistenten. Verktyg som dbForge måste utvecklas från traditionella IDE till kommando- och revisionscenter. Jobbet 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.

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

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

Nuvarande AI är fortfarande fast i ytanlig automatisering. Att generera en grundläggande SELECT-fråga eller boilerplate-kod är inte längre imponerande. 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 håller AI tillbaka 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 verkliga 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 produktionssystem. 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 produktionsscheman 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ärssinne. Inte bara “tabell_användare”, utan att förstå koncept som kundkohorter, avhoppningsrisk eller Q3 LTV-trender.

En annan skiftning är att AI fungerar mer som en senior DBA i bakgrunden. Kontinuerligt analyserar arbetsbelastningar, identifierar flaskhalsar, föreslår index, identifierar riskfyllda frågor och upptäcker 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 övervakning.

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

Från din erfarenhet av att leda intäkter och marknadsstrategi, hur förändrar AI prissättningsmodeller, produktförpackning och kundanskaffning i programvaruföretag?

Den traditionella marknadsstrategi-handboken är trasig. Vi ser det i våra egna siffror och i hela utvecklarverktygsbranschen.

Döden av klassisk kundanskaffning. Trots meningsfulla förbättringar av sökrankningar över våra produkter 2026, slår vi mot den nollklicksverkligheten. AI-sökning levererar svar direkt på resultatsidan och berövar webbplatser trafik. Starka rankningar översätter 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 väger varumärkesstyrka, positiva omnämnanden och communitydensitet när de bildar svar. Om ditt varumärke inte är synligt och pålitligt kommer AI-system att sluta yta dig konsekvent. Du förlorar inte bara trafik. Du försvinner från köpprocessen helt. Att göra saker värre, hela marknaden har panikattacker i betalda annonser, driver CPC till absurda nivåer och förstör diskret de enhetliga ekonomierna för de flesta SaaS-företag.

Denna skiftning slår traditionella utvecklarverktygsföretag särskilt hårt. SEO-drivna kundanskaffningskanaler som finansierade en generation B2B SaaS förlorar effektivitet snabbt. Alla som fortfarande förlitar sig på dem som en primär tillväxtmekanism behöver bygga alternativ aktivt 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 prissättning per huvud att fungera. Företag som inte omförpackar produkter runt värde snarare än huvudantal kommer att förlora MRR under de närmaste 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 den mönster är fortfarande några år bort, men att arkitektera 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 verkligt produktionsinflytande. Vilka är de nyckelfaktorer 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 verkligt produktionsinflytande.

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, arbetar teamet bakåt från tekniken för att uppfinna ett användningsfall. Resultatet är förutsägbart: en chatskärm 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 skeppas, får en pressrelease och presterar tyst under alla antagna antaganden om antagande. 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 teamen underskattar enormt skillnaden mellan ren demo-data och verklig produktionsdata. AI-demos körs på ren, kuraterad data. Produktion körs på den verkliga 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 kraftigt på live-data, och de flesta team upptäcker det inte förrän användare klagar. Kostnaden för den upptäckten i produktionstillit är sällan återvinningsbar.

En annan vanlig misslyckningspunkt ä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 har ingen 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 bleknat. Få produktteam har byggt om sin forskningspraxis för detta. De kör fortfarande 2019-spelböcker 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 genererad eller kostnad borttagen. Om du inte kan dra en rak linje från AI-funktionen till ett nummer på P&L, har du inte en produktionspåverkan. Du har en dyr 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 i 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 hårtkopplar AI till kärnupplevelsen utan ett sätt att inaktivera eller kringgå det, expanderar du inte din publik genom att lägga till AI. Du förlorar en sektor av din befintliga.

Det är exakt det problem vi löser med AI-konnektivitet. Regelefterlevnadsteam i reglerade branscher invänder inte mot AI själv. De invänder mot data som lämnar deras perimeter. Lösningen är inte att strippa AI; det är att ge dessa organisationer en AI-arkitektur som passar deras begränsningar. Det är varför AI-konnektivitet skeppas som lokal: AI-kapaciteten stannar, data lämnar aldrig kundens infrastruktur och inköp passerar granskning 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-kör åtta till tolv olika databasmotorer samtidigt: legacy Oracle för finans, PostgreSQL för nya tjänster, SQL Server för operativ, Snowflake eller BigQuery för analys och alltmer en vektorbutik för inbäddningar. Var och en har sitt eget dialekt, sitt eget verktyg, sitt eget styrningssystem. En utvecklare som ansluter till den miljön kan tillbringa tre månader med att lära sig var data bor och vem som får röra den.

AI löser inte den komplexiteten på egen hand. Den förstärker vad den än får. Å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 är 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, antingen Claude, GPT eller en intern modell, fungerar över hela fastigheten med konsekventa regler.

Det är den arkitektur vi bygger mot med AI-konnektivitet: 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 ange 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 intern samarbete och beslutsfattande 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ågon ledningsram 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 prissättningar?”, och får ett omedelbart svar, istället för att lägga till en Jira-biljett till analys 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ägga ett samtal med en senior ingenjör. Försäljningsrepresentanten får ett trovärdigt tekniskt svar i realtid, och affärs cykeln komprimeras.

Beslut flyttar in i samtalet snarare än i uppföljningen. Mönstret “låt mig återkomma till dig med det numret” 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 kollaps 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å proxy-mä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 rader kod eller stänga 500 supportbiljetter på en minut, blir mätning av aktivitet farligt vilseledande.

Vi flyttar explicit till sann resultatorienterad ledning, 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 ledningen måste vara villig att agera på den synligheten.

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

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 sida-projekt-databas och en företagsägd legacy-databas som om de vore desamma. De är inte.

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 hela ditt schema passar inom en LLM:s sammanhangsfönster 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 år av odokumenterad schemautveckling, tvärdatabasberoenden och anpassad triggerlogik i en prompt. När AI förlorar sammanhang på en stor databas, förvärras hallucinationer inte på ett tillfredsställande sätt. De multipliceras exponentiellt.

Risken som diskuteras för lite är falskt förtroende i skala. Naturliga språkgränssnitt är unikt bra på att producera trovärdiga men subtilt felaktiga svar. Om en SQL-fråga har ett syntaxfel, får du ett felmeddelande. Om ett naturligt språkgränssnitt missförstår “aktiva kunder” för att din data har sex olika definitioner av aktivitet, 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 bygga broar över sammanhangsgapet och skapa infrastruktur som låter AI operera säkert ovanpå.

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

Blickar du 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 chatskärm 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 en chatskärm. De flesta nuvarande verktyg misslyckas med den testen. Deras sammanhang återställs med varje session, och användaren betalar kostnaden för att bygga om det konstant.

För det andra måste verktygen kommunicera ordentligt med varandra. Din IDE måste prata med din databas, databasen med din övervakningsstack och CI/CD med din AI-granskare, etc. 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 antagandekurvan jag har sett i utvecklarinfrastruktur.

För det tredje kräver produktionsklassad AI allvarliga säkerhetsåtgärder. Förhandsgranskning av sprängområde före destruktiva operationer. Beroendeanalys. Automatiserad återställningsplan. Granskningsloggar som standard. AI utan dessa är bra för prototyper och farligt i produktion.

Hur man förbereder sig, konkret.

Granska din stack mot dessa tre komponenter. Har varje verktyg exponerat API 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 skeppar kommer att vara arton månader efter team som redan lär sig av verkliga produktionsmisslyckanden. Välj en lågriskig användningsfall. Skepp det. Bygg muskeln.

Team som fattar dessa beslut idag kommer att definiera de närmaste tio åren av hur programvara byggs. Fönstret är smalt, och det är öppet just nu.

Tack för det underbara samtalet, läsare som vill lära sig mer bör besöka Devart.