Poniższe notatki powstały na podstawie transmisji na żywo „AI Coding with Friends | Meet Kiro” prowadzonej przez Darko (Developer Advocate) z gościem Nathan’em (Software Manager w Amazon). Wszystkie przedstawione przemyślenia, obserwacje i doświadczenia pochodzą bezpośrednio od uczestników rozmowy.

TL;DR

Spec-driven development zastępuje chaotyczne „vibe coding” – struktura zamiast improwizacji
Trzy fazy rozwoju: Requirements → Design → Tasks zapewniają kontrolę nad procesem
Vibe mode służy eksploracji, Spec mode to ciężka robota przy budowaniu funkcji
Steering docs i agentic hooks umożliwiają personalizację przepływu pracy
Społeczność aktywnie wpływa na rozwój – ponad 810 zgłoszeń na GitHub w tydzień
Praktyczne zastosowania – od gier przez narzędzia po automatyzację domową
Amazon używa własnego produktu – duża część Kiro została zbudowana w Kiro

Problem tradycyjnego programowania z AI

Nathan wyjaśnia podstawowe wyzwanie współczesnych narzędzi AI. Vibe coding okazał się skuteczny w generowaniu kodu, jednak prowadził do utraty kontroli nad procesem. Programiści przestawali rozumieć, co system tworzy, a powrót do poprzednich stanów stawał się problematyczny.

Spec-driven development wprowadza strukturalne podejście do tej kwestii. Nathan podkreśla, że programowanie to fundamentalnie komunikacja między inżynierami w języku zrozumiałym dla komputera. Kiro zostało zaprojektowane z myślą o odzwierciedleniu tej filozofii współpracy.

Kluczowy kontekst stanowi kultura AWS. Nathan wyjaśnia, że Amazon stosuje „Doc driven culture” – przed rozpoczęciem jakichkolwiek prac zespoły przygotowują obszerne dokumenty, aby dokładnie zrozumieć problem. Kiro przenosi tę filozofię do współpracy z AI.

System umożliwia skupienie na problemie do rozwiązania zamiast na mechanice implementacji. Nathan porównuje to rozwiązanie do SQL – programiści nie martwią się szczegółami implementacji, lecz podają instrukcje określające pożądany rezultat.

Ewolucja podejścia – od test-driven do spec-driven

Nathan ujawnia historię rozwoju koncepcji. Początkowo zespół próbował zastosować test-driven development – planowali generować wszystkie testy z góry, aby kierować implementacją LLM. Takie podejście okazało się jednak zbyt sztywne i wykluczające z dyskusji osoby nietechniczne.

Obecne spec-driven development charakteryzuje się większą otwartością. Nathan zauważa, że gdy pierwszym artefaktem są testy jednostkowe, znacznie ogranicza to krąg osób mogących współpracować. Requirements w języku naturalnym pozwalają włączyć interesariuszy, zespół produktowy, projektantów i klientów do pierwszych faz projektu.

Trzy filary strukturalnego rozwoju

Requirements – co chcemy zbudować

Darko demonstruje proces na przykładzie aplikacji wiersza poleceń do transkrypcji video napisanej w Rust. Kluczowe było ograniczenie zakresu: „Chcę aplikację wiersza poleceń w Rust. Powinna używać Amazon Transcribe do tworzenia transkrypcji z wideo. To wszystko. Bez implementacji logowania, autoryzacji czy plików konfiguracyjnych.”

Kiro automatycznie strukturyzuje wymagania w formacie EARS (Easy Approach to Requirements Syntax) – standardzie, który LLM-y dobrze rozumieją. Pierwszym krokiem są historie użytkownika w formacie: „Jako użytkownik chcę…”. System oferuje przycisk „refine”, który pomoże przekształcić ręcznie napisane wymagania w ustandaryzowany format EARS.

