History rhymes: Miksi seuraava tittelisi on AI Agent Engineer

Historialla on jännä tapa toistaa itseään – yleensä juuri silloin, kun olemme ehtineet mukavoitua.

Kuvittele 90-luvun loppu. Jos osasit painia HTML:n ja pienen Perl- tai PHP-pätkän kanssa toimivaksi verkkosivuksi, olit velho. Olit Web Engineer, ja maailma oli avoinna sinulle. Rakensit internetin näyteikkunoita.

Kelaa vuoteen 2009. iPhone oli juuri mullistanut maailman. Yhtäkkiä ketään ei kiinnostanut staattinen verkkosivusi yhtä paljon. Energia siirtyi Objective-C:hen ja Javaan. Jos olit Mobile App Engineer, kirjoitit tulevaisuutta. Rakensit työkaluja, joita ihmiset kantoivat taskuissaan.

Katso nyt vuotta 2024. Ilma tuntuu taas ohuelta ja sähköiseltä. Sovelluskaupat ovat täynnä; web on ruuhkainen. Mutta pinnan alla tapahtuu tektoninen muutos. Olemme jättämässä käyttöliittymien (Interface) aikakauden ja siirtymässä agenttien (Agent) aikakauteen.

Seuraavan vuosikymmenen aikana arvokkain titteli ei ole "Full Stack Developer" tai "iOS Engineer". Se on AI Agent Engineer.

Uusi tektoninen muutos

Tämä ei ole vain yksi uusi framework-sota tai uusi ohjelmointikieli opeteltavaksi. Tämä on perustavanlaatuinen muutos siinä, kuka tekee työn.

Viimeiset kaksikymmentä vuotta ohjelmistokehitys on tarkoittanut selkeiden, determinististen polkujen rakentamista ihmisten klikkailtavaksi. Sinä rakensit napin; ihminen klikkasi sitä; koodi suoritti funktion. Ihminen oli aivot; ohjelmisto oli lihas.

Tämä asetelma on kääntymässä päälaelleen.

Agenttien aikakaudella ohjelmisto tarjoaa aivot. Työsi ei ole enää rakentaa nappia ihmisen klikattavaksi. Työsi on rakentaa digitaalinen työntekijä, joka päättää milloin nappia painetaan – tai vielä parempaa, päättelee, ettei nappia edes tarvita.

Olen rakentanut tuotteita yli kymmenen vuotta, ja tunnen maan liikkuvan jalkojen alla. Jos osaat kirjoittaa agentin tänään – sellaisen, joka palvelee sinua, automatisoi työnkulkusi tai palvelee asiakkaitasi – sinulla on sama vipuvoima kuin sillä nörtillä vuonna 1999, joka oli juuri oppinut laittamaan yrityksen nettiin.

Mutta tässä on karu totuus: Jos kieltäydyt oppimasta tätä, jos pitäydyt puhtaasti deterministisessä koodauksessa, olet vaarassa muuttua digitaaliseksi vastineeksi latojalle taitto-ohjelmien aikakaudella.

Taikuuden avaaminen: Työkalut ja Konteksti

Kun ihmiset kuulevat termin "AI Agent", he kuvittelevat Skynetin tai jonkin mahdottoman monimutkaisen neuroverkkoarkkitehtuurin. Unohdetaan hype hetkeksi.

Agentin rakentaminen ei ole taikuutta. Se on insinöörityötä. Ja se tiivistyy kahteen asiaan: Työkaluihin (Tools) ja Kontekstiin (Context).

Olen huomannut, että useimmat kehittäjät tekevät tästä liian monimutkaista. He luulevat, että heidän täytyy kouluttaa malleja. Ei tarvitse. Mallit – Claude, GPT-4, Llama – ovat jo tarpeeksi fiksuja. Sinun tehtäväsi on antaa niille kädet ja muisti.

1. Työkalut (Käsien antaminen mallille)

Suuri kielimalli (LLM) on vain aivot purkissa. Se osaa ajatella, mutta se ei voi koskettaa maailmaa. "Agentti" on yksinkertaisesti LLM, jolle on annettu pääsy API-rajapintoihin tai CLI-komentoihin.

Sanot mallille: "Tässä on työkalu nimeltä list_files. Tässä on työkalu nimeltä read_file. Tässä on työkalu nimeltä send_email."

2. Konteksti (Suunnan antaminen mallille)

Sitten määrittelet roolin. "Olet senioritason QA-insinööri. Tavoitteenasi on korjata tyyppivirheet tässä repositoriossa."

Siinä se. Se on ydinlooppi.

Jos olet käyttänyt Cursoria tai Claude Codea, olet nähnyt tämän toiminnassa. Et mikromanageroi muokkauksia. Sanot vain: "Korjaa tyyppivirheet tiedostossa utils.ts."

Agentti ajattelee: Okei, minun täytyy nähdä tiedosto ensin. Se päättää käyttää ls-työkalua. Sitten se päättää käyttää grep- tai read-komentoa. Se huomaa virheen. Se päättää kirjoittaa korjauksen. Se ajaa kääntäjän tarkistaakseen työnsä.

