Programavimo pagal nuojautą pabaiga! Tegyvuoja SDD!

Prieš kelis mėnesius kūrėjų bendruomenę pakerėjo naujas reiškinys: programavimas pagal nuojautą (angl. vibe coding). Prielaida buvo svaiginančiai paprasta – jums nereikėjo plano, schemos ar net gilaus sintaksės supratimo; tereikėjo apibūdinti jausmą DI agentui ir stebėti, kaip materializuojasi kodas. Tai atrodė kaip magija, kol pasirodė pirmoji rimta klaida. Staiga ta sklandi patirtis virto karštligišku „pataisyk tai“ ir „dabar anas sugedo“ ciklu, palikdama kūrėją įstrigusį pokalbyje su mašina, kuri pametė esmę.

Istoriškai mes praleisdavome mėnesius šlifuodami išsamius reikalavimų dokumentus prieš parašydami bent vieną kodo eilutę – tai buvo griežtas procesas, kuris dažnai slopino inovacijas; šiandien mes dažnai išleidžiame kodą dar nespėję nuspręsti, ką produktas turi daryti – tai chaotiškas įprotis, sukuriantis didžiulę techninę skolą. Ši įtampa pagimdė naują paradigmą: specifikacijomis grįstą kūrimą (angl. spec-driven development, SDD). Tai pragmatiškas vidurio kelias, sukurtas suteikti DI agentams reikiamas gaires, negrįžtant prie išpūstų 10-ojo dešimtmečio „krioklio“ (angl. waterfall) metodų.

Ketinimų sutartis

Iš esmės specifikacijomis grįstas kūrimas yra „tiesos šaltinio“, kurį gali skaityti tiek žmonės, tiek mašinos, kūrimas. Den Delimarsky iš „Microsoft“ apibūdina specifikaciją kaip „jūsų mąstymo versijų kontrolę“, o praktikoje ji veikia kaip privaloma sutartis. Užuot metęs neaiškias užklausas į ekraną ir tikėjęsis geriausio, kūrėjas rašo glaustą, struktūrizuotą dokumentą, kuris tiksliai apibrėžia, kaip kodas turėtų elgtis.

Techniškai kalbant, šis pokytis išsprendžia „konteksto dreifo“ problemą. DI agentai puikiai vykdo užduotis, tačiau po penkiasdešimties peržiūrų etapų linkę pamiršti funkcijos esmę („kodėl“). Susiejant kūrimo procesą su specifikacija, užtikriname, kad DI išliktų padėjėju, o ne nevaldomu įrankiu. Birgitta Böckeler iš „Thoughtworks“ išskiria tris šios evoliucijos lygius: „pirmiausia specifikacija“ (spec-first), kai planas eina prieš kodą; „įtvirtinta specifikacija“ (spec-anchored), kai dokumentas išlieka gairėmis priežiūrai; ir siekiamybė „specifikacija kaip šaltinis“ (spec-as-source), kai žmogus liečiasi tik prie specifikacijos, o pats kodas lieka visiškai „po gaubtu“.

Kiro: architekto CLI

„AWS“ viduje dirbančios kategoriškos komandos sukurtas „Kiro“ yra tvirtas įrankis, kuris į programinės įrangos kūrimą žiūri kaip į inžinerinę discipliną, o ne spėliojimą. Jis siūlo tiek IDE, tiek CLI, tačiau tikroji jo galia slypi struktūrizuotuose „Markdown“ reikalavimuose. „Kiro“ naudoja EARS (angl. Easy Approach to Requirements Syntax) – notaciją, kuri verčia siekti aiškumo per paprastą modelį: KAI [sąlyga], SISTEMA TURI [elgsena].

Žvelgiant iš vartotojo perspektyvos, EARS reikalavimų rašymas labiau primena logikos braižymą, o ne „programavimą“. Ši struktūra leidžia „Kiro“ generuoti savybėmis grįstus testus, kurie yra daug išsamesni nei standartiniai vienetiniai testai, užfiksuojant kraštutinius atvejus, kuriuos programuotojas žmogus – arba „nuojauta besivadovaujantis“ DI – tikriausiai praleistų. Be to, „Kiro“ pristato „vairavimo“ (angl. steering) failų koncepciją. Šie dokumentai – product.md, tech.md ir structure.md – veikia kaip nematoma projekto infrastruktūra, užtikrinanti, kad kiekviena sugeneruoto kodo dalis atitiktų pasirinktą technologijų rinkinį ir architektūrines konvencijas.

Spec Kit: agentų darbo eigos standartizavimas

„Microsoft“ sukurtas „Spec Kit“ laikosi kitokio požiūrio ir veikia kaip atvirojo kodo tiltas tarp trisdešimties skirtingų programavimo agentų ir struktūrizuoto keturių etapų proceso. Jei programavimas pagal nuojautą atrodo kaip nestruktūrizuota minčių audra, „Spec Kit“ primena profesionalias dirbtuves. Jame pristatomas „slash“ komandų rinkinys, pavyzdžiui, /speckit.plan ir /speckit.analyze, kurios verčia agentą sustoti ir pagalvoti prieš pradedant rašyti.

