
Hvor kodeagenter hjelper, og hvor de mislykkes

Pedro Alves
Teknologidirektør i Thoth AI

Pedro Alves forklarer hvor AI-kodeagenter kan gjøre utviklingsarbeidet raskere, hvor de introduserer skjulte risikoer, og hvorfor erfarne utviklere fortsatt er avgjørende.
Pedro Alves
Teknologidirektør i Thoth AI

Key Takeaways
Kodeagenter: Kodeagenter kan fremskynde implementeringen, men menneskelig dømmekraft må styre arkitektur, kvalitet og beslutninger i produksjon.
Skjulte feil: AI-generert kode kjører ofte uten problemer, samtidig som den skjuler logiske feil som erfarne gjennomgåere må oppdage.
Kreative begrensninger: Modeller håndterer veldefinerte oversettelsesoppgaver godt, men mennesker må bidra med uvanlige innsikter, forbindelser og grunnleggende beslutninger.
Utnyttelse av team: Organisasjoner oppnår mer ved å skalere erfarne fagfolk med AI enn ved å forsøke å løfte uerfarne team.
Sentral styring: Et lite, AI-fokusert team kan utvikle gjenbrukbare arbeidsflyter, redusere dupliserte eksperimenter og forbedre innføringen på tvers av avdelinger.
Pedro Alves har arbeidet omfattende med AI i 25 år. Han er for tiden CTO i Thoth AI og skaperen av Last Week in AI.
Vi satte oss ned med Pedro for å diskutere kodeagenter – og hvorfor det er så viktig å vite hva de kan og ikke kan gjøre. Her er det han fortalte oss.
Før «AI» var noe folk satte på lysbilder

