Минуло близько п’яти місяців від нашого останнього погляду на Control Resonant — очікуване продовження Control 2019 року від Remedy Entertainment — і тепер відома дата релізу: 24 вересня 2026 року. Її оголосили під час сьогоднішньої презентації PlayStation State of Play. Гра також вийде на Xbox Series X/S та PC.

Дату розкрили разом із коротким трейлером, що більше зосереджується на сюжеті. Центральним персонажем стане Ділан Фейден, брат головної героїні оригіналу Джессі. Гніт (The Hiss), зловісна сила, що вирвалася на волю у стінах Федерального бюро контролю, тепер лютує в Нью-Йорку, і саме Ділан має її зупинити — завдання, яке, схоже, створює напругу всередині самого Бюро. У трейлері також показують Джессі, яка використовує свої здібності разом із Діланом — добра новина для фанатів, що сподівалися побачити її знову, попри те що цього разу акцент зроблено на її братові.

PlayStation Blog трохи детальніше розкриває історію, зокрема стосунки між Джессі та Діланом. «Подорож Ділана формується діями Джессі, тоді як людство стикається з новою екзистенційною загрозою. Вона залишається центральною фігурою і присутня в грі, але саме він рухає історію вперед», — йдеться в описі.

«У Resonant ми глибше занурюємося в складне минуле родини Фейденів. Їхнє життя було далеким від легкого, і час заплатити за тягар, який вони несуть. Те, що чекає попереду, випробує їх більше, ніж будь-коли раніше».

Попередні замовлення Control Resonant відкриті вже сьогодні. Ті, хто оформить цифрове делюкс-видання, зможуть отримати доступ до гри на 48 годин раніше.

Джерело

Engadget

God of War Ragnarok ефектно завершила скандинавську сагу серії, але історія ще не закінчена. PlayStation Studios анонсувала гру God of War Laufey, де головною героїнею стане дружина Кратоса Фея (її повне ім’я — Лауфея), і показала довгий геймплейний уривок. Продемонстровано близько 20 хвилин ігрового процесу, які, схоже, відбуваються на самому початку гри.

Футаж починається майже так само, як God of War 2018 року: Кратос кладе тіло Феї на похоронне вогнище й прощається з нею разом із сином Атреєм. Потім Фея прокидається в зовсім іншому місці й, схоже, усвідомлює події, що сталися. Вона зазначає, що бачила це вогнище й зрозуміла, що Кратос і Атрей вирушили у свою подорож (події згаданої гри). Після цього вона починає мандрівку абсолютно незнайомим виміром, якого ми раніше не бачили. На гравця чекають сутички з класичним для God of War екшеном, хоча Фея б’ється зовсім не так, як Кратос чи Атрей.

Зрештою довга кат-сцена показує, як Фею захоплюють у полон нові вороги, що зовсім не схожі на більшість антагоністів із «скандинавського» циклу. З’являється новий персонаж — «космічний куб», якого Пранк називає потойбіччям богів. (У блозі PlayStation уточнюється, що це Everywhen — місце, де боги з різних міфологій змагаються за владу.) Деякі з прислужників, що утримують Фею, нагадують нежить із попередніх ігор, але загалом сетинг виглядає майже повністю новим.

Прев’ю закінчується тим, що Фея намагається використати магію, аби вирватися з полону — і це їй вдається, але вона опиняється в самому епіцентрі масштабної битви. Тут вона здобуває вражаючу зброю, яка на перший погляд виглядає не менш ефектно, ніж Blades of Chaos чи сокира Leviathan. Це розкішний меч, який вона може кидати й повертати до себе, відкриваючи масу цікавих і продуманих бойових прийомів, подібних до тих, що давали попередні культові види зброї. До клинка прикріплені розумні стрічки на ім’я Rue, створені для того, щоб меч не дістався ворогам.

Природно, після цього відбувається жорстка дуель один на один, яка демонструє повний спектр здібностей Феї та жорстокість мешканців нового світу, у якому вона опинилася.

Чутки про гру з Феєю в головній ролі ходили вже давно, але було незрозуміло, де саме вона впишеться в хронологію God of War. Тепер видно, що її нова подорож розгортається паралельно подіям, через які проходять Кратос і Атрей, — це додає історії серйозного інтригуючого повороту.

На жаль, жодного натяку на вікно релізу показ не дав, тож розраховувати варто не раніше ніж на 2027 рік. Залишається тільки схрестити сокири й мечі в очікуванні. Поки що ж доступні кілька додаткових відео, окрім основного геймплейного трейлера, які розповідають про нових персонажів і процес розробки гри.

Джерело

Engadget

Компанія з безпеки зберігання даних Cyera фіналізує раунд фінансування під керівництвом Evolution Equity Partners щонайменше на $300 млн за оцінки в $12 млрд, повідомили чотири обізнані з угодою джерела.

Першим про раунд написало видання Calcalist, однак джерела TechCrunch додали нові деталі про компанію та її фінансові показники.

За словами трьох співрозмовників TechCrunch, річний повторюваний дохід (ARR) Cyera перевищив $150 млн, хоча компанія досі далека від прибутковості. Угода оцінює Cyera у 80 річних ARR — мультиплікатор, який навіть вищий за той, що інвестори нині присвоюють багатьом швидкозростаючим AI‑стартапам.

Джерела повідомили TechCrunch, що компанія витрачає гроші швидше, ніж заробляє. Частина цих коштів спрямовується на найм продажників. За даними PitchBook, Cyera додала 500 робочих місць лише з початку цього року.

Представник Cyera заявив, що «наведені цифри є фактично й суттєво неточними». Evolution Equity Partners не відповіла на запит про коментар.

Новий раунд очікується всього через пʼять місяців після того, як Cyera оголосила про залучення $400 млн у рамках раунду серії F за оцінки $9 млрд. Тоді раунд очолила Blackstone, а також взяли участь наявні інвестори, зокрема Accel, Coatue, Lightspeed, Redpoint, Sapphire, Sequoia, Cyberstarts та інші. Майбутній раунд збільшить загальний обсяг залученого Cyera капіталу щонайменше до $2 млрд.

Cyera, заснована у 2021 році, виграла від зростання попиту з боку корпоративних клієнтів, які звертаються до її платформи для захисту даних від атак із використанням ШІ. Оголошуючи раунд серії F, компанія стверджувала, що її клієнтами є п’ята частина зі списку Fortune 500, а виручка за 2025 рік більш ніж утричі зросла.

Останніми місяцями компанія використовувала залучений капітал для покриття операційних збитків, а також для придбання інших кібербезпекових стартапів, зокрема Ryft, у який інвестував Index Ventures, і менше ніж рік тому створеного Genie Security.

Джерело

TechCrunch

Onimusha: Way of the Sword отримала дату релізу — 25 вересня 2026 року. Capcom показала новий трейлер фехтувального екшену під час сьогоднішньої онлайн-презентації Sony State of Play. У ролику роблять акцент на видовищному бою з босом, що відбувається на вершині гори Ое. Також там є натяки на сюжетний контекст того, як головний герой Міямото Мусаші отримав сили оні, які дозволяють йому використовувати надприродні здібності в бою.

Фанати й так давно чекають на продовження серії, тож Capcom випустила 30-хвилинне демо для PlayStation 5, яке доступне вже сьогодні, аби скоротити очікування до осені. У демоверсії вам доведеться битися з численними генма, а також спробувати свої сили в сутичці з суперником Мусаші — мечником Ґанрю.

Наш попередній тест ранньої демоверсії показав, що ця гра може бути менш каральною, ніж попередні частини, але при цьому пропонує достатньо демонів для ефектних поєдинків. Тепер ви можете оцінити це самостійно.

Джерело

Engadget

Сиквел Until Dawn зараз у розробці в ліверпульській студії Firesprite і має вийти на PlayStation 5 у 2027 році. Until Dawn 2 зберігає всі ключові риси оригінального «обери-сам» трилера про маніяка, але цього разу дія відбувається не на засніженій горі, а на тропічному острові.

