Mes esame programinės įrangos kūrimo lūžio taške. Diskusija dažnai sukasi apie tai, kokia ar dirbtinis intelektas rašo geriausią kodą (Claude vs. ChatGPT), ar kur kur dirbtinis intelektas turėtŷ gyventi (IDE ar CLI). Tačiu tai yra neteisingas klausimas.
Problema nėra generuoti kodo. Tai yra validavimas iš to.
Jei priimame dirbtinį intelektą kaip „Vibe Kodavimo įrankius“ – nurodydami ketinimą, o dirbtinis intelektas atlieka vykdymą – sukuriame didžiulę naujos programinės įrangos srautą. Dirbtinio intelekto 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 Dirbtinio Intelekto Dizaino Autoritetas.
Tradicinis „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.
Kai pereiname prie „Išmetamo kodo“ – programinės įrangos, kurios mes nerestruktūrizuojame be galo, o išmetame ir iš naujo generuojame, kai keičiasi reikalavimai – mūsų vaidmuo iš esmės pasikeičia. Mes nebeesame mūrininkai, klojantys akmenį po akmens. Mes esame sienas spausdinančios gamyklos architektai.
Bet kas patikrins, ar tos sienos yra tiesios?
Dirbtinio intelekto dizaino autoritetas nėra asmuo, o procesas. Tai yra „Iššūkis“ (Gauntlet), kurį kiekviena sugeneruoto kodo eilutė turi įveikti, kad pasiektų gamybą. Šis procesas nepakeičia žmogaus kodo peržiūros niekuo, o kuo nors geresniu.
Tai veikia trimis lygmenimis:
1. Vykdomoji valdžia (Generavimas)
Mes neprašome vieno dirbtinio intelekto (DI) sprendimo, mes prašome trijų. Mes leidžiame „Gemini 3“, „GPT-5“ ir atvirojo kodo modelį (pvz., „Llama“) lygiagrečiai dirbti su ta pačia problema. Tai apsaugo nuo siauro mąstymo ir įveikia „tingumą“, kuriuo kartais kenčia dideli kalbos modeliai (LLM). Šis metodas taip pat yra moksliškai ištirtas ir parodo, kad galite išvengti DI haliucinacijų ir be klaidų sukurti labai ilgus grandinius
2. Kietasis filtras (Įstatymas)
Čia negali būti jokių diskusijų. Kodas turi kompiliuotis. Linteriai neturi skųstis. Ir svarbiausia: Juodosios dėžės testai turi būti sėkmingi. Mes netestuojame, ar funkcija veikia viduje (tai gali manipuliuoti dirbtiniu intelektu), mes testuojame, ar sistema išorėje daro tai, ką turi daryti. Testas nepavyksta? Tiesiog į šiukšliadėžę.
3. Švelnus filtras (Dirbtinio intelekto žiuri)
Tai tikroji inovacija. Likę sprendimai pateikiami specializuotam „Balsavimo dirbtiniam intelektui“ (Voting AI). Šis agentas kodo nerašo, bet skaito kodas. Jis apmokytas pagal mūsų architektūros principus, saugumo reikalavimus (OWASP, ISO) ir atitikties taisykles (ES AI aktas).
Jis teigia: “A sprendimas yra greitesnis, tačiau B sprendimas yra saugesnis ir geriau atitinka mūsų mikroslygų architektūrą.”
Nugalėtojas keliauja į gamybą.
Šis modelis priverčia atskirti valdžias, kurios trūksta daugelyje komandų.
project-description.md, rules.md, skills.md en principles.md), griežti reikalavimai. Architektas nustato ką mes statome, kas stato, kaip ir kodėl.
Tai išlaisvina mus nuo sintaksės klaidų tironijos ir leidžia sutelkti dėmesį į tai, ką mes darome gerai: sisteminį mąstymą. Tiesa, kurią reikia rasti. Struktūra ir sprendimų priėmimas.
Klausimas nėra tai, ar dirbtinis intelektas gali parašyti mūsų kodą. Ta tema jau baigta. Kodas didžiąja dalimi taps vienkartiniu produktu.
Klausimas yra: ar išdrįsite perimti kontrolę per kodą paleisti, taip atgaunant kontrolę kokybę atgauti?
praneškite man