Jeg er Pedro, CTO i Thoth AI. Jeg arbeidet med AI før det var noe folk satte på lysbilder – tilbake i 2001, da jeg studerte informatikk, bygde jeg en liten simulert verden full av agenter og lot dem lære å utmanøvrere hverandre, en slags digital variant av livets spill, der hele poenget var å se dem bli bedre. Det var for 25 år siden, og jeg jakter fortsatt på det samme spørsmålet: Hvordan får man et system til å forbedre seg?
Da tiden for videre studier kom, antok alle at jeg skulle ta en doktorgrad i maskinlæring. Det gjorde jeg ikke. Det føltes for snevert, for teoretisk. Jeg ville lære faget gjennom de rikeste og mest uoversiktlige dataene jeg kunne finne, så jeg gikk inn i beregningsbiologi: proteomikk i masteroppgaven og genomikk i doktorgraden. Jeg lærte meg maskinlæring, statistikk og datavitenskap ved å bruke det – gen-gen-interaksjonsnettverk, funksjonskonstruksjon, nevrale nettverk og ensemblemetoder – på problemer der det fikk konsekvenser å ta feil.
Det var der jeg lærte leksen som har formet alt siden. Innen medisin bygde jeg modeller for sykdomsutvikling, og det vanlige målekortet – samlet nøyaktighet – var ubrukelig. En «god» modell etter dette målet bekreftet bare på nytt tilfellene legene allerede kjente til, selv om hele verdien lå i tilfellene de ville overse. I stedet for å optimalisere nøyaktighet optimaliserte jeg derfor delvis AUC – i praksis modellens evne på tilfellene som betydde noe. Måltallet noen gir deg, er nesten aldri det egentlige målet.
Derfra var jeg innom ulike bransjer: disse medisinske modellene, en periode som konsulent for et profesjonelt fotballag, deretter Silicon Valley og flere år med datamaskinsyn – tilbake da man fortsatt måtte innovere både på hvordan man trente et nettverk og på hvordan man initialiserte vektene for i det hele tatt å få deteksjon og klassifisering til å fungere. Jeg arbeidet med data fra sosiale nettverk, detaljhandel, mote og video. Jeg brukte et år på å bygge handelsalgoritmer med genetiske algoritmer og partikkelsvermoptimalisering – ikke-parametriske optimaliseringsmetoder jeg hadde skrevet artikler om på universitetet. Til slutt startet jeg mitt eget selskap, der jeg bygde AI-verktøy for mennesker som ikke var dataforskere.
Bredden knytter alt sammen. Etter et dusin fagområder ser jeg stadig det samme problemet i ulike forkledninger – et triks som er åpenbart innen genomikk, viser seg å være nøkkelen innen datamaskinsyn. Jeg er mer opptatt av hvordan et problem formuleres enn av hvordan det løses, fordi det er i formuleringen påvirkningskraften ligger skjult.
Det er dette som fører meg til Thoth. På papiret er vi et selskap for dataannotering. Men jeg mener at problemet hele dette feltet forsøker å løse, er feil problem. Ingen ønsker annoterte data – data er bare mellomsteget. De ønsker en bedre modell. Derfor arbeider jeg mot en fremtid der et system finner ut hvilke data modellen din trenger for å bli bedre, og håndterer den delen for deg, slik at du kan konsentrere deg om modellen i stedet for merkingen.
More Articles
To sider av virksomheten
Strukturelt har Thoth AI to sider. Den ene siden er motoren for dataoperasjoner, som drives internasjonalt og i stor skala. Den er større enn en typisk oppstartsbedrift, men fortsatt mye mindre enn gigantene i bransjen, så jeg vil kalle den mellomstor. Den andre siden, den jeg bygger, er et helt nytt forsknings- og innovasjonsteam her i Bay Area – for tiden fem personer, med flere som begynner i løpet av de neste månedene. Der arbeider vi med resten av modellforbedringen: alt utover merking.
Forskningen vår har to hovedretninger. Den første er robotikk: å generere situasjonsforankrede data, evaluere dem og bruke aktiv læring til automatisk å generere best mulig treningsdata, slik at roboter kan lære oppgavene sine med minst mulig data. Det meste bruker egosentrisk data (i praksis førstepersonsopptak), og vi fokuserer mye av arbeidet vårt på å produsere egosentrisk data av høyest mulig kvalitet. Den andre retningen er pålitelighet og effektivitet i språkmodeller: å forstå hva som forårsaker hallusinasjoner og hvordan de ser ut, samt på effektivitetssiden å gjenkjenne når en mindre modell kan håndtere en forespørsel, og deretter omformulere den eller dele den opp i biter slik at en enklere og rimeligere modell kan besvare den. Alt dette er forskning i dag, med sikte på produkter vi skal lansere fra dette teamet.
Når det gjelder fase og størrelse, er datasiden en etablert, mellomstor internasjonal virksomhet, mens det amerikanske forskningsteamet bevisst er i en tidlig fase. Fem av oss er på San Mateo-kontoret vårt nå, og én eller to nye medarbeidere begynner i løpet av de neste månedene. Det er vår nåværende status.
Hvordan omfattende testing skaper pålitelige resultater

