Ali-Reza Adl-Tabatabai, Gitarin perustaja ja toimitusjohtaja – Haastattelusarja

Ali-Reza Adl-Tabatabai, Gitarin perustaja ja toimitusjohtaja, on veteraani-insinöörijohtaja, jonka ura kattaa useita merkittäviä teknologiayrityksiä Silicon Valleyssä, mukaan lukien Uber, Google, Facebook, Intel, AMD ja IBM. Ennen Gitarin perustamista vuonna 2023 hän toimi Uberin insinööripäällikkönä, jossa hän avusti johtamaan yhtiön kehittäjäalustan aloitteita, seuraten aiempia johtajuutehtäviä Googlella, jossa hän valvoi sivuston luotettavuuden insinööritöitä tuotteille, kuten Viestintä, Valokuvat, Sosiaalinen, Pilvi ja tekninen infrastruktuuri.

Aikaisemmin urallaan hän työskenteli kääntäjätekniikoilla, virtuaalikoneilla, rinnakkaislaskennan järjestelmillä ja laitteiston optimoinnilla Intel Labsissa ja Facebookin HipHop VM -tiimissä, samalla opettaen edistynyttä kääntäjäsuunnittelua Stanfordin yliopistossa. Hänen pitkäaikainen taustansa ohjelmointikielissä, infrastruktuurin luotettavuudessa, kehittäjätyökaluissa ja suurten järjestelmien arkkitehtuurissa on asettanut hänet merkittäväksi hahmoksi kehittyvässä tekoälyvoittoisessa ohjelmistosuunnittelumaailmassa.

Gitar keskittyy kasvavaan ongelmaan, joka johtuu tekoälyavusteisen ohjelmistokehityksen noususta: validointiin ja turvallisuuteen valtavasta määrästä koneella generoituja koodia, joka nyt virtaa yritysjärjestelmiin. Alusta käyttää tekoälyagentteja automatisoimaan koodin tarkastelun, tutkimaan CI/CD-putkien epäonnistumisia, tunnistamaan virheitä ja haavoittuvuuksia, suosittelemaan korjauksia ja integroitumaan suoraan olemassa oleviin insinööritöihin työkalujen kautta, kuten GitHub, GitLab, Jenkins, Jira ja Slack. Sen sijaan, että kilpailisivat ainoastaan tekoälykoodin generoimisessa, yhtiö asettaa itsensä ympärille, mitä se kuvaa “agenteilla varustettujen laadun portteina”, auttaen insinööritiimejä ylläpitämään luotettavuutta, turvallisuutta ja operatiivista valvontaa ohjelmistokehityksen siirryttyä yhä enemmän autonomiseen ja tekoälyavusteiseen koodaukseen.

Olet johtanut insinööritiimejä Uberissa, Googlessa ja Intel Labsissa, työskennellessäsi suurten kehittäjäalustojen ja infrastruktuurin parissa. Mitkä kokemukset tästä matkalta johtivat sinut perustamaan Gitarin, ja miksi painotit koodin validointia sen sijaan, että koodin generointia?

Uberin, Googlen, Facebookin ja Intel Labsin parissa työskennellessäni kehittäjäalustoilla eri mittakaavoissa, sama opetus toistui: kehittäjäkokemus on kilpailuetu. Hyvät työkalut houkuttelevat ja pitävät parhaat insinöörit ja antavat yrityksille mahdollisuuden liikkua nopeasti. Kehittäjät haluavat nopeita, meluttomia työkaluja, jotka pitävät heidät työssä ja automatisoivat rutiinin työn. Mutta kehittäjätyökalut ovat syvälti hajanaisia, ja useimmat yritykset polttavat valtavat insinööriresurssit yhdenmukaisen kokemuksen kokoamiseen. Näin itse, kuinka paljon on vaikutusta korjaamalla tämän.

Tekoäly muuttaa yhtälön mahdollistamalla automatisoida paljon enemmän kehittäjän työnkulkua kuin aiemmin. Koodin generointi on jo hyvin kattava, mutta se on vain siirtänyt pullonkaulan eteenpäin, koodin validointiin, refaktorointiin ja ylläpitoon, minkä me nyt tuotamme ennennäkemättömässä määrin. Siinä Gitar keskittyy. Kun tekoäly kirjoittaa enemmän koodia, harvinainen resurssi ei ole generointi; se on luottamus, oikeellisuus ja ylläpidettävyys siitä, mitä toimitetaan. Koodin validointi on työnkulun osa, joka määrää, onko tekoälygeneroitu koodi turvallinen tuotantoon.

Koodin ylikuormitus on suuri ongelma monissa tiimeissä tällä hetkellä. Kuinka merkittävä ongelma tämä on yrityksissä tänään, ja missä kohdin tiimit kamppailevat eniten?

