Vibe engineering · · 6 min czytania
Jak utrzymać jakość kodu w vibe engineering: 5 praktyk
Pięć praktyk, które trzymają jakość, gdy większość kodu pisze agent.
Jakość w vibe engineeringu nie wynika z „dobrej dyscypliny”. Wynika z pięciu praktyk, które razem tworzą tarczę przed regresami. Pojedyncza praktyka nie wystarczy. Dwie wystarczają na start. Trzy dają komfort. Cztery i pięć — tu kończą się większość problemów typu „czemu znowu się popsuło, przecież testy przeszły”.
Praktyka 1: spec jako bramka
Każda zmiana powyżej trzech plików ma SPEC.md albo issue z formalnym opisemwymaga–niefunkcjonalnych (latencja, koszt LLM, ścieżka rollback) ifunkcjonalnych. Spec ma być krótki (400-800 słów), ma kończyć się sekcją „Out of scope”. Bez tej sekcji każda implementacja rozjeżdża się o 30%.
Spec piszesz ty (człowiek). Agent może pomóc z pierwszym draftem, ale akceptacja jest twoja. Tu nie ma kompromisów: bez ludzkiej decyzji spec staje się generatywnym placeholderem.
Praktyka 2: dwa review
Najpierw agent recenzuje PR (np. dedykowany subagent reviewer). Potem człowiek. Te dwa review łapią inne typy błędów. Agent łapie inkonsystencję stylu, brakujące typy, naiwne ścieżki kodu. Człowiek łapie błędną interpretację domenową i „rozwiązanie połowy problemu”.
Kluczowe: agent-reviewer NIE może zatwierdzać sam. Może tylko komentować. To różnica między pomocnikiem a decydentem.
Praktyka 3: testy z mutation albo property
Tradycyjny coverage 80% mówi tylko, że linia była wykonana. Mutation testing (Stryker, PIT, Cosmic Ray) zmienia jedną instrukcję w kodzie i sprawdza, czy test to wykrył. Jeśli nie, test był protezą.
Property-based testing (fast-check, Hypothesis) generuje setki przypadków losowych. Wystarczy, że jeden przejdzie regresji do prod, żeby uratować ci tysiące godzin postmortem.
W vibe engineeringu rekomendujemy minimum jeden z dwóch. Idealnie obydwa na kluczowych modułach.
Praktyka 4: bramki w CI
Lista bramek, których nie da się przejść:
- typescript strict bez błędów;
- lint bez warningów (lub z listą explicit-allow);
- testy unit + e2e — pełne (bez .skip-ów bez issue);
- mutation testing — minimum 70% killed mutants;
- bundle size delta < 5% (alert powyżej);
- security scan: zero high+critical, zero secrets w diffie;
- LLM evals na promptach: minimum 90% pass rate na zlocie regresji.
Każda bramka łapie inny typ błędu. Pominięcie którejkolwiek „tylko ten raz” to początek długu jakości, który spłacisz w nocy.
Praktyka 5: production telemetria + auto-rollback
Po deploy: alert na p99 latency, błędy 5xx, koszt LLM/req. Trigger auto-rollback przy threshold breach (np. Vercel deployment rollback API, Kubernetes deployment rollback).
Druga warstwa: incident response. Runbook na „co robić, kiedy alert dzwoni”. Trzecia: postmortem (bez win) po każdym incydencie z 5x „dlaczego”.
Mit: AI samo zapewni jakość
Nie. AI bardzo dobrze generuje kod, który „wygląda jak działający”, ale ma subtelne problemy. Bez powyższych pięciu praktyk LLM-generated PR przejdzie szybciej, ale wyląduje w produkcji z większym ryzykiem niż PR napisany przez juniora pod nadzorem mentora. Nie dlatego, że AI jest gorsze. Dlatego, że AI pisze szybciej, więc każda luka w procesie powiększa się proporcjonalnie do prędkości pisania.
Częste obawy zespołów
„Te pięć praktyk to za dużo na nasz mały zespół.” Pojedyncze praktyki kosztują kilka godzin tygodniowo. Brak praktyk kosztuje kilka dni miesięcznie na ratowanie produkcji. Matematyka się broni nawet w trzyosobowym zespole.
„Mamy startup, nie mamy czasu.” Spec, dwa review i jeden typ testów — to jest minimum dla startupu po pierwszym płatnym kliencie. Reszta wchodzi z czasem.
Jak wdrażać stopniowo
- Tydzień 1-2: spec dla każdej zmiany > 3 plików.
- Tydzień 3-4: agent-reviewer w CI (komentuje, nie blokuje).
- Tydzień 5-8: mutation testing na 1 module (najbardziej krytycznym).
- Tydzień 9-12: bramki CI z full enforcement.
- Tydzień 13+: production telemetria, auto-rollback, runbooki.
TL;DR
Jakość vibe engineeringu to pięć praktyk: spec, dwa review, mutation/property testing, bramki CI, production telemetria z auto-rollback. Same nie wystarczą. Razem zamieniają vibe engineering w model pracy, który skaluje się do prawdziwej produkcji bez nocnych dramatów.