Professor Eran Yahav, Co-Founder og Co-CEO af Tabnine – Interviewserie

Professor Eran Yahav, Co-Founder og Co-CEO af Tabnine er en professor i datalogi ved Technion – Israel Institute of Technology, hvis forskning fokuserer på programmeringssprog, maskinlæring og softwareudvikling, særligt programsyntese og storstilets kodeanalyse. Sammen med sit akademiske arbejde co-foundede han Tabnine (oprindeligt Codota) for at anvende års forskning i praktiske udviklerværktøjer, der hjælper med at bane vejen for AI-drevet kodekompletion og automatisering. Hans arbejde brobygger mellem akademiet og industrien, med fokus på at gøre AI-genereret kode mere pålidelig, sikker og kontekstbevidst for virkelige virksomhedsmiljøer.

Tabnine er en AI-drevet kodningsplatform designet til at hjælpe udviklere i hele softwareudviklingslivscyklussen, fra skrivning og fejlfinding af kode til generering af tests og dokumentation. Oprindeligt lanceret som et kodekompletionsværktøj, er det udviklet til en bredere virksomhedsfokuseret platform, der integrerer generativ AI og agentbaserede arbejdsgange, der muliggør, at hold kan automatisere komplekse udviklingstasks, samtidig med at de opretholder stærk kontrol over privatliv, sikkerhed og overholdelse. Med støtte til dusinvis af programmeringssprog og integrationer på tværs af større IDE’er, sigter Tabnine mod at forbedre udviklerproduktiviteten, samtidig med at det sikrer, at AI-genereret kode forbliver troværdig og i overensstemmelse med virksomhedens standarder.

De har brugt år på at forskere i programanalyse og syntese på Technion og har tidligere arbejdet på IBM Research. Hvad var problemet i softwareudvikling, der overbeviste dig om at co-founde Tabnine, og hvordan formede din akademiske forskning virksomhedens oprindelige vision?

Mit akademiske arbejde fokuserede på programanalyse og syntese, som i virkeligheden handler om at lære maskiner at forstå og generere kode. Jeg gjorde min ph.d. i programanalyse, og det er også, hvor jeg tilbragte mine første få år med anvendt forskningsarbejde. At tackle softwarekvalitetsproblemer med programanalyse gjorde det klart, at nogle problemer er meget svære at løse, når programmet er skrevet forkert. En lille smule forebyggelse er værd at en stor del af kurering, hvis man må sige. Dette overbeviste mig om, at den rigtige måde at tackle softwarekvalitetsproblemer på er via programsyntese, som er, hvor jeg tilbragte det meste af min forskningstid og energi.

Jeg arbejdede først med programsyntese for samtidige programmer, hvor jeg forsøgte at automatisere skabelsen af samtidige programmer fra sekventielle. Jeg skiftede derefter til en mere generelt anvendelig programsyntese ved hjælp af maskinlæring.

Programsyntese ved hjælp af maskinlæring var også den grundlæggende idé, der drev Tabnine. Ideen, som nu synes åbenlys, var, at modeller kunne lære kodemønstre direkte fra store korpora af kode og assistere udviklere i realtid. Denne generelle idé er anvendelig på alle stadier af softwareudviklingslivscyklussen – fra kodeoprettelse til kodereview, til installation og ud over.

Visionen har altid været at supplere den menneskelige udvikler ved at give dem værktøjer, der accelererer udviklingsprocessen og fjerner friktion. Softwareudvikling er en kreativ og problemløsende disciplin, og målet var, at AI skulle fjerne friktion fra processen ved at håndtere rutineopgaver og hjælpe udviklere med at blive i flow. Den vision guider os stadig i dag, selvom teknologien har udviklet sig betydeligt siden de tidlige dage.

Tabnine var pioner inden for AI-kodningsassistenter år før, generativ AI blev mainstream med værktøjer som OpenAI’s modeller. Hvad har ændret sig i AI’s rolle i softwareudvikling siden de tidlige dage, og hvilke lærdomme har branchen draget fra den første bølge af kodningscopiloter?

Den første generation af AI-kodningsassistenter fokuserede primært på forudsigelse. De var i virkeligheden avancerede autocomplete-systemer, der hjalp udviklere med at skrive kode hurtigere ved at forudsige den næste linje eller funktion.

Hvad der er ændret med agentløkker, er, at AI nu kan håndtere opgaver med større autonomi, sådan at vi kan betragte agenter (med korrekt vejledning) som uafhængige juniorudviklere.

Men dette har også lært branchen en vigtig lærdom. Rå modelkapacitet er ikke nok til enterprise-softwareudvikling. Modeller, der er trænet på offentlige data, kan producere imponerende outputs, men de mangler ofte bevidsthed om en virksomheds arkitektur, afhængigheder og konventioner.

