Кент Бек — одна з ключових фігур у сучасній розробці: автор Extreme Programming, співтворець JUnit, співавтор Agile Manifesto. У розмові на The Pragmatic Engineer Podcast він раптово зміщує фокус із мов і фреймворків на те, що роками вважав «другорядним» — комунікацію, емпатію, вміння витримувати конфлікт і продуктивний дискомфорт. І робить це не з позиції коуча з красивими слайдами, а через власне вигорання, «втрачене десятиліття» та кількарічну програму Good to Great у Facebook.

«Нас обдурили»: коли головною проблемою виявилися не комп’ютери

Бек формулює те, що багато інженерів відчувають, але рідко озвучують: найбільша складність у розробці — не технологічна.

Він описує це як «найбільший космічний практичний жарт». Поколінню, яке погано розуміло людей, але добре тягнулося до машин, пообіцяли простий шлях: «Ось комп’ютер. Якщо повністю зрозумієш комп’ютер — і все буде добре. Це все, що тобі потрібно». Він чесно пішов цим маршрутом: першу частину кар’єри будував як «найкращий програміст, яким тільки можу бути», бо здавалося, що цього достатньо.

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

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

Втрачене десятиліття: слава, крах і урок про кордони

Після буму кінця 90-х і початку 2000-х Бек опинився на піку впливу: Extreme Programming, JUnit, Agile Manifesto, безліч запитів на консалтинг, високі гонорари. Він отримував листи двох типів: «JUnit врятував мені життя», «XP змінив мою кар’єру» — і протилежні: «XP зруйнував моє життя, я втратив роботу, сім’ю, живу на вулиці, це твоя вина».

Ці емоційно полярні реакції стали детонатором кризи. Він описує період після дотком-кризи і 11 вересня як жорсткий злам: усі контракти на наступні місяці скасувалися «наступного дня після 9/11», паралельно потрібно було добудовувати будинок, а разом із замовленнями зник і звичний відгук індустрії.

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

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

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

Good to Great у Facebook: коучинг як каталізатор кар’єрного стрибка

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

Так народилася програма Good to Great. Ідея була простою: працювати з розробниками, які вже «хороші», але «зависли» на плато — накопичують досвід, не перетворюючи його на зростання. Він почав із трьох студентів, проводячи годинні розмови щодня, швидко зрозумів, що це занадто інтенсивно, скоригував формат — і програма почала масштабуватись.

Критичний момент — аналітика, яку зробив HR спільно з адміністраторкою програми. «Я запустив програму Good to Great… і виявилося, що люди, які були моїми студентами, удвічі частіше отримували підвищення у наступний рік, ніж схожа когорта без коучингу», — розповідає Бек.

Коучинг він описує максимально жорстко і чесно:

«Я кажу, що коучи існують, щоб ідентифікувати й індукувати продуктивний дискомфорт».

Це не «погладити по голові», а відверто сказати: «Ти це робиш погано, спробуй так-то, повернись і розкажи, що вийшло». Якщо людина не пробує — робота закінчена. Якщо пробує — з’являється шанс перейти на наступний рівень.

За кілька років через програму пройшло близько 200 людей один-на-один, ще тисячі — через курси, які він писав і передавав іншим інструкторам. До моменту, коли Бек залишав Facebook, він мав уже не лише «студентів», а й «правнуків»: тих, кого вчили люди, яких він колись коучив.

Кульмінаційний штрих — корпоративний offsite із топ-1% інженерів Facebook. «Було offsite з топ‑1% інженерів Facebook… із близько сотні людей десять були моїми колишніми студентами, які доросли до цього рівня». Це практичний доказ того, що м’які навички — не абстракція, а конкретний мультиплікатор кар’єри у висококонкурентному середовищі.

«Я просто казав правду»: як інженери ламають розмови, навіть цього не розуміючи

Окремий пласт розмови — неприємний для багатьох інженерів, але впізнаваний. Бек описує себе як людину на спектрі, з інженерною династією в родині, і дуже тверезо оцінює типові слабкі місця цієї групи.

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

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

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

«Є список відповідей, як у першому “Термінаторі”… але краще мати це випадаюче меню відповідей, ніж зробити щось, що зруйнує розмову до того, як вона завершиться».

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

Коучинг як інженерна задача: продуктивний дискомфорт замість токсичного «фідбеку»

Те, як Бек говорить про коучинг, виразно відрізняється від HR-риторики. Він не підміняє складні розмови «благополуччям» і «комфортом», але жорстко відділяє продуктивний дискомфорт від деструктивного приниження.

У його практиці коуч — це людина, яка:

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

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

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

Чому м’які навички стають ще важливішими в епоху AI

На тлі бурхливого розвитку LLM і дискусій у дусі «coding is going away» Бек займає жорстку позицію: такі тези — від людей, які не розуміють, що таке інженерія. Він відділяє «написання коду» як механічний процес від ширшої діяльності, де одночасно:

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

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

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

Підсумок: межа впливу проходить через людське

У фіналі цієї лінії розмови вимальовуються кілька тверезих висновків.

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

По-друге, коучинг і м’які навички — не «софтова» прикраса до хардових знань, а конкретний важіль кар’єрного зростання. У рамках однієї компанії — Facebook — можна було побачити, як системний коучинг множить шанси на промоушен і виводить людей у топ-1% інженерів.

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

Можливо, найбільш радикальна думка Бека полягає в тому, що тепер це — не опція, а необхідність. Світ, де код усе частіше генерують моделі, залишає інженерам поле, яке поки не здатний зайняти жоден LLM: простір довіри, конфліктів, домовленостей і рішень, прийнятих людьми. І межа реального впливу кожного з нас проходитиме саме тут.

Джерело

Повна розмова з Кентом Беком — на каналі The Pragmatic Engineer:

Кент Бек — легенда інженерії програмного забезпечення. Один із засновників Extreme Programming, автор TDD, співавтор JUnit і підписант Agile Manifesto. У розмові на подкасті The Pragmatic Engineer він з дивовижною відвертістю повернувся до історії народження маніфесту, пояснив, чому сама назва «agile» була помилкою, як рух перетворився на прибуткову, але порожню індустрію «чарівних пігулок» та чому без технічного фундаменту вся ця гнучкість нагадує людину, яку вперше поставили на сноуборд на вершині лавини.

Як народився Agile Manifesto — і чому перше ім’я в списку нічого не означає

