Yhden rakentajan pino: suunnittele, koodaa ja julkaise yksin

Ennen vanha veruke oman tuotteen rakentamatta jättämiselle oli, että tarvitset tiimin. Suunnittelijan, frontend-tekijän, backend-tekijän, jonkun joka ymmärtää tietokantoja, jonkun joka osaa deployata. Vähintään viisi ihmistä ennen kuin kukaan kirjoittaa riviäkään, jonka asiakas koskaan näkee. Se laskutoimitus on muuttunut, eikä suurin osa ole tajunnut, kuinka paljon.

Pyöritän Impact Nodea yksin. Suunnittelin Vantnodin, tekoäly edellä rakennetun kirjanpitotuotteen EU:n pk-yrityksille, ja koodasin ja julkaisin sen itse. Sama juttu Nordbriefin kanssa, joka on avustushakemusten kirjoitusalusta pohjoismaisille järjestöille. Ei kanssaperustajaa, ei alihankkijoita, ei mainostoimistoa. Ei siksi, että olisin joku kymmenen kertaa muita tehokkaampi insinööri. En ole. Vaan siksi, että yhden hengen rakentajan sitova rajoite siirtyi, ja kun näet minne se siirtyi, alat rakentaa toisin.

Pullonkaula ei ole taito vaan maku ja vipuvarsi

Vaisto on ajatella, että yhden hengen rakentajan ongelma on laajuus. Ethän voi olla yhtä aikaa hyvä suunnittelussa, frontendissä, backendissä, infrassa, copyssa ja hinnoittelussa. Ja olet oikeassa, et voi. Mutta "ole hyvä kaikessa" ei ollut koskaan se varsinainen vaatimus. Se oli korvike, jota käytimme aikana, jolloin ainoa tapa saada asia tehdyksi oli, että spesialisti teki sen käsin.

Tältä nykyinen yhtälö näyttää:

Tuotos = maku × vipuvarsi. Taito jokaisessa kerroksessa ei ole enää se portti. Portti on se, että tietää, miltä hyvä näyttää, ja että on työkalut, jotka kurovat umpeen tietämisen ja julkaisemisen välin.

Maku on se osa, jota et voi ulkoistaa mallille. Se on harkintaa siitä, että tämä väli on väärin, tässä polussa on yksi ruutu liikaa, tämä virheilmoitus säikäyttää kirjanpitäjän, tämä onboarding kysyy kolmea asiaa, vaikka sen pitäisi kysyä yhtä. Tunnet sen ennen kuin osaat pukea sen sanoiksi. Vipuvarsi on kaikki se, minkä avulla voit toimia sen harkinnan mukaan nopeasti: tiukka pino, jonka osaat ulkoa, tekoäly joka tuottaa pätevän ensiluonnoksen melkein mistä tahansa, ja scope-kuri joka pitää sinut pinnalla.

Jos sinulla on makua mutta ei vipuvartta, julkaiset hitaasti ja palat loppuun. Jos sinulla on vipuvarsi mutta ei makua, julkaiset nopeasti ja julkaiset roskaa. Tarvitset molemmat, ja hyvä uutinen on, että vipuvarsi on nykyään halpaa. Maku on se niukka panos. Suojaa sitä siis ja kaada se halpa panos sen ympärille.

Pino: tarkoituksella tylsä, tarkoituksella tuttu

Yhden hengen pinon odotetaan olevan eksoottinen. Se on päinvastoin. Koko pointti on poistaa jokainen päätös, joka ei ole itse tuote.

Sääntöni: valitse tylsät, hyvin dokumentoidut oletukset äläkä ota niitä enää uudelleen käsittelyyn. Käytän yhtä frontend-frameworkia, yhtä tyylittelytapaa, yhtä tietokantaa, yhtä hostia. Infran kohdalla minulla ei ole "annahan kun arvioin kolme vaihtoehtoa" -vaihetta, koska se vaihe on pelkkää kustannusta ilman mitään asiakkaalle näkyvää hyötyä. Tyypitetty kieli päästä päähän, jotta kääntäjä nappaa virheeni samalla kun liikun nopeasti enkä keskity täysillä. Hallinnoitu tietokanta, jotta minua ei herätetä kahdelta yöllä siksi, että levytila loppuu. Hosti, joka deployaa git pushilla, jotta julkaisu on yksi liike eikä rituaali.

