Professori Eran Yahav, Tabninen co-perustaja ja toimitusjohtaja – Haastattelusarja

Professori Eran Yahav, Tabninen co-perustaja ja toimitusjohtaja, on tietojenkäsittelytieteen professori Technion – Israel Institute of Technologyssa, jonka tutkimus keskittyy ohjelmistoihin, koneoppimiseen ja ohjelmistotuotantoon, erityisesti ohjelmistosynteesiin ja laajamittaiseen koodianalyysiin. Akateemisen työn ohella hän perusti Tabninen (alun perin Codota) soveltamaan vuosien tutkimusta käytännön kehittäjätyökaluihin, jotta voisi edistää AI-vetoinen koodin täydentämistä ja automaatiota. Hänen työnsä yhdistää akateemisen ja teollisen alan, keskittyen siihen, että tekee AI-luotujen koodin luotettavammaksi, turvallisemmaksi ja kontekstiaavallisemmaksi todellisille yritysympäristöille.

Tabnine on AI-pohjainen koodausalusta, joka on suunniteltu avustamaan kehittäjiä koko ohjelmistokehityksen elinkaaren ajan, koodin kirjoittamisesta ja virheenkorjaamisesta testien ja dokumentaation luomiseen. Alun perin julkaistu koodin täydentämistyökaluna, se on kehittynyt laajemmaksi yritysten keskuudessa toimivaksi alustaksi, joka integroi generatiivisen AI:n ja agenttipohjaiset työvirrat, mahdollistaen tiimien automatisoida monimutkaisia kehitystehtäviä ylläpitäen vahvaa valvontaa yksityisyyden, turvallisuuden ja vaatimustenmukaisuuden suhteen. Useiden ohjelmointikielten ja merkittävien IDE-integraatioiden tukemana Tabnine pyrkii parantamaan kehittäjien tuottavuutta varmistamalla, että AI-luotu koodi pysyy luotettavana ja yrityksen standardeiden mukaisena.

Olet viettänyt vuosia tutkimalla ohjelmistojen analyysiä ja synteesiä Technionissa ja työskennellyt aiemmin IBM Researchissa. Mikä ohjelmistokehityksen ongelma sai sinut perustamaan Tabninen, ja miten akateeminen tutkimuksesi muovasi yrityksen alkuperäisen visioin?

Akateeminen tutkimukseni keskittyi ohjelmistojen analyysiin ja synteesiin, joka on perustuu opettamaan koneille koodin ymmärtämistä ja luomista. Teeni väitöskirjani ohjelmistojen analyysistä, ja tämä on myös paikka, jossa vietin ensimmäiset soveltavat tutkimuksen vuosini. Ratkaisemalla ohjelmistolaadun ongelmia ohjelmistojen analyysin avulla, selvisi, että jotkut ongelmat ovat hyvin vaikeita ratkaista, kun ohjelma on jo virheellisesti kirjoitettu. Ennakkoonvarautuminen on parempi kuin jälkikäteen korjaaminen, jos voisimme sanoa.

Työskentelin aluksi ohjelmistojen synteesin parissa rinnakkaisohjelmien luomiseksi sekvenssaalisista ohjelmista. Sitten siirryin yleisemmin sovellettavissa ohjelmistojen synteesiin käyttäen koneoppimista.

Ohjelmistojen synteesi koneoppimisen avulla oli myös Tabninen perusidea. Idea, joka nyt näyttää ilmeiseltä, oli, että mallit voivat oppia koodausmalleja suoraan suurista koodikorpusten avulla ja avustaa kehittäjiä reaaliajassa. Tämä yleinen idea on sovellettavissa kaikissa ohjelmistokehityksen elinkaaren vaiheissa – koodin luomisesta koodin tarkasteluun, käyttöönottoon ja sen ulkopuolelle.

Visio on aina ollut kehittäjien työn helpottaminen antamalla heille työkaluja, jotka nopeuttavat kehitysprosessia ja poistavat kitkaa. Ohjelmistokehitys on luova ja ongelmanratkaisuun perustuva tieteenala, ja tavoitteena oli, että AI poistaa kitkaa prosessista käsittelemällä rutiininomaiset tehtävät ja auttamalla kehittäjiä pysymään virtauksessa. Tuo visio ohjaa meitä edelleen, vaikka teknologia on kehittynyt merkittävästi niistä varhaisista päivistä.