Requirements doc może być współdzielony z różnymi zespołami – produktowym, projektowym, klientami. Nathan podkreśla dostępność tej fazy dla wszystkich, nie tylko programistów.

Design – jak to zrobimy

Druga faza obejmuje techniczne projektowanie rozwiązania. Nathan wyjaśnia, że design doc powstaje po zaakceptowaniu wymagań i zawiera konkretne komponenty, struktury danych oraz architekturę.

Darko szczególnie ceni tę fazę za zachowanie kontroli – może sprawdzić, czy rozumie proponowane zmiany przed implementacją. System nie wprowadza niczego zaskakującego.

Tasks – podział na wykonalne części

Ostatnia faza dzieli projekt na konkretne zadania. Każde zadanie otrzymuje pełen kontekst specyfikacji, jednak wykonuje tylko określoną część pracy. Nathan zauważa ewolucję podejścia – zespół optymalizuje informacje przekazywane systemowi dla każdego konkretnego zadania.

Darko pokazuje praktyczne szczegóły: zamiast klikać przyciski można napisać „uruchom moje zadania teraz”. Czasem system zatrzymuje się po kilku zadaniach – wtedy wystarczy napisać „proszę kontynuować”. Specyfikacje pozostają w repozytorium (domyślnie w .kiro-ignored), więc można je wersjonować i udostępniać.

Dlaczego aplikacja, a nie wtyczka?

Nathan wyjaśnia strategiczną decyzję zespołu. Debata między wtyczką a aplikacją trwała długo. Kiro to fork VS Code (open source), jednak zespół potrzebował funkcji niemożliwych do zrealizowania jako rozszerzenie:

Notyfikacje systemowe (różne implementacje na Windows, Linux, Mac)
Agent hooks nasłuchujące zmian plików
Przekazywanie komunikatów między wątkami w aplikacji Electron
Elastyczność w szybko ewoluującym świecie agentic development

Nathan podkreśla zmianę stosunku „agent vs kod” z obecnych 10% agent / 90% kod w kierunku większej roli AI.

Praktyczne wyzwania i rozwiązania

Problemy z konfiguracją wymagające uwagi:

Shell integration musi być włączona (Command+Shift+P → „shell integration”) – to najczęstszy problem z zawieszającymi się komendami. Darko ostrzega przed zbyt złożonymi plikami .zshrc lub .bashrc.

Nathan przyznaje problemy zespołu z Power Level 10K i innymi skomplikowanymi konfiguracjami shell’a. Trwają prace nad wsparciem różnych wariantów terminali.

Obecne ograniczenia:

Linux updates – zespół jest świadomy problemów
Nie wszystkie rozszerzenia VS Code działają
Brak Microsoft Live Share
Limity użycia w wersji preview (generous quota, jednak ograniczona)

Działające funkcje: Autocomplete jest wbudowane, większość wtyczek działa, można instalować LSP dla różnych języków.

Vibe mode kontra Spec mode – kiedy używać którego

Nathan wyjaśnia kluczowe różnice między trybami:

Vibe mode – idealne do:

Eksploracji i ideacji
Debugowania i analizy błędów
Zadawania pytań o kod
Zrozumienia nieznanych technologii
Szybkich testów i prób

Spec mode – ciężka robota:

Budowanie nowych funkcji
Strukturalne zmiany w aplikacji
Długoterminowe projekty
Sytuacje wymagające kontroli procesu

Darko dzieli się praktyczną wskazówką: podczas zadawania pytań w vibe mode mówi systemowi „nie generuj kodu, tylko odpowiedz na pytanie” – dzięki temu unika niechcianej modyfikacji plików.

Praktyczne projekty – nauka przez budowanie

Nathan dzieli się projektami zbudowanymi w Kiro, które pokazują możliwości systemu przy nauce nowych technologii.

