Tidligere Google-CTO deler hvordan han bruker KI til å bygge selskapet sitt fra grunnen av

Valliappa Lakshmanan er medgründer og teknologidirektør i Obin, et AI-basert selskap som bygger autonome agenter for arbeidsflyter innen finans. Tidligere var han direktør for analyse- og AI-løsninger i Google Cloud. Han har også omfattende erfaring med AI-integrasjon.

Vi satte oss ned med Lak for å forstå hvordan han bygger et AI-basert selskap. Dette er det han hadde å si.

Omfattende ekspertise innen AI-integrasjon

Jeg heter Lak og er medgründer og teknologidirektør i Obin. Vi bygger autonome AI-agenter som utfører arbeidsflyter innen finans fra ende til ende.

Jeg startet karrieren som maskinlæringsforsker, med fokus på varsling av ekstremvær. Vi var blant de første bransjene som bygget maskinlæringsmodeller i sanntid og satte dem i produksjon. Deretter førte bølgen av dyp læring-teknologi i 2014 meg over til privat næringsliv.

Jeg ledet teamet for analyse- og AI-løsninger i Google Cloud, der jeg jobbet med mange kunder som implementerte AI i produksjon. Deretter gikk jeg til Silver Lake, et private equity-selskap, hvor jeg bidro til å utforme og gjennomføre AI-strategien for selskapene i porteføljen deres.

Dermed har jeg omfattende ekspertise både innen implementering av AI i produksjon og innen å tenke nytt om hvordan virksomheter tilpasser seg og utnytter mulighetene i den nye teknologien.

Å jobbe mot en høy standard

Obin er mindre enn ett år gammelt, men vi har et team i rask vekst. Den tekniske utfordringen ved å bygge autonome AI-agenter innen finans er å gå fra å bygge chatboter og assistenter – der mennesker styrer hvert trinn i prosessen – til en modus der AI-en gjennomfører arbeidsflyten fra ende til ende, mens mennesker vurderer og fører tilsyn.

Dette gjenspeiler også tett hvordan vi bygger programvare – AI-agenter skriver mesteparten av koden under nøye oppsyn av ingeniørene våre.

Vi jobber med noen av de største selskapene innen finans om deres mest kritiske funksjoner, så kravene til oppgavegjennomføring og nøyaktighet er svært høye.

Derfor bruker vi Robin – agentrammeverket vårt som forenkler byggingen av agenter for regulerte bransjer og sikrer at de oppfyller alle nødvendige krav til samsvar og etterprøvbarhet.

Hvorfor selskaper bygget for AI har et fortrinn

Valliappa deler

Så lenge vi kan verifisere at koden fungerer, og koden er liten nok, er den svært pålitelig.

Siden selskapet er relativt nytt, har vi vært så heldige å kunne bygge på en agentbasert måte. Vi er fullt ut AI-baserte i alle funksjonene våre.

Fremfor alt bruker vi AI i stor utstrekning i programvareutviklingen. Claude Code genererer nesten all den første koden vår. Så lenge vi kan verifisere at koden fungerer, og koden er liten nok, er den svært pålitelig. Vi har også en Claude-gjennomgangsbot i CI/CD-systemet vårt som gjennomgår hver commit og PR. «Raske gevinster» og problemer som boten fremhever, har redusert belastningen på kodegjennomgåerne, slik at vi kan jobbe raskere.

En annen fordel er at vi ikke lenger trenger brukerhistorier eller PRD-er for å bygge programvare. Nå lager vi bare prototyper og gjentar prosessen.

AI genererer også designdokumentasjon fra koden, og vi bruker AI til å omformatere denne dokumentasjonen for ulike målgrupper (sikkerhet, dataarkitekter, AI-ingeniører osv.). Vi kan hente ut, fremheve og omformatere dokumentasjonen mye raskere enn et menneske ville klart manuelt.

Som et siste eksempel lager vi også presentasjoner for investorer og salg ved hjelp av AI.

Hvorfor det byr på utfordringer å lede AI-medarbeidere