У Until Dawn 2 знімається компанія молодих мисливців на привидів – усі друзі, окрім випадкового накачаного хлопця, якого ніхто толком не знає. Вони ведуть молодий канал про паранормальні явища й щойно підписали угоду з телемережею, тож команду відправляють на віддалений острів збирати (або створювати) матеріал. Спочатку – безтурботні розваги серед водоспадів і зелені, а потім зненацька з’являється вбивця в масці з мачете, який розтинає комусь торс. У сиквелі повертаються фірмові для серії QTE-сцени з летальними наслідками й великою кількістю жорстокості, якщо зробити невдалий вибір.

Ось як Firesprite описує свій підхід до ігрової механіки продовження:

«Чи ризикнете ви отримати травму, щоб врятувати миле порося від жахливої капкана? Чи продовжите скандальний роман, навіть якщо він може розірвати команду? Чи будете тиснути на когось до межі, заради контенту, який, за словами вашого грізного босса, обов’язково треба зняти? Цього разу те, як ви керуєте стосунками всередині команди, важить як ніколи раніше, адже деякі розгалуження сюжету залежать від того, в яких стосунках перебувають персонажі. Ідеться не лише про великі моменти – навіть дрібні епізоди можуть запустити ефект метелика та відправити вашу історію в бік неочікуваних наслідків».

Until Dawn 2 є самостійною історією й чітко тримається підліткової слешер-естетики, що виглядає дуже доречним вибором. У трейлері, наприклад, сцена, де пару в лісі переривають просто під час поцілунку, могла б бути вирізана безпосередньо з «Хатинки в лісі» – класики жанру. Оригінальна Until Dawn вийшла у 2015 році з подібним б-хорор вайбом, тож усе виглядає цілком у дусі серії.

Until Dawn створювала студія Supermassive Games, видавцем виступила Sony. Гра стала культовим хітом і отримала кілька відгалужень, зокрема VR-проєкти Rush of Blood та The Inpatient. Духовний наступник Until Dawn від Supermassive – The Quarry – вийшов у 2022 році у видавництві 2K: попри вдалі моменти, він поступався оригіналу за загальним темпом і напругою. Між 2019 і 2022 роками студія також випустила The Dark Pictures Anthology. На початку 2024-го співзасновники Supermassive залишили студію, а більшу частину співробітників було звільнено.

Firesprite, які відповідають за Until Dawn 2, складена з колишніх учасників Studio Liverpool, відомої завдяки серії Wipeout. Sony повністю викупила Firesprite у 2021 році. Ліцензія на Until Dawn із самого початку належала Sony, тому наступні ігри Supermassive називали «духовними наступниками». Також Sony запустила у виробництво фільм за мотивами оригінальної гри та її ремейк, заплановані на 2025 рік.

Джерело

Engadget

Протягом останніх 10 років щорічний індекс загублених речей Uber (Lost & Found Index) дає своєрідний кумедний антропологічний зріз пасажирів сервісу — а іноді й певне уявлення про суспільство загалом. Щороку в переліку мільйонів забутих предметів опиняються як буденні «інструменти» на кшталт смартфонів і ноутбуків, так і значно екзотичніші речі: живі риби, електронний браслет на нозі, тобоган, посилка з живими метеликами та одна-єдина туфля Louboutin.

Цього року Uber вирішив використати звіт, щоб підсвітити ту саму стару проблему загублених речей, але з новим акцентом — роботаксі. За даними компанії, за останній рік у безпілотних авто, підключених до мережі сервісу, пасажири залишили вже тисячі предметів (до мільйонів ще далеко, це поки що новий напрямок). Серед них — традиційні телефони, ключі, гаманці, паспорти, навушники, а також речі з категорії «хто ж був тим пасажиром»: вставна щелепа, сумка з написом «I Heart Hot Dads» і синя кепка з текстом «Emotional Support Human».

За цим кумедним списком ховається і бізнес-можливість, хоч і відносно невелика. Навіть у майбутньому з роботаксі хтось усе одно має повертати пасажирам загублені речі.

Останніми роками Uber уклав десятки партнерств із компаніями, що розробляють технології автономного керування (AV). Але реальний комерційний рух у цьому бізнесі почався лише у березні 2025 року, коли в Остіні запустили сервіс «Waymo on Uber». Відтоді Uber і Waymo також відкрили роботаксі-сервіс в Атланті. За останній рік Uber додав до застосунку й інших AV-партнерів: Motional у Лас-Вегасі та Avride у Далласі, хоча в цих автомобілях досі присутні водії-безпекові інженери за кермом.

Той факт, що Uber уже зафіксував тисячі загублених речей лише за 12 місяців, дає певне уявлення про те, скільки поїздок роботаксі виконано через додаток. Неявне повідомлення таке: поточна інфраструктура Uber вже готова до того, щоб повертати пасажирам їхні речі — від 7-кілограмового йо-йо та великої чорної мармурової качки до іграшки Squishmallow та постера Charli XCX.

Якщо пасажир Uber забув щось у роботаксі, процедура повернення схожа на звичайну поїздку з водієм: потрібно відкрити застосунок, натиснути вкладку «Активність», вибрати поїздку, під час якої загублено річ, і звернутися до служби підтримки. Далі користувач може написати, почати чат або зателефонувати оператору. Якщо предмет знаходять, є два варіанти: заплатити $15 за доставку того ж дня через кур’єра Uber Courier або забрати річ особисто з депо автономних авто, де машини зберігаються та обслуговуються.

Uber Courier — це ребрендинг сервісу Uber Connect, запущеного у 2020 році, який дозволяв користувачам відправляти пакунки та особисті речі між локальними адресами. Але Uber стверджує, що його підтримка для роботаксі — це не лише повторне використання вже наявних сервісів.

«Щороку на Uber звітують про десятки мільйонів загублених речей, тож останнє десятиліття ми витратили на побудову систем, які допомагають пасажирам швидко й безперешкодно возз’єднатися зі своїми речами, — йдеться у заяві Емі Сатром, глобальної керівниці напряму автономної підтримки в Uber. — У міру масштабування автономних поїздок в Uber ми переносимо цей досвід і на AV — поєднуючи наші операції з автопарком, команди підтримки та гібридну мережу, щоб повернення загубленого предмета було простим, навіть коли за кермом немає водія».

У лютому компанія оголосила про створення Uber Autonomous Solutions — нового підрозділу, який відображає масштабні амбіції Uber у сфері безпілотних технологій. Підрозділ пропонує компаніям пакет послуг, що охоплюють усі завдання, пов’язані з експлуатацією роботаксі, безпілотних вантажівок або доставкових робо-платформ на тротуарах, включно з програмним забезпеченням і сервісною підтримкою.

Uber очевидно розглядає автономний транспорт як один з ключових драйверів майбутньої виручки. Компанія планує до кінця року запустити поїздки роботаксі у своєму застосунку щонайменше в 15 містах по всьому світу та заявляє, що до 2029 року прагне стати найбільшим посередником з організації поїздок на AV у світі.

Джерело

TechCrunch

Meta пішла на незначні поступки в межах свого вкрай суперечливого плану відстежувати кліки миші та натискання клавіш працівників заради навчання ШІ. Компанія нібито внесла деякі зміни до проєкту, який внутрішньо називають Model Capability Initiative (MCI), повідомляє The Information.

За оновленими правилами Meta планує дозволити працівникам «ставити на паузу» це відстеження до 30 хвилин, якщо їм потрібно «перевірити щось особисте», йдеться в службовій записці компанії. Частина співробітників також зможе подати запит на повну відмову від участі в програмі, але це стосуватиметься лише віддалених працівників із проблемами пропускної здатності мережі, людей, які мають справу з «чутливими» матеріалами, а також тих, хто часто працює в місцях, де складно постійно тримати ноутбук підключеним до джерела живлення.

Тобто для більшості працівників Meta вимога дозволити майже повне відстеження та запис їхніх дій на комп’ютері в ім’я покращення моделей ШІ фактично зберігається. Водночас, за даними Reuters, компанія заявила, що оптимізувала програмне забезпечення щодо споживання батареї, аби зняти частину претензій з боку співробітників. Meta вже стикнулася з протестами через MCI, який було оголошено минулого місяця — майже одночасно зі звільненням 8 000 працівників і переведенням тисяч інших на роль, зосереджені на ШІ.

