Viisi kuukautta tekoälyn kumppanina: mitä opin monimutkaisten järjestelmien rakentamisesta
Kun "kallis virhe" muuttui "pelinvaihtajaksi": Yllättävä matkamme tekoälyn kanssa
Ollaan rehellisiä: useimmilla kehittäjillä on ristiriitainen suhde tekoälypohjaisiin koodausapureihin. Olemme nähneet esittelyt, lukeneet onnistumistarinoita ja ehkä kokeilleetkin – vain huomataksemme, että generoitu koodi näytti oikealta mutta hajosi käytännössä.
Meillä on kokemusta tästä. Vuosia sitten hyppäsimme varhaisen tekoälytyökalujen kelkkaan ja tuloksena oli kuukausien korjausurakka. Koodi vaikutti siistiltä, testit menivät läpi, mutta se ei yksinkertaisesti vastannut tarpeitamme. Opimme kantapään kautta, miksi tekoälyn tulosteisiin sokeasti luottaminen on resepti katastrofille.
Kun palasimme tekoälytyökalujen pariin tänä vuonna, lähestyimme asiaa varovaisesti. Se, mitä löysimme, yllätti meidät: työkalut olivat kypsyneet merkittävästi, mutta tärkeämpää on, että tapa käyttää niitä on yhtä merkityksellinen kuin valinta.
Todellinen läpimurto: Aloita pienesti, ajattele isosti
Käännekohta tuli odottamattomasta suunnasta. Tiimimme ei-insinööri – markkinointipäällikkö – rakensi toimivan tietokantaklientin parissa tunnissa tekoälyavustajan avulla. Se toimi. Ei täydellisesti, mutta tarpeeksi hyvin.
Se kiinnitti huomiomme. Jos tekoäly voi auttaa kehitystiimin ulkopuolista henkilöä toimittamaan toimivaa koodia nopeasti, mitä se voisi tehdä varsinaiselle ominaisuuskehitykselle?
Aloimme kokeilla olemassa olevien järjestelmien laajentamista. REST-ohjelmointirajapintamme tarvitsi uusia ominaisuuksia erätoimintoja varten. Alkuperäinen toteutus vaati huomattavaa suunnittelutyötä. Tekoälyavusteinen laajennus? Kaksi päivää.
Tämä oli avainhavainto: tekoäly loistaa olemassa olevien koodikantojen laajentamisessa. Se ymmärtää kontekstin, nimeämiskäytännöt ja arkkitehtuurimallit, kun ne on jo määritelty. Sen sijaan se kamppailee monimutkaisten järjestelmien luomisessa tyhjästä ilman pohjaa.
Suuri vedonlyönti: Kymmenen vuotta vanhan haasteen kimppuun
Rohkaisevina näistä voitoista päätimme testata rajoja. Oli ominaisuus, jota käyttäjämme olivat toivoneet vuosia – kapasiteetti, jonka olimme siirtäneet prioriteeteissa alemmas, koska monimutkaisuus vaikutti mahdottomalta perinteisillä kehitysmenetelmillä.
Puhumme kehittyneiden kyselyominaisuuksien lisäämisestä hajautettuun avain-arvo-säilöön. Ajattele sitä monimutkaisen SQL-tuen tuomisena järjestelmään, joka on perinteisesti optimoitu yksinkertaisille, salamannopeille operaatioille. Perinteisin menetelmin arviot sijoittivat tämän vähintään kahden vuoden projektiksi.
Kysymys oli yksinkertainen: voiko tekoälyavusteinen kehitys muuttaa tätä yhtälöä perustavanlaatuisesti?
Viisi kuukautta myöhemmin meillä oli vastauksemme. Toimitimme beeta-tuen ominaisuuksille, jotka olivat odottaneet TODO-listallamme yli vuosikymmenen.
Kehitysmalli, joka todella toimii
Tässä on opit: tekoäly ei korvaa hyvää insinööriä – se vahvistaa sitä. Koko kehitysprosessimme ajan ylläpidimme kurinalaista lähestymistapaa, joka on aina toiminut monimutkaisten järjestelmien kanssa:
Aloita korkean tason suunnitelmalla. Tiedä mihin olet menossa, ennen kuin alat kirjoittaa koodia – vaikka tekoäly kirjoittaisi sitä.
Pilko se vaiheisiin. Toteutuksemme kulki useiden suunnittelukierrosten läpi, joista jokaisessa oli 10–20+ erillistä vaihetta. Tekoäly voi auttaa näiden vaiheiden toteuttamisessa nopeammin, mutta vain jos olet tehnyt ajatustyön etukäteen.
Testaa armottomasti. Tässä tekoälyavustus muuttuu aidosti mullistavaksi. Kattavien testikokoelmien generointi – mukaan lukien hajautettujen järjestelmien testit, jotka normaalisti vaativat valtavasti työtä – on mahdollista. Pystyimme testaamaan yksittäisiä järjestelmäkerroksia erikseen ennen integraatiota, mikä nopeutti merkittävästi polkua toimivaan toteutukseen.
Eri tekoälymallien täydentävät vahvuudet
Kaikki tekoälyavustajat eivät ole samanarvoisia, ja opimme hyödyntämään niiden erilaisia vahvuuksia:
Malli A (käytimme Claudea) loisti ylläpitämään kontekstia pitkien kehityssessioiden aikana. Se piti kirjaa siitä, missä olimme kokonaissuunnitelmassa, mitä oli jäljellä ja miten uusi koodi sopi laajempaan arkkitehtuuriin. Tämä malli toimi projektipäällikkönämme ja suunnistajanamme.
Malli B (käytimme Codexia) osoittautui paremmaksi monimutkaisten, keskitettyjen ongelmien ratkaisemisessa. Kun törmäsimme erityisen hankalaan bugiin tai piti toteuttaa mutkikas algoritmi, tämä malli löysi usein elegantteja ratkaisuja nopeammin kuin me.
Opetus? Älä sitoudu yhteen työkaluun. Rakenna työnkulku, joka hyödyntää kunkin mallin vahvuuksia.
Asynkroninen haaste: Missä tekoäly tarvitsee vielä ohjausta
Yksityiskohta, joka yllätti meidät: tekoälypohjaiset koodaustyökalut toimivat hämmästyttävän hyvin peräkkäisen, synkronisen koodin kanssa – sellaisten mallien kanssa, joita ne ovat nähneet eniten koulutusdatassa.
Kun heität asynkronisia operaatioita sekoittumaan, homma muuttuu mielenkiintoiseksi. Mallit joskus menettävät kontekstin, joka olisi ilmeinen kokeneelle kehittäjälle. Mutta tässä tulee oleellinen osa: kurssin korjaaminen kohdennettujen kehoteiden ja selitysten avulla on yleensä suoraviivaista.
Käänteinen pitää myös paikkansa. Nopeus, jolla tekoäly generoi toimivaa koodia – erityisesti standardiratkaisuja ja hyvin ymmärrettyjä malleja – ylittää täysin sen, minkä ihminen saavuttaisi manuaalisesti. Se on kuin väsymätön pariohjelmointikumppani, joka ei koskaan kyllästy kirjoittamaan yksikkötestejä.
Mitä tämä tarkoittaa seuraavalle projektillesi
Jos harkitset tekoälyavusteista kehitystä, tässä rehellinen arviomme:
Se toimii poikkeuksellisen hyvin kun:
- Sinulla on olemassa oleva koodikanta vakiintuneilla malleilla
- Laajennat tai lisäät olemassa olevaa toiminnallisuutta
- Pystyt generoimaan kattavia testikokoelmia (jotain, mitä aina halusimme tehdä mutta eivät koskaan resurssit riittäneet)
- Ylläpidät ihmisvalvontaa etkä pelkää iteroida kehotteita
Se on riskialttiimpaa kun:
- Rakennat monimutkaisia järjestelmiä tyhjästä ilman referenssiarkkitehtuuria
- Toimialue vaatii syvällistä kontekstuaalista ymmärrystä, jota tekoälylle ei ole altistettu
- Odotat tekoälyn ymmärtävän implisiittisiä vaatimuksia ilman eksplisiittistä määrittelyä
Teknologia on kypsynyt pisteeseen, jossa vakava insinöörimäinen työ tekoälyavustuksella on aidosti mahdollista. Mutta se on silti työkalu, joka vaatii taitavia käsiä toimiakseen tehokkaasti.
Vibe codingin etu
Termi "vibe coding" on saamassa jalansijaa kehittäjäpiireissä. Se tavoittaa jotain todellista siitä, miten tekoäly muuttaa kehityskokemusta. Kun tekoäly hoitaa standardiratkaisut ja generoi alustavat toteutukset, insinöörit voivat keskittyä enemmän luoviin, arkkitehtuurisiin päätöksiin, jotka todella merkitsevät.
Viiden kuukauden matkamme osoitti, ettei tämä ole pelkkää hypeä. Toimitimme ominaisuuksia, jotka olisivat vieneet vuosia perinteisillä lähestymistavoilla. Tärkeämpää on, että ylläpidimme laatua koko prosessin ajan – koska tekoälyavusteisesti rakentamamme testausinfrastruktuuri havaitsi ongelmat ajoissa.
Monimutkaisten järjestelmien kehityksen tulevaisuus ei ole insinöörien korvaamista tekoälyllä. Se on insinöörien supervoimien antamista – ja oppimista, milloin luottaa työkaluihin ja milloin soveltaa ihmisen harkintakykyä.
Sellainen fiilis on jotain, jonka puolesta voi helposti olla.