Tarkvaraarenduse tööstus on muutumas — püsivalt.

2003. aastal asutasin DCSL Software, mis hiljem sai One Beyond’ks. 2023. aastal lahkusin ettevõttest pärast seda, kui olin selle rahvusvaheliseks kasvatanud ja töötajate arvu suurendanud üle 300 inimeseni. Sellest ajast alates olen asutanud robotikavaldkonna idufirma ning kaasanud seemnefaasi rahastust enam kui 4 miljoni naela ulatuses.

Ma ei osanud kunagi arvata, et hakkan taas tootmisprogrammide kirjutamist harrastama. Ma lõpetasin igapäevase programmeerimise 2014. aastal – mitte seetõttu, et ma poleks seda suutnud teha, vaid hoopis sellepärast, et selline on ettevõtte skaleerumisel loomulik käitumismuster. Palkad võid inimesi, kes on sinust paremad teostuses, keskendud juhtimisele ja järk-järgult kaob klaviatuur üha kaugemale. Peaaegu kümme aastat tundus see täiesti loomulik.

Mida ma aga ei osanud oodata, oli see, et ligi kümme aastat hiljem leian end taas arendaja toolilt – mitte nostalgiliselt, vaid praktiliselt. Mitte lihtsalt katsetades, vaid ehitades tõeliselt keerulist robotikaplatvormi. Ja mitte uuesti õppides igat raamistikku või keelt, millest ma mööda olin läinud, vaid töötades põhimõtteliselt teistsugusel viisil.

Seda isiklikku muutust pean selgeimaks signaaliks, mida olen näinud, et tarkvaraarenduses on midagi struktuurset muutunud.

Kuidas me kunagi tarkvara disainisime — ja miks  

Kui ma alustasin, olime kindlalt veekulu-ajastus. See polnud ideoloogia, vaid majanduslik vajadus. Tarkvara ehitamine oli aeglane ja kulukas, nii et ainuke mõistlik lähenemisviis oli eelnevalt väga põhjalikult läbi mõelda.

Me kirjutasime üksikasjalikke spetsifikatsioone, sest me pidime seda tegema. Lepingu tingimused sõltusid nendest. Tähtaeg sõltus nendest. Hea spetsifikatsiooni koostamine oli spetsialistide oskus, milles mul juhtus olema üsna hea. Suutsin visualiseerida, milline võib valmis toode välja näha enne, kui see veel olemas oli, aimata keerukuse piirkondi ja kirjeldada käitumist piisava täpsusega, et meeskond saaks selle järgi ehitada.

Seda oskust oli raske leida ja raske õpetada. Paljud inimesed said sellega raskustes, sest keeruka süsteemi ette kujutamine, mida veel ei eksisteeri, on tõesti raske. Kuid see oli oluline, sest protsessi lõpus asjade valesti tegemine oli valus ja kulukas.

Aja jooksul liikus tööstus Agile’i suunas. Avalikult esitati seda kui paremat viisi muutustega reageerimiseks. Vaikselt tunnistati samas, et suurte ja pikalt töötavate süsteemide puhul ei säili ükski spetsifikatsioon tervena. Ärid muutuvad, kasutajad muutuvad, tehnoloogia muutub, ja vastupidist teeseldes tehti sageli rohkem kahju kui kasu.

Agile oli pragmaatiline, kuid sellel oli oma hind. Me loobusime suuresti põhjalikust eelnevalt planeerimisest ja asendasime selle järkjärgulise avastamisega. See töötas, kuid normaliseeris ka mõtteviisi, kus liiga kaugele ette mõtlemist peeti ebavajalikuks või isegi riskantseks.

Mis muutus — ja miks ma taas ehitama hakkasin  

Selle põhjus, miks olen suutnud tagasi astuda praktilisse arendusse, ei ole see, et mul oleks äkki tekkinud aega või soovi uuesti õppida kümnendi jagu tööriistu. Põhjus on hoopis selles, et AI on fundamentaalselt muutnud katsetamise maksumust.

Seda osa mõistetakse tihtipeale valesti. Tegelik muutus ei seisne selles, et koodi kirjutamine on kiirem. Pigem on asi selles, et asjade proovimine on nüüd odav, kiire ja suures osas pööratav.

Asjad, mis varem oleksid võtnud arendajate nädalaid, saab nüüd proovida minutitega. Saad uurida ühte lähenemist, vaadata, kuidas see tundub, visata see üldse ära ja proovida teistsugust suunda väga väikese hinnaga. Varem polnud see lihtsalt võimalik.