Наприкінці 90‑х у професійній спільноті визрів відкритий конфлікт. З одного боку — «дорослий» Rational Unified Process з товстими методичками, інструментами за мільйони доларів і водоспадними практиками. З іншого — група практиків, які вже тоді будували ітеративну, гнучку розробку, але кожен у своєму таборі: XP, Scrum, Feature-Driven Development та інші.

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

Наступний крок — запрошення до Snowbird. Там, у горах, зібралися 17 людей з «здоровими его», як делікатно формулює Бек. Перша частина зустрічі йшла погано: кожен намагався протягнути «своє» в загальний текст, пропозиції суперечили одна одній, напруга росла. Група пішла на перерву, а в кімнаті лишилися Мартін Фаулер і Джим Хайсміт.

Коли всі повернулися, сталося те, що Бек називає «магічним моментом». На стіні вже висів каркас тексту:

«Ми цінуємо це понад те…» — формат протиставлення,
і чотири конкретні пункти — усе це вже було.

Це ядро маніфесту стало тим компромісом, якого не могли досягти у великій кімнаті. Потім група додала принципи. Власний вклад Бека в цю частину мінімалістичний: він пригадує, що єдине слово, яке точно його, — «щоденна» у фразі про щоденну взаємодію з користувачами.

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

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

Але саме тут, на рівні назви, за словами Бека, і було закладено майбутню проблему.

«Agile» як невдала назва: коли марка не захищається

Окрема дискусія в Snowbird точилася навколо того, як назвати новий спільний підхід. Комусь спало на думку слово «agile». Бек був проти й залишається проти досі.

Його ключова претензія: назва не захищається. Формулювання він зводить до простого тесту:

ніхто не скаже: «я не agile, я люблю негнучку (rigid) розробку» або «я прихильник інфлексибл девелопменту».

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

Для контрасту Бек порівнює це з власним брендом Extreme Programming. Він навмисно обрав слово «extreme», щоб відсіяти випадкових: воно звучить різко, з викликом, і передбачає високий бар’єр входу.

У його логіці:

кожен скаже, що він agile, навіть якщо точно ні. Але ти ніколи не назвеш себе extreme‑програмістом, якщо ти ним не є.

«Extreme» натякає на серйозну підготовку — так само, як екстремальні види спорту. Не можна просто вперше стати на сноуборд на вершині лавини. Спершу роки тренувань, досвіду, дослідження ризиків. Лише потім — спуск. Це слово вбудовано стримує самозванців.

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

сьогодні це слово не просто нічого не означає, воно означає вже щось негативне.

Вибух agile-індустрії та «чарівні обіцянки» без техніки

Agile Manifesto був задуманий як спільний знаменник різних підходів. Але дуже швидко навколо нього виросла інша реальність — комерційна індустрія сертифікацій, масштабованих фреймворків, дорогих трансформацій. Те, що часто критикують як «snake oil»: продукт, який обіцяє чудеса, при цьому не розв’язуючи базових проблем.

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

Його головний закид до після‑agile‑світу — спроба продавати організаційну «гнучкість» без інженерного фундаменту. Формула звучить різко:

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

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

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

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

На цьому фоні особливо різко виглядає контраст із частиною комерційної agile‑екосистеми. Бек прямо говорить:

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

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

Коли бренд отруює ідею

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

Причин кілька, і всі вони проглядаються крізь його розповідь.

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

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

По‑третє, агресивний маркетинг. Обіцянки «удвічі більше роботи за половину часу» красиво звучать із трибуни, але в досвіді Бека це ознака саме тієї «snake oil»‑культури, якій він протистоїть. І коли проєкти під цим соусом провалювалися, негатив осідав не лише на конкретних консультантах, а й на самому слові «agile».

Результат — термін, який, за оцінкою одного з його співзасновників, перестав означати щось конкретне й набув негативного відтінку.

Після Agile: що лишається від маніфесту

Попри всю критику назви й індустрії навколо, Бек не відкидає змісту Agile Manifesto. Навпаки, значну частину кар’єри він будував на практиках, які безпосередньо реалізують його принципи: короткі ітерації, тісна взаємодія з бізнесом, прозорість прогресу, відповідальність за якість.

Розрив, який він бачить сьогодні, не між «agile» і «waterfall», а між словами й діями. У його особистому визначенні agile — це «здатність встигати відповісти вчасно». А отже, справжня гнучкість — не сертифікат і не церемонії, а комбінація:

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

Сам Agile Manifesto, в цій оптиці, лишається історичним артефактом і корисним нагадуванням про цінності. Проблема не в тексті й навіть не в тому, що він став популярним, а в тому, як легко прижився ярлик без змісту.

Бек при цьому звертає увагу ще на один урок. Маніфест не з’явився на порожньому місці — він став результатом приблизно 15 років інтенсивної роботи з об’єктно‑орієнтованим програмуванням. Лише після довгого періоду експериментів, успіхів і помилок практики змогли звести спостереження до лаконічного набору принципів.

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

Висновок: чесність замість магії

Історія Agile Manifesto в інтерпретації Кента Бека — це не ностальгія за героїчними часами й не спроба відхреститися від успішного бренду. Це радше спроба відділити те, що працює, від того, як це упакували.

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

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

Джерело

Подкаст The Pragmatic Engineer, випуск «How Kent Beck shapes the software engineering industry»
YouTube: https://www.youtube.com/watch?v=ddHQQtjIOpw

У свіжому випуску подкасту The Pragmatic Engineer легендарний інженер‑практик Кент Бек — автор Extreme Programming, піонер TDD і один з підписантів Agile Manifesto — пояснює, як одна ідея з часів його роботи у Facebook раптом стала ключем до розуміння нинішнього хаосу навколо AI. Йдеться про трьохфазну модель розвитку продуктів: explore, expand, extract. У ній він бачить і пояснення успіху Facebook, і точне формулювання нинішньої кризи в інженерів, які «втратили плейбук» в епоху великих мовних моделей.

Три стани продукту: від випадкових спроб до економії на масштабі

Великий зсув у мисленні Бека стався у Facebook. Там він зрозумів, що успішні технологічні продукти живуть не в одному «режимі розробки», а проходять через три якісно різні стани.

«Великий урок, який я засвоїв у Facebook, був у тому, що є три різні фази розробки ПЗ… фаза дослідження (exploration)… потім щось „злітає“… це expansion… а потім ти дістаєшся витискання цінності (extract)».

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

