Spec-aukot eivät ole uusi juttu – AI vain paljasti ne

Ohjelmistokehityksessä on vanha salaisuus, joka on pysynyt piilossa: pullonkaula ei ole koodin kirjoittaminen. Se on se, mitä koodia ylipäätään kannattaa kirjoittaa.

Jo Fred Brooks tiesi tämän vuonna 1986 kirjassaan No Silver Bullet. Hän huomasi, että isot innovaatiot – kuten olio-ohjelmointi tai strukturoitu koodi – toivat vain pientä helpotusta. Ne korjasivat accidental complexityä eli koodin sotkua, mutta eivät essential complexityä eli ajattelun vaikeutta. Todellinen haaste on aina ollut speksaus: sidosryhmien yhtenäistäminen, kompromissien sopiminen ja vaatimusten määrittely järjestelmälle, jota ei vielä ole.

Nyt kun AI hoitaa koodin generoinnin, moni luulee speksausongelman katoavan. Ei katoa.

"Yksityiskohtaiset speksit" eivät ole sama asia kuin "luonnolliskieliset speksit"

Monet uudet työkalut – AI-PRDeistä speksien tarkistajiin – lupaavat: jos AI kysyy oikeat kysymykset, aukot täyttyvät automaattisesti.

Tämä olettaa, että tavallinen kieli riittää tarkkuuteen, jota formaalit systeemit vaativat. Väärinpäin.

Formaali notaatio syntyi juuri siksi, että luonnollinen kieli on täynnä tulkinnanvaraa. Voit kirjoittaa kauniin tuotespeksin, joka kuulostaa hyvältä ja saa kaikki nyökyttelemään. Silti siinä puuttuu se tiukka tarkkuus, jota AI-agentti tarvitsee luotettavaan koodiin. "Käyttäjä näkee dashin alle kahdessa sekunnissa" eroaa "P95-latenssi analytiikka-dashissa alle 2000 ms, 99. persentiili max 5000 ms" – tämä ei ole tyylivalinta. Se on speksaus.

Epämääräinen speksi AI-agentille tuottaa joko:

1. Hämärää koodia. Toimii teknisesti, mutta arkkitehtuuri on pielessä. Korjaat sprinttejä myöten.

2. Oletuksia treenidatasta. Agentti ottaa mallia tuhansista samantyyppisistä projekteista ja toteuttaa sun tietämättäsi omiaan.

Kumpikaan ei ole voitto.

Missä agentic-koodaus loistaa – ja missä ei

Ole rehellinen: agentit ovat loistavia suppeissa jutuissa. Landing-sivut, CRUD-sovellukset, perusintegraatiot, tavallinen verkkokauppa – näissä onnistutaan, koska ne ovat tuttuja malleja. Treenidatassa on loputtomasti esimerkkejä. Agentti ei keksi pyörää uudelleen; se matittaa patternseja.

Tämä on aitoa tuottavuutta. Yksin yrittäjä voi moninkertaistaa tehonsa. Pieni tiimi väsää työkalut tunneissa viikkojen sijaan.

Mutta menestys perustuu selkeään speksaukseen, ei sen puutteeseen. Ongelma-alue on niin tuttu, että speksi voi olla melkein implisiittinen.

Kaikessa muussa – custom-liiketoimintalogiikassa, uusissa integraatioissa, tulevaisuutta avaavissa arkkitehtuurivalinnoissa – joudut ajattelemaan ihmisille. AI nopeuttaa kirjoittamista, ei ajattelua. Se ei voi sanoa "tää on huono idea, tee X ensin". Se vain toteuttaa käskysi.

Kuten eräs kehittäjä totesi: "AI kirjoittaa koodia, mutta ei kieltäydy kirjoittamasta, ellei sille kerrota miksi X olisi parempi." Se on tuotantoajattelua koodin verhoiluna. Korvaamatonta.

Todellinen pullonkaula: ihmisten välinen kitka

Jos speksaus on vaikeaa eikä AI korjaa sitä, mikä auttaa?

Vastaus on simppeli: vähennä kitkaa ihmisten välisessä viestinnässä.

Kun PM heittää brieffin devaajalle ja tämä viettää viikon palaverissa selvittämässä reunoja ja kompromisseja, speksaus ontuu. Kun desainerin mockupit törmäävät backend-rajoituksiin, speksaus ontuu. Kun AI generoi koodia oletuksilla, jotka eivät sovi bisnesvaatimuksiin, speksaus ontuu.

Ratkaisu ei ole fiksumpi agentti tai parempi validointityökalu. Se on tarkkuus ihmisten keskusteluun ennen agenttia.

Tee näin:

• Speksaus ensisijaiseksi artefaktiksi. Ei vaan dokumentti, vaan sopimus, josta koodigenerointi riippuu.
• Kirjaa trade-offit. Miksi eventual consistency eikä strong? Miksi tämä datamalli?
• Formaali notaatio kriittisissä kohdissa. SQL-skeemat, API-sopimukset, perf-budjetit – työkalut pakottavat selkeyteen.
• Pikainen agentti-feedback. Generoi pieni pala koodia speksistä, huomaa aukot ja korjaa speksi.

Mitä tämä tarkoittaa sun workflow'ssa

Jos rakennat tuotantojärjestelmiä AI-avusteisesti, älä hylkää agentteja. Panosta speksaukseen enemmän kuin ennen.

Kuulostaa oudolta nopeuden aikakaudella. Mutta nopea liikkuminen huonolla speksillä vie vääriin kohteisiin ripeämmin. Tiimit, jotka menestyvät agentic-kehityksessä, ovat tehneet ajattelutyön ensin. Agentit vain moninkertaistavat toteutuksen.

Startupit ja pienet tiimit: kilpailuetu ei ole koodigenerointi. Se on speksien selkeys. Jos saat bisneslogiikan niin tarkaksi, että AI toteuttaa sen luotettavasti, vaikein osa on ohi. Koodi on enää helppoa.

Lopputulos

Brooks oli oikeassa 1986, ja on edelleen 2025. Ohjelmistojen ydinkompleksisuus on konseptoinnissa, ei rakentamisessa. AI ei muuttanut tätä – se vain teki epämääräisen ajattelun ja tarkan koodin kuilun selväksi.

Seuraava tuottavuuslaine ei tule paremmista agenteista. Se tulee tiimeistä, jotka kurittavat speksauskäytäntöjä, tekevät vaatimusten määrittelystä insinööritiedettä ja käyttävät AI:ta selkeyden vahvistajana, ei hämmennyksen peitteenä.

Tuo on todellinen mahdollisuus AI:n ja kehityksen rajalla. Ja se vaatii sen, mitä agentti ei osaa: syvällistä pohdintaa siitä, mitä oikeasti rakennat.