Генеральний директор Марк Цукерберг нещодавно захищав програму перед працівниками, заявивши, що «спостереження за тим, як дуже розумні люди щось роблять» — найкращий спосіб швидко покращувати моделі ШІ. «Середній рівень інтелекту людей у нашій компанії значно вищий, ніж у середньої групи людей, яких можна найняти для виконання завдань», — сказав він в оприлюдненому аудіозаписі загальнокорпоративної зустрічі минулого місяця.

«Жодні дані не використовуються для того, щоб, типу, дивитися, що люди роблять, або для стеження, або для оцінювання ефективності чи чогось подібного. Ми просто використовуємо це, щоб зібрати дуже великий масив контенту для моделі ШІ, аби вона могла навчитися тому, як розумні люди користуються комп’ютерами для виконання завдань. Я вважаю, що це буде дуже великою перевагою, якщо ми зможемо це реалізувати». Він також додав, що якщо це спрацює, у майбутньому компанія «ймовірно робитиме ще більше подібних речей».

Джерело

Engadget

Ринок AI‑інженерії стрімко дорожчає: топові ролі вже зараз перевищують позначку $300 тис. на рік. Канал Marina Wyss – AI & Machine Learning окреслює п’ять ключових навичок, які в найближчі роки відрізнятимуть високооплачуваних фахівців від решти претендентів.

1. Структурована оцінка замість «погралися з промптами»

У класичній розробці ніхто не випускає код у продакшн без тестів. З LLM‑системами все складніше: моделі недетерміновані, однаковий запит може повертати різні відповіді, а помилки часто суб’єктивні й тонкі.

Попри це, більшість AI‑фіч сьогодні будують майже без реальної системи оцінювання. Типовий підхід — кілька ручних перевірок і одноразовий скрипт, до якого ніхто не повертається. У компаніях, які платять AI‑інженерам по $300K, усе навпаки: система оцінки закладається до старту розробки й супроводжує продукт на всіх етапах.

Критично важливо:

• мати формалізовані метрики якості для конкретного застосування;
• запускати регулярні, відтворювані тести на різних сценаріях;
• відстежувати деградацію якості з часом і після змін у коді чи конфігурації моделей.

Без цього AI‑продукти залишаються на рівні демо, а не надійних сервісів.

2. Контекст‑інжиніринг замість вузького «prompt engineering»

Базовий prompt engineering уже став обов’язковим мінімумом, але цього недостатньо. Сучасні AI‑системи дедалі частіше агентні: вони виконують десятки, а іноді й сотні кроків, використовуючи інструменти, історію діалогу, пам’ять і зовнішні джерела даних.

У кожному кроці до контексту додаються:

• визначення інструментів;
• результати попередніх викликів;
• фрагменти, витягнуті з баз знань;
• історія взаємодії з користувачем.

Усе це має вміститися у скінченне вікно контексту, і модель повинна «знайти» потрібну інформацію, не загубившись у шумі. Контекст‑інжиніринг — це про проєктування всієї інформаційної системи навколо моделі:

• що саме й у якій формі бачить модель на кожному кроці;
• як структуруються й фільтруються дані;
• як скорочується історія, щоб не втратити критичні деталі;
• як організовано пам’ять між сесіями.

Саме ця дисципліна часто відділяє інженерів, здатних будувати масштабовані, стабільні AI‑системи, від тих, хто зупиняється на «гарних промптах» для одиничних запитів.

3. Агентні системи, які витримують продакшн

У публічних обговореннях «агенти» часто зводяться до чат‑бота з кількома інструментами. У реальному продакшні картина інша: агент працює на потоці користувацького трафіку, взаємодіє з API, базами даних, зовнішніми сервісами — і все це в умовах, де помилки коштують дорого.

Ключові виклики:

• некоректні або частково зламані відповіді API;
• тайм‑аути мережі;
• збої в інструментах, на які спирається агент;
• необхідність не «зламатися» посеред критичної взаємодії з клієнтом.

Тут у гру входять навички, близькі до інженерії розподілених систем:

• механізми повторних спроб (retries);
• граційна деградація функціоналу;
• захист від «збоїв» моделі, яка за визначенням не є детермінованою.

Справжня цінність AI‑інженера — не в тому, щоб змусити агента зробити щось один раз у лабораторних умовах, а в тому, щоб він стабільно працював тижнями й місяцями під реальним навантаженням.

4. LLM Ops: міст між прототипом і продуктом

Окрема, ще мало сформалізована, але критично важлива зона — LLM Ops. Це аналог MLOps, але для систем на базі великих мовних моделей. Вона охоплює все, що перетворює разовий AI‑проєкт на повноцінний продукт.

Серед ключових елементів:

• деплоймент моделей і сервісів;
• моніторинг якості, помилок, латентності;
• оптимізація витрат на виклики моделей;
• кешування відповідей, щоб зменшити затримки й вартість;
• fallback‑механізми на випадок збоїв або відмови провайдера моделей.

До цього додаються практичні питання, з якими новачки часто не стикаються:

• як обрати різні моделі для різних частин системи;
• як прогнозувати витрати на інференс;
• як налаштувати моніторинг так, щоб проблеми виявлялися до того, як їх побачить користувач.

Ця сфера лише формується: ще кілька років тому просто не було достатньо продакшн‑досвіду з LLM, щоб створити повноцінні курси. Саме тому фахівці, які вміють будувати LLM Ops‑шар, залишаються рідкісними й високооплачуваними.

5. Адаптивність як базова професійна навичка

Технологічний стек в AI‑інженерії змінюється настільки швидко, що жоден «раз і назавжди» вивчений курс не дає довгострокової гарантії актуальності. Інструменти, з якими працюють сьогодні, можуть зникнути або радикально змінитися за кілька місяців. Моделі постійно оновлюються, з’являються нові API, фреймворки, підходи.

У такій реальності ключовою стає не конкретна бібліотека, а здатність:

• швидко розбиратися в нових інструментах;
• працювати в умовах невизначеності й постійних змін;
• приймати, що «фінішу» в навчанні не буде.

Ті, хто зможе не просто витримувати цей темп, а й знаходити в ньому мотивацію, мають найкращі шанси на успіх у ролях AI‑інженерів у 2026 році й далі.

Джерело

5 Skills That’ll Make You a $300K AI Engineer in 2026

У новому відео підприємець і розробник AI‑інструментів Остін Марчезе показує, як перетворити Claude від Anthropic з просто «розумного співрозмовника» на системний робочий інструмент. Перший і, за його логікою, базовий крок — навчити модель по‑справжньому працювати з інтернетом. Для цього він збирає окремий скіл веб‑скрейпінгу, який обходить вбудовані обмеження Claude, використовуючи два зовнішні сервіси: Firecrawl і Exa.

Цей матеріал розбирає саме цю частину підходу — як і навіщо будувати власний веб‑скрейпер для Claude, що вміє читати сучасні JavaScript‑сайти та шукати не за ключовими словами, а за змістом запиту.

Чому стандартний інтернет‑пошук Claude гальмує якість відповідей

Claude, як і інші великі мовні моделі, вражає здатністю структурувати думки, писати код і пояснювати складні теми простою мовою. Але всі ці можливості впираються в одну банальну річ: якість вхідних даних. Якщо модель бачить лише урізаний, зашумлений або застарілий шматок інформації, жоден «розумний» ланцюжок міркувань не врятує результат.

У випадку з Claude Марчезе виділяє дві фундаментальні проблеми вбудованого інтернет‑пошуку.

По‑перше, модель погано працює з сучасною мережею, де більшість сайтів рендеряться JavaScript‑фреймворками. Багато сторінок сьогодні не містять повноцінного HTML‑контенту «з коробки» — текст і структура з’являються вже після виконання скриптів у браузері. Для людини це непомітно, але для моделі, яка очікує статичний HTML, це означає: замість статті — порожня оболонка, фрагменти коду, обривки тексту. У результаті Claude просто «не бачить» значну частину сучасних ресурсів.

По‑друге, Claude покладається на базовий ключовий пошук. Це означає, що релевантність результатів сильно залежить від того, наскільки точно користувач вгадав формулювання. Такий підхід ігнорує суть запиту, контекст, синоніми, близькі за змістом формулювання. Для людини, яка мислить категоріями «намір», «проблема», «сценарій використання», це створює відчутний розрив: ви питаєте про одне, а отримуєте тексти, де просто збігаються окремі слова.

