Professor Eran Yahav, medgrunnlegger og med-CEO av Tabnine – Intervju-serie

Professor Eran Yahav, medgrunnlegger og med-CEO av Tabnine, er en professor i datavitenskap ved Technion – Israel Institute of Technology, hvis forskning fokuserer på programmeringsspråk, maskinlæring og programvareutvikling, særlig programsyntese og stor-skala kodeanalyse. Sammen med sin akademiske arbeid, grunnla han Tabnine (opprinnelig Codota) for å anvende år med forskning på praktiske utviklerverktøy, og hjalp med å bane vei for AI-drevet kodekomplettering og automatisering. Hans arbeid broer akademiske og industrielle miljøer, med fokus på å gjøre AI-generert kode mer pålitelig, sikker og kontekst-bevisst for virkelige bedriftsmiljøer.

Tabnine er en AI-drevet kodeplattform designet for å hjelpe utviklere gjennom hele programvareutviklingslivssyklusen, fra å skrive og feilsøke kode til å generere tester og dokumentasjon. Opprinnelig lansert som et kodekompletteringsverktøy, har det utviklet seg til en bredere bedrifts-fokusert plattform som integrerer generativ AI og agent-basert arbeidsflyt, og muliggjør at team kan automatisere komplekse utviklingoppgaver samtidig som de beholder sterkt kontroll over personvern, sikkerhet og overholdelse. Med støtte for dusinvis av programmeringsspråk og integrasjoner over større IDE-er, har Tabnine som mål å forbedre utviklerproduktiviteten samtidig som de sikrer at AI-generert kode forblir pålitelig og i samsvar med organisatoriske standarder.

DU har brukt år på å forske på programanalyse og -syntese ved Technion, og arbeidet tidligere ved IBM Research. Hva var problemet i programvareutvikling som overbeviste deg om å grunnlegge Tabnine, og hvordan har din akademiske forskning formet selskapets opprinnelige visjon?

Min akademiske arbeid fokuserte på programanalyse og -syntese, som i hovedsak handler om å lære maskiner å forstå og generere kode. Jeg gjorde min doktorgrad på programanalyse, og dette er også hvor jeg tilbrakte mine første år med anvendt forskningsarbeid. Å løse programkvalitetsproblemer med programanalyse gjorde det klart at noen problemer er svært vanskelige å løse når programmet er skrevet feil. En unse av forebygging er verdt en pund av kur, hvis du vil. Dette overbeviste meg om at riktig måte å håndtere programkvalitet på er via programsyntese, som er hvor jeg tilbrakte det meste av min forskningstid og energi.

Jeg arbeidet først med programsyntese for samtidige programmer, og prøvde å automatisere skapelsen av samtidige programmer fra sekvensielle. Jeg skiftet deretter til en mer generelt anvendbar programsyntese ved hjelp av maskinlæring.

Programsyntese ved hjelp av maskinlæring var også den grunnleggende ideen som drev Tabnine. Ideen, som nå kan synes åpenbar, var at modeller kunne lære kode-mønster direkte fra store korpus av kode og assistere utviklere i sanntid. Denne generelle ideen er anvendbar gjennom alle stadier av programvareutviklingslivssyklusen – fra kodeoppretting til koderevisjon, til deployering og utover.

Visjonen har alltid vært å supplere den menneskelige utvikleren med å gi dem verktøy som akselerer utviklingsprosessen og fjerner friksjon. Programvareutvikling er en kreativ og problemløsende disiplin, og målet var for AI å fjerne friksjon fra prosessen ved å håndtere rutineoppgaver og hjelpe utviklere å forbli i flyt. Den visjonen guider oss fremdeles i dag, selv om teknologien har utviklet seg betydelig siden de tidlige dagene.

Tabnine var en pionér innen AI-kodestøtte flere år før generativ AI ble mainstream med verktøy som OpenAI sine modeller. Ser du tilbake, hvordan har rollen til AI i programvareutvikling utviklet seg siden de tidlige dagene, og hva lærte industrien av den første bølgen av kodestøtte?

Den første generasjonen av AI-kodestøtte fokuserte primært på prediksjon. De var i hovedsak avanserte autocomplete-systemer som hjalp utviklere å skrive kode raskere ved å predikere neste linje eller funksjon.

Hva som har endret seg med agent-løkker er at AI nå kan håndtere oppgaver med større autonomi, til den grad at vi kan betrakte agenter (med riktig veiledning) som uavhengige junior-utviklere.

Men dette har også lært industrien en viktig lek. Rå modellkapasitet er ikke nok for bedriftsprogramvareutvikling. Modeller trenet på offentlige data kan produsere imponerende utdata, men de mangler ofte bevissthet om en organisasjons arkitektur, avhengigheter og konvensjoner.