Gra 2048 powstała jako narzędzie edukacyjne dla jego dzieci (12, 13, 15 lat). Projekt ewoluował od pytania „co to TypeScript?” do implementacji zaawansowanych algorytmów. Nathan wykorzystał Kiro do zbudowania autosolve’a – systemu automatycznie rozwiązującego grę w celu zrozumienia strategii wygrywania.

Sky Defense to pionowo-przewijająca się strzelanka, która pozwoliła Nathan’owi poznać Phaser.js bez wcześniejszego doświadczenia. Mimo braku wiedzy o pixel arcie czy collision detection, używał Kiro do nauki przez praktykę. Projekt obejmował zaawansowane tematy jak asset pooling i optymalizację sprite’ów.

Szczególnie interesujący okazał się sprite debugger – bardzo specjalistyczne narzędzie do testowania arkuszy sprite’ów. Nathan przyznaje: „Nigdy nie poświęciłbym czasu na budowanie takiego narzędzia tradycyjnymi metodami”, jednak z Kiro mógł stworzyć precyzyjne rozwiązanie dla konkretnego problemu.

Zaawansowane funkcje – steering docs i hooks

Steering docs pozwalają nadać Kiro różne osobowości i zachowania. Nathan przyznaje, że lubi używać tej funkcji do zabawy – może kazać systemowi mówić jak postać z gry. Funkcja działa per-projekt (nie ma globalnych ustawień), jednak specyfikacje można kopiować między projektami.

Agentic hooks oferują automatyzację przepływu pracy. Darko wspomina o potężnej kombinacji z MCP servers (Model Context Protocol) – sam używa home assistant MCP server. Przykłady z społeczności:

Automatyczne aktualizacje JIRA po commitach
Migracje bazy danych po zmianach
Integracja z home assistant (Nathan ma hook włączający zielone światło po commicie)
Generowanie commit messages z opisem zmian i oryginalnym promptem

Nathan dzieli się praktyczną wskazówką: można skonfigurować przepływ pracy „za każdym razem gdy wprowadzisz zmianę, zatwierdź ją w każdym obrocie” z automatycznymi, informacyjnymi commit messages zawierającymi nawet użyty prompt.

Możliwości łączenia MCP serwerów z hooks otwierają nieograniczone możliwości automatyzacji – od zarządzania projektami po kontrolę urządzeń domowych.

Społeczność napędza rozwój

Zespół Amazon został zaskoczony skalą przyjęcia. Nathan przyznaje, że liczba użytkowników przekroczyła wszystkie oczekiwania. W tydzień od premiery społeczność zgłosiła ponad 810 zgłoszeń na GitHub (Darko wspomina, że kilka dni wcześniej było 435, więc liczba rośnie błyskawicznie).

Skala zaangażowania obejmuje: Ponad 1000 osób na transmisji na żywo, aktywny Discord, szybki wzrost obserwujących na Twitch z 150 rano do znacznie większej liczby wieczorem.

Nathan ujawnia intensywną pracę zespołu nad wydajnością – wydajność pamięci podręcznej poprawiła się dramatycznie, natomiast obciążenie systemów wspierających modele zostało zoptymalizowane. Druga wersja jest już w przygotowaniu, skupiona na usunięciu limitów użycia.

Opinie użytkowników bezpośrednio wpływają na rozwój produktu. Funkcja notyfikacji powstała w jeden dzień dzięki zgłoszeniu społeczności – użytkownicy chcieli wiedzieć, kiedy Kiro potrzebuje ich uwagi podczas długich operacji. Wyzwanie techniczne okazało się znaczne – aplikacja Electron wymaga przekazywania komunikatów między wątkami, a każda platforma implementuje notyfikacje inaczej.

Darko podkreśla wagę Discord – to główne miejsce wymiany doświadczeń i najlepszych praktyk.

Checklist: Jak zacząć ze spec-driven development

Przed pierwszym projektem:

