Claude Code
Moje produkty, codziennie
Planowanie, incydenty, długie wątki i wszystko, co wymaga kontekstu produktu albo pamięci. Pisze specyfikacje, które wykonują inni agenci.
Praca z AI
Jak buduję produkty z agentami AI
Moim domyślnym agentem jest Claude Code. Codex CLI dostaje ograniczone zadania, które mają już spisany spec, a Kiro CLI używam w dużym kodzie korporacyjnym w mojej głównej pracy. Większość kodu piszą agenci. O tym, że da się go wdrożyć, decyduje wszystko wokół nich: spec, spisane standardy inżynierskie, reguły deny i hooki, testy jednostkowe, integracyjne i E2E, evals, review przez drugiego agenta i mój własny przegląd każdego pull requesta przed merge. Każda sekcja poniżej prowadzi do wpisu z mojej własnej pracy na produkcji.
Który agent dostaje które zadanie
Codex CLI
Moje produkty, obok Claude Code
Ograniczone zadania ze spisanym specem, uruchamiane we własnym git worktree, plus druga opinia w code review.
Kiro CLI
Duży kod korporacyjny w mojej głównej pracy
Agent zatwierdzony przez firmę, w ścisłych korporacyjnych ograniczeniach: małe zmiany, łatwe do przejrzenia, z człowiekiem w każdej pętli.
Zasada podziału i wspólna konfiguracja: Claude Code vs Codex CLI oraz Kiro vs Claude Code.
Jak powstaje nowa funkcja
- 01
Spec
Piszę go z agentem planującym: model produktu, twarde ograniczenia, ponumerowana lista testów i blok zakończenia.
Spec, który agent skończy sam → - 02
Agenci budują według moich standardów
Claude Code albo Codex CLI, każdy we własnym git worktree, trzymają się spisanych zasad: SOLID, DRY, KISS, małe czyste funkcje, reguły deny na wszystko, czego nie da się cofnąć.
Agenci równolegle w worktree → - 03
Testy i bramki
Testy jednostkowe reguł i przypadków brzegowych, integracyjne na ścieżkach danych, E2E w Playwright na ścieżkach użytkownika, lint na plikach w commicie i evals dla funkcji AI.
Evals przed merge → - 04
Review przez agenta
Drugi agent w świeżej sesji sprawdza diff względem specu i standardów, więc swój przegląd zaczynam od jego uwag.
Drugi agent jako recenzent → - 05
Mój review i merge
Człowiek w pętli: sam czytam każdy pull request, uruchamiam to, co się zmieniło, i robię merge dopiero wtedy, gdy mam pewność. Potem obserwuję produkcję.
Jak robię review kodu od AI →
Człowiekiem w pętli zostaję ja. Agenci nigdy nie robią merge. Każdy pull request sam czytam, uruchamiam to, co się zmieniło, i robię merge dopiero wtedy, gdy mam pewność, że jest dobrze, a nie wtedy, gdy CI zaświeci się na zielono.
Standardy, które musi spełniać kod od agentów
Agenci wczytują te zasady, zanim dotkną kodu produkcyjnego, a ja sprawdzam je w review. Szybki kod, którego nikt nie utrzyma, to nie przyspieszenie, tylko dług z odroczonym terminem.
- SOLID stosowany, nie recytowany
- Route'y walidują i delegują, logika biznesowa jest w warstwie domeny, SQL w warstwie repozytorium. Płatności, e-mail i dostawcy LLM są za adapterami, więc zmiana dostawcy to jeden nowy adapter.
- DRY z wyczuciem, KISS domyślnie
- Najpierw szukam, potem piszę: jedno źródło prawdy dla każdej wartości, wspólna paczka zamiast trzeciej kopii. Najprostszy projekt, który spełnia spec, bez abstrakcji na zapas i bez łączenia kodu, który zmienia się z różnych powodów.
- Małe jednostki
- Funkcja mieści się na jednym ekranie, mniej więcej 40-50 linii, a plik ma najwyżej kilkaset. Kod dzielę według odpowiedzialności, nie liczby linii, więc każdą jednostkę da się nazwać bez „i”.
- Czysta logika, efekty na brzegach
- Reguły biznesowe to czyste funkcje: dostają dane i zwracają dane. I/O, czas i losowość zostają na brzegach, dzięki czemu reguły da się testować bez mocków, a zmiany od agentów łatwo przejrzeć.
- Testy, które łapią regresje, a nie coverage
- Testy jednostkowe reguł i przypadków brzegowych, integracyjne na ścieżkach, które dotykają pieniędzy, autoryzacji i zakresu danych, E2E w Playwright na przepływach, od których zależą użytkownicy. Każdy bug dostaje najpierw test, który go odtwarza. Żadnych testów getterów.
- Bezpieczeństwo domyślnie
- Każde ID w żądaniu traktuję jak podrobione, a każde zapytanie filtruje po właścicielu. Walidacja i autoryzacja działają na serwerze, a każdy endpoint, który wywołuje model, ma limit na użytkownika, dzienny limit i wyłącznik awaryjny.
Harness wokół agenta
Harness agenta to wszystko, co otacza model: co agent może uruchomić, co jest zablokowane, co wczytuje na starcie i kiedy sesja musi się zatrzymać. Tu jest większość zabezpieczeń i większość kontroli kosztów.
- Agent kodujący z dostępem do shella, a ja śpię spokojnie: zabezpieczenia (guardrails), których używamCzterowarstwowy model bezpieczeństwa dla agentów kodujących z dostępem do shella: uprawnienia, reguły deny, hooki przed wykonaniem i zasady zachowania.
- Audyt zabezpieczeń mojego agenta kodującego: dziury, które znalazłemAudyt harnessu agenta kodującego: obejście przez API, hook, który przepuszczał wszystko, płatna ochrona gałęzi i sekrety w regułach always allow.
- Claude Code hooks w praktyce: jak utrzymać sesję agenta przy jednym temacieHook w harnessie agenta, który trzyma sesję przy jednym temacie: blokada tematów, skrzynka na pomysły, progi 250K-650K kontekstu i wymuszony handoff.
- Dlaczego przestałem ładować każdy skill do każdej sesji Claude CodeJak ułożyć kontekst Claude Code per projekt, ograniczyć skille i serwery MCP do potrzebnych i nie palić tokenów na instrukcje, których sesja nie używa.
- Context engineering dla agentów kodujących: dokumentacja projektu, z której agent wznawia pracę za 7K tokenówJak układam dokumentację, żeby agent kodujący wznawiał wątek za 6,7K tokenów zamiast 39,5K: limity hubów i bloków wejściowych, podział, format reguł.
- MCP w codziennej pracy inżyniera: lekkie sesje, ciężkie serwery na żądanieSerwery MCP w codziennej pracy: profile per sesja, odroczone schematy narzędzi, triage incydentów z logów i analityki, dostęp tylko do odczytu.
Delegowanie pracy agentom
Który agent dostaje które zadanie, jak je opisać, żeby agent skończył je sam, i jak odróżnić skończone zadanie od pewnego siebie raportu o postępach.
- Codex CLI obok Claude Code: jeden zbiór zasad, dwóch agentówClaude Code i Codex CLI na co dzień: który agent do jakiej pracy, wspólny AGENTS.md i hook, zgodność MCP oraz kontekst 272K kontra 1M.
- Dwóch agentów, dwa konteksty: Claude Code u siebie, Kiro CLI w korporacyjnym kodzieKiro vs Claude Code z codziennej pracy: Claude Code na moim produkcie, Kiro CLI w korporacyjnym kodzie i praktyki, które działają w obu miejscach.
- Spec-driven development z agentami kodującymi: specyfikacje, które agent skończy beze mnieSpec-driven development dla agentów kodujących: siedem części specyfikacji, którą agent skończy sam, twarde ograniczenia, koszt przeglądu i typowe błędy.
- Ten sam agent, odwrotne wyniki: o rezultacie decyduje kryterium wyjściaDlaczego agent kodujący kończy zadania z jasnym celem, a utyka na otwartym researchu: liczbowe kryteria wyjścia, zapisana weryfikacja, dobór modeli.
- Jak uruchamiać agentów kodujących równolegle na git worktreesJak uruchamiać agentów kodujących równolegle na git worktrees: podział na niekolidujące zadania, kontrakty, ograniczony dostęp i jedna integracja.
- Claude Code subagents i routing modeli: tanie zbieranie, mocna syntezaRouting modeli w pracy wielu agentów: drabina modeli, najpierw niższy effort, pilotaż przed rozdzieleniem pracy i minimalny kontekst subagenta.
- Model decyduje o czasie, spec o jakości: jak dobierać effort w Claude CodeJak dobierać model i effort w Claude Code: kiedy liczy się czas odpowiedzi, kiedy głębsze rozumowanie się opłaca i dlaczego kluczowa jest precyzyjna spec.
Jakość i koszty
Zielony build sprawdza tylko kształt. O tym, czy kod od agenta warto wdrożyć, decydują evals, review i jasny obraz tego, ile naprawdę kosztują tokeny.
- Evals przed merge: golden set za pipeline'em dopasowań AILLM evals dla pipeline'u rankingowego: golden set z decyzji ludzi, P@10, NDCG@10, MRR, bramka zero naruszeń i próg szumu ustalony z góry.
- Zielony build to nie dowód: jak sprawdzam zmiany wygenerowane przez AIDlaczego zielony build nie dowodzi, że kod z AI działa: bramki lint, strażnicy runtime, ochrona przed slopsquattingiem i drugi agent jako recenzent.
- Ile kosztowałby Claude Code na API: 30 dni transkryptów, policzone30 dni transkryptów agenta kodującego wycenione po stawkach API: 4176 USD, ponad 90% to odczyty z cache. Subskrypcja czy API i co z tego wynika dla kontekstu.
- Osiem miesięcy prowadzenia produktu w pojedynkę z agentami AI jako współinżynieramiOsiem miesięcy z Claude Code i Kiro CLI jako współinżynierami przy produkcyjnym produkcie: workflow, zyski, ograniczenia, zabezpieczenia i koszt.
LLM wewnątrz produktu
Druga połowa AI engineeringu: funkcje, które wywołują model na produkcji, z typowanym wynikiem, limitami wydatków i twardą granicą między tekstem dla modelu a publicznymi stronami.
- Tool use zamiast parsowania: ustrukturyzowane dane z LLM na produkcjiUstrukturyzowane dane z LLM na produkcji: tool use i ścisły JSON Schema zamiast parsowania, walidacja, ponowienia i adapter dostawcy.
- Każdy endpoint, który wywołuje model, to otwarty portfelKoszty endpointów z LLM pod kontrolą: limity na użytkownika, dzienny limit wydatków, kill switch, liczniki fail closed i rejestr wydatków.
- Jak nagłówek instrukcji dla LLM trafił do moich publicznych danych strukturalnychJak tekst promptu LLM wyciekł do publicznego JSON-LD, jak to znalazłem i naprawiłem oraz jakie reguły trzymają tekst dla modelu z dala od stron.
- Podobieństwo cosinusowe to nie prawdopodobieństwo: strojenie progów w pgvector przy prawdziwych dopasowaniachDlaczego podobieństwo cosinusowe to nie prawdopodobieństwo, jak rozkłady wyników w pgvector zależą od modelu i jak kalibrować progi na parach testowych.
Chcesz takiego sposobu pracy w swoim zespole?
Jestem otwarty na role senior product engineera i miejsce w zespole założycielskim, w którym agenci są częścią codziennej pracy. Co z nimi zbudowałem, zobaczysz na stronie projektów. Możesz też po prostu napisać do mnie.