Tabnine oli edelläkävijä AI-koodausavustajissa vuosia ennen kuin generatiivinen AI tuli tunnetuksi työkaluilla kuten OpenAI:n malleilla. Muistellessasi niitä varhaisia päiviä, miten AI:n rooli ohjelmistokehityksessä on kehittynyt, ja mitkä oppitunnit teollisuus on oppinut ensimmäisestä koodausavustajien aallosta?

Varhaisimmat AI-koodausavustajat keskittyivät lähinnä ennustamiseen. Ne olivat perustuu edistyneisiin autocomplete-järjestelmiin, jotka auttoivat kehittäjiä kirjoittamaan koodia nopeammin ennustamalla seuraavan rivin tai toiminnon.

Mikä on muuttunut agenttisilmukoiden myötä, on se, että AI voi nyt käsitellä tehtäviä suuremmalla itsenäisyydellä, jopa niin, että voimme pitää agenteja (oikean ohjauksen kanssa) itsenäisinä juniorikehittäjinä.

Se on myös opettanut teollisuudelle tärkeän oppitunnin. Raakamallin ominaisuudet eivät ole tarpeeksi yritysten ohjelmistokehitykseen. Julkisissa tiedoissa koulutetut mallit voivat tuottaa vaikuttavia tuloksia, mutta usein niillä on puute organisaation arkkitehtuurin, riippuvuuksien ja konventioiden tietämisestä.

Siksi seuraava kehitysvaihe ei ole vain suurempia malleja tai laajempia kontekstiruutuja, vaan yhdistää nämä mallit todelliseen kontekstiin, jossa ohjelmistoa kehitetään.

Monet yritykset ovat havainneet, että skaalaamalla AI-agenteja vaaditaan enemmän kuin vain suurempia malleja – vaaditaan syvempi organisaation konteksti. Miksi uskot, että konteksti on muuttumassa luotettavan AI-vetoisen kehityksen todelliseksi eturintamaksi?

Ohjelmistojärjestelmät ovat monimutkaisia suhteiden verkostoja. Yksittäinen muutos voi vaikuttaa useisiin palveluihin, rajapintoihin tai alirakenteisiin.

Nykyiset AI-mallit ovat hyviä luomaan uskottavaa koodia, mutta usein toimivat ilman järjestelmän suhteiden järjestelmällistä ymmärtämistä. Ilman tätä ymmärtämistä AI ei voi luotettavasti arvioida muutoksen seurauksia.

Mitä yritykset ovat havainneet, on se, että AI-järjestelmien luotettavuus riippuu kontekstista, jossa ne toimivat. Jos AI-järjestelmä ymmärtää järjestelmän arkkitehtuurin, palvelujen väliset riippuvuudet ja organisaation koodausstandardeja, se voi luoda koodia, joka on paljon lähempänä sitä, miten järjestelmä tosiasiallisesti toimii.

Tässä mielessä konteksti on muuttumassa seuraavaksi eturintamaksi yritysten AI-kehityksessä.

Uusi Enterprise Context Engine -lähestymistapa antaa AI-agenteille järjestelmällisen ymmärryksen organisaation arkkitehtuurista, riippuvuuksista ja insinööritöistä. Miten tämä lähestymistapa eroaa yleisesti käytetyistä menetelmistä, kuten retrieval-augmented generatiosta, jota monet yritykset tällä hetkellä käyttävät?

Retrieval-augmented generatiivinen menetelmä on hyödyllinen tekniikka. Se mahdollistaa malleille hakea relevantteja asiakirjoja tai koodinpätkiä vastauksen luomiseksi.

Mutta retrieval yksinään ei luo ymmärtämistä. Se tarjoaa pääsyn tietoihin, ei rakennetta.

Enterprise Context Engine on suunniteltu menemään pidemmälle rakentamalla järjestelmällisen edustuksen ohjelmistoympäristöstä. Se analysoi varastoja, palveluita, riippuvuuksia, rajapintoja ja arkkitehtuurisuhteita ja järjestää ne malliksi siitä, miten järjestelmä tosiasiallisesti toimii.

Tämä mahdollistaa AI-järjestelmien päättely suhteiden välillä komponenttien välillä eikä vain tekstinpätkien hakemisen. Monimutkaisissa yritysympäristöissä tämä ero tulee tärkeäksi.