Коли «ракета запустилася», починається expand. Тут логіка протилежна. «В expansion ти зосереджуєшся на одній речі, яка працює, і долаєш перешкоду за перешкодою», — каже Бек. Компанія перестає розпорошуватися, відкидає альтернативні напрямки й концентрується на масштабуванні того, що вже довело свою цінність. Це може бути напружено, навіть «несталий» темп, але — на короткий період, поки вікно можливостей відкрите.

Після цього приходить extract — фаза витискання цінності й економії на масштабі. «В extract ти досягаєш економії на масштабі», формулює Бек. На цьому етапі:

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

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

20 років у режимі extract — і раптовий обрив

На думку Бека, більшість індустрії останні два десятиліття жила саме в extract‑стані. «20 років ми були в extract‑стані… був плейбук… бути сеньйор‑інженером означало, що ти знаєш плейбук… тепер цей плейбук стертий начисто», — підсумовує він.

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

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

Він описує дуже людський наслідок: «люди, чия ідентичність — „я знаю плейбук“, зараз налякані… хто я такий?… виявляється, навичка писати плейбук зовсім інша, ніж навичка застосовувати плейбук». Інженери, які зробили кар’єру на вмілому застосуванні відомих рецептів, раптом опинилися в світі, де самих рецептів більше немає.

AI відкидає всіх назад у explore — і це не збій, а режим

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

Звідси кілька важливих висновків.

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

По‑друге, цінність зміщується від знання правил до здатності їх створювати. Те, що він бачив у 80–90‑х роках навколо об’єктно‑орієнтованого програмування, було саме написанням плейбука з нуля: експерименти зі Smalltalk, патерни проєктування, поява XP. Тепер, з AI, ситуація повторюється — але в новому технічному контексті.

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

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

Це — колективне написання плейбука, а не споживання вже готового.

Чому зараз не час для «нового маніфесту»

Тема маніфестів неминуче виникає, коли індустрія відчуває великий злам. Якщо був Agile Manifesto для об’єктного світу, чи не потрібен тепер «AI Manifesto» для епохи агентів? Бек відповідає на це дуже жорстко.

Він нагадує часову шкалу: «маніфест agile з’явився в 2001‑му… перший OOPSLA — 1986… це зайняло 15 років, щоб написати цей маніфест». Тобто Agile Manifesto став не початком, а підсумком півтора десятиліть щоденної практики з об’єктно‑орієнтованими мовами, проєктами й збоями. Лише тоді з’явилася можливість стиснути уроки в кілька принципів.

Сьогодні він бачить протилежне: «геній з’явився, і люди питають: „який новий маніфест?“… зараз не час маніфесту… речі ще змінюються дуже швидко, і ніхто не знає, що працює».

Його критерій простий: маніфест має сенс тоді, коли:

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

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

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

Хто виживе в новому циклі: не ті, хто знає, а ті, хто шукає

Наслідки його моделі для кар’єр і компаній доволі прямі. Якщо попередні 20 років винагороджували майстрів extract‑фази, то наступні роки, схоже, нагороджуватимуть:

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

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

У цій картині AI‑агенти — не стільки заміна розробників, скільки каталізатор фази explore, прискорювач експериментів. Те, наскільки ефективно інженери навчаться використовувати це прискорення, і визначить, хто наступним перейде в expand, а потім — знову в extract, уже з новим, спільно написаним плейбуком.

Висновок: епоха інженерів‑авторів

Трьохфазна модель Бека робить нинішній хаос навколо AI менш містичним і більш керованим. Якщо прийняти, що галузь справді повернулася в explore‑стан, багато явищ стають логічними: від нервовості сеньйорів до інфляції маніфестів і методологій.

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

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

Джерело

Подкаст The Pragmatic Engineer — «How Kent Beck shapes the software engineering industry»
https://www.youtube.com/watch?v=ddHQQtjIOpw

Кент Бек — один із тих, хто задавав стандарти для сучасної розробки: Extreme Programming, TDD, JUnit, Agile Manifesto. У розмові в подкасті The Pragmatic Engineer він уже не захищає старі підручники, а намагається чесно розібратися, що робить із професією нова хвиля AI‑інструментів і «геніїв»‑LLM. Його головний діагноз звучить тривожно: ми накопичуємо код швидше, ніж накопичуємо довіру.

Код без довіри: що саме ми втрачаємо, коли промптимо генія

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

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

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

Уся ця багатошарова робота над розумінням і стосунками зникає, якщо процес зводиться до короткого промпта в LLM. Бек карикатурно описує типовий сценарій: ми «даємо промпт генію, отримуємо finger guns, і геній каже: „все закінчено, бос“». Питання «а що саме означає „закінчено“?» лишається у повітрі.

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

LLM пришвидшили розробку — але не пришвидшили бізнес

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

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

Ще гостріше Бек бачить іншу асиметрію: «темп розробки однозначно прискорився… але темп бізнесу не прискорився, і цей дисбаланс ставатиме все очевиднішим». Процеси ухвалення рішень у великих компаніях, ланцюжки від саппорту до продакт‑менеджерів, маркетингу, sales і керівництва нікуди не зникли. Вони як були налаштовані на роки, так роками й мислять.

Бек наводить типовий сценарій: компанія платить 2 мільйони доларів на рік за SaaS‑продукт. Усередині хтось «вайб‑кодить» — швидко збирає заміну, яка краще відповідає специфічним потребам компанії і не коштує 2 мільйони щороку. Питання, яке цікавить Бека: «Як цей вендор буде на це реагувати?».

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

Вендор, теоретично, також може використати LLM, щоб пришвидшити розробку відповіді. Але бізнес‑процес, яким проходить визначення нових потреб, залишився старим, повільним і багатоступеневим. Машина вже стала Ferrari, а кермувати нею продовжують так, ніби це трактор.

Вайб‑кодинг і айсберги: чому заміна SaaS — це пастка

Бек фіксує ще одну тенденцію: люди почали масово «вайб‑кодити» верхівку айсберга, не бачачи, що під водою. І це загрожує серйозними «даунстрімними» проблемами.

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

Ілюзія контролю виникає миттєво: «ось, у мене є код, він робить те, що я бачу, все працює». На цій хвилі ентузіазму люди «викидають решту айсберга» — тобто ігнорують частину системи, яка не на поверхні. Бек описує наслідок: «люди вайб‑кодять вершину айсберга, викидають решту айсберга і потім мають проблеми… ти отримуєш ці даунстрімні проблеми, про які навіть не знав».

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