Tylsyydellä on syvempikin syy, ja se on toisenlaista vipuvartta: tekoälymallit ovat valtavasti parempia suositussa ja paljon kuljetussa pinossa kuin sinun nokkelassa räätälöidyssä. Kun pyydän mallia luonnostelemaan komponentin tai selvittämään tyyppivirheen, se ammentaa miljoonista esimerkeistä juuri sitä frameworkia. Valitse hämärä työkalu, niin olet huomaamattasi sammuttanut suurimman voimanvahvistimesi. Tylsä ei ole kompromissi. Se on juuri se, mikä tekee tekoälystä oikeasti hyödyllisen.

Ainoa paikka, jossa en tyydy tylsään, on se osa, joka on itse tuote. Vantnodissa se on täsmäytys ja se LLM-putki, joka lukee sotkuista pankkidataa. Sinne menevät tuntini ja makuni. Kaikki muu sen ympärillä on bulkkia, ja kohtelen sitä bulkkina.

Tekoäly voimanvahvistimena, ei autopilottina

Virhe, jonka näen yksin rakentavien tekevän tekoälyn kanssa, on sama jonka avustushakemusten kirjoittajat tekevät: he antavat sille koko homman ja hyväksyvät mitä takaisin tuleekin. Saat jotain, joka pyörii ja on hienovaraisesti, kalliisti väärin. Malli on sujuva ja vakuuttunut, mikä on juuri se ansa. Se kirjoittaa tietokantakyselyn, joka toimii kymmenellä rivillä ja kaatuu kymmenellätuhannella. Se keksii API-metodin, joka kuulostaa uskottavalta eikä ole olemassa.

Tapa, jolla oikeasti työskentelen sen kanssa päivästä toiseen, näyttää enemmän tältä:

1. Minä omistan arkkitehtuurin. Rajapinnat, datamallin, vaikeat kompromissit. Malli ei saa ääntä siihen, asuuko jurisdiktio ydinalueessa vai adapterissa. Se päätös on minun, koska sillä on seurauksia vuosiksi.
2. Malli omistaa rakennustelineet. Boilerplate-komponentit, sen kolmannen CRUD-lomakkeen, joka näyttää kahdelta edelliseltä, testifikstuurit, migraatiotiedostot, sen regexin jonka väsäämisessä menisi muuten kaksikymmentä minuuttia pieleen. Se on aidosti loistava tylsässä keskivaiheessa.
3. Luen jokaisen rivin, joka koskee rahaa, autentikointia tai datan eheyttä. Kirjanpitotuotteessa niitä rivejä on paljon, eikä oikoteitä ole. Tekoälyn tuottama koodi läpäisee silmämääräisen tarkastuksen ja hoitaa sitten hiljaa väärin jonkin valuutan pyöristyksen reunatapauksen. Sen nappaat vain lukemalla koodin niin kuin olisit itse kirjoittanut sen.

Lause, johon palaan yhä uudestaan: tekoäly vahvistaa sen, minkä sille annat. Anna sille selkeä arkkitehtuuri ja terävä aikomus, niin se tekee sinusta aidosti nopeamman. Anna sille epämääräinen prompti ja olankohautus, niin se tekee sinusta nopean tuottamaan asioita, jotka kirjoitat uusiksi ensi viikolla. Harkinta pysyy ihmisellä. Näppäilemisestä tulee halpaa.

Armoton scope on se oikea supervoima

Jos minun pitäisi nimetä yksi taito, joka erottaa julkaisevat yksin rakentavat ikuisesti näpertelevistä, se ei ole koodausnopeus. Se on valmius leikata pois.

