AI-styrning får inte vara en eftertanke

Abhishek Ranjan är CTO på Apna och Blue Machines, där han är djupt involverad i att förändra både den mänskliga arbetskraften och AI-arbetskraften.

Vi satte oss ner med honom för att diskutera styrning i AI-arbetsflöden. Här är vad han sa.

Teknik tillsammans med människor

Jag heter Abhishek Ranjan. Jag är CTO på Apna och Blue Machines. Två mycket sammanlänkade men ändå olika världar har format min resa fram till denna punkt i AI-transformationen.

På Apna utvecklar vi lösningar för den mänskliga arbetskraften. Apna är ett av Indiens snabbast växande enhörningsföretag, med över 60 miljoner användare på plattformen. I den skalan får vi en mycket nära inblick i Indiens arbetskraft. Vi ser miljontals människor som söker bättre möjligheter, arbetsgivare som försöker rekrytera snabbare, olika språk, olika kompetensnivåer samt varierande nivåer av digital tillgång och självförtroende.

På Blue Machines utvecklar vi lösningar för AI-arbetskraften. Vi fokuserar på röst-AI för företag och hanterar miljontals minuter varje dag. Vi bygger mer än bara botar som svarar på frågor. Vi bygger AI-arbetare som kan prata med kunder, förstå sammanhang, ta emot feedback, förbättras över tid och utföra verkliga affärsarbetsflöden.

Jag har sett hur teknik hjälper människor att hitta arbete, utvecklas och delta i ekonomin. Och nu ser jag hur AI i sig håller på att bli en ny typ av arbetskraft som kan arbeta tillsammans med människor.

För mig handlar detta ögonblick därför inte bara om att använda AI för produktivitet eller om att skriva kod snabbare. Det handlar om att tänka om kring hur företag fungerar och hur själva arbetet utförs.

Arkitekturen för två mycket olika verksamheter

Arkitekturen på Apna är byggd som en storskalig marknadsplatsplattform. Vi har konsumentsystem, arbetsgivarsystem, dataplattformar, AI- och matchningssystem, sökfunktioner, kommunikation, lager för bedrägeribekämpning och förtroende, samt numera funktioner för AI-rekryterare och AI-baserad intervjuförberedelse ovanpå detta. Implementeringsmodellen är molnorienterad, mycket skalbar och byggd för hög tillgänglighet, eftersom miljontals användare och tusentals företag använder plattformen.

Teknikorganisationen har över 100 personer som arbetar med produktutveckling, backend, frontend, mobil, data, AI, infrastruktur, säkerhet och plattformsteam. Vi fokuserar inte bara på att bygga funktioner, utan också på att bygga tillförlitliga system som kan fungera i massiv skala.

Blue Machines är en annan typ av teknikorganisation. Den fokuserar på röst-AI för företag och agentbaserade arbetsflöden. Vi bygger AI-arbetare som kan prata, resonera, vidta åtgärder, integrera med affärssystem och förbättras genom feedback. I dag arbetar vi redan i betydande skala, med miljontals röst-AI-minuter varje dag.

Arkitekturen på Blue Machines är mer realtidsbaserad och från grunden byggd för AI. Den omfattar röstinfrastruktur, telefoni, tal-till-text, resonemang med LLM, text-till-tal, orkestrering av arbetsflöden, integrationer, analys, observerbarhet och utvärderingssystem. Produktkomplexiteten är hög eftersom röst-AI för företag måste fungera i produktion, i verkliga samtal, med låg fördröjning, hög noggrannhet, efterlevnadsskydd och tydliga affärsresultat.

På Blue Machines byggde ett kärnteam på fyra ingenjörer en distribuerad plattform för röstorkestrering på bara några veckor. Vi har också ett mycket meriterat forskarteam som arbetar på djupet med röst-AI, utvärdering av agenter, resonemang, fördröjning, flerspråkiga system och kontinuerlig förbättring av agenter. Det forskningsdjupet är viktigt eftersom röst-AI för företag inte kan lösas enbart genom att koppla ihop modeller. Det kräver stark produktutveckling, stark systemutveckling och stark tillämpad AI-forskning.

Övergripande befinner sig teknikorganisationen jag leder i skärningspunkten mellan storskaliga plattformar och AI-system som är byggda från grunden för AI.

Så förbättrar välstyrd AI programvarans livscykel

Under det senaste året har AI förändrat hur vi bygger, testar och lanserar teknik.