Pedro deler
Forberedelsene går nå stort sett av seg selv. Men det er ikke den egentlige gevinsten. Den største forbedringen er kvaliteten: møtet er skarpere og mer presist, og de riktige tingene når pålitelig frem til CEO-en.
Mange skynder seg med å automatisere alle oppgaver og funksjoner med AI, men jeg er forsiktig. AI gjør det trivielt å bygge en demo. Å bygge noe som er pålitelig i daglig bruk, er noe annet. Når du bruker disse verktøyene i praksis, støter du på spesielle og uvanlige tilfeller der automatiseringen nesten fungerer, men ikke helt. Derfor tester jeg grundig før jeg stoler på noe i en reell arbeidsflyt.
I år bygget jeg AI-verktøy for vårt ukentlige gjennomgangsmøte med CEO-en som besto denne testen. Det sender e-post til de ansvarlige for områdene for å samle inn oppdateringer, setter automatisk sammen svar, utarbeider rapporter, sammendrag og agendaen, og følger resultatene over tid.
Tidligere var alt dette manuelt. Noen måtte purre på folk for å få oppdateringer, sette sammen svarene manuelt, skrive sammendrag og agendaen, og følge opp resultatene fra uke til uke. Det fungerte, men det gikk sakte, og agendaen dreide lett mot det som var ferskest, i stedet for det som var viktigst.
Forberedelsene går nå stort sett av seg selv. Men det er ikke den egentlige gevinsten. Den største forbedringen er kvaliteten: møtet er skarpere og mer presist, og de riktige tingene når pålitelig frem til CEO-en. Det handler derfor mindre om spart tid og mer om å rette CEO-ens oppmerksomhet mot beslutningene som virkelig betyr noe.
Hvorfor vurderinger fortsatt gjøres av mennesker, mens AI fremskynder programmeringen

AI driver nå selve programmeringen, nesten overalt. Forskerne mine, ingeniørene som setter arbeidet vårt i produksjon, og jeg bruker alle AI-verktøy for programmering. Menneskelig vurdering, ikke en bestemt oppgavetype, avgjør hvordan kode bygges, og denne standarden endres med innsatsen som står på spill.
På forskningssiden er målet vanligvis å få noe til å fungere, ofte ved å sette opp et GitHub-repositorium for å teste om en idé er gjennomførbar. Ingenting går til produksjon, så jeg er overbærende når det gjelder hvordan det er skrevet. Hvis det fungerer og besvarer spørsmålet, er det tilstrekkelig.
Produksjon er annerledes. Hvordan vi bygger noe, betyr like mye som hvorvidt det fungerer, så vi bruker AI mer forsiktig. Senioringeniører har ansvar for arkitektur, kvalitet og gjennomganger. AI fremskynder arbeidet deres, men tar ikke disse beslutningene. Den grensen forblir menneskelig.
Teamets erfaringsnivå hjelper. De bruker AI annerledes enn mindre erfarne personer. De vet allerede hvordan noe godt ser ut, så modellen forsterker deres eksisterende vurderingsevne i stedet for å erstatte vurderingsevnen de fortsatt utvikler. Den gjør dem raskere uten å erstatte den avgjørende delen.
Slik bruker du kodeagenter effektivt
Nesten alle prosjekter har én unik ting de trenger: en ikke-opplagt innsikt eller beslutning som problemet krever … Det som får et prosjekt til å fungere, er vanligvis ikke gjennomsnittlig, og AI-en kan ikke komme frem til det på egen hånd. Det er min oppgave å finne den delen. Deretter bygger AI-en alt som følger av den, raskere og bedre enn jeg kunne gjort alene.

Alt i alt kommer kodeagentenes effektivitet av at jeg disiplinerer meg selv når det gjelder teknologiens styrker og svakheter.
Jeg ser på det som å male et lerret. Målet er alltid det samme: å tydeliggjøre bildet jeg har i hodet, og deretter bruke AI til å omsette denne hensikten til fungerende kode så raskt som mulig. Hvor godt det lykkes, avhenger av én variabel: hvor mye kreativt arbeid jeg beholder, kontra hvor mye jeg overlater til andre.
AI utmerker seg på det første nivået. Jeg kan se hele maleriet og legge ned brede penselstrøk, mens AI fyller inn detaljene. Jeg vet nøyaktig hva som må bygges, og å omsette hensikt til kode er i hovedsak formelbasert. Det er her AI virkelig fungerer som en kraftig forsterker, og det meste av det daglige arbeidet mitt hører hjemme her.
Det andre nivået er nyttig, men har større variasjon. Det ligner, men jeg lar med hensikt noen områder av lerretet stå åpne og ber modellen male noe der. Det krever noe kreativitet, men retningen min setter fortsatt rammene. Jeg behandler resultatet som et utkast, ikke som et svar.
Jeg advarer folk mot det tredje nivået. Det innebærer å overlate den kreative kjernen til AI: prosjektdefinisjonen eller de viktigste designbeslutningene. Det ser imponerende ut for noen som ikke kjenner fagområdet inngående, men det lykkes langt sjeldnere enn det mislykkes, fordi modellen fyller et tomrom jeg selv burde ha fylt.
Det gapet er hele poenget. Nesten hvert prosjekt har én unik ting det trenger: en ikke åpenbar innsikt eller beslutning som problemet krever. Som standard leverer modellen gjennomsnittsløsningen, det vanligste mønsteret fra treningen. Det som får et prosjekt til å fungere, er vanligvis ikke gjennomsnittlig, og AI kan ikke komme frem til det på egen hånd. Det er min oppgave å finne den delen. Deretter bygger AI alt som følger etter den raskere og bedre enn jeg kunne gjort alene.
Hvordan kodeagenter skaper feil som er vanskelige å oppdage

