Olemme ohjelmistokehityksen murroskohdassa. Keskustelu koskee usein sitä, mikä kirjoittaako tekoäly parhaan koodin (Claude vai ChatGPT) vai missä missä tekoälyn pitäisi toimia (IDE:ssä vai komentorivillä). Mutta tämä ei ole oikea kysymyksenasettelu.
Jos omaksumme tekoälyn ”vibe-koodareina” – ilmaisemme tarkoituksen ja annamme tekoälyn huolehtia toteutuksesta – tuotamme valtavan määrän uutta ohjelmistoa. Tekoälyagenttien parvi voi tuottaa yhdessä minuutissa enemmän koodia kuin kokenut kehittäjä ehtii arvioida viikossa. Ihmisestä on tullut pullonkaula.
Ratkaisu ei ole enemmän ihmiset. Ratkaisu on AI-suunnitteluorganisaatio.
Perinteisesti ”Design Authority” on arkkitehtiryhmä, joka kokoontuu kerran viikossa tai kuukaudessa hyväksymään tai hylkäämään suunnitelman. Aikakaudella, jota leimaa erittäin nopean tekoälykehityksen tämä malli on toivottoman vanhentunut. Se on liian hidas ja reaktiivinen.
Kun siirrymme ”kertakäyttöiseen koodiin” – ohjelmistoon, jota emme refaktoroi loputtomasti vaan jonka heitämme pois ja tuotamme uudelleen vaatimusten muuttuessa – roolimme muuttuu perusteellisesti. Emme enää ole muurareita, jotka latovat kiven kerrallaan. Olemme tehtaan arkkitehteja, jotka tulostavat seinät.
Mutta kuka tarkistaa, ovatko nämä seinät suorassa?
Tekoälyn suunnitteluauktoriteetti ei ole henkilö, vaan putki. ”Gauntlet”, jonka läpi jokaisen tuotantoon päätyvän koodirivin on taisteltava. Tämä prosessi ei korvaa ihmisen tekemää koodikatsausta ei millään, vaan jollakin paremmalla.
Se toimii kolmella tasolla:
1. Toimeenpaneva valta (generointi)
Emme pyydä yhtä tekoälyä ratkaisemaan ongelmaa, vaan pyydämme kolmea. Annamme Geminin 3:n, GPT-5:n ja avoimen lähdekoodin mallin (kuten Llaman) työskennellä rinnakkain saman ongelman parissa. Tämä estää putkinäköä ja murtaa ”laiskuuden”, josta suuret kielimallit joskus kärsivät. Tämä lähestymistapa on myös tieteellisesti tutkittu ja osoittaa, että tekoälyn hallusinaatiot voidaan ehkäistä ja erittäin pitkiä ketjuja rakentaa ilman virheitä
2. Kova suodatin (laki)
Tässä ei ole sijaa keskustelulle. Koodin on käännyttävä. Lintersomääritysten ei pidä antaa virheilmoituksia. Ja mikä tärkeintä: Musta laatikko -testit on läpäistävä. Emme testaa, toimiiko funktio sisäisesti (tekoäly voi manipuloida sitä), vaan testaamme, tekeekö järjestelmä ulkoisesti sen, mitä sen pitääkin tehdä. Jos testi epäonnistuu, ratkaisu joutaa suoraan roskakoriin.
3. Pehmeä suodatin (tekoälyraati)
Tässä on todellinen innovaatio. Jäljelle jääneet ratkaisut esitetään erikoistuneelle ”äänestävälle tekoälylle”. Tämä agentti ei kirjoita koodia, vaan lukee koodia. Se on koulutettu noudattamaan arkkitehtuuriperiaatteitamme, tietoturvavaatimuksiamme (OWASP, ISO) ja vaatimustenmukaisuussääntöjämme (EU:n tekoälysäädös).
Hän antaa äänensä: ”Ratkaisu A on nopeampi, mutta ratkaisu B on turvallisempi ja noudattaa paremmin mikropalveluarkkitehtuuriamme.”
Voittaja siirtyy tuotantoon.
Tämä malli varmistaa vallanjaon, joka monista tiimeistä puuttuu.
project-description.md, rules.md, skills.md en principles.md), tiukat vaatimukset. Arkkitehti määrittää mitä mitä rakennamme, kuka sen rakentaa, miten ja miksi.Se vapauttaa meidät syntaksivirheiden tyranniasta ja antaa meidän keskittyä siihen, missä olemme hyviä: systeemiajatteluun, totuuden selvittämiseen, rakenteeseen ja päätöksentekoon.
Kysymys ei ole siitä, pystyykö tekoäly kirjoittamaan koodimme. Tämä aihe on jo loppuun käsitelty. Koodista tulee suurelta osin kertakäyttötuote.
Kysymys kuuluu: uskallatko luopua koodissa hallinnasta saadaksesi siten takaisin hallinnan laadusta ?
kerro minulle