Tidigare var vår lanseringsprocess mer traditionell. Ingenjörer byggde funktioner, skapade pullförfrågningar, genomförde kollegiala granskningar, körde testfall och distribuerade sedan ändringarna genom den vanliga distributionspipen. Det fungerade, men utvecklingstakten berodde på mänskliga granskningscykler, manuell kvalitetssäkring och teamets förtroende för lanseringen.

När AI-assisterad kodning blev en större del av utvecklingen började vi använda den – och insåg snart att enbart hastighetsförbättringar inte räckte. AI kan hjälpa ingenjörer att skriva kod snabbare, men om styrningen inte förbättras kan den också skapa fler dolda buggar, förbisedda specialfall eller dåliga abstraktioner.

Därför ändrade vi vår verksamhetsmodell.

1. Vi lade till ett AI-assisterat lager för granskning av pullförfrågningar. Varje pullförfrågan kontrollerades avseende riskfylld logik, saknade specialfall, brutna API-kontrakt, säkerhetsproblem, migreringsrisker och bristande testtäckning innan mänsklig granskning. Detta minskade uppenbara missar före granskningen.
2. Vi stärkte CI-grindarna. En ändring kunde inte gå vidare enbart för att koden såg bra ut. Den var tvungen att klara enhetstester, integrationstester, lintning, säkerhetskontroller, tester av API-kontrakt och regressionssviter för det berörda produktområdet.
3. Vi byggde starkare regressionspaket för kritiska arbetsflöden. Det innebar till exempel att lägga till testfall för verkliga användarscenarier, specialfall, flerspråkigt beteende, felhantering och affärsresultat.
4. Vi ändrade styrningen av prompter. Mer om det om en stund.
5. Vi gjorde kanarielanseringar obligatoriska för högriskområden. I stället för att lansera för alla distribuerar vi till en liten andel av trafiken, övervakar fel, svarstid, konvertering, avhopp, agentkvalitet och kundpåverkan och rullar sedan ut bredare eller återställer ändringen.
6. Vi lade till bättre observerbarhet. När något gick sönder ville vi veta exakt vilken kodversion, promptversion, modell, vilket arbetsflöde eller vilket beroende som orsakade det.

Effekten har varit mycket tydlig. Vår lanseringstakt ökade betydligt. Team som tidigare lanserade större, samlade versioner går nu över till mindre och mer frekventa lanseringar. Inom vissa områden ökade lanseringsfrekvensen med nästan 2x till 3x eftersom kontrollerna är mer automatiserade och förtroendet är högre. Och det är så ett team på fyra personer byggde en distribuerad komplex plattform på några veckor.

Antalet produktionsproblem minskade också eftersom varje lansering är mindre, bättre testad och enklare att återställa. Vi ser en tydlig minskning av buggar i produktion, särskilt där automatiserade regressionstester och kanarielanseringar nu är obligatoriska. I dag ligger antalet fel nästan 40 % under den ursprungliga baslinjen.

AI ger enbart hastighet. AI med styrning ger hastighet och kvalitet.

Varför prompter måste behandlas som kod

Abhishek Shares

För AI-system började vi också behandla prompter som kod…Detta har varit en viktig förbättring. Vi vet vilken prompt som var aktiv, vad som ändrades, vad som förbättrades och om kundresultaten blev bättre.

För AI-system började vi också behandla prompter som kod.

Nu versionshanterar, granskar, testar och befordrar vi prompter mellan miljöer och rullar ut dem stegvis. Prompter behandlas inte längre som små konfigurationsuppdateringar. De genomgår testkörningar, tester av specialfall, flerspråkiga kontroller, svarstidstester, efterlevnadskontroller och kontroller av affärsresultat.

Vi kan först lansera en ny prompt eller ett nytt agentarbetsflöde till en liten andel av trafiken, observera resultaten och sedan befordra det om mätvärdena ser bättre ut.

Detta har varit en viktig förbättring. Tidigare var det svårt att veta om en promptändring förbättrade agenten eller bara ändrade dess beteende. Nu kan vi jämföra versioner mer objektivt. Vi vet vilken prompt som var aktiv, vad som ändrades, vad som förbättrades och om kundresultaten blev bättre.

Den större förändringen är att hela teknologisystemet blev mer automatiserat, mer mätbart och bättre styrt.

Ett agentiskt arbetsflöde för tekniska lanseringar

Vi använder ett agentiskt arbetsflöde för tekniska lanseringar, där människor deltar vid viktiga tidpunkter.

Det här arbetsflödet fungerar inte för varje lansering. För mycket komplexa plattformsändringar, djupgående arkitekturändringar eller känsliga system använder vi fortfarande en mer traditionell, människostyrd process. Men för vissa produktområden, särskilt arbetsflöden som utvecklas snabbare, har det blivit standardmetoden för utveckling.