AI-koodausvälineet kehittyvät autocomplete-ehdotuksista autonomisten agenttien, jotka pystyvät suorittamaan monivaiheisia työvirtoja. Miten näet kehittäjien ja agenteiden välistä suhdetta muuttuvan seuraavan viiden vuoden aikana?

AI-agenteista tulee yhä enemmän vastuussa rutiininomaisista kehitystehtävistä. Ne pystyvät jo toteuttamaan ominaisuuksia loppuun asti, mukaan lukien testaus ja dokumentaatio. Jokainen kehittäjä tulee olemaan AI-kehittäjien tiimijohtaja. Päähaaste olisi viestintä vaatimusten kanssa tälle tiimille ja varmistaminen, että luodut artefaktit vastaavat määriteltyjä vaatimuksia.

Kuitenkin ohjelmistokehitys on perustuu luovuuteen ja ongelmanratkaisuun. Ihmiskehittäjät jatkavat arkkitehtuurin määrittelyssä, tasapainottamisessa ja järjestelmien yleisen suunnan ohjaamisessa.

Mikä muuttuu, on se, että kehittäjien työn abstraktiotaso nousee. Sen sijaan, että keskittyisivät koodiin, kehittäjät tulevat yhä enemmän orkestroimaan korkeamman tason työvirtoja ja yhteistyöhön AI-järjestelmien kanssa, jotka suorittavat osia näistä työvirroista.

Toisin sanoen kehittäjien rooli muuttuu strategisemmaksi, kun AI käsittelee enemmän mekaanista työtä.

Tabnine on ilmoittanut, että yrityksien asiakkaat voivat nähdä AI-luodun koodin hyväksymisprosentin olevan noin 80 % joissakin ympäristöissä. Mitkä mittarit organisaatioiden tulisi käyttää määrittämään, ovatko AI-koodausvälineet todella parantamassa kehittäjien tuottavuutta vai ainoastaan luomassa enemmän koodia?

Avainkysymys ei ole, kuinka paljon koodia AI luo, vaan kuinka paljon hyödyllistä työtä se todella tuottaa.

On useita mittareita, joita organisaatioiden tulisi seurata. Yksi on ensimmäisen kierroksen hyväksymisprosentti, joka määrittää, kuinka usein AI-luotu koodi voidaan käyttää ilman muutoksia. Toinen on tarkastelukierroksen kesto – kuinka monta iteraatiota vaaditaan ennen kuin vetopyyntö voidaan yhdistää.

Organisaatioiden tulisi myös tarkastella kehittäjien aikaa, joka kuluu korjaustoimiin, sekä johtamisaikaa kehityksestä tuotantoon.

Jos AI-työkalut todella parantavat tuottavuutta, pitäisi nähdä parannuksia näissä mittareissa. Kehittäjät viettävät vähemmän aikaa korjaamassa luotua koodia ja enemmän aikaa korkeamman arvon tehtävissä.

Yritykset ovat edelleen varovaisia altistamasta omistajaohjelmistoa ulkoisille malleille. Miten “Trusted AI Coding” -käsite vastaa hallintoa, yksityisyyttä ja vaatimustenmukaisuuden huolenaiheita, jotka ovat hidastaneet yritysten ottamista AI-kehitystyökaluista?

Luottamus on yksi tärkeimmistä tekijöistä yritysten hyväksymisessä AI:ta.

Luottamus on lopullinen haaste AI-insinöörin toteuttamiselle. Miten voimme luottaa AI-insinööriin toimimaan itsenäisesti toteuttaakseen kriittisiä ohjelmistotuotannon tehtäviä? Miten voimme varmistaa, että sen toimet ovat linjassa odotuksiimme laatua, turvallisuutta ja vaatimustenmukaisuutta koskien? Jos AI-insinööri on hyväksyttävä jäsen meidän insinööritiimissämme, se on oltava yhtä luotettava kuin hyvin valittu ja asianmukaisesti perehdytetty tiimikaveri.

Tämän haasteen ratkaiseminen perustuu kahteen kriittiseen pilarin:

