Tag: baltic AI gigafactory

  • Factory ułatwia wycofywanie zmian: nowe polecenie /rewind-conversation i centralne zarządzanie hookami

    Factory ułatwia wycofywanie zmian: nowe polecenie /rewind-conversation i centralne zarządzanie hookami

    Factory w wersji v0.156.2 wprowadza polecenie /rewind-conversation, które umożliwia cofnięcie sesji czatu i przywrócenie plików do wcześniejszego stanu. Organizacje zyskują również scentralizowane zarządzanie hookami, co pozwala administratorom na egzekwowanie spójnych zasad dla wszystkich członków zespołu. W aktualizacji znalazły się także poprawki stabilności oraz ulepszenia interfejsu.

    Co nowego w skrócie

    • /rewind-conversation cofa historię czatu i przywraca stan plików z konkretnego momentu sesji
    • Centralne zarządzanie hookami daje administratorom kontrolę nad regułami dla całej organizacji, zamiast konfiguracji per użytkownik
    • Klikalne linki w wiadomościach usprawniają nawigację między plikami i odniesieniami w kodzie
    • Poprawione renderowanie kolorów w terminalu zwiększa czytelność w interfejsie CLI
    • Poprawki stabilności obejmują obsługę dużych wklejeń, błędy cyklu życia narzędzi ACP oraz automatyczne ponowne łączenie Droidów

    Cofanie sesji, które przywraca stan projektu

    Polecenie /rewind-conversation to funkcja, która rzeczywiście cofa zmiany — zarówno w konwersacji, jak i w plikach. Dokumentacja SDK opisuje je jako akcję typu successor-session, która może "przywrócić lub usunąć pliki zmienione od wskazanego momentu". Oznacza to, że jeśli agent AI wprowadził błędne zmiany w kodzie, jedno polecenie przywraca stan projektu sprzed tych decyzji.

    Funkcja ta znacząco oszczędza czas. Bez niej użytkownicy musieliby ręcznie odtwarzać stan repozytorium, przeglądając historię gita i próbując ustalić, które zmiany wprowadził agent, a które były ich własnymi. Teraz Factory wykonuje to automatycznie i w jednym kroku.

    Problem "zanieczyszczenia konwersacji" — błędnych założeń wprowadzanych przez agenta na wczesnym etapie, które mogą zakłócać dalszą pracę — jest dobrze znany użytkownikom narzędzi takich jak Codex czy Claude Code. W tych środowiskach edytowanie historii bywa uciążliwe lub ograniczone do ostatniej wiadomości. Factory rozwiązuje to inaczej: pozwala cofnąć całą sesję do wybranego punktu, razem ze stanem plików.

    Dlaczego centralne hooki mają znaczenie

    Dotychczas konfiguracja hooków w Factory działała na poziomie pojedynczego użytkownika. W większych zespołach prowadziło to do chaosu, ponieważ każdy członek organizacji mógł mieć inne ustawienia, a administratorzy nie mieli narzędzi do ich ujednolicenia.

    Wersja v0.156.2 wprowadza scentralizowane zarządzanie hookami dla organizacji. Administrator definiuje reguły raz, a system automatycznie stosuje je do wszystkich sesji członków zespołu. To nie tylko wygoda, ale także bezpieczeństwo: można wymusić wspólną politykę dotyczącą dostępu do narzędzi, walidacji kodu czy formatowania commitów.

    W praktyce, jeśli organizacja wymaga, aby każdy agent przed modyfikacją plików wykonał testy, hook egzekwujący tę zasadę działa dla wszystkich — bez potrzeby proszenia każdego developera o samodzielną konfigurację.

    Mniejsze, ale odczuwalne ulepszenia

    Aktualizacja nie koncentruje się wyłącznie na dużych funkcjach. Klikalne linki w wiadomościach to detal, który znacząco ułatwia codzienną pracę — zamiast kopiować ścieżkę pliku i otwierać go ręcznie, wystarczy jedno kliknięcie. Naprawione renderowanie kolorów w terminalu również jest istotne, zwłaszcza gdy agent generuje długie, kolorowe diffy.

    Poprawki stabilności są równie ważne. Obsługa dużych wklejek przestała powodować błędy, cykl życia wywołań narzędziowych ACP nie zawiesza już sesji, a błędy pobierania binarek Droida na niektórych systemach zostały usunięte. Warto również wspomnieć o automatycznym ponownym łączeniu komputerów Droid, gdy aktywność zostaje wznowiona — to przydatne po uśpieniu maszyny.

    Kontekst dla zespołów web dev i AI

    Factory jest środowiskiem programistycznym zaprojektowanym z myślą o agentach AI. Funkcja rewind to element szerszego modelu cyklu życia sesji, który obejmuje również wznawianie, kompaktowanie i tworzenie sesji pochodnych. Dla zespołów webowych oznacza to bezpieczniejszą iterację: można eksperymentować z poleceniami agenta, mając pewność, że powrót do stabilnego stanu to kwestia jednej komendy.

    Centralne hooki odpowiadają na potrzebę firm, które chcą skalować wykorzystanie AI w developmentcie bez utraty kontroli. Zamiast zarządzać regułami per użytkownik, administrator ustala politykę raz — i działa ona wszędzie.

    Wydanie v0.156.2 pokazuje, że Factory koncentruje się na budowaniu narzędzi, które rozwiązują rzeczywiste problemy programistów pracujących z agentami AI: utratę stanu projektu, niespójne reguły w zespole i frustrujące detale interfejsu.

    Źródła

  • Factory otwiera się na npm – nowe wsparcie dla pluginów i zabezpieczenia sesji w wersji v0.150.0

    Factory otwiera się na npm – nowe wsparcie dla pluginów i zabezpieczenia sesji w wersji v0.150.0

    Najnowsza aktualizacja Factory (v0.150.0) wprowadza wsparcie dla pluginów publikowanych jako pakiety npm. Do tej pory rozszerzenia można było dystrybuować na kilka sposobów, ale teraz dołącza do nich najpopularniejszy rejestr ekosystemu JavaScript. Zmiana jest istotna, ponieważ npm to domyślne źródło zależności dla wielu zespołów developerskich. Dodatkowo, zespół Factory wprowadził mechanizm potwierdzenia przy zamykaniu aktywnych sesji Droid, poprawki wydajności dla długich czatów oraz lepszą widoczność statusu rozliczeniowego.

    Kluczowe informacje o aktualizacji

    • npm jako źródło pluginów – w definicji marketplace’u można teraz wskazać pakiet npm wraz z opcjonalną wersją, rejestrem i tokenem do prywatnych repozytoriów.
    • Bezpieczna instalacja z wyłączonymi skryptami – Droid pobiera pluginy przez npm install z flagami --ignore-scripts --no-save --no-audit --no-fund, a kod jest kopiowany do cache’u; żaden skrypt cyklu życia się nie uruchamia.
    • Potwierdzenie przed zamknięciem – nowy monit zapobiega przypadkowemu przerwaniu pracy Droid, gdy sesja jest w toku.
    • Optymalizacja długich czatów – poprawki wydajnościowe zmniejszają opóźnienia przy rozbudowanych workflow, gdzie kontekst rośnie z każdą turą.
    • Czytelniejszy status rozliczeniowy – użytkownicy widzą teraz stan konta wyraźniej podczas korzystania z narzędzia.

    Jak działa nowe źródło pluginów

    Factory definiuje plugin przez wpis w pliku marketplace. Nowa składnia dla źródła npm jest prosta. Deweloper podaje nazwę pakietu (obsługiwane są też pakiety z zakresem, np. @firma/nazwa), opcjonalną wersję zgodną z semver lub dist-tagiem oraz – jeśli plugin znajduje się w prywatnym rejestrze – adres URL rejestru HTTPS i nazwę zmiennej środowiskowej z tokenem.

    Brak wersji oznacza, że Droid automatycznie pobierze najnowszą oznaczoną jako latest. Dla zespołów korporacyjnych to wygodne rozwiązanie – nie trzeba budować obejść, aby podłączyć prywatne repozytorium. Wystarczy podać registry i authTokenEnvVar, a Factory respektuje te ustawienia bez grzebania w globalnej konfiguracji npm.

    Zespół Factory zadbał o bezpieczeństwo – Droid wykonuje npm install w tymczasowym katalogu roboczym, a następnie kopiuje rozpakowany pakiet do cache’a. Wszystkie skrypty cyklu życia są blokowane, co oznacza, że nie uruchamiają się preinstall, install ani postinstall. W ostatnich latach ataki na łańcuch dostaw przez npm stały się powszechne – złośliwe pakiety wykorzystywały instalacyjne skrypty do kradzieży tokenów czy eksfiltracji sekretów CI/CD. GitHub ogłosił, że w npm v12 domyślnie wyłączy automatyczne wykonywanie tych skryptów. Factory podąża tą samą drogą.

    Sesje pod ochroną

    Nowy monit potwierdzenia przed zamknięciem może wydawać się drobiazgiem, ale każdy, kto przypadkowo przerwał agentowi pracę nad złożonym zadaniem, wie, jak irytujące to może być. Droid potrafi wykonywać wieloetapowe operacje: klonuje repozytoria, modyfikuje pliki, odpytuje API. Przypadkowe wciśnięcie Ctrl+C mogło zostawić projekt w niedokończonym stanie. Teraz Factory pyta, czy na pewno chcesz wyjść, gdy sesja jest aktywna. To drobna zmiana, która oszczędza nerwy.

    Dodatkowo poprawiono wydajność długich rozmów z Droidem. W rozbudowanych workflow, gdzie kontekst rośnie z każdą kolejną turą, mniejsze opóźnienia oznaczają płynniejszą pracę. Zespół Factory nie podał szczegółów technicznych, ale efekt jest odczuwalny szczególnie przy sesjach trwających przez wiele interakcji.

    Dlaczego to ma znaczenie

    Rynek narzędzi AI dla developerów staje się coraz bardziej konkurencyjny. Cursor, Windsurf, Cline – każdy szuka swojej niszy. Factory stawia na rozszerzalność. Pluginy to nie tylko komendy i umiejętności, ale też Droidy, hooki i serwery MCP, które można udostępniać między projektami i zespołami. Wsparcie dla npm eliminuje trudności związane z dystrybucją przez mniej standardowe kanały. Dla web developerów i zespołów DevOps oznacza to, że łatwiej będzie budować własne, firmowe rozszerzenia i dzielić się nimi jak z każdą inną zależnością JavaScript. Factory pokazuje, że korzysta z infrastruktury, którą developerzy już znają i której ufają.

    Źródła

  • Factory v0.148.1: podpisane binarki CLI stabilizują środowiska odcięte od sieci

    Factory v0.148.1: podpisane binarki CLI stabilizują środowiska odcięte od sieci

    Factory wydało wersję v0.148.1, która rozwiązuje istotny problem dla zespołów pracujących w środowiskach air-gapped. Aktualizacja zapewnia, że wszystkie binarki CLI są teraz poprawnie podpisywane i publikowane, co umożliwia instalacjom offline pobieranie najnowszych wersji bez ryzyka związanego z niezweryfikowanym oprogramowaniem.

    Poprawka trafiła do użytkowników 14 czerwca 2026 roku jako część wydania CLI v0.148.1 i Desktop v0.105.0. Choć na pierwszy rzut oka wygląda to na drobną zmianę konfiguracyjną, dla branż objętych ścisłymi regulacjami bezpieczeństwa oznacza koniec ręcznych obejść i potencjalnych luk w łańcuchu dostaw.

    Kluczowe fakty

    • Binarki CLI dla środowisk air-gapped są teraz podpisywane i publikowane, eliminując ryzyko instalacji nieautoryzowanych wersji.
    • Aktualizacja jest częścią szerszego pakietu usprawnień korporacyjnych Factory, obejmującego kontrolę ruchu sieciowego i zarządzanie logami.
    • Wdrożenia w sektorze obronnym i administracji państwowej korzystają z trybu fully air-gapped, gdzie Factory Cloud nie jest osiągalny podczas działania Droidów.
    • Weryfikacja binarek odbywa się przez artifact repositories i procesy offline, co wymaga zaufanego podpisu cyfrowego na każdym etapie dystrybucji.

    Dlaczego podpisywanie binarek ma znaczenie w odciętych środowiskach

    W standardowym modelu SaaS aplikacja pobiera aktualizacje bezpośrednio z serwerów producenta. Środowiska air-gapped odwracają tę logikę – wszystko, co trafia do wewnętrznej sieci, musi przejść przez bramki bezpieczeństwa, skanery i ręczne audyty. Nie ma tu miejsca na automatyczne pobieranie paczek z internetu.

    Droidy Factory działające w takim reżimie polegają na artefaktach importowanych przez repozytoria offline. Jeśli binarka CLI nie jest podpisana, system nie może potwierdzić jej integralności. W takim przypadku administratorzy albo blokują instalację, albo – co gorsza – dopuszczają ją na ślepo, narażając infrastrukturę na ataki typu supply chain.

    Poprawka z v0.148.1 eliminuje ten dylemat. Teraz każda wersja CLI przeznaczona dla środowisk izolowanych przechodzi pełną ścieżkę podpisywania, zanim trafi do kanałów dystrybucyjnych. Dla zespołów DevOps oznacza to mniej ręcznej pracy przy weryfikacji i krótszy czas od wydania nowej funkcji do jej wdrożenia na produkcji.

    Szerszy kontekst: kontrola nad ruchem i modelami

    Warto spojrzeć na tę aktualizację w kontekście całej strategii Factory dla klientów enterprise. Dokumentacja wdrożeniowa platformy opisuje model, w którym nie tylko binarki, ale też punkty końcowe modeli AI i kolektory OTEL pozostają wewnątrz izolowanej sieci.

    Factory umożliwia uruchamianie Droidów w konfiguracji fully air-gapped, gdzie jedynym połączeniem ze światem zewnętrznym jest zaplanowany import artefaktów. To domyślny wzorzec dla sektorów takich jak obronność czy administracja rządowa, gdzie wyciek danych przez niekontrolowany ruch sieciowy jest niedopuszczalny.

    Ostatnie miesiące przyniosły też inne usprawnienia w tym obszarze: lepszą widoczność połączeń MCP, nowe kontrolki organizacyjne dla automatycznych aktualizacji, usprawnione zarządzanie logami i odświeżone procesy uwierzytelniania. Wszystko to składa się na obraz platformy, która działa w izolacji w sposób przewidywalny i audytowalny.

    Co to oznacza dla zespołów developerskich

    Dla programistów pracujących z Factory na co dzień, v0.148.1 nie przynosi nowych funkcji w interfejsie ani zmian w API. To wydanie ma charakter czysto infrastrukturalny. Jednak jego wpływ na stabilność środowisk CI/CD może być odczuwalny natychmiast.

    Zespoły utrzymujące pipeline'y w odciętych sieciach często borykają się z problemem nieaktualnych narzędzi. Każda aktualizacja CLI wymagała dotąd sprawdzania sum kontrolnych, ręcznego podpisywania i konfiguracji zaufanych źródeł. Teraz ten proces jest zautomatyzowany po stronie Factory, a administratorzy otrzymują gotowe, zweryfikowane paczki.

    To jedna z tych poprawek, których nikt nie zauważa, dopóki nie przestanie działać. Ale właśnie takie detale decydują o tym, czy platforma nadaje się do użytku w środowiskach o zaostrzonych wymogach bezpieczeństwa.

    Źródła

  • Factory wzmacnia pracę offline – nowa wersja z lepszym wsparciem dla środowisk air-gapped

    Factory wzmacnia pracę offline – nowa wersja z lepszym wsparciem dla środowisk air-gapped

    Factory wypuściło wersję v0.148.1, która wprowadza ulepszone wsparcie dla środowisk odciętych od sieci (air-gapped). Teraz binarki CLI są poprawnie podpisywane i publikowane, co eliminuje problemy z weryfikacją w zamkniętych infrastrukturach. To kolejny krok w serii aktualizacji, które systematycznie poprawiają stabilność narzędzia.

    Kluczowe informacje

    • Wersja v0.148.1 zapewnia poprawne podpisywanie plików binarnych CLI dla środowisk bez dostępu do internetu.
    • Śledzenie połączeń MCP – nowy mechanizm monitoruje status serwerów MCP w czasie rzeczywistym.
    • Automatyczne aktualizacje można teraz kontrolować na poziomie całej organizacji.
    • Konfiguracje BYOK doczekały się poprawek eliminujących błędy uwierzytelniania modeli niestandardowych.

    Co dokładnie zmieniono w środowiskach air-gapped

    Praca w odizolowanych sieciach zawsze była wyzwaniem dla narzędzi chmurowych. Factory od dłuższego czasu rozwija możliwości offline, ale dopiero teraz uporządkowało kwestię podpisów cyfrowych. Wcześniej użytkownicy mogli napotkać problemy z weryfikacją integralności plików CLI, ponieważ systemy bezpieczeństwa w zamkniętych środowiskach często odrzucały niespójnie podpisane binarki.

    Wersja v0.148.1 rozwiązuje ten problem poprzez ustandaryzowany proces podpisywania. Każda publikacja przechodzi teraz przez automatyczną walidację, która gwarantuje zgodność z wymaganiami przedsiębiorstw. Dla zespołów pracujących w sektorach regulowanych, takich jak finanse, obronność czy administracja publiczna, to znaczna oszczędność czasu, ponieważ ręczna konfiguracja przestaje być konieczna.

    Warto również wspomnieć o powiązanych poprawkach z poprzednich wydań. Wersja v0.148.1 dodała obsługę proxy HTTPS, a wcześniejsza wersja naprawiła obsługę zmiennych proxy zapisanych małymi literami. Te zmiany przyczyniają się do spójniejszego działania w sieciach korporacyjnych.

    MCP, BYOK i kontrola organizacyjna – co jeszcze przynosi aktualizacja

    Nowe śledzenie statusu połączeń MCP to funkcja, która ułatwia debugowanie. Gdy serwer MCP traci autoryzację po reconnect (problem rozwiązany w v0.148.1), użytkownik widzi teraz dokładnie, co się dzieje. Dzięki temu unika się sytuacji, w której agent przestaje działać bez wyjaśnienia.

    Jeśli chodzi o modele BYOK, Factory naprawiło błąd z wersji v0.148.1 – endpoint bez działających poświadczeń nie próbuje już wielokrotnie ponawiać zapytań. Zamiast tego od razu zwraca czytelny komunikat. To istotna zmiana dla administratorów konfigurujących własne modele, ponieważ pozwala zaoszczędzić czas na debugowanie.

    Kontrola automatycznych aktualizacji na poziomie organizacji to kolejna nowość. Administrator może teraz zdecydować, czy cały zespół przechodzi na nową wersję od razu, czy lepiej wstrzymać się do testów. W połączeniu z zarządzaniem politykami modeli, aktualizacja ta oferuje solidny zestaw narzędzi do zarządzania.

    Stabilność CLI i zarządzanie logami

    Nie można pominąć mniej widocznych, ale praktycznych ulepszeń. Szybsze uruchamianie CLI, naprawione lifecycle hooki oraz samonaprawiające się cache pluginów sprawiają, że narzędzie mniej przeszkadza w pracy. Własne modele nie gubią już kontekstu z SessionStart hooków, a procesy w tle raportują prawdziwe PID-y.

    W kontekście logów Factory systematycznie porządkuje bałagan. Puste drafty sesji nie zaśmiecają już historii, a komunikaty o błędach połączenia stały się bardziej czytelne. Te zmiany, choć mogą wydawać się drobne, znacząco zmniejszają frustrację podczas codziennej pracy z agentem.

    Całość pokazuje, że Factory koncentruje się na poprawie niezawodności, zamiast dążyć do spektakularnych funkcji. W narzędziach deweloperskich stabilność ma kluczowe znaczenie, co czyni te aktualizacje wartościowymi dla użytkowników.

    Źródła

  • Factory wzmacnia bezpieczeństwo komend i sugeruje sesje w aktualizacji v0.144.0

    Factory wzmacnia bezpieczeństwo komend i sugeruje sesje w aktualizacji v0.144.0

    Zespół Factory wprowadził wersję v0.144.0 swojego środowiska programistycznego, która wprowadza inteligentne podpowiedzi sesji oraz rozbudowany system ostrzeżeń przed ryzykownymi operacjami w terminalu. Aktualizacja zawiera również poprawki obsługi klawiatury w tmuxie oraz stabilności uwierzytelniania MCP. Te zmiany są szczególnie przydatne dla osób pracujących zdalnie i w środowiskach wielosesyjnych.

    Co nowego w Factory v0.144.0

    • Inteligentne sugestie sesji — agent podpowiada pliki sesji na podstawie kontekstu pracy, co przyspiesza wznawianie zadań.
    • Ostrzeżenia o wysokim ryzyku — system flaguje destrukcyjne komendy shellowe jeszcze przed ich wykonaniem.
    • Poprawiona obsługa tmuxa — klawisze działają stabilniej w środowiskach multipleksowanych.
    • Lepsza autoryzacja MCP — cichsze odświeżanie tokenów i eliminacja zbędnych monitów.

    Inteligentniejsze sesje: mniej zgadywania, więcej akcji

    Nowy mechanizm sugestii plików sesji analizuje historię pracy i bieżący kontekst projektu. Agent wskazuje, którą sesję warto wznowić, eliminując potrzebę ręcznego przeszukiwania listy, co jest szczególnie przydatne przy przełączaniu się między równoległymi zadaniami.

    Wcześniejsze wydania Factory miały problemy z korupcją historii sesji przy anulowaniu narzędzi, co zostało naprawione w wersji v0.144.0. Teraz dodano warstwę predykcyjną, która aktywnie podsuwa właściwy punkt startowy, zamiast tylko zabezpieczać integralność zapisów.

    Każdy, kto pracuje nad kilkoma gałęziami projektowymi jednocześnie, wie, ile czasu można stracić na szukanie odpowiedniego kontekstu. Ta zmiana powinna zredukować tarcie podczas codziennego korzystania z narzędzia.

    Bezpieczeństwo komend: ryzyko pod kontrolą

    Nowością jest system ostrzegania przed komendami wysokiego ryzyka. Factory wcześniej eksperymentowało z klasyfikacją operacji, a w CLI v0.144.0 zmieniono git push z średniego na wysokie ryzyko. Mechanizm wydaje się teraz bardziej dojrzały.

    Gdy agent wykryje potencjalnie destrukcyjną operację shellową, wyświetla ostrzeżenie i wymaga jawnej zgody. Obejmuje to operacje modyfikujące system plików poza katalogiem projektu, komendy sieciowe ingerujące w konfigurację oraz polecenia nadpisujące dane bez możliwości cofnięcia.

    To rozsądne posunięcie, zwłaszcza że sandboxing w Factory został wzmocniony w wersji v0.144.0. Dwie warstwy zabezpieczeń (izolacja procesów oraz flagowanie ryzyka) zapewniają lepszą ochronę niż poleganie na jednym mechanizmie.

    Tmux i klawiatura: detale, które robią różnicę

    Użytkownicy pracujący przez tmuxa odczują poprawę w obsłudze zdarzeń klawiatury. W multipleksowanych terminalach niektóre kombinacje klawiszy były błędnie interpretowane, szczególnie te z modyfikatorami. Wersja v0.144.0 rozwiązuje ten problem, co potwierdza trend z późniejszych wydań, w których dodano klikalne linki w tmuxie.

    MCP również zyskało na wydajności w zakresie autoryzacji. Ciche odświeżanie tokenów oraz eliminacja powtarzających się monitów o uwierzytelnienie to zmiany zauważalne w środowiskach z wieloma serwerami i złożoną konfiguracją OAuth.

    Stabilność i wydajność łączników

    Kolejnym obszarem poprawek jest wydajność połączeń MCP. Łączniki działają teraz sprawniej, a time-outy są lepiej zarządzane. Wprowadzono per-serwerowy connectTimeout dla wolno startujących serwerów MCP.

    Podsumowanie

    Aktualizacja v0.144.0 nie jest przełomowa, ale wprowadza istotne poprawki w zakresie bezpieczeństwa operacji shellowych oraz wygody nawigacji między sesjami. Osoby intensywnie korzystające z terminala i pracujące w wielu kontekstach projektowych zyskają na oszczędności czasu dzięki nowym sugestiom sesji, a system ostrzeżeń może pomóc uniknąć przypadkowego wykonania destrukcyjnych komend.

    Źródła

  • Factory stawia na GitLaba CI – nowa wersja 0.142.0 z obsługą komponentów i poprawkami stabilności

    Factory stawia na GitLaba CI – nowa wersja 0.142.0 z obsługą komponentów i poprawkami stabilności

    Factory wydał wersję 0.142.0 swojej platformy, wprowadzając wsparcie dla GitLab CI Components w umiejętności install-code-review. Ta aktualizacja automatyzuje pipeline’y do przeglądu kodu i eliminuje kilka błędów w interfejsie, w tym dublujące się wiadomości w czacie. Wydanie jest skierowane głównie do zespołów deweloperskich, które chcą zredukować powtarzalną konfigurację CI i wykorzystać ponownie używalne komponenty.

    Kluczowe informacje o wydaniu

    • GitLab CI Components są teraz wspierane w umiejętności install-code-review, co upraszcza pipeline’y automatycznej analizy kodu.
    • Naprawiono podwójne wiadomości – czat nie wyświetla już zduplikowanych komunikatów w trakcie sesji.
    • Odświeżanie podglądu diffa działa teraz poprawnie, bez opóźnień i braku synchronizacji.
    • Mniejsze duplikowanie kodu w .gitlab-ci.yml dzięki modelowi komponentowemu GitLaba.
    • Stabilniejsza praca całej platformy Factory przy zarządzaniu recenzjami kodu.

    Co właściwie daje integracja z GitLab CI Components

    GitLab promuje model komponentów CI/CD jako sposób na unikanie kopiowania tych samych fragmentów konfiguracji między projektami. Komponent to samodzielny, wersjonowany kawałek logiki pipeline’a, który można wciągnąć dyrektywą include:component. Zamiast pisać osobne joby do lintowania czy analizy statycznej, zespół może korzystać z gotowego bloku.

    Factory w wersji 0.142.0 wykorzystuje ten mechanizm w install-code-review. Umiejętność ta pozwala uruchomić automatyczny przegląd kodu bezpośrednio z poziomu pipeline’a GitLaba. Oznacza to, że po wypchnięciu commita system automatycznie uruchomi analizę, a wyniki będą dostępne w interfejsie Factory – bez potrzeby dodatkowych skryptów.

    Dla zespołów devopsowych to oszczędność czasu, ponieważ konfiguracja sprowadza się do wskazania odpowiedniego komponentu w pliku .gitlab-ci.yml. Resztą zajmuje się platforma.

    UI bez frustracji – diff viewer i czat pod kontrolą

    UI bez frustracji – diff viewer i czat pod kontrolą

    Obok nowości w integracji CI, Factory 0.142.0 wprowadza również dwie poprawki, które wpływają na komfort codziennej pracy. Pierwsza dotyczy podglądu różnic w kodzie – diff viewer. W poprzednich wersjach panel czasami nie odświeżał się po zmianie pliku, co prowadziło do wyświetlania nieaktualnego stanu. Teraz odświeżanie działa natychmiastowo, co sprawia, że przeglądanie zmian jest płynne.

    Druga poprawka eliminuje dublowanie wiadomości w czacie. Każdy, kto spędził czas na przeglądzie kodu, wie, jak dezorientujące może być pojawienie się tej samej linijki tekstu dwa razy. Factory naprawiło ten błąd, co poprawia czytelność komunikacji w zespole.

    Dlaczego akurat teraz ma to znaczenie

    Dlaczego akurat teraz ma to znaczenie

    Automatyzacja recenzji kodu zyskuje na znaczeniu w projektach opartych na szybkim kodowaniu i iteracjach. Gdy zespół wprowadza wiele zmian dziennie, ręczne przeglądanie każdego merge requestu staje się nieefektywne. Factory z obsługą GitLab CI Components wchodzi w ten moment, oferując automatyzację, która nie wymaga pisania własnych pipeline’ów od podstaw.

    Kierunek obrany przez Factory pokrywa się z trendem w narzędziach AI dla deweloperów. Coraz więcej platform integruje się z istniejącymi systemami CI/CD, zamiast budować zamknięte ekosystemy. GitLab, ze swoim modelem komponentowym, oferuje solidny fundament – wersjonowane bloki logiki, które można testować i udostępniać między repozytoriami.

    Podsumowanie

    Wydanie 0.142.0 to krok w stronę lepszej integracji Factory z ekosystemem GitLaba. Wsparcie dla komponentów CI w install-code-review eliminuje powtarzalną pracę przy konfiguracji pipeline’ów, a poprawki UI sprawiają, że codzienna praca z platformą staje się bardziej zorganizowana. Dla zespołów korzystających z GitLab CI, ta aktualizacja jest warta szybkiego wdrożenia – mniej konfiguracji, mniej błędów i płynniejszy przegląd kodu w jednym pakiecie.

    Źródła

  • Factory wzbogaca GitLaba o CI Components i gasi pożary stabilności

    Factory wzbogaca GitLaba o CI Components i gasi pożary stabilności

    Factory wzbogaca GitLaba o CI Components i gasi pożary stabilności

    Factory wypuściło wersję v0.142.0, w której użytkownicy zyskali możliwość bezpośredniej konfiguracji pipeline'ów code review przez GitLab CI Components. To pierwsze tak zaawansowane połączenie obu narzędzi – zamiast korzystać z zewnętrznych skryptów, Factory integruje się z mechanizmami CI GitLaba. Równocześnie zespół naprawił problem z duplikowaniem wiadomości w czacie oraz poprawił logikę odświeżania w przeglądarce diffów. To wydanie koncentruje się na inżynieryjnym porządkowaniu, co jest korzystne dla użytkowników.

    Kluczowe zmiany w Factory v0.142.0

    • GitLab CI Components pozwalają teraz na konfigurację pipeline'ów code review bezpośrednio z poziomu Factory.
    • Zduplikowane wiadomości w czacie zostały usunięte – poprawka dotyczy wielu obszarów jednocześnie.
    • Przeglądarka diffów zyskała ulepszoną logikę odświeżania, co eliminuje wizualne artefakty przy przełączaniu plików.
    • GitLab self-hosted działa teraz przez dedykowany flow OAuth, eliminując potrzebę ręcznego wklejania tokena.
    • Obserwowalność wchodzi w zakres uprawnień integracji – GitLab musi otrzymać scope'y read_observability i write_observability.

    GitLab CI Components zamiast klejenia na taśmę

    Dotychczas Factory wspierało GitLaba głównie poprzez aplikację OAuth dla instancji self-hosted. Konfiguracja wymagała stworzenia użytkownika „Factory Droid”, nadania mu odpowiednich uprawnień oraz autoryzacji przez panel Repository Selection. Funkcjonalne, ale bez większych innowacji.

    Wersja v0.142.0 dodaje możliwość konfiguracji pipeline'ów code review przez GitLab CI Components. Dla zespołów DevOps oznacza to, że Factory staje się integralną częścią cyklu CI. Można teraz wpiąć agenta code review bezpośrednio w joby GitLaba, korzystając z komponentów CI, które GitLab udostępnia jako standardowy mechanizm reużywalnych konfiguracji.

    Co ciekawe, zakres uprawnień wykracza poza standardowe read_repository i write_repository. Factory wymaga również dostępów do obserwowalności – read_observability i write_observability. To sugeruje, że integracja obejmuje nie tylko podgląd kodu, ale także metryki i logi środowiska CI. Dla osób zarządzających większą liczbą repozytoriów, taki poziom integracji ma znaczenie.

    Stabilność zamiast wodotrysków

    Oprócz nowości związanych z GitLabem, v0.142.0 rozwiązuje dwa istotne problemy. Pierwszy to zduplikowane wiadomości w czacie – problem występował w wielu obszarach i mógł dezorientować użytkowników. Drugi dotyczy przeglądarki diffów, gdzie logika odświeżania mogła wyświetlać nieaktualny stan pliku przy szybkim przełączaniu między zmianami. Obie poprawki są mniej widowiskowe, ale kluczowe dla codziennej pracy z narzędziem.

    W tle widać również, że Factory aktywnie pracuje nad problemami pamięciowymi w integracji z GitLabem. Wcześniejsze wydanie naprawiło błąd out-of-memory w aplikacji Factory, więc v0.142.0 kontynuuje ten porządkowy trend. Nie ma tu efektu wow, ale jest systematyczne zamykanie technicznego długu.

    Self-hosted i OAuth – o tym warto wiedzieć

    Dla zespołów korzystających z własnych instancji GitLaba, setup jest już dobrze dopracowany. Factory używa aplikacyjnego flow OAuth z redirect URI (https://app.factory.ai/api/integrations/redirect/gitlab-sh) i wymaga utworzenia użytkownika Factory Droid przed autoryzacją. Repozytoria pojawiają się w panelu selekcji, a nie są zgadywane na podstawie URL-u czy ścieżki.

    To podejście eliminuje ręczne zarządzanie tokenami, ale wprowadza dodatkowe kroki przy pierwszym setupie. Jednak po skonfigurowaniu działa solidnie – zwłaszcza teraz, gdy zespół Factory rozwiązał problemy z wyciekami pamięci w tej integracji.

    Co dalej dla użytkowników Factory

    Wydanie v0.142.0 to nie rewolucja, ale istotny krok w kierunku dojrzałości narzędzia. GitLab przestaje być integracją drugorzędną i staje się pełnoprawnym partnerem w pipeline'ach code review. Jeśli wasz zespół korzysta z self-hostowanego GitLaba i rozważa automatyzację przeglądów kodu, to wydanie może być dobrym momentem, aby dać Factory szansę. Zwłaszcza że zduplikowane wiadomości i problemy z lagami w diffach zostały rozwiązane.

    Źródła

  • Factory ulepsza obsługę dużych wyników poleceń i poprawia stabilność Droidów

    Factory ulepsza obsługę dużych wyników poleceń i poprawia stabilność Droidów

    Factory wypuściło aktualizację v0.141.0, która koncentruje się na bardziej niezawodnym wykonywaniu poleceń generujących duże ilości danych. To krok w stronę stabilniejszego środowiska deweloperskiego, które nie zawiesza się przy intensywnych operacjach.

    Najważniejsze zmiany w skrócie

    • Obsługa obszernych wyników poleceń została przeprojektowana, aby zapobiec awariom przy długich outputach.
    • Poprawiono rozmieszczenie podpowiedzi w interfejsie użytkownika, co eliminuje problemy z nakładaniem się elementów.
    • Droidy działają teraz stabilniej w projektach, które nie korzystają z Gita.
    • Wcześniejsze wydania pokazują, że Factory konsekwentnie inwestuje w niezawodność agentów i czytelność UI.

    Większa odporność na przeciążenia

    Przetwarzanie długich wyników poleceń od dawna stanowi problem w środowiskach deweloperskich opartych na agentach AI. Gdy output przekracza pewien rozmiar, system może się zawiesić, a sesja może zostać utracona. W wersji v0.141.0 Factory wprowadza mechanizmy, które radzą sobie z tym lepiej.

    Choć oficjalny dziennik zmian dla tej wersji nie został upubliczniony, wcześniejsze wydania Factory pokazują wyraźny wzorzec. Wersja 1.6 wprowadziła przycinanie wyników przekraczających limit i wymuszała limity rozmiaru wiadomości, aby chronić integralność danych. Wersja v0.141.0 kontynuuje tę tendencję, ale z większą precyzją. Celem jest nie tylko zapobieganie awariom systemu, ale także umożliwienie deweloperom zachowania kontekstu i uniknięcia powtarzania pracy.

    UI bez irytujących wpadek

    Kolejną istotną zmianą jest poprawa rozmieszczenia podpowiedzi w interfejsie. Każdy, kto korzystał z zaawansowanych narzędzi CLI, wie, że źle umieszczone podpowiedzi mogą zakłócać pracę. Nachodzące na siebie elementy i podpowiedzi pojawiające się w niewłaściwych miejscach to drobiazgi, które mogą prowadzić do frustracji.

    Aktualizacja v0.141.0 porządkuje te elementy. Wcześniejsze wersje, takie jak 0.182.0, poprawiały już nagłówki i stan interfejsu podczas wykonywania narzędzi. Teraz Factory skupia się na szczegółach — podpowiedzi trafiają tam, gdzie ich miejsce, co ułatwia pracę.

    Droidy w projektach bez Gita

    Zmiana dotycząca zachowania Droidów — autonomicznych agentów Factory — w projektach, w których Git nie jest używany, również zasługuje na uwagę. Wcześniej niektóre funkcje mogły nie działać prawidłowo w braku repozytorium, opierając się na założeniu, że projekt zawsze jest pod kontrolą wersji. Wiele zespołów pracuje lokalnie, korzysta z innych systemów kontroli wersji lub rezygnuje z nich na wczesnych etapach prototypowania.

    Factory dostosowuje algorytmy wykrywania katalogu głównego projektu i odświeżania przestrzeni roboczej. Droidy nie gubią się już, gdy nie widzą folderu .git — po prostu działają.

    Konsekwentny kierunek

    Analizując historię wydań Factory, widać, że to nie przypadkowy zbiór poprawek. Od wersji 1.3, przez 1.6, aż po ostatnie buildy z lipca 2026 — firma regularnie poprawia obszary niezawodności i użyteczności. Wprowadzono między innymi piaskownicę dla procesów na macOS, poprawki sesji MCP oraz zwiększoną odporność na uszkodzenia historii sesji.

    Te zmiany tworzą obraz narzędzia, które dojrzewa. Factory nie goni za spektakularnymi nowościami, lecz konsekwentnie usuwa przeszkody w codziennej pracy dewelopera. W obliczu szybkiego rozwoju AI w kodowaniu, jest to prawdopodobnie najlepsza strategia.

    Źródła

  • Factory v0.141.0: solidniejsza obsługa długich wyników poleceń i drobne poprawki

    Factory v0.141.0: solidniejsza obsługa długich wyników poleceń i drobne poprawki

    Nowa wersja Factory, oznaczona numerem v0.141.0, koncentruje się na zwiększeniu niezawodności w pracy z obszernymi wynikami poleceń. Aktualizacja nie wprowadza nowych funkcji, ale rozwiązuje kilka problemów, które mogły wpływać na codzienną pracę z narzędziem. Udoskonalone zostało również wykrywanie plików guideline w projektach spoza Gita oraz poprawiono rozmieszczenie podpowiedzi w interfejsie.

    Kluczowe zmiany w skrócie

    • Niezawodność – agent lepiej radzi sobie z długimi wynikami poleceń, które wcześniej mogły powodować błędy
    • Pliki guideline – poprawiono ich wykrywanie w projektach, gdzie nie korzysta się z Gita
    • Umiejscowienie podpowiedzi – input hinty wyświetlają się teraz w odpowiednich miejscach
    • Wydajność – mniejsze zużycie pamięci przy długich i bezczynnych sesjach

    Większa stabilność przy dużych wyjściach

    Głównym celem tej wersji jest poprawiona obsługa rozbudowanych wyników poleceń. Oznacza to, że gdy agent wykonuje komendę generującą tysiące linii tekstu – na przykład logi builda, output testów czy zrzut bazy danych – nie powinien już gubić danych ani się zawieszać.

    Problem ten był szczególnie widoczny przy zadaniach ciągłych, gdzie output rósł stopniowo. Wcześniejsze wersje mogły ucinać wyniki lub odmawiać współpracy po przekroczeniu pewnego progu. Teraz agent lepiej radzi sobie z tymi danymi, a cały proces jest bardziej przewidywalny – nie ma potrzeby dzielenia zadań na mniejsze kawałki, aby obejść ograniczenia.

    Lepsze wyczucie kontekstu projektu

    Kolejna zmiana dotyczy plików guideline, które informują agenta o zachowaniu w danym repozytorium. Wcześniej Factory zakładało, że każdy projekt jest pod kontrolą Gita, co nie zawsze jest prawdą. Nie każdy folder z kodem to repozytorium, a czasem użytkownicy testują coś lokalnie bez inicjowania systemu kontroli wersji.

    W wersji v0.141.0 mechanizm wykrywania guideline’ów działa również poza strukturami Gita. Dla osób prototypujących lub pracujących na fragmentach większych projektów to istotna zmiana. Agent nie gubi kontekstu tylko dlatego, że zapomniano wykonać git init.

    Podpowiedzi na swoim miejscu

    Poprawiono również umiejscowienie input hintów, które pojawiają się przy polach tekstowych. Wcześniej mogły wyświetlać się w nieodpowiednich miejscach, nachodzić na inne elementy interfejsu lub znikać w trakcie pisania.

    Teraz podpowiedzi są bliżej kursora i nie przeszkadzają w pracy. Choć to drobny szczegół, w dłuższych sesjach z CLI takie zmiany mogą znacząco poprawić komfort użytkowania. Deweloperzy Factory najwyraźniej dostrzegli ten problem.

    Pod maską – mniej pamięci, więcej porządku

    Aktualizacja kontynuuje prace nad optymalizacją pamięci, które były widoczne w poprzednich wersjach. Długie sesje i okresy bezczynności nie powodują już tak dużego wzrostu zużycia RAM-u. Dla użytkowników, którzy pozostawiają Factory otwarte przez cały dzień, to realna oszczędność zasobów.

    Kontekst i co dalej

    Analizując historię wydań Factory, można zauważyć, że zespół od miesięcy pracuje nad stabilnością. Wcześniejsze wersje wprowadziły sandboxing na macOS, lepszą obsługę MCP oraz mission side panel. Wersja v0.141.0 wpisuje się w ten trend – nie wprowadza rewolucyjnych nowości, ale poprawia działanie istniejących funkcji.

    Jeśli regularnie korzystasz z agenta generującego długie outputy, ta aktualizacja jest dla ciebie. Nawet jeśli nie, warto ją zainstalować, ponieważ poprawki błędów mogą okazać się przydatne w najmniej oczekiwanych momentach.

    Źródła

  • Factory rozszerza wsparcie dla Claude Opus 4.8 i Gemini 3.5 Flash, dodaje automatyczne śledztwo w alertach

    Factory rozszerza wsparcie dla Claude Opus 4.8 i Gemini 3.5 Flash, dodaje automatyczne śledztwo w alertach

    Factory wprowadziło aktualizację, która dodaje wsparcie dla nowych modeli oraz nowy mechanizm reagowania na incydenty. Droid może teraz automatycznie badać alerty, co znacznie ułatwia pracę zespołów DevOps podczas dyżurów. Dodatkowo, aktualizacja obejmuje integracje MCP oraz poprawki stabilności terminala.

    Kluczowe zmiany w pigułce

    • Nowe modele dostępne od ręki — planują pracę, uruchamiają setki równoległych podagentów i weryfikują wyniki przed raportowaniem.
    • Szybkie modele wchodzą do puli jako opcja zoptymalizowana pod kątem szybkości i kosztów.
    • Automatyczne badanie alertów przez Droida — incydent ląduje na kanale, agent zaczyna diagnostykę bez ręcznej interwencji.
    • Integracje MCP ułatwiają zarządzanie rozbudowanymi łańcuchami narzędziowymi.
    • Poprawki stabilności terminala i pętli agenta eliminują irytujące błędy przy długich sesjach.

    Nowe modele — dłuższe agenty, samokontrola i ta sama cena

    Dostępne modele, w tym Claude Opus 4.8 oraz Gemini 3.5 Flash, potrafią rozplanować zadanie i uruchomić setki równoległych podagentów w jednej sesji. Agenty mogą działać znacznie dłużej niż w poprzedniej wersji, a przed oddaniem wyników model sam je weryfikuje. To ważne przy agentowym kodowaniu — zamiast ręcznie przeglądać każdy wynik, otrzymujesz coś, co już przeszło wewnętrzną kontrolę.

    Ceny pozostają na poziomie 5 dolarów za milion tokenów na wejściu i 25 dolarów za milion na wyjściu. Tryb szybki kosztuje odpowiednio 10 i 50 dolarów. Zmiana dotycząca cache'owania promptów polega na obniżeniu minimalnej długości z 2048 do 1024 tokenów, co przy częstych zapytaniach do tych samych kontekstów przynosi realne oszczędności.

    Nowością w Messages API jest możliwość wrzucania system entries bezpośrednio do tablicy messages, co pozwala na aktualizację instrukcji w trakcie zadania bez zrywania cache'owania promptów. To przydatne, gdy agent dostaje nowe wytyczne w trakcie pracy i nie chcemy tracić kontekstu.

    Szybkie modele i MCP — szybkość i porządek w narzędziach

    Szybkie modele są odpowiedzią na potrzeby zespołów, które priorytetowo traktują szybkość działania i niskie koszty. Model sprawdzi się w scenariuszach z dużą liczbą zapytań, gdzie nie jest wymagane głębokie rozumienie, ale liczy się responsywność. Factory nie podało własnych benchmarków ani cennika dla tego modelu, więc konieczne będzie samodzielne przetestowanie jego wydajności w codziennej pracy.

    Integracje MCP rozwiązują problem, który narasta wraz z rozbudową toolchainu. Zamiast ładować wszystko z góry do pamięci lub trzymać sztywną konfigurację, Droid znajduje odpowiednie narzędzie w momencie, gdy jest potrzebne. Przy dużych setupach to różnica między chaosem a użytecznym zestawem narzędzi.

    Reagowanie na incydenty — Droid przejmuje Slacka

    Nowy workflow reagowania na incydenty to istotny element tej aktualizacji. Gdy alert trafia na kanał Slacka, Droid automatycznie rozpoczyna badanie. Nie trzeba klikać, potwierdzać ani ręcznie uruchamiać diagnostyki — agent sam zbiera kontekst, sprawdza logi i raportuje wnioski.

    Dla zespołów DevOps i SRE oznacza to skrócenie czasu od wykrycia problemu do pierwszej diagnozy. Zamiast budzić człowieka o trzeciej nad ranem, aby kliknął "investigate", Droid wykonuje wstępną robotę samodzielnie. Oczywiście nie zastąpi doświadczonego inżyniera przy złożonych awariach, ale potrafi odsiać fałszywe alarmy i przygotować grunt pod dalsze działania.

    Stabilność i drobne poprawki

    Aktualizacja przynosi również zestaw mniej spektakularnych, ale potrzebnych poprawek. Terminal przestał gubić znaki przy szybkim przewijaniu, a pętla agenta działa płynniej — koniec z zawieszaniem się przy powtarzających się wywołaniach narzędzi. To zmiany, które nie trafiają na pierwsze strony, ale przy codziennej, wielogodzinnej pracy robią realną różnicę.

    Co to znaczy w praktyce

    Ta aktualizacja to nie tylko dodanie nowych modeli do listy. To krok w stronę bardziej aktywnego uczestnictwa Droida w procesach operacyjnych. Automatyczne badanie alertów, dłuższe sesje agentów z samokontrolą oraz sprawniejsze zarządzanie narzędziami przyczyniają się do środowiska, w którym mniej czasu spędza się na rutynowych zadaniach, a więcej na rzeczywistym rozwiązywaniu problemów.

    Źródła