Varem oli koodiga tugev emotsionaalne ja finantsiline sidumine. Kui miski võttis kahe arendaja kolm nädalat ehitamiseks, siis oli loomulik, et sa ei tahtnud seda lihtsalt ära visata. Otsused kujunesid karmiks varakult, mitte alati seetõttu, et need oleksid õiged, vaid sellepärast, et nende tagasipööramine oli liiga kulukas.

Seda piirangut ei ole enam ja just see tõmbas mind tagasi. Nüüd saan tegutseda tasemel, kus olen kõige tugevam – probleemi mõistmine, süsteemi kujundamine, silmapiiril keerukuse ilmnemise märkamine – samal ajal kui AI hoolitseb mehaanika eest. Ma ei kirjuta koodi samal viisil nagu paarikümneselt. Ma juhin seda, lihvin seda, parandan seda ja aeg-ajalt peatan seda, et see ei läheks üldse vale suunas. Praktikas tundub see palju lähedasemaks meeskonna juhtimisele kui koodi kirjutamisele. Sa oled sisuliselt boss – määrates suuna, kontrollides tulemust, märkides laisku lühikest teed ja surudes tagasi, kui miski ei tundu õige.

Miks disain ikka veel loeb — rohkem kui kunagi varem   

Oleks lihtne arvata, et see uus vabadus muudab disaini vähem oluliseks. Tegelikult muudab see selle hoopis olulisemaks.

Selge ja üksikasjaliku idee sellest, mida sa üritad ehitada, on endiselt äärmiselt väärtuslik. Tegelikult parandab see aktiivselt AI-tulemusi. Mida selgem on kavatsus, seda paremad on tulemused. Ebamäärane mõtlemine toodab lihtsalt ebamäärasemaid süsteeme kiiremini. Oluline on mõista, et AI käitub väga sarnaselt inimesele. Ta tahab olla abivalmis. Ta tahab sulle vastata. Kui oled ebamäärane, täidab ta lünki. Kui oled hooletu, teeb ta eeldusi. Kui sa teda ei vaidlusta, jätkab ta kindlalt valel teel.

Erinevus on selles, et disain ei ole enam habras, ühekordne artefakt, mis peab aastaid muutumatuna vastu pidama. See on muutunud katsetamise juhendiks, mitte selle piiranguks. Sa võid hoida tugevat visiooni sellest, kuhu suundud, samal ajal kui oled valmis proovima, viskama ära ja arendama teed, mis sind sinna viib.

Uus oskus on teada, millal on uurimine produktiivne ja millal on see lihtsalt müra. AI genereerib rõõmsalt struktuuri veel pikalt pärast seda, kui see oleks juba ammu lihtsustatud. Ta ei tea, millal fail on muutunud liiga suureks, millal abstraktsioon hakkab lekkima või millal miski, mis „toimib“ täna, võib hiljem valu põhjustada. Need instinktid tulenevad endiselt kogemusest.

Mis see tööstuses murdab  

Kui katsetamine muutub odavaks, lakkavad paljud pikalt kehtinud eeldused kehtima. Planeerimine ei ole enam selle kohta, et kõik eelnevalt lukustada. See on kavatsuste, piirangute ja piiride seadmine.

Hinnangute tegemine muutub vähem pingutuste ennustamisest ja rohkem sellest, et mõista ruumi, mida uurid.

Ja meie suhe koodiga muutub täielikult. Konkreetsesse rakendusse on palju vähem sidumist ja palju rohkem fookust käitumisel, struktuuril ja tulemustel.

Sellepärast tundub tarkvaraarenduse tööstus rahutu. Paljud inimesed üritavad vanu mõttemudeleid uute tööriistade peale kohaldada. See toimib mõnda aega, kuid see jääb asjast mööda.

Tegelik muutus  

Selle põhjus, miks olen veendunud, et see muutus on püsiv, on lihtne: muidu ma ei hakkaks taas ehitama.

Ainus põhjus, miks ma võin usutavalt tagasi pöörduda praktilisse arendusse pärast kümnendit eemalolekut, on see, et kontrastid, mis mind esmakordselt välja tõmbasid, ei kehti enam. Tarkvara võib nüüd areneda juhitud katsetamise kaudu viisil, mida varem lihtsalt ei olnud võimalik.

See ei tähenda, et kogemus ei loe enam. See tähendab, et see loeb teistmoodi. Väärtus ei ole enam süntaksi või raamistikke meeles pidamises. See on hinnangus, struktuuris ja teadmises, millal peatuda.

Tegemist ei ole tarkvaraarenduse lõpuga. Kuid see on vana mudeli lõpp. Ja kui oled korra selliselt töötanud, ei ole tagasipöördumist.