Tämä on se läpimurto. Se ei ole enää vain "chattailua". Se on päätöksentekoketju. Malli valitsee, mihin työkaluihin se tarttuu ratkaistakseen sille antamasi ongelman.

Chatboteista päätöksentekomoottoreihin

Viimeiset kaksi vuotta olemme olleet jumissa "Chat"-vaiheessa. Kohtelemme tekoälyä kuin fiksua kirjastonhoitajaa – kysymme kysymyksen, se antaa vastauksen.

Tämä vaihe on päättymässä.

Agenttien aikakausi (The Agentic phase) on toteutuksen aikaa. Kyse on siitä, että CLI:tä ei nähdä paikkana, johon sinä kirjoitat, vaan leikkikenttänä mallille.

Mieti, mitä tämä tarkoittaa startupeille. Aiemmin, jos halusin rakentaa palvelun asiakaspalautusten käsittelyyn, minun piti rakentaa käyttöliittymä (UI), backend, tietokanta ja palkata tukitiimi klikkailemaan nappeja.

Tänään voin kirjoittaa agentin. Annan sille pääsyn Stripen API:in (Työkalu) ja sähköpostihistoriaamme (Konteksti). Annan sille säännön: "Palauta rahat, jos käyttäjä on tyytymätön 7 päivän sisällä." Agentti lukee saapuvan sähköpostin, päättää täyttyvätkö kriteerit, laukaisee Stripe-palautustyökalun ja luonnostelee vastauksen.

Ei käyttöliittymää. Ei tukipyyntöjonoa. Vain tavoite ja setti työkaluja.

Agenttien rakentamisen "sotkuinen keskivaihe"

En halua maalata tästä utopiaa. Olen viettänyt viimeiset kuusi kuukautta syvällä agenttien rakentamisen poteroissa, ja kerron teille: se on sotkuista.

Perinteinen koodaus on loogista. Jos X niin Y. Se toimii tai se hajoaa.

Agentti-insinöörityö on todennäköisyyksiin perustuvaa (probabilistic). Rakennat agentin, annat sille työkalut, ja joskus se päättää käyttää vasaraa ikkunan avaamiseen. Joskus se hallusinoi parametrin, jota ei ole olemassa.

Tässä piilee uusi osaamisvaatimus.

AI Agent Engineerinä oleminen ei ole vain Python-skriptejä. Se on:

• Prompt Engineering arkkitehtuurina: Järjestelmäpromptien suunnittelua mallin käytöksen rajaamiseksi.
• Eval Driven Development: Et voi kirjoittaa yksikkötestejä luovuudelle, joten rakennat evaluointiputkia mitataksesi, kuinka usein agentti onnistuu tehtävässään.
• Työkalujen suunnittelu: Sellaisten API-rajapintojen luomista, jotka ovat tarpeeksi "puhtaita" mallin ymmärrettäväksi ilman sekaannuksia.

Olen nähnyt agenttien jäävän ikuisiin looppeihin yrittäessään korjata itse luomaansa bugia. Olen nähnyt niiden itsevarmasti poistavan väärän tiedoston. Tämä on todellisuutta. Mutta näiden kitkapisteiden ratkaiseminen on juuri se paikka, jossa arvo luodaan.

Käytännön vinkit: Miten aloittaa tänään

Jos aloittaisin nyt tyhjästä tai etsisin suuntaa uralleni, tekisin juuri näin:

1. Lopeta graafisten käyttöliittymien (GUI) rakentaminen: Ainakin sivuprojekteissasi. Yritä ratkaista ongelma ilman frontendiä. Pystytkö ratkaisemaan sen CLI:llä ja LLM:llä?
2. Opettele rajapintaprotokollat: Ymmärrä, miten OpenAI:n "function calling" tai Anthropicin "tool use" toimii. Tämä on agenttiaikakauden TCP/IP.
3. Rakenna "tekijä", älä "puhujaa": Älä rakenna bottia, joka vastaa kysymyksiin kalenteristasi. Rakenna botti, joka hallinnoi kalenteriasi. Anna sille kyky poistaa tapahtumia. Tunne se pelko, kun annat tekoälylle kirjoitusoikeudet. Silloin alat oikeasti oppia.
4. Hallitse kontekstia: Opettele, miten syöttää oikea tieto konteksti-ikkunaan ilman, että se tulvii yli. RAG (Retrieval-Augmented Generation) on vasta alkua.

Tulevaisuuden mahdollisuus

Katselemme tulevaisuutta, jossa yksi kehittäjä, varustettuna erikoistuneiden agenttien laivueella, voi tehdä 20 hengen startupin työt.

Kynnys luomiseen on putoamassa nollaan. Mutta kynnys orkestrointiin – ymmärrykseen siitä, miten nämä aivot kytketään yhteen – on muodostumassa uudeksi vallihaudaksi.

Kymmenen vuotta sitten sinut palkattiin kirjoittamaan koodia. Tänään sinut palkataan arkkitehdiksi järjestelmälle, joka kirjoittaa koodin.

Juna on lähdössä asemalta. Voit joko seisoa laiturilla puristaen vanhoja frameworkejasi, tai voit hypätä kyytiin ja auttaa raiteiden rakentamisessa.

Aletaan rakentaa.