Här är arbetsflödet:

1. Processen börjar när ett produktkrav eller ett tekniskt problem kommer in. En AI-planeringsagent läser kravet, delar upp det i uppgifter, identifierar beroenden, markerar riskområden och föreslår en implementeringsplan. Ingenjören granskar planen, korrigerar antaganden och beslutar om det slutliga tillvägagångssättet.
2. Därefter genererar en kodagent kod, omstrukturerar moduler, skriver standardkod och skapar enhets- och integrationstester. En granskningsagent kontrollerar pull requesten med avseende på riskfylld logik, saknade specialfall, säkerhetsproblem, brutna API-kontrakt och luckor i testningen.
3. Nästa steg är att en testagent skapar regressionsscenarier och validerar specialfall. För AI-arbetsflöden kör den även promptutvärderingar, konversationstester, flerspråkighetskontroller, latenskontroller och kontroller av affärsresultat.
4. Releaseagenten rekommenderar sedan om ändringen är säker för kanarieutplacering baserat på testresultat, påverkansområde, tidigare fel och beredskap för observerbarhet. Människor godkänner dock fortfarande kritiska lanseringar, särskilt om ändringen påverkar intäkter, kundupplevelse, säkerhet eller den centrala infrastrukturen.
5. När ändringen har släppts övervakar övervakningsagenten fel, latens, konvertering, avhopp, agentkvalitet och kundpåverkan. Om något verkar vara fel rekommenderar den en återställning, öppnar en incident, sammanfattar loggar och skapar ett första utkast till RCA.

Det här arbetsflödet är agentbaserat, men inte blint autonomt. AI-agenter planerar, kodar, granskar, testar, släpper, övervakar och sammanfattar. Människor godkänner, ifrågasätter, prioriterar och äger det slutliga beslutet.

Där Claude Code och Cursor utmärker sig

Mina favoritverktyg är Claude Code och Cursor, beroende på arbetsflödet.

Cursor utmärker sig när ingenjörer vill ha AI djupt integrerad i sin IDE för den dagliga kodningen, omstruktureringen, förståelsen av kodbasen och snabbare implementering.

Claude Code är mycket användbart för mer agentbaserade uppgifter: att förstå större kodbaser, göra ändringar i flera filer, generera tester, åtgärda problem och iterera som en teknisk partner.

Varför AI ger hävstång medan människor bidrar med omdöme

Vi förlitar oss nu i hög grad på AI för allt som förbättrar hastighet, täckning eller konsekvens, men inte för uppgifter som kräver omdöme, ansvar eller långsiktiga avvägningar.

AI hjälper oss till exempel nu med kodgranskning, generering av testfall, regressionstäckning, dokumentation, felsökning, logganalys och till och med incidenttriage. Den kan snabbt identifiera riskfyllda kodvägar, saknade specialfall, möjliga säkerhetsproblem eller mönster i produktionsfel. I AI-system hjälper den oss också att jämföra promptversioner, utvärdera konversationer och förstå var en agent misslyckas.

Men de slutliga besluten förblir mänskliga. Här är några exempel:

• Arkitekturbeslut måste förbli mänskliga eftersom de innebär avvägningar kring skala, kostnad, tillförlitlighet, teamets förmåga och produktens långsiktiga inriktning.
• En fullständig RCA kan få hjälp av AI, men människor måste fortfarande knyta ihop trådarna, validera hypotesen och besluta om åtgärden.
• Prioritering av backloggen förblir mänsklig eftersom den kräver kundkontext, affärsstrategi och omdöme kring vad som verkligen är viktigt.
• Säkerhetsgranskningar använder AI, men expertomdöme är nödvändigt. AI kan flagga problem, men kan också skapa falska positiva resultat eller missa risker som beror på affärskontexten. Människor behåller ansvaret eftersom riskerna och ansvarsutkrävandet är för stora.

Verkliga exempel på AI:s brister i tekniskt omdöme

Här är ett par exempel på vikten av mänskligt omdöme.

Det första gällde latensspikar på millisekundnivå i vår röstpipeline. AI kommenterade problemet korrekt och identifierade att latensen i en sökväg kunde bli ett problem. Men koden som föreslogs var felaktig. Den såg ren ut, men skulle ha skapat en annan flaskhals under belastning. En mänsklig ingenjör klev in, förstod körningsbeteendet och åtgärdade det ordentligt.

