Te notatki powstały na podstawie szczegółowej analizy i testów narzędzia Kiro przeprowadzonych przez Theo „Kiro: Amazon’s unexpected Cursor competitor„. Wszystkie przemyślenia, obserwacje i wnioski pochodzą od rozmówcy, który przetestował oba narzędzia w praktycznych scenariuszach.
TL;DR:
- Amazon wypuścił Kiro – rozwidlenie VS Code z AI jako konkurencję dla Cursor
- Narzędzie oferuje dwa tryby: kodowanie intuicyjne oraz rozwój kierowany specyfikacjami
- W praktycznych testach Kiro okazał się znacznie wolniejszy od Cursor
- Generuje ogromne ilości dokumentacji: 1652 linie vs 202 w Cursor dla identycznego zadania
- Wykorzystuje OpenVSX zamiast VS Code Marketplace ze względów prawnych
- System zaczepów automatyzuje zadania w tle
- Skierowany głównie do dużych, korporacyjnych zespołów
Amazon wchodzi na rynek programowania z AI
Amazon nieoczekiwanie wprowadził na rynek narzędzie Kiro jako alternatywę dla popularnych edytorów wspomaganych sztuczną inteligencją. Jak wyjaśnia autor analizy – były pracownik Twitcha należącego do Amazona – to nie jest przypadkowe rozwidlenie VS Code. Firma pracowała nad tym narzędziem od znacznego czasu, wykorzystując je wewnętrznie przed publicznym uruchomieniem.
Zainteresowanie produktem okazało się tak duże, że Amazon musiał wprowadzić listę oczekujących. W rezultacie ruch przytłoczył infrastrukturę Amazon Bedrock, co zmusiło firmę do czasowego ograniczenia dostępu.
Kiro pozycjonuje się jako „IDE agentyczne” do pracy od prototypu do produkcji. Jednak autor wskazuje na pewną sprzeczność – mimo marketingowego hasła o użyciu „od prototypu do produkcji”, wewnętrznie Amazon poleca narzędzie głównie do dużych, istniejących baz kodu.
Filozofia dwóch światów programowania
Kiro wprowadza dwa różne podejścia do tworzenia oprogramowania. Pierwszy to kodowanie intuicyjne – szybkie prototypowanie przez bezpośrednie polecenia do AI, podobne do rozwiązań takich jak Cursor. Z kolei drugi to rozwój kierowany specyfikacjami, który łączy klasyczne podejście Amazon z programowaniem kierowanym testami.
Przepływ pracy oparty na specyfikacjach składa się z trzech etapów. Na początku AI przekształca pojedyncze polecenie w szczegółowe historie użytkownika z kryteriami akceptacji. Następnie na podstawie wymagań tworzy projekt techniczny zawierający diagramy przepływu danych, interfejsy TypeScript oraz schematy bazy danych. W końcu generuje zadania i podzadania wraz z testami jednostkowymi, integracjami oraz wymaganiami dostępności.
Praktyczne porównanie: drastyczne różnice w podejściu
Autor przeprowadził identyczny test w obu narzędziach, optymalizując system testów porównawczych. Zadanie polegało na sprawdzaniu, które testy zostały już uruchomione, aby pomijać je w kolejnych przebiegach.
Cursor rozwiązał problem w 15 sekund. Narzędzie stworzyło plan, wykonało go oraz dostarczyło działający kod. Finalny rezultat obejmował 202 dodane linie i 16 usuniętych, przy czym kod dostosował się do istniejącego stylu.
Kiro potrzebował kilku minut na wykonanie tego samego zadania. Proces rozpoczął od tworzenia wymagań specyfikacji, następnie przeszedł do dokumentu projektu, a na koniec wygenerował 137 linii zadań. Ostateczny rezultat wyniósł 1652 dodane linie, z których większość stanowiła dokumentacja. Dodatkowo narzędzie narzuciło własną architekturę z interfejsami i klasami.
Jak zauważa autor po przejrzeniu wygenerowanego kodu: „Wujek Bob musi być teraz bardzo szczęśliwy” – ironiczny komentarz odnoszący się do promowania nadmiernej abstrakcji i złożoności w imię „czystego kodu”.
„137 linii zadań dla funkcji sprawdzającej istnienie pliku przed uruchomieniem testu” – tak autor podsumowuje różnicę w filozofii obu rozwiązań.
Reakcja zespołu była jednoznaczna. Menedżer kanału skomentował: „Nie pobieram niczego, co tworzy historie użytkownika”. Autor zauważa, że to pokazuje przepaść między światem korporacyjnym a codziennym programowaniem.
Ograniczenia techniczne i problemy wydajnościowe
W testach z dużymi bazami kodu Kiro wypadł gorzej niż konkurencja. Podczas analizy bazy kodu React narzędzie wciąż szukało odpowiedzi, gdy inne rozwiązania już dawno zakończyły pracę. Dla porównania autor wspomina o Augment Code, który radzi sobie doskonale z gigantycznymi kontekstami.
Dodatkowo zauważono kilka błędów interfejsu – niepracujące przyciski, problemy z nawigacją oraz brak podstawowych funkcji takich jak kopiowanie poleceń.
Istotnym ograniczeniem jest używanie OpenVSX zamiast oficjalnego VS Code Marketplace. Jak wyjaśnia autor, Amazon jako duża korporacja nie może sobie pozwolić na ryzyko procesu sądowego ze strony Microsoft, dlatego musi korzystać z alternatywy o otwartym kodzie źródłowym. W konsekwencji dostęp do rozszerzeń jest ograniczony.
System punktów zaczepienia i automatyzacja procesów
Kiro wprowadza system punktów zaczepienia – automatyzacji uruchamianych przy określonych zdarzeniach. Przykłady obejmują automatyczne aktualizowanie plików testów przy zapisie komponentu React, odświeżanie dokumentacji w README przy modyfikacji punktów końcowych API, skanowanie kodu w poszukiwaniu wyciekniętych danych uwierzytelniających przed zatwierdzeniem zmian, oraz sprawdzanie zgodności z zasadą pojedynczej odpowiedzialności przy dodaniu nowego komponentu.
Autor ma jednak mieszane uczucia co do funkcji bezpieczeństwa. Jego zdaniem fakt, że wyciekanie danych uwierzytelniających w kodzie źródłowym wciąż stanowi problem, jest żałosny.
Analiza kodu źródłowego ujawnia korporacyjną naturę
Mimo że Kiro nie ma otwartego kodu źródłowego, Geoffrey Huntley zdołał wyodrębnić kod z pakietu i przeprowadził szczegółową analizę. Jego odkrycia potwierdzają korporacyjny charakter narzędzia.
Po pierwsze, polecenia systemowe są znacznie większe niż w typowych narzędziach AI, co wyjaśnia skomplikowany przepływ pracy. Po drugie, narzędzie używa Cloud Sonnet 4, mimo że interfejs sugeruje dostęp do różnych modeli. Wreszcie Amazon stworzył oddzielne szablony zoptymalizowane pod każdy model AI.
Jak zauważa autor po analizie kodu, „pięć funkcji tam, gdzie jedna by wystarczyła, to właściwie argument sprzedażowy dla automatycznych koderów”. To odzwierciedla myślenie korporacyjne, gdzie złożoność często postrzegana jest jako wartość dodana.
Identyfikacja grupy docelowej
Analiza wskazuje, że Kiro próbuje przekształcić każdą bazę kodu w strukturę podobną do tej stosowanej w Amazon. Takie podejście może mieć sens dla zespołów już pracujących z ciężkimi procesami, szczegółowymi specyfikacjami oraz metodologią korporacyjną. Autor dostrzega szczególną niszę dla narzędzia w dużych organizacjach, które już pracują w oparciu o sformalizowane procesy – na przykład zespoły używające skomplikowanych bibliotek takich jak Effect w TypeScript, gdzie zgodność z architekturą i automatyczne generowanie dokumentacji mogą być postrzegane jako kluczowe zalety.
Autor dostrzega potencjał w sytuacjach obejmujących duże zespoły wymagające jednolitych standardów, potrzebę szczegółowej dokumentacji dla każdej zmiany, oraz pracę z kompleksowymi bazami kodu podobnymi do tych w Effect czy podobnych frameworkach.
Jednak końcowa ocena jest sceptyczna. Narzędzie znajduje się w dziwnym miejscu spektrum między kodowaniem intuicyjnym a rozwojem ukierunkowanym na produkcję.
Dodatkowe problemy obejmują pozostawione błędy typów w wygenerowanym kodzie, brak testowania czy kod w ogóle działa po wygenerowaniu, dodawanie niechcianych funkcjonalności oraz narzucanie własnych konwencji zamiast dostosowywania się do istniejącego stylu.
Checklist: ocena przydatności dla zespołu
✅ Kiro może pasować, jeśli:
- [ ] Zespół liczy więcej niż 10 programistów
- [ ] Już używacie szczegółowych specyfikacji i dokumentacji
- [ ] Macie czas na naukę nowego narzędzia
- [ ] Priorytetem jest spójność kodu nad szybkością
- [ ] Potrzebujesz ścieżki audytu dla każdej zmiany
❌ Zostań przy alternatywach, jeśli:
- [ ] Zespół to mniej niż 5 osób
- [ ] Priorytetem są szybkie iteracje i prototypy
- [ ] Nie lubisz, gdy narzędzie narzuca sposób pracy
- [ ] Wolisz minimalistyczne podejście do dokumentacji
Przyszłość korporacyjnego programowania z AI
Kiro przedstawia alternatywę dla popularnego podejścia szybkiego prototypowania. Zamiast najpierw budować a potem dokumentować, promuje odwrotny proces – najpierw specyfikacja, następnie kod.
Takie podejście może być przyszłością dla dużych organizacji potrzebujących kontroli, dokumentacji oraz ustalonych procesów. Jednak jak pokazuje praktyczny test, wiąże się to z kosztem zarówno czasowym, jak i zwiększoną złożonością kodu.
Praktyczne polecenia i ich zastosowanie
Autor przetestował Kiro trzema różnymi poleceniami, każde w innym kontekście:
Analiza istniejącego kodu: Polecenie dotyczące zrozumienia implementacji useEffect najlepiej sprawdza się przy eksploracji nieznanych fragmentów w dużych bazach kodu oraz podczas wprowadzania do nowego projektu. Kiro długo szukał odpowiedzi, podczas gdy Augment Code szybko znalazł odpowiedni element.
Optymalizacja procesów: Szczegółowe polecenie dotyczące poprawy systemu testów nadaje się do rozwiązywania konkretnych problemów oraz optymalizacji istniejących przepływów pracy. Cursor rozwiązał zadanie w 15 sekund, Kiro potrzebował kilku minut i wygenerował znacznie więcej kodu.
Nowe funkcjonalności: Polecenie „dodaj system recenzji” w trybie rozwoju kierowanego specyfikacjami sprawdza się gdy potrzebujesz pełnej dokumentacji od początku oraz w projektach wymagających procesów zatwierdzania.
Krótkie, konkretne polecenia działają lepiej w Cursor dla szybkich rezultatów. Z kolei długie, szczegółowe polecenia lepiej pasują do Kiro przy potrzebie korporacyjnego podejścia z pełną dokumentacją.
Kluczowy insight: odwrócenie kolejności rozwoju
Kod przed specyfikacją
Standardowe myślenie zakłada pisanie szczegółowych specyfikacji przed implementacją kodu, zgodnie z nauczaniem w korporacjach i metodykach zarządzania projektami.
Praktyka pokazuje jednak, że budowanie działającego prototypu przed zajmowaniem się specyfikacjami pozwala napisać lepszą i prostszą specyfikację. Autor zauważa, że nie wiadomo co naprawdę ma znaczenie, dopóki nie ma się działającej wersji.
Ma to istotne znaczenie, ponieważ specyfikacje pisane przed implementacją często rozwiązują nieistniejące problemy, ignorując te rzeczywiście trudne. Działający kod ujawnia prawdziwe wąskie gardła oraz przypadki brzegowe.
Test praktyczny: Przy planowaniu nowej funkcjonalności warto najpierw zbudować najprostszą działającą wersję i sprawdzić trafność założeń, zamiast zaczynać od szczegółowych wymagań.
Dodaj komentarz
Musisz się zalogować, aby móc dodać komentarz.