Muutos ei ole koodin kirjoittamisessa. Tuo osa on jo liikkeellä nopeammin kuin useimmat tiimit voivat absorboida. Mitä on muuttunut, on kaikki se, mitä seuraa. Tekoälytyökalut generoivat jatkuvan virtaan pull-pyyntöjä, usein nopeammin kuin tiimit voivat tarkastella niitä, mikä luo painetta järjestelmän osissa, jotka eivät olleet suunniteltu tälle tasolle.

Jokainen muutos on edelleen validoitava. Koodin tarkastelu, CI, turvallisuustarkastukset, hyväksynnät. Mikään näistä ei katoa vain siksi, että koodi on generoitu nopeammin. Mitä oli aiemmin hallittava virta, on muuttunut jonoksi. Tiimit eivät ole enää estyneitä ideoista tai toteutuksesta. He ovat estyneitä luottamuksesta. Voidaanko tämä toimittaa? Onko se turvallista? Rikkoiko se jotain hienoa?

Siinä kitka nykyään on. Ei luomisessa, vaan saadessa koodia valmiiksi ilman riskejä.

Teollisuus on keskittynyt pääasiassa koodin generoimiseen nopeammin. Miksi uskot, että validointi on jäänyt huomiotta, ja miksi se on tulevaisuudessa tärkeämpää?

Koska järjestelmä koodin generoinnin jälkeen ei ole kehittynyt samalla tahdilla. Kun tuotanto kasvaa, kaikki järjestelmän osat jälkeenpäin joutuvat paineen alle. Pull-pyyntöjen määrä kasvaa ja ne tulevat tiheimmin. CI-epäonnistumiset alkavat kasaantua. Tarkastelujaksoa on pakko tiivistää, koska kukaan ei ole aikaa mennä syvälle jokaisen muutoksen kanssa.

Laatu alkaa laskea, ei siksi, että insinöörit eivät välitä, vaan siksi, että määrä pakottaa kompromisseja. Alustatiimit ottavat enemmän taakkaa, käsitellessään putkiongelmia, triage-epäonnistumisia ja yrittäessään pitää asiat liikkeellä. Vanhemmat insinöörit joutuvat toimimaan koordinaattoreina, kokoamalla lokit, diagnostisoimalla ongelmia ja päättämällä, mitä on turvallista yhdistää.

Tiimit kohtaavat valinnan, joka ei toimi kummallakaan tavalla. Työnnä koodi nopeasti läpi ja selvitä regressioista myöhemmin, tai hidasta ja suojaa laatua, mutta hyväksy, että nopeus laskee. Tämä jännite on näkyvissä insinööriorganisaatioissa juuri nyt.

Gitar käyttää tekoälyagentteja koodin tarkasteluun, testaamiseen ja jatkuvaan integrointiin (CI) -työnkulkuun. Miten nämä agentit eroavat perinteisistä staattisista analyysityökaluista ja sääntöpohjaisista putkistosta?

Ero ei ole kosmeettinen. Oikea agentti tarvitsee tehdä enemmän kuin vain reagoida ärsykkeisiin. Se tarvitsee hallita monivaiheista työtä, suunnitella, käyttää työkaluja, pitää yllä asiayhteyttä ja edetä tehtävissä ilman jatkuvaa syötettä.

Useimmat järjestelmät eivät täytä tätä vaatimusta. Ne generoivat tuloksia, mutta eivät hallitse suoritusta. Kun nämä työkalut asetetaan todellisiin työnkulkuun, aukot tulevat nopeasti näkyviin. Ne eivät vähennä monimutkaisuutta. Useissa tapauksissa ne lisäävät toisen kerroksen, jonka joku on hallitseva.

Tämän vuoksi keskustelu siirtyy “onko meillä agenteja” kohti “mikä työ voidaan todella käsitellä luotettavasti”.

Luottamus on suuri este automaatioon ohjelmistokehityksessä. Miten Gitar varmistaa, että sen validointiprosessi on luotettava riittävästi tiimien luottamiseen?

Toimiva malli on yksinkertainen. Jakaa työn pienempiin askeliin. Määritellä selkeät rajat. Validoida tulokset jatkuvasti. Pitää ihmiset mukana siellä, missä päätökset kantavat riskiä.

Agentit voivat tarkastella koodia ja paljastaa ongelmia, joita on helppo missata suuressa mittakaavassa. Ne voivat analysoida CI-epäonnistumisia, ryhmitellä liittyviä virheitä ja osoittaa todennäköistä alkuperää. Ne voivat ehdottaa korjauksia ja joissain tapauksissa soveltaa niitä hallitusti.