У світі, де AI‑системи все частіше використовують як «другий мозок» для досліджень, аналітики й прийняття рішень, ці два обмеження стають критичними. Вони не просто знижують комфорт роботи — вони обмежують стелю якості, до якої взагалі може дотягнутися Claude.

Дані як точка максимального важеля: чому варто починати саме з пошуку

У традиційній розробці AI‑систем часто фокусуються на «верхньому шарі»: кращі промпти, складніші ланцюжки інструкцій, багатокрокові воркфлоу. Але Марчезе пропонує дивитися на проблему інакше: найефективніший важіль покращення — не в тому, як ми просимо модель думати, а в тому, що ми їй даємо думати.

Якщо уявити Claude як аналітика, то вбудований інтернет‑пошук — це його асистент, який приносить йому документи. Можна нескінченно тренувати аналітика краще структурувати звіти, але якщо асистент приносить йому випадкові, поверхневі або неповні матеріали, результат завжди буде посереднім.

Звідси логіка: щоб «розблокувати» потенціал Claude, потрібно прокачати саме шар виявлення та добування даних. Це означає:

1. Дотягнутися до тих джерел, які модель раніше фізично не могла прочитати (JavaScript‑важкі сайти, сучасні веб‑додатки, динамічні сторінки).
2. Замінити примітивний ключовий пошук на семантичний, який розуміє намір користувача, а не лише збіг слів.

Як тільки цей «вхідний» шар стає якіснішим, усі наступні кроки — аналіз, узагальнення, планування, генерація контенту — автоматично піднімаються на інший рівень. Саме тому веб‑скрейпер у системі Марчезе — не просто одна з опцій, а базовий «утилітарний» скіл, який має право викликатися в будь‑якому проєкті й підсилювати всі інші навички Claude.

Firecrawl: як навчити Claude бачити сучасні JavaScript‑сайти

Перша половина рішення — Firecrawl. Це зовнішній сервіс, який бере на себе роль «браузера для AI»: він відкриває веб‑сторінку, виконує JavaScript, чекає, поки контент з’явиться, і лише потім віддає Claude вже «розгорнутий» текст і структуру.

У стандартному режимі Claude стикається з типовою проблемою: заходить на сайт, де контент підтягується через React, Vue чи інший фреймворк, бачить мінімальний HTML і купу скриптів, і на цьому все. Будь‑які спроби аналізу такої сторінки перетворюються на вгадування. Firecrawl закриває цю прогалину, фактично емулюючи поведінку реального користувача в браузері, але з виходом у форматі, зручному для LLM.

У веб‑скрейпер‑скілі Firecrawl використовується як плагін, до якого Claude може звернутися, коли потрібно:

• отримати повний текст статті з сучасного медіа‑сайту;
• витягнути контент із дашборду чи веб‑додатку, де все «малюється» на льоту;
• працювати з ресурсами, які без виконання JavaScript виглядають порожніми.

Ключовий момент у підході Марчезе — зробити цей інструмент не разовою «фішкою», а частиною постійної інфраструктури. Веб‑скрейпер визначається як утилітарний скіл: він може автоматично підключатися в будь‑якому діалозі чи проєкті, коли Claude розуміє, що йому потрібні свіжі дані з мережі. Це не окремий сценарій «піди поскрейпи», а базова можливість: якщо потрібна інформація — модель знає, як її дістати навіть із найсучасніших сайтів.

Результат — Claude перестає бути заручником статичних сторінок і починає працювати з тією ж мережею, яку бачить користувач у браузері. Для будь‑яких задач, де важлива актуальність і глибина джерел, це радикально змінює картину.

Exa: від ключових слів до семантичного пошуку за наміром

Друга половина конструкції — Exa, сервіс семантичного пошуку, який замінює для Claude традиційний keyword‑підхід. Якщо Firecrawl відповідає за «бачити більше», то Exa — за «знаходити краще».

Ключова відмінність семантичного пошуку в тому, що він працює не з буквальними збігами слів, а з близькістю значень у векторному просторі. Для користувача це означає: можна формулювати запит природною мовою, з контекстом, уточненнями, навіть із побутовими формулюваннями — система намагатиметься зрозуміти, що саме ви маєте на увазі, а не які слова ви використали.

У випадку Claude це критично з двох причин.

По‑перше, користувачі часто описують задачі, а не терміни. Наприклад: «Я 36‑річний, повертаюся до кардіо, хочу додати м’язи, не втрачаючи витривалість». Ключовий пошук може розсипати це на «36 років», «кардіо», «м’язи», «витривалість» і видати щось випадкове. Семантичний пошук на кшталт Exa намагається зрозуміти загальний намір: програма тренувань для людини середнього віку, яка повертається до навантажень і хоче збалансувати силові та кардіо.

По‑друге, Claude сам по собі добре працює з сенсом і контекстом. Але якщо на вході він отримує набір статей, підібраних за грубими ключовими словами, то змушений витрачати частину «інтелектуального бюджету» на відсіювання шуму. Коли ж пошук одразу віддає релевантні, змістовно близькі матеріали, модель може зосередитися на аналізі, порівнянні, синтезі.

У веб‑скрейпер‑скілі Exa інтегрується як другий плагін поруч із Firecrawl. Схема роботи виглядає так:

Claude отримує запит користувача, формує семантичний пошуковий запит до Exa, отримує список релевантних сторінок, а далі за потреби «проходить» по них через Firecrawl, щоб витягнути повний контент навіть із JavaScript‑важких сайтів. Усе це відбувається в одному воркфлоу, прозоро для користувача.

Таким чином, Claude перестає бути прив’язаним до буквальної форми запиту й починає працювати з наміром — так, як це робить людина‑експерт, яка спочатку намагається зрозуміти, «про що насправді питання», а вже потім шукає джерела.

Як працює кастомний веб‑скрейпер: один скіл, два плагіни, новий рівень даних

Конструкція, яку пропонує Марчезе, на перший погляд проста: взяти два зовнішні сервіси й «підшити» їх до Claude як плагіни. Але важливий не лише набір інструментів, а й те, як вони з’єднані в єдиний скіл.

Веб‑скрейпер у цій моделі — це не просто набір окремих команд «запусти Firecrawl» чи «запусти Exa». Це цілісний утилітарний скіл, який Claude може викликати щоразу, коли йому потрібні зовнішні дані. Усередині нього:

Firecrawl відповідає за доступність: він гарантує, що модель зможе прочитати контент навіть там, де стандартний механізм Claude безсилий через JavaScript‑рендеринг.

Exa відповідає за релевантність: він підбирає ті джерела, які найбільш близькі до наміру користувача, а не просто містять потрібні слова.

У поєднанні це створює новий «шар відкриття даних» для Claude. Замість того, щоб покладатися на вбудований, обмежений пошук, модель отримує:

• ширший горизонт джерел (завдяки Firecrawl);
• глибшу відповідність запиту (завдяки Exa);
• автоматизований воркфлоу, де обидва інструменти працюють як єдиний скіл.

Марчезе називає такі скіли утилітарними не випадково. Вони не прив’язані до конкретної предметної області — фітнес, бізнес, освіта — і не залежать від конкретного проєкту. Один раз налаштований веб‑скрейпер може підсилювати будь‑яку задачу: від дослідження ринку до підготовки навчальних матеріалів.

Показовий приклад — його демонстрація з персональним фітнес‑тренером. Користувач може попросити Claude:

спочатку знайти найкращі дослідження з фітнесу за останні три роки, використовуючи веб‑скрейпер, а потім зберегти знайдену інформацію в проєкт за допомогою іншого скіла — /ingest‑source. У результаті Claude не лише працює з актуальними науковими даними, а й має власну, зібрану базу знань, до якої може звертатися в майбутньому без повторного пошуку.

Але фундамент усього цього — саме веб‑скрейпер, який забезпечує якісний, широкий і релевантний вхідний потік даних.

Від разових запитів до системи: чому веб‑скрейпер має бути «завжди ввімкнений»

Ключова ідея підходу Марчезе — перестати сприймати інтернет‑пошук як разову дію «піди в Google», і почати думати про нього як про постійний сервіс у вашій AI‑інфраструктурі.

У традиційному сценарії користувач сам вирішує, коли «піти в інтернет», формулює запит, переглядає результати, відбирає посилання, копіює фрагменти тексту й приносить їх у діалог із моделлю. Це повільно, фрагментарно й сильно залежить від навичок самого користувача.

