Tekoälyn suunnitteluviranomainen
Olemme ohjelmistokehityksen käännekohdassa. Keskustelu pyörii usein sen ympärillä, mikä kumpi tekoäly kirjoittaa parhaan koodin (Claude vs. ChatGPT) vai missä missä tekoälyn tulisi asua (IDE vai komentorivi). Mutta se on väärä keskustelu.
Todellinen ongelma ei ole sukupolvi koodin. Todellinen ongelma on validointi sen.
Kun omaksumme tekoälyn "Vibe Codersiksi" – jossa me annamme aikomuksen ja tekoäly suorittaa – luomme valtavan uuden ohjelmistovirran. Tekoälyagenttien parvi voi tuottaa minuutissa enemmän koodia kuin kokenut kehittäjä ehtii tarkistaa viikossa. Ihminen on muuttunut pullonkaulaksi.
Ratkaisu ei ole lisää ihmiset. Ratkaisu on Tekoälyn suunnitteluviranomainen.
Käsityöläisestä tehtaanjohtajaksi
Perinteisesti "Design Authority" on pieni joukko arkkitehteja, joka kokoontuu kerran viikossa tai kuukaudessa hyväksymään tai hylkäämään suunnitelman. Maailmassa, nopeatahtinen tekoälyn kehitys on tuo malli toivottomasti vanhentunut. Se on liian hidas ja liian reaktiivinen.
Kun siirrymme "kertakäyttöiseen koodiin" – ohjelmistoon, jota emme jatkuvasti refaktoroi, vaan heitämme pois ja luomme uudelleen vaatimusten muuttuessa – roolimme muuttuu perustavanlaatuisesti. Emme ole enää muurareita, jotka asettavat kiviä yksitellen. Olemme tehtaan arkkitehteja, joka tulostaa seinät.
Mutta kuka valvoo, että nuo seinät ovat suorassa?
”Hanska”: Automatisoitu tulikoe
Tekoälyn suunnitteluviranomainen (AI Design Authority) ei ole henkilö, vaan putkilinja. "Haaste", jonka läpi jokaisen säännön mukaisesti luodun koodin on taisteltava päästäkseen tuotantoon. Tämä prosessi ei korvaa ihmisen suorittamaa koodin tarkistusta ei mitään, vaan jotain parempaa.
Se toimii kolmessa kerroksessa:
1. Toimeenpanovalta (Generointi)
Emme pyydä yhtä tekoälyä ratkaisua, 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ää tunnelinäön ja murtaa sen "laiskuuden", josta LLM:t joskus kärsivät. Tämä lähestymistapa on myös tieteellisesti tutkittu ja osoittaa, että voit estää tekoälyn hallusinaatiot ja rakentaa erittäin pitkiä ketjuja ilman virheitä
2. Kova suodatin (Laki)
Tästä ei voi keskustella. Koodin on käännyttävä. Linttereiden ei pidä valittaa. Ja ratkaisevaa: Mustan laatikon testit täytyy onnistua. Emme testaa, toimiiko funktio sisäisesti (se voi manipuloida tekoälyä), vaan testaamme, tekeekö järjestelmä ulkoisesti sen, mitä sen pitää tehdä. Epäonnistuuko testi? Suoraan roskakoriin.
3. Pehmeä suodatin (Tekoälytuomaristo)
Tämä on todellinen innovaatio. Jäljelle jääneet ratkaisut esitetään erikoistuneelle "Äänestys-tekoälylle". Tämä agentti ei kirjoita koodia, vaan lukee koodi. Se on koulutettu arkkitehtuurimme periaatteiden, turvallisuusvaatimusten (OWASP, ISO) ja vaatimustenmukaisuussääntöjen (EU:n tekoälyasetus) mukaisesti.
Se toteaa: “Ratkaisu A on nopeampi, mutta Ratkaisu B on turvallisempi ja noudattaa paremmin mikropalveluarkkitehtuuriamme.”
Voittaja siirtyy tuotantoon.
Ohjelmiston vallan kolmijako-oppi
Tämä malli pakottaa aikaan vallan kolmijakoa, joka puuttuu monista tiimeistä.
- Lainsäädäntövalta (Arkkitehti): Arkkitehti kirjoittaa ”perustuslain”. Kehotteet, arkkitehtuuridokumentit (
project-description.md, rules.md en principles.md), kovat vaatimukset. Arkkitehti päättää mitä rakennamme ja miksi. - Toimeenpanovalta (Koodausagentit): Ne toteuttavat. Nopeasti, edullisesti ja ihmiskehittäjien valvonnassa.
- Tuomiovalta (Suunnitteluviranomainen): Lakiin sitoutuva itsenäinen tekoälykerros.
Johtopäätös: Arkkitehdin uusi rooli
Se vapauttaa meidät syntaksivirheiden tyrannialta ja antaa meidän keskittyä siihen, missä olemme hyviä: Järjestelmäajatteluun. Totuuden löytämiseen. Rakenteeseen ja päätöksentekoon.
Kysymys ei ole siitä, voiko tekoäly kirjoittaa koodimme. Se on jo päätetty. Koodista tulee suurelta osin kertakäyttöistä.
Kysymys kuuluu: Uskallatko luopua hallinnasta toteutus antaa periksi, jotta voitaisiin saada takaisin hallinta laatu takaisin?
