przewiń
tovarna.dev
tovarna.dev · AI issue factory

Issue wchodzi.
Merge wychodzi.

Autonomiczna fabryka przetwarzania issues GitHuba. Każde issue przechodzi linię produkcyjną w izolowanym git worktree — od triażu przez rozwój i testy po niezależną rewizję i fast‑forward merge do maina. Ty sprawujesz nadzór, nie trzymasz klawiatury.

Coding agent pisze kod. Tovarna prowadzi cały proces, który decyduje, czy ten kod może trafić do maina. W środku spokojnie może działać Claude Code — Tovarna to warstwa nad nim, nie jego zamiennik.

Linia produkcyjna

Jedna linia. Żadnych skrótów.

Każde issue jedzie taśmą przez stałe stanowiska — od zlecenia po dostarczenie. Co nie przejdzie testów i niezależnej rewizji, nie wychodzi. Bramki są fail‑closed.

#616
01

Zlecenie

issue z jasnym celem

02

Analiza

co i dlaczego się zmienia

03

Architektura

jak wpasuje się w całość

04

Rozwój

implementacja w izolacji

05

Test

weryfikacja na czystym stanie

06

Dostarczenie

niezależna rewizja · merge

stanowisko automatyczne możliwa eskalacja do człowieka
Zasady

Zbudowana na nieufności. Celowo.

Autonomia bez hamulców to hazard. Każdy mechanizm w fabryce zakłada, że agent może się mylić — i stawia mu na drodze bramkę.

Izolowany worktree

Każde issue działa na własnej gałęzi we własnym worktree. Do maina prowadzi jedna droga: merge ff-only zmiany, której komplet testów przeszedł w tej izolacji.

Niezależna rewizja

Diff sprawdza model, który nie widział procesu rozwoju — zero anchoring bias. Ocenia wynik wyłącznie względem zlecenia.

Człowiek w pętli

Konflikt w rewizji albo zablokowane stanowisko nie jest zamiatane pod dywan — eskaluje. Decyzję wrzucasz prosto do działającej pętli i linia jedzie dalej. Bez restartu.

Co nie przejdzie bramki, nie istnieje.

zmiany atomowe · merge gate · identyfikowalność źródeł

Każda zmiana ma identyfikowalny powód i bramkę, którą musiała przejść.

Każda porażka staje się bramką.

Incydent przechodzi RCA i zamienia się w trwałą regułę — fabryka, która dziś się pomyliła, jutro sama napisze sobie kontrolę.

Nadzór, nie harówka

Wkraczasz jednym zdaniem. Resztę dowozi linia.

Gdy rewizja znajdzie konflikt między zleceniem a testem, fabryka staje i pyta. Piszesz decyzję — a pipeline rusza dokładnie tam, gdzie stanął. Średnia interwencja: jedno zdanie, dwadzieścia sekund.

12
merge / dzień
stabilny autonomiczny przepływ
83 %
czysty first-pass
reszta przez naprawę lub eskalację
0,52 USD
koszt modeli AI / issue
Haiku triaż · Sonnet dev · Opus rewizja
3,7 min
mediana czasu / issue
p90 10,5 min · wcześniej 7,4 min
Jak mierzymy liczby →
  • 12 merge / dzień — średnia z aktywnych dni (mediana 7,5, maksimum 50); autonomiczne przejścia bez ludzkiej ingerencji w kod.
  • 83 % first-pass — issue przeszło od triażu do merge'a bez iteracji naprawczej i z pierwszym werdyktem krytyka APPROVE; niezależna rewizja działała dla 100 % zmergowanych issues (w 03–07 dla 79 %).
  • 0,52 USD — średni koszt modeli AI na issue, wliczając wszystkie iteracje i niezależną rewizję (mediana 0,39; zakres 0,07–2,78).
  • 3,7 min — mediana czasu przebiegu pipeline'u na issue (p90 10,5 min); w 03–07 było to 7,4 min.

Mierzone na rozwoju samej Tovarny — fabryka buduje samą siebie (dogfooding). n = 397 zmergowanych issues, okres 08–09/2026 (32 aktywne dni). Źródło: git log dla tempa, metryki przebiegu per issue dla first-pass, kosztu i czasu; kosztu brakuje dla 1 z 397 issues. Poprzednie wydanie podawało 16 / 64 % / 0,82 USD za 03–07/2026 — tempo od tego czasu spadło (niezależna rewizja działa dla wszystkich issues, nie dla 79 %), first-pass, koszt i czas przebiegu się poprawiły. Liczby z projektów zewnętrznych dodamy po pilotażu.

Nowości

Zbuduj własną fabrykę.

Fabryka dopiero rusza. Zostaw nam e-mail, a damy znać, gdy będzie co testować.

✓ Napiszemy, gdy otworzymy dostęp beta — zero spamu.