Бек наводить ситуацію з домену, який добре знає: у сфері payroll. Людина запитує LLM: у мене стільки‑то годин, така‑то ставка, ось податкова категорія — порахуй зарплату. Модель видає відповідь, і користувач робить висновок: «я не потребую спеціалізованого сервісу, я сам можу вести payroll». Бек пропонує експеримент: спробуйте таким чином прожити хоча б квартал, а потім розібратися з усіма формами й звітами для різних податкових органів, штатів чи країн. Те, що здається верхівкою айсберга (брутто та нетто зарплати), насправді спирається на величезну приховану масу правил і обов’язків.

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

Коли «геній» каже «готово» — а ніхто не знає, що це означає

У центрі критики Бека — саме інтерфейс взаємодії з LLM як із «генієм, що виконує бажання». Історія з «finger guns» — більше ніж жарт; це опис психології взаємодії.

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

Бек формулює це питання дуже прямо: «ми накопичуємо код швидше, ніж ми накопичуємо довіру… і нічого з цього не відбувається, якщо ми просто промптимо, отримуємо finger guns, і геній каже: „все закінчено, бос“. А що значить „закінчено“?».

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

Бек не стверджує, що LLM‑и не можна або не треба використовувати. Він говорить про інше: якщо професія дозволить собі приймати «готово» від моделі, не переосмисливши, як тепер має будуватися довіра до системи, конфлікт між швидкістю коду й швидкістю довіри лише зростатиме.

Дисбаланс, який ставатиме все очевиднішим

Підсумовуючи свій погляд, Бек описує картину, в якій одночасно діють кілька сил.

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

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

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

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

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

Джерело

How Kent Beck shapes the software engineering industry

Коли в індустрії кібербезпеки говорять про Q‑Day — момент, коли квантові комп’ютери стануть «криптографічно релевантними» і зможуть зламувати нинішні системи шифрування, — зазвичай йдеться про ризики. В подкасті IBM Security Intelligence про це говорили керівники кібербезпекового напряму IBM Марк Г’юз та Суджа Вісвесан. Але в тій самій розмові прозвучала й інша, не менш важлива лінія: квантові обчислення водночас несуть і фундаментальні можливості — від нових фінансових стратегій до персоналізованої медицини.

Як Shor’s Algorithm ламатиме сучасну криптографію

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

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

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

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

Шифрування під загрозою — чому це не вся історія про квант

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

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

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

Фінансові ринки: квант як двигун складних стратегій

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

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

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

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

Квант і природничі науки: від білків до персоналізованого лікування

Ще одна область, де очікування особливо високі, — природничі науки. Г’юз говорить про «весь спектр навколо природничих наук і природного світу, як ми можемо емітувати природний світ», а особливо — про «життєві науки й медичні застосування».

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

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

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

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

Тихий прогрес: квант уже у хмарі й в науці

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

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

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

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

Між загрозою і проривом

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

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

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

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

Джерело

YouTube: The new post-quantum cryptography executive order. Plus: What is Q-Day, really?

Постквантовий перехід уже вийшов за межі урядових документів і наукових статей: для великого бізнесу це стає довгостроковою програмою змін. У подкасті IBM Security Intelligence віцепрезидентка з продуктової безпеки Suja Viswesan та глобальний керівник Cybersecurity Services Mark Hughes детально розбирають, що означає «crypto agility» на практиці і як будувати до неї системну дорожню карту.

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

Чому «старих практик» уже недостатньо

Кібербезпека сьогодні одночасно переживає дві хвилі: стрімкий розвиток ШІ та поступовий вихід квантових обчислень на «криптографічно релевантний» рівень. За словами Марка Г’юза, у фундаментальних речах кіберзахисту мало що змінюється — але змінюється темп.

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

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

Старт із прозорості: чому discovery важливіший за алгоритми

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

Марка Г’юза це формулює прямо: «Просто дійти до точки discovery — це дуже важливий крок у всьому цьому. Це взагалі не про якісь складні алгоритми. Це про те, щоб почати з питання: що у вас уже є і що ви знаєте про сьогоднішній стан?»

Йдеться не лише про сертифікати TLS на периметрі. Потрібно бачити:

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

Коли цього огляду немає, будь-який подальший «перехід на PQC» ризикує звестися до точкових латок і непередбачених збоїв на стику систем. Г’юз окремо підкреслює вимір ланцюга постачання: навіть якщо у вас усе модернізовано, але ваші партнери змінюють криптографію, а ви — ні (або навпаки), на вас чекають проблеми з сумісністю.

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

Від «проєкту» до циклу: п’ять етапів трансформації

Suja Viswesan наголошує: ставитися до постквантового переходу як до чергового великого ІТ‑проєкту — помилка. «Це не “project project”. Це трансформація», — підкреслює вона.

Вона описує безперервний цикл із п’яти кроків, який має стати новою нормою:

1. Strategize – спочатку стратегія
   Потрібно врахувати одразу кілька площин: апаратне забезпечення, програму, мережі, а також постачальників. Якщо якийсь ключовий вендор не планує бути постквантово готовим, це для вас вже міграційний сценарій, а не косметичне оновлення. Сюди ж входить планування апаратних оновлень і політик щодо сертифікатів.

2. Assess – оцінювання й discovery
   Це той самий етап прозорості, про який говорить Г’юз. Виявити всі сертифікати, алгоритми, ключі, залежності в коді й продукти третіх сторін. Без оцінки немає адекватних пріоритетів.

3. Modernize – модернізація
   На основі стратегії та карти активів формується план модернізації: де, як і в якій послідовності оновлювати криптографію, як змінювати процеси керування ідентичностями, як вплітати нові алгоритми у вже існуючі протоколи.

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

5. Remediate – виправлення, коли настане день
   Коли алгоритми, стандарти та рекомендації остаточно формалізуються, організація має бути в стані швидко й контрольовано переформатовувати свою криптографію. «Коли альґоритми будуть доступні, ви маєте бути готові бути agile і remediate. І цикл продовжується», — пояснює вона.

Цей цикл не має «кінцевої дати». Візвесан прямо говорить, що це коло, яке постійно обертається: strategize – assess – modernize – govern – remediate – і знову спочатку.

Crypto agility як ціль: криптографія за моделлю оновлення ПЗ

Фінальна мета цього циклу — стан, який співрозмовники називають crypto agility. Suja Viswesan дає просте, але показове визначення: «Crypto agility — це здатність змінювати вашу криптографію так само легко, як оновлення програмного забезпечення».

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

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

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