• Personointi: Varustamalla AI-insinööri syvällisellä ymmärryksellä organisaatiostasi, koodipohjastasi ja parhaista käytännöistäsi.
• Valvonta: Toteuttamalla vahvat järjestelmät, joiden avulla voidaan varmistaa, että kaikki koodi – sekä AI-luotu että ihmisten kirjoittama – täyttää organisaation laatu-, turvallisuus-, suorituskyky- ja luotettavuusvaatimukset.

Lisäksi Trusted AI Coding tarkoittaa antamista organisaatioille valvontaa siitä, miten AI:ta käytetään, ja varmistamista keskitetystä hallinnosta ja valvonnasta.

Olet ehdottanut, että organisaation konteksti voi tulla perustavanlaatuiseksi kerrokseksi yritysten AI-pilvessä – samalla tavalla kuin tietokannat tai pilvirakenteet aiemmissa laskentamahdollisuuksissa. Miltä tuo tulevaisuuden arkkitehtuuri näyttää?

Jos katsotaan, miten yritysten teknologia kehittyy, usein uudet infrastruktuurikerrokset tulevat näkyviin.

Tietokannat tulivat perustaksi tietojen hallintaan. Pilvi-alustat tulivat perustaksi sovellusten suorittamiseen laajassa mittakaavassa.

AI-aikakaudella organisaatioiden tarvitsee infrastruktuuria, joka mahdollistaa AI-järjestelmien ymmärtämisen yrityksen sisäistä rakennetta – sen järjestelmiä, suhteita ja toimintarajoituksia.

Tuo infrastruktuurikerros tarjoaa järjestelmällisen kontekstin, jota useat AI-järjestelmät voivat käyttää, olivat ne koodausavustajia, tukipalvelun agenteja tai toiminnan automaatiovälineitä.

Tässä mielessä konteksti tulee jaetuksi perustaksi yritysten AI:lle.

Monet yritykset rakentavat koodausavustajia, jotka ovat tiiviisti kytketty yhteen perusmalliin. Tabnine sallii yritysten yhdistää eri malleja tarpeidensa mukaan. Miksi mallin joustavuus on tärkeää yritysten AI-kehitystyökalujen pitkän aikavälin evoluutiolle?

AI-ekosysteemi kehittyy erittäin nopeasti. Uusia malleja julkaistaan usein, ja eri mallit usein ovat vahvoja eri aloilla.

Yritysten ei tarvitse uudelleen suunnitella kehitysprosessejaan joka kerta, kun mallimaisema muuttuu. Sallimalla organisaatioiden valita ja vaihtaa malleja, tarjoamme joustavuutta, joka auttaa tulevaisuuden näkymää heidän AI-strategiassaan.

Mallin joustavuus myös mahdollistaa organisaatioiden tasapainottaa suorituskykyä, kustannuksia, yksityisyyttä ja käyttöönottorajoituksia.

Pitkällä aikavälillä yritykset toimivat todennäköisesti monimallisen ympäristössä, ja kehitysalustojen on suunniteltava tämä todellisuus huomioon ottaen.

Mitä ovat suurimmat virheet, joita organisaatiot tekevät käyttäessään AI-kehitystyökaluja, ja miten he voivat välttää niitä?

Yksi yleinen virhe on keskittyminen vain mallin ominaisuuksiin. Suuremmat mallit ovat toki kriittinen osa, mutta luotettavuus todellisissa ympäristöissä riippuu siitä, kuinka hyvin AI ymmärtää järjestelmää, jossa se toimii.

Toinen virhe on AI-työkalujen käyttöönotto ilman hallinnon ja turvallisuuden vaatimusten huomioon ottamista. Yritysten on oltava selkeät käytäntöjä siitä, miten koodiin pääsy, mallien käyttöönotto ja tulosten validointi hoidetaan.

Lopulta organisaatiot odottavat usein, että AI tuo välittömästi tuottavuuden parantumista ilman sopeuttamista prosessejaan tai antamatta riittävää kontekstia. Onnistuneet käyttöönotot yleensä vaativat AI:n integroimista olemassa oleviin kehitysprosesseihin ja yhdistämistä organisaation koodiin ja arkkitehtuuriin.

Kun nämä elementit yhdistyvät, AI voi muuttua voimakkaaksi kiihdyttimäksi ohjelmistokehitykselle eikä ainoastaan ole työkalu.

Kiitos haastattelusta, lukijat, jotka haluavat oppia lisää, voivat vierailla Tabninen sivustolla.