Коли ж веб‑скрейпер оформлено як утилітарний скіл, Claude отримує можливість самостійно:

• визначати, коли йому бракує даних для якісної відповіді;
• запускати семантичний пошук через Exa;
• витягувати повний контент із потрібних сторінок через Firecrawl;
• інтегрувати отримані дані у власні міркування в рамках того ж діалогу.

Для користувача це виглядає як «просто кращі відповіді», але насправді за цим стоїть зміна архітектури: модель перестає бути ізольованою від живого інтернету й отримує власний, розумний шар доступу до даних.

У поєднанні з іншими скілами, які Марчезе будує навколо Claude — такими як /ingest‑source для створення довгострокової бази знань чи /improve‑system для поступового вдосконалення самої системи — веб‑скрейпер стає фундаментом. Без нього вся надбудова працює на обмеженому, випадковому наборі джерел. З ним — система може рости, оновлюватися й адаптуватися разом із зовнішнім світом.

Висновок: майбутнє LLM — у розумному доступі до даних, а не лише в «розумних промптах»

Історія з веб‑скрейпером для Claude добре ілюструє ширший тренд у розвитку AI‑інструментів. Перші хвилі захоплення великими мовними моделями були зосереджені на тому, «що вони вміють»: писати тексти, генерувати код, відповідати на питання. Сьогодні стає очевидно: справжня цінність з’являється тоді, коли ці можливості поєднуються з якісним, актуальним і релевантним доступом до даних.

Комбінація Firecrawl і Exa у вигляді єдиного веб‑скрейпер‑скіла для Claude — це приклад того, як можна обійти вбудовані обмеження моделі, не змінюючи її ядро. Замість того, щоб чекати на «ідеальну LLM із ідеальним пошуком», користувачі вже сьогодні можуть будувати власні шари доступу до інформації, які:

• розширюють видимий для моделі інтернет за рахунок JavaScript‑важких сайтів;
• підвищують релевантність результатів завдяки семантичному пошуку;
• інтегруються в робочі процеси як утилітарні, завжди доступні навички.

У підсумку Claude перестає бути просто «розумним чат‑ботом» і перетворюється на частину більшої системи, де якість вихідного результату визначається не лише потужністю моделі, а й тим, наскільки грамотно побудовано шар виявлення та добування даних. І саме тут сьогодні проходить одна з головних ліній розмежування між «іграшковим» використанням AI і справжніми продуктивними системами.

Джерело

YouTube: The ONLY 6 Skills You Need to 10x Your Claude Projects

У потокових системах з «майже реальним часом» дублікати подій — не виняток, а норма. Команда Confluent Developer у своєму розборі показує, чому прості підходи часто не працюють, і як коректно реалізувати дедуплікацію в Apache Flink SQL без зайвої затримки та помилкових втрат даних.

Чому дублікати взагалі з’являються

Сучасні фреймворки потокової обробки вміють забезпечувати семантику exactly-once, але це має ціну — додаткову затримку. Для частини сценаріїв (наприклад, високочастотна торгівля чи моніторинг) навіть кілька зайвих мілісекунд або секунд — критичні. Тому розробники часто обирають at-least-once доставку, приймаючи ризик появи дублікатів.

У такій конфігурації будь-який збій, повторна відправка або повторне зчитування з брокера можуть призвести до того, що одна й та сама подія потрапить у стрім кілька разів. Якщо потім ці дані агрегуються, збагачуються або використовуються для виявлення патернів, дублікати спотворюють результати — від подвійних сум до хибних тригерів.

Отже, дедуплікація стає окремим обов’язковим «будівельним блоком» у конвеєрі обробки подій.

Чому дедуплікація через tumbling window — антипатерн

Поширена інтуїтивна ідея: взяти tumbling window (ковзні вікна фіксованої довжини) і в межах кожного вікна прибирати дублікати за ключем. На практиці це створює одразу кілька проблем.

1. Дубль може потрапити в інше вікно

Уявімо потік трейдів, де кожна угода має унікальний trade_id, а часові мітки виставляє брокер Kafka. Оригінальна подія T1 приходить у чорному, дублікат — трохи пізніше, у червоному. Навіть якщо вони йдуть майже одночасно, різниця в timestamp може віднести їх у різні вікна.

Результат: перша подія потрапляє в одне вікно, дублікат — у наступне. Жодне з вікон не бачить обидві події разом, отже дубль не розпізнається й не відкидається. Це повністю нівелює задум дедуплікації.

2. Висока затримка через очікування кінця вікна

При віконній обробці результати з’являються лише після закриття вікна. Якщо вікно триває, скажімо, хвилину, то будь-яка подія чекатиме до хвилини, перш ніж потрапити в результуючий стрім. Для сценаріїв, де важлива низька затримка, це неприйнятно.

3. Проблеми з late events і watermarks

У Flink SQL робота вікон тісно пов’язана з watermarks. Пізні події, що приходять після того, як watermark «перестрибнув» їхній час, просто відкидаються. Для дедуплікації це означає ризик втратити або оригінал, або дублікат, що знову робить результат ненадійним.

Підсумок: використання tumbling window для дедуплікації в Flink SQL — радше антипатерн, ніж рішення.

Over-window: подія як тригер, а не кінець вікна

Набагато природніший підхід у Flink SQL — over-aggregation (over-window). Ідея в тому, що «вікно» фактично тригериться кожною подією, а не часом.

Як це працює концептуально

1. Партиціювання за унікальним ключем
   Потік розбивається за унікальним ідентифікатором, наприклад trade_id. Логічно це виглядає як окремий підпотік для кожної угоди.

2. Збирання всіх подій з однаковим ключем
   Для кожного trade_id збираються всі події (зазвичай одна, але можуть бути дві чи більше у разі дублікатів).

3. Вибір «правильної» події за порядком
   Події впорядковуються за часом. Якщо використовується ascending порядок, береться перша подія, а всі наступні з тим самим ключем вважаються дублікатами й відкидаються.

4. Миттєвий вивід результату
   Як тільки приходить нова подія:

5. якщо ключ ще не зустрічався — подія одразу проходить далі;
6. якщо ключ уже є в стані — подія розпізнається як дубль і відкидається без очікування будь-якого «кінця вікна».

Це дає дедуплікацію з низькою затримкою й без залежності від розміру вікна чи поведінки watermarks.

Що зі станом: скільки всього треба зберігати

Такий підхід створює необмежений стан: теоретично кількість унікальних ключів може зростати нескінченно. Втім, зберігати весь запис не обов’язково — достатньо пам’ятати сам унікальний ключ (trade_id), а не повний трейд.

Однак за високої активності (наприклад, у біржовій торгівлі) навіть набір ключів може стати дуже великим. Тому критично важливо налаштувати:

• State Time To Live (TTL) для таблиці/стану.
  TTL визначає, як довго зберігається інформація про вже бачені ключі. Орієнтиром може бути максимальна очікувана тривалість збоїв або затримок, які можуть спричинити дублікати. Наприклад, якщо повторна доставка можлива в межах години, TTL у годину може бути достатнім.

Це дозволяє обмежити ріст стану й уникнути проблем із ресурсами.

Ascending vs descending: чому «останній» елемент у стрімі — пастка

Over-window дозволяє впорядковувати події як у ascending, так і в descending порядку. На перший погляд може здаватися логічним брати «останню» версію події (descending), але в потоковому світі це ускладнює життя.

Ascending: стабільний, «фінальний» результат

При ascending сортуванні береться перша подія за часом. У стрімінгу це добре визначена операція: як тільки перша подія з ключем приходить, її можна вважати результатом, а всі наступні — дублікатами. Вихідний потік при цьому є append-only — записи додаються, але не змінюються.

Це спрощує інтеграцію з подальшими системами (сховища, аналітика, дашборди), які очікують стабільні, неоновлювані записи.

Descending: оновлюваний стрім і складніший пайплайн

Якщо обрати descending порядок, логіка змінюється:

• фактично запитується «останній» елемент за часом;
• але в стрімі ніколи не можна бути впевненим, що не прийде ще один дубль пізніше.

Тому система змушена:

1. Спочатку видати перший запис як поточний «останній».
2. Якщо приходить новий дубль — відкликати попередній результат («забудьте те, що я казав») і видати оновлений.

