Tag: AWS

  • Codex CLI 0.124.0: Wsparcie dla Amazon Bedrock i kontrola rozumowania w terminalu

    Codex CLI 0.124.0: Wsparcie dla Amazon Bedrock i kontrola rozumowania w terminalu

    Wydanie Codex CLI 0.124.0 od OpenAI wprowadza kilka znaczących nowości, które koncentrują się na integracji z chmurą AWS, ulepszeniach interfejsu terminalowego oraz zwiększeniu bezpieczeństwa i automatyzacji. Ta najnowsza wersja narzędzia dla deweloperów wprowadza konkretne funkcje, które mogą wpłynąć na codzienną pracę z agentami sztucznej inteligencji.

    Wersja 0.124.0 jest skierowana głównie do profesjonalnych użytkowników i zespołów DevOps, oferując nowe możliwości oraz istotne usprawnienia w zakresie stabilności i zarządzania uprawnieniami. To kolejny krok w rozwoju Codex, który przekształca się z narzędzia badawczego w platformę produkcyjną.

    Kluczowe zmiany w wersji 0.124.0

    • Wiele środowisk w sesji app-server: Remote workflows zyskały wsparcie dla configured remote environments, co ułatwia pracę z monorepo i różnymi kontekstami aplikacji bez konieczności restartowania agenta.
    • Integracja z Amazon Bedrock: Codex uzyskał wsparcie dla Bedrock jako dostawcy zgodnego z OpenAI API, z uwzględnieniem AWS SigV4 signing oraz autoryzacji opartej na AWS credentials.
    • Zdalne przeglądanie marketplace pluginów: Użytkownicy mogą teraz przeglądać źródła pluginów zdalnie i między repozytoriami, korzystając z opcji takich jak podgląd w kartach, przełączniki włączania/wyłączania oraz usuwanie pluginów.

    Integracja z Amazon Bedrock

    To jedna z najważniejszych zmian w tej wersji dla zespołów działających w ekosystemie AWS. Dzięki wsparciu dla Amazon Bedrock, Codex może teraz korzystać z modeli dostępnych na tej platformie, wykorzystując natywne mechanizmy autoryzacji AWS, zamiast standardowego klucza API OpenAI. Oznacza to, że zespoły korzystające z infrastruktury AWS mogą łatwiej włączyć Codex do swoich procesów, wykorzystując istniejące polityki IAM i role.

    Aby skonfigurować integrację, należy dodać odpowiednie wpisy do pliku ~/.codex/config.toml. Testy techniczne wykazały, że po skonfigurowaniu zmiennych środowiskowych z danymi AWS za pomocą polecenia aws configure export-credentials, Codex wykonuje zapytania do modeli przez Bedrock bez problemów.

    Warto zauważyć, że Bedrock udostępnia zgodne z OpenAI Responses API (/v1/responses), które wykorzystuje Codex.

    Interaktywna kontrola rozumowania i wiele środowisk

    Funkcja wielośrodowiskowych sesji app-server odpowiada na potrzeby złożonych projektów. Deweloper pracujący nad frontendem w jednym katalogu i backendem w innym, czy też konfiguracjami dla różnych środowisk (dev, staging), może teraz zarządzać tym wszystkim w ramach jednej sesji Codex, przełączając kontekst pracy. To oszczędza czas i redukuje bałagan.

    Większa niezawodność i bezpieczeństwo

    Aktualizacja 0.124.0 kontynuuje trend wzmacniania bezpieczeństwa i stabilności, który był widoczny w wcześniejszych wersjach 0.122–0.124. Wprowadzono zaostrzone polityki uprawnień, silniejsze sandboxing oraz mechanizmy takie jak deny-read glob policies. Izolowane przebiegi Codex ignorują konfigurację użytkownika i reguły, co zwiększa przewidywalność w kontrolowanych środowiskach, na przykład na serwerach CI/CD.

    Poprawki obejmują także stabilniejsze zarządzanie stanem sesji oraz narzędzia wydawnicze. Dla profesjonalnych użytkowników i zespołów DevOps te zmiany są często ważniejsze niż nowe funkcje, ponieważ przekładają się na mniej awarii i większe zaufanie do automatyzacji opartej na Codex.

    Podsumowanie

    Wydanie Codex CLI 0.124.0 pokazuje kierunek rozwoju tego narzędzia: głęboka integracja z ekosystemami chmurowymi (AWS) oraz udoskonalenie doświadczenia dewelopera w codziennej pracy.

    Źródła

  • Claude Opus 4.7 wchodzi na rynek, a Bedrock rozszerza dostępność

    Claude Opus 4.7 wchodzi na rynek, a Bedrock rozszerza dostępność

    Anthropic wprowadziło nową generację modelu Claude – Opus 4.7, który jest określany jako najbardziej zaawansowany w zakresie rozumowania i zdolności agentowych. Premiera miała miejsce 16 kwietnia 2026 roku. W tym samym czasie firma ogłosiła rozszerzenie dostępności swoich modeli w środowisku Amazon Bedrock, gdzie Claude Opus 4.7 oraz Claude Haiku 4.7 są już dostępne dla klientów w wielu regionach AWS. To wydarzenie ma duże znaczenie dla deweloperów i zespołów DevOps, które tworzą zaawansowane aplikacje AI.

    Nowa generacja Opusa utrzymuje dotychczasową strukturę cenową (5 USD / 25 USD za MTok), ale wprowadza zmiany w API, które wymagają uwagi podczas migracji. Model został zaprojektowany z myślą o zadaniach związanych z inżynierią oprogramowania, wieloetapowych workflowach oraz pracy z wiedzą, oferując lepsze możliwości w zakresie kodowania, obsługi multimediów oraz długotrwałych procesów agentowych z wykorzystaniem narzędzi i pamięci.

    Kluczowe informacje o premierze

    • Claude Opus 4.7 jest najbardziej zaawansowanym modelem Anthropic do złożonych zadań programistycznych i analitycznych, dostępnym od 16 kwietnia 2026.
    • Model wprowadza obsługę obrazów wysokiej rozdzielczości – do 2576 px na długim boku i 3.75 megapikseli, co jest istotne dla workflowów analizy UI, screenshotów i dokumentów.
    • Claude Haiku 4.7 jest teraz dostępny jako nowsza, wydajniejsza wersja modelu Haiku.
    • Amazon Bedrock otworzył samoobsługowy dostęp do Claude Opus 4.7 i Haiku 4.7 dla wszystkich klientów w wielu regionach AWS.

    Zmiany w rozumowaniu i kodowaniu

    Claude Opus 4.7 wprowadza model z adaptacyjnym myśleniem, który reguluje ilość „rozumowania” używanego przez model w zależności od złożoności zadania. Oznacza to, że dla prostych problemów model działa szybciej i efektywniej, a dla bardziej skomplikowanych poświęca więcej „cykli myślowych”, aby uzyskać lepsze wyniki.

    Dla deweloperów, benchmarki firmy pokazują, że na zestawie 93 zadań kodowych Opus 4.7 poprawił skuteczność rozwiązywania o 13% w porównaniu do Opusa 4.7, rozwiązując cztery zadania, które były niemożliwe dla wcześniejszych generacji Opusa i Sonneta. Vercel, jeden z partnerów, zauważył, że nowy model jest „fenomenalny w jednorazowych zadaniach kodowych”, bardziej precyzyjny i kompletny niż 4.7, oraz „zauważalnie bardziej szczery o swoich własnych ograniczeniach”.

    Wysoka rozdzielczość i precyzyjne koordynaty

    Jedną z istotnych zmian dla deweloperów pracujących z automacją wizualną jest zwiększenie limitu rozdzielczości obrazów. Opus 4.7 obsługuje obrazy do 2576 px / 3.75 MP. Koordynaty obrazów są teraz mapowane 1:1 z rzeczywistymi pikselami.

    Ta zmiana otwiera nowe możliwości dla:

    • agentów „computer-use” wymagających precyzyjnej lokalizacji elementów na ekranie,
      workflowów screenshot-to-code,
    • automatycznej analizy i weryfikacji UI (visual regression testing),
      ekstrakcji danych z formularzy i dokumentów opartych na obrazach,
    • interpretacji mockupów z Figma czy innych narzędzi designowych.

    Dla zespołów zajmujących się hostingiem i infrastrukturą AI, ważna jest również ekspansja na Amazon Bedrock.

    Globalna dostępność przez AWS Bedrock

    Dostępność Claude Opus 4.7 oraz Haiku 4.7 na Amazon Bedrock oznacza, że modele działają na next-generation inference engine Bedrocka, z nową logiką schedulingu i skalowania, zaprojektowaną dla poprawy dostępności, szczególnie dla steady-state workloads. To istotne dla zespołów DevOps planujących długoterminowe, produkcyjne wdrożenia modeli AI.

    Bedrock zapewnia także zero operator access – co oznacza, że prompty i odpowiedzi klientów nie są widoczne dla operatorów Anthropic ani AWS, co jest kluczowe dla firm z wysokimi wymaganiami bezpieczeństwa i prywatności danych. Otwarty dostęp w wielu regionach daje większą elastyczność geograficzną i redukuje potencjalne problemy z opóźnieniami.

    Migracja i praktyczne następstwa

    Premiera Opus 4.7 i dostępność Haiku 4.7 wymagają działań od deweloperów korzystających z API Anthropic. Firma publikuje oficjalny migration guide, ponieważ Opus 4.7 zawiera breaking changes w API względem 4.7. Ważne jest, aby sprawdzić dokumentację przed aktualizacją.

    Dla tych, którzy budują zaawansowane agentowe narzędzia do kodowania, nowe możliwości memory improvements mogą być przełomowe. Model jest lepszy w pisaniu i użyciu pamięci opartej na systemie plików, co pomaga agentom utrzymywać scratchpad, notes czy structured memory store między kolejnymi turami. Anthropic promuje także swój client-side memory tool jako opcję zarządzanego scratchpada.

    Podsumowanie

    Premiera Claude Opus 4.7 oraz ekspansja na Amazon Bedrock to istotne wiadomości dla ekosystemu AI, szczególnie w kontekście zaawansowanego kodowania i produkcyjnej infrastruktury. Opus 4.7 oferuje znaczące poprawy w rozumowaniu, obsłudze multimediów i pamięci, co czyni go silnym narzędziem dla złożonych agentowych workflowów.

    Źródła

  • Claude Code 2.1.92 Wzmacnia Bezpieczeństwo i Przejrzystość Kosztów

    Claude Code 2.1.92 Wzmacnia Bezpieczeństwo i Przejrzystość Kosztów

    Aktualizacja Claude Code do wersji 2.1.92 wprowadza zmiany przydatne dla programistów indywidualnych oraz zespołów w dużych firmach. Deweloperzy skupili się na trzech obszarach: bezpieczeństwie, integracji z chmurą AWS oraz monitorowaniu wydatków na API. Wersja ta dodaje 10 nowych flag i 21 zmian w interfejsie wiersza poleceń (CLI).

    Nowe zasady bezpieczeństwa dla firm

    Najważniejszą zmianą techniczną jest wprowadzenie opcji forceRemoteSettingsRefresh. Działa ona w trybie fail-closed, co jest istotne w korporacjach dbających o spójność konfiguracji. Jeśli ta funkcja jest aktywna, Claude Code 2.1.92 nie uruchomi się, jeżeli nie uda mu się pobrać aktualnych ustawień z serwera.

    W praktyce oznacza to, że aplikacja kończy pracę, zamiast korzystać ze starych danych zapisanych w pamięci lokalnej. Zapobiega to pracy na nieaktualnych uprawnieniach lub błędnych parametrach bezpieczeństwa. Jest to rozwiązanie przygotowane pod wymogi działów compliance w dużych organizacjach.

    Konfiguracja AWS Bedrock w formie kreatora

    Zespoły korzystające z infrastruktury Amazon Web Services mogą teraz użyć interaktywnego kreatora dla usługi Bedrock. Narzędzie to upraszcza proces łączenia Claude Code z chmurą.

    Kreator prowadzi użytkownika przez logowanie do AWS, wybór konkretnego regionu oraz wskazanie modeli, z których chce korzystać. Wcześniej deweloperzy musieli samodzielnie ustawiać zmienne środowiskowe i edytować pliki tekstowe. Teraz proces ten odbywa się automatycznie wewnątrz terminala.

    Kontrola kosztów i optymalizacja prędkości

    Użytkownicy planu Pro mogą teraz dokładniej sprawdzać wydatki za pomocą komendy /cost. Pokazuje ona zużycie środków z rozbiciem na poszczególne modele i uwzględnia oszczędności wynikające z użycia pamięci podręcznej (cache hits). Pozwala to precyzyjnie określić, które zadania generują największe opłaty.

    Dodano również powiadomienia o tokenach. Jeśli sesja zostanie wznowiona po wygaśnięciu pamięci podręcznej promptów, system wyświetli informację o liczbie tokenów, które zostaną ponownie przetworzone. Ułatwia to zarządzanie budżetem projektu.

    Pod kątem wydajności poprawiono narzędzie write tool. Obliczanie różnic w kodzie (diff) jest o 60% szybsze w plikach, które zawierają tabulatory lub znaki specjalne, takie jak & i $. Program zużywa też mniej pamięci RAM, ponieważ pliki gramatyki potrzebne do podświetlania składni są ładowane tylko wtedy, gdy są faktycznie potrzebne.

    Zmiany w interfejsie i stabilność pracy

    Wersja 2.1.92 zawiera kilka poprawek w obsłudze programu. Polecenie /release-notes ma teraz listę wyboru, która pozwala przeglądać opisy poprzednich wersji bezpośrednio w konsoli. Naprawiono też błędy techniczne, w tym problemy z działaniem subagentów wewnątrz sesji tmux, błędy przy przewijaniu tekstu oraz usterki związane z funkcją Stop.

    Limit danych dla narzędzi MCP (Model Context Protocol) został zwiększony do 500 000 znaków. Dzięki temu w kontekście rozmowy można umieścić bardzo duże pliki, takie jak pełna dokumentacja API czy rozbudowane schematy baz danych, bez ryzyka ich ucięcia.

    Podsumowanie

    Claude Code 2.1.92 to aktualizacja nastawiona na praktyczne aspekty pracy programisty. Lepsza kontrola nad kosztami, łatwiejsza konfiguracja AWS oraz mechanizmy wymuszające aktualność ustawień sprawiają, że narzędzie staje się bardziej przewidywalne w profesjonalnych zastosowaniach. Poprawki szybkości działania diffów i stabilności interfejsu odczują wszyscy użytkownicy pracujący z kodem w terminalu.

    Źródła

  • Kiro, „vibe-coding” i awaria, której nie było? Amazon odpiera atak na swoje AI

    Kiro, „vibe-coding” i awaria, której nie było? Amazon odpiera atak na swoje AI

    W świecie chmur obliczeniowych, gdzie każda minuta przestoju może kosztować fortunę, plotka o tym, że wewnętrzne AI Amazona samo wyłączyło fragment AWS, rozniosła się błyskawicznie. Media podchwyciły soczysty nagłówek o narzędziach AI, które "zavibowały za mocno". Amazon jednak stanął na rzęsach, by tę narrację zdemontować. Co naprawdę wydarzyło się w październiku 2025 roku? I czy to opowieść o zbuntowanej sztucznej inteligencji, czy raczej stary jak świat błąd ludzki w nowym technologicznym opakowaniu?

    Co się właściwie stało? Poważna awaria kluczowego regionu

    Według oficjalnych raportów i analiz, incydent z października 2025 roku był poważną awarią. 20 października 2025 roku, na przestrzeni 13-15 godzin, problemy dotknęły szerokiego spektrum usług AWS w kluczowym regionie US-EAST-1 (Północna Wirginia). Dotknięte zostały rdzeniowe usługi, w tym DynamoDB, AWS Lambda, Amazon EC2, Amazon S3, AWS Config i Amazon Redshift.

    Co kluczowe, awaria w regionie US-EAST-1 spowodowała globalne zakłócenia w działaniu setek usług i serwisów zewnętrznych, takich jak Netflix, Slack, mBank czy Perplexity. Skala była znacząca – firmy odnotowały masowe zgłoszenia od klientów i użytkowników na całym świecie. W wewnętrznej klasyfikacji AWS był to poważny incydent, analizowany przez proces Correction of Error (COE).

    Wersja medialna vs. rzeczywiste przyczyny awarii

    Niektóre media, snując spekulacje, przedstawiały dramatyczną opowieść o eksperymentalnym narzędziu AI. Sugerowano, że do awarii doprowadził wewnętrzny asystent kodowania typu „vibe-coding”, który miał zamieniać naturalne polecenia w specyfikacje, a potem w działający kod. Twierdzono, że takie narzędzie podjęło autonomiczną decyzję o "usunięciu i odtworzeniu środowiska", co poskutkowało przerwą.

    Odpowiedź Amazona i analiza przyczyn były jednak inne i oparte na faktach. Spółka oraz zewnętrzni obserwatorzy wskazali na problemy techniczne. Główną przyczyną awarii były problemy z rozwiązywaniem nazw DNS (Domain Name System) w usłudze DynamoDB, które następnie rozprzestrzeniły się na inne usługi. Inne analizy wskazywały na single point of failure lub problemy z aktualizacjami API. Amazon i analitycy podkreślali techniczny charakter usterki, nie potwierdzając żadnego związku z autonomicznym działaniem sztucznej inteligencji.

    Gdzie w tym wszystkim jest AI? Rola narzędzi w zarządzaniu chmurą

    Choć sztuczna inteligencja znajduje się w centrum szerszej dyskusji o automatyzacji, w kontekście tej awarii jej rola była marginalna lub niepotwierdzona. Firma wyjaśnia, że jej wewnętrzne narzędzia przed podjęciem jakiejkolwiek istotnej akcji wymagają autoryzacji i nadzoru człowieka. Problem nie leżał w autonomicznej decyzji AI, ale w złożoności systemów i potencjalnych błędach konfiguracji. To klasyczne wyzwania inżynieryjne, które mogą się zdarzyć przy zarządzaniu dowolną złożoną infrastrukturą – niezależnie od użytych narzędzi.

    Amazon przyznaje, że nowe technologie, w tym asystenci programistyczne, mają swoje problemy. W przeszłości wprowadzano różne limity i poprawki. Pojawiały się też błędy konfiguracyjne mające wpływ na użytkowników. Te wpadki jednak nie są bezpośrednio powiązane z październikową awarią w US-EAST-1.

    Nauka na przyszłość: Nowe zabezpieczenia po incydencie

    Mimo że szczegóły wniosków z tego konkretnego incydentu nie są w pełni publiczne, Amazon i cała branża wyciągają lekcje z każdej poważnej awarii. Standardową praktyką jest wdrażanie dodatkowych zabezpieczeń, których celem jest zapobieganie podobnym sytuacjom w przyszłości. Często obejmuje to wzmocnienie procesów przeglądu (peer review) oraz architektury odporniejszej na pojedyncze punkty awarii.

    Warto zaznaczyć, że te działania są podyktowane rutynowym, proaktywnym podejściem liderów chmury do doskonalenia swoich procesów i niezawodności. Firma traktuje to jako część ciągłej nauki i poprawy swoich usług.

    Szerszy kontekst: "Vibe-coding" i prawdziwe ryzyko AI

    Cała dyskusja, nawet jeśli rozdmuchana, trafia na podatny grunt. Koncepcja „vibe-coding” – czyli pisania kodu za pomocą swobodnych, naturalnych poleceń – zdobywa ogromną popularność. Nie jest jednak pozbawiona ryzyka. Jak pokazują inne przypadki, AI potrafi "zhallucinować" i wygenerować kod, który usuwa partycje dysku czy bazy danych. Agenci AI potrafią też wpadać w pętle, bez końca wywołując te same API.

    Co ciekawe, z narzędzi do automatycznego kodowania korzystają także cyberprzestępcy. Specjaliści z Palo Alto Networks potwierdzają, że przestępcy również „vibe-codują” malware. Czasem w sam kod wbudowują zapytania do modeli językowych, prosząc o pomoc w generowaniu ataków czy wiarygodnych maili phishingowych. Na szczęście dla obrońców, AI bywa w tym mniej skuteczna – generuje kod, który wygląda groźnie, ale jest nieskuteczny, co specjaliści nazywają "security theater".

    Wnioski: Wojna narracji w erze AI

    Sprawa awarii AWS z października 2025 to więcej niż relacja o incydencie technicznym. To studium wojny narracji w początkowej erze agentic AI. Z jednej strony media i opinia publiczna chętnie snują opowieści o zbuntowanych sztucznych inteligencjach, które wymykają się spod kontroli. To chwytliwa i niepokojąca wizja. Z drugiej strony gigant technologiczny, broniąc swojej reputacji niezawodności, skupia się na technicznych aspektach i prozaicznych przyczynach.

    Prawda w tym przypadku jest techniczna. Incydent był poważną awarią spowodowaną problemami infrastrukturalnymi, która dobitnie przypomina, że nawet najbardziej zaawansowane systemy nie są odporne na klasyczne błędy i pojedyncze punkty awarii. Złożoność, nadmierne uprawnienia i brak odpowiednich redundancji wciąż są kluczowymi czynnikami ryzyka, niezależnie od tego, jak zaawansowane są nasze narzędzia. Najważniejsza lekcja z tej historii jest uniwersalna: technologia to tylko narzędzie. To od ludzi zależy, jak ją zaprojektują, jakich zabezpieczeń użyją i czy zachowają czujność. Branża, wdrażając lepsze praktyki inżynieryjne, zdaje się tę lekcję odrabiać.