Kategoria: Aktualizacje Oprogramowania

  • Devin Desktop 3.1.7 wprowadza płynniejsze przełączanie między agentem a edytorem

    Devin Desktop 3.1.7 wprowadza płynniejsze przełączanie między agentem a edytorem

    Ekipa Cognition wypuściła Devin Desktop 3.1.7, aktualizację, która koncentruje się na poprawie codziennej pracy z agentem AI i edytorem kodu. To kolejny krok w serii 3.1, rozwijającej niedawny rebranding aplikacji. Nowa wersja eliminuje kilka drobnych, ale irytujących problemów w przepływie pracy oraz porządkuje nazewnictwo związane z lokalnym środowiskiem uruchomieniowym.

    Co nowego w Devin Desktop 3.1.7

    • Przełącznik Agent/Editor został umieszczony na pasku tytułowym przy zwiniętym panelu bocznym, a ikona wyszukiwania została ujednolicona, aby zawsze otwierała wyszukiwanie agenta.
    • Zachowanie panelu bocznego poprawiono — teraz pozostaje na swoim miejscu przy otwieraniu i zamykaniu szuflady.
    • Okna pomocnicze nie znikają już i nie odtwarzają się przy przechodzeniu między trybem agenta a edytora.
    • Sekcja ustawień „Devin CLI” została przemianowana na „Devin Local”.
    • Wsparcie dla plików .devinignore dołącza do znanych już .windsurfignore i .codeiumignore.

    Płynność ponad wszystko

    Przełączanie się między trybem agenta a edytorem w Devin Desktop 3.1.7 stało się znacznie prostsze. Wcześniej każde przejście wiązało się z zamykaniem i ponownym otwieraniem okien pomocniczych, takich jak terminal, podgląd czy panele diagnostyczne. Wersja 3.1.7 rozwiązuje ten problem, ponieważ okna pozostają na swoim miejscu.

    Dodatkowo, przełącznik Agent/Editor jest teraz dostępny bezpośrednio na pasku tytułowym, nawet gdy boczny panel jest zwinięty. To może wydawać się drobnym szczegółem, ale w praktyce oszczędza kliknięcia i nie przerywa rytmu pracy. Wyszukiwanie również zostało uproszczone — jedna ikona, jeden sposób działania, niezależnie od kontekstu.

    Te mikrozmiany mają znaczenie podczas długich sesji z kodem. Mniej migających okien i mniej przypadkowych strat kontekstu poprawiają komfort pracy.

    Devin Local zamiast CLI

    Devin Local zamiast CLI

    Zmiana nazwy z „Devin CLI” na „Devin Local” może wydawać się kosmetyczna, ale jest uzasadniona z perspektywy użytkownika. „CLI” sugerowało narzędzie wyłącznie terminalowe, podczas gdy w rzeczywistości odnosi się do całego lokalnego środowiska agenta — od instalacji po zarządzanie sesjami.

    W tej samej aktualizacji zaktualizowano również lokalnego agenta do wersji v2026.5.26-8 oraz dodano powiadomienia o nieudanym logowaniu. Wcześniej, gdy autoryzacja się nie powiodła, użytkownik mógł nie wiedzieć, co się stało. Teraz otrzymuje jasny komunikat — proste, ale potrzebne.

    .devinignore — kontrola nad kontekstem agenta

    .devinignore — kontrola nad kontekstem agenta

    Nowy plik .devinignore odpowiada na potrzebę zarządzania tym, co agent AI widzi w projekcie. Wsparcie dla tego mechanizmu dołącza do istniejących już .windsurfignore i .codeiumignore, co sugeruje spójną filozofię Cognition: użytkownik decyduje, które pliki wchodzą w skład kontekstu.

    Ma to znaczenie z kilku powodów. Po pierwsze — prywatność: klucze API, dane testowe czy pliki konfiguracyjne mogą być wykluczone z analizy agenta. Po drugie — wydajność: mniejszy kontekst prowadzi do szybszych odpowiedzi i mniejszego zużycia tokenów. Po trzecie — higiena projektu: agent nie będzie sugerował zmian w plikach, które celowo trzymamy poza jego zasięgiem.

    UI i ustawienia

    W Devin Desktop 3.1.7 odświeżono również wygląd paneli Ustawień i marketplace MCP. Strony te korzystają teraz z pełnej szerokości panelu, a ich zawartość pozostaje wyśrodkowana na szerszych ekranach. Ta zmiana wizualna poprawia czytelność, szczególnie na monitorach o wyższej rozdzielczości.

    Całość wpisuje się w szerszy obraz Devin Desktop 3.1.7 jako środowiska, które łączy lokalną edycję kodu z pracą agentów — zarówno lokalnych, jak i chmurowych. Aplikacja bazuje na Windsurf IDE, więc wszystkie ustawienia, rozszerzenia i skróty klawiszowe są zachowane. Wersja 3.1.7 to nie rewolucja, ale solidna dawka dopracowania — co w narzędziach codziennego użytku ma kluczowe znaczenie.

    Źródła

  • Zed 1.5.5: Claude Fable 5 w BYOK i naprawa zaufania repozytoriów

    Zed 1.5.5: Claude Fable 5 w BYOK i naprawa zaufania repozytoriów

    Zed wprowadził stabilną aktualizację 1.5.5, która rozszerza wsparcie dla Anthropic BYOK o model Claude Fable 5 oraz eliminuje błąd związany z przyciskiem zaufania dla repozytoriów git. Te dwie zmiany mają istotny wpływ na codzienną pracę programistów korzystających z tego edytora.

    Kluczowe fakty

    • Claude Fable 5 dołączył do konfiguracji Anthropic BYOK w Zed 1.5.5
    • Przycisk zaufania repozytorium git przestał ignorować kliknięcia po naprawie błędu
    • BYOK pozwala użytkownikom Zed podłączać własne klucze API zamiast polegać wyłącznie na dostawcach wbudowanych
    • Mechanizm zaufania to część systemu bezpieczeństwa Zed przy pracy z repozytoriami o różnych stanach zaufania
    • Aktualizacja trafiła do stabilnego kanału, nie jest to wersja testowa

    Claude Fable 5 w ekosystemie BYOK

    Zed rozwija funkcję Bring Your Own Key, która daje programistom możliwość wyboru dostawcy modeli AI. Użytkownicy mogą podłączyć własny klucz API i korzystać z preferowanych modeli. W wersji 1.5.5 do listy obsługiwanych modeli Anthropic dołączył Claude Fable 5.

    Dodanie jednego modelu może wydawać się drobną zmianą, ale dla osób, które polegają na konkretnym modelu w pracy z AI – czy to do generowania kodu, refaktoryzacji, czy analizy kontekstu w projekcie – to różnica między wygodnym workflow a frustracją. Zed systematycznie poszerza paletę modeli, co widać po historii wydań, w których pojawiały się aktualizacje dotyczące Anthropic i innych dostawców.

    Oznacza to, że jeśli masz wykupiony dostęp do Claude przez Anthropic i używasz go poza Zedem, teraz możesz wykorzystać ten sam klucz API wewnątrz edytora, co eliminuje potrzebę przeskakiwania między narzędziami.

    Git – przycisk, który wreszcie działa

    Git – przycisk, który wreszcie działa

    Druga zmiana w aktualizacji 1.5.5 to naprawa błędu, który powodował, że kliknięcie przycisku „zaufaj temu repozytorium git” nie przynosiło rezultatu. Choć może to brzmieć nieistotnie, brak możliwości oznaczenia repozytorium jako zaufanego mógł blokować część operacji w Zed, wymagając ciągłego potwierdzania.

    Kontrola zaufania repozytoriów to element szerszego podejścia Zed do bezpieczeństwa. Edytor ostrzega przed potencjalnie niebezpiecznymi repozytoriami i wymaga zgody użytkownika na pełną interakcję. Gdy przycisk nie działa, użytkownik nie może normalnie pracować ani potwierdzić, że ufa kodowi. Naprawa tego problemu przywraca płynność pracy z projektami, szczególnie tymi klonowanymi z zewnętrznych źródeł.

    Co to znaczy dla zespołów webowych i AI

    Co to znaczy dla zespołów webowych i AI

    Zed pozycjonuje się jako nowoczesny edytor dla programistów, którzy cenią szybkość i integrację z AI. Aktualizacje, takie jak 1.5.5, pokazują, że zespół Zed reaguje na potrzeby użytkowników – zarówno w zakresie elastyczności w wyborze modeli AI, jak i eliminowania przeszkód w podstawowych przepływach pracy, takich jak git.

    Dodanie Claude Fable 5 do BYOK wpisuje się w szerszy trend, w którym twórcy narzędzi deweloperskich odchodzą od narzucania jednego dostawcy AI na rzecz otwartej architektury, w której programista sam decyduje, z czego korzysta. Podobne podejście widać w innych edytorach i platformach, ale Zed konsekwentnie realizuje je w kolejnych wydaniach.

    Naprawiony przycisk zaufania pokazuje, że nawet drobne elementy interfejsu mają znaczenie dla produktywności. Gdy coś, co powinno działać od razu, przestaje reagować, efektem jest nie tylko irytacja, ale także realna strata czasu – szczególnie przy pracy z wieloma repozytoriami jednocześnie.

    Co dalej?

    Zed rozwija się w szybkim tempie, a historia wydań pokazuje, że aktualizacje związane z AI i integracją z git pojawiają się regularnie. Wersja 1.5.5 jest stosunkowo niewielka, ale obie zmiany odpowiadają na praktyczne potrzeby użytkowników. Jeśli korzystasz z Zed, warto zaktualizować – szczególnie jeśli używasz Anthropic przez BYOK lub miałeś problemy z przyciskiem zaufania repozytorium.

    Źródła

  • Kimi Code CLI 1.47.0 ułatwia przesiadkę na samodzielną wersję i poprawia raportowanie błędów

    Kimi Code CLI 1.47.0 ułatwia przesiadkę na samodzielną wersję i poprawia raportowanie błędów

    MoonshotAI wprowadziło 5 czerwca 2026 roku wersję 1.47.0 Kimi Code CLI, która ma na celu ułatwienie użytkownikom przejścia na nową, samodzielną wersję narzędzia. Aktualizacja wprowadza komendę /upgrade, automatyzując proces migracji oraz dostarczając więcej informacji w przypadku nieudanych poleceń.

    Kluczowe zmiany w skrócie

    • Nowa komenda /upgrade instaluje samodzielną wersję Kimi Code CLI, przenosząc konfigurację oraz sesje.
    • Podpowiedzi przy starcie i wyjściu przypominają o aktualizacji raz dziennie, w sposób nieinwazyjny.
    • Lepsze komunikaty błędów pokazują końcowe linie wyjścia polecenia, co ułatwia diagnozowanie problemów.
    • Starsza wersja w Pythonie/uv nie będzie już rozwijana, a zespół koncentruje się na wersji w Node.js.

    Automatyczna migracja bez ręcznego przeklikiwania

    Przejście na nową, samodzielną wersję Kimi Code CLI jest teraz bardzo proste. Wystarczy wpisać /upgrade w terminalu, a narzędzie pobierze odpowiednią paczkę, przeniesie konfigurację, historię wejść oraz wybrane sesje czatu. Zespół MoonshotAI zapewnił, że stare dane w katalogu ~/.kimi/ pozostaną nietknięte – migracja nie usuwa ani nie modyfikuje oryginalnych plików.

    Warto jednak zauważyć, że nie wszystkie dane są przenoszone. Poświadczenia OAuth oraz autoryzacje MCP nie są kopiowane, co jest decyzją podjętą w trosce o bezpieczeństwo. W przypadku problemów migrację można uruchomić wielokrotnie, a już przeniesione sesje nie będą zduplikowane.

    Nowa wersja działa na Node.js, co przyspiesza uruchamianie i wprowadza przeprojektowany interfejs terminala. Stara wersja nie będzie już otrzymywać poprawek, co sprawia, że aktualizacja staje się koniecznością.

    Kiedy polecenie pada – teraz widać więcej

    Kolejną istotną zmianą jest poprawa raportowania błędów. Wcześniej komunikaty o niepowodzeniach były mało informacyjne – użytkownik dowiadywał się jedynie, że coś poszło nie tak. W wersji 1.47.0 Kimi Code CLI wyświetla końcowe linie wyjścia w przypadku błędu, pokazując rzeczywisty output polecenia, które nie powiodło się.

    Dla osób spędzających dużo czasu w terminalu, to istotna różnica. Szybsze zrozumienie przyczyny awarii oszczędza frustrację i przyspiesza iterację, eliminując potrzebę ręcznego odtwarzania komendy w celu sprawdzenia jej wyjścia.

    Nienachalne przypominanie o aktualizacji

    Zespół MoonshotAI wprowadził także subtelne przypomnienia o aktualizacji. Przy starcie CLI pojawia się sugestia przejścia na nową wersję, a raz dziennie – przy wyjściu – wyświetlana jest krótka porada. To podejście minimalizuje dystrakcje, dostarczając informacji w odpowiednim momencie. Użytkownicy, którzy pracują w kilku sesjach dziennie, docenią, że podpowiedź pojawia się tylko raz.

    Dlaczego to ma znaczenie dla web developerów

    Kimi Code CLI 1.47.0 to nie tylko czat z modelem AI, ale również pełnoprawne środowisko do kodowania w terminalu, z dostępem do edycji plików, wykonywania poleceń powłoki, wyszukiwania w sieci i autonomicznego planowania zadań. Nowa, samodzielna wersja upraszcza instalację i przyspiesza start, co jest istotne przy konfigurowaniu środowisk deweloperskich w kontenerach czy na maszynach wirtualnych.

    Lepsze raportowanie błędów jest korzystne dla tych, którzy używają CLI w zautomatyzowanych pipeline’ach. Gdy skrypt zawiedzie, użytkownik chce od razu wiedzieć, dlaczego, a nie po długim dochodzeniu. Migracja, która zachowuje kontekst pracy, oznacza, że nie traci się historii rozmów ani ustawień MCP, co bywa problematyczne przy ręcznej reinstalacji.

    Wydanie 1.47.0 pokazuje, że MoonshotAI traktuje poważnie proces przejścia między starą a nową architekturą. Użytkownicy otrzymali jedno polecenie, które automatyzuje cały proces, zamiast instrukcji do ręcznej reinstalacji.

    Ź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

  • OpenCode 1.16.0: klonowanie workspace’ów z brudnymi plikami i sesje przenoszone między katalogami

    OpenCode 1.16.0: klonowanie workspace’ów z brudnymi plikami i sesje przenoszone między katalogami

    OpenCode wydał wersję 1.16.0, która wprowadza zarządzane klonowanie workspace’ów, umożliwiające zachowanie niezatwierdzonych zmian oraz przenoszenie aktywnych sesji między katalogami. Dodatkowo, aktualizacja wprowadza natywną obsługę OpenAI przez AWS Bedrock, automatyczne wykrywanie skilli oraz szereg poprawek stabilności. Choć zmiany mogą wydawać się niewielkie, mają one znaczący wpływ na sposób pracy z agentami AI w większych projektach.

    Kluczowe zmiany

    • Zarządzane klonowanie workspace’ów tworzy kopię środowiska pracy, zachowując brudne i nieśledzone pliki. Agent może eksperymentować w izolacji, nie ryzykując utraty bieżącego stanu.
    • Przenoszenie sesji pozwala kontynuować pracę agenta w innym katalogu lub workspace’ie bez potrzeby restartowania zadania.
    • Natywna obsługa OpenAI przez AWS Bedrock zapewnia wsparcie dla modeli OpenAI bez konieczności korzystania z pośrednich adapterów.
    • Skill discovery i file-based agent loading umożliwia OpenCode znajdowanie i ładowanie skilli bezpośrednio z plików, a nie tylko z wbudowanych menu.
    • Sesje replay przez run --replay oferują interaktywny podgląd przebiegu sesji, co ułatwia debugowanie.

    Jak działają workspace’y w OpenCode

    Aby zrozumieć znaczenie klonowania workspace’ów, warto zauważyć, że OpenCode opiera je na Git worktrees. Każdy workspace ma własny katalog i gałąź, co oznacza, że pliki jednego środowiska nie wpływają na inne, a wszystko to przy współdzielonej bazie Gita, bez konieczności pełnego klonowania repozytorium.

    Do tej pory stworzenie nowego workspace’a oznaczało czysty start. Teraz, dzięki zarządzanemu klonowaniu, można skopiować bieżący workspace wraz z niezatwierdzonymi zmianami. Agent zyskuje własną piaskownicę do testowania pomysłów, podczas gdy oryginalny workspace pozostaje nietknięty. To idealne rozwiązanie, gdy chcemy uruchomić kilka równoległych agentów – każdy działa na swoim worktree, nie przeszkadzając sobie nawzajem.

    Przenoszenie sesji bez utraty kontekstu

    Kolejną istotną nowością jest możliwość przenoszenia sesji między workspace’ami i katalogami. Dotychczas agent uruchomiony w jednym katalogu był do niego przywiązany, a zmiana kontekstu wymagała restartu. Teraz można przenieść trwającą sesję do innego worktree, zachowując całą historię rozmowy i bieżący stan pracy.

    To funkcja, która często brakuje w wielu narzędziach. Zdarza się, że agent zaczyna zadanie w katalogu projektu, a po chwili okazuje się, że powinien pracować w dedykowanym workspace’ie. Zamiast zaczynać od nowa, można po prostu przenieść sesję, zachowując kontekst i umożliwiając agentowi kontynuację.

    AI i integracje: Bedrock, skille i replay

    OpenCode obsługuje już wielu dostawców modeli, a dodanie natywnego wsparcia OpenAI przez AWS Bedrock upraszcza konfigurację i stabilizuje połączenie w porównaniu do wcześniejszych adapterów.

    Skill discovery to funkcja, która pozwala OpenCode automatycznie wykrywać skille zapisane w plikach. Wcześniej trzeba było definiować je ręcznie lub wybierać z menu. Teraz agent samodzielnie znajduje dostępne rozszerzenia, co zmniejsza potrzebę ręcznej konfiguracji.

    Interaktywny replay sesji, dostępny przez run --replay, umożliwia prześledzenie każdego kroku agenta, co jest przydatne przy debugowaniu złożonych zadań. Nie trzeba zgadywać, dlaczego agent podjął określoną decyzję – można po prostu odtworzyć sesję i zobaczyć cały proces.

    Stabilność i tempo rozwoju

    Aktualizacja poprawia także kilka uciążliwych błędów, w tym problemy z anulowaniem komend shella oraz normalizacją ścieżek. Dodatkowo, uruchamianie aplikacji stało się szybsze, co jest odczuwalne, zwłaszcza przy częstym otwieraniu i zamykaniu workspace’ów.

    Tempo rozwoju jest dynamiczne, a aktualizacje są starannie przemyślane. Nowe funkcje są dodawane tylko wtedy, gdy realnie wpływają na workflow.

    Co to oznacza dla zespołów deweloperskich

    Kierunek, w którym zmierza OpenCode, jest jasny: równoległa praca agentów, izolowane środowiska i minimalizacja tarcia przy zmianie kontekstu. Klonowanie workspace’ów z brudnymi plikami to nie tylko nowość – to praktyczne narzędzie dla zespołów, które chcą zwiększyć wykorzystanie AI w kodzie bez konieczności ciągłego sprzątania repozytorium przed każdym zadaniem.

    Dla zespołów pracujących z wieloma agentami równolegle lub często przenoszących zadania między środowiskami, wersja 1.16.0 przynosi znaczące zmiany. Pozostałe funkcje, takie jak skille, Bedrock i replay, to solidne dodatki, ale to workspace’y i sesje odgrywają kluczową rolę w tej aktualizacji.

    Źródła

  • Google Antigravity 2.0.10 załatało błąd kredytów G1 i poprawiło stabilność

    Google Antigravity 2.0.10 załatało błąd kredytów G1 i poprawiło stabilność

    Google wypuściło aktualizację Antigravity 2.0.10, która została wydana 28 maja 2026 roku. Ta wersja koncentruje się na naprawie błędów oraz poprawie niezawodności aplikacji. Zespół rozwiązał przede wszystkim krytyczny problem związany z kredytami G1, który wpływał na historię salda użytkowników.

    • Google wydało wersję 2.0.10 swojej aplikacji Antigravity 28 maja 2026
    • Główną zmianą jest poprawka błędu kredytów G1, który zniekształcał wyświetlanie salda konta
    • Dodatkowo wprowadzono szereg poprawek zwiększających ogólną niezawodność i użyteczność
    • Antigravity 2.0.10 zastąpiło wcześniejsze IDE, zmieniając podejście na aplikację desktopową skoncentrowaną na agentach AI

    Błąd G1 – co dokładnie poprawiono?

    Problem z kredytami G1 był jednym z bardziej irytujących błędów, które pojawiły się po premierze Antigravity 2.0.10. Użytkownicy zauważali różnice między rzeczywistym stanem wykorzystanych jednostek rozliczeniowych a tym, co pokazywał interfejs. W niektórych przypadkach system nie poprawnie odzwierciedlał zużycie kredytów z pakietu Google One. Ta kwestia była już częściowo rozwiązana w łatce 2.0.10, ale nie do końca skutecznie.

    Wersja 2.0.10 zamyka ten temat. Mechanizm śledzenia salda został poprawiony, aby dane wyświetlane w zakładce Models w ustawieniach zgadzały się z rzeczywistym stanem konta. Dla osób intensywnie korzystających z agentów AI ma to praktyczne znaczenie – użytkownicy mogą teraz łatwo sprawdzić, ile kredytów faktycznie zostało, bez konieczności ręcznego przeliczania.

    W changelogu nie podano szczegółów technicznych poprawki. Wpis ogranicza się do stwierdzenia „G1 credit bug fix”. Jednak na podstawie wcześniejszych problemów można przypuszczać, że chodziło o synchronizację między backendem rozliczeniowym a lokalnym stanem aplikacji.

    Niezawodność i użyteczność – zbiorcza kategoria poprawek

    Niezawodność i użyteczność – zbiorcza kategoria poprawek

    Oprócz poprawki G1, Antigravity 2.0.10 przynosi również zbiór poprawek określonych jako „różne usprawnienia niezawodności i użyteczności”. To klasyczny zbiór, w którym Google umieszcza mniejsze poprawki, które nie wymagają osobnego opisywania. W praktyce chodzi prawdopodobnie o stabilniejsze działanie przy przełączaniu konwersacji, mniej awarii przy operacjach na plikach oraz ogólne wygładzenie interfejsu.

    Wersja 2.0.10 nie wprowadza nowych funkcji. Nie ma wsparcia dla PDF-ów (to pojawiło się w 2.0.10), nie ma komendy /btw ani przeprojektowanego ekranu limitów. To inżynieryjne wydanie, które przygotowuje grunt pod późniejsze, bardziej rozbudowane aktualizacje.

    Kontekst: Antigravity 2.0.10 jako następca IDE

    Wersja 2.0.10 pojawia się nieco ponad tydzień po premierze Antigravity 2.0.10, zaprezentowanej na Google I/O 19 maja 2026 roku. Ta premiera była dużą zmianą – Google porzuciło dotychczasowe podejście w stylu IDE i zastąpiło je samodzielną aplikacją desktopową skoncentrowaną na agentach.

    Dla wielu programistów oznaczało to utratę znanych narzędzi – eksploratora plików, terminala czy kontroli wersji wbudowanych w poprzednie środowisko. Dlatego kolejne łatki, takie jak 2.0.10, są niezwykle ważne – stabilizują nowe doświadczenie, podczas gdy zespół odbudowuje funkcjonalności w nowej architekturze.

    Co ciekawe, wersja 2.0.10 dodała integrację z Antigravity IDE, co umożliwia otwieranie projektów w starym środowisku. Wygląda na to, że Google stworzyło most między starym a nowym światem, zamiast całkowicie odcinać użytkowników.

    Co dalej?

    Patrząc na dalszy ciąg changeloga – wersje 2.0.10, 2.0.10 czy 2.0.10 – widać, że tempo rozwoju jest wysokie. Kolejne wydania wprowadzają wsparcie dla PDF-ów, komendę /btw do bocznych pytań w trakcie konwersacji, a nawet odtwarzanie plików audio bezpośrednio w aplikacji.

    Dla osób śledzących rozwój narzędzi AI i środowisk pracy z agentami, Antigravity staje się interesującym przypadkiem. Google stara się zbudować pomost między klasycznym IDE a w pełni agentskim workflow – coś, co konkurencja również próbuje robić, ale na razie bez jednego spójnego produktu. Wersja 2.0.10 to mały, ale solidny krok w stronę stabilności, która jest kluczowa dla funkcji aplikacji.

    Źródła

  • Codex 0.135.0 wprowadza rozbudowaną diagnostykę i ulepszony tryb Vima

    Codex 0.135.0 wprowadza rozbudowaną diagnostykę i ulepszony tryb Vima

    OpenAI wydało 28 maja 2026 roku stabilną wersję Codex 0.135.0 — piątą aktualizację w ciągu dziesięciu dni. To wydanie koncentruje się na doświadczeniu użytkownika, nie wprowadzając nowych modeli AI ani agentowych prymitywów. Zamiast tego oferuje narzędzia, które skracają czas potrzebny na diagnozowanie problemów i konfigurację środowiska.

    Kluczowe zmiany w Codex 0.135.0

    • Rozszerzona diagnostyka — polecenie codex doctor bada teraz pięć kategorii: środowisko wykonawcze, stan repozytorium Git, terminal, serwer aplikacji i inwentarz wątków, generując gotowy raport do zgłoszeń supportowych.
    • Ulepszenia trybu Vima — dodano obsługę edycji obiektów tekstowych (ciw, ca(, da") oraz konfigurowalne skróty przerywania konwersacji.
    • Udostępnienie presetów Sandbox — Python SDK zyskuje nazwane presety wykonawcze, co redukuje powtarzalny kod przy konfiguracji sandboksów.
    • Profile uprawnień — /permissions umożliwia przełączanie się między nazwanymi profilami uprawnień dostosowanymi do konkretnych projektów.
    • Widoczność połączeń zdalnych — /status pokazuje szczegóły zdalnego transportu i wersję serwera.

    Diagnostyka, która oszczędza czas

    Największą nowością jest rozszerzenie komendy codex doctor. Narzędzie, które po raz pierwszy pojawiło się w wersji 0.131.0, przeszło gruntowną przebudowę. Analizuje teraz pięć kategorii: środowisko wykonawcze, stan repozytorium Git, terminal, serwer aplikacji oraz inwentarz wątków. Wynik jest formatowany tak, aby można go było wkleić bezpośrednio do zgłoszenia supportowego, eliminując konieczność ręcznego zbierania kontekstu.

    Dla zespołów devopsowych i web developerów pracujących w złożonych środowiskach terminalowych to znacząca oszczędność czasu, zwłaszcza podczas debugowania problemów na zdalnym serwerze przez SSH — wystarczy jedno polecenie.

    Tryb Vima: obiekty tekstowe i konfigurowalne skróty

    Tryb Vima w Codexie zyskał kilka długo oczekiwanych poprawek. Dodano obsługę edycji obiektów tekstowych — ciw do zmiany słowa pod kursorem, ca( do zmiany zawartości nawiasów, da" dla cudzysłowów. Te operacje są kluczowe dla płynnej edycji bez odrywania rąk od klawiatury.

    Poprawiono także zachowanie przy końcu słowa i końcu linii (#24380), eliminując nieintuicyjne przeskoki kursora, które irytowały podczas szybkiego kodowania. Dodatkowo wprowadzono możliwość konfiguracji skrótów do przerywania konwersacji (#24766), co pozwala na dostosowanie ich do własnych przyzwyczajeń.

    Python SDK: mniej boilerplate'u, więcej kontroli

    Dla programistów integrujących Codexa z własnymi narzędziami, istotną zmianą w Python SDK są nazwane presety Sandbox dla API wątków i tur (threads, turns). Dotychczas każdorazowe konfigurowanie trybu wykonawczego sandboksa wymagało pisania powtarzalnego kodu. Teraz wystarczy odwołać się do gotowego presetu.

    Ta zmiana współgra z profilem uprawnień — /permissions wprowadza wsparcie dla nazwanych profili uprawnień z własnymi konfiguracjami. Umożliwia to szybkie przełączanie się między restrykcyjnym trybem dla zewnętrznych bibliotek a luźniejszym dla własnego kodu testowego, bez potrzeby edytowania plików konfiguracyjnych.

    Stabilność i infrastruktura

    Wydanie 0.135.0 wprowadza poprawki stabilności TUI. Udoskonalone zostało renderowanie na macOS i w Zelliju, a dopełnianie slash-komend nie nadpisuje już wprowadzanego tekstu — co było uciążliwe podczas dłuższych sesji. Instalator zyskał tryb nieinteraktywny, co ułatwia integrację Codexa w pipeline'y CI/CD.

    Pod maską zaszły zmiany architektoniczne: pamięć przeniesiono do niezależnej bazy SQLite, a konfiguracja TUI stopniowo zbiega się w stronę serwera aplikacji. To przygotowanie do przyszłej skalowalności, choć dla końcowego użytkownika na razie niewidoczne.

    Ewolucja, nie rewolucja

    Codex 0.135.0 wpisuje się w szerszy trend: narzędzie przestaje być tylko generatorem kodu, a staje się fundamentem agentowym, który operuje całym środowiskiem developerskim. Pięć stabilnych wydań w dziesięć dni pokazuje tempo prac oraz świadomą strategię OpenAI. Zamiast wprowadzać nowe modele, firma koncentruje się na tym, aby istniejące funkcje działały przewidywalnie i wygodnie.

    Dla web developerów, którzy spędzają godziny w terminalu, te zmiany przynoszą konkretne ułatwienia w codziennej pracy. Dla tych, którzy integrują Codexa z własnymi skryptami Pythona, presety Sandbox i profile uprawnień oznaczają czystszy kod i mniej niespodzianek na produkcji. Kolejnym krokiem ewolucji będzie wersja 0.136.0 alpha, która już się pojawiła i zapowiada dalsze usprawnienia.

    Źródła

  • Cline CLI v3.0.14: cicha aktualizacja, która ratuje kompilowane buildy przed milczącą awarią telemetrii

    Cline CLI v3.0.14: cicha aktualizacja, która ratuje kompilowane buildy przed milczącą awarią telemetrii

    Zespół Cline wypuścił wersję v3.0.14 swojego CLI, koncentrując się na poprawie stabilności telemetrii. To aktualizacja, która nie wprowadza nowych funkcji, lecz rozwiązuje problem z bundlowaniem zmiennych OTEL w kompilowanych buildach. Jeśli kiedykolwiek zastanawiałeś się, dlaczego telemetria znika po zbudowaniu aplikacji, odpowiedź leży w tej aktualizacji.

    Kluczowe fakty

    • Cline CLI v3.0.14 naprawia bundlowanie zmiennych telemetrycznych OTEL, które powodowały wyłączanie telemetrii w kompilowanych buildach.
    • Problem dotyczył niezdefiniowanych zmiennych środowiskowych, które podczas budowania były usuwane przez bundlery, zamiast pozostać jako sprawdzalne wartości.
    • Poprawka dodaje zabezpieczenia przed undefined i optymalizuje kompatybilność z narzędziami do budowania.
    • Aktualizacja jest krytyczna dla zespołów używających Cline w środowiskach CI/CD i produkcyjnych.
    • Wydanie nie wprowadza żadnych nowych funkcji — to czysto techniczna łatka infrastrukturalna.

    Dlaczego telemetria OTEL potrafi zniknąć po zbudowaniu

    OpenTelemetry to standard zbierania danych o działaniu aplikacji. Problem polega na tym, że bundlery takie jak esbuild czy Webpack analizują kod podczas budowania i usuwają wszystko, co uznają za martwy kod. Gdy zmienna środowiskowa nie jest jawnie zdefiniowana, bundler traktuje ją jako nieosiągalną i wycina cały blok z logiką telemetrii.

    Efekt? W trybie developerskim wszystko działa. Uruchamiasz cline dev, metryki są dostępne. Budujesz wersję produkcyjną — cisza. Żadnych błędów, żadnych ostrzeżeń, po prostu telemetria przestaje istnieć w skompilowanym kodzie.

    To problem, który może pozostać niezauważony przez długi czas. Zespoły mogą przez tygodnie myśleć, że monitoring działa, podczas gdy w rzeczywistości dane nie są nigdzie wysyłane.

    Co dokładnie zmieniono w v3.0.14

    Co dokładnie zmieniono w v3.0.14

    Mechanika naprawy jest prosta, ale skuteczna. Zamiast polegać na bezpośrednich referencjach do zmiennych środowiskowych, kod telemetrii został przepisany tak, by najpierw sprawdzać istnienie zmiennej, a dopiero potem podejmować decyzję. To klasyczne podejście, które bundler musi pozostawić w spokoju, ponieważ nie może udowodnić, że warunek zawsze będzie fałszywy.

    Dodatkowo zoptymalizowano sposób, w jaki zmienne OTEL są pakowane. Teraz nawet jeśli bundler agresywnie tree-shakuje nieużywane importy, ścieżka telemetryczna pozostaje nietknięta. Dla użytkownika końcowego to zmiana niewidoczna — po prostu rzeczy działają tak, jak powinny.

    Dla kogo ta łatka ma znaczenie

    Dla kogo ta łatka ma znaczenie

    Jeśli używasz Cline lokalnie w trybie dev i nigdy nie budujesz wersji produkcyjnych, prawdopodobnie nie byłeś świadomy problemu. Jednak jeśli twoja konfiguracja obejmuje CI/CD, gdzie Cline jest częścią zautomatyzowanych pipeline'ów, albo uruchamiasz go jako komponent większego systemu — ta aktualizacja jest istotna.

    Telemetria w środowiskach produkcyjnych to nie tylko statystyki użycia. To sygnały błędów, metryki wydajności, informacje o tym, które narzędzia i modele są faktycznie wywoływane. Utrata tych danych może oznaczać, że przez długi czas nie zauważysz regresji wydajności czy błędów dotykających konkretnych ścieżek kodu.

    Podsumowanie

    Cline CLI v3.0.14 przypomina, że narzędzia AI w produkcji wymagają takiej samej dyscypliny infrastrukturalnej jak każdy inny software. Telemetria, która znika po zbudowaniu, nie jest błędem krytycznym w rozumieniu awarii aplikacji. Jest to problem, który może być trudny do zauważenia. Ta łatka rozwiązuje ten problem, zapewniając, że telemetria działa zgodnie z oczekiwaniami.

    Źródła

  • Zed 1.4.2: System umiejętności zastępuje reguły agenta i wprowadza globalne instrukcje

    Zed 1.4.2: System umiejętności zastępuje reguły agenta i wprowadza globalne instrukcje

    Zed wydał wersję 1.4.2, która zmienia sposób konfigurowania agentów AI w edytorze. Dotychczasowy system reguł został usunięty, a jego miejsce zajęły umiejętności (Skills), czyli pakiety instrukcji wielokrotnego użytku. Wprowadzono również globalny plik AGENTS.md, który pozwala na definiowanie wytycznych dostępnych dla wszystkich agentów, eliminując potrzebę powtarzania tych samych zasad w różnych wątkach.

    Najważniejsze zmiany w pigułce

    • Umiejętności zastępują stare @rule – to ustrukturyzowane foldery z plikiem SKILL.md, które agent ładuje tylko wtedy, gdy są potrzebne, zamiast wprowadzać cały blok tekstu do każdej konwersacji.
    • Globalny AGENTS.md definiuje instrukcje dla całego projektu, co eliminuje potrzebę rozrzucania reguł po różnych plikach konfiguracyjnych.
    • Wybór gałęzi bazowej w widoku porównania gałęzi pozwala teraz wskazać, z którą gałęzią chcemy zestawić obecne zmiany.
    • Przełączanie wszystkich fragmentów diffa jednym poleceniem przyspiesza nawigację po zmianach.
    • C++ runnables umożliwiają uruchamianie plików wykonywalnych C++ bezpośrednio z poziomu edytora.

    Jak działają umiejętności?

    Umiejętność to folder zawierający plik SKILL.md z metadanymi i instrukcjami. Agent widzi katalog wszystkich zainstalowanych umiejętności i może załadować dowolną z nich na żądanie. Można to zrobić na dwa sposoby: przez polecenie slash (/) w edytorze wiadomości albo przez wzmiankę @skill w menu autouzupełniania.

    Tworzenie nowych umiejętności jest proste. Zed ma wbudowaną umiejętność create-skill, która prowadzi przez proces konfiguracji krok po kroku. Dostępny jest również menedżer umiejętności pod cmd-alt-l na macOS oraz ctrl-alt-l na Windows i Linuksie. Można także zaimportować umiejętność z pliku Markdown na GitHubie, używając polecenia agent: create skill from url w palecie komend.

    Są jednak pewne ograniczenia techniczne. Łączny rozmiar nazw i opisów wszystkich umiejętności nie może przekraczać 50KB – jeśli limit zostanie przekroczony, nadmiarowe umiejętności znikają z katalogu, a użytkownik otrzymuje ostrzeżenie w interfejsie. Plik SKILL.md powinien mieścić się w 500 liniach, a szczegółowe materiały referencyjne lepiej przenieść do folderu references/.

    Koniec ery @rule

    Dla dotychczasowych użytkowników to zmiana, która wymaga działania. Stary system reguł i wpis @rule w autouzupełnianiu zostały całkowicie usunięte. Wcześniej reguły działały jak ściana tekstu wprowadzana do każdej konwersacji – agent musiał przetwarzać całość za każdym razem.

    Nowy system działa inaczej. Umiejętności są ładowane selektywnie, tylko gdy agent uzna, że są potrzebne do konkretnego zadania. To poprawia wydajność i zmniejsza szum w kontekście. Wszystkie istniejące reguły trzeba teraz ręcznie przenieść do nowego formatu – nie ma automatycznej migracji.

    Globalne instrukcje i pozostałe usprawnienia

    Plik AGENTS.md to kolejny element porządkujący pracę z agentami. Działa na poziomie całego projektu – definiuje instrukcje, które agent bierze pod uwagę niezależnie od tego, który konkretnie skill został załadowany. To wygodne rozwiązanie dla zespołów, które chcą zachować spójność stylu kodowania czy konwencji nazewnictwa bez powtarzania tych samych zasad w każdym skonfigurowanym skillu.

    W kwestii workflow z kodem: pojawiła się możliwość wyboru gałęzi bazowej przy porównywaniu zmian w widoku diffa. Nowe polecenie zwijania i rozwijania wszystkich fragmentów diffa naraz znacznie przyspiesza przeglądanie większych pull requestów czy commitów.

    Jeśli chodzi o C++, Zed dodał wsparcie dla uruchamiania plików wykonywalnych, co jest korzystne dla programistów pracujących z tym językiem. Aktualizacja poprawia również stabilność na Linuksie i wprowadza poprawki błędów w integracjach z AI, Gitem oraz MCP (Model Context Protocol).

    Dlaczego to ma znaczenie dla zespołów deweloperskich

    Dla grup stosujących vibe coding lub AI-driven development, umiejętności pozwalają na standaryzację wewnętrznych standardów pisania kodu czy podejścia do testów bez konieczności dołączania dużych bloków kontekstu w każdym prompcie. Jest to szczególnie przydatne w zespołach DevOps, gdzie agenci muszą obsługiwać różne workflow – od integracji z bazami danych po przetwarzanie dokumentów. Umiejętność ładuje dokładnie te instrukcje, które są potrzebne do konkretnego zadania, zamiast zalewać agenta niepotrzebnymi informacjami.

    Ustawienia okna konfiguracji również doczekały się drobnego, ale użytecznego usprawnienia – w breadcrumb pojawił się przełącznik zakresu dla podstron takich jak umiejętności, co pozwala łatwo przeskakiwać między konfiguracją użytkownika a konfiguracją projektu.

    Źródła

  • OpenCode v1.14.50: stabilniejsze sesje i nowe możliwości SDK dla programistów

    OpenCode v1.14.50: stabilniejsze sesje i nowe możliwości SDK dla programistów

    OpenCode doczekał się kolejnej aktualizacji – wersja v1.14.50 została udostępniona użytkownikom 13 maja 2026 roku. Wprowadza ona sześć zmian, które koncentrują się głównie na stabilności sesji HTTP oraz rozszerzeniu możliwości SDK. Ta aktualizacja rozwiązuje kilka problemów zgłaszanych przez społeczność.

    Kluczowe zmiany w skrócie

    • Stabilność strumieni HTTP – naprawiono zrywanie połączeń podczas ciągłych aktualizacji instancji, co poprawia płynność pracy w czasie rzeczywistym.
    • Obsługa przeciążonych sesji – ulepszone komunikaty błędów dla sesji zajętych innymi operacjami.
    • Nowe zapytania w SDK v1.14.50 – dodano wsparcie dla odpytywania katalogów i przestrzeni roboczych, co ułatwia nawigację po projektach.
    • Renderowanie Markdown w TUI – przywrócono domyślne formatowanie tekstu w terminalu.
    • Konfiguracja modeli – system automatycznie przełącza się na zapasowe modele, gdy główny provider zawiedzie.

    Naprawione strumienie i lepsza obsługa błędów

    Głównym celem tej aktualizacji było ustabilizowanie sesji HTTP. Wcześniej zdarzało się, że strumienie zdarzeń (event streams) przerywały się podczas długotrwałych operacji, co było frustrujące dla programistów korzystających z ciągłych aktualizacji instancji.

    Teraz połączenia pozostają otwarte tak długo, jak to konieczne. Zespół OpenCode poprawił również komunikaty błędów w interfejsach CLI i SDK – użytkownicy otrzymują teraz jasne informacje o problemach, co ułatwia debugowanie sesji pod dużym obciążeniem.

    SDK v1.14.50 z nowymi możliwościami

    Deweloperzy integrujący OpenCode z własnymi narzędziami zyskali nowe funkcje. SDK v1.14.50 obsługuje teraz zapytania o strukturę katalogów i przestrzenie robocze (workspace i directory query support). Umożliwia to precyzyjne odpytywanie agentów o zawartość konkretnych folderów, eliminując potrzebę ręcznego przeszukiwania całego projektu.

    To znaczące ułatwienie dla narzędzi budowanych wokół OpenCode, ponieważ agenci mogą szybciej lokalizować pliki i lepiej rozumieć kontekst projektu.

    Drobne, ale odczuwalne poprawki

    Wersja v1.14.50 przywraca domyślne renderowanie Markdown w interfejsie terminalowym (TUI). Po wcześniejszych aktualizacjach niektórzy użytkownicy zauważyli, że sformatowane odpowiedzi modeli były wyświetlane jako surowy tekst. Teraz nagłówki, listy i fragmenty kodu znów wyglądają zgodnie z oczekiwaniami.

    Dodatkowo wprowadzono solidniejszy mechanizm fallbacku dla konfiguracji modeli AI. Jeśli główny provider (np. Claude, GPT czy Gemini) nie odpowiada, OpenCode automatycznie przełącza się na zapasowy model, co eliminuje konieczność ręcznej interwencji. To usprawnienie może uratować sesję w krytycznych momentach.

    Kontekst dla użytkowników platformy

    OpenCode to jedno z aktywnie rozwijanych narzędzi w ekosystemie vibe codingu oraz AI-assisted web development. Działa w terminalu, jako aplikacja desktopowa i rozszerzenie IDE, obsługując zarówno płatne modele (Claude, GPT, Gemini), jak i darmowe, lokalnie uruchamiane sieci. Aktualizacja v1.14.50 wpisuje się w szerszy trend, w którym producenci narzędzi AI kładą większy nacisk na niezawodność.

    OpenCode ma już 647 śledzonych wydań w changelogu, co świadczy o szybkim rozwoju projektu open-source. Choć ta aktualizacja jest niewielka, rozwiązuje realne problemy zgłaszane przez społeczność, co jest często bardziej wartościowe niż wiele niedopracowanych nowości.

    Źródła