Alle ingeniørene våre fungerer i praksis som en teknisk leder som har ansvar for en gruppe AI-medarbeidere. Takket være denne tilnærmingen har vi redusert tiden det tar å implementere funksjoner, og kodekvaliteten ble faktisk bedre på grunn av bedre feilhåndtering.

Utrullingstempoet bød imidlertid på en utfordring. Nå må vi håndtere utviklingsmiljøene nøye for å muliggjøre funksjonstesting.

Hvorfor KI-genererte artefakter krever nye gjennomgangsprosesser

Med økningen i KI-genererte artefakter – kode, konfigurasjonsfiler, dokumenter, prosesser og så videre – er det viktig for teknologiledere å skalere opp evnen til å gjennomgå dem. Du kan og bør opprette kontroller av korrektheten for hvert artefakt.

Her er et eksempel: Du kan sammenligne informasjonen i et betalingsvarsel med tidligere betalingsvarsler for samme avtale, låntaker og så videre.

Det er bedre å legge inn kontroller av korrektheten på forhånd enn å oppdage et problem med det KI-genererte artefaktet under kjøring!

Og deretter må du selvfølgelig bruke kontrollpunkter for menneskelig gjennomgang.

Hvor mennesker fortsatt må være til stede i KI-programvareutvikling

Når det gjelder kode, er det et tydelig skille mellom hva KI håndterer, og hva mennesker håndterer.

For øyeblikket får alle commits og PR-er en foreløpig KI-gjennomgang. Mennesker utfører imidlertid den endelige sammenslåingen av PR-er. En seniorutvikler fortsetter å gjennomgå alle PR-er med tanke på arkitektur.

Grensen går ved alt som innebærer kontekst utover kildekoden. Det betyr for eksempel at mennesker må håndtere alt som er knyttet til interessenter og regulatorisk kompleksitet.

Hvorfor domeneekspertise er viktig ved KI-integrasjon

KI fungerer best på områder der du har dyp ekspertise. Det er viktig å vite hvordan noe som er «bra», ser ut, slik at du kan iterere med modellen til den presterer godt.

På områder der vi ikke har ekspertise, har KI-resultatene hatt en tendens til å bli overfladiske.

Her er et eksempel. KI fungerte ikke godt til å generere sammendrag av avtalene våre uten videre tilpasning. Den klarte ikke å håndtere motstridende informasjon i kildedokumentene, og fokuserte ofte på de mest ekstreme utsagnene i stedet for de viktigste. Når det gjaldt informasjon uten forankring i kildene, hadde KI ikke sett nok informasjon fra private markeder til å fange opp nyansene. Og siden vi ikke var eksperter på området, syntes vi det var vanskelig å få den opp på riktig nivå.

Valliappa deler

Det er viktig å vite hvordan noe som er “bra”, ser ut, slik at du kan iterere med (KI-)modellen til den presterer godt.

Hvorfor teknologiledere må være forsiktige med å automatisere eksisterende prosesser

Når det gjelder automatisering, bør du ikke automatisere de nåværende prosessene dine. Bruk i stedet KI til å fjerne mellomtrinnene og gå rett til det endelige resultatet.

Tenk for eksempel på trinnene du følger for å lage et PowerPoint-lysbilde. Det er fristende å få KI-en til å følge nøyaktig disse trinnene, men et lysbilde er i bunn og grunn XML + bilder. KI-en kan generere det uten å følge trinnene dine. Denne ideen gjelder også forretningsprosesser – du kan opprette en faktura uten å bruke det nåværende systemet for fakturaoppretting. Bare kall de relevante API-ene i bakenden for å hente riktige priser og mengder.

Hvorfor KI kan skape kognitiv overbelastning

Her er en av de største ulempene jeg har sett for teknologiledere: Hastigheten KI-verktøy arbeider med, skaper en betydelig kognitiv overbelastning.

For å redusere overbelastningen innførte vi to timer med «fordypning» hver ettermiddag. Når det gjelder om det vil hjelpe, gjenstår det å se.

Følg med videre

Du kan følge Valliappa Lakshmanan på LinkedIn, eller ta en titt på Obin.

Det kommer flere intervjuer med eksperter på The CTO Club!