Det er derfor, at den næste udviklingsfase ikke kun handler om større modeller eller større kontekstvinduer, men om at tilkoble disse modeller til den virkelige kontekst, som software bliver bygget i.

Mange virksomheder opdager, at skalering af AI-agenter kræver mere end større modeller – det kræver dybere organisatorisk kontekst. Hvorfor tror du, at kontekst bliver den sande grænse for pålidelig AI-drevet udvikling?

Software-systemer er komplekse netværk af relationer. En enkelt ændring kan påvirke multiple tjenester, API’er eller downstream-komponenter.

AI-modeller i dag er meget gode til at generere plausibel kode, men de opererer ofte uden en struktureret forståelse af disse relationer. Uden denne forståelse kan AI ikke pålideligt resonere om konsekvenserne af en ændring.

Hvad virksomheder opdager, er, at pålideligheden af AI-systemer afhænger af kvaliteten af konteksten, som de opererer i. Hvis et AI-system forstår arkitekturen i systemet, afhængighederne mellem tjenester og virksomhedens kodestandarder, kan det generere kode, der er mere i overensstemmelse med, hvordan systemet faktisk fungerer.

I den forstand bliver kontekst den næste grænse for enterprise AI-udvikling.

Deres nye Enterprise Context Engine sigter mod at give AI-agenter en struktureret forståelse af en virksomheds arkitektur, afhængigheder og ingeniørpraksis. Hvordan adskiller denne tilgang sig fra almindelige metoder som retrieval-augmented generation, som mange virksomheder i dag afhænger af?

Retrieval-augmented generation er en nyttig teknik. Det giver modeller mulighed for at trække relevante dokumenter eller kodeeksempler, når de genererer en besked.

Men retrieval alene skaber ikke forståelse. Det giver adgang til information, ikke struktur.

Enterprise Context Engine er designet til at gå videre ved at opbygge en struktureret repræsentation af software-miljøet. Det analyserer repositories, tjenester, afhængigheder, API’er og arkitektoniske relationer og organiserer dem i en model af, hvordan systemet faktisk fungerer.

Dette giver AI-systemer mulighed for at resonere om relationerne mellem komponenter i stedet for kun at trække tekststykker. For komplekse enterprise-miljøer bliver denne forskel meget vigtig.

AI-kodningsværktøjer udvikler sig fra autocomplete-forslag til autonome agenter, der kan udføre multi-trins arbejdsgange. Hvordan ser du på ændringen i balancen mellem menneskelige udviklere og agenter over de næste fem år?

AI-agenter vil i stigende grad overtage rutineudviklingstasks. De er allerede i stand til at implementere funktioner fra ende til anden, herunder test og dokumentation. Hver udvikler bliver en teamleder for AI-udviklere. Den største udfordring vil være at kommunikere kravene til dette team og verificere, at de genererede artefakter matcher de fastlagte krav.

Men softwareudvikling er i virkeligheden en kreativ og problemløsende disciplin. Menneskelige udviklere vil fortsat definere arkitektur, træffe kompromiser og guide den overordnede retning for systemer.

Hvad der vil ændre sig, er niveauet af abstraktion, som udviklere arbejder på. I stedet for at fokusere på kode, vil udviklere i stigende grad orkestrere højere-niveauer arbejdsgange og samarbejde med AI-systemer, der udfører dele af disse arbejdsgange.

På den måde bliver udviklernes rol mere strategisk, mens AI håndterer mere af det mekaniske arbejde.

Tabnine har angivet, at enterprise-brugere kan se AI-genereret kodeaccepteringsrater nå op til omkring 80% i nogle miljøer. Hvordan skal organisationer bruge metrikker til at bestemme, om AI-kodningsværktøjer faktisk forbedrer udviklerproduktiviteten i stedet for kun at generere mere kode?

Hovedspørgsmålet er ikke, hvor meget kode AI genererer, men hvor meget brugbart arbejde det faktisk producerer.

Der er flere metrikker, organisationer skal spore. En af dem er first-pass accepteringsrater, som måler, hvor ofte AI-genereret kode kan bruges uden ændringer. En anden er review-cyklustid – hvor mange iterationer er nødvendige, før en pull-anmodning kan sammenføjes.

Organisationer skal også se på udviklertid, der bruges på omgørelse, samt lead-tid for ændringer fra udvikling til produktion.

Hvis AI-værktøjer faktisk forbedrer produktiviteten, skal man se forbedringer på tværs af disse metrikker. Udviklere bruger mindre tid på at rette genereret kode og mere tid på at arbejde med højere-værdi-opgaver.