Dette er hvorfor den neste fasen av utvikling ikke bare handler om større modeller eller større kontekstvinduer, men om å koble disse modellene til den virkelige konteksten hvor programvare utvikles.

Mange bedrifter oppdager at skalerings-AI-agenter krever mer enn større modeller – det krever dypere organisatorisk kontekst. Hvorfor tror du at kontekst blir den sanne grensen for pålitelig AI-drevet utvikling?

Programvaresystemer er komplekse nettverk av relasjoner. En enkelt endring kan påvirke flere tjenester, API-er eller nedstrømskomponenter.

AI-modeller i dag er svært gode til å generere plausibel kode, men de opererer ofte uten en strukturert forståelse av disse relasjonene. Uten den forståelsen kan AI-en ikke pålitelig begrunne konsekvensene av en endring.

Hva bedrifter oppdager er at påliteligheten av AI-systemer avhenger av kvaliteten på konteksten de opererer i. Hvis et AI-system forstår arkitekturen til systemet, avhengighetene mellom tjenester og organisasjonens kode-standarder, kan det generere kode som stemmer mye bedre overens med hvordan systemet faktisk fungerer.

I den forstand blir kontekst den neste grensen for bedrifts-AI-utvikling.

Ditt nye Enterprise Context Engine har som mål å gi AI-agenter en strukturert forståelse av en organisasjons arkitektur, avhengigheter og ingeniørpraksis. Hvordan adskiller denne tilnærmingen seg fra vanlige metoder som f.eks. retrieval-augmented generering som mange bedrifter for tiden avhenger av?

Retrieval-augmented generering er en nyttig teknikk. Den lar modeller trekke inn relevante dokumenter eller kode-utdrag når de genererer et svar.

Men retrieval alene skaper ikke forståelse. Den gir tilgang til informasjon, ikke struktur.

Enterprise Context Engine er designet for å gå lenger ved å bygge en strukturert representasjon av programvare-miljøet. Den analyserer repository, tjenester, avhengigheter, API-er og arkitektoniske relasjoner og organiserer dem i en modell av hvordan systemet faktisk fungerer.

Dette lar AI-systemer begrunne relasjonene mellom komponenter i stedet for bare å trekke inn tekst. For komplekse bedriftsmiljøer blir denne forskjellen veldig viktig.

AI-kodetøy utvikler seg fra autocomplete-forslag til autonome agenter i stand til å utføre fler-trinns arbeidsflyt. Hvordan ser du for deg at balansen mellom menneskelige utviklere og agente systemer endrer seg de neste fem årene?

AI-agenter vil stadig ta på seg rutineutviklingsoppgaver. De er allerede i stand til å implementere funksjoner fra ende til ende, inkludert testing og dokumentasjon. Hver utvikler blir en teamleder for AI-utviklere. Hovedutfordringen vil være å kommunisere kravene til dette teamet og verifisere at de genererte artefaktene matcher de angitte kravene.

Men programvareutvikling er i grunn en kreativ og problemløsende disiplin. Menneskelige utviklere vil fortsette å definere arkitektur, gjøre avveiinger og lede den overordnede retningen av systemer.

Hva som vil endre seg er abstraksjonsnivået som utviklerne arbeider på. I stedet for å fokusere på kode, vil utviklerne stadig koordinere høyere-nivå arbeidsflyt og samarbeide med AI-systemer som utfører deler av disse arbeidsflytene.

I andre ord blir utviklerens rolle mer strategisk når AI håndterer mer av det mekaniske arbeidet.

Tabnine har indikert at bedriftsbrukere kan se AI-generert kode-akseptansrater nå rundt 80% i noen miljøer. Hvilke målinger bør organisasjoner bruke for å bestemme om AI-kodetøy faktisk forbedrer utviklerproduktivitet, og ikke bare genererer mer kode?

Hovedspørsmålet er ikke hvor mye kode AI genererer, men hvor mye nyttig arbeid det faktisk produserer.

Det er flere målinger organisasjoner bør spore. En er første-gangs akseptansrater, som måler hvor ofte AI-generert kode kan brukes uten modifikasjon. En annen er gjennomgangssyklus-tid – hvor mange iterasjoner er nødvendige før en pull-forespørsel kan slås sammen.

Organisasjoner bør også se på utviklertid brukt på omgjøring, samt levetid for endringer fra utvikling til produksjon.

Hvis AI-verktøy faktisk forbedrer produktivitet, bør du se forbedringer over disse målingene. Utviklere bruker mindre tid på å fikse generert kode og mer tid på å arbeide med høyere-verdi-oppgaver.