Paradoksalu, tačiau pridėjus šiuos „trinties taškus“, „Spec Kit“ iš tikrųjų pagreitina kūrimą. Jis apsaugo nuo „haliucinacijų ciklų“, kai agentas bando ištaisyti klaidą įvesdamas naują, dar sudėtingesnę klaidą. Nesvarbu, ar kuriate naują projektą nuo nulio, ar bandote išnarplioti fragmentuotą seną kodą, „Spec Kit“ suteikia projektui „konstituciją“. Jis perkelia programuotoją iš mašininko vaidmens į apžvalgininko vaidmenį, sutelkiant dėmesį į aukšto lygio logiką, kol agentas tvarko grubias įgyvendinimo detales.

Tessl ir įgūdžių registras

„Tessl“ į SDD ekosistemą įneša intriguojantį sluoksnį: paketų registrą. Jei kodą laikytume receptu, „Tessl“ per savo „plyteles“ (angl. tiles) pateikia standartizuotus ingredientus ir gaminimo būdus. Šiose plytelėse yra procedūrinės darbo eigos (įgūdžiai), privalomi kodavimo standartai (taisyklės) ir dokumentacija, kurios agentai gali teirautis pagal poreikį.

Kasdieniais terminais tariant, naudoti „Tessl“ yra tas pats, kas duoti savo DI agentui bibliotekos kortelę ir namų taisyklių rinkinį. Įdiegus „Tessl SDD“ plytelę ir tiesiog paprašius agento „naudoti specifikacijomis grįstą kūrimą“, darbo eiga pasikeičia. Agentas nustoja elgtis kaip nuolankus automatinis užbaigėjas ir pradeda elgtis kaip jaunesnysis inžinierius, kuris užduoda patikslinančius klausimus ir parengia planą prieš liesdamas saugyklą. Šis skaidrumas yra gyvybiškai svarbus; jis paverčia nepermatomą DI generavimo „juodąją dėžę“ matomu, audituojamu procesu.

Zenflow: orkestravimas su verifikacija

Jei kiti įrankiai sutelkia dėmesį į „ką“ ir „kaip“, „Zenflow“ orientuojasi į „kas“ ir „kur“. „Zencoder“ komandos sukurtas „Zenflow“ veikia kaip orkestravimo sluoksnis, koordinuojantis kelių DI agentų darbą lygiagrečiai, nepažeidžiant kodo bazės. Kiekviena funkcija traktuojama kaip darbo eiga, naudojant izoliuotas „Git“ darbo medžių (angl. worktrees) kopijas, kad pakeitimai būtų išbandyti ir peržiūrėti dar prieš jiems patenkant į pagrindinę šaką.

Žvelgiant plačiau pramonės mastu, „Zenflow“ atstovauja perėjimą prie „kelių agentų“ sistemų. Šiame modelyje vienas agentas gali rašyti specifikaciją, kitas įgyvendinti kodą, o trečias atlikti kryžminę agentų kodo peržiūrą. Ši patikros ir pusiausvyros sistema imituoja aukštos kvalifikacijos žmonių inžinerinę komandą. Vartotojui tai reiškia atsparų kūrimo ciklą, kuriame nepavykę testai sukelia automatinius pataisymus, o kodas „išleidžiamas“ tik praėjus pro visus verifikacijos vartus.

Tylus skaitmeninio raštingumo pokytis

Perėjimas nuo programavimo pagal nuojautą prie specifikacijomis grįsto kūrimo atskleidžia gilų mūsų santykio su programine įranga pokytį. Mes suprantame, kad DI „magija“ yra efektyviausia tada, kai ją nukreipia žmogaus ketinimai. Kaip netvarkingą spintą lengva užpildyti, bet neįmanoma joje susiorientuoti, taip nestruktūrizuotą kodo bazę lengva sugeneruoti, bet neįmanoma prižiūrėti.

Galiausiai tokių įrankių kaip „Kiro“, „Spec Kit“, „Tessl“ ir „Zenflow“ atsiradimas rodo, kad programavimo ateitis yra ne techninio griežtumo išnykimas, o jo evoliucija. Mes tolstame nuo „vienišo hakerio“ eros ir judame link „techninio architekto“ eros. Šiame naujame pasaulyje mūsų, kaip žmonių, vertė slypi ne gebėjime prisiminti sintaksę, o gebėjime apibrėžti aiškias, etiškas ir efektyvias specifikacijas mašinoms, kurios kuria mūsų pasaulį.

Stebėdami šiuos pokyčius, turėtume į savo skaitmeninius įrankius žiūrėti dar atidžiau. Kitą kartą, kai programėlės atnaujinimas atrodys išpūstas ar nepatogus, paklauskite savęs: ar tai buvo sukurta pagal specifikaciją, ar tai buvo tik nuojauta? Programinės įrangos kontrolės susigrąžinimas prasideda nuo reikalavimo užtikrinti aiškumą, kurį gali suteikti tik gerai parašyta specifikacija.

Šaltiniai

• AWS Documentation: Kiro Agent and EARS Notation Standards (2025-2026).
• Microsoft Open Source: Spec Kit Repository and 'Version Control for Thinking' by Den Delimarsky.
• Thoughtworks Technology Radar: 'The Three Levels of Spec-Driven Development' by Birgitta Böckeler.
• Tessl Official Registry: Tile and Skill Documentation for AI Agents.
• Zencoder Engineering Blog: Zenflow Orchestration and Verification Gate Mechanics.