Vibe coding w Elixirze i Phoenix - jak dowozić szybciej bez chaosu

ElixirPhoenixAIvibe codingAGENTS.mdprocesCTOWszystkie tagi

Vibe coding działa. To nie trend z konferencji, tylko codzienna praktyka zespołów, które używają Cursora, Claude Code, Copilota czy Codexa do tworzenia nowych modułów.

Problem zaczyna się później. Kod powstaje szybciej, ale często:

  • jest nierówny jakościowo,
  • trudniej go utrzymać po 3-6 miesiącach,
  • przesuwa odpowiedzialność z "napisać" na "zrozumieć i zweryfikować".

Jeśli chcesz realnie skorzystać z AI-assisted development, nie potrzebujesz większego modelu. Potrzebujesz lepszego systemu pracy.

W tym artykule pokazujemy, jak robić vibe coding w Elixirze i Phoenix tak, żeby zysk z prędkości nie zamieniał się w chaos.

Najpierw definicja: czym vibe coding jest, a czym nie jest

Vibe coding to sposób pracy, w którym programista definiuje intencję (co ma powstać, jakie warunki ma spełnić), a AI generuje większą część implementacji. Programista pozostaje odpowiedzialny za architekturę, bezpieczeństwo i jakość.

To nie jest:

  • "AI pisze wszystko, człowiek tylko klika merge",
  • "junior replacement",
  • "skrót do ominięcia testów i code review".

To jest:

  • przyspieszenie wytwarzania kodu,
  • przesunięcie energii zespołu z boilerplate'u na decyzje projektowe,
  • konieczność dojrzalszego procesu review i walidacji.

Dlaczego akurat Elixir i Phoenix

Nie każdy stack daje AI podobne warunki pracy. Elixir i Phoenix mają kilka cech, które zmniejszają koszt błędów generowanych przez model:

  • kompilator i ostrzeżenia szybko wychwytują klasyczne pomyłki AI,
  • spójne konwencje Phoenixa ograniczają "zgadywanie struktury projektu",
  • Ecto changesets i podejście data-first wymuszają jawne reguły walidacji,
  • LiveView pozwala zamknąć wiele przypadków bez osobnej warstwy API + frontend state management,
  • Phoenix 1.8 wprowadza AGENTS.md, czyli kontekst projektu zorientowany pod asystentów AI.

W praktyce oznacza to mniej losowości w wygenerowanym kodzie i krótszą pętlę korekty.

Model operacyjny: 4 warstwy, które robią różnicę

Najczęstszy błąd we wdrożeniach AI to skupienie się wyłącznie na narzędziu. Lepszy rezultat daje zdefiniowanie pełnego przepływu pracy:

flowchart TD
    A["1. Kontekst
AGENTS.md, standardy, przykłady"] --> B["2. Generowanie
prompty zadaniowe, małe scope"]
    B --> C["3. Weryfikacja
compile, test, credo, security"]
    C --> D["4. Governance
review, ADR, KPI, retrospektywy"]

Kontekst

AI działa tak dobrze, jak dobry ma kontekst. Minimum:

  • reguły architektoniczne (gdzie jest logika domenowa, gdzie I/O),
  • wzorce obsługi błędów i wyników ({:ok, _} / {:error, _}),
  • standard testów (unit/integration, kiedy wymagane),
  • przykłady "dobrych" modułów referencyjnych.

W projektach Phoenix to naturalne miejsce na AGENTS.md plus krótkie dokumenty projektowe (docs/architecture/*.md).

Generowanie

Najlepsze wyniki daje mały zakres na jedno zlecenie dla AI:

  • jeden kontekst biznesowy albo jedna funkcjonalność UI,
  • jasno opisane wejścia/wyjścia i edge case'y,
  • jawne ograniczenia (bez nowych zależności, bez zmian w schemacie DB, itd.).

Zamiast promptu: "zrób cały moduł fakturowania", lepiej:

  • "dodaj walidację statusu płatności w istniejącym changesecie",
  • "dopisz worker Oban do przypomnienia o terminie płatności",
  • "napisz testy regresji dla tego scenariusza".

Weryfikacja

Tu najczęściej wygrywa albo przegrywa cały vibe coding.

Minimalna bramka jakości przed merge:

mix compile --warnings-as-errors
mix test
mix format --check-formatted
mix credo --strict
mix deps.audit

Dodatkowo:

  • dla zmian endpointów: testy integracyjne,
  • dla zmian domenowych: testy właściwości lub scenariusze graniczne,
  • dla zmian SQL: sprawdzenie planów zapytań przy większych danych.

Governance

Bez governance zespół szybciej produkuje niespójny kod. Z governance szybciej buduje produkt.

Praktyczny zestaw:

  • obowiązkowy PR review przez człowieka odpowiedzialnego za obszar,
  • krótki ADR dla decyzji architektonicznych (co i dlaczego),
  • tagowanie PR-ów generowanych z użyciem AI (dla późniejszej analizy),
  • miesięczny przegląd jakości: tempo vs regresje vs dług utrzymaniowy.

Konkretny workflow dla zespołu Phoenix

Poniżej prosty model, który dobrze działa w zespołach 3-10 osób:

  1. Planujesz pracę w małych pionowych wycinkach (feature slice).
  2. Tworzysz prompt z kryteriami akceptacji i ograniczeniami.
  3. AI generuje kod + testy dla konkretnego wycinka.
  4. Odpalasz lokalną bramkę jakości (compile/test/credo/audit).
  5. W PR opisujesz, co wygenerował model i co poprawił człowiek.
  6. Reviewer ocenia nie tylko "czy działa", ale też "czy będzie utrzymywalne".

Ważne: każda iteracja powinna kończyć się kodem, który rozumie człowiek z zespołu bez pomocy AI.

Przykładowy prompt, który zwykle działa lepiej

Kontekst:
- Projekt Phoenix, logika domenowa tylko w kontekstach.
- Walidacje danych wyłącznie przez Ecto changesets.
- Zadania asynchroniczne przez Oban.

Zadanie:
- Dodaj możliwość oznaczenia zamówienia jako "overdue".
- Jeśli termin minął i status != paid, ustaw overdue = true.
- Nie zmieniaj istniejących endpointów HTTP.

Wymagania:
- Bez nowych zależności.
- Testy: happy path + 2 edge case'y.
- Zachowaj istniejący styl i nazewnictwo.

Output:
- Lista plików do zmiany.
- Kod zmian.
- Krótkie wyjaśnienie decyzji.

To podejście zmniejsza halucynacje i ogranicza "kreatywność" AI tam, gdzie potrzebujesz przewidywalności.

Jak mierzyć, czy to faktycznie działa

Bez metryk dyskusja o vibe codingu kończy się opiniami. Z metrykami masz dane.

Zacznij od 6 KPI:

  • lead time od zadania do merge,
  • liczba regresji na produkcji na 100 PR,
  • odsetek PR wymagających większego reworku po review,
  • średni czas review,
  • pokrycie testami nowych ścieżek krytycznych,
  • liczba incydentów "nie rozumiem kodu, który mergowaliśmy".

Jeśli lead time spada, a regresje i rework nie rosną, jesteś na dobrej drodze.

Najczęstsze pułapki i jak ich uniknąć

"AI zrobiło szybko, to mergujemy"

Szybko nie znaczy dobrze. Trzymaj bramkę jakości bez wyjątków.

"Jeden wielki prompt na cały feature"

Duży scope zwiększa ryzyko niespójności. Dziel zadania na mniejsze kroki.

"Brak własnych standardów"

Bez standardów AI tworzy kod "średni z internetu". Z standardami tworzy kod "pod Twój projekt".

"Brak ownership po stronie zespołu"

Każdy fragment kodu AI musi mieć ludzkiego właściciela, który rozumie decyzje i skutki zmian.

Dla CTO: gdzie jest realny zwrot

Największy zysk nie polega na tym, że "AI pisze za programistę". Zysk jest w tym, że:

  • zespół szybciej dowozi funkcjonalności biznesowe,
  • seniorzy mniej czasu tracą na ręczny boilerplate,
  • wdrażanie nowych developerów jest krótsze dzięki lepszej dokumentacji i powtarzalnym wzorcom,
  • możesz utrzymać wyższą częstotliwość releasów bez zwiększania rozmiaru zespołu.

Warunek: wdrożenie vibe codingu jako procesu inżynierskiego, nie jako eksperymentu narzędziowego.

Kiedy nie warto iść w vibe coding

Są sytuacje, gdzie ostrożność powinna być dużo większa:

  • komponenty krytyczne bezpieczeństwa bez dojrzałego review,
  • obszary regulowane wymagające formalnej ścieżki certyfikacji,
  • zespoły bez czasu na utrzymanie testów i standardów.

W takich miejscach AI może wspierać analizę i refactoring, ale nie powinno dominować implementacji.