PromptFactory · od PromptCompany
Oprogramowanie i elektronika budowane przez agentów AI. Zadania wyznacza człowiek.
Działa jak ChatGPT, tylko wynikiem nie jest odpowiedź w czacie, ale gotowy, przetestowany kod scalony na main. Człowiek ustala też reguły i decyduje tam, gdzie pyta o to bramka.
Dla zespołów, które budują oprogramowanie lub elektronikę. Każde zadanie przechodzi z Twojego backlogu do kodu scalonego na main przez stałe etapy: budowa z testami, przegląd i bramki jakości. Większe zadania przechodzą też weryfikację, a największe najpierw dostają plan.
- Zadaniez backlogu Ustalasz zadania i priorytety
- PlanTHINKnajwiększe zadania
- BudowaBUILDkażde zadanie
- Testy i weryfikacjaPROVEwiększe zadania czerwone testy → kolejna runda budowy
- PrzeglądREVIEWkażde zadanie uwagi z przeglądu → kolejna runda budowy drugi, niezależny przegląd dla większych zmian w kodzie i każdej zmiany ryzykownej
- Bramkijakość Gdy bramka pyta, decyduje człowiek
- Scalenie na mainLANDING jedna kolejka scaleń, po kolei
W liczbach
Odczyt z rejestru fabryki i z repozytoriów git.
- 1203 zadania scalone na main od 22.09.2026 Zadanie to jedna zmiana z testami, w kodzie produktu albo samej fabryki. stan na 3.11.2026
- 72% zadań od 15.10 miało dwa niezależne przeglądy 469 z 655 zadań scalonych na main. stan na 3.11.2026
- 56 411 wpisów w rejestrze od 6.09.2026 Każdy skrót w łańcuchu przeliczony: bez przerwy i bez niezgodności. stan na 3.11.2026
- 52,4 zadania dziennie w najlepszym tygodniu, 19–25.10 stan na 3.11.2026
- 83 repozytoria git w 12 warstwach Od firmware'u i kontraktów po serwer, aplikacje internetowe i CI/CD. stan na 3.11.2026
- 20 projektów płytek drukowanych Jako kod, w atopile i KiCad. stan na 3.11.2026
Jak działa
Od backlogu do main, za każdym razem według tych samych reguł
Zadanie to jedna zmiana razem z testami, a od jego wielkości zależą etapy, przez które przechodzi. Agenci AI pracują w swoich rolach, zadania i reguły ustalasz Ty, a gdy bramka pyta, decyduje człowiek.
Reguła wielkości
| Wielkość zadania | PlanTHINK | BudowaBUILD | WeryfikacjaPROVE | PrzeglądyREVIEW |
|---|---|---|---|---|
| XS, S | nie | tak | nie | 1 |
| Większe | nie | tak | tak | 2 przy kodzie |
| Największe | tak | tak | tak | 2 przy kodzie |
| Zmiana ryzykowna, każda wielkość | etapy według wielkości | 2 | ||
2 to drugi, niezależny przegląd: przechodzą go większe zmiany w kodzie i każda zmiana ryzykowna. Czerwone testy i uwagi z przeglądu odsyłają zmianę do kolejnej rundy budowy. Każde zadanie kończy się na bramkach jakości i w jednej kolejce scaleń.
Dziś przeglądy wykonują modele Claude (Anthropic). Planujemy, że kolejne wersje fabryki będą niezależne od dostawcy modeli.
Konsola i aplikacja właściciela
Pytania przychodzą jako karty. Decyzja to jedno dotknięcie.
Gdy taśma potrzebuje człowieka, pytanie pojawia się w konsoli i w aplikacji: internetowej (React, TypeScript) i na Androida, z mikrofonem. Zakładki to Rozmowa, Decyzje i Zdrowie, a z fabryką można rozmawiać głosowo.
- ustalasz zadania i ich priorytety
- gdy bramka pyta, decyduje człowiek
- przy zmianach ryzykownych właściciel ma też prawo weta
-
Rejestr z łańcuchem skrótów
Każdy krok to wpis w rejestrze, do którego można tylko dopisywać. Wpis niesie skrót poprzedniego i własny skrót SHA-256 z kanonicznego JSON-a, więc zmiana lub usunięcie wpisu przerywa łańcuch.
-
Jedno dozwolone przejście
Taśma przesuwa zadanie, czytając rejestr. Z każdego stanu prowadzi dokładnie jedno dozwolone następne przejście.
-
Jedna kolejka scaleń
Każde czekające scalenie ma bilet w jednej kolejce. Blokadę repozytorium próbuje wziąć tylko pierwsze w kolejce, więc zmiany trafiają na main po kolei.
-
Bramki jakości
Kontrole, które zmiana musi przejść przed scaleniem. Gdy bramka pyta, decyduje człowiek.
-
Budżety i limity rund
Każde zadanie i każdy agent mają budżet tokenów; po jego przekroczeniu zadanie może czekać na decyzję właściciela. Liczbę rund budowy ogranicza limit zależny od wielkości zadania.
-
Maszyny na zadanie
Budowa lub test dostaje maszynę uruchomioną dla tego jednego zadania; trafienie w pamięci podręcznej nie potrzebuje żadnej. Loty w symulacji idą na osobnej maszynie dla każdego lotu, usuwanej po jego końcu.
-
Agenci w rolach
Na taśmie pracują agenci od planowania, budowy, testów i przeglądów. Nad taśmą są dyrygent i stanowiska kierownicze.
-
Front engineering
Zanim fabryka zacznie budować, razem z Tobą ustalamy wymagania, rozpisujemy backlog i architekturę.
Testy
Testy dobrane do każdej zmiany, pełna bateria co noc
Budowa uruchamia kryteria akceptacji zadania i zestawy testów, których dotyka zmiana. Weryfikacja powtarza dokładnie ten zakres. Co noc rusza pełna bateria.
Jednostkowe
funkcje i moduły w izolacji
pytest · GoogleTest · Vitest · Jest
Funkcjonalne
kryteria akceptacji każdego zadania
pytest · Playwright
Integracyjne
usługi razem, w kontenerach
Docker Compose · pytest
End-to-end
pełne scenariusze w działającym systemie
Robot Framework · Playwright
SITL
lot w symulatorze Gazebo, oprogramowanie w pętli
osobna maszyna na każdy lot, uruchamiana na żądanie
W repozytoriach: 1736 plików testów pytest, 179 plików C++ z testami GoogleTest, 67 plików Robot Framework. stan na 3.11.2026
Kiedy
- Przy każdym zadaniu
- testy zmiany w budowie, powtórzone w weryfikacji, jeśli zadanie ją ma
- Co noc
- pełna bateria
Agenci testują sami
Playwright MCP: agent obsługuje aplikację w przeglądarce.
Robot Framework MCP: agent uruchamia i czyta testy end-to-end.
Co buduje
Dziś: oprogramowanie i elektronika
Rozwijamy kolejne specjalizacje: mechanikę z CAD jako kodem w build123d, inżynierię systemów, cyberbezpieczeństwo i produkcję.
Oprogramowanie
Oprogramowanie wbudowane i pokładowe (ROS 2), usługi serwerowe, aplikacje internetowe, modele AI, symulacja, CI/CD.
Elektronika
Płytki drukowane jako kod, w atopile i KiCad, z BOM generowanym z projektu.
Płytki projektują agenci AI w sesjach z inżynierem.
Technologie, w których fabryka już pracuje
- C/C++ · Zephyr RTOS
- Python
- TypeScript · React · Next.js
- Qt/QML
- ROS 2
- Gazebo (SITL)
- PyTorch · ONNX
- FastAPI · gRPC · PostgreSQL
- Protobuf
- Docker · GCP · CI
- atopile · KiCad
- BOM
Projekt referencyjny
SmartDrones sp. z o.o. (spółka powiązana). Fabrykę najpierw sprawdziliśmy u siebie. Zespół SmartDrones codziennie buduje z nią własne oprogramowanie do autonomicznych inspekcji dronowych: firmware, oprogramowanie pokładowe, chmurę i aplikacje. Kod i wyniki tej pracy należą do SmartDrones.
Praca obejmuje:
- Autopilot i nawigacjaoprogramowanie wbudowane, C/C++, Zephyr RTOS
- Komputer misji i stacje naziemneROS 2
- Symulacja SITLlot w symulatorze Gazebo
- Percepcja AIinspekcja łopat turbin wiatrowych; PyTorch, ONNX
- Usługi serweroweFastAPI, gRPC, PostgreSQL
- Kontrakty API i SDKProtobuf; SDK generowane z kontraktów
- Aplikacje internetowe i stacjonarneTypeScript, React, Next.js; Qt/QML
- CI/CD i testy całościowePython; Docker, GCP, Robot Framework
- Elektronikarodzina autopilota i moduły: czujniki, zasilanie, sieć
Pilotaż
Pilotaż na własnym projekcie
Rdzeń fabryki już działa. Szukamy partnerów, którzy sprawdzą go na własnym projekcie.
-
1 · OK. 2 TYGODNIE
Wdrożenie
Warsztat startowy: wymagania, backlog i architektura. Potem kopia fabryki skonfigurowana pod Twój projekt.
-
2 · 2–4 TYGODNIE
Praca fabryki
Fabryka realizuje zadania z Twojego backlogu.
-
3 · NA ZAKOŃCZENIE
Wyniki
Przegląd zrealizowanych funkcji, pomiary i raport z pilotażu.
CO WNOSISZ
- projekt lub repozytorium
- jedną osobę po stronie produktu
- ok. 2 godziny tygodniowo
CO DOSTAJESZ
- funkcje zrealizowane w pilotażu, scalone na main
- pomiary z przebiegu pilotażu
- raport z pilotażu
To proponowany kształt pilotażu; szczegóły ustalamy w rozmowie.
Kontakt
Następny krok: krótka rozmowa
Napisz, co budujesz, a umówimy krótką rozmowę o pilotażu.