Це перетворює вихідний потік на updating stream — з подіями типу «update» замість простих «insert». Подальші компоненти мають уміти коректно обробляти оновлення, що ускладнює архітектуру.

Тому, коли це можливо, доцільно:

• уникати descending у дедуплікації;
• віддавати перевагу ascending і append-only виходу.

Практичні рекомендації для дедуплікації у Flink SQL

Підсумовуючи, для побудови надійної дедуплікації в Flink SQL варто врахувати кілька ключових моментів:

• Не покладатися на tumbling windows
  Вони не гарантують, що дубль опиниться в тому самому вікні, створюють затримку й залежать від watermarks та обробки late events.

• Використовувати over-window з партиціюванням за унікальним ключем
  Це дозволяє реагувати на кожну подію миттєво, без очікування кінця вікна.

• Обмежувати стан через TTL
  Налаштувати state time to live відповідно до максимальної очікуваної тривалості збоїв/затримок, які можуть породжувати дублікати.

• Вибирати ascending порядок для стабільного виходу
  Це дає append-only потік, спрощує подальшу обробку й інтеграцію.

• Обачно працювати з updating streams
  Over-window може приймати на вхід оновлювані стріми й генерувати оновлюваний вихід. Якщо це неминуче, архітектура наступних компонентів має бути до цього готовою, але за можливості краще уникати такого сценарію.

Для тих, хто працює з DataStream API, залишається опція написати власну ProcessFunction для дедуплікації. Це дає повний контроль, але потребує самостійного врахування всіх описаних нюансів: управління станом, TTL, семантики часу та оновлень.

Джерело

Deduplication | Design Patterns for Apache Flink SQL

Apache Kafka офіційно позбулася залежності від ZooKeeper. Команда Confluent Developer пояснює, як режим KRaft (Kafka Raft mode) перебудовує керування метаданими, спрощує архітектуру кластера та відкриває шлях до масштабування без старих обмежень.

Від ZooKeeper до KRaft: нова модель керування метаданими

Раніше Kafka покладалася на окремий кластер ZooKeeper для всього, що стосувалося метаданих:

• ідентифікатори брокерів
• конфігурації топіків
• інформація про партиції та їхніх лідерів
• загальний стан кластера

У режимі KRaft ця роль переходить самій Kafka. Ключові зміни:

• Жодного окремого кластера ZooKeeper — більше не потрібно розгортати й підтримувати другу систему.
• Метадані зберігаються в Kafka — у спеціальному внутрішньому топіку, а не в ZooKeeper.
• Вбудований консенсус на базі Raft — Kafka отримує власний шар узгодження стану замість зовнішнього сервісу.

Це означає, що платформа сама «володіє» своїми метаданими, не делегуючи критичну логіку зовнішньому компоненту.

Контролерний кворум і Raft: як тепер працює кластер

Одне з головних архітектурних оновлень — перехід від єдиного контролера до кворуму контролерів, які працюють за алгоритмом Raft.

Було: один контролер

У класичній архітектурі Kafka:

• існував один контролер-брокер, який відповідав за керування метаданими;
• інші брокери стежили за ZooKeeper, щоб отримувати оновлення;
• вибір нового контролера та лідерів партицій залежав від сесій і таймаутів ZooKeeper.

Це створювало додаткову складність і потенційні затримки під час відмов.

Стало: кворум контролерів і єдиний журнал метаданих

У KRaft:

• формується невеликий кворум контролерів всередині самого кластера Kafka;
• усі метадані записуються в metadata log — внутрішній журнал, який реплікується за Raft;
• вибір лідерів партицій і контролерів відбувається через Raft, а не через механізми ZooKeeper.

Ключові наслідки:

• підвищена відмовостійкість — кілька контролерів у кворумі замість одного вузла;
• єдине джерело істини для стану кластера — один Raft-журнал метаданих, з якого брокери реплікують інформацію так само, як звичайні дані Kafka;
• швидші та передбачувані фейловери — вибори лідерів більше не залежать від нестабільних сесій ZooKeeper.

Спрощена архітектура та операційка

Перехід на KRaft змінює не лише внутрішню логіку, а й операційну модель:

• Одна система замість двох — адміністрування зосереджене навколо Kafka, без окремого життєвого циклу ZooKeeper.
• Єдина поверхня безпеки та експлуатації — немає потреби налаштовувати, моніторити й оновлювати ще один критичний компонент.
• Менше точок відмови — окремий кластер ZooKeeper більше не може «покласти» Kafka у разі проблем.

Для команд експлуатації це означає простіше розгортання, менше рухомих частин і більш передбачувану поведінку кластера під навантаженням.

Що залишилося незмінним для розробників

Попри суттєву внутрішню перебудову, модель використання Kafka для клієнтів не змінюється:

• продюсери та конс’юмери працюють як раніше;
• топіки, партиції, патерни споживання — усе зберігає звичну семантику;
• зміни стосуються переважно внутрішньої архітектури, а не API для застосунків.

Тобто перехід до KRaft — це радше еволюція платформи, ніж злам сумісності для користувачів.

Чому це важливо: масштаб, надійність, cloud native

KRaft робить Kafka більш придатною до сучасних сценаріїв використання:

• Cloud native-підхід — вбудований консенсус і відсутність зовнішнього координатора краще вписуються в хмарні середовища.
• Простіше керування та масштабування — менше компонентів, чіткіший шлях масштабування кластера.
• Більше партицій на кластер — ZooKeeper більше не виступає «вузьким місцем» для метаданих, що відкриває шлях до значно більшої кількості партицій.

У підсумку відмова від ZooKeeper — це не просто «прибирання старого коду», а крок до зрілої, самодостатньої платформи, де Kafka повністю контролює власні метадані та краще відповідає вимогам великих розподілених систем.

Джерело

Kafka Without ZooKeeper — Confluent Developer

Квантові комп’ютери часто подають як «магічні чорні скриньки», але їхня логіка починається з дуже конкретних математичних об’єктів — квантових брам. У свіжому пояснювальному ролику IBM Technology на прикладі кількох ключових брам показано, як із простих матриць і векторів народжуються суперпозиція, заплутаність і, зрештою, квантова перевага.

Від бітів до кубітів: спільна мова — брами

У класичних і квантових комп’ютерів є спільний фундамент: обидва працюють із брамами (gates), тобто інструкціями, які змінюють стан інформації.

• У класичній схемі брами змінюють біти — 0 та 1.
• У квантовій — кубіти, які можуть бути не лише в 0 чи 1, а й у їхній суперпозиції.

Класичний приклад — NOT (інверсія): 0 перетворюється на 1, а 1 — на 0. У квантовому світі аналогічні операції описуються не просто логічними правилами, а матрицями, що діють на вектори станів.

У квантовій механіці стани записують у так званій нотації Дірака:
– |0⟩ — стан «нуль»
– |1⟩ — стан «один»

У лінійній алгебрі це вектори-стовпці:

• |0⟩ → [1, 0]ᵀ
• |1⟩ → [0, 1]ᵀ

Якщо стани — вектори, то брами — це матриці, які їх перетворюють.

Hadamard: як одна брама створює суперпозицію

Перша ключова квантова брама — Hadamard (H). Вона безпосередньо пов’язана з явищем суперпозиції: кубіт може одночасно перебувати в комбінації станів |0⟩ і |1⟩, доки його не виміряють.

Математика суперпозиції

Рівноймовірна суперпозиція двох станів записується так:

(1/√2)·|0⟩ + (1/√2)·|1⟩

Коефіцієнти перед |0⟩ та |1⟩ — це амплітуди. Якщо їх піднести до квадрату, отримаємо ймовірності вимірювання:

• (1/√2)² = 1/2 для |0⟩
• (1/√2)² = 1/2 для |1⟩

Разом — 1, як і має бути для повної ймовірності.

Hadamard як матриця

У матричному вигляді брама H виглядає так:

H = (1/√2) · [[1, 1],
        [1, −1]]

Якщо застосувати її до |0⟩ (вектор [1, 0]ᵀ), отримаємо:

• добуток матриці H на вектор |0⟩ дає вектор [(1/√2), (1/√2)]ᵀ
• у нотації Дірака це саме (1/√2)|0⟩ + (1/√2)|1⟩

