Programmēšanas beigas pēc izjūtām! Lai dzīvo SDD!

Pirms dažiem mēnešiem izstrādātāju kopienu pārņēma jauna parādība: "vibe coding" jeb programmēšana pēc izjūtām. Pieņēmums bija apreibinoši vienkāršs — jums nebija vajadzīgs plāns, blokshēma vai pat dziļa sintakses izpratne; jums vienkārši vajadzēja aprakstīt sajūtu AI aģentam un vērot, kā kods materializējas. Tas šķita kā maģija, līdz parādījās pirmā lielā kļūda. Pēkšņi šī nemanāmā pieredze pārvērtās izmisīgā cilpā "izlabo šo" un "tagad tas salūza", atstājot izstrādātāju iesprostotu sarunā ar mašīnu, kas bija pazaudējusi pavedienu.

Vēsturiski mēs pavadījām mēnešus, slīpējot izsmeļošus prasību dokumentus, pirms tika uzrakstīta kaut viena koda rindiņa — stingrs process, kas bieži slāpēja inovācijas; šodien mēs bieži izlaižam kodu, pirms vēl esam izlēmuši, ko produktam ir paredzēts darīt — haotisks ieradums, kas rada milzīgu tehnisko parādu. Šī spriedze ir radījusi jaunu paradigmu: specifikāciju vadītu izstrādi (SDD — spec-driven development). Tas ir pragmatisks vidusceļš, kas izstrādāts, lai dotu AI aģentiem nepieciešamās vadlīnijas, neatgriežoties pie 90. gadu uzpūstajām "ūdenskrituma" metodēm.

Nodoma līgums

Būtībā specifikāciju vadīta izstrāde ir saistīta ar "patiesības avota" izveidi, ko var lasīt gan cilvēki, gan mašīnas. Dens Delimarskis no Microsoft apraksta specifikāciju kā "jūsu domāšanas versiju kontroli", un praksē tā darbojas kā saistošs līgums. Tā vietā, lai ekrānā mestu neskaidras uzvednes un cerētu uz labāko, izstrādātājs uzraksta kodolīgu, strukturētu dokumentu, kas precīzi definē, kā kodam būtu jāuzvedas.

Tehniski runājot, šī pāreja atrisina "konteksta dreifa" problēmu. AI aģenti ir izcili izpildē, taču tie mēdz aizmirst funkcijas būtību pēc piecdesmit pārskatīšanas kārtām. Nostiprinot izstrādes procesu specifikācijā, mēs nodrošinām, ka AI joprojām ir palīgs, nevis neprognozējams spēks. Birgita Bekelere no Thoughtworks identificē trīs šīs evolūcijas līmeņus: vispirms specifikācija (spec-first), kur plāns ir pirms koda; nostiprināta specifikācija (spec-anchored), kur dokuments turpina dzīvot, lai vadītu uzturēšanu; un mērķtiecīgā specifikācija kā avots (spec-as-source), kur cilvēks pieskaras tikai specifikācijai, bet pamata kods pilnībā paliek "zem pārsega".

Kiro: Arhitekta CLI

Kiro, ko izstrādājusi mērķtiecīga komanda AWS ietvaros, ir stabils rīks, kas pret programmatūras izstrādi izturas kā pret inženierzinātņu disciplīnu, nevis minēšanas spēli. Tas piedāvā gan IDE, gan CLI, taču tā reālais spēks slēpjas strukturētās Markdown prasībās. Kiro izmanto EARS (Easy Approach to Requirements Syntax) — notāciju, kas spiež panākt skaidrību, izmantojot vienkāršu paraugu: KAD [nosacījums], SISTĒMAI IR [uzvedība].

Raugoties no lietotāja skatpunkta, EARS prasību rakstīšana šķiet mazāk kā "programmēšana" un vairāk kā loģikas kartēšana. Šī struktūra ļauj Kiro ģenerēt uz īpašībām balstītus testus, kas ir daudz visaptverošāki nekā standarta vienību testi, notverot malas gadījumus, kurus cilvēks-programmētājs vai "izjūtu vadīts" AI, visticamāk, nepamanītu. Turklāt Kiro ievieš "stūrēšanas" failu koncepciju. Šie dokumenti — product.md, tech.md un structure.md — darbojas kā projekta neredzamā infrastruktūra, nodrošinot, ka katra ģenerētā koda daļa ievēro izvēlēto tehnoloģiju steku un arhitektūras konvencijas.

Spec Kit: Aģentu darba plūsmas standartizēšana

Microsoft Spec Kit izmanto citu pieeju, darbojoties kā atvērtā pirmkoda tilts starp trīsdesmit dažādiem programmēšanas aģentiem un strukturētu četru fāžu procesu. Kamēr programmēšana pēc izjūtām šķiet kā nestrukturēta prāta vētra, Spec Kit šķiet kā profesionāla darbnīca. Tas ievieš slīpsvītras komandu kopumu — piemēram, /speckit.plan un /speckit.analyze —, kas spiež aģentu apstāties un padomāt, pirms tas sāk rakstīt.