Bedrifter er fortsatt forsiktige når det gjelder å eksponere proprietær kode for eksterne modeller. Hvordan adresserer konseptet “Trusted AI Coding” styrings-, personvern- og overholdelsesproblemer som har bremset bedrifts-tilpasning av AI-utviklingsverktøy?

Tillit er en av de viktigste faktorene for bedrifts-tilpasning av AI.

Tillit er den ultimate utfordringen for å realisere AI-ingeniøren. Hvordan kan vi stole på AI-ingeniøren til å handle uavhengig for å fullføre kritiske programvare-utviklingsoppgaver? Hvordan kan vi sikre at dens handlinger er i samsvar med våre forventninger til kvalitet, sikkerhet og overholdelse av våre politikker? Hvis AI-ingeniøren skal være en akseptert medlem av våre ingeniørteam, må den være like pålitelig som våre godt verifiserte og riktig ombord-satte medarbeidere.

Å løse denne utfordringen avhenger av to kritiske søyler:

• Personliggjøring: Utstyre AI-ingeniøren med en intim forståelse av din organisasjon, kodebase og beste praksis.
• Kontroll: Implementere robuste systemer for å sikre at all kode – både AI-generert og menneske-skrevet – møter organisasjonens kvalitets-, sikkerhets-, ytelses- og pålitelighetsstandarder.

I tillegg betyr Trusted AI Coding å gi organisasjoner kontroll over hvordan AI deployeres, og sikre sentralisert styring og kontroll.

Du har foreslått at organisatorisk kontekst kan bli en grunnleggende lag i bedrifts-AI-stakken – lignende databaser eller sky-infrastruktur i tidligere datatidsalder. Hva ser den fremtidige arkitekturen ut som?

Hvis du ser på hvordan bedriftsteknologi utvikler seg, ser vi ofte nye infrastruktur-lag dukke opp.

Databaser ble grunnlaget for å håndtere data. Sky-plattformer ble grunnlaget for å kjøre applikasjoner i skala.

I AI-æraen vil organisasjoner trenge infrastruktur som lar AI-systemer forstå den interne strukturen til bedriften – dens systemer, relasjoner og operasjonelle begrensninger.

Den infrastruktur-lagen vil gi strukturert kontekst som flere AI-systemer kan bruke, enten det er kodestøtte-agenter, support-agenter eller operasjonell automatiserings-verktøy.

I den forstand blir kontekst en felles grunnlag for bedrifts-AI.

Mange bedrifter bygger kodestøtte-agenter tett koblet til en enkelt grunnmodell. Tabnine lar i stedet bedrifter koble forskjellige modeller avhengig av deres behov. Hvorfor er modell-fleksibilitet viktig for den lange utviklingen av bedrifts-AI-utviklingsverktøy?

AI-økosystemet utvikler seg svært raskt. Nye modeller utgis hyppig, og forskjellige modeller har ofte styrker i forskjellige områder.

Bedrifter bør ikke trenge å redesigne sine utviklingsarbeidsflyter hver gang modell-landskapet endrer seg. Ved å tillate organisasjoner å velge og bytte mellom modeller, gir vi fleksibilitet som hjelper med å fremtidssikre deres AI-strategi.

Modell-fleksibilitet lar også organisasjoner balansere ytelse, kostnad, personvern-krav og deployerings-begrensninger.

På lang sikt vil bedrifter sannsynligvis operere i et multi-modell-miljø, og utviklingsplattformer bør være designet med denne realiteten i mente.

For CTO-er og ingeniørledere som vurderer AI-utviklingsplattformer i dag, hva er de største feilene organisasjoner gjør når de deployer AI-kodetøy, og hvordan kan de unngå dem?

En vanlig feil er å fokusere bare på modell-kapasitet. Større modeller er definitivt en kritisk komponent, men pålitelighet i virkelige miljøer avhenger av hvor godt AI-en forstår systemet det opererer i.

En annen feil er å deployere AI-verktøy uten å vurdere styrings- og sikkerhetskrav. Bedrifter trenger klare politikker rundt hvordan kode aksesseres, hvordan modeller deployeres og hvordan utdata verifiseres.

Til slutt forventer organisasjoner ofte at AI skal levere umiddelbare produktivitetsgevinster uten å tilpasse arbeidsflyter eller gi tilstrekkelig kontekst. Suksessfulle deployeringer involverer vanligvis å integrere AI i eksisterende utviklingsprosesser og koble det til organisasjonens kode og arkitektur.

Når disse elementene kommer sammen, kan AI bli en kraftig akselerator for programvareutvikling i stedet for bare et annet verktøy.

Takk for det flotte intervjuet, lesere som ønsker å lære mer bør besøke Tabnine.