Для багатьох ІТ‑керівників ця перспектива виглядає незвичною і навіть дискомфортною: «Це не “зробив і забув”. Це тривалий, постійний процес crypto agility… Дехто сприймає це непросто, бо це про постійну зміну». Водночас він бачить у цьому й «велику можливість» — відмовитися від статичності, яка дедалі гірше узгоджується з реальністю ШІ та квантових обчислень.

Архітектура майбутнього: відв’язати криптографію від застосунків

Щоб crypto agility стала реальною, її потрібно закладати в архітектуру ще на стадії проєктування. Тут Suja Viswesan окреслює кілька принципових вимог до майбутніх систем.

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

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

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

І нарешті, необхідні чіткі правила управління. Візвесан говорить про «чисте управління», коли зміни відбуваються систематично, а не як відповідь на локальні інциденти чи зовнішні вимоги.

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

IBM як «лабораторія crypto agility»: власний шлях і уроки

У розмові прозвучав і важливий момент: великі постачальники технологій проходять цей шлях паралельно зі своїми клієнтами. Suja Viswesan наводить приклад самої IBM: компанія «просканувала тисячі репозиторіїв, мільйони рядків коду, вибудовуючи cryptographic bill of materials».

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

Фактично великі гравці стають полігоном для відпрацювання практик crypto agility на складних, об’ємних кодових базах — із усіма типовими проблемами, які мають і великі замовники: історичний техборг, старі алгоритми, залежності, вимоги до безперервності сервісів.

Час стартувати раніше, а не бігти швидше

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

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

Її висновок лаконічний: «Для мене переможцями стануть не ті, хто рухається найшвидше, а ті, хто починає раніше». Запізнілий старт означає роботу в умовах дедлайнів, регуляторного тиску, вимог великих партнерів і високих витрат. Ранній — дозволяє розподілити трансформацію в часі й перетворити crypto agility на природне продовження еволюції ІТ‑ландшафту, а не на антикризовий захід.

Висновок: crypto agility як новий стандарт безпеки

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

Звідси й зсув парадигми: від точкових міграцій до безперервного циклу strategize–assess–modernize–govern–remediate. В основі цього циклу — прозора інвентаризація, архітектури, в яких криптографія є сервісом, а не «вшитим» модулем, автоматизовані життєві цикли сертифікатів та кероване управління.

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

Джерело

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

У подкасті Security Intelligence від IBM Technology віцепрезидентка з продуктів безпеки Суджа Вісвесан та глобальний керівник напряму кібербезпеки Марк Г’юз обговорюють, що насправді стоїть за терміном Q‑Day і чому чекати «чорного дня квантового хаосу» — небезпечна ілюзія. Розмова виходить далеко за межі технічних деталей: йдеться про довгі життєві цикли даних, тактику «harvest now, decrypt later» та те, чому справжнім вузьким місцем стане не технологія, а виконання.

Q‑Day — не Y2K: загроза, яка приходить хвилями

У масовій уяві Q‑Day часто подають як конкретну дату, коли квантовий комп’ютер зламає публічні криптографічні системи, і все «раптово впаде». Такий образ зручний, але хибний.

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

Вісвесан підкреслює: Q‑Day — це не точка в часі, а процес, який «приходить хвилями, а не шоками». Причина в тому, що криптографія — це невидимий «будівельний ліс» сучасного софту: вона пронизує апаратне забезпечення, облікові дані, сертифікати, PKI‑інфраструктуру. Коли квантові обчислення зламають ключові криптографічні припущення, змінювати доведеться не один компонент, а весь цей шар.

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

«Harvest now, decrypt later»: дані вже крадуть із розрахунком на квантовий прорив

Поки дискусія про Q‑Day триває, зловмисники не чекають календарної позначки. У першій частині епізоду керівник напряму кіберполітики IBM Мейсон Молеські звертає увагу на тенденцію, яка вже спостерігається: зловмисні актори активно збирають зашифровані масиви даних.

Цю тактику називають «collect now, decrypt later» або «harvest now, decrypt later» — збирай зараз, розшифровуй потім. Логіка проста: якщо дані мають довгий строк життя, їх можна вкрасти вже сьогодні, зберігати зашифрованими, а коли потужні квантові машини стануть практично доступними — повернутися і розшифрувати.

Йдеться не лише про державні секрети. Молеські наголошує, що під загрозою:

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

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

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

У цій логіці квантовий прорив у криптоаналізі автоматично «активує» архіви даних, викрадених задовго до того. Саме тому розмову про Q‑Day Вісвесан називає подорожжю, яке необхідно починати заздалегідь.

Минулі криптопереходи ще не завершені — а новий уже на порозі

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

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

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

На цьому тлі очікування умовного «2040» як комфортного дедлайну виглядає небезпечно самозаспокійливим. Історичний досвід підказує: криптоперехід не вкладається в короткі календарні цикли.

Головний вузол — не алгоритми, а виконання

У популярних розповідях про постквантовий світ увага часто прикута до нових криптоалгоритмів і конкурсу NIST. Вісвесан пропонує змістити фокус: проблема не лише технологічна, а радше організаційна.

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

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

Особливо це відчутно на фоні зростання «нелюдських ідентичностей» — машинних облікових записів, сервісних акаунтів, мікросервісів, які взаємодіють між собою. Співвідношення таких ідентичностей до людських, за її словами, за кілька років стрибнуло з «20 до 1» до «десятків і навіть сотень до однієї». Кожна така ідентичність пов’язана з ключами, сертифікатами, секретами — і всі вони теж підпадають під квантовий ризик.

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

Чому виграють не ті, хто «біжить швидко», а ті, хто починає рано

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

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

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

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

Від «великого проєкту» до безперервної криптоагільності

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

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

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

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

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

Висновок: Q‑Day уже почався — як процес, а не як дата

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

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

По‑друге, загроза «harvest now, decrypt later» означає, що для довгоживучих даних Q‑Day фактично починається вже сьогодні, незалежно від того, коли саме з’являться практичні квантові машини.

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

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

У такій оптиці питання для бізнесу звучить не «коли настане Q‑Day», а «на якому етапі цього багаторічного процесу ми хочемо опинитися — серед тих, хто встигає на ранніх хвилях, чи серед тих, хто задихатиметься в останній?».

Джерело: The new post-quantum cryptography executive order. Plus: What is Q-Day, really?