[ ] Włącz shell integration (Command+Shift+P → „shell integration”)
[ ] Dołącz do Discord społeczności (discord.gg/curo.dev)
[ ] Przeczytaj FAQ na curo.dev
[ ] Sprawdź czy masz aktualną wersję (uwaga na limity w preview)

Tworzenie pierwszego spec’a:

[ ] Zacznij od prostego, konkretnego problemu (nie całej aplikacji)
[ ] Opisz wymagania w 1-2 zdaniach
[ ] Pozwól Kiro wygenerować Requirements doc
[ ] Przejrzyj i zatwierdź Design doc przed przejściem do Tasks
[ ] Wykonuj zadania pojedynczo, nie wszystkie naraz

Najlepsze praktyki podczas pracy:

[ ] Używaj vibe mode do pytań i eksploracji, spec mode do budowania funkcji
[ ] Działaj granularnie – jedna specyfikacja dla jednej, małej funkcji
[ ] Weryfikuj każdy krok – przeglądaj dokumenty wymagań i projektu przed implementacją
[ ] Używaj Kiro do nauki nowych technologii przez budowanie małych projektów
[ ] Zadawaj pytania o wszystko, co niezrozumiałe w kodzie lub procesie
[ ] Twórz steering docs dla powtarzalnych przepływów pracy
[ ] Rób backup postępów w plikach build_[data].md

Wskazówki od praktyków

Nathan dzieli się trzema najważniejszymi radami:

Personalizuj Kiro przez steering files – nadaj systemowi różne osobowości, czyni kodowanie bardziej przyjemnym

Pytaj o wszystko – Nathan podkreśla: „Kiro rozumie własne funkcje” – system wyjaśni jak konfigurować hooks, steering docs, MCP czy inne zaawansowane funkcje.

Eksploruj bez ograniczeń – buduj mikronarządzia dla konkretnych problemów, nie ograniczaj się do standardowych zastosowań. Darko zachęca do publikowania specyfikacji w repozytoriach, żeby inni mogli iterować i uczyć się.

Darko dodaje własną praktykę – na koniec każdej sesji prosi o podsumowanie w pliku build_[data].md. „Z mojego doświadczenia, potrzebuję czuć się pewnie swojego kodu” – wyjaśnia, dlaczego ta dokumentacja jest dla niego kluczowa.

Biblioteka promptów – sprawdzone wzorce od praktyków

Na podstawie transmisji Nathan i Darko podzielili się konkretnymi promptami sprawdzającymi się w codziennej pracy:

Vibe mode – eksploracja bez modyfikacji kodu

"Nie generuj kodu, tylko odpowiedz na pytanie"

Kiedy stosować: Gdy chcesz zrozumieć kod, zadać pytanie o implementację lub poznać nową technologię bez ryzyka niechcianych zmian w plikach.

Automatyzacja przepływu pracy przez steering docs

"Za każdym razem gdy wprowadzisz zmianę, zatwierdź ją w każdym obrocie. Za każdym razem gdy dam ci prompt, podsumuj zmiany które wprowadziłeś, stwórz informacyjną wiadomość commit i chcę żebyś uwzględnił prompt który ci wysłałem jako część wiadomości commit."

Kiedy stosować: Do automatycznego dokumentowania procesu rozwoju i tworzenia szczegółowej historii zmian.

Kontrola wykonania zadań

"Uruchom moje zadania teraz"
"Proszę kontynuować"

Kiedy stosować: Alternatywa dla klikania przycisków. Pierwszy prompt zamiast „Run Task”, drugi gdy system zatrzymuje się po kilku zadaniach.

Dokumentacja sesji programistycznej

"Wszystko co zrobiliśmy dzisiaj, daj mi podsumowanie. I w pliku build_[aktualna_data].md"

Kiedy stosować: Na koniec każdej sesji kodowania do stworzenia archiwum postępów i ułatwienia przyszłego zrozumienia zmian.

Modyfikacja wymagań w trakcie rozwoju

