Kiro

Kiro ma sens wtedy, gdy problemem nie jest brak modelu AI, tylko chaos między pomysłem a działającą zmianą w produkcie. Oficjalna strona opisuje podejście spec-driven: prompt zamienia się w wymagania, projekt i sekwencję zadań, a potem agent realizuje kolejne kroki. To dobry kontrast do jednego wielkiego polecenia w edytorze. Dla osoby budującej produkt, stronę lub wewnętrzne narzędzie istotne jest, że można najpierw powiedzieć, co ma się wydarzyć dla użytkownika, a dopiero potem wybierać komponenty i pliki. Kiro nie usuwa odpowiedzialności za produkt. Wymusza tylko lepszy moment na podjęcie decyzji.

Pierwsza specyfikacja powinna być mała. Weź funkcję, której efekt potrafisz sprawdzić w kilka minut: zapis formularza, ekran statusu, eksport danych albo pojedynczą integrację. Opisz użytkownika, punkt startowy, oczekiwany rezultat, błędy i kryteria akceptacji. Następnie przeczytaj wygenerowane wymagania. Czy agent rozumie, kiedy funkcja ma działać, czego nie wolno robić i co jest sukcesem? Dopiero wtedy przejdź do projektu oraz zadań. Jeśli przeskoczysz ten etap, dostaniesz szybkie wykonanie błędnego założenia. To nadal jest strata czasu, nawet jeśli kod wygląda profesjonalnie.

W dokumentacji Kiro specs obejmują funkcje i bugfixy. Tryb funkcji prowadzi przez wymagania, design oraz implementację, a bugfix ma pomóc znaleźć przyczynę i uniknąć regresji. Materiały opisują też analizę wymagań oraz testy własnościowe, które sprawdzają zasady zachowania w wielu wariantach danych zamiast kilku ręcznie wybranych przykładów. Nie każdy projekt wymaga takiej głębokości. Przy prostej zmianie copy byłoby to przesadą. Przy płatności, uprawnieniach, imporcie danych lub automatyzacji warto jednak zadać pytanie: jaka reguła musi być prawdziwa niezależnie od wejścia? To lepsze pytanie niż „czy agent napisał test”.

Steering, skills i hooki są najbardziej użyteczne jako ograniczenia, nie jako magazyn luźnych promptów. W steeringu zapisz stack, katalogi, konwencje, komendy testowe, standard dostępności i granice zmian. Skill niech opisuje powtarzalny proces, na przykład dodanie endpointu albo weryfikację formularza. Hook może uruchomić kontrolę po określonym zdarzeniu. Każda automatyzacja powinna mieć jasny koszt i efekt. Jeśli hook spowalnia pracę, a nie łapie realnych błędów, usuń go z procesu. Dobry zestaw instrukcji jest krótki, aktualny i możliwy do sprawdzenia w kodzie.

Kiro może pracować jako IDE, CLI lub przez web. Oficjalne dokumenty opisują wspólną konfigurację projektu oraz możliwość pracy lokalnie, w chmurze i w CI. To jest wygodne, ale zwiększa znaczenie uprawnień. MCP podłączaj tylko do narzędzi potrzebnych w danym zadaniu. Nie przekazuj agentowi tokenów produkcyjnych tylko dlatego, że łatwiej mu będzie samodzielnie coś sprawdzić. Używaj oddzielnych środowisk testowych, minimalnych ról i plików wykluczających dla sekretów. Agent może działać szybko oraz szeroko, a błąd uprawnień jest zwykle kosztowniejszy niż kilka minut ręcznego testu.

Kiro ma model kredytowy. Oficjalny cennik wskazuje darmowy plan z 50 kredytami miesięcznie, plan Pro za 20 USD miesięcznie z 1000 kredytów oraz wyższe poziomy. Różne modele i typy zadań zużywają różną liczbę kredytów, a specyfikacje, zadania i hooki również mogą je konsumować. Przed zakupem wykonaj jeden pełny, powtarzalny scenariusz: wymagania, projekt, implementacja, testy, review i deploy na środowisko testowe. Zmierz liczbę poprawek, czas oraz koszt, nie liczbę wygenerowanych plików. Jeśli narzędzie nie poprawia przewidywalności procesu, większy pakiet kredytów nie rozwiąże problemu.