Tag: oprogramowanie open source

  • Kimi K2.7 Code wchodzi do gry – Moonshot AI rzuca wyzwanie Claude i GPT w długodystansowym kodowaniu

    Kimi K2.7 Code wchodzi do gry – Moonshot AI rzuca wyzwanie Claude i GPT w długodystansowym kodowaniu

    Moonshot AI wprowadziło 12 czerwca 2026 roku model Kimi K2.7 Code, który jest ich najnowszym asystentem do programowania. Model ten został zaprojektowany z myślą o długoterminowych zadaniach inżynierskich, obsługuje długie konteksty oraz autonomiczne narzędzia. Użytkownicy mogą uzyskać do niego dostęp przez API, Hugging Face oraz środowisko Kimi Code.

    • Kimi K2.7 Code jest modelem stworzonym do długodystansowych zadań programistycznych, który lepiej radzi sobie z różnymi językami oraz z frontendem, DevOpsem i optymalizacją wydajności.
    • 256-tysięczne okno kontekstowe oraz tryb myślący (bez szybkich odpowiedzi) – model został zoptymalizowany do złożonego, wieloetapowego rozumowania.
    • Około 30% mniej tokenów rozumowania w porównaniu do Kimi K2.6 Code przy tych samych zadaniach, co prowadzi do niższych kosztów inferencji.
    • Ceny API: 0,95 USD za milion tokenów wejściowych, 4 USD za milion wyjściowych oraz 0,19 USD przy trafieniach cache’a – model jest dostępny na licencji Modified MIT.

    Model dostosowany do agentowego kodu

    Kimi K2.7 Code nie jest jedynie poprawioną wersją swojego poprzednika. Moonshot AI określa go jako „najbardziej zdolny model do kodowania”, który został dostosowany do agentowego generowania kodu oraz długoterminowej inżynierii oprogramowania. Model ma na celu lepsze radzenie sobie z zadaniami wymagającymi wielu kroków, wywoływania narzędzi oraz utrzymania spójności w długich kontekstach.

    Dokumentacja wskazuje na znaczną poprawę w zadaniach długohoryzontalnych. Kimi K2.7 Code lepiej generalizuje między Rustem, Go i Pythonem, a także poprawia efektywność w projektach frontendowych, automatyzacji DevOps i optymalizacji wydajności. Dla zespołów korzystających z vibe coding lub autonomicznych agentów, model ten może obsługiwać bardziej złożone zadania niż tylko krótkie fragmenty kodu.

    Duże okno i jeden tryb

    Model dysponuje oknem kontekstowym o długości 256 tysięcy tokenów i nie obsługuje trybu niemyślącego – cała komunikacja odbywa się poprzez ścieżkę rozumowania. Dla programistów przyzwyczajonych do szybkich odpowiedzi od GPT czy Claude, może to być zauważalna różnica w interakcji, ale zapewnia, że model nie uprości skomplikowanej logiki.

    Moonshot informuje o redukcji tokenów rozumowania o około 30% w porównaniu do Kimi K2.6 Code. Oznacza to, że nowa architektura lub proces treningowy pozwoliły modelowi myśleć bardziej zwięźle, nie tracąc jakości. Mniejsza liczba tokenów przekłada się również na niższe koszty przy wywołaniach API.

    Ceny, licencja i możliwości testowania

    Dostęp do Kimi K2.7 Code można uzyskać przez Moonshot API, narzędzie Kimi Code (terminalowy/IDE agent) oraz repozytorium na Hugging Face. Model jest dostępny na licencji Modified MIT, co oznacza, że w przeciwieństwie do niektórych konkurencyjnych rozwiązań, nie ma ograniczeń dotyczących komercyjnego wykorzystania.

    Ceny wynoszą: 0,95 USD za milion tokenów wejściowych, 4 USD za milion wyjściowych oraz 0,19 USD za cache. W przypadku długich kontekstów i powtarzalnych promptów, te stawki mogą być korzystne. W porównaniu do modeli takich jak Claude czy GPT, Kimi K2.7 Code może być bardziej opłacalnym rozwiązaniem.

    Rodzina K2 i jej znaczenie dla web deweloperki

    Kimi K2.7 Code to kolejny krok po modelu Kimi K2.6 Code, który Moonshot promowało jako otwarte narzędzie do kodowania, długoterminowej egzekucji oraz agentów. Seria K2 opiera się na architekturze Mixture-of-Experts, która według wcześniejszych zapowiedzi ma bilion parametrów, z czego 32 miliardy są aktywowane podczas inferencji. Nowsze informacje sugerują, że Kimi K2.7 Code utrzymuje podobną skalę, chociaż oficjalne specyfikacje nie zostały jeszcze w pełni ujawnione.

    Dla programistów pracujących z Kimi K2.7 Code, model ten oferuje nowe możliwości w zakresie długoterminowego kodowania i bardziej złożonych projektów.

  • Majowa aktualizacja OpenCode: Pełne wsparcie proxy w desktopie i nowy przepływ sesji

    Majowa aktualizacja OpenCode: Pełne wsparcie proxy w desktopie i nowy przepływ sesji

    Majowa aktualizacja OpenCode przyniosła wersję 1.17.4, która jest szczególnie ważna dla deweloperów pracujących w środowiskach korporacyjnych. Oprogramowanie rozwija wsparcie dla serwerów proxy i niestandardowych certyfikatów bezpieczeństwa, a także poprawia zarządzanie sesjami. Choć nie wprowadza spektakularnych nowości, odpowiada na potrzeby zgłaszane przez użytkowników na GitHubie i forach społeczności.

    Kluczowe zmiany w skrócie

    – OpenCode obsługuje standardowe zmienne proxy (HTTP_PROXY, HTTPS_PROXY), co potwierdza dokumentacja.
    – Obsługa niestandardowych urzędów certyfikacji (CA) jest dostępna dla ruchu przez proxy oraz bezpośrednich połączeń z API modeli – konfiguracja jest opisana w oficjalnych materiałach.
    – Udoskonalono przepływ pracy z sesjami, aby zminimalizować ryzyko utraty kontekstu przy przełączaniu zadań.
    – Rozwój funkcji zarządzania wieloma projektami – OpenCode zwiększa możliwości pracy równoległej.
    – Wprowadzono poprawki stabilności i interfejsu dla użytkowników systemu Windows.

    Dlaczego wsparcie proxy pozostaje priorytetem dla firm

    Dla użytkowników OpenCode korzystających z domowych łączy temat zmiennych proxy może wydawać się mało istotny. W rzeczywistości jednak wielu deweloperów pracuje w środowiskach korporacyjnych, gdzie cały ruch sieciowy przechodzi przez firmowe serwery pośredniczące. Bez odpowiedniej obsługi HTTPS_PROXY agent AI nie może nawiązać połączenia z żadnym modelem językowym, co czyni go bezużytecznym.

    OpenCode dokumentuje wsparcie dla zmiennych środowiskowych proxy i niestandardowych certyfikatów – w oficjalnych materiałach technicznych można przeczytać, że oprogramowanie „wspiera standardowe zmienne proxy i niestandardowe certyfikaty”. Oznacza to, że w środowiskach skonfigurowanych zgodnie z dokumentacją agent powinien komunikować się przez firmowe proxy. Wątki na GitHubie pokazują, że niektóre instalacje napotykały trudności, co skłaniało zespół do ciągłych poprawek.

    Aktualizacja v1.17.4 nie przyniosła rewolucji, ale wpisuje się w długofalowe działania na rzecz niezawodności. OpenCode wykrywa zmienne proxy zgodnie z konfiguracją systemową, a zaufanie do firmowych CA można ustanowić jednorazowo. Dla zespołów IT kluczowe jest, że nie ma potrzeby ręcznego ingerowania w pliki konfiguracyjne poza standardowymi zmiennymi środowiskowymi.

    W środowiskach o zaostrzonej polityce bezpieczeństwa – takich jak sektor finansowy czy rządowy – proxy i niestandardowe certyfikaty są niezbędne. Bez nich narzędzie AI nie przejdzie audytu bezpieczeństwa, co wyklucza je z wielu projektów komercyjnych. Dlatego każda iteracja OpenCode, która zapewnia stabilną pracę w tych warunkach, jest dla firm istotna.

    Udoskonalenia w zarządzaniu sesjami

    Zespół OpenCode pracuje nad tym, by przełączanie między zadaniami nie prowadziło do utraty kontekstu – to jeden z najczęściej podnoszonych postulatów społeczności. Dotychczas nagłe zamknięcie karty lub szybkie przechodzenie między projektami mogło prowadzić do frustracji, gdy prompt i wybór środowiska były niezgodne.

    Nowa wersja rozwija mechanizmy porządkujące ten proces – użytkownik ma teraz większą kontrolę nad kontekstem pracy. Flow sesji został przeprojektowany, aby dać więcej czasu na doprecyzowanie zapytania i wskazanie projektu, zanim agent zacznie działać.

    Usprawnienia obejmują także jednoczesną pracę nad wieloma projektami. OpenCode lepiej radzi sobie ze zmianą środowiska, minimalizując konieczność ręcznego odtwarzania ustawień przy przełączaniu kontekstu. To docenią zwłaszcza osoby pracujące z kilkoma repozytoriami jednocześnie.

    Bieżące poprawki na platformie Windows

    Użytkownicy Windowsa mogą liczyć na regularne poprawki stabilności aplikacji OpenCode – dotyczą one zarówno elementów interfejsu (w tym paska tytułu), jak i procesu aktualizacji z wcześniejszych instalacji. Każda nowa łatka przybliża środowisko Windows do poziomu płynności znanego z Linuksa czy macOS, a aktualizacja 1.17.4 eliminuje kilka rzadkich przypadków błędów renderowania i usprawnia migrację ze starszych wersji.

    Źródła

  • Windsurf Editor 2.2.17: Devin integruje się jeszcze głębiej, a wydajność zyskuje nowy blask

    Windsurf Editor 2.2.17: Devin integruje się jeszcze głębiej, a wydajność zyskuje nowy blask

    Czerwcowa aktualizacja Windsurf Editor w wersji 2.2.17 to kolejny krok w rebrandingu znanego środowiska programistycznego na Devin Desktop. Zmiana dotyczy jedynie nazwy, a nie funkcjonalności. Twórcy z Cognition skoncentrowali się na usprawnieniach interfejsu Agent Command Center, wprowadzeniu lokalnego agenta Devin Local oraz poprawkach stabilności, szczególnie dla użytkowników Windows.

    Kluczowe informacje o aktualizacji

    • Devin Local – agent działa teraz lokalnie w terminalu, oferując do 30% większą wydajność tokenową w porównaniu do Cascade, według przeprowadzonych testów.
    • Agent Command Center – odświeżony interfejs z widokiem Spaces, tablicą Kanban i zarządzaniem wieloma agentami.
    • Poprawki dla Windows – naprawiono błąd związany z tworzeniem sesji terminala na systemie Windows.
    • Stabilność agenta lokalnego – zwiększono niezawodność Devin Local oraz naprawiono usterki w integracji z serwerami MCP.

    Devin Local – agent teraz na twoim komputerze

    Nowością w tej wersji jest agent Devin Local, który działa bezpośrednio w terminalu użytkownika. Zgodnie z oficjalnym changelogiem, nowy agent jest nawet do 30% bardziej wydajny tokenowo niż dotychczasowy agent Cascade. Dzięki temu lokalne sesje stają się szybsze i mniej obciążają zasoby, co jest istotne, zwłaszcza przy pracy na słabszych maszynach. To rozwiązanie przybliża możliwości chmurowego Devina do środowiska lokalnego, eliminując potrzebę stałego połączenia z serwerami.

    Nowy wygląd skrzynki agenta – Spaces i Kanban

    Wraz z wersją 2.2.17 interfejs Agent Command Center został odświeżony. Wprowadzono widok Spaces, który pozwala lepiej organizować pracę nad różnymi projektami, oraz tablicę Kanban do wizualnego zarządzania zadaniami. Dodano także możliwość zarządzania wieloma agentami jednocześnie, co ułatwia koordynację pracy zespołowej i przełączanie się między zadaniami.

    Poprawki dla Windows – koniec z problemami terminala

    Aktualizacja 2.2.17 przynosi ważną poprawkę dla użytkowników systemu Windows, którzy doświadczali problemów z uruchamianiem sesji terminala. Błąd ten został naprawiony, co zapewnia płynniejszą pracę z agentami na tym systemie. To krok w kierunku lepszego wsparcia dla platformy Windows.

    Stabilność i wydajność – mniej błędów, szybciej

    Stabilność i wydajność – mniej błędów, szybciej

    Obszerny blok poprawek dotyczy również ogólnej stabilności. Naprawiono błędy w integracji z niektórymi serwerami MCP (Model Context Protocol), co wpłynie korzystnie na współpracę z zewnętrznymi narzędziami i bazami wiedzy. Znacznie poprawiono również niezawodność agenta Devin Local, który oferuje do 30% większą wydajność tokenową w porównaniu do wcześniejszego agenta Cascade. Sesje lokalne są teraz mniej podatne na niespodziewane przerwania, a czas ich ładowania został skrócony.

    Co ta aktualizacja oznacza dla całego ekosystemu?

    Wersja 2.2.17 wpisuje się w proces zmiany nazwy Windsurf na Devin Desktop, mający na celu ujednolicenie marki. Nowe funkcje, takie jak Devin Local i ulepszony Agent Command Center, pokazują, że Cognition konsekwentnie rozwija możliwości agentów, nie zmieniając przy tym samej natury narzędzia.

    Źródła

  • Z.ai wprowadza GLM-5.2 – nowy flagowy model językowy z naciskiem na kodowanie i milion tokenów kontekstu

    Z.ai wprowadza GLM-5.2 – nowy flagowy model językowy z naciskiem na kodowanie i milion tokenów kontekstu

    Z.ai, firma odpowiedzialna za jeden z najbardziej zaawansowanych modeli językowych, wprowadziła GLM-5.2 – nową wersję swojego flagowego modelu. GLM-5.2 jest następcą uznanego GLM-5 i wprowadza ulepszenia w zakresie kodowania oraz obsługi długiego kontekstu, co przekłada się na lepszą wydajność w złożonych zadaniach programistycznych. Model jest dostępny dla wszystkich subskrybentów planu Coding Plan – Lite, Pro i Max – bez dodatkowych opłat.

    Kluczowe informacje o premierze GLM-5.2

    • GLM-5.2 to nowy model w rodzinie GLM, zoptymalizowany do kodowania i autonomicznych agentów programistycznych.
    • Model obsługuje długi kontekst, co umożliwia analizę całych repozytoriów kodu oraz złożonych zadań.
    • Użytkownicy Coding Plan (Lite, Pro, Max) uzyskali dostęp do modelu bez dodatkowych kosztów od dnia premiery.
    • Z.ai koncentruje się na agentowości, przechodząc od pojedynczych zapytań do autonomicznych procesów inżynieryjnych.
    • Nowy model ma silniejsze możliwości kodowania i lepiej radzi sobie z rzeczywistymi zadaniami programistycznymi w porównaniu do wcześniejszych wersji.

    Tło i ewolucja rodziny GLM

    Aby zrozumieć znaczenie GLM-5.2, warto przyjrzeć się wcześniejszym wersjom. GLM-5 był pierwszym flagowym modelem Z.ai, który wykorzystał architekturę Mixture-of-Experts. Dysponował 744 miliardami parametrów, z czego 40 miliardów było aktywnych na token. Obsługiwał kontekst o długości 200 tysięcy tokenów wejściowych oraz 128 tysięcy tokenów wyjściowych. W benchmarku Intelligence Index v4.0 uzyskał wynik 50 punktów, co oznaczało wzrost o 8 punktów w porównaniu do GLM-4.7. Model został wytrenowany na 28,5 biliona tokenów, co stanowiło wzrost o 5,5 biliona w stosunku do poprzednika.

    GLM-5 był promowany jako model do „złożonej inżynierii systemów i długoterminowych zadań agentowych”. Z.ai podkreślało, że model ten wprowadza nową jakość w autonomicznej inżynierii. Zyskał uznanie za swoje możliwości w rzeczywistych zadaniach programistycznych.

    GLM-5.2, opisany jako „model flagowy nowej generacji do inżynierii agentowej”, wprowadza znaczne ulepszenia w zakresie kodowania, co pokazuje, że Z.ai kontynuuje rozwój i podnosi standardy w narzędziach AI do kodowania.

    Co nowego wnosi GLM-5.2

    GLM-5.2 rozwija możliwości swojego poprzednika, wprowadzając kilka istotnych usprawnień. Najważniejsza zmiana dotyczy jakości kodowania – model ma lepsze możliwości programistyczne, co potwierdzają wewnętrzne testy Z.ai oraz opinie użytkowników planu Coding Plan. Oznacza to lepsze rozumienie skomplikowanych struktur kodu oraz generowanie bardziej wydajnego i lepiej udokumentowanego kodu.

    Kolejnym istotnym obszarem jest rozwój w kierunku agentowości. GLM-5.2 nie jest już tylko narzędziem do pojedynczych zapytań, ale systemem zdolnym do prowadzenia złożonych procesów inżynieryjnych, obejmujących analizę wymagań, implementację, testowanie i wdrożenie. Oznacza to, że może zarządzać całym repozytorium lub modułem oprogramowania bez potrzeby mikrozarządzania przez programistę.

    Trzecim kluczowym elementem jest obsługa długiego kontekstu, która umożliwia analizę rozbudowanych repozytoriów i śledzenie zależności w projektach bez utraty spójności.

    Znaczenie dla użytkowników Coding Plan

    Z.ai udostępniło GLM-5.2 w ramach istniejącej subskrypcji Coding Plan, obejmującej pakiety Lite, Pro i Max. Użytkownicy nie muszą ponosić dodatkowych kosztów ani zmieniać warunków umowy, aby korzystać z nowego modelu. Plan Coding Plan został zaprojektowany do codziennej pracy na średnich repozytoriach, oferując priorytetowy dostęp do najnowszych modeli i zestawu narzędzi MCP. Wprowadzenie GLM-5.2 znacząco zwiększa wartość tej oferty, dając programistom dostęp do jednego z najsilniejszych narzędzi agentowości na rynku.

  • OpenCode v1.14.37: Lepsza kontrola sesji i stabilność na pulpicie

    OpenCode v1.14.37: Lepsza kontrola sesji i stabilność na pulpicie

    Najnowsza odsłona otwartoźródłowego asystenta programistycznego OpenCode – oznaczona numerem v1.14.37 – przynosi szereg ulepszeń skoncentrowanych na zarządzaniu zadaniami, wizualizacji sesji oraz niezawodności aplikacji desktopowej. Twórcy położyli szczególny nacisk na wygodę pracy z wieloma podzadaniami jednocześnie oraz na usprawnienia dla użytkowników Windows, co czyni tę aktualizację istotną dla wszystkich, którzy na co dzień polegają na agentach AI w terminalu, IDE lub samodzielnej aplikacji.

    Kluczowe fakty

    • Anulowanie zadań potomnych – od teraz można przerywać podzadania razem z sesją nadrzędną, bez pozostawiania wiszących procesów.
    • Poprawione renderowanie sesji v2 – dokładniejsze wyświetlanie stanów narzędzi i precyzyjniejsze odmierzanie czasu ich działania.
    • Przenoszenie sesji między przestrzeniami roboczymi – funkcja warp pozwala reorganizować pracę bez utraty kontekstu.
    • Płynniejsza migracja w wersji desktopowej – użytkownicy aplikacji okienkowej zyskują łatwiejsze przenoszenie ustawień i danych.
    • Stabilność paska tytułowego w Windows – wyeliminowano migotanie i problemy z powiększeniem okna przy zmianie zoomu.

    Usprawnione zarządzanie podzadaniami

    Do tej pory anulowanie sesji nadrzędnej często prowadziło do sytuacji, w której uruchomione w jej ramach podzadania (ang. child subtasks) działały dalej w tle, zużywając zasoby i tworząc bałagan. OpenCode v1.14.37 rozwiązuje ten problem – mechanizm anulowania został rozbudowany tak, aby jednym poleceniem można było zatrzymać zarówno zadanie główne, jak i wszystkie jego procesy potomne. To szczególnie ważne w środowiskach, gdzie agent AI wykonuje złożone, wieloetapowe operacje (np. refaktoryzację kodu, testy integracyjne czy generowanie dokumentacji). Teraz po wydaniu komendy przerwania użytkownik ma pewność, że nic nie zostanie w zawieszeniu, co przekłada się na czystsze środowisko pracy i mniejsze ryzyko konfliktów.

    Sesje v2 – dokładniejsza wizualizacja stanu narzędzi

    Sesje v2 – dokładniejsza wizualizacja stanu narzędzi

    Drugim filarem wydania jest przebudowa renderowania sesji w wersji drugiej. Deweloperzy poprawili sposób, w jaki wyświetlane są stany poszczególnych narzędzi (np. linterów, formaterek czy skryptów budujących), oraz dopracowali odzwierciedlenie faktycznego czasu ich trwania. W poprzednich wersjach zdarzały się opóźnienia lub nieaktualne informacje o postępie, co mogło wprowadzać użytkownika w błąd przy debugowaniu lub monitorowaniu pracy agenta. Teraz dane są odświeżane w czasie zbliżonym do rzeczywistego, a ikony i opisy stanów są bardziej czytelne. Dzięki temu programista szybciej orientuje się, które narzędzia już zakończyły pracę, a które wciąż działają, co bezpośrednio skraca czas reakcji i pozwala sprawniej zarządzać równoległymi zadaniami.

    Sesje w ruchu: warp między workspace’ami

    Sesje w ruchu: warp między workspace’ami

    Nowością jest możliwość przenoszenia całych sesji między różnymi przestrzeniami roboczymi (workspace’ami). Funkcja warp pozwala w locie zmienić katalog roboczy, w którym działa dana sesja, bez konieczności jej zamykania i odtwarzania od nowa. Dla osób pracujących nad wieloma projektami jednocześnie lub często reorganizujących foldery to ogromne ułatwienie – wystarczy jedno polecenie, aby cały kontekst (historia rozmowy z agentem, otwarte pliki, ustawienia narzędzi) został przeniesiony w nowe miejsce. W praktyce oznacza to, że można np. rozpocząć sesję w repozytorium głównym, a następnie przenieść ją do forka lub gałęzi testowej, zachowując pełną ciągłość pracy. To kolejny krok w kierunku uczynienia z OpenCode elastycznego środowiska, które dostosowuje się do dynamicznego stylu pracy programistów.

    Desktop zyskuje na stabilności

    Użytkownicy aplikacji desktopowej – dostępnej obok interfejsu terminalowego i wtyczek do IDE – otrzymują dwie ważne poprawki. Pierwsza dotyczy płynniejszego procesu migracji: przy przechodzeniu między wersjami lub przenoszeniu konfiguracji na inny komputer OpenCode lepiej radzi sobie z przenoszeniem ustawień i danych sesji, eliminując irytujące błędy i potrzebę ręcznej ingerencji. Druga, szczególnie istotna,

    Źródła

  • Factory CLI v0.118.1 wprowadza niestandardowy katalog roboczy dla sesji programistycznych

    Factory CLI v0.118.1 wprowadza niestandardowy katalog roboczy dla sesji programistycznych

    Nowa wersja Factory CLI (v0.118.1) wprowadza długo oczekiwany parametr cwd do publicznego Sessions API, co umożliwia uruchamianie sesji Droid Computer w wybranym katalogu. Zespół poprawił także obsługę błędnych ścieżek – teraz zamiast cichego przełączania na niewłaściwy katalog, użytkownicy otrzymują jasny, ustrukturyzowany komunikat o problemie.

    • Parametr cwd pozwala wskazać folder startowy dla sesji Droid Computer
    • Ustrukturyzowane błędy zastępują dotychczasowe ciche przełączanie się na niewłaściwy katalog
    • Szybsze wykrywanie problemów – nieprawidłowa ścieżka natychmiast przerywa inicjalizację sesji
    • Lepsza kontrola w monorepozytoriach – agent trafia dokładnie tam, gdzie go potrzebujesz

    Co dokładnie się zmieniło

    Publiczne Sessions API zyskało opcjonalne pole cwd. Oznacza to, że przy starcie sesji można podać ścieżkę bezwzględną lub względną, a Droid Computer rozpocznie pracę w tym miejscu. Wcześniej katalog roboczy był ustalany automatycznie, co w złożonych strukturach projektowych mogło prowadzić do problemów, zwłaszcza przy pracy w kilku modułach jednocześnie.

    Druga zmiana dotyczy obsługi błędów. Jeśli wskażesz nieistniejącą ścieżkę lub katalog bez odpowiednich uprawnień, Factory CLI natychmiast zwróci strukturalny błąd. Koniec z sytuacjami, w których agent w milczeniu lądował w zupełnie innym folderze, a użytkownik orientował się po fakcie, przeglądając zmiany w niewłaściwym repozytorium.

    Dlaczego to ważne dla web developerów

    Praca z agentami AI w środowisku deweloperskim wymaga przewidywalności. Gdy zlecasz Droidowi zadanie w projekcie zagnieżdżonym głęboko w strukturze monorepo, każdy błąd ścieżki może skutkować edycją niewłaściwych plików. Nowy parametr cwd eliminuje ten problem u źródła.

    Dla zespołów korzystających z vibe codingu to znaczna oszczędność nerwów. Na przykład, jeśli masz folder apps/admin-panel i packages/shared-ui, a agent ma pracować tylko w tym pierwszym, bez jawnego wskazania katalogu ryzyko, że naruszy też drugi obszar, było realne. Teraz wystarczy podać cwd: "./apps/admin-panel" i mieć pewność, że wszystko przebiega zgodnie z planem.

    Aspekty DevOps i automatyzacji

    W kontekście CI/CD i skryptów automatyzacyjnych strukturalne błędy mają duże znaczenie. Wcześniej musiałeś liczyć na to, że sesja jakoś się uruchomi, a jeśli nie, to debugowałeś efekty uboczne. Teraz błąd jest jawny, sformatowany i gotowy do przechwycenia w pipeline’ie.

    Dla zespołów DevOps pracujących z tymczasowymi workspace’ami (np. generowanymi dynamicznie per PR) możliwość wskazania dokładnego katalogu przy starcie sesji upraszcza integrację z istniejącymi workflow. Nie trzeba już ręcznie przechodzić do odpowiedniego katalogu na początku każdego zadania – Factory CLI zajmuje się tym automatycznie.

    Kontekst wersji i co dalej

    Wersja v0.118.1 to kolejny krok w kierunku bardziej zaawansowanego narzędzia. Factory regularnie wprowadza aktualizacje – w ostatnich tygodniach pojawiły się usprawnienia w obsłudze Jiry, bezpieczniejsza kontrola ryzykownych komend oraz możliwość samodzielnej dezaktywacji organizacji. Widać wyraźny kierunek: większa kontrola użytkownika nad środowiskiem wykonawczym agentów.

    Choć w notatkach do wydania nie ma danych dotyczących benchmarków ani konkretnych metryk wydajnościowych, zmiana w Sessions API jest na tyle istotna, że warto ją wdrożyć od razu po aktualizacji. Deweloperzy pracujący z wieloma repozytoriami, zagnieżdżonymi aplikacjami czy środowiskami kontenerowymi odczują różnicę natychmiast.

    Podsumowanie

    Factory CLI v0.118.1 rozwiązuje dwa konkretne problemy: brak kontroli nad katalogiem startowym sesji i niejasne komunikaty o błędach ścieżek. Dodanie parametru cwd oraz strukturalnych błędów ma znaczenie zwłaszcza w złożonych projektach webowych, gdzie precyzja jest kluczowa. Jeśli korzystasz z sesji Droid Computer, ta aktualizacja ułatwi ci pracę.

    Źródła

  • Factory CLI z transmisją na żywo i masową kontrolą limitów

    Factory CLI z transmisją na żywo i masową kontrolą limitów

    Factory wydało 9 czerwca 2025 roku wersję v0.118.0 swojego Factory CLI, wprowadzając kilka istotnych usprawnień dla programistów oraz administratorów. Najważniejszą nowością jest transmisja na żywo w aplikacji desktopowej, która umożliwia użytkownikom śledzenie myślenia droidów w czasie rzeczywistym, co eliminuje potrzebę czekania na zakończenie całego zadania. Dodatkowo wprowadzono masowe aktualizacje limitów oraz rozszerzone wsparcie językowe.

    Co nowego w Factory CLI v0.118.0

    • Live streaming w aplikacji desktopowej pokazuje cząstkowe wyniki tekstowe i proces myślowy droidów przed zakończeniem zadania.
    • Masowa aktualizacja limitów pozwala administratorom zmieniać ustawienia wielu kont jednocześnie, co oszczędza czas i redukuje ryzyko błędów.
    • Lokalizacja wyników przeglądu umożliwia korzystanie z narzędzia przez użytkowników spoza anglojęzycznego rynku oraz dostosowuje workflow do lokalnych potrzeb.
    • Poprawki błędów eliminują problemy z odzyskiwaniem sesji i zapewniają spójne działanie persona w Slacku.

    Transmisja na żywo – podgląd pracy droidów w czasie rzeczywistym

    Dotychczas użytkownicy Factory widzieli jedynie końcowy efekt działania droidów. Po aktualizacji aplikacja streamuje częściowe aktualizacje tekstu oraz proces myślowy agenta AI w trakcie wykonywania zadania. Dla programistów oznacza to większą przejrzystość – mogą na bieżąco oceniać, czy droid zmierza w dobrym kierunku, i szybciej identyfikować błędy w rozumowaniu.

    Transmisja na żywo zmienia również sposób pracy z narzędziem. Zamiast czekać na wynik, deweloper ma wgląd w iteracyjne decyzje agenta. Jest to szczególnie istotne przy dłuższych zadaniach, takich jak generowanie kodu, refaktoryzacja czy debugowanie, gdzie pośrednie kroki wpływają na jakość końcowego rozwiązania. Funkcja ta jest obecnie dostępna tylko w aplikacji desktopowej, co warto uwzględnić przy planowaniu workflow.

    Masowe zarządzanie limitami – ukłon w stronę administratorów

    Masowe zarządzanie limitami – ukłon w stronę administratorów

    Drugą istotną zmianą w v0.118.0 są masowe aktualizacje limitów, które umożliwiają aktualizację limitów dla grup użytkowników w jednym kroku. Wcześniej administratorzy musieli ręcznie konfigurować każde konto, co przy większej liczbie deweloperów wiązało się z dużą ilością pracy i ryzykiem błędów. Teraz wystarczy zaznaczyć odpowiednich użytkowników i ustawić limity hurtowo.

    Factory kieruje tę funkcję do większych zespołów i klientów enterprise. Masowe operacje na kontach wskazują na rozwój platformy jako narzędzia do zarządzania AI w organizacji. Podczas onboardingu nowych pracowników czy rotacji w zespołach taka funkcjonalność oszczędza czas administratorów i zapewnia spójność przydziałów, co jest istotne dla efektywnego zarządzania.

    Lokalizacja, stabilność i spójność w Slacku

    Lokalizacja, stabilność i spójność w Slacku

    Mniej spektakularne, ale równie ważne są pozostałe zmiany. Wyniki przeglądów zostały zlokalizowane, co rozszerza wsparcie dla użytkowników nieanglojęzycznych oraz zespołów pracujących w regionach, gdzie angielski nie jest głównym językiem. To ważny krok w kierunku zwiększenia adopcji narzędzia poza rynkiem amerykańskim.

    Dodatkowo poprawiono kilka błędów. Odtwarzanie sesji działa teraz bardziej niezawodnie, a persona droidów zachowuje spójność niezależnie od tego, czy zespół korzysta z nich przez Slacka, aplikację desktopową, czy Factory CLI. Dla rozproszonych zespołów, które używają różnych kanałów komunikacji, ta spójność jest kluczowa, eliminując sytuacje, w których agent działa inaczej w zależności od interfejsu.

    Znaczenie dla codziennego workflow

    Factory pozycjonuje się jako agent inżynierii oprogramowania AI działający z poziomu terminala. Dla web developerów i zespołów DevOps każda z tych aktualizacji ma praktyczne znaczenie dla codziennej pracy. Transmisja na żywo ułatwia debugowanie złożonych zadań, masowe limity odciążają administratorów, a poprawki stabilności zwiększają niezawodność w dłuższych projektach.

    Interesujące jest połączenie transmisji na żywo z integracją Slack. Można sobie wyobrazić scenariusz, w którym deweloper zleca zadanie przez czat, obserwuje postępy w aplikacji desktopowej, a po zakończeniu otrzymuje spójny raport na Slacku. Factory skutecznie testuje granice między różnymi interfejsami.

    Źródła

  • OpenCode v1.14.33 łata krytyczny błąd z agentami we wtyczkach

    OpenCode v1.14.33 łata krytyczny błąd z agentami we wtyczkach

    Zespół OpenCode wydał wersję v1.14.33 swojego otwartoźródłowego agenta AI do kodowania. Aktualizacja koncentruje się na jednym istotnym poprawieniu — naprawia błąd, który uniemożliwiał poprawne ładowanie niestandardowych agentów w pluginach. Dla deweloperów korzystających z rozszerzeń, ta łatka jest kluczowa, ponieważ bez niej agenty nie działały.

    Co przynosi wydanie — najważniejsze fakty

    • OpenCode v1.14.33 naprawia błąd blokujący ładowanie customowych agentów w pluginach.
    • Aktualizacja ma charakter stabilizacyjny, nie wprowadza nowych funkcji.
    • Problem dotyczył przede wszystkim deweloperów używających rozszerzeń pluginowych w workflow.
    • Łatka wpisuje się w szerszy trend hartowania stabilności aplikacji w ostatnich wydaniach.

    Dlaczego ten fix jest ważny dla codziennej pracy

    OpenCode to narzędzie używane w terminalu, IDE i na desktopie. Jeśli polegasz na pluginach rozszerzających możliwości agenta — w kontekście web developmentu, devopsów czy zadań związanych z AI — niedziałający agent to poważna przeszkoda. To blokada całego workflow.

    Wydanie v1.14.33 eliminuje sytuację, w której customowy agent skonfigurowany w pluginie nie pojawiał się. Problem nie wynikał z błędów konfiguracyjnych po stronie użytkownika, lecz z samego mechanizmu ładowania agentów przez rdzeń aplikacji. W praktyce oznaczało to, że plugin istniał, był widoczny, ale jego główna funkcjonalność nie działała.

    Co ważne, poprawka obejmuje również poboczne problemy z zależnościami. Z changeloga wynika, że deweloperzy OpenCode poprawili nie tylko samo ładowanie, ale także kwestie związane z zarządzaniem zależnościami w kontekście pluginów. To sugeruje, że źródło błędu mogło być głębsze niż zwykła pomyłka w kodzie — prawdopodobnie chodziło o nieprawidłową kolejność inicjalizacji komponentów.

    Kontekst szerszych poprawek w ekosystemie OpenCode

    Kontekst szerszych poprawek w ekosystemie OpenCode

    Wydanie v1.14.33 nie jest odosobnione. Przegląd changeloga z ostatnich dni pokazuje, że zespół konsekwentnie pracuje nad stabilnością rdzenia. Wcześniejsze aktualizacje z tego samego cyklu przyniosły m.in. poprawki w obsłudze zakładek w desktopie, ulepszenia wieloserwerowej architektury, poprawki dla sesji i widoków uprawnień, a także usprawnienia w odświeżaniu stanu sesji.

    Widać wyraźny wzorzec — OpenCode dojrzewa jako narzędzie dla profesjonalistów. Zamiast gonić za nowymi efektownymi funkcjami, zespół inwestuje czas w to, co naprawdę ma znaczenie w codziennej pracy: niezawodność. Agent AI do kodowania, który działa sporadycznie, jest bezużyteczny — szczególnie gdy jest częścią zautomatyzowanego pipeline'u.

    Wersja v1.14.33 pokazuje, jak istotna jest architektura pluginowa w nowoczesnych narzędziach deweloperskich. OpenCode od początku stawiał na rozszerzalność. Jeśli jednak fundament — czyli mechanizm ładowania agentów — nie działa, cała filozofia "zainstaluj i rozszerz" traci sens. Ta łatka przywraca ten fundament.

    Co zrobić po aktualizacji

    Co zrobić po aktualizacji

    Jeśli korzystasz z OpenCode i masz skonfigurowane własne agenty w pluginach, po aktualizacji do v1.14.33 powinieneś zobaczyć je z powrotem na liście dostępnych. Nie są wymagane żadne dodatkowe kroki migracyjne — poprawka działa automatycznie po restarcie aplikacji.

    Warto również sprawdzić, czy wcześniejsze problemy z zależnościami pluginów ustąpiły. Jeśli któryś z twoich pluginów wymagał konkretnych bibliotek i wcześniej nie działał, istnieje duża szansa, że teraz załaduje się poprawnie. Zespół OpenCode nie opublikował osobnej dokumentacji migracyjnej dla tego wydania, ponieważ nie jest ona potrzebna. To czysta łatka stabilizacyjna.

    Deweloperzy, którzy jeszcze nie aktualizowali, mogą pobrać nową wersję bezpośrednio z repozytorium GitHub projektu lub przez menedżer pakietów. Standardowa komenda opencode update również powinna zadziałać.

    Podsumowanie

    v1.14.33 nie jest wydaniem, które przyciągnie uwagę mediów. Nie zawiera nowych modeli AI, przełomowych integracji ani przeprojektowanego UI. Jest za to coś znacznie ważniejszego dla użytkowników OpenCode — pewność, że ich agenty się załadują. W świecie narzędzi deweloperskich stabilność bywa niedoceniana, aż do momentu, gdy jej zabraknie. Zespół OpenCode zdaje się to rozumieć.

    Źródła

  • Zed 1.0.1: łatka dla agenta AI usuwa błąd blokujący nanoszenie zmian w kodzie

    Zed 1.0.1: łatka dla agenta AI usuwa błąd blokujący nanoszenie zmian w kodzie

    Zespół Zed opublikował wersję 1.0.1, która usuwa błąd, przez który wbudowany agent AI czasami nie wprowadzał sugerowanych edycji. To pierwsza aktualizacja stabilizacyjna po debiucie wersji 1.0. Zmiana, choć niewielka, jest istotna dla użytkowników korzystających z asystentów kodowania w tym edytorze.

    Najważniejsze informacje

    • Zed 1.0.1 to stabilne wydanie skoncentrowane na niezawodności, bez nowych funkcji.
    • Główna poprawka dotyczy błędu, w którym agent AI nie nanosił edycji w niektórych scenariuszach (issue #55500).
    • Łatka eliminuje źródło frustracji przy vibe codingu i refaktoryzacji wspomaganej przez wbudowane modele.
    • Aktualizacja jest częścią szerszego cyklu poprawek agenta, obejmującego m.in. problemy ze strumieniowanymi edycjami, wysokim zużyciem CPU oraz problemami z systemem plików.

    Drobny patch, duży komfort pracy

    Poprawka 1.0.1 nie wprowadza nowych opcji ani zmian w interfejsie – to celowy krok po tym, jak Zed 1.0.1 został określony jako ważne wydanie, łączące bogactwo możliwości z dbałością o wydajność. Wydanie główne wprowadziło m.in. wątki w terminalu, historię gałęzi w panelu Gita oraz obsługę diagramów Mermaid w agencie, ale szybko okazało się, że najważniejsza jest niezawodność w codziennym użytkowaniu.

    Deweloperzy zgłaszali sytuacje, w których agent nie wprowadzał wygenerowanego fragmentu kodu. W pracy nad nowym kodem lub przy szybkim testowaniu pomysłów, takie sytuacje mogą być irytujące. Dlatego zespół skupił się na zgłoszeniu #55500 i wypuścił stabilną łatkę, która zapewnia, że edycje są wprowadzane do edytora.

    „Fixed an issue where the agent failed to apply edits in some cases” – krótki wpis w changelogu wskazuje na zakres zmian. Choć modyfikacja jest niewielka, dla programisty korzystającego z asystenta AI oznacza to brak wątpliwości, czy agent zadziała, czy trzeba będzie powtarzać polecenie.

    Stabilność nie kończy się na jednym ficie

    Stabilność nie kończy się na jednym ficie

    Wersja 1.0.1 nie jest jedynym przypadkiem – w kolejnych stabilnych wydaniach Zed regularnie naprawia podobne problemy z agentem. W notkach do nowszych wersji znajdują się poprawki dotyczące streamowania edycji zawierających znaki wielobajtowe, wysokiego użycia procesora przy wtyczce Zeta oraz awarii podczas pobierania agentów z rejestru ACP. To dowód na to, że po premierze 1.0.1 twórcy intensywnie monitorują działanie asystenta i eliminują wąskie gardła, które wpływają na płynność współpracy z AI.

    Dla użytkowników, którzy już zaktualizowali do 1.0.1, proces aktualizacji jest prosty. Wystarczy standardowa procedura pobrania najnowszej wersji na macOS, Windows lub Linux – nie są wymagane dodatkowe konfiguracje. Edytor utrzymuje dotychczasowy poziom wydajności, a łatka dotyka tylko krytycznej ścieżki odpowiedzialnej za nanoszenie zmian przez agenta.

    Znaczenie dla programistów i zespołów

    W pracy opartej na szybkich iteracjach – szczególnie przy prototypowaniu czy refaktoryzacji – każda przerwa w działaniu asystenta może rozpraszać i wydłużać czas realizacji zadania. Zed 1.0.1 sprawia, że agent AI staje się bardziej przewidywalny, a polecenia takie jak „dopisz obsługę błędu” czy „zamień pętlę na strumień” kończą się rzeczywistą modyfikacją kodu, a nie komunikatem o błędzie.

    Choć łatka dotyczy jednego konkretnego problemu, wysyła jasny sygnał: Zed nie zamierza spoczywać na laurach po wydaniu 1.0.1. Stabilność agenta to priorytet, zwłaszcza że edytor jest narzędziem dla tych, którzy chcą łączyć ręczne rzemiosło z automatyzacją. Wersja 1.0.1 pokazuje, że za ważnym wydaniem idzie równie istotne doskonalenie szczegółów.

    Źródła

  • OpenCode v1.14.32: Poprawki edycji w powłoce i stabilności środowiska pracy, które realnie usprawniają codzienną pracę koderów

    OpenCode v1.14.32: Poprawki edycji w powłoce i stabilności środowiska pracy, które realnie usprawniają codzienną pracę koderów

    Na początku czerwca 2026 roku OpenCode, otwartoźródłowy agent AI do zadań programistycznych w terminalu, IDE i na pulpicie, otrzymał aktualizację do wersji v1.14.32. Choć na pierwszy rzut oka może wydawać się to kolejnym rutynowym wydaniem, wprowadza szereg kluczowych poprawek, które wpływają na płynność i niezawodność pracy z agentami AI. To wydanie koncentruje się na usuwaniu błędów i zwiększaniu stabilności w środowiskach wielodostawcowych, a nie na wprowadzaniu spektakularnych nowości. Dla deweloperów korzystających z OpenCode na co dzień, poprawki te są jednak istotne: przywracają tryb edycji w powłoce, który wcześniej zawodził w pewnych konfiguracjach, korygują routing żądań do przestrzeni roboczych oraz naprawiają problemy z zarządzaniem sesjami.

    Kluczowe zmiany w wersji v1.14.32

    • Przywrócono tryb edycji w powłoce – naprawiono mechanizm fallbacku zewnętrznego edytora, dzięki czemu sesje attach-mode otwierają się nawet wtedy, gdy oryginalna ścieżka projektu jest lokalnie niedostępna.
    • Poprawiono routing workspace'ów – eksperymentalne żądania tworzenia przestrzeni roboczych bez pola extra działają teraz poprawnie, a schematy OpenAPI są w pełni zgodne z publicznym API.
    • Zwiększono stabilność długotrwałych sesji – wyeliminowano problem zawieszania się modeli Bedrock przed rozpoczęciem odpowiedzi i zapewniono trwałe przechowywanie aktualizacji kontekstu systemowego podczas długich konwersacji.
    • Zredukowano artefakty wizualne w TUI – naprawiono awarie widoków uprawnień i sesji, skorygowano przycinanie przepełnionych kart w pasku tytułu i poprawiono nawigację między kartami.
    • Dodano wsparcie dla Snowflake Cortex – rozszerzono ekosystem kompatybilnych backendów o nowego dostawcę modeli.

    Edycja w powłoce: krytyczny tryb wraca do życia

    Jedną z najbardziej odczuwalnych poprawek jest przywrócenie możliwości edycji w trybie powłoki (shell mode). Problem, który dotknął wielu deweloperów, ujawniał się w sytuacjach, gdy oryginalna ścieżka projektu lokalnie przestawała być dostępna – na przykład w przypadku zdalnie montowanych zasobów czy przenoszenia projektów między katalogami. Wcześniej takie sesje typu attach-mode nie mogły się otworzyć, co przerywało przepływ pracy w najmniej oczekiwanym momencie.

    Dzięki naprawie mechanizmu fallbacku zewnętrznego edytora OpenCode radzi sobie teraz z tym scenariuszem bez przeszkód. Dla programistów pracujących w złożonych, dynamicznych konfiguracjach oznacza to mniej frustracji i ciągłość pracy – agent nie „gubi się” przy zmianie lokalizacji projektu, a sesja pozostaje w pełni funkcjonalna niezależnie od okoliczności.

    Sesje, które nie zacinają się i nie tracą kontekstu

    Drugim obszarem, w którym v1.14.32 wprowadza istotne zmiany, jest stabilność sesji. Dwie poprawki w tym zakresie zasługują na szczególną uwagę. Po pierwsze, wyeliminowano problem z modelami Bedrock, które potrafiły zawiesić się jeszcze przed wygenerowaniem pierwszej odpowiedzi – usterka ta była szczególnie irytująca w interaktywnych przepływach pracy, gdzie każda sekunda oczekiwania ma znaczenie.

    Po drugie, OpenCode teraz trwale przechowuje aktualizacje kontekstu systemowego podczas długich konwersacji. Oznacza to, że agent nie gubi informacji o środowisku, uprawnieniach czy niestandardowych regułach nawet po wielu godzinach pracy z kodem – wszystko pozostaje spójne od początku do końca sesji. To jest nieocenione w złożonych zadaniach programistycznych, gdzie kontekst odgrywa kluczową rolę w jakości odpowiedzi agenta.

    Stabilniejszy routing i zgodne API

    Stabilniejszy routing i zgodne API

    Dla zespołów budujących narzędzia wokół OpenCode istotna jest poprawka dotycząca routingu workspace'ów. Eksperymentalne żądania tworzenia przestrzeni roboczych, które pomijały pole extra, działały nieprawidłowo – teraz ten błąd został skorygowany. Co więcej, poprawiono schematy OpenAPI, dzięki czemu wygenerowani klienci są zgodni z publicznym API. To redukuje tarcie w zautomatyzowanych przepływach pracy, gdzie poprawność integracji jest krytyczna.

    Mniej artefaktów wizualnych, więcej komfortu

    Mniej artefaktów wizualnych, więcej komfortu

    Wersja v1.14.32 przynosi również poprawki w interfejsie użytkownika. Naprawiono awarie widoków uprawnień i sesji, które mogły występować przy nieprawidłowo sformatowanych metadanych ścieżek lub diffów – były to błędy trudne do zdiagnozowania, ale mogące skutecznie wytrącić z rytmu pracy. W trybie pulpitu skorygowano przycinanie przepełnionych kart w pasku tytułu, a także poprawiono logikę zamykania kart i nawigacji, tak aby po zamknięciu aktywnej karty wybierana była ta właściwa. Drobne, ale odczuwalne codziennie niedogodności wreszcie znikają.

    Nowy dostawca i lepsza izolacja pulpitu

    OpenCode v1.14.32 rozszerza również ekosystem o wsparcie dla Snowflake Cortex – nowego dostawcę modeli, który daje użytkownikom większą elastyczność.

    Źródła