Тобто одна-єдина брама Hadamard перетворює «класичний» нуль у квантову суперпозицію двох станів. Це перший фундаментальний крок, який відрізняє квантову схему від класичної.

CNOT і Bell-стан: як народжується заплутаність

Друге базове квантове явище — заплутаність (entanglement). Воно означає, що два кубіти описуються єдиним спільним станом: вимірявши один, миттєво знаєш стан іншого, незалежно від відстані між ними.

Ключова брама для створення заплутаності — CNOT (controlled-NOT). Вона діє одразу на два кубіти:

• перший — керуючий (control)
• другий — цільовий (target)

Правило: CNOT інвертує цільовий кубіт лише тоді, коли керуючий у стані |1⟩.

Чому CNOT — це 4×4 матриця

Один кубіт має два базові стани: |0⟩ і |1⟩.
Два кубіти — вже чотири: |00⟩, |01⟩, |10⟩, |11⟩.

Тому:

• стани двох кубітів — це 4-вимірні вектори
• брама, що діє на два кубіти, — матриця 4×4

CNOT саме така матриця, яка реалізує описане вище правило для пар станів.

Як із Hadamard і CNOT отримати Bell-стан

Щоб побачити заплутаність у дії, послідовність виглядає так:

1. Початковий стан: обидва кубіти в |0⟩, тобто |00⟩.
2. Створення суперпозиції на першому кубіті:
3. застосовуємо Hadamard до першого кубіта, другий лишається в |0⟩
4. технічно це означає «розширити» H до матриці 4×4 так, щоб вона діяла лише на перший кубіт
5. Застосування CNOT:
6. керуючий — перший кубіт
7. цільовий — другий

У результаті виникає стан, відомий як Bell-стан. Це один із найвідоміших станів у фізиці, який демонструє, що два кубіти більше не описуються незалежно — вони утворюють єдину квантову систему.

Цей Bell-стан став ключовим аргументом у роботах Джона Белла, який показав: якщо квантова механіка правильна, Всесвіт не може одночасно задовольняти принцип локального реалізму. Або об’єкти не мають визначених властивостей до вимірювання, або жодна взаємодія не обмежена швидкістю світла — одне з цих тверджень має бути хибним. У сучасній фізиці зазвичай зберігають обмеження швидкістю світла, а відмовляються від ідеї «заздалегідь визначених» станів.

Факт залишається: лише дві брами — Hadamard і CNOT — достатні, щоб створити суперпозицію й заплутаність.

Чому цього мало: обмеження групи Кліффорда і роль T-брами

Попри всю «квантовість» Hadamard і CNOT, самі по собі вони не роблять квантовий комп’ютер принципово сильнішим за класичний. Обидві ці брами належать до так званої групи Кліффорда (Clifford group).

Теорема Ґоттсмана–Ніла: квантове, але ще не «надкласичне»

Існує важливий результат — теорема Ґоттсмана–Ніла. Вона стверджує:

Схеми, які використовують лише брами з групи Кліффорда, можна ефективно симулювати на класичному комп’ютері.

Тобто:

• Hadamard + CNOT (і інші Clifford-брами) дають суперпозицію та заплутаність
• але цього недостатньо, щоб отримати експоненційну перевагу над класичними обчисленнями

Щось у цій картині бракує.

T-брама: маленький фазовий зсув з великими наслідками

Відсутню «цеглинку» додає T-брама. На вигляд вона проста: це одно кубітна брама, яка змінює лише фазу стану |1⟩, не чіпаючи |0⟩.

У матричній формі T-брама:

• залишає амплітуду |0⟩ незмінною
• множить амплітуду |1⟩ на фазовий множник e^{iπ/4}

Ключові моменти:

• T не змінює ймовірності вимірювань напряму (бо фаза не впливає на модуль амплітуди)
• але змінює відносні фази між компонентами суперпозиції
• саме ці фази визначають інтерференцію — як амплітуди підсилюють чи гасять одна одну

Додавання T-брами до набору Clifford-брам різко ускладнює класичну симуляцію:

• стани стають важче стисливими
• з’являється «додатковий вимір» у просторі станів
• вартість симуляції може зростати експоненційно

Універсальність: Clifford + T як повний набір

Комбінація Clifford-брам (зокрема Hadamard і CNOT) з T-брамою утворює універсальний набір для квантових обчислень. Це означає:

Будь-яку квантову еволюцію, яка можлива в природі, можна з довільною точністю апроксимувати схемою з цих брам.

Інакше кажучи, саме невеликий фазовий зсув, який вносить T-брама, стає «щілиною» в класичному світі. Через неї квантові схеми виходять за межі того, що можна ефективно відтворити класичними алгоритмами.

Висновок: Всесвіт складніший за нулі й одиниці

Квантові обчислення починаються не з екзотичних пристроїв, а з чітко визначених математичних операцій:

• Hadamard створює суперпозицію
• CNOT — заплутаність
• T-брама — фазу, яка робить схеми універсальними й важкими для класичної симуляції

Разом вони показують, що на фундаментальному рівні Всесвіт не зводиться до простих 0 і 1. Між ними існує простір фаз, суперпозицій і заплутаних станів — і саме в цьому просторі працюють квантові комп’ютери.

Джерело

The Most Important Gates in Quantum Computing Explained — IBM Technology

Канадський розробник і ютубер Tech With Tim, відомий практичними тестами інструментів для програмістів, вирішив перевірити, як нова модель Composer 2.5 від Cursor поводиться не в синтетичних бенчмарках, а в реальному завданні. У середовищі Cursor він запустив head‑to‑head тест трьох моделей — Composer 2.5, Opus 4.7 та GPT 5.5 — давши їм однаковий промпт: створити реальний застосунок — колаборативну whiteboard‑дошку в реальному часі.

Результат виявився не лише питанням швидкості й якості коду, а й дуже відчутної різниці у вартості, особливо в “швидких” режимах Cursor.

Як випадкове перемикання моделі виявило трьох‑чотирикратний приріст швидкості

Знайомство з Composer 2.5 у цього розробника почалося взагалі не з бенчмарків. Працюючи в Cursor, він, як зазвичай, обрав Opus 4.7 і кілька годин будував застосунок, поки не вичерпав ліміт використання преміальних моделей. Після цього Cursor автоматично переключився на нову Composer 2.5 — і це спочатку навіть залишилося непоміченим.

Зміни стали очевидними лише тоді, коли завдання почали виконуватися приблизно у три‑чотири рази швидше, ніж до цього з Opus 4.7, при цьому якість відповідей залишалася на тому ж рівні або здавалася навіть кращою з погляду структури виводу. Лише після цього автор звернув увагу на індикатор моделі в інтерфейсі й побачив, що працює вже не з Opus, а з Composer 2.5.

Цей досвід став відправною точкою для більш формального порівняння. Якщо модель, яка коштує значно дешевше, працює помітно швидше й не програє в якості, логічно перевірити це в контрольованому тесті. Так з’явився сценарій з колаборативною whiteboard‑дошкою, де всі три моделі отримали однаковий промпт усередині Cursor.

Whiteboard‑челендж: хто швидше й краще напише реальний застосунок

Для порівняння моделей було обрано завдання, яке добре відображає реальну роботу розробника: створити застосунок колаборативної дошки, де кілька користувачів можуть одночасно малювати в реальному часі. Це не “іграшковий” скрипт, а повноцінний стек: фронтенд, бекенд, синхронізація, мережеві події, структура проєкту.

Усі моделі запускалися всередині Cursor з однаковим промптом, але в різних режимах швидкості, які впливають і на вартість.

Composer 2.5: робоча дошка за 3–4 хвилини

У “fast mode” Composer 2.5 впорався із завданням приблизно за 3–4 хвилини. За цей час модель згенерувала робочий застосунок колаборативної дошки, який реально функціонував.

Архітектурно Composer 2.5 обрав стек, який сьогодні є де-факто стандартом для сучасних фронтенд‑проєктів: клієнт на React і TypeScript плюс окремий сервер. Такий підхід дає чітке розділення відповідальностей, кращу типобезпеку та простіший масштабований розвиток коду.

