DI architektūros priežiūros institucija

Programinės įrangos kūrimas pasiekė lūžio tašką. Diskusijose dažnai kalbama apie tai, kuri ar DI rašo geriausią kodą („Claude“ ar „ChatGPT“), ar kur kur tas DI turėtų būti naudojamas (IDE ar CLI). Tačiau tai nėra tinkamai suformuluotas klausimas.

Jei priimsime DI kaip „Vibe Coding“ įrankį – kai mes nurodome ketinimą, o DI atlieka įgyvendinimą, – sukursime milžinišką kiekį naujos programinės įrangos. DI agentų spiečius per vieną minutę gali sugeneruoti daugiau kodo, nei vyresnysis programuotojas spėtų peržiūrėti per savaitę. Žmogus tapo kliūtimi.

Sprendimas – ne daugiau žmonės. Sprendimas – DI projektavimo priežiūros institucija,.

Nuo amatininko iki gamyklos direktoriaus

Tradiciškai „projektavimo priežiūros institucija“ – tai architektų grupė, kartą per savaitę ar mėnesį susirenkanti patvirtinti arba atmesti projektą. Pasaulyje, kuriame didelės spartos DI kūrimo šis modelis beviltiškai paseno. Jis pernelyg lėtas ir reaktyvus.

Jei pereisime prie „vienkartinio kodo“ – programinės įrangos, kurios neperdarinėjame be galo, o pasikeitus reikalavimams išmetame ir sugeneruojame iš naujo, – mūsų vaidmuo iš esmės pasikeis. Mes jau nebesame mūrininkai, dedantys plytą po plytos. Esame gamyklos, kuri spausdina sienas, architektai.

Tačiau kas tikrina, ar tos sienos stovi tiesiai?

„Gauntlet“: automatizuotas išbandymas

DI dizaino priežiūros institucija nėra žmogus, tai – konvejeris. „Gauntlet“ – išbandymas, kurį turi įveikti kiekviena sugeneruoto kodo eilutė, kad patektų į gamybinę aplinką. Šis procesas nepakeičia žmogaus atliekamos kodo peržiūros niekuo, o kažkuo geresniu.

Jis veikia trimis sluoksniais:

1. Vykdomoji valdžia (generavimas)
Mes neprašome vieno DI pateikti sprendimo – prašome trijų. Leidžiame „Gemini 3“, „GPT-5“ ir atvirojo kodo modeliui (pavyzdžiui, „Llama“) lygiagrečiai spręsti tą pačią problemą. Taip išvengiama tunelinio mąstymo ir įveikiamas „tingumas“, nuo kurio kartais kenčia didieji kalbos modeliai. Šis metodas taip pat yra moksliškai ištirtas ir įrodo, kad galima išvengti DI haliucinacijų bei kurti labai ilgas grandines be klaidų

2. Griežtasis filtras (įstatymas)
Čia diskusijoms nėra vietos. Kodas turi būti sukompiliuotas. Linteriai neturi pateikti įspėjimų. Ir svarbiausia: „Black Box“ testai turi būti sėkmingi. Mes netikriname, ar funkcija veikia viduje (DI gali tuo manipuliuoti), tikriname, ar sistema iš išorės daro tai, ką privalo. Testas nepavyko? Iškart į šiukšliadėžę.

3. Švelnusis filtras (DI žiuri)
Tai tikroji inovacija. Likę sprendimai pateikiami specializuotam „balsuojančiam DI“. Šis agentas nekoduoja, bet skaito kodas. Jis apmokytas pagal mūsų architektūros principus, saugumo reikalavimus (OWASP, ISO) ir atitikties taisykles (ES DI aktą).
Jis balsuoja: „Sprendimas A yra greitesnis, tačiau sprendimas B yra saugesnis ir geriau atitinka mūsų mikropaslaugų architektūrą.“

Nugalėtojas perkeliamas į gamybinę aplinką.

Programinės įrangos valdžių atskyrimas

Šis modelis užtikrina valdžių atskyrimą, kurio trūksta daugelyje komandų.

• Įstatymų leidžiamoji valdžia (Architektas): Architektas rašo „Konstituciją“. Raginimus, architektūros dokumentus (project-description.md, rules.md, skills.md en principles.md), griežtus reikalavimus. Architektas nustato, ką ką kuriame, kas kuria, kaip ir kodėl.
• Vykdomoji valdžia (kodavimo agentai): Jie įgyvendina. Greitai, nebrangiai ir prižiūrint žmonėms kūrėjams.
• Teisminė valdžia (dizaino priežiūros institucija): Nepriklausomas dirbtinio intelekto sluoksnis, tikrinantis, ar laikomasi įstatymų.

Išvada: naujas architekto vaidmuo

Jis išlaisvina mus nuo sintaksės klaidų tironijos ir leidžia susitelkti į tai, ką išmanome geriausiai: sisteminį mąstymą. Tiesos paiešką. Struktūrą ir sprendimų priėmimą.

Klausimas nėra, ar DI gali parašyti mūsų kodą. Ši tema jau uždaryta. Kodas iš esmės taps vienkartiniu produktu.
Klausimas toks: ar išdrįsi atsisakyti kodui kontrolės, kad taip atgautum kokybei kontrolę?

pranešk man