Kategoria: Narzędzia IT

  • Gemini CLI v0.39.0-nightly.20260409: lepsza kontrola i wydajność dla nocnej wersji

    Gemini CLI v0.39.0-nightly.20260409: lepsza kontrola i wydajność dla nocnej wersji

    Google wydało nową nocną wersję swojego narzędzia AI działającego w terminalu — Gemini CLI v0.39.0-nightly.20260409. Aktualizacja koncentruje się na zwiększeniu kontroli użytkownika nad agentem, poprawie wydajności systemu oraz usunięciu kilku kluczowych błędów, które utrudniały pracę. Dla deweloperów i entuzjastów web devu oraz AI oznacza to bardziej stabilne i przewidywalne środowisko pracy bezpośrednio z linii poleceń.

    Wśród najważniejszych zmian widać wyraźny nacisk na bezpieczeństwo operacji. Tryb Plan, w którym AI może autonomicznie planować zadania, teraz wymaga od użytkownika ręcznego potwierdzenia przed aktywacją każdej umiejętności. To istotna zmiana, która pozwala na lepszą kontrolę nad bardziej złożonymi, automatycznymi workflow. Dopracowano także formatowanie wyjścia narzędzi oraz obsługę klawiszy w Windows Terminal, rozwiązując problem z usuwaniem całych słów za pomocą Ctrl+Backspace.

    Kluczowe zmiany w nocnej wersji 0.39.0

    • Wzmocniona kontrola w trybie Plan: Wprowadzono obowiązkowe potwierdzenie użytkownika dla aktywacji umiejętności, co daje większą władzę nad działaniami agenta.
    • Poprawki dla Windows Terminal i stabilności sesji: Naprawiono błąd uniemożliwiający usuwanie całych słów (Ctrl+Backspace) w Windows Terminal oraz problemy z wznawianiem zawieszonych sesji.
    • Wydajność i optymalizacja: Dodano nowe mechanizmy testowania zużycia pamięci i CPU, aby zapobiegać regresjom wydajności.
    • Bezpieczeństwo sandboxa: Wdrożono refaktoryzację sandboxa Seatbelt dla macOS oraz naprawiono problemy z symlinkami na Windows, co zwiększa izolację i bezpieczeństwo wykonywanych operacji.

    Ta nocna wersja to nie tylko poprawki, ale także rozwój infrastruktury testowej. Zespół dodał zaawansowane testy integracyjne mierzące zużycie pamięci i wydajność procesora, co pokazuje dbałość o długoterminową stabilność projektu.

    Dla użytkowników oznacza to bardziej responsywne działanie CLI. Szczególnie ważna dla programistów pracujących na Windowsie jest poprawka w Windows Terminal, która przywraca intuicyjne edytowanie linii poleceń.

    Rozwój ekosystemu i przyszłość

    Wydanie wpisuje się w szerszy trend rozwoju Gemini CLI jako platformy. Widać inwestycję w rozszerzalność i dalsze prace nad integracją z MCP serverami. Projekt, będący open source, aktywnie rozwija społeczność, co potwierdza długa lista pull requestów od wielu kontrybutorów.

    Choć wersja nightly jest przeznaczona dla użytkowników chcących testować najnowsze, czasem niestabilne funkcje, to wprowadzone w wersji 0.39.0 poprawki są niezwykle praktyczne. Niektóre z nich, jak naprawa Ctrl+Backspace na Windowsie, były wyczekiwane przez długi czas. To pokazuje, że zespół nie tylko dodaje nowe, eksperymentalne możliwości, ale także słucha społeczności i troszczy się o codzienny komfort pracy.

    Dla deweloperów zainteresowanych AI, web devem czy automatyzacją zadań devopsowych, Gemini CLI staje się coraz bardziej dojrzałym narzędziem. Ta nocna aktualizacja, skoncentrowana na kontroli i wydajności, to krok w kierunku zapewnienia stabilności potrzebnej do profesjonalnego wykorzystania AI w terminalu. Warto obserwować dalsze zmiany, zwłaszcza w stabilnych wydaniach, które powinny wkrótce wchłonąć te ulepszenia.

    Źródła

  • OpenCode v1.4.0: telemetria OTLP, wsparcie proxy i ulepszenia dla programistów

    OpenCode v1.4.0: telemetria OTLP, wsparcie proxy i ulepszenia dla programistów

    OpenCode w wersji 1.4.0 wprowadza zmiany ułatwiające pracę zespołom programistycznym. Aktualizacja skupia się na monitorowaniu pracy systemu (observability), integracji z infrastrukturą firmową oraz poprawkach w codziennym użytkowaniu. Są to funkcje przydatne dla osób, które włączają narzędzia AI do swoich procesów wytwórczych.

    OTLP i monitorowanie w firmach

    Główną nowością jest obsługa protokołu OpenTelemetry (OTLP). Pozwala on na przesyłanie logów i zdarzeń (a opcjonalnie metryk i trace'ów) do systemów takich jak Grafana, New Relic czy Honeycomb. Dzięki temu firmy mogą monitorować działanie OpenCode v1.4.0 w ramach swoich standardowych narzędzi.

    Zespoły DevOps mogą teraz tworzyć wspólne dashboardy, które łączą dane z aplikacji z informacjami o wykorzystaniu AI w procesie programowania. Konfiguracja eksportera OTEL jest automatycznie kopiowana do zarządzanych workspace’ów. Naprawiono też błąd w parsowaniu nagłówków, który występował przy wartościach ze znakiem „=”.

    Obsługa HTTP proxy i stabilność sieci

    W wersji 1.4.0 dodano pełne wsparcie dla HTTP proxy. Jest to rozwiązanie dla programistów pracujących w sieciach z restrykcyjnymi firewallami, co często zdarza się w dużych organizacjach. Poprawka ta umożliwia korzystanie z narzędzia tam, gdzie wcześniej blokowały to polityki sieciowe.

    Zwiększono również stabilność połączeń. Wyeliminowano problem z wiszącymi timeoutami, które pojawiały się po nieudanych próbach pobierania danych. Dodatkowo komunikaty o błędach podczas logowania (opencode login) są teraz bardziej precyzyjne, co przyspiesza diagnozowanie problemów z siecią.

    Zmiany w TUI i wersji desktopowej

    Interfejs tekstowy (TUI) otrzymał nowe skróty klawiaturowe, które pozwalają na szybsze przełączanie się między wariantami modeli.

    W aplikacji desktopowej zmieniono sposób prezentacji subagentów. Sesje mają teraz czytelne tytuły i jaśniejsze statusy postępu prac. Ustawienie automatycznego akceptowania uprawnień trafiło do głównego panelu ustawień, co uprościło wygląd głównego okna.

    Poprawki techniczne i optymalizacja

    W silniku aplikacji wprowadzono zmiany w obsłudze błędów u poszczególnych dostawców:

    • W przypadku providera Alibaba błędy dotyczące limitów zapytań (rate limiting) powodują teraz ponowienie próby zamiast błędu.
      Naprawiono błędy w integracji z OpenRouter.
    • Ujednolicono poziomy rozumowania (reasoning) dla GitHub Copilot przy korzystaniu z modeli Anthropic.
      Warianty modeli są teraz na stałe przypisane do konkretnych wersji, co eliminuje błędy przy ich zmianie.

    Status prac nad OpenCode v1.4.0

    Wersja 1.4.0 dostosowuje narzędzie do wymogów pracy w dużych zespołach. Wprowadzenie OTLP i obsługi proxy odpowiada na potrzeby administratorów IT i działów bezpieczeństwa. Jednocześnie poprawki w interfejsie i stabilności działania wpływają na komfort pracy programistów korzystających z OpenCode na co dzień.

    Źródła

  • Kimi Code CLI 1.29.0: Lepsza Kontrola Agentów i Kompatybilność Terminala

    Kimi Code CLI 1.29.0: Lepsza Kontrola Agentów i Kompatybilność Terminala

    Kimi Code CLI, terminalowy asystent programistyczny od MoonshotAI, otrzymał właśnie znaczącą aktualizację. Wersja 1.29.0, dostępna jako najnowsze wydanie stabilne, wprowadza szereg usprawnień skupionych na precyzyjnym sterowaniu agentami AI oraz niezawodności pracy w różnych środowiskach terminalowych. To kolejny krok w ewolucji narzędzia, które zamienia terminal w pełnoprawnego, inteligentnego współpracownika przy pisaniu kodu.

    Hierarchiczne instrukcje projektowe z AGENTS.md

    Jedną z kluczowych nowości jest wsparcie dla hierarchicznego ładowania plików AGENTS.md. Jak to działa? CLI automatycznie wykrywa i scala instrukcje z plików AGENTS.md, zaczynając od katalogu głównego projektu Git aż do aktualnego katalogu roboczego, uwzględniając także pliki w ukrytych katalogach .kimi/. Co ważne, instrukcje z głębszych poziomów hierarchii mają priorytet, ale całość podlega limitowi 32 KiB. Dzięki temu najbardziej szczegółowe wytyczne dla agenta w konkretnym podkatalogu nie zostaną pominięte przez limity kontekstu, co zapewnia precyzyjne sterowanie zachowaniem AI na poziomie projektu.

    To eleganckie rozwiązanie problemu zarządzania złożonymi instrukcjami w dużych repozytoriach, gdzie różne części kodu mogą wymagać odmiennego podejścia.

    Większa niezawodność środowiska terminalowego

    Najnowsza wersja kładzie duży nacisk na poprawę komfortu pracy w terminalu. Naprawiono problemy z renderowaniem kolorów na terminalach bez wsparcia truecolor (np. w popularnym Xshell). Dodano także nowe zmienne środowiskowe: KIMI_CLI_PASTE_CHAR_THRESHOLD i KIMI_CLI_PASTE_LINE_THRESHOLD. Pozwalają one kontrolować, kiedy wklejany tekst jest zwijany do postaci placeholderów. Jest to istotne dla użytkowników wprowadzających znaki CJK (chińskie, japońskie, koreańskie) w terminalach takich jak Xshell po połączeniu przez SSH – zapobiega to błędom przy przetwarzaniu danych wejściowych.

    Dodano również obsługę proxy SOCKS, automatycznie normalizując prefiks socks:// do socks5:// w zmiennych środowiskowych dla lepszej kompatybilności. Ułatwia to pracę za zaporami sieciowymi czy w specyficznych konfiguracjach korporacyjnych.

    Nowe komendy i usprawnienia agentów

    Wśród nowych funkcji znajdziemy komendę /title, która pozwala na ręczne przemianowanie sesji. Co istotne, zapobiega ona nadpisaniu nazwy przez automatyczny mechanizm nadawania tytułów, jednocześnie unifikując stan sesji w pliku state.json.

    Znacząco ulepszono także agenta explore, odpowiedzialnego za analizę kodu. Zyskał on możliwość przyjmowania wyspecjalizowanych ról, różnych poziomów szczegółowości (thoroughness levels) oraz automatyczne dostarczanie kontekstu środowiska, np. informacji o repozytorium przy starcie. Teraz potrafi on też aktywnie sugerować głównemu agentowi wykorzystanie swoich możliwości podczas researchu w bazie kodu.

    Poprawki stabilności i wydajności

    Pod maską dokonano wielu istotnych poprawek. Rozwiązano problem konwersji znaków nowej linii (LF na CRLF) w systemie Windows, który mógł uszkadzać pliki tekstowe. Dodano nagłówki Cache-Control do zasobów webowych, aby uniknąć błędów 404 związanych z buforowaniem po aktualizacji. Ulepszono także mechanizm czyszczenia pustych sesji, który teraz działa na wszystkich ścieżkach wyjścia z programu, w tym przy błędach i awaryjnym zakończeniu.

    Dodanie informacji o systemie operacyjnym i powłoce (shell) do promptu systemowego poprawia kompatybilność z Windows, a refaktoryzacja współdzielonej logiki prepare_soul eliminuje wyścigi (race conditions) przy współbieżnym wznawianiu sesji w tle.

    Podsumowanie: dojrzałość narzędzia dla deweloperów

    Wydanie Kimi Code CLI 1.29.0 to nie spektakularna rewolycja, ale solidny krok w stronę dojrzałości produktu. Skupia się na eliminowaniu niedogodności – od lepszego wsparcia znaków międzynarodowych, przez naprawę błędów na specyficznych platformach, po wprowadzenie bardziej elastycznego zarządzania instrukcjami projektowymi. Te usprawnienia, wraz z potężnym modelem Kimi K2.5 i wsparciem dla Model Context Protocol (MCP), umacniają pozycję tego otwartoźródłowego narzędzia jako jednego z najbardziej zaawansowanych asystentów AI działających bezpośrednio w terminalu. Aktualizację można pobrać w formie plików binarnych ze SourceForge lub śledzić oficjalne release notes na GitHubie.

    Źródła

  • CodePilot: Niezależna Alternatywa Dla Pulpitu w Epoce Asystentów AI

    CodePilot: Niezależna Alternatywa Dla Pulpitu w Epoce Asystentów AI

    W świecie zdominowanym przez chmurę i zamknięte ekosystemy, takie jak GitHub Copilot czy Microsoft Copilot, pojawiają się interesujące alternatywy. W pełni open-source’owe, desktopowe środowiska pracy zaprojektowane specjalnie do współpracy z modelami AI, takie jak Claude Code, oferują prywatność, kontrolę i elastyczność, przyciągając społeczność deweloperów ceniących niezależność. Przykładami takich projektów są Codeium, Continue, Tabnine, Tabby czy FauxPilot.

    Czym są alternatywy i czym różnią się od GitHub Copilot?

    Warto od razu wyjaśnić pewne zamieszanie nazewnicze. GitHub Copilot to rozbudowany, komercyjny asystent programistyczny od Microsoftu, zintegrowany z IDE oraz platformą GitHub. Z kolei alternatywy open source to często zupełnie inne projekty: lekkie, lokalne aplikacje desktopowe lub rozszerzenia, które służą jako centra dowodzenia dla różnych modeli językowych.

    Podstawowa filozofia jest odmienna. Wiele z tych narzędzi działa na zasadzie „Bring Your Own Key” (BYOK). Użytkownik łączy się bezpośrednio z wybranym dostawcą AI — jak Anthropic (Claude), OpenAI, Google czy AWS Bedrock — używając własnego klucza API. Cała komunikacja przebiega z pominięciem pośredników, co gwarantuje, że ani kod, ani konwersacje nie są przesyłane przez serwery twórców aplikacji. To rozwiązanie dla osób, które priorytetowo traktują bezpieczeństwo i własność danych.

    Kluczowe funkcje: więcej niż tylko chat

    Zaawansowane narzędzia open source nie są po prostu kolejnymi front-endami do czatu z AI. To zaawansowane przestrzenie robocze (workspaces) zaprojektowane z myślą o rzeczywistej pracy deweloperskiej.

    • Wielowątkowe konwersacje pozwalają prowadzić niezależne rozmowy w różnych kontekstach projektowych. Niektóre aplikacje oferują tryby pracy dedykowane generowaniu i analizie kodu, planowaniu architektury lub zadawaniu ogólnych pytań. Istotną cechą jest kontrola uprawnień — użytkownik musi wyrazić zgodę, zanim AI wprowadzi jakiekolwiek zmiany w plikach, co zapobiega niechcianym modyfikacjom.

    • Workspace to panel, w którym można na żywo przeglądać pliki projektu, śledzić zmiany sugerowane przez model i przeprowadzać ich code review. Niektóre systemy zapewniają, że asystent zachowuje spójny styl i kontekst między sesjami. Deweloperzy mogą też często tworzyć i udostępniać gotowe wzorce promptów przydatne w specyficznych zadaniach.

    Rozwój napędzany przez społeczność

    Jako projekty open source hostowane często na GitHubie, narzędzia te dynamicznie ewoluują dzięki wkładowi społeczności. Ich roadmapy i nowe funkcje są kształtowane przez rzeczywistych użytkowników. Rozwój skupia się na optymalizacjach, takich jak inteligentny system zarządzania kontekstem, który automatycznie mierzy zużycie tokenów i kompresuje długie konwersacje, a także na technikach redukujących zużycie pamięci.

    Dla kogo są alternatywy open source?

    Te narzędzia nie konkurują bezpośrednio z wszechobecnym GitHub Copilot pod względem głębokiej integracji z IDE czy automatyzacji w chmurze. Ich siłą jest coś innego; są to doskonałe rozwiązania dla:

    • purystów open source, którzy unikają zamkniętych, komercyjnych produktów;
    • deweloperów dbających o prywatność, pragnących pełnej kontroli nad danymi i przepływem informacji do AI;
    • entuzjastów eksperymentujących z różnymi modelami (Claude, GPT, Gemini), którzy chcą mieć do nich dostęp w jednym, spójnym interfejsie;
    • osób pracujących nad wrażliwymi projektami, w których kod nie może opuszczać lokalnej infrastruktury.

    Podsumowanie

    W ekosystemie asystentów AI dla deweloperów alternatywy open source zajmują ważną, niszową pozycję. Nie oferują może tak głębokiej automatyzacji jak agenci GitHub Copilot, ale rekompensują to niepodważalnymi zaletami: transparentnością kodu, brakiem opłat abonamentowych (poza kosztami API), pełną kontrolą nad danymi i niezwykłą elastycznością. To narzędzia, które oddają moc w ręce użytkownika, zamiast zamykać go w wygodnym, ale kontrolowanym środowisku. Dla rosnącej grupy programistów to właśnie jest kluczową wartością w erze powszechnej sztucznej inteligencji.

    Źródła

  • OpenCode v1.2.25: lepsze bezpieczeństwo typów, wsparcie arm64 i rozszerzona integracja z modelami językowymi

    OpenCode v1.2.25: lepsze bezpieczeństwo typów, wsparcie arm64 i rozszerzona integracja z modelami językowymi

    Projekt OpenCode, otwartoźródłowy asystent kodowania działający w terminalu, IDE i jako aplikacja desktopowa, właśnie otrzymał znaczącą aktualizację. Wersja 1.2.27 przynosi szereg usprawnień architektonicznych, które mają bezpośredni wpływ na stabilność, wydajność i możliwości pracy z AI. To nie są kosmetyczne poprawki, lecz zmiany, które realnie wpływają na codzienną pracę programistów korzystających z narzędzi do „vibe coding”.

    Najważniejsze nowości? Zwiększone bezpieczeństwo typów dzięki „branded types”, natywne wsparcie dla architektury ARM64 na Windows oraz rozszerzenie możliwości integracji z dużymi modelami językowymi (LLM) o rozwiązania spoza ekosystemu OpenAI.

    Fundamenty bezpieczniejsze niż kiedykolwiek: branded types

    Jedną z kluczowych zmian w rdzeniu OpenCode jest wprowadzenie tzw. branded types. To zaawansowana technika w TypeScripcie, która pomaga zapobiegać błędom logicznym przez nadanie typom prostym (jak string czy number) swoistej „tożsamości”. Na czym to polega? W skrócie: identyfikator projektu (ProjectID) przestaje być zwykłym ciągiem znaków. Staje się osobnym typem, który nie jest wymienny z identyfikatorem sesji (SessionID) czy dostawcy modelu (ProviderID).

    W praktyce oznacza to, że kompilator wyłapie błąd, jeśli przez pomyłkę przekażesz WorkspaceID tam, gdzie oczekiwany jest ModelID. Te typy są teraz propagowane przez wewnętrzne sygnatury funkcji, schematy w bazie danych (Drizzle) i walidację danych (Zod). Dla programistów korzystających z API OpenCode lub rozwijających jego wtyczki to duży skok w stronę eliminacji całej klasy błędów już na etapie pisania kodu. To także uszczelnienie przepływów związanych z kontami użytkowników, które zostały przepisane z użyciem biblioteki Effect dla większej przewidywalności i odporności na błędy.

    ARM64 dla Windows: szybsza praca na nowym sprzęcie

    Drugą ważną wiadomością, zwłaszcza dla użytkowników laptopów z procesorami ARM (jak Microsoft Surface Pro z Qualcomm Snapdragon X), jest dodanie natywnych plików binarnych dla ARM64 na Windows. Dotąd OpenCode prawdopodobnie działał na takim sprzęcie przez warstwę emulacji. Teraz może korzystać z pełni możliwości procesora, co przekłada się na szybsze uruchamianie, płynniejszą pracę terminala i mniejsze zużycie energii.

    To nie jest odosobniona poprawka. W zestawieniu widać też inne zmiany dla środowiska Windows, jak ukrywanie konsoli w tle w frameworku Electron czy poprawki w ścieżkach Git dla Git Bash, MSYS2 i Cygwin. Wszystko to wskazuje na konsekwentne dbanie o doświadczenie użytkowników tej platformy.

    LLM bez granic: Azure, Vertex AI i optymalizacja agenta

    LLM bez granic: Azure, Vertex AI i optymalizacja agenta

    Jeśli chodzi o integrację z AI, OpenCode w wersji 1.2.27 znacząco poszerza horyzonty. Najważniejsze zmiany to:

    • Wsparcie dla modeli innych niż OpenAI na Azure. Teraz narzędzie potrafi korzystać z endpointów completions dostępnych na platformie Azure, otwierając drogę do używania różnorodnych modeli hostowanych w chmurze Microsoftu.
    • Integracja z Google Vertex AI. Dzięki wkładowi społeczności dodano obsługę Vertex AI poprzez zmienną środowiskową GOOGLE_VERTEX_LOCATION. To proste, ale potężne rozszerzenie ekosystemu dostępnych modeli.
    • Lepsza prezentacja umiejętności agenta. To ciekawa optymalizacja pod kątem efektywności kosztowej. Mechanizm, który informuje model AI o dostępnych narzędziach (skills) i funkcjach OpenCode, został dopracowany. Chodzi o to, by zużywać mniej tokenów na te opisy, jednocześnie zwiększając szansę, że AI poprawnie zidentyfikuje i wywoła potrzebne narzędzie. W efekcie sesje mogą być tańsze i bardziej precyzyjne.
    • Wsparcie wariantów „thinking” dla SAP AI. Dla użytkowników modeli SAP AI dodano możliwość korzystania z różnych wariantów rozumowania (thinking variants).

    Stabilność, stabilność i jeszcze raz stabilność

    Stabilność, stabilność i jeszcze raz stabilność

    Lista poprawek w tym wydaniu jest długa i pełna technicznych szczegółów, które przekładają się na znacznie większy komfort użytkowania. Wśród nich warto wymienić:

    • Odporność na błędy przy pobieraniu danych organizacji. System lepiej radzi sobie z chwilowymi problemami sieciowymi.
    • Bezpieczne przełączanie kont. Logowanie i aktualizowanie kont zostało zabezpieczone, co jest kluczowe w środowiskach wieloużytkownikowych.
    • Rozwiązanie problemu z cache'owaniem dowiązań symbolicznych (symlinków). Zapobiega to tworzeniu duplikatów kontekstu w pamięci.
    • Naprawiony timeout przy przetwarzaniu długich strumieni odpowiedzi z LLM oraz ograniczenie dostępu do katalogów systemowych w celu zwiększenia bezpieczeństwa.
    • Poprawki w zarządzaniu cyklem życia procesów (spawn lifecycle), które eliminują procesy „zombie” pozostające w tle.

    Aplikacja desktopowa i terminal: płynniejszy interfejs

    Część desktopowa oraz TUI (Text-based User Interface, czyli interfejs terminalowy) również otrzymały solidną porcję poprawek. Użytkownicy aplikacji desktopowej zauważą:

    • Większą płynność i brak problemów ze stanem terminala. Poprawiono animacje, zarządzanie fokusem i ogólną responsywność.
    • Naprawione błędy z rozmiarem paska bocznego na urządzeniach mobilnych w trybie workflow.
    • Przepisaną inicjalizację serwera i połączenia WebSocket dla większej niezawodności.
    • Nowe okno debugowania i statystyki deweloperskie dla osób chcących zajrzeć pod maskę.
    • Zoptymalizowane renderowanie sesji, co odciąża procesor.

    W interfejsie terminalowym (TUI) poprawiono m.in. obsługę błędów przy tworzeniu nowej sesji i zapewniono, że automatyczne przesyłanie promptów (--prompt) czeka na pełne załadowanie listy modeli.

    Dlaczego te zmiany mają znaczenie?

    OpenCode pozycjonuje się jako otwarta alternatywa dla komercyjnych asystentów kodowania. Wydanie 1.2.27 pokazuje, że projekt dojrzewa nie tylko przez dodawanie nowych funkcji, ale przede wszystkim przez inwestycję w solidność fundamentów.

    Bezpieczeństwo typów to mniej błędów w przyszłości. Wsparcie ARM64 to dbałość o użytkowników nowej generacji sprzętu. Rozszerzenie integracji z LLM pozwala uniknąć uzależnienia od jednego dostawcy (vendor lock-in) i zapewnia elastyczność. Natomiast setki poprawek stabilizacyjnych oznaczają, że można skupić się na pisaniu kodu z pomocą AI, zamiast walczyć z narzędziem.

    Dla społeczności skupionej wokół web developmentu, AI i „vibe coding” to istotny krok. Pokazuje on, że otwartoźródłowe narzędzia mogą nie tylko naśladować liderów rynku, ale też wprowadzać innowacje na poziomie architektury i kompatybilności. Teraz pozostaje tylko sprawdzić, jak te wszystkie ulepszenia sprawdzają się w codziennej pracy.

  • Kimi Code CLI zyskuje tryb planowania, wizualizację i lepszą obsługę plików

    Ostatnie aktualizacje Kimi Code CLI, terminalowego asystenta AI od Moonshot AI, mocno stawiają na kontrolę i przejrzystość. Zamiast agenta działającego jak „czarna skrzynka”, użytkownicy otrzymują narzędzia do zatwierdzania jego planów, śledzenia każdego kroku i sprawnego zarządzania kodem. To wyraźny sygnał, że rozwój tego typu narzędzi idzie w stronę większej współpracy człowieka z AI, a nie pełnej autonomii.

    Kluczowe nowości pojawiły się w wersjach 1.7.0, 1.15.0, a zwłaszcza 1.12.0 z lutego 2026 roku. Wprowadzają one tryb planowania, dedykowane polecenie do wizualizacji sesji oraz szereg usprawnień w panelach zatwierdzania i pracy z plikami. Brzmi technicznie? W praktyce to zmiana, która może znacząco przyspieszyć pracę i zwiększyć pewność podczas korzystania z asystenta.

    Tryb planowania: najpierw strategia, potem wykonanie

    Najważniejszą nowością jest tryb planowania. Dotąd agent mógł od razu przystąpić do modyfikacji plików czy uruchamiania komend. Teraz, po aktywacji trybu (skrótem Shift+Tab lub komendą /plan), jego możliwości są czasowo ograniczone wyłącznie do narzędzi odczytu: przeglądania katalogów (Glob), wyszukiwania w plikach (Grep) i czytania plików (ReadFile).

    W tym trybie agent analizuje zadanie, a następnie tworzy ustrukturyzowany plan, który zapisuje w specjalnym pliku. Ten plan to nie luźna notatka, lecz konkretna lista kroków do wykonania. Dopiero po jego stworzeniu agent prosi użytkownika o zatwierdzenie, prezentując plan w specjalnym panelu. Użytkownik może go zaakceptować, odrzucić lub – jak pokazują najnowsze zapowiedzi – zażądać jego edycji. Agent będzie wtedy modyfikował tylko odpowiednie sekcje planu, zamiast przepisywać go od zera.

    To podejście eliminuje element zaskoczenia. Zamiast sprawdzać historię poleceń po fakcie, wiesz z góry, co agent zamierza zrobić. Jest to szczególnie cenne przy bardziej złożonych refaktoryzacjach czy migracjach, gdzie niechciana zmiana mogłaby zepsuć projekt.

    kimi vis: interaktywna wizualizacja sesji

    Drugi filar aktualizacji to nowe polecenie kimi vis. Uruchamia ono interaktywny dashboard w przeglądarce, służący do dogłębnej inspekcji śladów sesji. To potężne narzędzie do debugowania i zrozumienia sposobu działania agenta.

    Dashboard pozwala przejrzeć chronologię zdarzeń w sesji (timeline), przyjrzeć się pełnemu kontekstowi rozmowy z modelem (context viewer) oraz analizować statystyki użycia. Co praktyczne, z poziomu wizualizacji można też otworzyć katalog sesji czy skopiować jego ścieżkę. W połączeniu z możliwością eksportu i importu całej sesji do pliku ZIP, kimi vis staje się narzędziem do archiwizacji, dzielenia się przykładowymi sesjami lub analizy problematycznych przypadków.

    To kolejny krok w demistyfikacji działania AI. Dzięki wizualizacji możesz zobaczyć, jakie narzędzia były wywoływane, w jakiej kolejności i z jakimi argumentami. Jeśli agent podjął złą decyzję, łatwiej zrozumieć dlaczego.

    Usprawnione panele i skróty klawiszowe

    Usprawnione panele i skróty klawiszowe

    Aby proces zatwierdzania planów i odpowiadania na pytania agenta był płynny, znacznie przeprojektowano interfejs w trybie shell. W wersji 1.15.0 wprowadzono szybkie wybieranie opcji za pomocą klawiszy numerycznych (1-5) w panelach pytań i zatwierdzeń.

    Dodano też nawigację „zakładkową” dla paneli z wieloma pytaniami. Za pomocą strzałek lewo/prawo lub klawisza Tab można przełączać się między pytaniami, co jest bardzo intuicyjne. Panel wizualnie wskazuje, które pytania mają już przypisaną odpowiedź, które jest bieżące, a które oczekują na reakcję. Stan ten jest przywracany po powrocie do danego pytania.

    Może wydawać się to drobnostką, ale ma ogromny wpływ na ergonomię. Praca z agentem przestaje być walką z interfejsem, a staje się płynną interakcją. Usunięcie prefiksu z nazwą użytkownika z promptu również uprościło i oczyściło widok terminala.

    Lepsza praca z plikami i zasobami

    Lepsza praca z plikami i zasobami

    Obsługa plików została dopracowana w kilku obszarach. Po pierwsze, udoskonalono mechanizm wzmiankowania plików za pomocą @. W interfejsie webowym (a koncepcja ta jest kluczowa dla całego ekosystemu) po naciśnięciu @ pojawia się menu z autouzupełnianiem, pozwalając szybko odnosić się do załączonych plików czy plików w obszarze roboczym.

    Co ważne, indeks tych plików jest teraz odświeżany po zmianie sesji lub gdy pliki w workspace ulegną zmianie, co eliminuje problem nieaktualnych sugestii. W wersji 1.12.0 dodano też wsparcie dla osadzonej treści zasobów w trybie ACP (Agent Communication Protocol). To techniczna, ale istotna zmiana, która zapewnia, że gdy używamy Kimi z edytorami takimi jak Zed, Neovim czy Emacs, odwołania do plików za pomocą @ poprawnie dołączają ich zawartość do kontekstu.

    Kontekst i moc modelu K2.5

    Warto pamiętać, że Kimi Code CLI to tylko klient. Jego możliwości są bezpośrednio powiązane z modelem językowym, z którym współpracuje. Obecnie jest to głównie Kimi K2.5, potężny model o architekturze Mixture-of-Experts (MoE).

    K2.5 ma imponujące parametry: 1 bilion parametrów całkowitych, z czego 32 miliardy są aktywne podczas inferencji. Jego skuteczność w zadaniach inżynierii oprogramowania potwierdza wynik 92,3% w OCRBench – benchmarku do oceny zdolności wizualnego kodowania. Co kluczowe dla programistów, oferuje tzw. „thinking mode” (tryb myślenia), który pozwala modelowi na dłuższe, wewnętrzne rozumowanie przed podaniem odpowiedzi. W kontekście CLI model ten jest nie tylko potężny, ale i relatywnie tani, co czyni go konkurencyjnym wobec rozwiązań takich jak Claude Code.

    Podsumowanie: więcej kontroli, mniej niespodzianek

    Ostatnie aktualizacje Kimi Code CLI jasno wyznaczają kierunek: uczynienie AI-assisted coding procesem bardziej przewidywalnym, kontrolowanym i przejrzystym. Tryb planowania oddaje inicjatywę strategiczną w ręce użytkownika, narzędzie kimi vis daje wgląd w „myślenie” agenta, a dopracowane panele i obsługa plików usuwają bariery w codziennej interakcji.

    To nie jest już tylko narzędzie do szybkiego generowania kodu. To coraz bardziej dojrzała platforma do współpracy, w której AI działa jak starannie nadzorowany partner, a nie nieprzewidywalny automat. Dla programistów, którzy potrzebują nie tylko szybkości, ale też pewności i możliwości audytu zmian, te funkcje mogą być decydującym argumentem.

  • OpenCode v1.2.20: Fundament Stabilności i Udoskonalenia Interfejsu Terminalowego

    OpenCode v1.2.20: Fundament Stabilności i Udoskonalenia Interfejsu Terminalowego

    Wydanie OpenCode w wersji 1.2.20, opublikowane 6 marca 2026 roku, to kolejny kluczowy krok w ewolucji tego zaawansowanego środowiska programistycznego wspieranego przez sztuczną inteligencję. Choć nie wprowadza spektakularnych nowości, koncentruje się na kwestiach fundamentalnych dla codziennej pracy – solidności rdzenia i płynności działania. Aktualizacja ta eliminuje poważne problemy z zarządzaniem pamięcią i zwiększa kompatybilność, poprawiając jednocześnie user experience w trybie tekstowego interfejsu użytkownika (TUI).

    Dla zespołu OpenCode takie wydania są często najważniejsze. Stabilna i przewidywalna podstawa pozwala później bezpiecznie wprowadzać eksperymentalne funkcje, na których skupiają się kolejne wersje, jak 1.2.21 czy 1.2.23. Wersja 1.2.20 to cegiełka umacniająca fundament pod przyszłe innowacje.

    Naprawa krytycznego wycieku pamięci w daemonach fsmonitor

    Najpoważniejszą zmianą w tej wersji jest rozwiązanie problemu wycieku pamięci w daemonach fsmonitor. Narzędzie to monitoruje zmiany w systemie plików, reagując na modyfikacje kodu w czasie rzeczywistym. Nieszczelność w jego działaniu była jednak wyjątkowo dotkliwa.

    Podczas uruchamiania testów nieprawidłowo zamykane procesy daemonów potrafiły pozostawiać w pamięci operacyjnej (committed memory) ponad 60 GB śmieci. Dla programistów pracujących na lokalnych maszynach, zwłaszcza tych z mniejszą ilością RAM, taki wyciek prowadził do drastycznego spadku wydajności całego systemu, a nawet do jego zawieszenia. Problem był szczególnie uciążliwy podczas długich sesji deweloperskich lub przy ciągłym uruchamianiu testów jednostkowych i integracyjnych.

    Naprawa tego błędu ma bezpośredni wpływ na developer experience. Zamiast martwić się o restartowanie środowiska co kilka godzin w celu zwolnienia pamięci, użytkownik może skupić się wyłącznie na pisaniu kodu. Zwiększa to również niezawodność OpenCode jako narzędzia do ciągłej integracji (CI), gdzie stabilne zużycie zasobów jest kluczowe.

    Większa kompatybilność: zamiana Bun.which na npm which

    Kolejna istotna zmiana w module core dotyczy zastąpienia narzędzia Bun.which jego odpowiednikiem z ekosystemu npm – npm which. To część szerszego trendu w rozwoju OpenCode, polegającego na stopniowym odchodzeniu od specyficznych API środowiska Bun na rzecz bardziej uniwersalnych rozwiązań z Node.js.

    Funkcja which służy do lokalizowania ścieżek do plików wykonywalnych w systemie. Choć API Buna jest wydajne, jego użycie może czasem powodować problemy z kompatybilnością w niektórych konfiguracjach, zwłaszcza przy złożonych setupach z wieloma menedżerami pakietów lub w kontenerach.

    • Migracja na npm which zwiększa przenośność kodu OpenCode. Oznacza to, że środowisko będzie działać bardziej niezawodnie na różnych dystrybucjach Linuksa, wersjach macOS czy w systemie Windows z WSL2. To strategiczny ruch ułatwiający wdrożenie OpenCode w zróżnicowanych zespołach i infrastrukturach. Trend ten jest kontynuowany w późniejszych wydaniach, w których pojawiają się podobne zmiany, jak zastąpienie Bun.semver czy Bun.shell.

    Przywrócenie obsługi stdin z Buna w TUI

    W obszarze tekstowego interfejsu użytkownika (TUI) wprowadzono ważną poprawkę techniczną. Przywrócono wykorzystanie Bun.stdin do odczytu danych wejściowych z prompta. Poprzednie wydanie eksperymentowało z przejściem na node:stream/consumers w celu poprawy kompatybilności, co jednak najwyraźniej wywołało pewne komplikacje.

    Interfejs TUI w OpenCode jest kluczowy dla osób preferujących pracę bezpośrednio w terminalu. Wszelkie problemy z odczytem komend, zwłaszcza w trybie interaktywnym podczas pisania promptów dla AI, natychmiast odbijają się na produktywności. Przywrócenie sprawdzonego mechanizmu z Bun zapewnia płynność i responsywność, których oczekują programiści. Pokazuje to również podejście zespołu OpenCode: chęć do eksperymentowania, ale i zdolność do szybkiego wycofania zmian, które nie działają optymalnie.

    Kontekst ścieżki rozwoju

    Aby w pełni zrozumieć znaczenie wersji 1.2.20, warto spojrzeć na sąsiadujące wydania. Poprzednia wersja była dużym krokiem w stronę uniezależnienia od Buna. Zawierała serię zamian: Bun.stderr, Bun.color, Bun.connect, Bun.hash, Bun.write i Bun.sleep na ich odpowiedniki z Node.js. Wersja 1.2.20 kontynuuje ten proces, skupiając się na Bun.which.

    Z kolei wersja 1.2.21, wydana dzień później, wprowadza już ulepszenia funkcjonalne, które bazują na stabilności zapewnionej przez „łatanie” w 1.2.20. Mowa tu o poprawie rozwiązywania ścieżek Git na Windowsie, uszczelnieniu wycieku uchwytów sesji PTY czy zachowaniu oryginalnych zakończeń linii (line endings) w narzędziu do edycji. To klasyczny schemat: najpierw budowa solidnego fundamentu, a dopiero potem bezpieczne wznoszenie na nim nowych konstrukcji.

    Dlaczego takie wydania są kluczowe?

    Dla użytkownika końcowego wydania skupione na stabilizacji mogą nie być tak ekscytujące jak te wprowadzające nowe modele AI czy spektakularne funkcje interfejsu. Ich wartość jest jednak nie do przecenienia.

    • Niezawodność to podstawa zaufania do narzędzia. Programista używa OpenCode jako głównego środowiska pracy, a wszelkie problemy z zarządzaniem pamięcią czy kompatybilnością bezpośrednio uderzają w jego efektywność. Stabilne zużycie zasobów jest kluczowe zarówno lokalnie, jak i w środowiskach CI/CD. Wydania takie jak 1.2.20, choć mało efektowne, są niezbędne, aby innowacyjne funkcje mogły działać bez zarzutu. Dzięki takim aktualizacjom OpenCode staje się nie tylko potężnym, ale i godnym zaufania partnerem w procesie tworzenia oprogramowania.