AI-kiihtyvyyden synkkä salaisuus

Olet tuntenut sen. Ensimmäinen kuukausi Clauden tai Cursorin kanssa tuntuu taialta. Uudet ominaisuudet syntyvät salamannopeasti, perusrakenteet nousevat tyhjästä ja tylsä toisto katoaa. Sitten tulee toinen kuukausi. Koodi kääntyy, testit menevät läpi ja deployit toimivat. Silti lopputulos ei vastaa sitä, mitä oikeasti halusit rakentaa.

Ei ole kyse laiskuudesta. Kyse on driftistä.

Tuoreet tutkimukset vahvistavat pelottavan kuvan. SlopCodeBenchin analyysi (maaliskuu 2026) näyttää, että lähes 90 prosenttia AI-agenttien poluista paisuu pitkillä tehtävillä ja menettää teräänsä. CMU:n Cursor-tutkimuksessa alkuperäinen 3–5-kertainen nopeusbuusti haihtuu kahdessa kuukaudessa, tilalle jää 30 prosenttia enemmän varoituksia ja 41 prosenttia monimutkaisempaa koodia. Pahinta: 22,7 prosenttia AI:n tuamista ongelmista jää elämään lopullisissakin versioissa satojen tuhansien committien jälkeen.

AI ei ole rikki. Ongelma on hallintamalli.

Kolme vaiettua vikaantumistapaa

Semanttinen drift
Tuotespec vaatii "kevyttä ja intuitiivista". Kolmen kuukauden ja viidenkymmenen promptin jälkeen systeemi noudattaa speksiä teknisesti – mutta painaa nyt 5 MB ja tarvitsee kolme mikropalvelua. Ideat muuttuivat huomaamatta. Kukaan ei hyväksynyt muutosta. Koodi kääntyy. Ongelma paljastuu vasta tuotannossa.

Näkymätön hallinta
Mistä tuo arkkitehtuuripäätös tuli? Chat-historiasta. Mikä specin versio oli pohjana? Tarkista Slack. Kuka päätti, että API palauttaa pesitetyt objektit litteiden sijaan? Luultavasti se insinööri, joka kysyi. Ei ole pysyvää tarkistuspinnoitetta, hyväksyntäjälkeä tai vastausta kysymykseen "kuka päätti tämän ja milloin?" – iso ongelma auditeissa tai regulaattoreiden kanssa.

Kontekstin hajoaminen
Koodisi kasvoi ulos yhden AI:n konteksti-ikkunasta jo kolme sprinttiä sitten. Yksikään agentti ei pidä kokonaiskuvaa. Omistus muuttui epäviralliseksi. Sitten arvaukseksi. Nyt kymmenen eri tulkintaa arkkitehtuurista elää rinnakkain brancheissa, kaikki "hyväksyttyjä" koska kukaan ei pystynyt tarkistamaan kokonaisuutta.

Ongelman tunnistaminen

Alkuvuodesta 2026 tämä iski samanaikaisesti kuudella nimellä viiden kuukauden aikana:

• Intent debt (Storey, Canada Research Chair)
• Cognitive debt (MIT Media Lab)
• Paradox of supervision (Anthropic)
• Scaffolding fragility (viral on HN)
• Comprehension debt (O'Reilly)
• AI slop (Baltes et al.)

Kaikki näkivät saman haavan. Kukaan ei toimittanut ratkaisua.

Sitten tuli contract-driven development.

Sopimus specsien sijaan

Spec-driven development oli askel eteenpäin. Kirjoitat haluamasi, systeemi generoi, kaikki laivaa. Se nappasi helpon hedelmän.

Mutta specsit vanhenevat hiljaa. Ne pyörivät wikissä. Kukaan ei tiedä, vastaako koodi enää speksiä, koska yhteyttä ei ole.

Contract-driven kääntää mallin päälaelleen.

Koodi generoidaan ja arvioidaan elävää sopimusta vastaan – monikerroksista rakennetta, joka tallentaa:

• Intent: Mihin systeemi on tarkoitettu (sinä omistat ja hyväksyt)
• Product & UX: Mitä käyttäjä kokee (generoidaan intentistä, sinä päätät hyväksynnästä)
• System: Kuinka se on rakennettu (generoidaan intentistä ja productista, sinä päätät hyväksynnästä)

Jokainen kerros hashataan. Jokainen on jäljitettävissä. Kun drift paljastuu – ja se paljastuu – saat:

1. Tunnistuksen: Kaikki hyväksytyt fingerprintataan; drift nousee pintaan automaattisesti
2. Korjauksen: Määritelty polku remontointiin, ei arvausta
3. Uudelleenarvioinnin: Koodi tuomitaan sopimusta vastaan, ei irrallaan

Jousto ja tiukkuus yhdessä

VibeLoom (ja contract-driven systeemit yleensä) toimivat viidessä tilassa riippuen projektin kypsyydestä:

Vibe – Protovauhti. Yksi hyväksyntä (intent). Loput etenevät automaattisesti. Laivaa nopeasti, opi nopeasti.

Product-led – Sinä omistat intentin ja productin. Systeemi etenee. Sopii design-vetoisille tiimeille.

Tech-led – Sinä omistat intentin ja systeemin. Product etenee. Infra-painotteisiin projekteihin.

Design-led – Sinä omistat intentin ja UX:n. Mockupit ohjaavat productia. Käyttäjäkeskeisille porukoille.

Expert – Jokainen kerros eksplisiittinen. Ei automaatiota. Nollan luottamuksen malli. Regulaatioon tai kriittisiin systeemeihin.

Älä aloita kaikilla. Mene vibellä alkuun. Päivitä kun koodisi vaatii seremonioita.

Miksi juuri nyt?

Tumma tehdaskehitys lähestyy. Koko systeemit syntyvät agenteilla minimaalisella ihmistyöllä. Kysymys ei ole, käytätkö AI:ta koodigenerointiin – vaan onko sinulla näkyvyyttä ja hallintaa kun käytät.

Spec-driven tallentaa intentin. Contract-driven säilyttää sen.

Ero kasvaa eksponentiaalisesti. Kun mallit kiihtyvät, systeemi joka tiukkenee ajan myötä (contract-driven) voittaa velkaantuvan (spec-driven) moninkertaisesti.

Koodikanta joka tietää tarkoituksensa, tunnistaa drifin ja korjaa sen määritellyllä polulla – sellainen skaalautuu AI:n kanssa, ei vastaan.

Ydinviesti

Jos laivaat AI-generoitua koodia tuotantoon, kysy itseltäsi:

• Voisinko jäljittää tämän päätöksen syyn?
• Tunnistaisinko, jos koodi ajautui intentistä?
• Onko minulla tapa korjata se?

Jos mikään ei ole "kyllä", tarvitset contract-kerroksen. Ei huomenna. Nyt.

Haluatko kokeilla? VibeLoom on open-source ja toimii Claude Code:n sekä Python 3.10+:n kanssa. Ei runtime-riippuvuuksia. MIT-lisenssi. Koodi on valmiina tiimeille, jotka haluavat specksien yli.

AI:n vauhtivoitot ovat totta. Niiden johdonmukainen pitäminen on seuraava raja.