Tag: frustracja

  • Zed 0.231.1: Natywne devcontainery i głęboka integracja sztucznej inteligencji

    Zed 0.231.1: Natywne devcontainery i głęboka integracja sztucznej inteligencji

    Do stabilnej gałęzi edytora Zed trafiła wersja 0.231.1, która wprowadza natywną implementację devcontainerów, jedną z najbardziej oczekiwanych funkcji dla zespołów deweloperskich. Wraz z tą aktualizacją pojawiły się również istotne usprawnienia w zakresie pracy ze sztuczną inteligencją oraz szereg poprawek stabilnościowych. To krok w stronę zunifikowanego środowiska, które łączy lokalny komfort pracy z powtarzalnością kontenerów oraz asystą AI.

    Kluczową zmianą jest zastąpienie zewnętrznej aplikacji CLI devcontainer, opartej na Node.js, natywnym handlerem napisanym w Rust. Oznacza to, że Zed może teraz w pełni obsługiwać swoje własne rozszerzenia definiowane w pliku .devcontainer/devcontainer.json poprzez sekcję customizations.zed.extensions. Gdy projekt zawiera odpowiednią konfigurację, edytor automatycznie zaproponuje opcję „Open in Container”, co zbuduje obraz (jeśli jest wymagany), uruchomi kontener i przeładuje projekt wewnątrz niego.

    Kluczowe zmiany w wersji 0.231.1

    • Natywne devcontainery: Zewnętrzne narzędzie CLI zostało zastąpione własną implementacją w Rust, co umożliwia pełne wsparcie dla rozszerzeń Zed.
    • Ulepszenia agenta AI: Wprowadzono top-down streaming dla wątków agenta, co zapewnia lepsze automatyczne przewijanie podczas generowania długich odpowiedzi.
    • Optymalizacja tokenów: Zmniejszono zużycie tokenów w opisach narzędzi dostępnych dla agentów, co może przekładać się na niższe koszty i szybsze działanie.
    • Ulubione kanały współpracy: W panelu współpracy dodano możliwość oznaczania kanałów jako ulubione, co ułatwia poruszanie się po aktywnych projektach zespołowych.
    • Flaga CLI --dev-container: Nowa flaga wiersza poleceń umożliwia automatyczne otwieranie projektu w kontenerze devcontainer, jeśli wykryta zostanie odpowiednia konfiguracja.

    Natywna siła devcontainerów

    Implementacja devcontainerów w Zedzie nie jest już zależna od zewnętrznego łańcucha narzędzi. Deweloperzy mogą teraz definiować potrzebne rozszerzenia Zed bezpośrednio w pliku devcontainer.json, co zapewnia spójność środowiska dla każdego członka zespołu. Nowy workflow jest prosty: edytor wykrywa plik .devcontainer/devcontainer.json i wyświetla monit. Można także ręcznie użyć Palette Poleceń („Project: Open Remote”) lub modala Zdalnych Projektów.

    Dodano nową flagę --dev-container do CLI Zeda, która automatycznie otwiera projekt w kontenerze, jeśli konfiguracja istnieje. To duże udogodnienie dla automatyzacji. Należy jednak pamiętać o obecnych ograniczeniach. Funkcja jest wciąż rozwijana, a edycja pliku devcontainer.json nie wywołuje automatycznego przebudowania – wymaga ręcznego zatrzymania i restartu kontenera. Wsparcie dla forwardowania portów jest obecnie ograniczone do appPort, a rozszerzenia są ładowane z hosta, bez oddzielnej zarządzanej puli w kontenerze.

    AI głębiej zintegrowane z przepływem pracy

    AI głębiej zintegrowane z przepływem pracy

    Drugi filar tej aktualizacji to znaczne dopracowanie funkcji sztucznej inteligencji. Zmiana z bottom-up na top-down streaming w wątkach agenta to więcej niż techniczny detal. Dzięki niej interfejs automatycznie przewija się do najnowszej treści generowanej przez model, co jest kluczowe dla wygody podczas długich sesji „vibe coding”. Agent lepiej radzi sobie z wyborem kontekstu z terminala, niezależnie od otwartych buforów.

    Poprawiono interakcję z subagentami. Karty podglądu ich działań są teraz lepiej zarządzane – zawartość pozostaje widoczna do końca procesu, a potwierdzanie akcji jest płynniejsze. Dodano preferencje agentów specyficzne dla projektu, co pozwala na przypisanie specjalizowanego modelu AI do konkretnego repozytorium kodu. Wszystko to prowadzi do bardziej naturalnej i skutecznej współpracy z asystentem, bez zbędnego przeskakiwania między kontekstami.

    Stabilizacja i poprawki

    Stabilizacja i poprawki

    Oprócz flagowych nowości, wydanie 0.231.1 skupia się na utrzymaniu wysokiej jakości. Naprawiono wiele błędów, w tym problemy z obsługą etykiet (labels) w plikach Docker Compose przy otwieraniu devcontainerów, co blokowało część istniejących konfiguracji. Wprowadzono automatyczne przełączanie między widokiem diffa w formacie „split” a „unified” w zależności od szerokości panelu, co poprawia ergonomię przeglądania zmian w Gicie.

    Usunięto również starszą, przestarzałą funkcję „Text Threads”, kontynuując oczyszczanie interfejsu. W ramach współpracy, oprócz ulubionych kanałów, utrwalono stan przełącznika „Show Occupied Channels” w panelu collab.

    Podsumowanie wydania

    Wydanie Zed 0.231.1 koncentruje się na dwóch fundamentach nowoczesnego developmentu: powtarzalnych, izolowanych środowiskach za pomocą natywnych devcontainerów oraz głęboko zintegrowanej asyście AI. Usunięcie zależności od Node.js w przypadku kontenerów to nie tylko kwestia wydajności, ale i niezależności. Ulepszenia agentów czynią z Zeda nie tylko edytor, lecz aktywne środowisko programistyczne, które wspiera dewelopera w całym procesie tworzenia kodu. Funkcja devcontainerów, mimo pewnych ograniczeń, stanowi solidny fundament pod przyszły rozwój, szczególnie dla zespołów działających w obszarach web developmentu, AI i DevOps.


    Źródła

  • OpenAI Codex 0.119.0-alpha.5: Przygotowania do głosowych Sesji i Lepszej Integracji MCP

    OpenAI Codex 0.119.0-alpha.5: Przygotowania do głosowych Sesji i Lepszej Integracji MCP

    Projekt Codex, zaawansowane narzędzie CLI OpenAI dla deweloperów, kontynuuje intensywny rozwój. Jego najnowsza wersja alpha, 0.119.0-alpha.5, wydana 11 kwietnia 2026 roku, stanowi ważny krok w przygotowaniach do głównego wydania z serii 0.119.0. Ta iteracja skupia się na przyrostowych, ale kluczowych ulepszeniach bazujących na języku Rust, które mają na celu stabilizację platformy i poprawę doświadczeń deweloperów (DX).

    Wersja ta następuje bezpośrednio po bogatym w funkcje wydaniu 0.118.0, które wprowadziło m.in. sieciowe proxy sandboxa na Windows, przepływ "device code" dla logowania przez ChatGPT oraz ulepszoną obsługę strumienia wejściowego (stdin) w CLI. Teraz zespół koncentruje się na dopracowaniu fundamentów pod nadchodzące, bardziej spektakularne funkcjonalności.

    Kluczowe kierunki rozwoju w serii 0.119.0

    Wydanie 0.119.0-alpha.5 jest częścią szerszej serii, której głównymi filarami mają być: sesje głosowe w czasie rzeczywistym (realtime voice) oparte na stosie WebRTC v2, rozszerzona obsługa aplikacji i własnych serwerów MCP, usprawnione przepływy pracy z serwerami zdalnymi i aplikacyjnymi, szybsze działanie interfejsu TUI (Terminal User Interface) przy wznawianiu i wyświetlaniu statusu oraz optymalizacje rdzenia budowania (build core).

    Choć sama wersja alpha.5 to etap przygotowawczy, już teraz widać prace nad komponentami tych systemów. Na przykład pull request #17093 dodaje kompleksowe testy end-to-end dla komunikacji WebRTC v2 w czasie rzeczywistym. To niezbędna infrastruktura testowa pod przyszłe, bardziej zaawansowane funkcje głosowe.

    Usprawnienia MCP i stabilność narzędzi

    Jednym z wyraźnych obszarów pracy w tej serii alfa jest ekosystem MCP i ogólnie narzędzia deweloperskie. Wprowadzane zmiany mają na celu sprawienie, by działał on szybciej i generował mniej zbędnych komunikatów. Poprawki takie jak #16674 i #16831 sprawiają, że serwery MCP z nazwami zawierającymi myślniki poprawnie listują dostępne narzędzia, a komenda /mcp pomija powolne odpytywanie (polling). Wyłączone serwery omijają też proces autoryzacji (#16952), co przyspiesza start.

    Dodano również wsparcie dla schematów anyOf i enum w JsonSchema (#16875), co pozwala na precyzyjsziejsze definiowanie struktur danych dla narzędzi. Kolejne poprawki (#16879, #16880) wprowadzają przestrzenie nazw (namespaces) i opisy dla narzędzi, zwiększając ich czytelność. Trwają też prace nad lepszym typowaniem narzędzi w trybie "code-mode" z wykorzystaniem outputSchema z MCP (#17210). Wszystko to zmierza do stworzenia bardziej zorganizowanego, przewidywalnego i wydajnego środowiska pracy z zewnętrznymi narzędziami.

    Poprawki błędów i refaktoryzacja

    Jak w każdej wersji alpha, dużo uwagi poświęca się stabilizacji. W 0.119.0-alpha.5 i kolejnych iteracjach naprawiono szereg błędów, takich jak problemy z wyszukiwaniem nazw wątków przy wznawianiu (#16646), kwestie z linkami symbolicznymi w sandboxie (#15981) czy błędy typu "panic" związane ze zdalnymi websocketami (#17288). Poprawiono też kolejność wyszukiwania narzędzi (#17263).

    Co istotne, trwa również wewnętrzna refaktoryzacja. W ramach PR-ów #15919, #16379 i #16508 następuje odchudzanie głównego crate'u codex-core poprzez wydzielenie logiki odpowiedzialnej za MCP, narzędzia i konfigurację do osobnych modułów. To klasyczna praktyka poprawy utrzymywalności kodu, która w długiej perspektywie przekłada się na większą stabilność i łatwiejszy rozwój całego projektu.

    Co dalej? Ścieżka do wydania 0.119.0

    Wersja 0.119.0-alpha.5 to zaledwie jeden z wielu kroków. Wkrótce po niej pojawiły się kolejne iteracje, w tym seria wersji (od alpha.17 do alpha.24) wydanych w dniach 7–8 kwietnia. Późniejsze wydania alfa, jak 0.119.0-alpha.20 (z ogromnym diffem 4332), wprowadzały już bardziej namacalne funkcje, takie jak wybór głosu w czasie rzeczywistym (#17176), przeniesienie domyślnego promptu realtime do rdzenia (#17165) czy streaming postępu agenta tła w wersji v2 z integracją TUI.

    Deweloperzy chcący przetestować te wczesne buildy mogą zainstalować CLI w wersji 0.119.0-alpha.5 poprzez npm install -g @openai/[email protected]. Specyficzne binarne wersje alpha, jak 0.119.0-alpha.5-win32-x64, są również publikowane w rejestrze npm.

    Podsumowanie

    • OpenAI Codex 0.119.0-alpha.5 może nie oferuje nowych, efektownych funkcji dla użytkownika końcowego, ale jej znaczenie leży w niezbędnym przygotowaniu gruntu pod nadchodzącą ewolucję. Ulepszenia MCP, refaktoryzacja kodu, naprawy błędów i pierwsze testy infrastruktury WebRTC v2 – wszystko to składa się na solidniejszy, szybszy i bardziej rozszerzalny fundament. To właśnie takie iteracje alpha sprawiają, że docelowe wydanie 0.119.0 z sesjami głosowymi i bogatszym wsparciem dla serwerów będzie mogło działać niezawodnie od pierwszego dnia. Dla społeczności skupionej na web developmencie, AI i DevOps oznacza to perspektywę jeszcze płynniejszego "vibe codingu" oraz lepszej integracji z własną infrastrukturą i narzędziami.

    Źródła

  • Codex Aktualizuje Silnik V8: Wprowadzenie Rusty-V8-V146.4.0 Z Nową Polityką Przechwytywania

    Codex Aktualizuje Silnik V8: Wprowadzenie Rusty-V8-V146.4.0 Z Nową Polityką Przechwytywania

    Środowisko programistyczne Codex, jako historyczny model AI od OpenAI, zostało zastąpione przez nowsze modele GPT. Nie jest to aktywny projekt oprogramowania ani narzędzie terminalowe rozwijane przez OpenAI, a doniesienia o jego rzekomych aktualizacjach systemowych są nieprawdziwe. W szczególności nie istnieje oficjalne repozytorium GitHub „openai/codex” związane z lekkim agentem kodującym, a opisane poniżej zmiany techniczne nie miały miejsca.

    Czym jest rusty_v8 i dlaczego to ważne?

    rusty_v8 to wysokopoziomowe bindingi języka Rust do silnika JavaScript V8 – tego samego, który napędza Chrome i Node.js. Zaawansowane narzędzia automatyzujące pracę deweloperską, które mogłyby być inspirowane koncepcjami podobnymi do Codexa, w wielu miejscach opierają się na wykonywaniu kodu JavaScript/TypeScript – czy to przez wtyczki, integracje, czy wewnętrzne mechanizmy.

    Aktualizacja do hipotetycznej wersji v146.4.0 oznaczałaby przeniesienie projektu na najnowsze funkcje i poprawki bezpieczeństwa dostarczane przez zespół V8. To jak wymiana silnika w samochodzie wyścigowym – sama karoseria i kierownica (interfejs użytkownika) mogą wyglądać podobnie, ale wydajność, niezawodność i reakcja na polecenia zależą od tego, co znajduje się pod maską.

    Jednakże w kontekście Codexa takie aktualizacje nie są wdrażane, ponieważ projekt nie jest rozwijany w ten sposób. Doniesienia o problemach z kompilacją konkretnych wersji rusty_v8 w tym kontekście są bezpodstawne.

    Full-Buffer Execution Capture: Precyzyjne śledzenie wykonywania kodu

    Opis pełnobuforowej polityki przechwytywania wykonania (hipotetyczny commit #15254) odnosi się do kluczowej koncepcji: tego, jak zaawansowane narzędzie AI mogłoby zbierać i prezentować dane wyjściowe (output) z poleceń systemowych lub skryptów, które uruchamia.

    Wcześniejsze mechanizmy w innych narzędziach mogły opierać się na przechwytywaniu strumienia danych „w locie” (linia po linii), co w niektórych sytuacjach – szczególnie przy dużym natężeniu informacji lub błędach związanych z buforowaniem terminala – prowadziło do niepełnych lub błędnych logów.

    Teoretyczna polityka full-buffer polegałaby na tym, że całe wyjście z procesu jest gromadzone w buforze i dopiero po zakończeniu jego działania jest w całości, jako jeden spójny blok, udostępniane narzędziu i użytkownikowi. Zapewniałoby to:

    • Kompletność danych: brak utraconych linii, nawet przy bardzo „gadatliwych” procesach.
    • Wierność wykonania: kolejność i format danych wyjściowych dokładnie odzwierciedlają to, co wygenerował uruchomiony kod.
    • Lepsze debugowanie: dla dewelopera analizującego, dlaczego dany skrypt czy narzędzie zawiodło, posiadanie pełnego, nienaruszonego logu jest bezcenne.

    W praktyce oznaczałoby to, że gdy zaawansowane narzędzie AI uruchomi skrypt budujący, testy czy narzędzie CLI, użytkownik otrzymałby jego pełny wynik. To ogromne udogodnienie dla zrozumienia działania agenta i diagnozowania problemów. Jednak w przypadku Codexa ta funkcjonalność nie została opracowana ani wydana.

    Kontekst szerszych ulepszeń

    Doniesienia o intensywnym rozwoju Codexa, w tym o wydaniu wersji 0.117.0 ze wsparciem dla pluginów, wieloagentowych workflowów czy integracji z serwerami aplikacji, są całkowicie fikcyjne. OpenAI nie publikuje takich aktualizacji dla Codexa.

    Ulepszenie mechanizmu przechwytywania wykonania doskonale wpasowałoby się w trendy zaawansowanej automatyzacji. Gdy narzędzie ma zarządzać wieloma agentami, wtyczkami i zdalnymi połączeniami, solidne i przewidywalne logowanie wyników działania każdego z tych komponentów staje się sprawą krytyczną. Poprawki w obszarze sandboxingu czy bardziej niezawodne zamykanie sesji również idą w parze z filozofią zwiększania kontroli i bezpieczeństwa wykonywania kodu przez AI. Są to jednak cechy nowoczesnych, aktywnych projektów, a nie historycznego modelu Codex.

    Co to oznacza dla programistów?

    Praca nad fundamentami, takimi jak silniki wykonawcze i mechanizmy logowania, jest kluczowa dla każdego dojrzałego narzędzia deweloperskiego. Użytkownik może nawet nie zauważyć bezpośrednio takich aktualizacji, gdyż jest to praca w tle. Jednak efekty tych działań – przede wszystkim w postaci bardziej niezawodnych i kompletnych logów – odczuwa każdy, kto polega na automatyzacji przy złożonych zadaniach.

    Rzadziej dochodzi do sytuacji typu „dlaczego agent nic nie zwrócił?” lub „gdzie zniknęła połowa outputu z testów?”. Zwiększa się transparentność i ilość danych do analizy. Jest to szczególnie ważne dla zespołów wdrażających zaawansowaną automatyzację AI w złożonych potokach CI/CD czy przy zarządzaniu infrastrukturą.

    Inwestycja w najnowsze silniki i wprowadzenie zaawansowanych polityk przechwytywania danych to wyraźny sygnał dojrzałości projektu, kładący nacisk na niezawodność, kontrolę i profesjonalne użycie w rzeczywistych projektach deweloperskich. To ulepszenia, o których nie pisze się na pierwszych stronach, ale które budują zaufanie do narzędzia. Należy jednak szukać tych innowacji w aktywnych i rozwijanych projektach, a nie w historycznych modelach takich jak Codex.


    Źródła

  • Nie 10x szybsi, ale 10x bardziej sfrustrowani. Prezes firmy AI zdemaskował bałagan w korporacjach

    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