Важливий момент: це був не просто “hello world” з однією сторінкою, а саме робоча колаборативна дошка в реальному часі, яка виконувала поставлену задачу. На думку автора тесту, саме ця реалізація від Composer 2.5 виявилася найкращим стартовим варіантом серед усіх трьох моделей.

Opus 4.7: 15 хвилин очікування — і неробочий застосунок

Opus 4.7 запускали в “medium-fast mode” — тобто в режимі, де модель має більше ресурсів і, теоретично, повинна показувати сильніший результат, хоча й дорожчий. Попри це, час виконання завдання виявився приблизно 15 хвилин, що в кілька разів довше, ніж у Composer 2.5.

Кінцевий результат виявився проблемним: застосунок, який згенерував Opus 4.7, не працював. Замість сучасного стеку модель побудувала рішення на “чистому” JavaScript і CSS, без використання React чи TypeScript. Формально це теж веб‑клієнт, але з погляду підтримуваності, масштабованості та відповідності типовим робочим стек‑вимогам це крок назад.

Тобто в цьому тесті Opus 4.7 не лише програв у швидкості, а й не зміг видати робочий продукт, попри вищий режим продуктивності та значно більшу вартість обчислень.

GPT 5.5: повільніше, але з тестами й спільними типами

Третім учасником став GPT 5.5, також у “medium-fast mode”. Час виконання завдання коливався в діапазоні 10–20 хвилин — помітно довше, ніж у Composer 2.5, але трохи швидше або на рівні з Opus 4.7.

Проте тут результат був якісно іншим. GPT 5.5 згенерував робочий застосунок колаборативної дошки на React і TypeScript, доповнивши його тестами та спільними типами між клієнтом і сервером. Такий підхід ближчий до того, як будують продакшн‑системи: є типобезпека на всьому шляху даних, є базове тестове покриття, що полегшує подальшу розробку й рефакторинг.

Якщо дивитися лише на якість архітектури та “інженерну культуру” в коді, GPT 5.5 виглядає дуже переконливо. Але це досягається за рахунок часу: очікування в 10–20 хвилин проти 3–4 хвилин у Composer 2.5 — суттєва різниця, особливо коли мова йде про інтерактивну роботу розробника з інструментом.

Різні стеки — різні сценарії: чому вибір моделі важить для реального коду

Цей whiteboard‑челендж показав не лише різницю в швидкості, а й те, як моделі “мислять” щодо стеку й структури проєкту.

Composer 2.5, працюючи у швидкому режимі, одразу обрав React і TypeScript на клієнті та окремий сервер. Це дає розробнику знайому архітектуру, яку легко розширювати: можна додати авторизацію, історію змін, інтеграцію з базою даних чи аналітикою, не змінюючи фундаментальних рішень.

Opus 4.7, навпаки, пішов шляхом простішого JavaScript + CSS без фреймворку та типів. Для маленьких демо‑проєктів це може бути прийнятно, але для реальної розробки в команді та довгострокової підтримки такий стек швидко стає тягарем. Відсутність типів ускладнює рефакторинг, а відсутність React — побудову складних інтерфейсів із передбачуваним станом.

GPT 5.5 показав, що може не лише обрати сучасний стек, а й додати до нього інженерні практики: тести, спільні типи між клієнтом і сервером. Це важливо там, де якість і надійність коду критичні, навіть якщо час генерації більший.

На цьому фоні оцінка автора, що саме реалізація Composer 2.5 виглядала найкращим стартовим варіантом, виглядає логічно. Вона поєднує сучасний стек, робочий стан застосунку й дуже швидкий час отримання результату. GPT 5.5 додає “плюшки” у вигляді тестів, але коштом очікування. Opus 4.7 у цьому конкретному завданні програв і за швидкістю, і за якістю.

Швидкі режими Cursor: коли “fast” і “medium-fast” б’ють по гаманцю

Окремий вимір цього порівняння — вартість. Cursor дозволяє вмикати так званий “max mode”, який відкриває доступ до fast і medium-fast режимів для моделей. Це робить інференс значно швидшим, але й помітно дорожчим.

За словами автора тесту, увімкнення fast або medium-fast режимів у Cursor піднімає ціну за токен приблизно в шість разів. І саме тут виявляється одна з найсуттєвіших переваг Composer 2.5.

При використанні Opus 4.7 у medium-fast режимі загальна вартість виконання завдань може бути приблизно в 20–25 разів вищою, ніж при використанні Composer 2.5 для того ж самого завдання. Це корелює з офіційними даними Cursor: на їхньому внутрішньому бенчмарку середня вартість одного завдання для Composer 2.5 становить близько 0,50 долара, тоді як для Opus 4.7 — близько 7 доларів. Cursor сам підкреслює, що це приблизно 14‑разова різниця в ціні на користь Composer 2.5.

У реальному сценарії з колаборативною дошкою ця різниця посилюється ще й тим, що Opus 4.7 у підсумку не видав робочий застосунок, тоді як Composer 2.5 — так. Тобто розробник не лише платить більше за токени, а й витрачає додатковий час на виправлення або повну перегенерацію рішення.

GPT 5.5 у цьому порівнянні займає проміжну позицію. У тесті він працював у medium-fast режимі й витрачав 10–20 хвилин на завдання, але при цьому видавав робочий застосунок із тестами й спільними типами. Вартість такого запуску вища, ніж у Composer 2.5, але точних цифр у цьому фрагменті не наводиться. Автор припускає, що GPT 5.5, ймовірно, дешевший за Opus 4.7, але все одно суттєво дорожчий за Composer 2.5.

Для розробників це означає, що вибір моделі в Cursor — це не лише питання якості коду, а й прямий вплив на бюджет, особливо якщо активно використовувати швидкі режими. Composer 2.5 у цьому контексті виглядає як “робоча конячка”: швидко, дешево й достатньо якісно для більшості реальних задач.

Коли швидкість важливіша за ще кілька відсотків якості

У синтетичних бенчмарках різниця між моделями часто вимірюється кількома відсотками точності. У випадку Composer 2.5 Cursor сам визнає, що на деяких тестах Frontier‑моделі на кшталт GPT 5.5 або Opus 4.7 можуть показувати трохи кращі результати. Проте в реальних робочих сценаріях ці 2–3 відсотки часто губляться на фоні інших факторів.

Whiteboard‑челендж добре демонструє, що для розробника критично важливі три речі: чи працює застосунок, наскільки він відповідає звичному стеку й наскільки швидко можна отримати перший робочий варіант. У цьому трикутнику Composer 2.5 показав себе як модель, яка дає “достатньо хорошу” якість при значно кращих показниках швидкості й вартості.

GPT 5.5 залишається привабливим вибором там, де важливі тести, сувора типізація й додаткові інженерні практики, навіть якщо це означає довше очікування й вищу ціну. Opus 4.7 у цьому конкретному тесті виглядає найменш привабливо: повільніше, дорожче й без робочого результату.

Цей баланс між “максимальною можливою якістю” та “оптимальною для роботи комбінацією швидкості, ціни й якості” стає ключовим при виборі інструментів для щоденного кодування. І саме тут Composer 2.5, за підсумками цього експерименту, виглядає конкурентним не лише технічно, а й економічно.

Висновок: Composer 2.5 стає серйозним гравцем для щоденного кодингу

Тест із колаборативною whiteboard‑дошкою в Cursor показав, що новий Composer 2.5 — це не просто “ще одна модель” у списку. У реальному завданні він:

помітно перевершив Opus 4.7 за швидкістю,
згенерував сучасний стек на React і TypeScript з окремим сервером,
видав робочий застосунок за 3–4 хвилини в fast‑режимі,
і при цьому коштував на порядки дешевше в перерахунку на завдання.

GPT 5.5 продемонстрував сильну сторону у вигляді тестів і спільних типів, але за ціну довшого часу виконання й вищої вартості. Opus 4.7 у цьому конкретному сценарії виявився повільнішим, дорожчим і менш вдалим з точки зору результату.

Для розробників, які працюють у Cursor і регулярно запускають складні завдання в fast або medium-fast режимах, вибір моделі стає питанням не лише зручності, а й економіки. Composer 2.5 у цьому контексті виглядає як прагматичний дефолт: швидкий, дешевий і достатньо потужний, щоб конкурувати з Frontier‑моделями в реальних проєктах.

Джерело

https://www.youtube.com/watch?v=XOCVdPIhAHg