Tämä vähentää määrää manuaalista triagea, jonka insinöörit on tehtävä. Se ei poista insinöörejä silmukasta, vaan muuttaa, mihin he käyttävät aikaa. Useimmat järjestelmät toimivat tarkastuskohtien, ei täydellisen itsenäisyyden, kanssa.

Gitar sallii tiimien luoda omat agenttinsa. Kuinka tärkeää on mukautuminen yritysten omaksumiselle, ja mitkä ovat joitain mielenkiintoisimmista käyttötavoista, joita näet?

Mukautuminen on olennaista yritysten omaksumiselle. Jokainen alustatiimi käyttää merkittäviä resursseja sovittamaan CI:ää yrityksensä tarkoituksiin, ja tämä on perinteisesti vaatinut mukautettuja skriptejä, konfiguraatiota, työkalujen integrointia, lokiprosessoreita ja muuta liimaa, joka pitää modernin kehitys-infrastruktuurin koossa.

Gitar tiivistää tämän työn. Alustatiimit voivat kirjoittaa mukautettuja tarkastuksia luonnollisen kielen ärsykkeillä, mikä mahdollistaa validoida asioita, jotka ovat vaikeita tai mahdottomia perinteisellä ohjelma-analyysillä, esimerkiksi liputtaa käyttäjän näkymien merkkijonoja, jotka ovat epäselviä käännöksille, tai validoida AGENTS.md-tiedostojen päivityksiä. He voivat myös automatisoida mukautettuja työnkulkuja pull-pyyntöjen yläpuolelle: linkittää PR: t Jira-ongelmiin, avata seurantatapaamisia ratkaisemattomista tarkastelukommenteista, automaattisesti uudelleenyritys epävakaita testejä tai liittää mukautettuja tehtävälistoja PR-yhteenvetoihin.

Mielenkiintoisimmat käyttötavat ovat usein sellaisia, joita emme olisi osanneet odottaa. Tiimit tuntevat koodipohjansa ja heidän kipukohtansa paremmin kuin mikään toimittaja, joten kun annamme heille primitiivin, joka muuttaa “toivomme, että CI voisi vain tarkastaa X” 10-riviseksi ärsykkeeksi, he alkavat heti automatisoida asioita, joita emme olisi koskaan rakentaneet oletusarvoisesti. Se on täsmälleen sitä, mitä haluamme.

Modernit insinööritiimit riippuvat monimutkaisesta työkalupinosta, kuten GitHub, GitLab ja Jira. Kuinka tärkeää on, että Gitar integroidaan olemassa oleviin työnkulkuun sen sijaan, että yritetään korvata ne?

Omaksuminen riippuu siitä, että kehittäjät tapetaan siellä, missä he jo ovat. Insinöörit eivät halua uutta pintaa, jota opetella, toista dashboardia tarkastella, tai enemmän kontekstivaihtoa työkalujen välillä. He haluavat, että heidän olemassa olevat työnkulkuunsa nopeutuvat ja hiljenevät. Joten integroida syvällisesti GitHubiin, GitLab, Jira ja loput pinosta ei ole meillä miellyttävä asia, vaan se on koko strategia.

Mutta meidän tavoitteemme menee pidemmälle kuin integrointi. Emme yritä korvata näitä työkaluja, emme yritä liittää niihin. Automatisoimme työnkulkuja, jotka toimivat niiden ylitse. PR-tarkastelu, lippujen linkitys, seurantatehtävät, epävakaiden testien uudelleenyritykset, kaikki tämä tapahtuu autonomisesti taustalla. Ja meidän pyrkimyksiemme on vielä pidemmälle: agentti muokkaa PR:ää suoraan koodin tarkastelupalautteen ja CI-epäonnistumisten korjaamiseksi ja lopulta käsittelee hyväksynnän ja yhdistämisen muutoksille, jotka täyttävät tiimin käytännöt. Kehittäjän rooli siirtyy ajamasta joka askelta tarkastelemaan tuloksia ja käsittelemään poikkeamia.

Lopputila ei ole uusi työkalu, johon kehittäjät kirjautuvat. Se on olemassa olevat työkalut, jotka tekevät enemmän itse, jotta kehittäjät voivat pitää fokuksensa työssä, joka edellyttää heidän arviointiaan.

Olet ehdottanut, että ihmisten koodin tarkastelut voivat lopulta tulla poikkeukseksi eikä säännöksi. Mitä on tapahtuvalla, jotta organisaatiot tuntisivat itsensä mukaviksi tämän muutoksen kanssa?