Ett annat exempel uppstod under produktionsfelsökning. Flera nedströmsystem slutade fungera, och AI fortsatte att analysera dessa system var för sig och föreslå optimeringar. Men vi visste redan att det verkliga problemet var ett uppströmsberoende som hade slutat fungera först. AI blandade ihop synliga fel med grundorsaken.

Det är här AI fortfarande har svårt. Det kan läsa loggar, sammanfatta spårningar, föreslå lösningar och snabba upp felsökningen. Men i komplexa distribuerade system kan det missa orsakssamband, tidsförlopp och systemkontext.

Varför team blir mindre men får större bredd

AI har förändrat rekryteringsprofilen mer än organisationsschemat.

Tidigare rekryterade vi för smalare funktionell spetskompetens: backend, frontend, QA, DevOps, data och så vidare. Dessa färdigheter är fortfarande viktiga, men nu värdesätter jag ingenjörer som kan arbeta över hela teknikstacken, använda AI på djupet och ta sig från problem till produktion med betydligt mindre handledning.

De bästa ingenjörerna skriver inte bara kod längre. De utformar arbetsflöden, använder AI för implementation, genererar tester, granskar resultat, felsöker snabbare och tänker på lanseringskvalitet.

Därför försköts rekryteringskraven mot ingenjörer med stort ägarskap och gott omdöme. Personer som kan ställa rätt frågor, verifiera AI:s resultat, förstå system på djupet och leverera självständigt.

Det har också minskat behovet av stora team inom vissa områden. Ett mindre team med stark hävstång från AI kan nu utföra arbete som tidigare krävde betydligt fler personer.

Varför AI gör det svårare att utbilda nya ingenjörer

Abhishek delar med sig

Jag tror inte att det är lösningen att förbjuda AI eller tvinga människor att koda som om det vore 2010. Det vore fel. Men jag tror inte heller att vi helt har löst hur man bygger ett djupt ingenjörsomdöme när AI utför så mycket av förarbetet. Just nu är mitt bästa svar att göra förståelsen synlig.

Hur utbildar vi nya ingenjörer i AI-eran? Jag har ännu inget perfekt svar.

När vi började hjälpte IDE:er oss. Sedan hjälpte Google oss. Därefter hjälpte Stack Overflow oss. Men under alla dessa faser var du fortfarande tvungen att kämpa dig igenom problemet. Du var tvungen att förstå svaret, anpassa det, felsöka det och lära dig varför det fungerade.

Med AI och vibe-kodning kan vi hoppa över den kampen. En ny ingenjör kan generera fungerande kod utan att verkligen förstå systemet, avvägningarna eller fellägena. Det oroar mig.

Jag tror inte att det är lösningen att förbjuda AI eller tvinga människor att koda som om det vore 2010. Det vore fel. Men jag tror inte heller att vi helt har löst hur man bygger ett djupt ingenjörsomdöme när AI utför så mycket av förarbetet.

Just nu är mitt bästa svar att göra förståelsen synlig. Ingenjörer bör kunna förklara varför koden fungerar, var den kan fallera, vilka tester som är viktiga, vad som händer i stor skala och hur de skulle felsöka den i produktion.

Så hanterar du tokenanvändning

Kostnaden har också varit en utmaning med AI.

Tokenanvändningen verkar obetydlig i början, men när AI används för kodning, granskningar, testning, felsökning och agentbaserade arbetsflöden kan kostnaden växa mycket snabbt.

Därför måste vi nu mäta avkastningen på investeringen per arbetsflöde och använda smartare orkestrering. Alla uppgifter kräver inte den dyraste modellen.

Framtiden handlar om att använda rätt modell för rätt uppgift.

Varför CTO:er måste agera snabbt – med kontrollmekanismer

Här är mitt råd: Bygg snabbt. Experimentera snabbt. Inför AI i verkliga arbetsflöden inom teknik, produkt, support, försäljning, verksamhet och interna processer. Låtsas inte att det inte fungerar. Det fungerar, ibland förvånansvärt bra.

Men bli inte blinda anhängare. AI är kraftfullt, men det är inte magi. Du behöver kontroll, styrning, testning, observerbarhet och tydligt ägarskap. Annars skapar du bara kaos snabbare.

Det rätta tankesättet är varken ”AI kommer att ersätta allt” eller ”AI är överhajpat”. Det rätta tankesättet är ”hur använder jag detta för att göra min organisation tio gånger mer kapabel?”

Följ med

Följ Abhishek Ranjan på LinkedIn. Läs också hans nyhetsbrev Hacktivate.

Fler expertintervjuer kommer snart på The CTO Club!