Pedro deler
Det tydeligste gode resultatet av kodeagenter er hastighet. Kodingen går raskere, noe som øker utrullingsfrekvensen vår, og det handler ikke bare om ren hastighet. Ting som var kompliserte å sette opp, er mye enklere nå. Den delen er reell, og den betyr noe.
Det tydeligste gode resultatet av kodeagenter er hastighet. Kodingen går raskere, noe som øker utrullingsfrekvensen vår, og det handler ikke bare om ren hastighet. Ting som var kompliserte å sette opp, er mye enklere nå. Den delen er reell, og den betyr noe.
Et mer interessant resultat er hvordan feilene våre har endret seg. Feilraten har ikke økt, men typene feil har endret seg. AI sørger for at koden kjører. Den sjekker nesten alltid dette før den gir den tilbake til deg. Derfor dukker de enkleste feilene – de som bare utløser en feilmelding eller gjør at koden ikke kjører – opp langt sjeldnere. Det som gjenstår, er logiske feil og tilfeller modellen ikke tenkte gjennom, og disse er vanskeligere å oppdage nettopp fordi koden kjører problemfritt.
Det er her ulempen ligger. Disse feilene skjuler seg bedre. Hvis noen mangler erfaring eller stoler for mye på verktøyet, ser de at koden kjører og antar at den er riktig, selv når den ikke er det. Faren er ikke flere feil; det er falsk trygghet. Du trenger noen som vet hva de skal se etter, for å oppdage ting som består testen «den kjører», men som likevel er feil.
Hvorfor AI bør brukes til å skalere erfarne folk i stedet for å forbedre mindre erfarne folk
Det som overrasket meg mest, var hvor skaleringseffekten kommer fra. Intuitivt skulle man tro at AI senker erfaringskravet, slik at man kan bemanne billigere og mer juniorpregede team og la verktøyene løfte dem opp. Det motsatte viste seg å være sant. Erfaring betyr mer nå, ikke mindre.
Det handler om pålitelighet. Å bruke AI til å gjøre én seniorutvikler til fem seniorutviklere er langt mer pålitelig enn å gjøre en juniorutvikler til en seniorutvikler. AI mangedobler vurderingsevnen du allerede har; den skaper ikke vurderingsevne du mangler.
Derfor skalerer jeg de sterkeste folkene mine utover; jeg prøver ikke å løfte de svakeste. Noen få erfarne personer, som hver leverer flere ganger så mye som før, slår et større blandet team hver gang.
Hvorfor mennesker må stå for kreativiteten – ikke AI

