Standardy w repozytorium
Standardy gotowości, ukończenia, testów, bezpieczeństwa, przeglądu, kodowania i koordynacji mają jeden nadrzędny indeks. Test jednostkowy blokuje CI, jeśli standard zostanie dodany lub usunięty bez aktualizacji indeksu.
Tworzenie oprogramowania w Idego
AI-native cykl tworzenia
Sześć etapów. Wspólne kontrole. Decyzje ludzi.
Agenci piszą, testują i sprawdzają kod. Ludzie zatwierdzają zakres i scalają zmiany do main. Specyfikacje, kontrole i zasady pracy są częścią repozytorium projektu.
Czym jest AI-Native SDLC?
AI-native SDLC to proces tworzenia oprogramowania, w którym agenci wykonują zadania, a ludzie zarządzają pracą. Specyfikacje, testy, zasady przeglądu i zatwierdzenia są wersjonowane w repozytorium projektu.
Asystent AI pomaga w pojedynczych zadaniach. W procesie AI-native wszystkie zadania podlegają wspólnym, obowiązkowym kontrolom. Repozytorium zawiera zapis zmian, wyników kontroli i zatwierdzeń.
Tworzenie oprogramowania AI-native a wsparcie AI
Asystenci potrafią pisać testy i sprawdzać kod. Różnica polega na tym, czy zespół ma wspólny proces, który wymaga tych kroków.
| Obszar | Praca ze wsparciem AI | Proces AI-native |
|---|---|---|
| Gdzie zapisany jest proces | Może zależeć od indywidualnych nawyków i poleceń. | Wersjonowane standardy, specyfikacje i umiejętności agentów są w repozytorium. |
| Specyfikacja przed kodem | Specyfikacja może być opcjonalna lub poza procesem. | Przed kodem wymagana jest specyfikacja gotowa do wdrożenia. Udokumentowany wyjątek dotyczy tylko dokumentacji lub procesu. |
| Testy przed implementacją | Asystenci potrafią pisać testy, ale kolejność może nie być wymagana. | Każde zachowanie zaczyna się od nieprzechodzącego testu i wymaga macierzy przypadków brzegowych. |
| Automatyczny przegląd | Zakres przeglądu może zależeć od osoby i wybranych przez nią kontroli. | Czterech recenzentów sprawdza bezpieczeństwo, błędy, standardy i specyfikację oraz łatwość utrzymania. |
| Waga problemów i odroczenie napraw | Może brakować wspólnych zasad oceny wagi problemów i zapisu odroczonych napraw. | Problemy krytyczne i wysokiej wagi trzeba naprawić. Odroczenie naprawy problemów średniej i niskiej wagi wymaga pisemnego uzasadnienia w PR. |
| Limity powtórzeń | Ponowne próby mogą nie mieć wspólnego limitu ani zasad eskalacji. | Po drugiej nieudanej próbie pętla się zatrzymuje, a człowiek otrzymuje raport braków. |
| Zatwierdzenia przez ludzi | Zatwierdzenia mogą zależeć od indywidualnej praktyki. | Ludzie zatwierdzają zakres, wybierają zadania, potwierdzają commity i scalają do main. |
| Przenoszenie między narzędziami | Instrukcje mogą różnić się między narzędziami. | Te same umiejętności działają w Cursor, Claude Code i Codex. Kontrola sprawdza ich zgodność. |
| Śledzenie zmian po scaleniu | Powiązania wymagań, testów i decyzji mogą być niepełne. | Zadania są powiązane ze specyfikacjami, testami, PR i zarchiwizowanymi wymaganiami opisującymi dostarczony system. |
Jak Idego realizuje AI-Native SDLC
Każda zmiana przechodzi przez sześć etapów. Przejście do kolejnego wymaga pomyślnego wyniku kontroli. Realizacja pojedynczego zadania (/deliver-issue) obejmuje etapy od Rozpoczęcia do Archiwizacji. Przy realizacji kamienia milowego (/deliver-milestone) zadania są wykonywane w równoległych partiach, każde w osobnym katalogu roboczym. Ich PR są scalane do gałęzi integracyjnej, a następnie powstaje zbiorczy PR roboczy do main. Końcowe scalenie do main wykonuje człowiek.
Zakres
RezultatZadania i kamień milowy
Uzgadniamy jasny, sprawdzalny zakres przed rozpoczęciem realizacji.
- Wymagana kontrola
- Człowiek musi zatwierdzić listę zadań i ich zakres przed rozpoczęciem realizacji.
Szczegóły procesu
Po krótkiej rozmowie i analizie repozytorium dzielimy pomysł na zadania. Każde obejmuje działający fragment funkcji, mieści się w jednym PR i ma sprawdzalne kryteria akceptacji oraz określone zależności. Jeśli zadań jest co najmniej trzy, kamień milowy określa kolejność realizacji. Audyt bez zmian w kodzie może też prowadzić do utworzenia kamienia milowego z zadaniami usprawnień, priorytetami i etykietami.
- Rola agenta
- Analizuje kod, zadaje konkretne pytania, przygotowuje i publikuje zadania.
- Rola człowieka
- Odpowiada na pytania o zakres i zatwierdza listę zadań.
Rozpoczęcie
RezultatGałąź, PR roboczy i specyfikacja
Przygotowujemy specyfikację wybranego zadania gotową do implementacji.
- Wymagana kontrola
- Zadanie musi mieć jasny zakres i specyfikację gotową do wdrożenia. Wyjątkiem jest praca nad samą dokumentacją lub procesem, jeśli udokumentowana ocena pozwala na spec:skip.
Szczegóły procesu
Dla jednego zadania powstają gałąź gh-<n> i PR roboczy z Closes #<n>. Wyjaśniamy niejasności zakresu, a decyzje i terminy zapisujemy w dokumentacji. Zanim zacznie pisać kod, agent przygotowuje propozycję OpenSpec, projekt rozwiązania, scenariusze i zadania. Jeśli praca dotyczy wyłącznie dokumentacji lub procesu, może zamiast tego zapisać decyzję spec:skip.
- Rola agenta
- Tworzy gałąź, specyfikację i PR roboczy oraz dodaje etykiety.
- Rola człowieka
- Wybiera gałąź bazową i wyjaśnia niejasności zakresu.
Implementacja
RezultatKod, testy i wyniki kontroli
Wdrażamy po jednym zachowaniu, wraz z testami i wymaganymi kontrolami.
- Wymagana kontrola
- Wszystkie kontrole wstępne i końcowe muszą zakończyć się pomyślnie, a lista kontrolna PR musi odpowiadać wykonanej pracy.
Szczegóły procesu
Kontrole wstępne sprawdzają gotowość do pracy, specyfikację, granice architektury, bezpieczeństwo i dokumentację. Dopiero po nich jeden podagent przypisany do każdej grupy zadań zaczyna cykl TDD: test, który początkowo nie przechodzi, minimalny kod, refaktoryzacja. Macierz testów obejmuje przypadki puste, nieprawidłowe, graniczne, pierwszeństwo reguł, dziedziczenie, izolację i asymetrię. Kontrole końcowe obejmują lint, typy, testy jednostkowe i integracyjne, kompilację produkcyjną oraz każdy scenariusz specyfikacji.
- Rola agenta
- Pisze testy i kod, uruchamia kontrole i raportuje wyniki.
- Rola człowieka
- Rozwiązuje blokady zgłoszone przez agentów.
Zakończenie
RezultatRaport przeglądu i plan testów
Równolegle przeglądamy zmianę i rozwiązujemy problemy blokujące jej ukończenie.
- Wymagana kontrola
- Raport musi mieć status DONE, bez nierozwiązanych problemów krytycznych lub wysokiej wagi, z aktualną listą kontrolną i planem testów.
Szczegóły procesu
Pełna weryfikacja i przegląd wykonywany równolegle przez czterech recenzentów wskazują problemy i ich wagę. Problemy krytyczne i wysokiej wagi trzeba naprawić. Odroczenie naprawy problemów średniej i niskiej wagi wymaga pisemnego uzasadnienia w PR. Przegląd ma najwyżej dwie rundy. Jeśli po nich pozostają problemy krytyczne lub wysokiej wagi, praca otrzymuje status NOT DONE, a sprawa trafia do człowieka.
- Rola agenta
- Sprawdza pracę, naprawia problemy, uzasadnia odroczenie napraw i raportuje DONE lub NOT DONE.
- Rola człowieka
- Czyta raport i rozstrzyga problemy przekazane mu przez agentów.
Archiwizacja
RezultatAktualne specyfikacje systemu
Aktualizujemy bieżące specyfikacje, aby odpowiadały zweryfikowanemu kodowi.
- Wymagana kontrola
- Bieżące specyfikacje muszą odzwierciedlać zweryfikowaną zmianę przed przejściem do scalania.
Szczegóły procesu
Dla zmian wymagających specyfikacji agent scala specyfikacje zmiany z bieżącą biblioteką wymagań. Zapisuje je w commicie, aby opisywały faktycznie zbudowany system.
- Rola agenta
- Synchronizuje i zapisuje specyfikacje w commicie zgodnie z zasadami zatwierdzania.
- Rola człowieka
- Zachowuje prawo do potwierdzania commitów zgodnie z zasadami projektu.
Scalenie
RezultatScalenie zatwierdzone przez człowieka
Człowiek zatwierdza i scala ukończoną zmianę.
- Wymagana kontrola
- Po pomyślnym zakończeniu wszystkich wymaganych kontroli człowiek musi zatwierdzić i wykonać scalenie do main.
Szczegóły procesu
Człowiek sprawdza ukończoną pracę i scala ją do main. Łączenie PR zadań w gałęzi integracyjnej to osobny krok, który nie upoważnia agenta do scalania do main.
- Rola agenta
- Przekazuje zweryfikowaną pracę i raport; nigdy nie scala do main.
- Rola człowieka
- Zatwierdza i scala do main.
Rola agentów AI w cyklu tworzenia oprogramowania
Agenci wykonują zadania i przedstawiają wyniki potwierdzające wykonaną pracę. Ludzie wyznaczają kierunek i zachowują kontrolę nad nieodwracalnymi decyzjami.
Ludzie decydują
- Zatwierdzają zakres i wybierają zadania.
- Wybierają gałąź bazową i wyjaśniają wymagania.
- Potwierdzają commity zgodnie z zasadami projektu.
- Rozwiązują blokady i eskalowane problemy.
- Sprawdzają raport końcowy i scalają do main.
Agenci wykonują
- Analizują repozytorium i przygotowują zadania, specyfikacje i PR robocze.
- Delegują grupy zadań, piszą testy i implementują kod.
- Uruchamiają kontrole jakości i cztery przeglądy.
- Naprawiają problemy, zapisują decyzje o odroczeniu napraw i raportują wyniki.
- Archiwizują zweryfikowane specyfikacje i łączą zadania kamienia milowego w gałęzi integracyjnej.
Tworzenie oprogramowania z agentami według specyfikacji
Zanim powstanie kod istotnej zmiany, przygotowujemy specyfikację gotową do wdrożenia. Jej scenariusze określają, co mają potwierdzić testy i weryfikacja końcowa.
OpenSpec przechowuje dokumenty zmiany w repozytorium. Zapisy decyzji wyjaśniają wybory, słownik definiuje pojęcia domenowe, a zarchiwizowane specyfikacje opisują aktualny system.
- Propozycja: uzgodnienie problemu, zakresu i oczekiwanego wyniku.
- Projekt rozwiązania: zapis podejścia i kluczowych decyzji.
- Specyfikacje zmiany: opis zmienionych wymagań ze sprawdzalnymi scenariuszami.
- Zadania: podział zatwierdzonej zmiany na kroki implementacji.
- Implementacja: testy przed kodem, zgodne ze scenariuszami.
- Weryfikacja: sprawdzenie kodu, testów i każdego scenariusza.
- Archiwizacja: scalenie zweryfikowanych wymagań z bieżącymi specyfikacjami.
Jeśli praca dotyczy wyłącznie dokumentacji lub procesu, udokumentowana ocena może dopuścić spec:skip. Ten wyjątek nie obejmuje zmian w kodzie i nie pozwala pomijać wymaganych kontroli.
Kontrole jakości i automatyczny przegląd
Kryteria gotowości określają, czy pracę można rozpocząć. Kryteria ukończenia określają, czy można ją uznać za zakończoną. Dalsza realizacja wymaga testów przed kodem, macierzy przypadków brzegowych i pomyślnych wyników kontroli.
Recenzenci
Bezpieczeństwo
Sprawdza zagrożenia i zgodność z zasadami bezpieczeństwa projektu.
Błędy
Sprawdza poprawność kodu, sytuacje, w których występują błędy, i przypadki brzegowe.
Standardy i specyfikacja
Sprawdza zasady repozytorium i każdy scenariusz specyfikacji.
Łatwość utrzymania
Wskazuje zbędną złożoność i kod, który trudno zmieniać.
Waga problemu
- Krytyczna
- Wymaga naprawy, zanim praca otrzyma status DONE.
- Wysoka
- Wymaga naprawy, zanim praca otrzyma status DONE.
- Średnia
- Można odroczyć tylko z pisemnym uzasadnieniem w PR.
- Niska
- Można odroczyć tylko z pisemnym uzasadnieniem w PR.
Wdrażanie agentów programistycznych AI w firmie
Repozytorium zawiera zasady pracy i wyniki kontroli, dzięki którym zespół może nadzorować agentów. Pozwalają one sprawdzać przebieg procesu i go powtarzać.
Obowiązkowe zasady pracy
Wymagane są testy przed kodem i macierz przypadków brzegowych. Agenci korzystają z podstawowych komponentów UI z rejestru systemu projektowego i nie mogą tworzyć własnych odpowiedników tych komponentów. Obowiązują etykiety PR i Conventional Commits. CI wymaga nazw gałęzi gh-<n>.
Aktualne specyfikacje i historia decyzji
Repozytorium łączy zadania, specyfikacje, testy, PR i zarchiwizowane wymagania. Zapisy decyzji zachowują uzasadnienie wykonanej pracy, a słownik wyjaśnia pojęcia domenowe.
Limity i raportowanie pętli
Przeglądy, testy i weryfikacja mają limit dwóch nieudanych prób. Po drugiej pętla się zatrzymuje ze statusem BLOCKED i powstaje raport braków. Każdy raport etapu zawiera wiersz Loops: z liczbą rund, prób, delegowań i odroczeń.
Przenośne umiejętności agentów
Te same umiejętności działają w Cursor, Claude Code i Codex. Kontrola zgodności sprawdza, czy działają tak samo; proces nie zależy od konkretnego modelu.
Zatwierdzenia przez ludzi
Ludzie zatwierdzają zakres, wybierają zadania, potwierdzają commity i scalają do main. Agenci raportują blokady i eskalacje, aby człowiek mógł zdecydować o kolejnym kroku.
Dla kogo jest AI-Native SDLC?
Pracujemy z zespołami inżynierskimi w Wielkiej Brytanii i całej Europie. Nasz proces jest dla organizacji, które chcą powierzyć zadania agentom, zachować kontrolę i dalej prowadzić pracę we własnym zespole.
Zespoły zamawiające oprogramowanie
Od pierwszego dnia otrzymujesz repozytorium projektu ze specyfikacjami, zasadami pracy i umiejętnościami agentów. Raporty pokazują wyniki kontroli i sprawy wymagające decyzji.
Zespoły wdrażające agentów programistycznych
Dajesz agentom wspólny proces z obowiązkowymi testami, przeglądami i zatwierdzeniami przez ludzi. Programiści nie muszą ustalać zasad pracy każdy z osobna.
Twój zespół po przekazaniu projektu
Ten sam proces zostaje w repozytorium. Możesz prześledzić powiązania zadania ze specyfikacją, testami, PR i zarchiwizowanymi wymaganiami, a potem zastosować ten proces do kolejnej zmiany.
Pytania o AI-Native SDLC
Czym jest AI-native SDLC?
To proces tworzenia oprogramowania, w którym agenci wykonują zadania, a ludzie nadzorują pracę. Repozytorium zawiera specyfikacje, standardy, umiejętności agentów, kontrole jakości, raporty i zapisy zatwierdzeń.
Czym różni się od używania asystenta programistycznego?
Asystent może pomagać w pisaniu, testowaniu i sprawdzaniu kodu. W AI-native te działania podlegają wspólnym, obowiązkowym zasadom. Wymagają specyfikacji przed kodem, przeglądów, limitów prób i zatwierdzeń przez ludzi.
Czy AI samodzielnie scala kod?
Agenci nigdy nie scalają do main. Podczas realizacji kamienia milowego mogą łączyć PR zadań w gałęzi integracyjnej i otworzyć zbiorczy PR roboczy. Człowiek zatwierdza i wykonuje końcowe scalenie do main.
Co się dzieje, gdy agent utknie?
Po drugiej nieudanej próbie pętla zatrzymuje się ze statusem BLOCKED. Powstaje raport braków, które musi rozstrzygnąć człowiek. Przegląd ma najwyżej dwie rundy. Jeśli po nich pozostają problemy krytyczne lub wysokiej wagi, praca otrzymuje status NOT DONE, a sprawa trafia do człowieka.
Jakich narzędzi i modeli AI używacie?
Proces nie zależy od konkretnego modelu. Te same umiejętności działają w Cursor, Claude Code i Codex, a kontrola w procesie sprawdza ich zgodność między narzędziami.
Jak utrzymujecie zgodność specyfikacji z kodem?
Zanim powstanie kod, przygotowujemy zmianę OpenSpec gotową do wdrożenia. Weryfikacja sprawdza każdy scenariusz, a na etapie Archiwizacji specyfikacje zmiany są scalane z bieżącą biblioteką wymagań. Tylko udokumentowana ocena pracy nad samą dokumentacją lub procesem dopuszcza spec:skip.
Czy nasz zespół może korzystać z procesu po przekazaniu projektu?
Tak. Proces, standardy, specyfikacje i umiejętności agentów zostają w repozytorium projektu. Wasz zespół może uruchamiać ten sam proces i śledzić decyzje oraz wyniki każdej dostarczonej zmiany.
Jak prowadzicie przegląd bezpieczeństwa?
Podstawowe wymagania bezpieczeństwa są częścią kontroli wstępnych. Osobny recenzent sprawdza bezpieczeństwo. Równolegle pozostali recenzenci sprawdzają błędy, standardy i specyfikację oraz łatwość utrzymania kodu. Problemy krytyczne i wysokiej wagi trzeba naprawić. Odroczenie naprawy problemów średniej i niskiej wagi wymaga pisemnego uzasadnienia w PR.
Jak firma może wdrożyć AI w całym cyklu rozwoju oprogramowania?
Zacznij od procesu, a nie od narzędzia. Umieść specyfikacje, testy i zasady przeglądu w repozytorium, aby każdy agent i inżynier podlegał tym samym kontrolom. Wyznacz agentom jasne granice, pozostaw zatwierdzanie zakresu i scalanie zmian ludziom oraz przetestuj proces w rzeczywistym projekcie. Gdy zacznie działać, przekaż go zespołowi, który będzie prowadził go na co dzień.
Jak mierzyć wzrost produktywności dzięki narzędziom AI do programowania?
Mierz wyniki dostarczania oprogramowania, a nie wrażenia. Zapisz punkt odniesienia dla czasu od rozpoczęcia zmiany do jej wdrożenia, częstotliwości wdrożeń, odsetka zmian powodujących awarie i czasu przeglądu kodu. Następnie porównaj wyniki po wdrożeniu AI. Subiektywne oceny mogą mylić: w badaniu METR z 2025 roku doświadczeni programiści pracowali z narzędziami AI o 19% wolniej nad badanymi zadaniami, choć uważali, że byli o 20% szybsi.
Czym jest rozwój oprogramowania oparty na specyfikacji?
Rozwój oparty na specyfikacji oznacza uzgodnienie, co zmiana ma robić, zanim powstanie kod. Krótka specyfikacja opisuje problem, zakres, decyzje projektowe i scenariusze, których poprawność muszą potwierdzić testy. Dla agentów programistycznych AI jest instrukcją pracy. Testy i przeglądy sprawdzają zgodność kodu z jej wymaganiami. W Idego specyfikacje przechowujemy w repozytorium z użyciem OpenSpec.
Czy AI-native SDLC nadaje się do tworzenia oprogramowania dla dużych organizacji?
Tak, gdy zasady zarządzania są częścią procesu od początku. Duże organizacje potrzebują standardów zapisanych jako kod, egzekwowanych reguł pracy, specyfikacji zgodnych ze stanem systemu i historii pokazującej, co zmieniono i kto to zatwierdził. Agenci nigdy samodzielnie nie scalają zmian do main, dzięki czemu ludzie zachowują kontrolę nad każdym wydaniem.
Proces, który zostaje w Twoim zespole
Porozmawiajmy o potrzebach projektu, zasadach zatwierdzania i przekazaniu pracy zespołowi. Określimy zakres i pokażemy, gdzie sprawdzą się agenci.