Kategoria: Narzędzia IT

  • 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.