AI har tydeligvis ikke levert når det gjelder de kreative og forbindende sidene ved forskning. Når jeg gjør teknisk arbeid med hjelp fra AI, må et menneske fortsatt knytte sammen trådene: finne ut hvordan man kan bygge videre på andres arbeid, koble sammen to artikler på en måte som gir mening, og ta de logiske sprangene man ellers tar for gitt. Den delen krever fortsatt et menneske.
Dette er ikke overraskende når man husker hva disse modellene er. De er sannsynlighetsmaskiner. De produserer teksten som mest sannsynlig vil tilfredsstille leseren. Vi blir stadig bedre til å trene dem på andre typer oppgaver, men det blir virkelig vanskelig når man prøver å lære dem selve kreativiteten, fordi det er krevende å bygge treningssignalet.
Se på datasett. Et datasett for hvordan en hund ser ut, er enkelt. Du samler mange bilder av hunder. Et datasett for kreativitet i tegninger av hunder byr på et annet problem. Tenk for eksempel på noen som gir en hund vinger. Poenget med eksempelet er ikke vingene. Det er den abstrakte handlingen bak dem: å ta noe som ikke hører hjemme der, og plassere det et sted der det ikke forventes. For å få en modell til å forstå dette trenger du et enormt antall eksempler, slik at den lærer at vingene ikke er det viktige; det er den kreative handlingen som betyr noe.
Selv om den kommer dit, møter du den neste hindringen. Ta nå den samme kreativiteten og bruk den på en matematisk ligning eller et stykke kode fra en artikkel, for å videreutvikle andres algoritme. Det er ved denne typen overføring det bryter sammen.
Folk støtter seg på maskiner akkurat på det området der de er svakest. Ironien er at løsningen er billig. Litt menneskelig kreativitet kommer man langt med. Ikke stol for tungt på maskinen for den delen, så kommer du bemerkelsesverdig langt.
Hvorfor CTO-er må redesigne hvordan AI-evner beveger seg gjennom organisasjoner
Dette blir kanskje ikke det populære rådet akkurat nå, men jeg mener det er det fornuftige og det som mest sannsynlig vil lønne seg: Vær mer bevisst enn øyeblikket presser deg til å være.
Akkurat nå bruker selskaper enorme summer basert på en enkel antakelse: Alle kan automatisere deler av jobben sin med AI. Derfor sendes direktivet ut til alle. Ingeniører, datafolk, salg, markedsføring, hele selskapet. Skaff en konto, automatiser noe, bygg dine egne verktøy, sett i gang. Resultatet er en enorm mengde bortkastet innsats: dobbeltarbeid, prosjekter som ikke fører noe sted, og verktøy ingen bruker. Selskaper brenner av mye penger på innsats, tid og tokens som ikke skaper noe varig.
Lag en reell prosess rundt det. Sentraliser det. Ha et lite sentralt team med oppgave å gjøre alle andre team bedre med AI. De utvikler arbeidsflyter, gjenbrukbar kontekst, standarder og effektive mønstre, og distribuerer dem deretter slik at ikke hver enkelt ingeniør må betale oppdagelseskostnaden. Dette er den strukturelle versjonen av det jeg sa tidligere om å konsentrere påvirkningskraften hos de sterkeste medarbeiderne: noen få AI-kyndige ingeniører som løfter hele organisasjonen.
Dette gir to resultater samtidig. Utnyttelsesgraden øker fordi teamene bruker utprøvde mønstre i stedet for å gjette. Og dere vinner tilbake mye tid som i det stille går tapt på eksperimentering som aldri trengte å skje mer enn én gang.
Dette blir kanskje ikke det populære rådet akkurat nå, men jeg mener det er det fornuftige og det som mest sannsynlig vil lønne seg: Vær mer bevisst enn øyeblikket presser deg til å være… Lag en reell prosess rundt det. Sentraliser det. Ha et lite sentralt team med oppgave å gjøre alle andre team bedre med AI.

Følg med
Du kan følge Pedro Alves' arbeid på LinkedIn eller abonnere på nyhetsbrevet hans, Last Week in AI. Ta også en titt på Thoth AI.
Det kommer flere ekspertintervjuer på The CTO Club!

