AI-suunnittelun auktoriteetti

Olemme käännekohdassa ohjelmistokehityksessä. Keskustelu käy usein siitä, mikä kirjoittaako AI parhaan koodin (Claude vs. ChatGPT) vai missä pitäisikö AI:n asua IDE:ssä vai CLI:ssä. Mutta se ei ole oikea kysymys.

Ongelma ei ole generointi koodin määrä. Ongelma on validointi sen

Kun omaksumme AI:n ”vibe-koodereina” — joissa määrittelemme tarkoituksen ja AI hoitaa toteutuksen — luomme valtavan määrän uutta ohjelmistoa. AI-agenttien parvi voi minuutissa generoida enemmän koodia kuin vanhempi kehittäjä ehtii viikossa tarkistaa. Ihminen on tullut pullonkaulaksi.

Ratkaisu ei ole lisää ihmisissä. Ratkaisu on AI-suunnitteluviranomainen.

Käsityöläisestä tehtaanjohtajaksi

Perinteisesti ”Design Authority” on joukko arkkitehteja, jotka tapaavat kerran viikossa tai kuukaudessa hyväksyäkseen tai hylätäkseen suunnitelman. Maailmassa, nopean kehityksen tekoälykehitys on tuo malli toivottoman vanhentunut. Se on liian hidas ja reaktiivinen.

Kun siirrymme ”Disposable Code” -malliin – ohjelmistoon, jota emme refaktoroi loputtomiin, vaan hylkäämme ja generoimme uudelleen vaatimusten muuttuessa – roolimme muuttuu perusteellisesti. Emme ole enää muurareita, jotka laativat tiili tiileltä. Olemme tehtaan suunnittelijoita, jotka suunnittelevat seinien tulostavan koneen.

Mutta kuka tarkistaa, että nuo seinät ovat suoria?

"Gauntlet": Automaattinen tulikoe

AI Design Authority ei ole henkilö, vaan putkisto. ”Haasteura”, jonka läpi jokaisen generoidun koodirivin on taisteltava päästäkseen tuotantoon. Tämä prosessi ei korvaa ihmisen tekemää koodikatselmointia ei millään, vaan jollakin paremmalla.

Se toimii kolmella tasolla:

1. Toimeenpaneva valta (Generointi)
Emme pyydä yhdeltä tekoälyltä ratkaisua, pyydämme kolmea. Annamme Geminin 3:n, GPT-5:n ja avoimen lähdekoodin mallin (kuten Llama) työskennellä rinnakkain saman ongelman parissa. Tämä estää tunnelinäön ja katkaisee LLM:ien ajoittaisen ”laiskuus”-ongelman. 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ässä ei ole keskustelun varaa. Koodin on pakko kääntyä. Linterit eivät saa valittaa. Ja ratkaisevaa: Black box -testit testien on läpäistävä. Emme testaa toimiiko funktio sisäisesti (se voi mahdollistaa AI:n manipuloinnin), vaan testaamme, tekeekö järjestelmä ulkoisesti sen, mitä sen pitää tehdä. Epäonnistuuko testi? Suoraan roskiin.

3. Pehmeä suodatin (AI-tuomioistuin)
Tässä on todellinen innovaatio. Jäljelle jääneet ratkaisut viedään erikoistuneen "äänestävä AI":n arvioitaviksi. Tämä agentti ei kirjoita koodia, mutta lukee arvioi koodia. Se on koulutettu arkkitehtuuriperiaatteisiimme, turvallisuusvaatimuksiin (OWASP, ISO) ja sääntelyn noudattamiseen (EU:n AI-asetus).
Se äänestää: "Ratkaisu A on nopeampi, mutta ratkaisu B on turvallisempi ja noudattaa paremmin mikropalveluarkkitehtuuriamme."

Voittaja siirtyy tuotantoon.

Ohjelmiston vallan kolmijako

Tämä malli pakottaa vallan kolmijakoisuuden, jota monista tiimeistä puuttuu.

• Lainsäädäntövalta (Arkkitehti): Arkkitehti kirjoittaa "perustuslain". Promptit, arkkitehtuuridokumentit (project-description.md, rules.md, skills.md en principles.md), tiukat vaatimukset. Arkkitehti päättää mitä mitä rakennamme, kuka rakentaa, miten ja miksi.
• Toimeenpaneva valta (Koodausagentit): He toteuttavat. Nopeasti, edullisesti ja ihmiskehittäjien valvonnassa.
• Tuomioistuinvalta (Design Authority): Itsenäinen tekoälykerros, joka varmistaa lain noudattamisen.

Johtopäätös: Arkkitehdin uusi rooli

Se vapauttaa meidät syntaksivirheiden tyranniasta ja antaa meidän keskittyä siihen, missä olemme hyviä: systeemiajatteluun. Totuuden etsintään. Rakenteeseen ja päätöksentekoon.

Kysymys ei ole, voiko AI kirjoittaa koodimme. Se aihe on jo ratkaistu. Koodi muuttuu enimmäkseen kertakäyttötuotteeksi.
Kysymys on: uskallatko luopua kontrollista over koodi päästää irti, ja siten saada takaisin kontrolli laatu voitto takaisin?

kerro minulle