22 червня у США вийшло рішення, яке навряд чи помітить пересічний користувач, але яке може визначити архітектуру глобальної безпеки даних на десятиліття. Йдеться про новий указ президента США Дональда Трампа щодо постквантової криптографії. У подкасті IBM Security Intelligence його зміст і наслідки детально розібрав Мейсон Молеські, керівник напряму кіберполітики IBM, що відповідає, зокрема, за постквантову криптографію.

Указ формально стосується федерального уряду США, але закладає рамку для всього ринку: від постачальників технологій до критичної інфраструктури та міжнародних партнерів. Фактично це перехід від «усвідомлення ризику» до обов’язкових дій.

Від визнання квантової загрози до обов’язкових дій

За оцінкою Молеські, новий документ — це етап у багаторічній політиці Сполучених Штатів, спрямованій на підготовку до епохи квантових комп’ютерів:

«Президент Trump signed an executive order on post-quantum cryptography, which is just the latest development in a decade long US government policy effort to address this transition from modern day encryption to new encryption that is not susceptible to attacks from quantum computers».

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

«This particular executive order represents the US government’s transition from recognizing quantum risk to really mandating coordinated actions and efforts… through establishing clear accountability, clear timelines and enforcement, to ensure our information and data is protected».

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

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

Хто керує переходом: архітектура відповідальності у Вашингтоні

Указ чітко розподіляє ролі між ключовими органами виконавчої влади США. Молеські описує це так:

«It establishes first… that the Office of Management and Budget… as well as the national cyber director in the White House are going to lead this strategy… as well as technical guidance to be coming from our National Institute of Standards and Technology, our National Security Agency and our Cybersecurity and Infrastructure Security Agency».

Фактично формується двошарова модель управління.

На політичному й стратегічному рівні:

• Офіс з управління та бюджету (Office of Management and Budget), де розміщується федеральний CIO, відповідає за інтеграцію постквантового переходу в загальну ІТ‑ та бюджетну політику уряду.
• Національний директор з кібербезпеки в Білому домі отримує мандат координувати загальну стратегію і міжвідомчу взаємодію — що підкреслює рівень політичної ваги питання.

На технічному рівні:

• Національний інститут стандартів і технологій (NIST) продовжує задавати криптографічні стандарти.
• Агентство національної безпеки (NSA) і Агентство кібербезпеки та безпеки інфраструктури (CISA) відповідають за технічні рекомендації та застосування стандартів у сфері нацбезпеки та критичної інфраструктури.

Окремо указ вводить принцип персональної відповідальності в кожному федеральному відомстві:

«It asks for agencies to appoint a lead for post-quantum cryptography migration efforts, so that the White House specifically knows who to go to… and who to hold accountable for these efforts across the federal government».

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

Прискорення дедлайнів: чому переносять «точку безвідкличності»

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

«2035 was kind of an agreed upon date generally with the US government before this new executive order accelerates that up to end of 2030 and then the 2031».

Тобто приблизний орієнтир «бути quantum‑safe до 2035 року» замінюється новими рамками — кінець 2030‑го та 2031 рік. Ці дати вказують на прискорення щонайменше на кілька років.

Це рішення ґрунтується на двох практичних спостереженнях, які Молеські теж озвучує в розмові:

перше — це довгі життєві цикли чутливих даних. Частина інформації (наприклад, медичні записи або деякі фінансові дані) повинна залишатися конфіденційною десятиліттями. Якщо її перехоплять сьогодні у зашифрованому вигляді, майбутній квантовий комп’ютер потенційно зможе її розшифрувати. Це відомий підхід «harvest now, decrypt later», який, за словами спікера, уже спостерігається в поведінці зловмисних акторів.

друге — це інерційність криптографічних міграцій. Сам Молеські нагадує, що навіть попередні переходи між алгоритмами тривали роками й досі не завершені повністю. Якщо врахувати, що квантовий ризик може стати практичним уже в цьому десятилітті, дедлайн у 2035 році виглядає занадто оптимістичним. Перенесення орієнтирів на 2030–2031 роки — визнання того, що для масштабної заміни криптографії потрібен запас часу.

Нові дати створюють жорсткий сигнал не лише для федеральних структур, а й для всіх, хто так чи інакше працює з урядом США. Вікно «комфортного очікування» суттєво звужується.

Вплив на ринок: від федеральних агентств до всього ланцюга постачань

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

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

«The US government’s going to be updating its acquisition regulation so that government or federal contractors are required to comply as well… they’re looking to streamline and enable this in the marketplace».

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

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

По‑друге, указ прямо адресований критичній інфраструктурі США: від енергетики й водопостачання до фінансів і охорони здоров’я. У документі, як передає Молеські, ставиться завдання для CISA та так званих «sector risk management agencies» — профільних органів для окремих галузей, як‑от Міністерство охорони здоров’я — працювати з операторами інфраструктури й підтримувати їх у переході.

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

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

США хочуть, щоб в ідеалі світ використовував ті самі стандарти, передусім розроблені NIST у співпраці з міжнародною спільнотою. Молеські наголошує: це потрібно заради інтероперабельності — щоб обмін даними між країнами був зрозумілим і безпечним на технічному рівні.

Глобальний контекст: «світ колективно рухається до безпеки»

Указ Трампа не виник у вакуумі. Молеські описує ширшу картину: постквантова криптографія поступово стає темою національної політики в різних країнах.

«A dozen or so governments worldwide updated post-quantum cryptography policies last year, another dozen or so created new ones. We’re seeing sector guidance already start to come out. So collectively, the world is kind of moving towards ensuring the security».

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

Молеські описує свій підхід до роботи з урядами трьома словами: «plan, act, motivate» — планувати, діяти, мотивувати. Указ США, за його логікою, маркує перехід якраз від планування до активної фази. Він ставить завдання не лише продумати дорожні карти й інтегрувати постквантову криптографію в національні стратегії, а й:

• запускати пілоти вже наступного року, щоб швидко отримати уроки міграції;
• встановлювати чіткі терміни переходу (2030–2031 для федерального сектору);
• масштабувати успішні кейси з державних структур на критичну інфраструктуру.

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

Що це означає для решти світу

Хоч указ написаний під федеральну систему США, його наслідки будуть відчутними далеко за межами американської адміністрації.

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

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

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

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

Висновок

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

Чи стане цей крок каталізатором для інших урядів і компаній у світі — показують уже перші ознаки: десятки країн переглядають свої підходи, з’являються галузеві рекомендації, а термін «post‑quantum cryptography» виходить із вузького кола експертів у ширший регуляторний та бізнес‑лексикон.

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

Джерело

