Esame programinės įrangos kūrimo lūžio taške. Diskusijos dažnai sukasi apie tai, kuris ar dirbtinis intelektas rašo geriausią kodą („Claude“ ir „ChatGPT“ dvikova), kur Tačiau tai nėra tinkamas klausimas.
Jei priimsim dirbtinį intelektą kaip „nuotaikos programuotojus“ („Vibe Coders”), kai mes nurodome ketinimą, o dirbtinis intelektas atlieka vykdymą, sukursime didžiulį naujos programinės įrangos srautą. Dirbtinio intelekto 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 (bottleneck).
Sprendimas nėra daugiau žmonės. Sprendimas – tai AI projektavimo institutas.
Tradiciškai “projektavimo institutas” (Design Authority) – tai architektų grupė, susirenkanti kartą per savaitę ar mėnesį patvirtinti arba atmesti projektą. Pasaulyje, didelio greičio dirbtinio intelekto kūrimo (high-velocity AI development) šis modelis yra beviltiškai pasenęs. Jis per lėtas ir per daug reaktyvus.
Jei pereisime prie „vienkartinio kodo“ („Disposable Code“) – programinės įrangos, kurios be galo refaktoriuojame, o tiesiog išmetame ir sugeneruojame iš naujo, pasikeitus reikalavimams – mūsų vaidmuo iš esmės pasikeičia. Mes jau nesame mūrininkai, dedantys plytą po plytos. Mes esame gamyklos, spausdinančios sienas, architektai.
Bet kas patikrina, ar tos sienos tiesios?
Dirbtinio intelekto dizaino institucija (AI Design Authority) nėra asmuo, o konvejeris. Tai „išbandymų laukas“ (Gauntlet), per kurį turi pereiti kiekvienas sugeneruotas kodas, kad pasiektų gamybinę aplinką. Šis procesas nepakeičia žmogiškojo kodo peržiūros niekuo, o pakeičia jį kažkuo geresniu.
Jis veikia trimis lygiais:
1. Vykdomoji valdžia (Generavimas)
Mes neprašome vieno dirbtinio intelekto rasti sprendimo – prašome trijų. Leidžiame „Gemini 3“, „GPT-5“ ir atvirojo kodo modeliui (tokiam kaip „Llama“) lygiagrečiai spręsti tą pačią problemą. Tai padeda išvengti tunelinio mąstymo ir įveikia „tingumą“, kuriam kartais būdingi dideli kalbos modeliai (LLM). Šis požiūris taip pat yra moksliškai ištirtas ir įrodo, kad galima išvengti dirbtinio intelekto halliucinacijų bei kurti labai ilgas grandines be klaidų
2. Griežtas filtras (Įstatymas)
Čia jokių diskusijų negali būti. Kodas privalo kompiliuotis. „Linters“ neturi reikšti nusiskundimų. Ir kas itin svarbu – juodosios dėžės testai turi būti sėkmingi. Mes netikriname, ar funkcija veikia iš vidaus (tai dirbtinis intelektas gali manipuliuoti), mes tikriname, ar sistema išorėje atlieka tai, ką privalo. Testas nepavyko? Iškart į šiukšliadėžę.
3. Švelnusis filtras (DI žiuri)
Tai tikroji inovacija. Liko atrinkti sprendimai, kurie pateikiami specializuotam „balsavimo dirbtiniam intelektui“ („Voting AI“). Šis agentas nerašo kodo, bet skaito kodą. Jis apmokytas pagal mūsų architektūros principus, saugumo reikalavimus (OWASP, ISO) ir atitikties taisykles (ES Dirbtinio intelekto aktą).
Jis nusprendžia: „A sprendimas yra greitesnis, bet B sprendimas yra saugesnis ir geriau atitinka mūsų mikropaslaugų architektūrą.“
Laimėtojas keliauja į gamybinę aplinką.
Šis modelis užtikrina valdžių padalijimą, kurio dažnai trūksta daugelyje komandų.
project-description.md, rules.md, skills.md en principles.md), griežtus reikalavimus. Architektas nusprendžia ką mes statome, kas tai stato, kaip ir kodėl.Tai išvaduoja mus iš sintaksės klaidų tironijos ir leidžia susitelkti į tai, ką mokame geriausiai: sisteminį mąstymą, tiesos paiešką, struktūrą ir sprendimų priėmimą.
Klausimas ne tau, ar DI gali parašyti mūsų kodą. Šis klausimas jau uždarsas. Kodas iš esmės tampa vienkartiniu produktu.
Klausimas yra: ar išdrįsti paleisti kontrolę kodo srityje, kad vėl susigrąžintum kontrolę kokybės srityje?
praneškite man