Polityka prototypów — awans według ryzyka i dowodów
Szybkie generatory aplikacji i conversational coding są wartościowe do nauki, ale „prototyp” nie jest stałą klasą bezpieczeństwa. Dojrzała polityka routuje pracę według ekspozycji, danych, skutków zewnętrznych, odwracalności, ownership i dowodów. Określa, kiedy artefakt może pozostać disposable, kiedy potrzebuje kontroli inżynierskich, a kiedy musi wejść do produkcyjnego AI SDLC — niezależnie od narzędzia.
Q16 · Paralelizm w skali zespołu Dowód na maksymalny wynik: tool-neutral polityka z jawnymi granicami capability, triggerami awansu, dowodami akceptacyjnymi i ownership.
Klasyfikuj według ekspozycji
Dział zatytułowany „Klasyfikuj według ekspozycji”| Klasa | Granica | Wymagany dowód |
|---|---|---|
| Disposable exploration | dane syntetyczne, brak external users i writes, łatwe usunięcie | cel, owner, expiry |
| Controlled pilot | ograniczeni użytkownicy, approved data, odwracalne efekty | accepted spec, testy, monitoring, support i rollback |
| Production system | zależność klienta lub operacji, persistent data albo material effects | pełna pętla artefaktów Plan–Maintain i nazwane gates |
| Forbidden prototype path | sekrety, niezatwierdzone dane prywatne/regulowane, niekontrolowane płatności lub destructive access | stop i przejście do approved workflow |
- Klasyfikuj przy utworzeniu. Zapisz cel, ownera, users, dane, efekty, integracje, expiry i repozytorium.
- Egzekwuj granice klasy. Użyj osobnych kont, danych, credentials, domen, budżetów i network access.
- Zdefiniuj triggery awansu. Uruchom review przy zmianie ekspozycji, persistence, criticality, danych, ownership albo skutków zewnętrznych.
- Rebuild lub harden świadomie. Decyduj z architektury i dowodów; nie zakładaj, że generated code zawsze trzeba wyrzucić ani zawsze można promować.
- Wycofuj stare artefakty. Odbierz credentials, usuń dane i domeny, zarchiwizuj decyzje i zweryfikuj cleanup.
Prompty do review prototypu
Dział zatytułowany „Prompty do review prototypu”Sklasyfikuj artefakt według users, danych, efektów zewnętrznych, persistence, reversibility, criticality i ownership. Wskaż dozwoloną granicę, prohibited behavior, expiry i wymagany dowód.Sprawdź, czy zadziałał trigger awansu: real users, dane klienta lub regulated, payments, durable state, shared dependency, support obligation albo hard-to-reverse effect. Zacytuj dowody.Zarekomenduj retire, keep disposable, harden in place albo rebuild w production workflow. Porównaj architekturę, testy, data migration, ownership, koszt, rollback i utraconą wiedzę.Dowody akceptacyjne
Dział zatytułowany „Dowody akceptacyjne”- Każdy aktywny prototyp ma ownera, klasę, expiry i wpis w discoverable inventory.
- Granice sandbox są techniczne, nie tylko zapisane w dokumencie.
- Awans uruchamia zmiana ekspozycji i ryzyka, nie arbitralny wiek ani vendor.
- Promocja produkcyjna wchodzi do kanonicznej pętli artefaktów i approvals.
- Cleanup jest zweryfikowany i obejmuje credentials, dane, integracje, domeny i billing.
Wzorzec awarii: „tymczasowa” produkcja
Dział zatytułowany „Wzorzec awarii: „tymczasowa” produkcja”Prototyp może zdobyć real users, dane i dependencies bez formalnej deklaracji produkcji. Automatyczny inventory review i exposure triggers muszą wykryć przejście, zanim artefakt stanie się business-critical bez ownership albo rollbacku.
Dalej: pełny lifecycle
Dział zatytułowany „Dalej: pełny lifecycle”Przenieś awansowaną pracę do AI-native SDLC i zapisz decyzję capability w Roadmapie toolingu AI.