Virksomheder er stadig forsigtige med at eksponere proprietær kode for eksterne modeller. Hvordan adresserer konceptet “Trusted AI Coding” regerings-, privatlivs- og overholdelsesproblemer, der har bremset virksomhedens adoption af AI-udviklingsværktøjer?

Tillid er en af de vigtigste faktorer i virksomhedens adoption af AI.

Tillid er den ultimative udfordring for at realisere AI-ingeniøren. Hvordan kan vi stole på AI-ingeniøren til at handle autonomt for at fuldføre kritiske software-ingeniør-opgaver? Hvordan kan vi sikre, at dens handlinger er i overensstemmelse med vores forventninger til kvalitet, sikkerhed og overholdelse af vores politikker? Hvis AI-ingeniøren skal være en accepteret del af vores ingeniørhold, skal den være lige så troværdig som vores velgennemførte og korrekt ombordviste kolleger.

At adressere denne udfordring afhænger af to kritiske søjler:

• Personliggørelse: Udstyre AI-ingeniøren med en intim forståelse af jeres organisation, kodebase og bedste praksis.
• Kontrol: Implementere robuste systemer til at sikre, at al kode – både AI-genereret og menneskeskrevet – opfylder jeres organisations kvalitets-, sikkerheds-, ydeevne- og pålidelighedstandarder.

Derudover indebærer Trusted AI Coding, at organisationer får kontrol over, hvordan AI bliver deployet, og at der sikres central regering og kontrol.

De har foreslået, at organisationskontekst kan blive en grundlæggende lag i enterprise AI-stakken – lignende databases eller cloud-infrastruktur i tidligere computerepoker. Hvad ser den fremtidige arkitektur ud til?

Hvis man ser på, hvordan enterprise-teknologi udvikler sig, ser man ofte nye infrastrukturlag opstå.

Databaser blev grundlaget for at håndtere data. Cloud-platforme blev grundlaget for at køre programmer i stor skala.

I AI-æraen vil organisationer have brug for infrastruktur, der giver AI-systemer mulighed for at forstå den interne struktur i virksomheden – dens systemer, relationer og operationelle begrænsninger.

Denne infrastrukturlag vil give struktureret kontekst, som multiple AI-systemer kan bruge, uanset om de er kodningsassistenter, support-agenter eller operationsautomatiseringsværktøjer.

På den måde bliver kontekst en fælles grundlag for enterprise AI.

Mange virksomheder bygger kodningsassistenter tæt sammenkoblede med en enkelt grundmodel. Tabnine giver i stedet virksomheder mulighed for at tilkoble forskellige modeller afhængigt af deres behov. Hvorfor er model-fleksibilitet vigtig for den lange udvikling af enterprise AI-udviklingsværktøjer?

AI-økosystemet udvikler sig meget hurtigt. Nye modeller udgives hyppigt, og forskellige modeller har ofte styrker i forskellige områder.

Virksomheder skal ikke have brug for at genopbygge deres udviklingsarbejdsgange hver gang model-landskabet ændrer sig. Ved at give organisationer mulighed for at vælge og skifte mellem modeller, giver vi fleksibilitet, der hjælper med at fremtidssikre deres AI-strategi.

Model-fleksibilitet giver også organisationer mulighed for at balancere ydeevne, omkostninger, privatlivskrav og installationsbegrænsninger.

På lang sigt vil virksomheder sandsynligvis operere i et multi-model-miljø, og udviklingsplatforme skal være designet med denne realitet i mente.

For CTO’er og tekniske ledere, der i dag vurderer AI-udviklingsplatforme, hvad er de største fejl, organisationer begår, når de implementerer AI-kodningsværktøjer, og hvordan kan de undgå dem?

En almindelig fejl er at fokusere kun på modelkapacitet. Større modeller er bestemt en kritisk komponent, men pålidelighed i virkelige miljøer afhænger af, hvor godt AI’en forstår systemet, det opererer i.

En anden fejl er at implementere AI-værktøjer uden at overveje regerings- og sikkerhedskrav. Virksomheder har brug for klare politikker om, hvordan kode adgang, hvordan modeller deployes, og hvordan outputs valideres.

Til sidst forventer organisationer ofte, at AI leverer umiddelbare produktivitetsgevinster uden at tilpasse arbejdsgange eller give tilstrækkelig kontekst. Succesfulde implementationer involverer ofte integration af AI i eksisterende udviklingsprocesser og tilkobling til virksomhedens kode og arkitektur.

Når disse elementer kommer sammen, kan AI blive en kraftfuld accelerator for softwareudvikling i stedet for bare endnu et værktøj.

Tak for det gode interview, læsere, der ønsker at lære mere, skal besøge Tabnine.