"Mam nowe wymaganie. Nie pomyślałem o tym [opis nowego wymagania]"

Kiedy stosować: Gdy w trakcie projektowania odkryjesz edge case lub dodatkową funkcjonalność. System zaktualizuje wszystkie trzy fazy (Requirements, Design, Tasks).

Kontrola eksploracji bez modyfikacji kodu

"Hej, nie generuj żadnego kodu, tylko odpowiedz na moje pytanie. Porozmawiajmy o tym."

Kiedy stosować: Alternatywa dla podstawowego promptu Darko. Użyj gdy chcesz dogłębnie przeanalizować problem lub skonsultować podejście bez ryzyka modyfikacji plików.

Minimalna funkcjonalność (MVP)

"Chcę aplikację wiersza poleceń w Rust. Powinna używać Amazon Transcribe do tworzenia transkrypcji z wideo. To wszystko. Bez implementacji logowania, autoryzacji czy plików konfiguracyjnych."

Kiedy stosować: Na samym początku projektu. Pozwala stworzyć absolutne minimum funkcjonalności – „szkielet”, na którym można budować kolejne elementy.

Rozbudowa istniejącej funkcjonalności

"Chcę nową funkcję, która zaimplementuje plik konfiguracyjny dla mojej aplikacji. W pliku chcę przechowywać nazwę bucketa S3."

Kiedy stosować: Gdy masz już działającą bazę i chcesz dodać kolejny, dobrze zdefiniowany element. To serce pracy w trybie Spec-Driven – dodawanie jednej rzeczy naraz.

Prompt na naukę przez budowanie

"Zaimplementuj dla mnie auto-solver do gry 2048."

Kiedy stosować: Gdy chcesz, aby AI zbudowało coś złożonego, abyś mógł przeanalizować kod i nauczyć się, jak działają konkretne algorytmy lub technologie.

Kiedy Kiro buduje Kiro

Nathan ujawnia, że duża część Kiro została zbudowana przy użyciu Kiro. Gdy zespół zaczął używać własnego produktu do rozwoju, wiedzieli że są na dobrej drodze.

Przykład funkcji notyfikacji pokazuje potęgę spec-driven development – skomplikowana implementacja dla różnych platform (Windows, Linux, Mac) została zrealizowana w jeden dzień dzięki strukturalnemu podejściu.

Kluczowy insight

Ucz się, budując jednorazowe narzędzia

Standardowo myślimy: Aby nauczyć się nowej technologii, trzeba przeczytać dokumentację, przejść kursy i zbudować projekt z tutoriala.

W praktyce okazuje się, że: Szybszą i głębszą naukę osiąga się, używając AI do błyskawicznego zbudowania małego, jednorazowego narzędzia, które rozwiązuje JEDEN, konkretny problem, z którym właśnie się mierzysz.

Dlaczego to jest istotne: Zamiast uczyć się teorii w oderwaniu od rzeczywistości, od razu stosujesz ją w praktycznym, realnym kontekście. To zmienia naukę z pasywnego konsumowania wiedzy w aktywne rozwiązywanie problemów.

Test na jutro: Następnym razem gdy utkniesz przy nowej bibliotece lub frameworku, zamiast szukać kolejnego tutoriala, spróbuj poprosić Kiro o zbudowanie mini-narzędzia, które wizualizuje lub debuguje tylko ten jeden, problematyczny element. Sprawdź, czy zrozumienie problemu nie przyjdzie w ciągu minut, a nie godzin.

Ten wpis jest częścią kolekcji notatek z ciekawych podcastów, webinarów i innych treści, które uważam za wartościowe i do których wracam. Jeśli chcesz sprawdzić oryginalne źródło, znajdziesz je tutaj: AI Coding with Friends | Meet Kiro 👻

Tag: Aws

Kiro i spec-driven development – rewolucja w programowaniu z AI #EN233

DevOps w erze GenAI – rewolucja czy ewolucja? #EN133