Paradoksāli, pievienojot šos "berzes punktus", Spec Kit faktiski paātrina izstrādi. Tas novērš "halucināciju cilpas", kurās aģents mēģina izlabot kļūdu, ieviešot jaunu, sarežģītāku kļūdu. Neatkarīgi no tā, vai veidojat jaunu projektu no nulles vai mēģināt atšķetināt fragmentētu mantoto kodu bāzi, Spec Kit nodrošina projekta "konstitūciju". Tas pārvieto cilvēku-izstrādātāju no mašīnrakstītāja lomas uz recenzenta lomu, koncentrējoties uz augsta līmeņa loģiku, kamēr aģents tiek galā ar smagnējām ieviešanas detaļām.

Tessl un prasmju reģistrs

Tessl ievieš aizraujošu slāni SDD ekosistēmā: pakotņu reģistru. Ja mēs domājam par kodu kā par recepti, Tessl nodrošina standartizētas sastāvdaļas un gatavošanas tehnikas, izmantojot savas "flīzes" (tiles). Šīs flīzes satur procedūru darba plūsmas (prasmes), obligātos kodēšanas standartus (noteikumus) un dokumentāciju, ko aģenti var pieprasīt pēc pieprasījuma.

Ikdienas izteiksmē Tessl lietošana ir kā AI aģentam izsniegta bibliotēkas karte un mājas noteikumu kopums. Instalējot Tessl SDD flīzi un vienkārši mudinot aģentu "izmantot specifikāciju vadītu izstrādi", darba plūsma mainās. Aģents pārstāj darboties kā padevīgs automātiskais pabeidzējs un sāk rīkoties kā jaunākais inženieris, kurš uzdod precizējošus jautājumus un sagatavo plānu pirms pieskaršanās repozitorijam. Šī caurskatāmība ir vitāli svarīga; tā pārvērš necaurredzamo AI ģenerēšanas "melno kasti" redzamā, auditējamā procesā.

Zenflow: Orķestrēšana ar verifikāciju

Ja citi rīki koncentrējas uz "ko" un "kā", Zenflow koncentrējas uz "kurš" un "kur". Zenflow, ko izstrādājusi Zencoder komanda, darbojas kā orķestrēšanas slānis, koordinējot vairākus AI aģentus darbam paralēli, nesabojājot koda bāzi. Tas uztver katru funkciju kā darba plūsmu, izmantojot izolētus Git darba kokus (worktrees), lai nodrošinātu, ka izmaiņas tiek pārbaudītas un pārskatītas, pirms tās nonāk galvenajā zarā.

Raugoties no nozares līmeņa, Zenflow pārstāv virzību uz "vairāku aģentu" sistēmām. Šajā modelī viens aģents varētu rakstīt specifikāciju, otrs ieviest kodu, bet trešais veikt starpaģentu koda pārskatīšanu. Šī pārbaužu un līdzsvara sistēma atdarina augsti kvalificētu cilvēku inženieru komandu. Lietotājam rezultāts ir noturīgs izstrādes cikls, kurā neveiksmīgi testi izraisa automātiskus labojumus, un kods tiek "izlaists" tikai tad, kad tas ir izgājis cauri katram verifikācijas posmam.

Klusā maiņa digitālajā pratībā

Pāreja no programmēšanas pēc izjūtām uz specifikāciju vadītu izstrādi atklāj pamatīgas pārmaiņas mūsu attiecībās ar programmatūru. Mēs saprotam, ka AI "maģija" ir visefektīvākā tad, ja to vada cilvēka nodoms. Tāpat kā nekārtīgu skapi ir viegli piepildīt, bet tajā nav iespējams orientēties, nestrukturētu koda bāzi ir viegli ģenerēt, bet nav iespējams uzturēt.

Galu galā tādu rīku kā Kiro, Spec Kit, Tessl un Zenflow uzplaukums liecina, ka programmēšanas nākotne nav saistīta ar tehniskās stingrības izzušanu, bet gan ar tās evolūciju. Mēs attālināmies no "vientuļā hakera" ēras un dodamies "tehniskā arhitekta" ēras virzienā. Šajā jaunajā pasaulē mūsu kā cilvēku vērtība nav rodama spējā atcerēties sintaksi, bet gan spējā definēt skaidras, ētiskas un efektīvas specifikācijas mašīnām, kas būvē mūsu pasauli.

Navigējot šajās pārmaiņās, mums būtu jāraugās uz saviem digitālajiem rīkiem ar vērīgāku aci. Nākamreiz, kad lietotnes atjauninājums šķiet uzpūsts vai neveikls, pajautājiet sev: vai tas tika izveidots ar specifikāciju, vai tās bija tikai izjūtas? Kontroles atgūšana pār mūsu programmatūru sākas ar prasību pēc skaidrības, ko var sniegt tikai labi uzrakstīta specifikācija.

Avoti

• 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.