Luottamus rakentuu vaiheittain, ei kerran. Organisaatioiden on näytettävä, omalla koodillaan, että tekoäly voi löytää virheet ja haavoittuvuudet, jotka todella merkitsevät, ja pakottaa heidän mukautettuja sääntöjään tarkkuudella ja laajalla peittävyydellä. Siitä eteenpäin polku autonomiseen yhdistämiseen on luonnollinen eteneminen neljän asteikon kautta, joissa luottamus kasvaa.

Ensimmäinen taso on havaitseminen. Tiimit rakentavat luottamusta, että agentit löytävät todellisia ongelmia matalalla virheellisyydellä. Kun tämä luottamus on vakiintunut, he antavat tekoälylle estää PR: t, kun se löytää kriittisiä ongelmia.

Toinen taso on korjaus. Tekoäly ei ainoastaan lippaa ongelmia, vaan korjaa ne, estäen PR: n ja muuttaen CI: n vihreäksi ilman ihmisen väliintuloa. Luottamus tässä on, että agentti voi ratkaista ongelmia ja CI-epäonnistumisia tarkasti ilman rikkoa asioita.

Kolmas taso on hyväksyntä. Kun tiimit näkevät tekoälyagentit luotettavasti muuttaa PR: t vihreäksi, he antavat tekoälylle hyväksyä PR: t sääntöjensä mukaisesti. Antaen organisaatioille eksplisiittisen valvonnan ehtoja autohyväksynnälle, tekee tämän askeleen tuntua turvalliselta eikä hätäiltynä.

Neljäs taso on yhdistäminen. Tekoäly laskee muutoksen, jälleen ehdoin, joita tiimi on mukava. Tässä vaiheessa on oma kynnyksensä: agentin on resolvoitava yhdistämisen ristiriidat tarkasti ilman regressioiden tai päävirran rikkomista. Se on tärkeää, koska ristiriidan taajuus kasvaa commitin läpimenoaikaa, ja läpimenoaika räjähtää, kun tekoäly generoi enemmän koodia. Suuret monorepositoriot tuntevat jo tämän; kaikki muut ovat menossa samaan suuntaan.

Siirtymä tekoälystä oletusarvoiseksi tarkastelijaksi ei ole yksittäinen loikka uskoon. Se on tikapuut, ja organisaatiot kiipeävät sitä yhden porukan kerrallaan, kunnes näyttö kertyy.

Miten näet seniori-insinöörien roolin kehittyvän seuraavien vuosien aikana, kun tekoäly ottaa enemmän koodauksen prosessia?

Seniori-insinöörit ovat jo siirtymässä koordinaattorin rooleihin, kokoamalla lokit, diagnostisoimalla ongelmia ja päättämällä, mitä on turvallista yhdistää. Se ei ole rooli, jota kukaan on suunnitellut. Se on reaktio järjestelmän murtumiseen kuormituksen alla.

Kun agentit ottavat enemmän toistuvaa validointityötä, insinöörit pysyvät silmukassa, mutta siirtyvät ylemmäs pinossa. He viettävät vähemmän aikaa manuaalisessa triagessa ja enemmän aikaa päätöksissä siitä, mitä pitäisi toimittaa ja miksi.

Gitar on vastikään kerännyt 9 miljoonaa dollaria alustan laajentamiseksi. Mitkä ovat ensisijaiset tavoitteesi tämän pääoman kanssa, ja mitä onnistumista tarkoittaa seuraavien 12-18 kuukauden aikana?

Pääoma menee kahteen tärkeään kohteeseen. Ensimmäinen on markkinointi: skaalaa yritystoimintaa ja investoi kehittäjien tietoisuuteen, jotta tiimit, jotka hyötyvät Gitarista, tietävät, että olemme olemassa. Toinen on tuote: jatkaa rakentamista täydellisen autonomisen koodin validoinnin ja laadun visioon, mikä tarkoittaa syvempiä agenttien kykyjä, laajempaa työnkulun kattavuutta ja tiiviimpää integrointia työkalujen kanssa, joita kehittäjät jo käyttävät.

Onnistuminen seuraavien 12-18 kuukauden aikana näyttäytyy merkittävänä joukolla yritysasiakkaita, jotka ajavat Gitaria koodipohjansa ylitse, kehittäjäyhteisö, joka tunnustaa meidät oletusarvoiseksi tekoälyvoittoiseksi koodin validoinniksi, ja selvä näyttö siitä, että agenttimme tekevät enemmän tarkastelua, korjausta ja yhdistämistä autonomisesti ajan myötä. Jos olemme raiteilla, keskustelu vuoden kuluttua ei ole siitä, voivatko tekoälyt validoida koodia, vaan siitä, kuinka paljon validointiputkea tiimit ovat luovuttaneet agenteille. Kiitos hienosta haastattelusta, lukijat, jotka haluavat oppia enemmän, kannattaa vierailla Gitarissa.