Tiimillä on varaa rakentaa se kiva lisä. Yksin operoivalla ei ole, ja muun teeskenteleminen on tapa, jolla tuotteet kuolevat laatikkoon. Joten ajan jokaisen ominaisuuden yhden suodattimen läpi, ennen kuin se saa yhtäkään tuntia: epäonnistuuko tuote ilman tätä ensimmäisen maksavan asiakkaan kohdalla? Jos rehellinen vastaus on ei, sitä ei rakenneta nyt. Ei "myöhemmin backlogiin" kohteliaana ein muotona. Sitä ei aktiivisesti rakenneta, ja teen sovinnon sen kanssa.

Konkreettinen esimerkki. Kun aloitin Nordbriefin, ilmeinen visio oli täysi avustustenhallintapaketti: deadlinejen seuranta, monikäyttäjäroolit, raportointinäkymä, integraatiot rahoittajien portaaleihin. Jokainen niistä on oikea asia, jonka järjestöt haluavat. En rakentanut yhtäkään niistä aluksi. Ensimmäinen julkaisukelpoinen versio teki täsmälleen yhden asian hyvin: otti projektin strategisen narratiivin ja hakemuslomakkeen, ja tuotti vahvan ensiluonnoksen, jonka ihminen sitten teroittaa. Se on se asia, joka saa jonkun tiistai-iltapäivän katoamaan hyvällä tavalla. Kaikki muu oli ominaisuus, josta olisin ollut ylpeä ja josta kukaan ei olisi vielä maksanut.

Tämä on sama vaisto kuin nuorisotyön ohjelmia koordinoidessani. Voit suunnitella kaksikymmentä tapahtumaa vuodelle, tai voit pitää ne kahdeksan, jotka oikeasti liikuttavat jotain, ja pitää ne hyvin. Rajoite pakottaa rehellisyyteen siitä, mikä on tärkeää. Yksin rakentaminen tekee saman, vain koodilla.

Epäonnistumisen tavat, nimettyinä

Kolme tapaa, joilla tämä menee pieleen, ja olen osunut niihin kaikkiin.

Bulkin kiillottaminen. Viikonlopun kuluttaminen kauniiseen asetussivuun, jota kukaan ei pyytänyt, samalla kun ydinominaisuudessa on bugi. Korjaus on yllä oleva scope-suodatin, sovellettuna itseen ilman armoa.

Mallin uskominen kantavassa viidessä prosentissa. Autentikointivirta, maksujen käsittely, datamigraatio. Tässä vakuuttavalta kuulostava tekoälytuotos on vaarallisinta, koska väärässä olemisen hinta on korkein juuri siellä, missä todennäköisimmin jätät testaamatta kunnolla. Lue se kahdesti. Kirjoita testi itse.

Pinon valuminen. Hidas houkutus vaihtaa tilalle se kiiltävä uusi framework, se nokkela kirjasto, se toinen tietokanta "vain tätä yhtä asiaa varten". Jokainen lisäys on vero jokaiselle tulevalle tunnille, koska nyt ylläpidät kahta asiaa ja tekoäly osaa niistä toisen hyvin. Kohtelen pinoani sopimuksena tulevan itseni kanssa: muutokset vaativat syyn, joka selviää yön yli nukutusta.

Mitä tämä oikeasti tarkoittaa

Romanttinen versio yksin rakentamisesta on yksinäinen nero. Oikea versio on paljon vähemmän sankarillinen ja paljon hyödyllisempi: operaattori, jolla on kelpo maku, tylsä pino jonka osaa ulkoa, malli joka tekee tylsän 80 prosenttia, ja kuri kieltäytyä siitä 80 prosentista ominaisuuksia, joilla ei ole väliä.

Sinun ei tarvitse olla paras suunnittelija, paras insinööri tai paras infrassa. Sinun pitää tietää, miltä hyvä näyttää kussakin, pitää linja scopessa, ja antaa vipuvarren kuroa kuilu umpeen. Tuota yhdistelmää ei ollut yhdelle ihmiselle viisi vuotta sitten. Nyt on, ja ainoa asia, joka seisoo useimpien ihmisten ja heidän oman tuotteensa julkaisun välissä, on se, että he yhä odottavat lupaa, tai tiimiä. Et tarvitse kumpaakaan. Tarvitset makua, lyhyen työkalulistan ja rohkeuden leikata.