AI dizaina pārvalde
Programmatūras izstrādē esam nonākuši lūzuma punktā. Diskusijas bieži vien ir par to, kurš vai AI raksta labāko kodu (Claude vai ChatGPT), vai kur kur AI būtu jāatrodas (IDE vai CLI). Taču tas nav pareizais jautājums.
Ja pieņemam AI kā “Vibe Coders” — mēs norādām ieceri, bet AI veic izpildi — mēs radām milzīgu jaunas programmatūras plūsmu. AI aģentu bars vienas minūtes laikā var ģenerēt vairāk koda, nekā vecākais izstrādātājs spēj pārskatīt nedēļas laikā. Cilvēks ir kļuvis par šauro vietu.
Risinājums nav vairāk cilvēki. Risinājums ir AI dizaina pārvaldības institūcija.
No amatnieka par rūpnīcas vadītāju
Tradicionāli “dizaina pārvaldības institūcija” ir arhitektu grupa, kas reizi nedēļā vai mēnesī sanāk kopā, lai apstiprinātu vai noraidītu dizainu. Pasaulē, kurā notiek ātras izstrādes ar AI šis modelis ir bezcerīgi novecojis. Tas ir pārāk lēns un reaģējošs.
Ja pārejam uz “vienreizlietojamu kodu” — programmatūru, kuru mēs nepārtraukti nepārstrukturējam, bet, mainoties prasībām, izmetam un ģenerējam no jauna — mūsu loma būtiski mainās. Mēs vairs neesam mūrnieki, kas klāj akmeni pēc akmens. Mēs esam rūpnīcas arhitekti, kas drukā sienas.
Bet kurš pārbauda, vai šīs sienas ir taisnas?
“Gauntlet”: automatizēts ugunskristību tests
AI dizaina autoritāte nav persona, bet gan konveijers. “Gauntlet” — pārbaudījumu virkne, kurai jāiziet cauri katrai ģenerētā koda rindiņai, lai tā nonāktu produkcijas vidē. Šis process neaizstāj cilvēka veiktu koda pārskatīšanu ar neko, bet gan ar kaut ko labāku.
Tas darbojas trīs līmeņos:
1. Izpildvara (ģenerēšana)
Mēs nelūdzam vienai AI sistēmai rast risinājumu — mēs lūdzam trim. Mēs liekam Gemini 3, GPT-5 un atvērtā koda modelim (piemēram, Llama) paralēli risināt vienu un to pašu problēmu. Tas novērš redzesloka sašaurināšanos un pārrauj “slinkumu”, no kura LLM dažkārt cieš. Šī pieeja ir arī zinātniski izpētīta un parāda, ka var novērst AI halucinācijas un veidot ļoti garas ķēdes bez kļūdām
2. Stingrais filtrs (likums)
Šeit diskusijām nav vietas. Kodam ir jākompilējas. Linters nedrīkst ziņot par kļūdām. Un pats svarīgākais: Melnās kastes testi ir jāiztur pārbaudes. Mēs nepārbaudām, vai funkcija darbojas iekšēji (AI to varētu manipulēt), bet gan to, vai sistēma no ārpuses dara to, kas tai jādara. Pārbaude neizturēta? Uzreiz miskastē.
3. Mīkstais filtrs (MI žūrija)
Šī ir īstā inovācija. Atlikušie risinājumi tiek nodoti specializētai “balsojošajai AI”. Šis aģents neraksta kodu, bet lasa kods. Tas ir apmācīts, balstoties uz mūsu arhitektūras principiem, drošības prasībām (OWASP, ISO) un atbilstības noteikumiem (ES MI akts).
Tas balso: “Risinājums A ir ātrāks, bet risinājums B ir drošāks un labāk atbilst mūsu mikropakalpojumu arhitektūrai.”
Uzvarētājs nonāk ražošanas vidē.
Programmatūras varas dalīšana
Šis modelis nodrošina varas dalīšanu, kuras daudzās komandās trūkst.
- Likumdevēja vara (arhitekts): Arhitekts izstrādā “Konstitūciju”. Uzvednes, arhitektūras dokumenti (
project-description.md, rules.md, skills.md en principles.md), stingrās prasības. Arhitekts nosaka ko ko mēs būvējam, kas to būvē, kā un kāpēc. - Izpildvara (kodēšanas aģenti): Viņi to īsteno — ātri, lēti un cilvēku izstrādātāju pārraudzībā.
- Tiesu vara (dizaina pārvalde): Neatkarīgs MI slānis, kas pārbauda atbilstību likumam.
Secinājums: arhitekta jaunā loma
Tas atbrīvo mūs no sintakses kļūdu tirānijas un ļauj koncentrēties uz to, kas mums padodas vislabāk: sistēmisko domāšanu. Patiesības noskaidrošanu. Struktūru un lēmumu pieņemšanu.
Jautājums nav par to, vai MI spēj uzrakstīt mūsu kodu. Šis jautājums jau ir atrisināts. Kods lielākoties kļūs par vienreiz lietojamu produktu.
Jautājums ir: vai tu uzdrīksties atteikties no kontroles pār kodu lai tādējādi atgūtu kontroli pār kvalitāti ?
dod man ziņu