YouTube, IBM Technology — The new post-quantum cryptography executive order. Plus: What is Q-Day, really?

Google NotebookLM отримав помітне оновлення: у сервісі з’явився режим коротких відеооглядів, який з однієї кнопки перетворює нотатки на вертикальні освітні ролики з анімацією, закадровим голосом та зображеннями. Огляд можливостей і обмежень новинки опублікував канал Futurepedia.

Як працюють короткі відеоогляди в NotebookLM

Новий формат описують формулою «думе-скролінг, але освітній». Ідея проста: користувач обирає зошит у NotebookLM, заходить у панель Studio та натискає «Video overview». Для платних акаунтів доступні три режими: cinematic, explainer і новий short. У безкоштовній версії залишаються explainer та short.

У режимі short система сама пропонує кілька варіантів фокусу для відео — міні-теми з ваших джерел. Можна:

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

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

Обмеження за кількістю: у безкоштовному плані — до 3 коротких відео на день, у Pro — до 20.

Що саме генерує NotebookLM: структура, голос, анімація

Короткі відео мають стандартну структуру, орієнтовану на вертикальні формати на кшталт TikTok і Reels:

• Хук на перші секунди — одна фраза, що чіпляє:
  наприклад, «Твоя ранкова кава — це не просто заряд енергії. Це потужний біологічний модулятор, який активно переписує роботу твого тіла».
• Пояснювальна частина — стислий, але логічний виклад теми; тривалість одного ролику зазвичай 1–1,5 хвилини.
• Візуальний ряд — поєднання анімацій, статичних зображень і простих моушн-ефектів.

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

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

За зображення відповідає нова модель Nano Banana 2 Lite. Вона орієнтована на швидкість і вартість: середній час створення картинки – близько 4 секунд.

Сильні сторони: від наукових пояснень до креативних форматів

Нова можливість найбільш переконливо виглядає в освітніх сценаріях — як інструмент для стислих пояснень складних тем.

Серед продемонстрованих прикладів:

• Фізика та геологія — детальний, але доступний ролик про те, як протягом століть у породі накопичується напруга, що зрештою призводить до землетрусів.
• Антропологія та історія — історія народу рарамурі з книги Born to Run, де показують, як географія каньйонів сформувала унікальний спосіб життя та біг.
• Економіка — відео про фінансові бульбашки з візуалізацією графіків, зокрема про «залізничну манію» у Великій Британії.
• Технології та енергоспоживання — пояснення парадоксу Джевонса: що відбувається, коли здешевлення обчислювальних ресурсів призводить до вибухового зростання попиту.
• Нейронаука та психологія — ролики про фантазію та атипову візуалізацію (афантазію), де умовні сигнали між фронтальними зонами мозку та візуальною корою подаються через образи й метафори.
• Анімація та кіно — міні-лекція про еволюцію 3D-анімації та принцип збереження об’єму: як одночасне стискання по вертикалі й розтягування по горизонталі створює ілюзію еластичних об’єктів.

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

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

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

Обмеження: контроль стилю, помилки в кадрі й відсутність редагування

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

Слабкий контроль над стилем і тривалістю

Попри те, що система дійсно володіє ширшим спектром стилів, користувач наразі майже не може ними керувати:

• запити на кшталт «зробити в стилі пластилінової анімації» або «аніме» ігноруються;
• прохання про «whiteboard explainer» не перетворюються на фірмовий формат малювання на дошці;
• спроби задати жорстку тривалість (наприклад, «менше 30 секунд») практично не впливають на довжину: ролику все одно виходять близько хвилини з лишком.

Фактично користувач найбільше впливає зараз лише на:

• тему (який аспект зошита обрати);
• кут подачі (наприклад, «як детективна історія» чи «як вступний гайд»).

Решта — голос, загальний візуальний стиль, темп — залишаються переважно на розсуд моделі.

Нерівна якість зображень та дрібні артефакти

Більшість згенерованих відео виглядає цілісно, однак трапляються типові для генеративної графіки збої:

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

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

• замінити окреме зображення;
• виправити текст;
• перегенерувати лише частину ролику.

Єдиний варіант — згенерувати відео наново, що не завжди дає кращий результат і споживає добовий ліміт.

Нерівномірність анімацій

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

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

Потенціал і напрямок розвитку

У нинішньому вигляді короткі відеоогляди в NotebookLM найбільш логічно розглядати як:

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

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

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

Джерело

Огляд функції коротких відеооглядів у NotebookLM:
https://www.youtube.com/watch?v=_8DHTnjb2ho

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

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

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

«Наступне десятиліття визначатимуть компанії “з однієї людини”, які генеруватимуть понад мільйон доларів річного доходу — тому що кожен індивід фактично отримає необмежену робочу силу», — сказав засновник і CEO OKX Стар Сюй (Star Xu) в коментарі TechCrunch. — «Традиційна фінансова інфраструктура створювалася для людей. Агентна економіка потребує інфраструктури, спроєктованої для автономного софту. Саме тому ми створили OKX.AI».

Хайдер Рафік (Haider Rafique), директор з маркетингу та глобальний керівний партнер OKX, зазначив, що компанія вважає: «агентна комерція» може перетворитися на ринок обсягом у трильйон доларів протягом наступних п’яти років, підживлюваний мікроплатежами та автономним ПЗ.

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

Серед перших партнерів — CertiK, сервіс якої дозволяє AI-агентам оцінювати безпеку криптогаманця або токена перед виконанням транзакції, а також CoinAnk, що надає дані про ринок у режимі реального часу за моделлю оплати «за запит». Ще один партнер запуску, GenLayer, привносить у маркетплейс інфраструктуру вирішення спорів, щоб допомагати AI-агентам розв’язувати договірні конфлікти.

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

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

Запуск OKX відбувається на тлі гонки технологічних компаній та стартапів за створення інфраструктури для AI-агентів — від платформ для розробників та маркетплейсів до платіжних та ідентифікаційних систем. Альберт Кастельяна (Albert Castellana), співзасновник і CEO GenLayer Labs, каже, що найбільший виклик полягає не лише в тому, щоб дати AI-агентам можливість проводити транзакції, а й у тому, щоб допомогти їм знаходити один одного та вирішувати спори, коли щось іде не так.

«По суті, ми будуємо цифрову судову систему», — сказав Кастельяна в коментарі TechCrunch. — «Наш головний виклик — дистрибуція. У OKX вона вже є».

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

