Kategoria: Chmura obliczeniowa

  • 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 Wraca na Tropy: Wersja 2.1.96 Naprawia Krytyczny błąd Uwierzytelniania w AWS Bedrock

    Claude Code Wraca na Tropy: Wersja 2.1.96 Naprawia Krytyczny błąd Uwierzytelniania w AWS Bedrock

    Zespół Claude Code wydał aktualizację oprogramowania. Wersja 2.1.96 usuwa błąd uwierzytelniania w AWS Bedrock, który pojawił się w wydaniu 2.1.94. Ta usterka uniemożliwiała wielu osobom połączenie z usługą, co zmusiło programistów do przygotowania poprawki w krótkim czasie.

    Problem objawiał się komunikatami HTTP 403 o treści "Authorization header is missing". Błąd występował u użytkowników konfigurujących dostęp przez zmienne środowiskowe, takie jak AWS_BEARER_TOKEN_BEDROCK lub CLAUDE_CODE_SKIP_BEDROCK_AUTH. W efekcie potoki CI/CD, skrypty automatyzacji oraz osoby korzystające z tych metod autoryzacji straciły dostęp do modeli AI w Bedrock, mimo że wcześniej usługa działała bez zakłóceń.

    Przyczyny problemów w wersji 2.1.94

    Błąd dotyczył konkretnego sposobu logowania. Wersja 2.1.94 wprowadziła zmiany, które powodowały błędne przetwarzanie nagłówków autoryzacji przy aktywnych wspomnianych zmiennych środowiskowych.

    Usterka nie dotyczyła wszystkich metod łączenia się z AWS Bedrock. Osoby korzystające ze standardowych profili AWS CLI lub ról IAM zazwyczaj nie miały problemów. Błąd uderzył w rzadsze scenariusze, takie jak użycie statycznego tokena w zmiennej AWS_BEARER_TOKEN_BEDROCK lub pomijanie autoryzacji przez CLAUDE_CODE_SKIP_BEDROCK_AUTH. Takie ustawienia są często stosowane w zautomatyzowanych środowiskach, na przykład w GitHub Actions, gdzie zarządzanie dynamicznymi poświadczeniami jest trudniejsze.

    Wersja 2.1.96 przywraca właściwą logikę obsługi tych zmiennych. Aby zainstalować poprawkę, należy użyć polecenia npm update @anthropic-ai/claude-code. Warto jednak dodać, że w zgłoszeniach na GitHubie pojawiają się informacje, że niektórzy użytkownicy GitHub Actions nadal widzą błędy 403 po aktualizacji, co może oznaczać, że problem nie został całkowicie rozwiązany w każdym środowisku.

    Znaczenie dla inżynierów AI

    AWS Bedrock jest podstawą dla zespołów budujących przepływy pracy oparte na sztucznej inteligencji w chmurze. Platforma ta pozwala korzystać z modeli Claude bez konieczności zarządzania własnymi serwerami, co ułatwia integrację z usługami AWS.

    W środowiskach DevOps i potokach CI/CD zmienne typu AWS_BEARER_TOKEN_BEDROCK są używane do bezpiecznego przekazywania uprawnień bez zapisywania ich w plikach konfiguracyjnych. Błąd w wersji 2.1.94 mógł więc zatrzymać automatyczne wdrażanie, testy czy procesy generowania kodu.

    Ostatnie wydania przyniosły też inne poprawki dla Bedrock. Rozwiązano problemy z autoryzacją SigV4, które występowały przy ustawianiu nagłówka Authorization przez ANTHROPIC_AUTH_TOKEN lub ANTHROPIC_CUSTOM_HEADERS. Zespół Claude Code regularnie poprawia współpracę z dostawcami chmurowymi, co jest niezbędne w zastosowaniach profesjonalnych.

    Konfiguracja połączenia z Bedrock

    Po przejściu na wersję 2.1.96 ustawienia powinny działać poprawnie. Przykładowa konfiguracja dla środowiska korzystającego z Claude Code i AWS Bedrock wygląda tak:

    export CLAUDE_CODE_USE_BEDROCK=1
export AWS_REGION=us-east-1
export AWS_PROFILE=your-profile
# Jedna z poniższych metod autoryzacji:
export AWS_BEARER_TOKEN_BEDROCK=your-token
# Lub:
export CLAUDE_CODE_SKIP_BEDROCK_AUTH=1

    W przypadku korzystania z własnych bramek lub serwerów proxy można dodatkowo użyć zmiennej ANTHROPIC_BEDROCK_BASE_URL. Taka elastyczność pozwala dopasować narzędzie do zasad bezpieczeństwa wewnątrz firmy.

    Reakcja na błędy

    Wydanie wersji 2.1.96 zaraz po wykryciu błędu pokazuje, że proces rozwoju Claude Code jest sprawny. W branży narzędzi AI, gdzie aktualizacje pojawiają się bardzo często, szybkie usuwanie usterek technicznych jest kluczowe dla zachowania ciągłości pracy użytkowników.

    Dla osób korzystających z Claude Code ta poprawka oznacza możliwość powrotu do pracy z modelami hostowanymi w chmurze. Sytuacja ta przypomina również o tym, jak ważne jest dokładne testowanie systemów uwierzytelniania przy wprowadzaniu zmian w kodzie.

    Ź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ć.