Mes esame programinės įrangos kūrimo lūžio taške. Diskusijos dažnai sukasi apie tai, kuri ar dirbtinis intelektas rašo geriausią kodą (Claude prieš ChatGPT), ar kur kur dirbtinis intelektas turėtų gyventi (IDE ar CLI). Tačiau tai yra netinkama diskusija.
Tikroji problema nėra kartojimas kodas. Tikroji problema yra validavimas jos.
Jei priimame DI kaip „Vibų Kodavimo“ (nurodydami ketinimą, o DI atlieka vykdymą), sukursime didžiulę naujos programinės įrangos bangą. DI agentų spiečius per vieną minutę gali sugeneruoti daugiau kodo, nei vyresnysis programuotojas gali peržiūrėti per savaitę. Žmogus tapo kliūtimi.
Sprendimas nėra daugiau žmonės. Sprendimas yra DI Dizaino Autoritetas.
Tradicinis „Design Authority“ (Dizaino autoritetas) yra nedidelė architektų grupė, kuri susitinka kartą per savaitę ar mėnesį, kad patvirtintų ar atmestų dizainą. Pasaulyje, kuriame didelio greičio dirbtinio intelekto (DI) kūrimas šis modelis yra beviltiškai pasenęs. Jis per lėtas ir per daug reaktyvus.
Jei pereisime prie „Išmetamo kodo“ (Disposable Code) – programinės įrangos, kurios mes nerestruktūrizuosime be galo, o išmesime ir iš naujo sugeneruosime, kai pasikeis reikalavimai – mūsų vaidmuo iš esmės pasikeis. Mes nebėra mūrininkai, dedantys akmenį po akmens. Mes esame gamyklos, spausdinančios sienas, architektai.
Bet kas patikrins, ar tos sienos yra tiesios?
Dirbtinio intelekto projektavimo institucija (AI Design Authority) nėra asmuo, o procesas. Tai „išbandymas“ (Gauntlet), kurį turi įveikti kiekviena sugeneruoto kodo eilutė, kad pasiektų gamybą. Šis procesas nepakeičia žmogaus kodo peržiūros niekuo, o kažkuo geresniu.
Tai veikia trimis lygmenimis:
1. Vykdomoji valdžia (Generavimas)
Mes nenaudojame vieno dirbtinio intelekto sprendimui, o trijų. Leisime „Gemini 3“, „GPT-5“ ir atvirojo kodo modeliui (pvz., „Llama“) lygiagrečiai spręsti tą pačią problemą. Tai padeda išvengti siauro mąstymo ir įveikti „tingumą“, kuris kartais vargina didelius kalbos modelius (LLM). Šis metodas taip pat moksliškai ištirtas parodo, kaip galima išvengti dirbtinio intelekto haliucinacijų ir be klaidų sukurti labai ilgus grandinius
2. Kietasis filtras (Įstatymas)
Čia diskusija negalima. Kodas turi kompiliuotis. „Linters“ neturi skųstis. Ir svarbiausia: Juodosios dėžutės testai turi būti sėkmingi. Mes netestuojame, ar funkcija veikia viduje (tai gali manipuliuoti DI), mes testuojame, ar sistema išorėje daro tai, ką turi daryti. Jei testas nepavyksta? Iš karto į šiukšliadėžę.
3. Švelnusis filtras (Dirbtinio intelekto komisija)
Tai tikroji inovacija. Likę sprendimai pateikiami specializuotai „Balsuojančiai AI“ (Voting AI). Šis agentas nerašo kodo, bet skaito kodą. Jis apmokytas mūsų architektūros principų, saugumo reikalavimų (OWASP, ISO) ir atitikties taisyklių (ES AI akto).
Jis balsuoja: „Sprendimas A yra greitesnis, tačiau Sprendimas B yra saugesnis ir geriau atitinka mūsų mikropaslaugų architektūrą.“
Nugalėtojas keliauja į gamybą.
Šis modelis priverstinai atskiria valdžios šakas, ko dažnai trūksta daugelyje komandų.
project-description.md, rules.md en principles.md), griežti reikalavimai. Architektas nustato kas kaip mes statome ir kodėl.
Tai išlaisvina mus nuo sintaksės klaidų tironijos ir leidžia mums sutelkti dėmesį į tai, ką mokame geriausiai: sisteminį mąstymą, tiesos paiešką, struktūrą ir sprendimų priėmimą.
Klausimas nėra tai, ar dirbtinis intelektas gali rašyti mūsų kodą. Tai jau nuspręsta. Kodas didžiąja dalimi taps vienkartinis.
Klausimas yra: ar išdrįsite paleisti įgyvendinimas kontrolę, kad atgautumėte kontrolę kokybė atgal?