У березні Intercontinental Exchange (ICE), материнська компанія Нью-Йоркської фондової біржі (NYSE), інвестувала близько 200 млн доларів в OKX, оцінивши її в 25 млрд доларів. За словами Рафіка, це партнерство є частиною амбіцій компанії «модернізувати ринки» завдяки токенізації, тоді як OKX AI — паралельна спроба «модернізувати гроші» для епохи автономного ПЗ.

Розробники отримують доступ до маркетплейсу через Onchain OS — набір інструментів OKX для підключення AI-агентів до блокчейн-сервісів. У компанії зазначають, що для старту не потрібен акаунт OKX, а платформа сумісна з інструментами AI-програмування, серед яких Claude Code, Codex, Hermes і OpenClaw.

Оскільки маркетплейс насамперед орієнтований на розробників, а не роздрібних користувачів, Індія посідає важливе місце в планах OKX. Країна стала одним із найбільших у світі хабів для AI та блокчейн-розробників — спільноти, до якої компанія прагне достукатися ще до потенційного ширшого повернення свого криптотрейдингового бізнесу.

Джерело

TechCrunch

Компанія Shark представила новий пилосос PowerDetect під назвою Transformer — тому що він може перетворюватися на три різні типи пилососів. Базова конфігурація — це вертикальний пилосос із великою колбою, прикріпленою до корпусу. Колбу можна від’єднати (судячи з опису, одним кліком), перетворивши пристрій на вертикальний «стік»-пилосос, який легше підлізає в важкодоступні місця. Також можна зняти трубу й приєднати одну з насадок, щоб отримати ручний пилосос.

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

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

У стік- і ручному режимах використовується менша колба біля рукоятки, куди потрапляє сміття під час роботи. Коли прибирання завершено, достатньо зібрати Transformer назад у вертикальний пилосос — і цей менший контейнер автоматично спорожниться у більший. Тобто не потрібно окремо висипати пил із двох ємностей.

Shark PowerDetect Transformer вже доступний на сайті компанії та в її TikTok-магазині за ціною 529 доларів. За 650 доларів пропонується комплект із додатковими інструментами й насадками для домівок із домашніми тваринами.

Вертикальні пилососи, що перетворюються на стік, нині не рідкість, але система з трьома форматами у Shark досить незвична. Водночас минулого року Eufy також випустила трансформований пилосос — робот, який може ставати стік- та ручним пилососом.

Джерело

Engadget

App Store давно став тихим, але вагомим джерелом доходу Apple. Щоразу, коли власник iPhone оформлює підписку через платіжну платформу Apple, компанія з Купертіно забирає до 30% з кожного регулярного платежу. Практика настільки агресивна, що суд зобов’язав Apple дозволити сторонні платіжні системи, а торік той самий суд визнав компанію винною в неповазі до суду за порушення цього рішення, коли вона ввела аналогічну плату для розробників, які реалізують власні інструменти білінгу.

Втім, розробники додатків підлаштувалися під «комісію Apple» ще задовго до судових рішень. Замість того, щоб миритися з втратою 15–30% доходів від підписок, багато хто просто переклав ці витрати на користувачів, підвищивши ціну підписок, оформлених через App Store. Сервіс, що коштує $10 на сайті компанії, у магазині Apple може продаватися вже за $13. Це явище отримало неофіційну назву «податок Apple».

YouTube Premium — один із показових прикладів. Раніше зазначалося, що деякі користувачі можуть замінити наявні музичні підписки на YouTube Premium, але ситуація змінюється, якщо оформлювати її через App Store. Якщо подивитися на ціни YouTube Premium, видно, що Google також закладає «податок Apple». При оформленні підписки через сайт YouTube вартість індивідуального тарифу становить $16 на місяць. Але якщо оформлювати через App Store, ціна зростає до $21 на місяць. Тобто додаткові $5 щомісяця ви платите лише для того, щоб Google компенсував комісію Apple — і це ускладнює завдання отримати максимальну користь від підписки YouTube Premium.

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

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

Попри це, завжди варто економити, де можливо. На щастя, у випадку з YouTube Premium відмовитися від підписки через власну платіжну систему сервісу досить просто. Процес скасування відносно прозорий, і Google не чинитиме особливих перешкод, якщо ви вирішите перестати платити. Якщо зараз ви переплачуєте за YouTube Premium через App Store або тільки планували оформити цю підписку, вигідніше зробити це напряму, оминувши «податкового збирача» біля воріт обгородженого садка Apple.

Джерело

Engadget

Компанія Proton, відома своїми орієнтованими на приватність продуктами для продуктивності, торік запустила публічний AI-чатбот Lumo. У вівторок сервіс отримав велике оновлення.

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

Версія 2.0 розширює й можливості Lumo для роботи з Projects — віджетом, який дозволяє завантажувати документи та виконувати завдання через інші продукти Proton, такі як електронна пошта та хмарне сховище. У Projects з’явилася керована користувачем постійна пам’ять — функція, що дозволяє Lumo запам’ятовувати вподобання користувача між різними сесіями спілкування.

Окрім цього, у Proton стверджують, що оновлення зробило Lumo значно потужнішим за попередню версію. Lumo 2.0 відповідає на більшість запитів до 76% швидше, ніж раніше. Також у чатботі з’явився новий «режим мислення» для більш складних завдань і запитань.

«Lumo 2.0 було повністю переосмислено, а запровадження режиму мислення надає йому потужні нові можливості», — сказав засновник і CEO Proton Енді Йен. — «Lumo 2.0 демонструє, що користувачам більше не потрібно обирати між потужними AI-можливостями та реальним захистом приватності».

Публічна версія Lumo за своєю корисністю загалом відповідає іншим великим чатботам. Вона відповідає на запитання у схожому форматі до Gemini та ChatGPT, із приблизно таким самим рівнем деталізації та контексту.

Втім, Proton відрізняє Lumo від інших чатботів саме підходом до конфіденційності. Сервіс використовує так звану архітектуру з нульовим доступом (zero-access encryption), яка шифрує дані користувачів під час передачі та у стані зберігання й надає доступ лише самому користувачеві. Компанія також заявляє, що серверні логи сесій не зберігаються, тож ніхто в Proton не може бачити зміст розмов. Proton обіцяє ніколи не використовувати дані клієнтів для навчання AI та не передавати їх третім сторонам.

Lumo 2.0 вже доступний. Окрім безкоштовної публічної версії, Proton пропонує платні тарифи Plus і Professional, які надають значно більше лімітів і ресурсів.

Джерело

TechCrunch