Без маркетинга и успешного успеха. Только боль, костыли и суровый прод! Мой пет-проект - бот «Щёлк-ГДЗ». Это ИИ-помощник, который решает школьные задачки по фоткам, видео, гс, тг-кружкам и PDF. Под капотом Python 3.12.3, aiogram 3, aiosqlite, апи OpenRouter (модель Gemini 3.0 Flash) и Робокасса. Крутится всё это на дешёвом VPS в Нидерландах. Держит 2500+ пользователей и не падает.

В этой статье расскажу, как за 9 месяцев построил логичную архитектуру, победил ошибку FloodWait при стриминге ответа ИИ и почему в условиях 1 гига RAM обычная SQLite - отличное решение.

Нейронка вместо джуна и Уроборос багов

Сразу признаюсь... С нуля я это не писал :) Синтаксис мне генерили LLM-ки. Начинал с Gemini 2.5 Pro, затем перешел на 3.0 Pro, а сейчас использую 3.1 Pro.

Многие думают, что нейронка сама напишет проект "под ключ", но это миф. Я никогда не доверял ИИ проектирование архитектуры и использовал его как продвинутый StackOverflow (скармливал конкретную задачу (например, написать SQL-миграцию) и получал кусок кода).

ИИ — это не архитектор, а джун на спидах.

Как только логика усложнялась - гемини ловил «Уроборос багов». Кидаешь баг А - он его фиксит, но появляется ошибка Б. Скармливаешь и её - фиксит, но возвращается баг А. Цикл замкнулся. Лечилось только созданием новых чатов, в которые я кидал код и писал запросы типа "Найди критические ошибки, логические дыры и баги".

Про продуктовую логику нейронка вообще не слышала. В первой версии рефералки был баг, где любой(если его аккаунта ещё нет в БД) мог написать в конце ссылки что любые 9 цифр (?start=1234567890) и получить бонусы.

Также были ошибки с гонкой состояний при оплатах и активациях промокодов, которые тоже фиксил запросами в новые чаты с ИИ. Так я исправил около 20 архитектурных дыр.

Немного про архитектуру.

Чтобы код не превратился в нечитаемую лапшу на 5000 строк, я жестко разбил всё на модули. Архитектура бота выглядит так:

main.py - это точка входа с настройкой логгеров, коннетами aiohttp и запуском APScheduler

database.py - вся работа с БД

neiro.py - логика общения с апи OpenRouter (стриминг, сжатие фоток через Pillow, JSON-контекст)

states.py - классы состояний aiogram.fsm.state (например, PaymentProcess, GdzMode)

utils.py - легковесные утилиты. Например лок пользователей (защита от спама запросами):

Хэндлеры вынесены в отдельную папку handlers/:

handlers/common_handlers.py - главное меню с обработкой /start (рефералки, utm-метки).

handlers/gdz_handlers.py - сам процесс ИИ-решения (вход в GdzMode, прием фото, видео, кружочков).

handlers/pay_handlers.py - это логика платежей (Robokassa) и "Умная корзина".

handlers/tasks_handlers.py - квесты (выдача премиума за подписку на каналы спонсоров).

Сборку интерфейсов вынес в all_def.py. Не люблю, когда в хэндлерах генерится полотно текста с кнопками. Там же лежат функции склонения слов (1 запрос, 2 запроса, 5 запросов). А в settings.py лежат списки с рандомными ответами бота, чтоб казался живым.

Так же в settings.py я сделал кэширование картинок, тоесть при первом запуске бот грузит фото меню как BufferedInputFile, сохраняет file_id от Телеграма и дальше шлет картинки моментально по ID. Сервак говорит спасибо за сэкономленный трафик)

В handlers/common_handlers.py находится первичная маршрутизация. Вот так обрабатываются рефералки, переходы с сайта, с рекламы и другое при старте:

Диета по токенам

Хранить бесконечную историю диалогов дорого и бессмысленно. В бесплатной версии храню 10 последних сообщений (5 пар вопрос-ответ), а в преме — 30.

Но фотки весят большое кол-во токенов. Если премиум-юзер закинет 30 фоток, OpenRouter выставит мне огромный счет. В итоге я прикрутил ограничение: Из 30 сообщений ИИ видит только 10 последних картинок.

Старые фотки тупо вырезаю из JSON. Подменяю на системный промпт:

С довольно неплохой моделью (gemini 3.0 flash) это работает как часы (она честно признается, что забыла картинку, а не выдумывает что-то из воздуха).

Стриминг, FloodWait и защита баланса

Чтобы бот не выглядел тормозом, я сделал стриминг ответа от ИИ в neiro.py. Я обновляю сообщение в Телеграме чанками по мере получения их от ОпенРоутера.

Но если делать message.edit_text слишком часто, ловишь FloodWait. В итоге я выставил интервал в 0.7 секунд и обернул всё в жесткий try/except:

Стрим при этом не прерывается. Поспали и погнали дальше :) Если на этапе обработки файла или стриминга падает критическая ошибка - честно возвращаю юзеру запрос на баланс.

В handlers/gdz_handlers.py это выглядит так:

SQLite тащит

Почему не Postgre? Потому что для микро-SaaS с 2,5к пользователей SQLite хватает за глаза. Но в асинхронной среде она любит кидать ошибку database is locked.

Чтобы этого избежать, я включил WAL-режим при инициализации пула, разделил коннекты на db_writer и db_reader, а сложные операции доверил самому SQL.

Например, 00:00 запускается крон-таска, которая собирает огромную аналитику, начисляет всем активным юзерам +1 ежедневный запрос и сбрасывает просроченные подписки. И это всё это работает атомарно внутри database.py:

Умная корзина на APScheduler

Когда дело дошло до монетизации, всплыли две проблемы:

Первая: юзер оплатил, но забыл нажать кнопку «✅ Я оплатил» в боте. Бот ждет, юзер ждет, товар не выдается, поддержка кипит.

Вторая: юзер сформировал счёт и передумал ("брошенная корзина").

Вместе с LLM я с нуля изучил apscheduler и убил двух зайцев фоновыми задачами. Теперь в handlers/pay_handlers.py при генерации ссылки на оплату я создаю две отложенные таски:

Как это работает?

Через 5 минут срабатывает async def auto_check_payment(), которая тихо стучится в робокассу. Если статус success - бот сам начисляет запросы на баланс и радует клиента. Если статус pending - таска умирает, и в дело вступает 30-минутная таска.

Но она не шлёт спам вслепую, а лезит в БД и проверяет 3 бизнес-правила:

1. await db.has_successful_payment_recently - Не купил ли он другой товар за последние 3 часа?

2. await db.get_latest_invoice_id - А это точно самый последний сгенерированный им счет?

3. await db.can_send_agitation - Не присылали ли мы ему агитацию недавно?

Если проверки пройдены, то юзер получает сообщение: "⏳ Домашка сама себя не решит! Ты начал оформлять покупку, но оплата так и не прошла...". Это поднимает конверсию оплат.

Финал

Почему я не использую Redis для стейтов? Ответ банален: мой дешевый VPS имеет всего 1 гб оперативки. Пул aiohttp, In-Memory стейты и асинхронные таски и так жрут 70% RAM. Редис тупо не влезет.

Как говорится, работает — не трогай.

Сейчас проект обзавелся сайтом-витриной и продолжает развиваться. В планах - искать и чинить новые баги. Перееду на более мощное железо, когда сервак начнет физически задыхаться.

Готов ответить на вопросы по архитектуре и послушать советы в комментариях \(^^)/

P.s. вот ссылка на первую статью о моём проекте:

P.s. Если кто-то хочет потестить вживую(не реклама), то юз бота в тг @gdzshchelk_bot

С практической точки зрения проект на**й не нужен. Есть GitHub, GitLab и куча нормальных инструментов. Но как эксперимент — почему бы и нет? Чисто посмотреть, можно ли заставить Telegram работать как VCS.

Почему не JSON

На старте я думал: «Положу всё в JSON, на кой мне база данных?» Проектов мало, пользователей немного, файлы текстовые — чего заморачиваться?

Подергал JSON туда-сюда пару дней и понял: не варик.

1. Конкурентный доступ. Два юзера одновременно коммитят — один перезаписывает файл другого.
2. Целостность данных. Если бот упал в середине записи — JSON остаётся в невалидном состоянии.
3. Версионность. Хранить историю изменений в JSON — это просто перенести проблему из кода в структуру файла.

Вывод: JSON — для конфигов, а не для данных, которые меняются каждую секунду.

Выбор SQLite и схема БД

Выбрал SQLite, потому что:

• Не надо поднимать отдельный сервер
• Целостность данных на уровне движка (транзакции, foreign keys, rollback)
• Всё в одном файле — скопировал и унёс

Сущности:

• users — telegram_id, username, current_project_id
• projects — owner_id, name, thread_id (каждый проект живёт в своём треде канала)
• files — filename, current_version, флаг modified (файл изменился и готов к коммиту)
• file_versions — мясо. Каждая версия файла с полным содержимым. Привязана к file_id и опционально к commit_id
• commits — сообщение, время, ссылка на проект
• commit_files — связка коммитов с версиями файлов (many-to-many, чтобы поддержать ветки)

Почему так: я хотел иметь возможность откатиться к любой версии любого файла. Да, база распухнет, но текстовые файлы — это не гигабайты видео. Плюс наличие file_versions и commit_files позволяет делать diff между версиями и смотреть историю изменений.

В коде вместо голых кортежей из SQL — датаклассы:

Маркдауновый ад

Казалось бы: взял код, обернул в тройные апострофы, кинул в Telegram. Telegram сам подсветит синтаксис, если указать язык. Красота. В теории.

На практике Telegram использует свой диалект Markdown, где куча служебных символов: _ * [ ] ( ) ~ > # + - = | { } . !

Попытка 1: заэкранировать всё подряд. Результат: код превращается в кашу. Вместо def __init__- получается def |_|_init|_|_ — уже не запустишь, и в канале выглядит как говно.

Попытка 2: не экранировать вообще. Telegram шлёт на**й с ошибкой «can't parse entities».

Попытка 3: экранировать только то, что реально ломает разметку. Выяснилось, что порядок важен. Сначала экранируем точки и подчеркивания, потом обратную косую черту. Но и это не панацея — последовательности типа \*

после экранирования превращаются в \\*, и Telegram снова недоволен.

Попытка 4: разбивать на части. Для больших файлов делаю превью (первые 50 строк), экранирую их, отправляю как код, а полную версию — файлом. И тут начался ад: Telegram находил ошибки в тех частях кода, которых в превью вообще не было. Оказывается, он всё равно парсил полный код, даже если отправлялась только его часть.

Попытка 5 (финал): забил на Markdown и перешёл на HTML. Telegram умеет его принимать. Да, он не такой красивый, но зато предсказуемый:

Никаких точек, подчеркиваний, обратных слешей. Просто экранируем три символа — и код летит как надо.

Security by design

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

Добавил в /commit. Потом решил с другого аккаунта потестировать команды на чужих файлах. И тут бот на каждую команду стал выдавать «файл не найден» или «проект не найден». И я понял: безопасность уже работает. С самого начала. Из коробки. Без единой строчки кода.

Как так вышло? В таблице projects с самого начала было поле owner_id. При создании проекта я писал туда telegram_id владельца. Все запросы к БД фильтруются по этому полю:

Показать проекты — только свои. Найти файл — только в своих проектах. Выбрать проект — только из своих. Никаких лишних проверок. Просто SQL-запросы, которые с самого начала учитывали владельца.

Команды: от семи до двух десятков

Изначально казалось, что команд будет немного. Но...

Жизнь рассудила иначе.

• База: /start, /init, /use, /list, /ls, /commit, /log, /status
• Удаление: /rm, /rmproject + подтверждение
• Игнор: /ignore, /ignored, /unignore
• Ветки: /branch, /branches, /checkout
• Диффы и просмотр: /diff, /cat

Итого — уже под два десятка. И это не предел.

Простота > абстракции

В моём коде нет абстрактных базовых классов. Совсем. Потому что они нужны только когда у тебя есть минимум две разные реализации одного и того же. В GitGram всё проще: один способ работать с БД, один способ шифровать, один способ парсить .gitignore.

Если завтра появится вторая реализация — тогда и буду делать интерфейс. А пока это просто оверхед.

В GitGram:

• Хочешь понять, как работает add_file — идёшь в database.py и читаешь 10 строк кода.
• Хочешь увидеть обработчик /commit — открываешь bot.py и смотришь.

Никаких AbstractMinerShieldEventProcessor, BaseGitGramManager, InterfaceProviderFactory.

Код должен быть тупым. Чем тупее — тем проще его читать и отлаживать.

Что дальше

В планах:

• Докрутить коллаборацию (несколько человек над одним проектом)
• Приватные репозитории
• Кодспейс прямо в боте (да да знаю я сошёл с ума и бла бла бла..)

Итог

GitGram принимает файлы, режет их на куски если надо, постит в канал с подсветкой. Коммиты ходят, ветки переключаются, диффы показываются. Всё это в тредах, каждый проект отдельно.

На практике GitGram ни к чему. Но сама задумка — Git в Telegram — это же так прикольно. Просто посмотреть, можно ли такое вообще запилить.

Если хочешь поучаствовать

• GitGram
• Чат для хардкорных: @sandbox_hardcore — вся сырая разработка, факапы и обсуждения (без цензуры)

Подписывайся на мой TГ-канал — там я публикую все свои эксперименты, код и приглашаю к обсуждению. Только факты, мат и никакой политоты.

На первый взгляд кнопка «наверх» — задача на пять минут. Добавил position: fixed, обработчик window.scrollTo() — готово.

Но стоит этой кнопке появиться в живом проекте, как выясняется, что она пересекается с cookie-баннером, мешает чату поддержки, выглядит иначе в мобильной версии, не дружит со строгим CSP или пропадает из Django Admin.

В итоге маленькая UI-деталь начинает обрастать условиями. Я решил собрать их в отдельный Django-пакет — django-scroll-to-top

Когда трёх строк JavaScript достаточно

Для небольшого сайта, где нет сложной верстки, админки, CSP и требований к повторному использованию, самый простой вариант действительно выглядит примерно так:

Это нормальное решение. Не всегда стоит тянуть пакет ради одной кнопки.

Но в реальном Django-проекте быстро появляются дополнительные вопросы:

• когда именно показывать кнопку: после 300 пикселей, одного экрана или только при прокрутке вверх;
• что делать на коротких страницах;
• как не перекрыть cookie-баннер, чат, toast-уведомления или нижнюю мобильную навигацию;
• как дать пользователю закрыть кнопку;
• как не сломать клавиатурную навигацию и режим reduced motion;
• как сделать отдельное оформление для сайта и Django Admin;
• как не заставлять проект добавлять unsafe-inline в Content Security Policy;
• как позволить редактору или администратору изменить цвет, положение и иконку без нового деплоя.

Именно в этот момент «три строки JavaScript» превращаются в отдельный компонент.

Что я хотел получить

Цель была не в том, чтобы сделать ещё одну стрелку в правом нижнем углу. Хотелось собрать переиспользуемый компонент со следующими свойствами:

1. Подключение сайта одной template-тегом.
2. Отдельная поддержка обычных страниц и стандартного Django Admin.
3. Настройка внешнего вида через админку, а не через постоянную правку CSS.
4. Без jQuery, CDN, фронтенд-фреймворка и обязательной сборки.
5. Безопасная работа при строгой CSP.
6. Прогрессивное улучшение: без JavaScript остаётся обычная ссылка в начало страницы.
7. Возможность жить рядом с другими фиксированными элементами интерфейса.

Пакет в итоге хранит обычные настройки установки в settings.py, а визуальное поведение — в базе данных. Это позволяет менять кнопку через Django Admin, публиковать новую версию настроек и при необходимости откатываться на предыдущую. В проекте есть отдельные профили для публичного сайта и Django Admin, а ревизии могут быть черновыми, опубликованными или архивными.

Быстрое подключение

Базовый сценарий начинается с установки:

В settings.py добавляем приложение. Если нужна поддержка стандартной админки, пакет должен идти раньше django.contrib.admin:

Включаем области, где должна работать кнопка:

Для публичной части добавляем URLConf пакета:

А в общий шаблон сайта — один тег:

На стандартном Django Admin ничего дополнительно вставлять не нужно: пакет использует обычный механизм разрешения шаблонов Django. Если же в проекте переопределён admin/base_site.html тег можно добавить вручную в блок footer

Настройка без превращения админки в редактор CSS

Мне не хотелось хранить в базе шаблоны, произвольный CSS или JavaScript. Это неудобно для сопровождения и создаёт лишнюю поверхность для ошибок.

Поэтому визуальная часть собрана из контролируемых вариантов:

• круг, квадрат, скруглённый квадрат или pill;
• заливка solid, outline, soft, ghost, glass или gradient;
• положение в любом углу экрана;
• отдельные размеры для desktop и mobile;
• светлая и тёмная тема;
• встроенные иконки, иконки от разработчика или загружаемые SVG;
• настройки тени, границы, opacity и focus ring.

Что происходит, когда рядом есть cookie-баннер или чат

Нижний правый угол страницы редко бывает свободен. Там часто живут:

• cookie-баннер;
• компактная кнопка после закрытия баннера;
• чат поддержки;
• кнопка обратного звонка;
• мобильная навигация;
• toast-уведомления.

Пакет умеет рассматривать такие элементы как препятствия. Для этого можно пометить элемент атрибутом:

Дальше для кнопки можно выбрать поведение: игнорировать препятствия, сдвинуться вдоль края, попробовать другой угол или скрыться, если безопасного места не осталось.

Для сложных виджетов есть отдельный адаптер: он может отслеживать появление и исчезновение элементов, например компактного launcher после закрытия cookie-баннера. При этом ни cookie-пакет, ни чат не становятся зависимостями django-scroll-to-top

Доступность — не отдельная галочка в конце

У кнопки есть понятное имя для screen reader, поддержка клавиатуры, видимый focus-visible, минимальный размер области нажатия и режим prefers-reduced-motion.

Если пользователь отключил анимации на уровне системы, плавная прокрутка не будет навязываться. Если JavaScript не загрузился, кнопка остаётся обычной ссылкой на начало документа.

Полный независимый аудит WCAG 2.2 AA и тестирование масштабирования 200% и 400% пока находятся в roadmap, поэтому называть компонент полностью сертифицированным по WCAG было бы неправильно. Но структурные требования — клавиатурная доступность, фокус, reduced motion, forced-colors и безопасная работа без JavaScript — уже заложены в компонент и покрываются тестами.

CSP и загружаемые SVG

В корпоративных проектах часто нельзя просто добавить inline-скрипт и включить unsafe-inline ради одной кнопки.

По умолчанию компонент использует same-origin CSS и JavaScript. Для него подходит политика такого вида:

Настраиваемые цвета и размеры отдаются не через inline-стили, а через версионированный stylesheet endpoint. Это позволяет сохранить простой контракт с одним template-тегом и не ослаблять CSP.

Отдельно пришлось подумать о загружаемых SVG. Админ не рендерит исходный файл как есть: SVG проходит санитарную обработку. Скрипты, обработчики событий, внешние ресурсы, встроенные документы и небезопасные namespace отклоняются. Для загружаемых иконок также хранится информация об авторе, источнике и лицензии.

Ревизии, публикация и откат

Одна из самых полезных вещей в пакете — не сама кнопка, а жизненный цикл её настроек.

Можно создать черновик, посмотреть результат в live preview, опубликовать изменения или вернуться к предыдущей версии. Это особенно удобно, когда кнопку настраивает не разработчик, а контент-менеджер или дизайнер.

У ревизий есть три состояния:

• draft — редактируемый черновик;
• published — текущая активная конфигурация;
• archived — сохранённая версия для отката.

Где пакет уместен, а где нет

django-scroll-to-top имеет смысл, когда кнопка нужна в нескольких проектах, должна работать в Django Admin, настраиваться без деплоя или жить в окружении со строгими требованиями к CSP и интерфейсу.

Для лендинга на одну страницу проще и правильнее написать несколько строк самостоятельно. Это будет быстрее, понятнее и дешевле в сопровождении.

Но если такая маленькая деталь начинает повторяться в нескольких продуктах, появляется необходимость поддерживать мобильную версию, доступность, независимые настройки для сайтов и админки, то отдельный компонент уже перестаёт быть избыточным.

Сейчас пакет выпущен как beta-версия 0.2.0, требует Python 3.10+ и поддерживает Django 4.2 LTS, 5.x и 6.0. Лицензия — MIT.

Исходный код, документация и примеры использования доступны в GitHub-репозитории проекта.

Пакет опубликован в PyPI под именем django-scroll-to-top.

Обратная связь, баг-репорты и предложения по интеграции с кастомными Django Admin-темами приветствуются в Issues.

SafeLine WAF — это бесплатный инструмент, который я лично тестировал.

Это полностью open-source решения, продукт с действительно бесплатной Community Edition, где ключевые функции не урезаны.

SafeLine WAF — веб-приложенийный межсетевой экран, который действительно поставляется с разумными настройками по умолчанию

Что он делает:

Защищает веб-приложения от SQL-инъекций, XSS-атак, командных инъекций, CSRF, SSRF, атак включения файлов и других угроз из списка OWASP Top 10. Также поддерживает защиту от CC/DDoS-атак, управление ботами и может работать как шлюз аутентификации.

Почему он:

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

SafeLine использует другой подход — вместо того чтобы полностью полагаться на сигнатурное обнаружение, он применяет движок семантического анализа, который фактически анализирует и понимает входящие HTTP-запросы. Это позволяет добиться более высокого уровня обнаружения при значительно меньшем количестве ложных срабатываний по умолчанию.

Некоторые показатели, которые стоит учитыват

1. Уровень обнаружения - SafeLine (Balanced) (71.65%), ModSecurity (Level 1) (69.74%), Cloudflare (Free) (10.7%)
2. Уровень ложных срабатываний - SafeLine (Balanced) (0.07%), ModSecurity (Level 1) (17.58%), Cloudflare (Free) (0.07%)
3. Точность - SafeLine (Balanced) (99.45%), ModSecurity (Level 1) (82.20%), Cloudflare (Free) (98.40%)

Сбалансированный профиль SafeLine обнаруживает более 70% атак, при этом блокируя легитимный трафик ошибочно всего в 0.07% случаев. Это именно тот уровень настроек по умолчанию, который можно использовать в промышленной среде без постоянного ручного контроля.

Установка выполняется одной командой

После запуска он разворачивается как набор Docker-контейнеров: Tengine (форк Nginx) используется в качестве reverse proxy, отдельный сервис отвечает за семантический анализ, PostgreSQL хранит конфигурации и логи, а удобная веб-панель администратора работает на порту 9443.Community Edition поддерживает до 10 сайтов, чего достаточно для большинства личных проектов и небольших бизнес-сценариев.

Сайт: https://cyberserval.tech/landing/safeline

GitHub: github.com/chaitin/SafeLine (более 21 тыс. звёзд)

Лицензия: GPL-3.0 / MIT (Community Edition)

Но при этом к такому коду часто боятся прикасаться. И не без причины. В старых системах редко бывает понятная карта зависимостей. Документация устарела, часть знаний живет только в головах нескольких разработчиков, а бизнес при этом продолжает ждать новых релизов, интеграций и продуктовых экспериментов.

Так появляется классическая ловушка legacy: систему надо модернизировать, но остановить развитие нельзя. Переписать всё с нуля страшно, поддерживать как есть — всё дороже. В результате продукт обрастает временными решениями, скорость разработки падает, а стоимость каждого следующего изменения растет.

Хорошая новость в том, что модернизация legacy-кода не обязана быть большим взрывом. Старую систему можно менять постепенно, сохраняя рабочий продукт, не замораживая фичи и не устраивая один критический релиз, от которого зависит всё.

Почему Big Bang-переписывание чаще всего заканчивается плохо

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

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

Проблема не в самой идее переписывания, а в условиях, при которых оно проваливается. Большой риск возникает, когда совпадают четыре фактора: переписывание занимает много месяцев, в это время бизнес продолжает развивать старую систему, новая версия покрывает сразу большую часть функциональности, а откат связан с миграцией данных. Если все четыре пункта присутствуют, Big Bang почти гарантированно превратится в долгий и дорогой проект.

Допустим, команда решила переписать модуль заказов в e-commerce-продукте. В старой версии есть корзина, промокоды, доставка и оплата. Команда планирует за полгода сделать новый сервис заказов. Но за эти полгода бизнес добавляет подписки, подарочные сертификаты, частичную оплату бонусами и новую логику возвратов. В итоге новая система, которую проектировали под старые требования, к моменту релиза уже нуждается в доработке.

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

Big Bang всё-таки бывает оправдан — но в узких условиях. Если кодовая база молодая (год-два), пользователей мало, у системы нет критичного состояния в БД и продукт можно временно заморозить или вести в обоих контурах параллельно, полное переписывание может оказаться дешевле постепенной миграции. Это редкая ситуация, и она быстро исчезает по мере роста продукта. В зрелых системах безопаснее работает другой подход — постепенная архитектурная эволюция.

Пример: как команда переписала сервис документов и потеряла полгода

Команда сопровождала сервис — старый модуль на aiohttp с Pydantic v1, через который проходила вся обработка путевых листов и актов осмотра транспорта. Сервис существовал шесть лет, был покрыт тестами фрагментарно, а его API использовали мобильное приложение водителей, диспетчерская веб-панель и пакетный импорт.

Команда решила переписать сервис целиком: перейти на FastAPI, обновить Pydantic до v2, заодно почистить контракты и заменить внутреннее хранилище документов с MongoDB на PostgreSQL. План был рассчитан на четыре месяца.

Через восемь месяцев проект всё ещё не был готов к выкатке, а к десятому месяцу команда откатила миграцию полностью. Причин было несколько.

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

Во-вторых, команда не написала характеристических тестов. Поведение «как есть» нигде не было зафиксировано, и расхождения находились только в продакшене после переключения.

В-третьих, у старого сервиса были скрытые побочные эффекты, о которых никто не помнил. При смене статуса документа публиковал событие в Kafka, которое читал биллинг и сервис аналитики. В новой реализации это поведение не было воспроизведено, потому что в коде оно выглядело как «лишний» вызов. После переключения биллинг перестал получать события, и расхождение обнаружили только через две недели — по жалобе финансового отдела.

В-четвёртых, переключение было сделано «в лоб»: маршрут в API Gateway просто перенаправили на новый сервис. Фича-флага не было, теневого запуска не было, плана отката не было. Когда выяснилось, что новый сервис строже валидирует исторические форматы документов и отклоняет часть старых записей, быстро вернуться на старую реализацию не получилось — её к тому моменту уже отключили на стенде, а в БД успели уйти записи в новом формате.

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

Strangler Fig Pattern: как заменить систему по частям

Один из самых практичных подходов к модернизации legacy-кода — Strangler Fig Pattern. В софтверном виде паттерн был сформулирован Мартином Фаулером в 2004 году под названием StranglerFigApplication. Идея проста: не переписывать систему целиком, а постепенно выносить отдельные части в новую реализацию.

Название пришло из биологии. Фикус-душитель растет вокруг дерева-хозяина и постепенно вытесняет его. В архитектуре принцип похожий: старая система продолжает работать, новая функциональность появляется рядом, а затем отдельные потоки постепенно переводятся на новую реализацию.

Представим старый монолит интернет-магазина. Внутри него есть каталог, корзина, заказы, платежи, скидки, личный кабинет и уведомления. Переписать всё сразу — рискованно. Но можно начать с относительно изолированного участка, например с уведомлений.

Сначала команда описывает текущий контракт: какие события приходят в модуль уведомлений, какие каналы используются, какие шаблоны отправляются, какие ошибки считаются допустимыми. Затем рядом создается новый сервис уведомлений, который реализует тот же контракт. На первом этапе он может даже не отправлять реальные сообщения, а только принимать события и логировать результат. После проверки часть трафика переводится на новую реализацию. Когда сервис стабилизируется, старый код уведомлений удаляется из монолита.

Strangler Fig хорошо работает там, где между старым и новым кодом есть сетевая граница: HTTP, message bus, RPC. Если такой границы нет — например, нужно постепенно заменить функцию или класс внутри одного процесса — используется родственный паттерн Branch by Abstraction: над старой реализацией создается абстракция, рядом пишется новая реализация, переключение происходит через конфигурацию или фича-флаг, после стабилизации старая ветка удаляется. Снаружи это выглядит как Strangler Fig, но без сетевого прокси.

Такой подход снижает риск. В системе нет одного большого релиза, где всё меняется сразу. Есть серия небольших контролируемых изменений. Каждое можно протестировать, измерить и откатить.

Главное правило: сначала повторить поведение, потом улучшать

Одна из частых ошибок при модернизации legacy-кода — попытка одновременно переписать систему и улучшить бизнес-логику. Команда смотрит на старый модуль и думает: «Раз уж мы его трогаем, давайте сразу сделаем нормальную архитектуру, изменим контракты, уберем странные кейсы и перепишем поведение».

Это опасный путь. В legacy-системах странное поведение часто существует не случайно. За ним может стоять неочевидное бизнес-правило, старый клиент, интеграция с внешней системой или исторический баг, на который уже кто-то завязался.

Например, в системе расчета налогов может быть правило: для контрактов, заключенных до 2018 года, НДС округляется в меньшую сторону до целого рубля, а для всех остальных — по математическим правилам. Новый разработчик может решить, что это ошибка, и «исправить» округление. Но потом выяснится, что часть крупных клиентов держит это поведение в своих сверках, а смена правила приведет к расхождениям в актах и претензиям.

Прежде чем менять поведение, его нужно зафиксировать. Для этого пишут характеристические тесты (characterization tests, иногда называемые golden master или approval tests). Идея простая: на реальных данных или их обезличенных копиях прогоняется старая реализация, её ответы сохраняются как эталон, и любые будущие изменения, отклоняющиеся от эталона, отлавливаются автоматически. Тесты пишутся не для красоты, а для того, чтобы зафиксировать существующее поведение — даже странное — перед тем, как его трогать. Подробно эта техника описана у Майкла Физерса в книге Working Effectively with Legacy Code; на практике её удобно реализовать через библиотеки семейства approval-tests (approvaltests-python, approvaltests-java и аналоги).

Поэтому первый этап модернизации — не улучшение, а воспроизведение текущего поведения. Новая реализация должна вести себя так же, как старая. Даже если старое поведение кажется странным. Только после стабилизации можно отдельно обсуждать, что именно стоит менять.

Feature toggles: как включать новую логику без риска

Feature toggles, или фича-флаги, — один из главных инструментов безопасной миграции. Они позволяют включать и выключать новую логику без деплоя.

В обычной разработке релиз часто выглядит бинарно: код либо выкатили, либо нет. При миграции legacy это неудобно. Гораздо безопаснее иметь возможность включить новую реализацию для 1% пользователей, затем для 10%, потом для половины аудитории и только после этого для всех.

Например, команда переносит расчет стоимости доставки из монолита в новый сервис. С помощью фича-флага это выглядит так:

user_id передается явно, чтобы решение «попал ли пользователь в новый сегмент» было стабильным от запроса к запросу. Иначе один и тот же клиент будет получать разные ответы при обновлении страницы, и поведение системы станет непредсказуемым.

На первом этапе флаг включают только для внутренней команды. Потом для тестового сегмента пользователей. Затем для небольшой доли реального трафика. Если метрики стабильны, долю увеличивают. Если появляются ошибки, флаг выключают, и пользователи снова идут в старую реализацию.

Важно различать два разных типа флагов. Флаг постепенной выкатки (rollout flag) меняется редко и контролирует, какой процент пользователей видит новую логику. Kill switch — отдельный флаг, единственная задача которого — мгновенно выключить новую реализацию при инциденте. Kill switch должен опрашиваться на каждом запросе, его кэширование должно жить секунды, а не минуты, и он принципиально не должен зависеть от той системы, которую он выключает. Иначе в момент аварии может оказаться, что выключатель сам недоступен.

В качестве инфраструктуры для флагов команды обычно берут одну из платформ: LaunchDarkly, Unleash, Flagsmith, GrowthBook, либо собирают собственную поверх Redis или конфигурационного сервиса. Для миграции важны три свойства: быстрое распространение изменений (секунды, а не минуты), поддержка таргетинга по пользователю/сегменту и аудит — кто и когда менял флаг.

Важно, что фича-флаг — это не просто if в коде. Для серьезной миграции нужны правила: кто может включать флаг, как быстро его можно отключить, какие метрики отслеживаются, когда флаг должен быть удален.

Последний пункт особенно важен. Если флаги не удалять, система быстро превращается в набор ветвлений, где никто уже не понимает, какая логика актуальна.

Shadow testing: как проверить новую систему на реальном трафике

Feature toggles помогают безопасно переключать пользователей. Но перед этим хорошо бы понять, совпадает ли новая логика со старой. Для этого используют shadow testing.

Shadow testing — это запуск новой реализации параллельно старой, но без влияния на пользователя. Пользовательский запрос по-прежнему обрабатывает старая система, а новая получает копию запроса и считает результат «в тени». Пользователю этот результат не показывается. Команда только сравнивает ответы.

Например, есть старый модуль расчета скидок. Он учитывает промокоды, сегмент пользователя, историю покупок, регион и партнерские условия. Команда пишет новый сервис скидок. Чтобы не переключать пользователей сразу, можно запустить теневой режим:

Два момента, на которые стоит обратить внимание в этом коде. Теневой вызов запускается через asyncio.create_task — корутина сразу планируется в event loop и начнёт выполняться, как только функция вернёт управление. И весь блок завернут в try/except: исключение в новой логике не должно ронять основной запрос. Без этих двух свойств shadow testing рискует ухудшить продакшен вместо того, чтобы безопасно его проверить.

Небольшая оговорка для продакшена: event loop держит на task только слабую ссылку, и без сохранённой ссылки задача может быть собрана сборщиком мусора прямо во время выполнения. В реальном коде Task имеет смысл класть в set фоновых задач и удалять оттуда через add_done_callback. В примере выше эта обвязка опущена для читаемости.

Для критичной доменной логики — платежей, биллинга, расчета тарифов — допустимый уровень расхождения должен быть около нуля: цель в shadow-режиме не «как можно меньше различий», а «понимаем каждое расхождение». Для менее чувствительных доменов (рекомендации, ранжирование результатов поиска) можно жить с расхождением в долях процента, но и там расхождения нужно классифицировать, а не игнорировать. Возможно, это баги новой реализации. А возможно, старая система содержит устаревшую логику, которую нужно отдельно обсудить с бизнесом.

Shadow testing особенно полезен для критичных доменных частей: платежей, биллинга, расчета тарифов, персональных предложений, транзакций. Там нельзя просто «попробовать на пользователях» и посмотреть, что будет.

При этом важно отличать теневую проверку чтения от теневой проверки записи. Чтение проверить относительно дёшево: запрос идёт в обе системы, ответы сравниваются, никаких внешних эффектов нет. С записью всё сложнее. Если новая реализация в shadow-режиме действительно создаст заказ, спишет деньги или отправит письмо, у пользователя возникнут двойные эффекты. Поэтому для writes либо вводят идемпотентные ключи и shadow-режим без реальных побочных действий (внешние вызовы заменены no-op-стабами, БД — отдельной shadow-копией), либо вообще отказываются от теневой проверки записи в пользу постепенной выкатки за фича-флагом.

Сравнение ответов в реальной системе тоже не сводится к одной функции compare. Нужно отдельно решать, как игнорировать «нормальный» шум (метки времени, идентификаторы, порядок коллекций), как сэмплировать трафик, чтобы не утопить хранилище расхождений, и как организовать триаж — кто и в каком ритме разбирает накопившиеся диффы. Готовые решения этого класса — GitHub Scientist (Ruby и его порты в другие языки), Twitter Diffy, либо собственный лёгкий регистратор поверх Kafka и таблицы расхождений.

С чего начинать модернизацию

Начинать лучше не с самого больного и не с самого центрального модуля. Это звучит контринтуитивно, потому что обычно хочется сразу взяться за главный источник проблем. Но если начать с ядра системы, команда быстро упрется в максимальное количество зависимостей и рисков.

Удобный способ выбрать первый кусок — оценить кандидатов по двум осям: насколько модуль критичен для бизнеса (low / high) и насколько сильно он связан с остальной системой (low / high). Начинать стоит с квадранта low-criticality + low-coupling: ошибки в нем не уронят бизнес-показатели, а малое количество зависимостей позволит провести миграцию полностью, не утянув за собой смежные модули. Высоко-критичные и сильно связанные части (платежи, ядро авторизации) трогают в последнюю очередь — на этот момент команда уже наберёт опыт безопасной миграции.

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

Допустим, в банковском приложении есть старый модуль истории операций. Он медленный, сложно расширяется, но при этом не выполняет сами транзакции. Это хороший кандидат для первой миграции. Ошибка в истории операций неприятна, но обычно менее критична, чем ошибка в списании денег.

Команда может вынести чтение истории в отдельный сервис, сначала запустить его в shadow-режиме, потом включить для части пользователей, затем полностью перевести чтение на новую реализацию. При этом критичная транзакционная логика останется в старой системе до тех пор, пока команда не наберет опыт безопасной миграции.

Миграция данных: самая сложная часть

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

Базовый рабочий приём — Expand-Contract (он же Parallel Change). Изменение схемы делается в три такта. На этапе expand в БД добавляются новые поля, таблицы или индексы, при этом старое поведение полностью сохраняется. Затем — migrate: обе реализации начинают писать и в старое, и в новое место (dual writes), а отдельный фоновый процесс делает backfill — заполняет новые поля историческими данными. После этого читатели по одному переключаются на новую схему. Только когда никто из читателей не использует старую структуру, наступает contract — удаление лишних колонок и таблиц.

Несколько практических деталей, которые часто упускают:

· Dual writes — это не бесплатная операция. Две записи означают две точки отказа. Если одна из них упала, нужно решать, что делать: продолжать ли работу, ставить ли событие в очередь на повтор, помечать ли запись как несогласованную. Простое «сначала пишем туда, потом сюда» в продакшене на нагрузке приводит к расхождениям.

· Backfill часто длиннее, чем кажется. На большой таблице миграция в одном UPDATE блокирует продакшен. Поэтому backfill делают батчами по N тысяч строк с паузами, отслеживают прогресс и предусматривают возможность остановить и продолжить.

· Онлайн-изменения схемы на крупных таблицах делаются не штатным ALTER TABLE, а специализированными инструментами: gh-ost или pt-online-schema-change для MySQL, встроенные онлайн-механизмы PostgreSQL для индексов и колонок, Liquibase/Flyway — для управления версионированием изменений в репозитории.

· Shadow testing данные не покрывает. Можно сравнить, что новая реализация возвращает то же, что и старая, но если за этим стоит другая схема в БД, проверка корректности самой миграции данных — это отдельная работа: сверки, контрольные суммы, выборочный аудит исторических записей.

Без этих шагов любая красивая фасадная архитектура наталкивается на разъезжающиеся данные — и тогда даже идеальный Strangler Fig снаружи не спасает.

Прокси-слой как точка контроля

Чтобы постепенно заменять legacy-код, нужно управлять маршрутизацией запросов. Для этого часто создают прокси-слой, API Gateway или фасад, через который проходит обращение к старой и новой логике. В терминах Domain-Driven Design такой слой часто называют Anti-Corruption Layer: он защищает новую реализацию от старых контрактов и наоборот, позволяя двум моделям сосуществовать без взаимного «загрязнения».

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

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

В качестве технической основы команды обычно берут один из трех вариантов: классический API gateway (Kong, AWS API Gateway), service mesh (Envoy, Istio) или более простой reverse proxy (NGINX, HAProxy). Service mesh особенно удобен, когда трафик уже идёт внутри Kubernetes-кластера: маршрутизацию можно менять конфигурацией, без правок кода клиентов и сервисов.

Например, мобильное приложение обращается к endpoint /orders/history. Раньше этот endpoint напрямую обслуживал монолит. После введения API Gateway приложение продолжает ходить по тому же контракту, но внутри gateway может решать, куда направить запрос: в legacy-модуль или новый сервис истории заказов.

Управление маршрутизацией обычно делается не «всё или ничего», а на основании атрибутов запроса: значения заголовка (X-Migration-Cohort: new), куки, хэша от user-id (стабильное разбиение пользователей на сегменты) или географического региона. Это позволяет выкатывать новую реализацию сначала на одну страну, на сотрудников самой компании или на тестовый сегмент — и только потом расширять охват.

Для клиента ничего не меняется. Для команды появляется управляемость.

Наблюдаемость: без метрик миграция превращается в гадание

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

Минимальный набор — это логи, метрики и распределенная трассировка (distributed tracing). Нужно понимать, сколько запросов идет в старую и новую реализацию, сколько ошибок возникает, как меняется latency, где появляются таймауты, какие статусы возвращаются, какие бизнес-метрики проседают.

Технические метрики стоит формулировать не как «средний ответ» и «процент ошибок», а в терминах SLI и SLO: целевые показатели вида «99.9% запросов на /orders/history отвечают быстрее 300 ms за 30 дней» с явным error budget. Latency измеряется по перцентилям (p50, p95, p99) — среднее значение почти всегда обманчиво, а хвосты распределения говорят о реальном опыте пользователя. На время миграции имеет смысл выставить отдельные SLO для нового и старого пути и сравнивать их.

В качестве инструментов де-факто стандартом стал OpenTelemetry для трассировок, метрик и логов — единый протокол, который пишет в практически любое хранилище. Дальше — Prometheus и Grafana для метрик, Jaeger или Tempo для traces, Sentry или аналог для ошибок. Для миграции важна возможность фильтровать метрики по «варианту» — отдельно по старому и новому пути — иначе все цифры смешаются и реальную динамику будет не видно.

Технических метрик недостаточно. Если команда переносит оформление заказа, важно смотреть не только на 500 ошибки и время ответа, но и на конверсию в оплату, количество брошенных корзин, повторы запросов, обращения в поддержку.

Пример: новая система формально отвечает быстрее старой и не дает ошибок. Но после включения на 10% пользователей падает конверсия в оплату. Причина может быть не в серверной ошибке, а в изменении порядка полей, другом тексте сообщения или потере какого-то edge-case. Без бизнес-метрик команда может решить, что миграция успешна, хотя для продукта она уже создает проблему.

Практическая последовательность миграции

Рабочая последовательность обычно выглядит так.

Сначала команда выбирает ограниченный участок системы. На этом этапе важно не просто назвать модуль, а описать его границы. Какие сценарии он закрывает? Кто его вызывает? Какие данные он читает и пишет? Какие внешние интеграции использует? Какие неочевидные бизнес-правила в нем есть?

Затем поверх legacy-логики создается стабильный контракт. Это может быть API, фасад, gateway или отдельный слой внутри приложения. Главная задача — сделать так, чтобы клиенты зависели не от внутренней реализации, а от понятного интерфейса. На этом этапе полезно вспомнить про contract testing (Pact, Spring Cloud Contract): автотесты со стороны потребителей фиксируют, что именно они ожидают от API, и предупреждают о ломающих изменениях до того, как они доедут до продакшена.

После этого рядом пишется новая реализация. Она должна повторять текущее поведение, а не сразу становиться «идеальной версией будущего». На этом этапе полезно фиксировать все расхождения: где старая система работает странно, где требования не описаны, где бизнес-правила требуют уточнения.

Следующий этап — shadow testing. Новая система получает копии реальных запросов, считает результат, но пользователю по-прежнему возвращается ответ legacy. Команда сравнивает результаты и устраняет расхождения.

Когда новая реализация достаточно стабильна, начинается постепенное переключение через feature toggles. Сначала внутренние пользователи, потом 1% реального трафика, затем 5–10%, затем 50% и только после этого 100%.

На каждом этапе команда смотрит на метрики. Если всё стабильно, движение продолжается. Если появляются проблемы, флаг выключается, трафик возвращается в legacy, а команда разбирает причины.

Последний этап — удаление старого кода. Это не формальность, а обязательная часть миграции. И «удалить старый код» — это не один коммит, а явный Definition of Done: вырезана старая ветка кода, удалён фича-флаг, обновлена документация и схемы архитектуры, переименованы или удалены устаревшие дашборды и алерты, обновлены runbook’и для on-call и проведено короткое внутреннее обучение. Если этого не сделать, через полгода никто уже не вспомнит, какой путь актуален, и легаси-ветвление останется в коде навсегда.

Откат миграций: дешёвый только пока не пошли записи

Откатить миграцию, в которой ещё не было записи в БД, легко: достаточно переключить фича-флаг, и трафик снова идёт через старую реализацию. Откатить миграцию, в которой новая система уже неделю писала данные в новые таблицы, — отдельный, гораздо более тяжёлый разговор.

Поэтому ещё на этапе проектирования каждое изменение должно сопровождаться явным планом отката. Удобно различать три типа шагов.

Полностью обратимые шаги. Чтение через новый сервис, расчёт «в тени», новые метрики. Откат — выключить флаг. Это самый комфортный режим, и в нём стоит держать миграцию как можно дольше.

Обратимые с компенсацией. Новая реализация пишет дополнительные данные (например, дублирует операции в новую таблицу), но старый источник тоже обновляется. Откат возможен, но требует решить, что делать с уже записанными данными: оставить, очистить, синхронизировать. План этих действий должен быть написан до выкатки, не во время инцидента.

Forward-only. После некоторой точки откат становится невозможен — например, после того, как старая схема удалена или внешние интеграции перенастроены на новый сервис. Такие шаги допустимы, но к ним нужно приходить отдельно, осознанно, с особенно строгими SLO в предыдущем этапе. До forward-only-перехода имеет смысл подержать систему в режиме параллельной работы дольше, чем по графику.

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

Пример: как тот же сервис мигрировали со второй попытки

После неудачного опыта команда взялась за тот же сервис заново, но изменила подход.

На первом шаге они зафиксировали поведение существующего сервиса. На самые часто используемые сценарии (создание путевого листа, подпись акта осмотра, выгрузка пакета документов за период) написали характеристические тесты на реальных продакшен-данных, обезличенных и сохранённых как фикстуры. Любое будущее изменение поведения теперь падало в CI как явное расхождение.

Параллельно команда провела инвентаризацию побочных эффектов. Из исходного кода и логов выяснилось, что сервис не только хранит документы, но и: публикует событие в Kafka при смене статуса, инкрементирует счётчик в Redis для рейтинга водителей, отправляет webhook во внешнюю систему партнёра, пишет в таблицу аудита. Каждый из этих эффектов попал в отдельный пункт чек-листа «что должно остаться» в новой реализации.

Затем команда выбрала первый кусок для выноса — не весь сервис, а только чтение документов (GET /documents/{id} и GET /documents/by-driver/{driver_id}). Это была наименее рискованная часть: ошибки в чтении неприятны, но не ломают финансовые потоки.

Новый сервис написали на FastAPI рядом со старым. На уровне API Gateway появилось правило маршрутизации: запросы на чтение шли в старый сервис, но в фоне дублировались в новый. Ответ пользователю всегда возвращал legacy, а ответ нового сервиса сравнивался с эталоном и записывался в отдельную таблицу для разбора. Использовали обёртку поверх asyncio.create_task — на ответ пользователя теневой вызов не влиял.

За три недели shadow-режима команда нашла четыре расхождения. Два оказались багами новой реализации (округление времени, неправильная сортировка вложений). Два — давно забытыми особенностями старого сервиса (одно поле возвращалось в UTC, другое — в локальной зоне; так было исторически, бизнес не возражал, но в новой реализации захотели единый формат). Все четыре зафиксировали явно: баги — починили, особенности — согласовали с продуктовой командой как осознанное изменение.

Когда расхождений не осталось, включили фича-флаг на сотрудников самой компании. Через неделю — на 1% реальных водителей. Дальше шаг по 5%, 25%, 50%, 100% с паузой в несколько дней между этапами. На каждом шаге следили не только за HTTP-ошибками и latency, но и за продуктовыми метриками: количество подписанных актов, время от открытия документа до подписи, доля повторных запросов. Один раз пришлось откатиться с 25% на 5% — в одном из регионов выросло время отклика из-за неэффективного запроса. Исправили, выкатили снова.

Через два месяца чтение полностью перешло в новый сервис. Старый код чтения и фича-флаг удалили в том же релизе. После этого по той же схеме мигрировали запись документов, потом публикацию событий, потом импорт из внешних систем. Полная миграция заняла девять месяцев — почти столько же, сколько провалившийся Big Bang, — но продукт всё это время продолжал развиваться, инцидентов не было, и в конце команда осталась с системой, которую понимает.

Типичные ошибки при работе с legacy

Первая ошибка — пытаться улучшить всё сразу. Команда одновременно меняет архитектуру, бизнес-логику, контракты и инфраструктуру. В результате становится невозможно понять, какая именно часть вызвала проблему. Правильнее сначала воспроизвести поведение, стабилизировать новую реализацию и только потом улучшать.

Вторая ошибка — недооценивать скрытые зависимости и побочные эффекты. Legacy-код часто делает больше, чем кажется. На один и тот же вызов могут быть навешаны: запись в таблицу аудита, инкремент счётчика в кэше, публикация события в очередь, обновление статуса связанной сущности, инвалидация кэша, дёрганье webhook’а во внешнюю систему. Если в новой реализации воспроизвести только явный путь, скрытые потребители молча перестанут получать данные — и узнают об этом через жалобу бизнеса, а не через ошибку в логах. Поэтому перед выносом любого модуля имеет смысл составить инвентаризацию побочных эффектов: пройтись по коду и логам и выписать каждое нелогичное действие отдельным пунктом чек-листа.

Третья ошибка — отсутствие наблюдаемости. Без логов, метрик и трассировки команда не управляет миграцией, а угадывает. Особенно опасно смотреть только на технические ошибки и игнорировать бизнес-показатели.

Четвертая ошибка — не договариваться с бизнесом. Модернизация не должна быть невидимой «инженерной активностью в стол». Её нужно встраивать в roadmap, объяснять эффект и договариваться о приоритетах. Если бизнес не понимает, зачем команда тратит время на миграцию, работа будет постоянно проигрывать новым фичам.

Пятая ошибка — не удалять старый код. Временное сосуществование старой и новой логики нормально. Вечное сосуществование — нет. Если legacy не удаляется, технический долг не уменьшается, а просто меняет форму.

Шестая ошибка — не удалять фича-флаги после миграции. Флаг, который сыграл свою роль и больше никогда не выключается, превращается в постоянное ветвление в коде. Через год команда не помнит, можно ли удалить такую ветку или там сидит важный edge-case. Через два — кода с такими «мёртвыми» флагами становится больше, чем основной логики. Поэтому каждый флаг должен заводиться с условием удаления («после полной выкатки и двух недель стабильной работы») и иметь ответственного, кто этим удалением займётся.

Отдельно стоит упомянуть организационную сторону. Закон Конвея работает и в обратную сторону: если новый и старый код владеются разными командами с разными приоритетами, миграция будет тормозиться независимо от выбранного паттерна. На время миграции имеет смысл явно проговорить, кто отвечает за переход, и не разделять старую и новую реализации между несовместимыми roadmap’ами.

Компромиссы, к которым нужно быть готовыми

Постепенная модернизация безопаснее Big Bang-переписывания, но она не бесплатна. Некоторое время система будет сложнее, чем раньше. В ней появятся старый и новый код, прокси-слой, фича-флаги, дублирование логики, дополнительные метрики.

Shadow testing увеличит нагрузку на инфраструктуру, потому что часть запросов будет обрабатываться дважды. Команде придется поддерживать дисциплину: документировать контракты, отслеживать флаги, удалять старую реализацию после миграции, поддерживать contract-тесты в актуальном состоянии.

Но это контролируемая сложность. Она распределена во времени и управляется инженерными практиками. В отличие от Big Bang-риска, где команда долго работает с минимальной обратной связью, а потом выкатывает один большой релиз с максимальной неопределенностью.

Когда Strangler Fig особенно оправдан

Постепенная миграция особенно хорошо подходит для систем, где downtime невозможен или слишком дорог. Это финтех, e-commerce, биллинг, мобильные бэкенды с большой аудиторией, высоконагруженные продукты, старые монолиты и системы с большим количеством интеграций.

Если продуктом ежедневно пользуются сотни тысяч или миллионы людей, нельзя позволить себе «переписать и посмотреть, что будет». Нужно менять архитектуру так, чтобы пользователь не замечал процесса миграции.

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

Когда модернизацию лучше не делать

Постепенная миграция — мощный инструмент, но у неё тоже есть стоимость, и иногда правильный ответ — оставить систему как есть. Несколько сценариев, в которых модернизация плохо окупается.

Продукт, который уходит из эксплуатации. Если через год сервис будет выключен или заменён на покупное решение, тратить квартал на его рефакторинг бессмысленно. Достаточно стабилизировать то, что есть.

Модуль, который никто не трогает. Если код десятилетней давности продолжает работать, не падает, не требует изменений и не вызывает инцидентов, его «уродливость» — не повод его переписывать. Цель модернизации — упростить будущие изменения; если будущих изменений нет, цели тоже нет.

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

Простой тест: если на вопрос «какой бизнес-сценарий мы откроем после миграции» нет внятного ответа — модернизацию имеет смысл отложить и заняться чем-то другим.

Что получает команда

Главный результат постепенной модернизации — управляемость. Команда начинает лучше понимать систему, контролировать изменения и снижать риск инцидентов.

Появляются понятные контракты, наблюдаемость, практика безопасных релизов, культура удаления старого кода. Разработчики перестают бояться legacy, потому что у них появляется метод, а не только желание «когда-нибудь всё переписать».

Для бизнеса это тоже выгодно. Продукт продолжает развиваться, сроки становятся более прогнозируемыми, риски крупных сбоев снижаются, а технический долг постепенно уменьшается.

Модернизация — это процесс, а не проект

Legacy нельзя «починить за квартал». Если система развивалась годами, она не станет простой после одного рефакторинга. Но её можно системно улучшать.

Strangler Fig Pattern, Branch by Abstraction, feature toggles, shadow testing и аккуратная миграция данных дают рабочую модель: выбрать ограниченный участок, описать контракт, реализовать новую версию, проверить её на реальном трафике, постепенно переключить пользователей и удалить старый код.

Это не самый быстрый путь. Зато он управляемый. А в зрелых продуктах управляемость важнее скорости.

Потому что цель модернизации — не написать красивую новую систему. Цель — сделать так, чтобы продукт продолжал развиваться, команда могла безопасно вносить изменения, а пользователи не становились участниками инженерного эксперимента.

Я Java-разработчик и в основном работаю с backend: Spring Boot, базы данных, интеграции, авторизация, WebSocket — всё то, что обычно находится за интерфейсом.

В какой-то момент я поймал себя на мысли: я каждый день пользуюсь мессенджерами, но плохо понимаю, как они устроены внутри. Окей, JWT, WebSocket, PostgreSQL, Redis — это понятно. Но что технически означает фраза "end-to-end encryption"? Как сервер доставляет сообщения, если он не должен их читать? Где живут ключи? Что хранится в базе? Что происходит, если у пользователя два устройства?

Решил разобраться через практику. Написал мессенджер с нуля. Назвал Chaos Messenger.

Сразу честно: криптографическую часть я изучал вместе с Claude и ChatGPT — читал спецификации X3DH и Double Ratchet, разбирал примеры, задавал вопросы, пока не сложилась цельная картина. Frontend тоже делался с активной помощью ChatGPT: я backend-разработчик, React для меня не основная среда. Но архитектура, backend, интеграция WebCrypto, модель конвертов, хранение сообщений и принципиальные решения — мои.

Для меня AI здесь был не заменой понимания, а инструментом — примерно как документация, Stack Overflow и ревью коллег. Без понимания threat model и архитектуры такой проект всё равно не собрать.

В статье расскажу, как работает E2EE изнутри: как устанавливается сессия через X3DH, как каждое сообщение получает отдельный ключ через Symmetric Ratchet, почему сервер хранит только зашифрованные конверты, и какие ошибки я допустил по дороге.

Стек: Spring Boot 3, React 18, WebCrypto API, PostgreSQL, Redis, WebSocket/STOMP, Prometheus, Grafana.

Важная оговорка про web-E2EE

Когда я говорю, что сервер не может прочитать сообщения, я имею в виду backend, базу данных, WebSocket-слой и уже сохранённые ciphertext-конверты. У них нет ключей и plaintext.

Но у web-E2EE есть отдельная проблема: frontend-код тоже приходит с сервера. Теоретически скомпрометированный сервер может отдать изменённый JavaScript, который украдёт ключи или plaintext до шифрования. Это ограничение не конкретно моего проекта, а браузерной модели в целом.

Поэтому корректная формулировка такая: backend не получает ключи и не может расшифровать уже переданные или сохранённые сообщения. Защита от подмены клиентского кода — отдельный слой безопасности: подпись сборок, независимая верификация клиента, desktop/mobile-приложения, reproducible builds.

Почему обычный подход не работает

Большинство "мессенджеров" на GitHub выглядят примерно так:

Сервер знает всё. Видит каждое сообщение. Если БД утекла — утекла вся переписка. Если сервер взломали — читай что хочешь. Если завтра компания решит продать данные — технически ничего не мешает.

E2EE решает это радикально: backend не получает ключи и не хранит plaintext. Сообщение шифруется на устройстве отправителя до отправки в сеть, а расшифровывается только на устройстве получателя.

Это уже не вопрос политики конфиденциальности в стиле "мы обещаем не читать". Это архитектурное ограничение: если у сервера нет ключа, он не может превратить ciphertext обратно в текст.

Звучит как магия. На самом деле — два протокола и немного WebCrypto.

Главная идея: конверты

Представь что Алиса хочет написать Бобу. Вместо того чтобы положить письмо на стол и надеяться что никто не прочитает — она кладёт его в запечатанный конверт. Конверт может открыть только Боб своим ключом. Сервер просто передаёт конверт не заглядывая внутрь.

Именно так это работает в коде. В базе данных у меня это выглядит так:

Когда я впервые увидел

в своей БД вместо текста — стало понятно, что модель наконец работает правильно: сервер создал сообщение, доставил его, сохранил метаданные, но так и не узнал содержимое.

А вот что сервер возвращает при запросе списка чатов через API:

Не

. Не

. Буквально

(DevTools → Network → ответ API с

)

Откуда берутся ключи: X3DH

Главный вопрос: как Алиса и Боб получают общий секрет, если они никогда раньше не общались? И как сделать это так, чтобы сервер только помог передать публичные данные, но сам не смог вычислить итоговый ключ?

Для этого используется X3DH — Extended Triple Diffie-Hellman, протокол из экосистемы Signal. Его задача — установить общий секрет между двумя устройствами, используя долгосрочные и временные ключи.

Что хранится на сервере

Когда пользователь регистрирует устройство, он загружает на сервер пакет публичных ключей:

На сервер уходят только публичные части. Приватные ключи сериализуются и хранятся локально в браузере — и никогда не покидают устройство в сеть.

Здесь важно сказать честно: хранение приватных ключей в

Более строгий вариант — использовать Web Crypto API с

, чтобы приватный ключ жил внутри браузерного crypto runtime и его нельзя было экспортировать в байты. Но у этого подхода есть практическая сложность: ключи нужно переживать между перезагрузками страницы, синхронизировать с IndexedDB, аккуратно восстанавливать состояние устройства и не сломать UX.

В браузерных E2EE-приложениях обычно приходится выбирать между несколькими вариантами:

• Сериализуемые ключи в localStorage или IndexedDB — проще реализовать, но нужно очень серьёзно относиться к XSS и целостности frontend-кода.
• extractable: false + IndexedDB — безопаснее, но сложнее в реализации и восстановлении состояния.
• Нативное secure storage вроде Android Keystore или iOS Secure Enclave — лучший вариант для мобильных клиентов, но он недоступен обычному web-приложению.

В текущей версии Chaos Messenger используется первый вариант. Это осознанный компромисс для pet/open-source проекта и удобного запуска в браузере. Переход на non-extractable ключи и более строгую модель хранения стоит в roadmap.

Ключевой момент: backend всё равно не получает приватные ключи и не может расшифровать сохранённые ciphertext-конверты. Но защита ключей на клиенте — отдельная задача, и её нельзя честно замалчивать.

Установка сессии

Когда Алиса открывает переписку с Бобом впервые, происходит следующее:

В классическом X3DH четвёртая DH-операция с one-time prekey опциональна: она выполняется, если сервер выдал доступный OPK получателя. В моей реализации устройство публикует набор one-time prekeys при регистрации, поэтому первое сообщение обычно использует DH4. Если OPK закончились, сессию всё равно можно установить через остальные DH-компоненты, но это уже менее сильный вариант.

Боб, получив конверт с эфемерным публичным ключом Алисы, повторяет те же операции со своими приватными ключами и получает тот же самый

. Математика симметрична.

Сервер в этот момент видит только публичные ключи и зашифрованный конверт. Он помогает устройствам найти друг друга, но не участвует в вычислении секрета.

Получить

Как шифруется каждое сообщение: Symmetric Ratchet

X3DH даёт нам стартовый

. Но использовать один и тот же ключ для всех сообщений — плохая идея. Если использовать один ключ для всей переписки, компрометация этого ключа сразу открывает весь поток сообщений.

Решение — симметричный ratchet. После каждого сообщения цепочка ключей продвигается вперёд:

Визуально это выглядит так:

используется для шифрования одного сообщения через AES-GCM, после чего уничтожается. Если атакующий компрометирует

— он прочитает только второе сообщение.

В рамках такой симметричной цепочки это даёт forward secrecy назад по цепочке: зная текущий или отдельный

Само шифрование сообщения:

А вот что уходит на сервер — живой пример из DevTools:

Сервер получает

и

. Расшифровать без

Важная оговорка: это ещё не полный Double Ratchet

В этом проекте реализован Symmetric Ratchet — цепочка, где из

для каждого сообщения выводится отдельный

Это защищает прошлые сообщения: если атакующий узнает текущий ключ или отдельный

, он не сможет откатить HMAC назад и получить старые ключи.

Но это не полный Double Ratchet из Signal Protocol.

В полном Double Ratchet есть ещё DH ratchet step: стороны периодически выполняют новый Diffie-Hellman обмен и обновляют root key. Это даёт break-in recovery — возможность восстановить безопасность будущих сообщений после компрометации части состояния.

В моей реализации DH ratchet step пока нет. Если атакующий получит актуальное состояние сессии на устройстве и сможет продолжать его читать, он сможет расшифровывать будущие сообщения до переустановки сессии. Это честное ограничение текущей версии, и оно стоит первым пунктом в roadmap.

Мультиустройство: один пользователь, несколько конвертов

Первый неочевидный момент: в E2EE сообщение адресуется не просто пользователю, а конкретным устройствам пользователя.

Если у Боба два устройства — телефон и ноутбук — нужен отдельный encrypted envelope для каждого устройства. Сервер не может взять один конверт, расшифровать его и "переупаковать" для второго устройства: у него нет ключей и он не знает plaintext.

Значит при отправке сообщения нужно зашифровать его отдельно для каждого устройства каждого участника чата.

Для чата где у каждого по 2 устройства — 4 конверта на одно сообщение. Для группы из 10 человек — потенциально 20 конвертов. Это нормально, это цена безопасности.

Сервер: хранение и доставка конвертов

На сервере сообщение создаётся с контентом

, а конверты сохраняются отдельно:

После сохранения — fanout по WebSocket. Каждое устройство получает свой конверт и только его:

Это важное отличие от обычного WebSocket-чата. В обычном чате сервер рассылает одно и то же событие всем участникам. В E2EE-чате сервер рассылает разные события разным устройствам: payload для каждого устройства содержит свой

Топик

— строго персональный. Устройство А не получает конверт устройства Б. Никакого broadcast — только адресная доставка.

Архитектура целиком

Баг который долго не замечал

В панели чатов показывается превью последнего сообщения. Я реализовал это через

Запускаю — в списке чатов у всех написано

.

Конечно. Сервер же не знает что там написано.

Я полчаса думал как решить это на сервере. Потом дошло: нельзя решить это на сервере — у него нет ключей. Решение только на клиенте.

После того как пользователь открыл чат и сообщения расшифровались — кешируем последнее в памяти:

Это хороший пример того, как E2EE меняет привычное мышление backend-разработчика. В обычном приложении preview — это поле в SQL-запросе. В E2EE-приложении preview — это локальное клиентское состояние, потому что только клиент видел plaintext.

Простое решение. Но чтобы к нему прийти нужно было полностью принять идею что сервер здесь просто не при делах — и перестать пытаться решить задачу на его стороне.

Rate limiting: дыра которую легко не заметить

Эндпоинт

отправляет SMS с кодом. Без защиты любой скрипт может дёргать его тысячи раз — это называется SMS pumping fraud, SMS стоят реальных денег.

Redis у нас уже был для хранения онлайн-статусов. Добавил rate limiting поверх него:

При превышении — HTTP 429 с заголовком

. Клиент знает через сколько секунд можно повторить.

Важный нюанс: в текущей реализации, если Redis недоступен, сервис не блокирует авторизацию полностью. Для pet-проекта это приемлемый компромисс: лучше рискнуть одним лишним SMS, чем положить вход в приложение.

В production я бы сделал строже: fallback in-memory лимит на инстанс, отдельные лимиты по IP и телефону, антифрод-логику и алерты на всплески отправки кодов.

Авторизация WebSocket

Отдельная история — авторизация WebSocket соединений. HTTP-эндпоинты защищены Spring Security автоматически, но WebSocket — другое дело. STOMP-соединение устанавливается один раз, и нужно проверять JWT при каждом подключении.

Отдельно важно не только проверить JWT, но и связать WebSocket-соединение с конкретным устройством. Пользователь может быть один, но устройств у него несколько, а encrypted envelope адресован именно

Поэтому при подключении я проверяю не только токен, но и

: устройство должно быть зарегистрировано и принадлежать текущему пользователю. Иначе легко случайно превратить per-device E2EE-доставку обратно в обычный broadcast по пользователю.

Что получилось — живые скрины

Что реализовано:

• E2EE-модель с per-device encrypted envelopes
• X3DH session setup + Symmetric Ratchet + AES-GCM
• Мультиустройство
• Личные и групповые чаты
• Realtime доставка через WebSocket/STOMP
• Статусы SENT → DELIVERED → READ
• Редактирование и soft delete сообщений
• Online presence, typing indicator
• Фото-вложения
• Поиск пользователей
• Rate limiting на SMS через Redis
• Prometheus метрики + Grafana дашборд
• Swagger UI с JWT авторизацией
• 24 backend-теста на Testcontainers, 12 frontend на Vitest, E2E на Playwright
• GitHub Actions CI

Что ещё не сделано:

• Полный Double Ratchet с DH ratchet step и break-in recovery
• Ротация signed prekey и аккуратное пополнение one-time prekeys
• Более строгая модель хранения приватных ключей на клиенте: non-extractable CryptoKey + IndexedDB
• Защита от подмены frontend-кода: подпись сборок, независимая верификация клиента, reproducible builds
• Android-клиент с Android Keystore
• Реальный SMS-провайдер вместо кода в backend-логах
• Push-уведомления без утечки содержимого сообщений
• Более строгая metadata-модель для групповых чатов

Главный инсайт

E2EE — это архитектурное решение, а не библиотека.

Нельзя взять обычный Spring Boot чат и просто "включить шифрование". Нужно с самого начала проектировать систему так, чтобы backend не был участником доверенной зоны: он не должен получать plaintext, не должен иметь ключи и не должен уметь пересобирать сообщение из данных в базе.

Это меняет почти всё:

• структуру БД — вместо текста появляются encrypted envelopes
• API — сервер отдаёт [encrypted], а не preview сообщения
• WebSocket — доставка идёт не по пользователю, а по конкретному устройству
• мультиустройство — одно сообщение превращается в несколько ciphertext-конвертов
• frontend — становится полноценной криптографической частью системы, а не просто UI

Второй инсайт: мессенджер — это не "чат с WebSocket". В E2EE-модели это система доставки зашифрованных конвертов с адресацией по устройствам. Как только это принимаешь, многие странные на первый взгляд решения становятся логичными.

Репозиторий

Код открыт: github.com/vaazhen/chaos-messenger

В репозитории есть README на русском и английском, диаграммы, скриншоты, security audit, Docker Compose и запуск одной командой.

Проект не претендует на уровень production-криптомессенджера вроде Signal. Это учебный и инженерный open-source прототип, цель которого — показать, как E2EE меняет архитектуру backend, frontend и realtime-доставки.

Если вы делали что-то похожее — особенно интересно сравнить подходы к ротации prekey-ов, хранению non-extractable ключей в браузере и реализации DH ratchet step. Вопросы и критика приветствуются.

Мы остановились на открытом симуляторе InferSim от Alibaba. Он умеет считать TTFT, TPOT и пропускную способность без запуска реального инференса. Но из коробки поддерживает только несколько топовых GPU и фиксированный набор моделей — для наших сценариев этого было недостаточно. Пришлось дорабатывать.

Как устроен InferSim

В основе симулятора — двухфазная схема. Сначала на целевом железе запускаются микро-бенчмарки: измеряется реальная производительность на типовых операциях внимания и матричных умножениях. Получается таблица коэффициентов Model FLOPs Utilization (MFU) — сколько процентов от теоретического максимума выдаёт конкретная карта на конкретной операции. Затем, уже без доступа к GPU, симулятор на основе этих MFU и аналитической модели вычисляет задержки. Именно такой подход даёт более точные предсказания, чем оценка по паспортной пропускной способности памяти.

Добавляем своё железо

Первым делом мы внесли в hardware/gpu.py поддержку MetaX C500 64GB. Характеристики добавляются через dataclass-экземпляры:

После этого c500 попадает в словарь gpu_map, и симулятор запускается с ключом --device-type C500 --world-size 2. Значения FLOPS и пропускной способности пришлось оценивать по косвенным источникам — производитель не публикует точных цифр. Позже планируем уточнить их через бенчмаркинг на реальном оборудовании. Таким же способом добавили Nvidia 1xH100 и A100.

Конфигурация моделей и одна болезненная ошибка

Симулятор ожидает стандартный config.json в формате Hugging Face. Для Qwen3-32B подготовили файл qwen3_32b_config.json:

Ключевой момент — правильное значение head_dim. У Qwen3-32B оно равно hidden_size / num_attention_heads = 5120 / 64 = 80. У нас ушло некоторое время, чтобы понять, почему симулятор выдаёт невалидные результаты: изначально в конфиге стояло значение 128. Пока не исправили — KV-кеш переоценивался, и метрики улетали в неадекватные цифры. После исправления всё встало на свои места.

Позже добавили поддержку Qwen3.5‑9B с её гибридной архитектурой, построенной на чередовании Gated DeltaNet и Gated Attention. Главная особенность модели в том, что около трёх четвертей слоёв не создают привычного KV‑кеша, а используют линейное внимание – компактное скрытое состояние, которое лишь обновляется с каждым новым токеном, не увеличиваясь в объёме. Это кардинально снижает расход памяти на длинных контекстах, но привносит и свою цену: на коротких дистанциях такая модель проигрывает в скорости Prefill, потому что Gated DeltaNet работает последовательно и хуже утилизирует матричные вычисления GPU.

Симулятор изначально не умел различать слои двух типов и считал весь KV‑кеш одинаково. Чтобы поддержать Qwen3.5, пришлось доработать расчёт задержек в классе HybridModel: теперь он отдельно обсчитывает full‑attention‑слои с полным кешем и linear‑attention‑слои без кеша, используя параметры num_full_attn_layers и num_linear_attn_layers из конфигурации. В директорию проекта models добавили hybrid_model.py, в котором сделали дополнительные расчёты:

Без такой дифференциации симулятор для Qwen3.5‑9B показывал E2E порядка 2 500 секунд вместо реальных нескольких секунд – та ошибка, которую мы долго отлавливали.

Визуализация и эксплуатация

Чтобы не разбирать каждый раз текстовый вывод InferSim, сделали веб-интерфейс на Streamlit. Симулятор дёргается через subprocess, результаты парсятся из stdout и визуализируются:

• тепловые карты задержек (Prefill, Decode, E2E Total) для разных длин входных и выходных токенов;
• анализ RPS с расчётом требуемой параллельности и сравнением с доступной памятью;
• информация о занятой памяти в формате «X ГБ из Y ГБ».

Кэширование через @st.cache_data позволило избежать повторных запусков симуляции при неизменных параметрах. Интерфейс получился достаточно удобным, чтобы даже коллеги без погружения в командную строку могли осмысленно сравнивать конфигурации.

Приложение упаковано в Docker и лежит в репозитории на GitHub. Сервисы — сам Streamlit и Nginx в качестве обратного прокси с SSL-терминацией и базовой HTTP-аутентификацией. Деплой на VDS автоматизирован через GitHub Actions: собрали образ, отправили на сервер, перезапустили контейнеры. SSL-сертификаты Let's Encrypt обновляются по cron.

Что в итоге

Адаптированный InferSim не претендует на абсолютную точность — она ограничена качеством бенчмарков и коэффициентов MFU. Но инструмент позволяет избежать грубых ошибок при планировании, что в условиях ограниченного доступа к GPU и их высокой стоимости само по себе немало. Мы продолжаем калибровку симулятора и готовим обновлённые конфигурации для следующих моделей.

Репозиторий проекта открыт, будем рады замечаниям и предложениям от тех, кто решает схожие задачи.

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

Поэтому исследователи начали менять подход. Вместо того, чтобы анализировать ИИ как программу, его все чаще изучают как биологическую систему. Примерно так же, как ученые изучают человеческий мозг.

ИИ под «МРТ»: механистическая интерпретируемость

Как пишет MIT Technology Review, исследователи из Anthropic разработали инструменты для так называемой механистической интерпретируемости.

Они позволяют отслеживать, какие внутренние структуры модели активируются при выполнении конкретной задачи.

По аналогии с медициной, это похоже на МРТ: мы не знаем, как именно работает сознание, но можем наблюдать активность и делать выводы. Один из ученых Anthropic Джош Батсон прямо говорит, что такой анализ ближе к биологии, чем к математике или физике.

«Органоиды» для ИИ

Еще один подход вдохновлен биологией напрямую. В медицине для исследований используют органоиды — миниатюрные аналоги человеческих органов.

В ИИ похожую роль играют специальные нейросети, например sparse autoencoder. Это упрощенные модели, внутреннюю логику которых легче анализировать, чем у полноценных LLM.

Такие «упрощенные мозги» позволяют понять, какие представления формируются внутри модели и как они связаны с итоговым поведением.

Вслушаться во внутренний монолог

Отдельное направление — мониторинг цепочек рассуждений (chain-of-thought monitoring). Модели просят объяснять, почему они пришли к тому или иному выводу. Это похоже на попытку услышать внутренний монолог человека.

По словам исследователя OpenAI Боэна Бейкера, этот метод оказался неожиданно эффективным. Он уже помог выявлять случаи, когда модель действует «плохо» или расходится с собственными правилами безопасности и истинности.

Почему ученые спешат

Главная причина спешки скрыта в тревоге. Специалисты опасаются сложности будущих моделей.

Есть риск, что ИИ станет настолько запутанным (особенно если новые системы будут проектироваться другими ИИ), что инженеры полностью перестанут понимать принцип работы технологии.

Опасность не абстрактная. В новостях уже появляются реальные случаи, когда люди вредили себе из-за советов ИИ. И это происходит на фоне того, что мы все еще не понимаем, как именно эти системы формируют ответы

По его словам, человечество несколько столетий приучали к простой мысли: если ответ выдала машина — значит, он правильный.

Сначала механические калькуляторы, потом компьютеры, потом автоматизация всего подряд. Ошибка человека — норма, ошибка машины — исключение.

Эта логика отлично работала для арифметики, бухгалтерии и повторяемых операций. Но проблема в том, что большие языковые модели — это не калькуляторы.

Они выглядят убедительно, говорят уверенно и звучат разумно. Но в то же время они не обладают тем качеством, на котором строилось доверие к машинам: надежностью результата.

Как работает классическое мошенничество

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

Критика LLM предлагает рассматривать нынешний ИИ-бум именно в этом ключе. Нам показывают системы, которые «почти как человек». Затем годами подогревают доверие к автоматическим решениям. И в итоге включают эмоциональное давление.

Страх как основной двигатель

Риторика вокруг ИИ с самого начала строилась на страхе. Нам рассказывали о риске вымирания человечества, потере рабочих мест и необходимости срочно адаптироваться.

То есть если не внедришь ИИ, то тебя обязательно вытеснят. Или еще пример: если не научишься пользоваться искусственным интеллектом, то останешься без работы.

При этом те же компании продолжают активно продавать доступ к своим моделям и наращивать дата-центры. Если бы угроза была реальной, логичным шагом было бы торможение, а не масштабирование.

Лесть вместо интеллекта

Вторая эмоциональная ловушка — симпатия. Современные LLM намеренно обучены быть максимально дружелюбными и поддерживающими.

Это результат RLHF — обучения с подкреплением от людей. Модели усваивают простое правило: чем больше ты хвалишь пользователя, тем выше оценка.

В итоге система одинаково восторженно поддерживает рабочую идею, ошибочный вывод или откровенно бредовую гипотезу.

Это создает иллюзию понимания и формирует псевдодоверительные отношения между человеком и машиной.

Срочность и пузырь ожиданий

По словам Реннера, нас убеждают — действовать нужно прямо сейчас. Инвестировать, перестраивать бизнес, увольнять людей, внедрять ИИ везде.

И компании охотно ведутся на манипуляцию. Хотя реальность оказывается куда прозаичнее: по данным исследований MIT, до 95% ИИ-проектов в индустрии не приносят ожидаемого ROI.

Не интеллект, а уверенная болтовня

Ключевая мысль материала проста: LLM не являются интеллектуальными системами. Они не понимают, не проверяют и не знают — они угадывают наиболее правдоподобный ответ.

Но благодаря исторически сложившемуся доверию к машинам, мы принимаем этот ответ за истину. Именно на этом и держится иллюзия.

Но, внезапно, все больше компаний возвращают уволенных работников обратно. По данным аналитической фирмы Visier, доля «возвращенцев» (людей, которых снова наняли после сокращений) начала заметно расти.

ИИ не заменил людей, как обещали

Visier проанализировала данные 2,4 млн сотрудников из 142 компаний по всему миру. Около 5,3% уволенных впоследствии были наняты обратно. Этот показатель держался стабильным несколько лет, но в 2025-м пошел вверх.

По словам Андреа Дерлер, главного аналитика Visier, ИИ часто использовался как «удобное оправдание» для сокращений, но реальность оказалась куда сложнее.

«Компании быстро столкнулись с тем, что ИИ-решения не могут полноценно заменить людей — только автоматизировать отдельные процессы», — поясняет она.

Цена автоматизации оказалась выше

Установка ИИ-инфраструктуры (куда входят серверы, системы безопасности, базы данных) требует огромных инвестиций. Многие компании не учли эти расходы, а интеграция новых инструментов оказалась медленной и затратной.

В итоге руководители пересматривают эффективность наспех принятых решений с увольнениями и возвращают опытных специалистов, без которых ИИ-продукты попросту не работают.

Исследование MIT также показывает: 95% организаций пока не увидели заметной финансовой отдачи от своих инвестиций в искусственный интеллект. А главный стратег Interactive Brokers Стив Сосник добавляет:

«Возможно, все эти миллиарды потратили не так уж разумно».

Бумеранг есть

Даже стандартные «оптимизации» оказались невыгодными. По данным платформы Orgvue, компании тратят $1,27 на каждый доллар, который пытаются сэкономить за счет увольнений — с учетом выплат, страховок и скрытых издержек.

Как итог — ИИ по-прежнему не способен заменить живых специалистов. Компании, которые пытались «сократить за счет автоматизации», теперь вынуждены возвращать тех, кого уже уволили.

Редакция Tproger сделала и адаптировала перевод подборки программ для Windows и macOS. Здесь вы найдёте проверенные временем решения для работы, развлечений и повседневных задач. Мы сосредоточились на бесплатных и условно-бесплатных приложениях с отличной репутацией, которые решают реальные задачи без навязывания ненужных функций.

Список разбит по категориям: от браузеров и гейминга до утилит безопасности и инструментов для продуктивности.

Неважно, опытный вы пользователь или новичок — здесь найдётся что-то полезное для каждого.

Браузеры

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

• Большинство пользователей: Chrome, Edge или Safari
• Защита приватности: Firefox, Brave, Ungoogled Chromium
• Опытные пользователи: Vivaldi
• Максимальная анонимность: Tor Browser

Google Chrome

Chrome остаётся самым популярным браузером в мире — и не просто так. Он быстрый, стабильный и отлично интегрируется с экосистемой Google. Огромная библиотека расширений из Chrome Web Store позволяет настроить браузер под любые задачи. Синхронизация между устройствами работает безупречно: вкладки, пароли, закладки и история всегда под рукой.

Минус один, но существенный: Chrome прожорлив. Если у вас открыто больше десятка вкладок, он может съесть несколько гигабайт оперативной памяти. На компьютерах с 8 ГБ RAM и меньше это становится проблемой.

Mozilla Firefox

Firefox — это выбор тех, кто ценит приватность и открытость. Mozilla не зарабатывает на продаже ваших данных, а сам браузер активно развивается сообществом. Встроенные инструменты защиты от трекинга работают из коробки, блокируя рекламные сети и скрипты слежения.

По скорости Firefox не уступает Chrome, а по потреблению памяти даже выигрывает. Библиотека расширений чуть меньше, чем у Chrome, но все основные инструменты доступны.

Microsoft Edge

Edge построен на том же движке Chromium, что и Chrome, но при этом лучше оптимизирован для Windows. Microsoft вложилась в производительность: браузер работает быстро, потребляет меньше ресурсов и отлично интегрируется с системой.

Особенно приятны функции вроде Collections (коллекции вкладок для организации исследований), режим чтения и встроенный скриншотер. Edge поддерживает все расширения Chrome, так что переход безболезненный.

Brave

Brave — это Chrome на стероидах приватности. Браузер блокирует рекламу и трекеры по умолчанию, что делает сёрфинг быстрее и безопаснее. При этом он полностью совместим с расширениями Chrome.

Есть интересная фишка: Brave Rewards позволяет зарабатывать криптовалюту за просмотр приватной рекламы (если захотите её включить). Спорная механика, но как опция — почему нет. Для тех, кто хочет Chrome без Google и с упором на приватность, Brave — отличный выбор.

Safari (только macOS)

Если у вас Mac, Safari заслуживает внимания. Это самый энергоэффективный браузер для macOS: на MacBook он даёт ощутимо больше автономности по сравнению с Chrome или Firefox. Интеграция с экосистемой Apple безупречна: Handoff, синхронизация через iCloud, Reading List, автозаполнение паролей.

Safari быстрый, безопасный и не перегружен функциями. Единственный минус — библиотека расширений заметно скромнее, чем у конкурентов. Но для большинства задач базового функционала хватает.

Ungoogled Chromium

Для ультраосторожных Ungoogled Chromium удаляет всё отслеживание и сервисы Google — но вам придётся настраивать всё самостоятельно, так как в нём нет автообновлений или встроенной синхронизации.

Для максимально осторожных пользователей — это Chrome, из которого убрали всю телеметрию Google, отслеживание и облачные сервисы. Браузер работает, но требует ручной настройки: отсутствуют автоматические обновления и встроенная синхронизация между устройствами.

Tor Browser

Выводя приватность на следующий уровень, Tor Browser маршрутизирует ваш трафик через сеть Tor, анонимизируя ваш IP и многократно шифруя соединение. Он медленнее по задумке, но идеален, если ваш приоритет — максимальная анонимность, а не скорость или удобство.

Vivaldi

Vivaldi — браузер мечты для тех, кто хочет полного контроля. Стекирование вкладок, тайлинг, кастомные горячие клавиши, встроенная почта и календарь, веб-панели — это полноценный десктопный опыт внутри браузера. Хотите боковую панель браузера, открывающую ваши заметки, RSS-ленты или любой нужный сайт? Vivaldi это умеет.

Arc

Наконец, Arc — когда-то новичок на рынке браузеров, нацеленный на переосмысление UX: замена традиционной панели вкладок на боковую панель, акцент на веб-приложениях, интегрированные разделённые виды и easels для заметок и доски. К сожалению, компания за Arc прекратила разработку, чтобы полностью переключиться на ИИ с новым браузером, который сейчас в закрытой бета-версии.

Управление паролями

• Лучший бесплатный выбор: Bitwarden
• Также отлично: 1Password, Dashlane, KeePass

Миллионы людей продолжают использовать одни и те же слабые пароли на всех сайтах — или, что ещё хуже, держатся за классику вроде «123456». Даже сильные пароли мало помогают, если их повторяют или забывают. Конечно, большинство браузеров предлагают встроенные менеджеры паролей, но они ограничены, привязаны к одному браузеру и менее безопасны, чем специализированные решения.

Также не будем забывать о passkeys (ключах доступа). Если говорить практически, можно сказать, что passkeys объединяют концепцию пароля и двухфакторной аутентификации (2FA) в одно плавное действие, но гораздо безопаснее и гораздо менее раздражающе.

Bitwarden

Полностью опенсорсный, зашифрованный и щедрый даже в бесплатной версии. Вы получаете неограниченное количество паролей, синхронизацию между устройствами и приложения для всех платформ. Премиум ($10/год) добавляет безопасный обмен файлами и инструменты 2FA. Также есть доступные семейные и командные планы.

1Password

Премиум-решение с отполированным интерфейсом, сильной кроссплатформенной поддержкой и отличными функциями вроде Travel Mode (режим путешествий) и полной интеграцией passkeys.

Dashlane

Предлагает мониторинг даркнета, интеграцию VPN и плавный пользовательский опыт. Есть бесплатный тариф с ограниченными функциями, но премиум-версия конкурентоспособна.

KeePassXC

Отличная оффлайн-альтернатива, если хотите полного контроля и не против ручной синхронизации (или использования чего-то вроде Syncthing или Dropbox для синхронизации базы данных).

Пропустите LastPass — когда-то фаворит, он упал в немилость после повторных утечек безопасности. Для душевного спокойствия лучше поискать в другом месте.

Продвинутые утилиты и дополнения к ОС

• Поиск + лаунчеры: Everything или Wox (Windows), Alfred или Raycast (macOS)
• Пакетные менеджеры: WinGet, Homebrew (macOS)
• Для пользователей Windows: PowerToys
• Для пользователей Mac: Rectangle
• История буфера обмена: ClipClip, Flycut (macOS)
• Скриншоты + аннотации: Monosnap

Winget

Официальный менеджер пакетов Microsoft, встроенный в Windows 10 и 11. Работает похоже на Chocolatey, но разработан и поддерживается Microsoft. Homebrew — самый популярный менеджер пакетов для macOS. Позволяет быстро устанавливать, обновлять и управлять приложениями и CLI-инструментами с помощью команд в терминале.

Everything

Что касается поиска, Everything остаётся золотым стандартом сверхбыстрого поиска по именам файлов в Windows. Он индексирует диски за секунды и выдаёт почти мгновенные результаты с минимальной нагрузкой на систему. Если нужен функционал шире базового поиска, Wox использует движок Everything и добавляет мощные возможности лаунчера: поиск файлов, запуск приложений, калькулятор, перевод текста и расширения через плагины. Получается более гибкий опыт в духе Spotlight для Windows.

Command Palette/Alfred/Raycast

В который раз Microsoft не смогла существенно улучшить встроенный поиск Windows, хотя Command Palette в PowerToys даёт неплохой компромисс для тех, кто не хочет ставить сторонние утилиты.

На macOS Alfred по-прежнему главный лаунчер и утилита поиска. Он быстрый, интуитивный и в бесплатной версии включает историю буфера и настраиваемые поиски; расширенная автоматизация и «воркфлоу» доступны в Powerpack.

Тем, кто хочет современную облачно-интегрированную альтернативу с готовыми расширениями и встроенной поддержкой Notion, GitHub и Slack, стоит присмотреться к Raycast — это стильный, дружественный к разработчикам вариант, который стремительно набирает популярность.

Менеджеры буфера обмена

Они позволяют возвращаться к ранее скопированному — тексту, изображениям, ссылкам — и сильно ускоряют рутинные операции.

В Windows встроенная история буфера (Win + V) кое-как выручает, но продвинутым пользователям обычно хочется большего. В числе бесплатных рекомендаций — ClipClip для Windows и Flycut для macOS.

Когда речь о скриншотах и аннотациях, штатные инструменты macOS и Windows заметно выросли. Но многим всё равно удобнее сторонние решения. Нам по-прежнему нравится Monosnap за простоту и возможность мгновенно заливать снимки в облако для шаринга (и это бесплатно).

PowerToys — набор полезных утилит от Microsoft для продвинутых пользователей Windows, повышающих продуктивность и упрощающих рабочие процессы. Среди инструментов: FancyZones для продвинутого раскладывания окон, PowerRename для пакетного переименования, Keyboard Manager для ремапинга клавиш, универсальный color picker и другие.

Rectangle и Magnet — два самых популярных приложения на macOS для закрепления окон: быстрые выравнивание и ресайз по хоткеям или перетаскиванием, примерно как по умолчанию в Windows. Пользователям, пришедшим с Windows и скучающим по системному снапингу, одно из них жизненно необходимо.

Широко используемая альтернатива в Windows — FancyZones (часть PowerToys), предлагающая продвинутое управление окнами: настраиваемые сетки, зоны привязки и поддержку нескольких мониторов — поэтому это фаворит пауэр-пользователей на Windows.

Для рутины и создания проектов

• Бесплатные инструменты: FreeOffice, LibreOffice и WPS Office
• Microsoft Office за единовременную плату $49, Office 2024 — $129
• Заметки: Notion, OneNote, Obsidian
• Бесплатный PDF-редактор: PDFsam
• Почтовые клиенты: Thunderbird, eM Client

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

Microsoft Office остаётся отраслевым стандартом для профессиональной продуктивности. Подписка Microsoft 365 открывает доступ к Word, Excel, PowerPoint, Outlook и включает 1 ТБ облачного хранилища.

Среди бесплатных альтернатив LibreOffice — мощный open-source комплект с сильным сообществом (хотя интерфейс некоторым кажется старомодным). Если нужна внешне более майкрософтовская альтернатива, попробуйте FreeOffice или WPS Office Free — у них хорошая совместимость.

На macOS Pages, Numbers и Keynote предустановлены и более чем достаточны для большинства задач, особенно если вы в экосистеме Apple.

Знания и ведение заметок

Notion стал универсальной платформой организации: заметки, базы данных, to-do, управление проектами, создания совместных рабочих пространств. Если нужны более локальные заметки с синхронизацией между устройствами и поддержкой Markdown, Obsidian — любимец студентов и исследователей.

Для быстрых кроссплатформенных заметок OneNote — крепкий бесплатный вариант от Microsoft. В качестве альтернатив — Simplenote или open-source Joplin.

Если вы занимаетесь академической работой и научными статьями, Zotero — отличный open-source менеджер источников с интеграцией в браузер и совместными коллекциями. Milanote предлагает визуальный подход к заметкам и планированию — идеально для креативных пользователей.

Работа с PDF

Хотя Adobe Acrobat остаётся премиальным редактором PDF, бесплатные альтернативы вроде PDFsam позволяют без усилий объединять, разбивать, редактировать и поворачивать страницы.

Инструменты для дизайна и создания контента

Для дизайна два выделяющихся приложения хорошо дополняют набор продуктивности. Figma Desktop — совместная платформа интерфейс-дизайна, широко используемая UI/UX-дизайнерами и фронтенд-разработчиками. Десктоп-версия работает быстрее, чем браузер, и лучше интегрируется с ОС — это удобно для сложных дизайн-систем и коллаборации в реальном времени.

Canva с интуитивным drag-and-drop превосходно чувствует себя и как десктоп-приложение. Отлично подходит для быстрых графических материалов для соцсетей, маркетинга, постеров и презентаций. Благодаря тысячам шаблонов и совместной работе это фаворит как у профи, так и у новичков.

Почтовые клиенты

Если вы предпочитаете отдельный почтовый клиент, у eM Client много функций, бесплатный — до двух аккаунтов. Mozilla Thunderbird — мощная open-source альтернатива с удобной настраиваемостью, а Mailbird — вариант с упором на продуктивность для тех, кого не пугает подписка.

Инструменты разработчика

• Редакторы кода и текста: VS Code, Cursor, Sublime Text
• Система контроля версий: SourceTree, GitHub Desktop
• Контейнеры: Docker
• Локальные LLM: Ollama
• SFTP, загрузка файлов: WinSCP, Forklift

Для разработчиков Visual Studio Code — безусловный вариант. Бесплатный, лёгкий, но мощный, кроссплатформенный — тысячи расширений покрывают практически любой язык, фреймворк или инструмент. Набирающая популярность альтернатива — Cursor, редактор на базе VS Code с усиленной AI-помощью. Он подходит для связки с LLM: даёт inline-подсказки, генерирует код, рефакторит и позволяет редактировать кодовую базу.

При этом Sublime Text остаётся для скорости и простоты, а Notepad++ — отличный лёгкий редактор для быстрых правок в Windows.

Для Git графические клиенты SourceTree и SmartGit дают понятный интерфейс для управления репозиториями на GitHub, GitLab и не только. GitHub Desktop раньше был простоват и не слишком хорош, но сейчас существенно прибавил — всё ещё простой для работы, но в хорошем смысле.

Для локальных окружений, API-тестирования или терминального воркфлоу инструментов — пруд пруди. Например, Docker Desktop стал стандартом для тех, кто собирает и запускает контейнеризированные приложения на разных платформах. Он упрощает настройку окружений и держит систему чистой.

Ollama позволяет запускать большие языковые модели (LLM) локально с минимальной настройкой. Поддерживает модели вроде LLaMA, Mistral и другие open-weight альтернативы GPT, так что можно работать с ИИ прямо на своём компьютере без отправки данных в облако.

Если вы работаете с облачными хранилищами или SFTP, WinSCP (Windows) и ForkLift (macOS) — отличные клиенты с двухпанельным управлением файлами, синхронизацией и автоматизацией. На Mac также популярны Commander One и Transmit — у них есть встроенные подключения к удалённым и облачным путям.

Безопасность

И Windows, и macOS сегодня предлагают более чем достойную встроенную защиту. С защитой в реальном времени, интеграцией с файерволом и биометрией вроде Windows Hello и Touch ID. Для обычных пользователей, которые соблюдают гигиену безопасности: не скачивают сомнительное ПО, используют менеджеры паролей и включают 2FA — встроенной защиты часто хватает.

Для продвинутых пользователей есть дополнительные варианты.

Отличное первое дополнение — Malwarebytes. Это давний фаворит в обнаружении и удалении malware, adware и руткитов; бесплатная версия по-прежнему хороша для ручных сканов. В платной — защита в реальном времени без ощутимой просадки производительности.

Если не хочется ставить традиционный антивирус, есть достойные альтернативы. Emsisoft Emergency Kit — мощный портативный сканер, который можно запускать с флешки: идеально для редких глубоких сканов или лечения заражённых систем без установки чего-либо. Просто подключаете, когда нужно.

Ещё один отличный инструмент — VirusTotal: бесплатный веб-сервис, который проверяет файлы и URL через десятки антивирусных движков. Прежде чем открывать подозрительную загрузку, можно залить файл на VirusTotal.com или использовать их расширение для браузера, чтобы проверять ссылки в реальном времени. Быстро, просто и удобно для осторожных пользователей.

Мы не поклонники установки антивирусов на каждый компьютер и не полностью в курсе, какие сейчас показывают лучшие результаты. Тем не менее, AV-Test давно и регулярно оценивает популярные решения, поэтому советуем смотреть их свежие отчёты. В текущем списке высокооценённых — Avast, BitDefender, ESET и другие; многие из них предлагают бесплатные версии для пробы.

Удалённый доступ и вспомогательные утилиты

RustDesk стал современным, ориентированным на приватность аналогом TeamViewer. Он с открытым исходным кодом, быстрый и работает кроссплатформенно.

Тем, кому нужны более устоявшиеся коммерческие решения, подойдёт AnyDesk, который остаётся лёгким и надёжным вариантом для личного и командного использования.

Превращение смартфона в пульт дистанционного управления компьютером бывает невероятно удобно — будь то презентации, потоковое видео или просто навигация с дивана.

Remote Mouse — простой и эффективный способ эмулировать мышь и клавиатуру с телефона. Для более продвинутых сценариев можно использовать приложения вроде Unified Remote.

Редактирование изображений и видео

• Профессиональный видеомонтаж: DaVinci Resolve
• Простой видеомонтаж: CapCut
• Редакторы изображений: GIMP, PhotoDemon, Pixelmator Pro
• Бесплатное улучшение изображений: Upscayl
• RAW-редактирование: RawTherapee
• Видеоконвертация: HandBrake

Если вам нужен бесплатный инструмент для редактирования изображений, GIMP — один из самых мощных вариантов. Он предоставляет профессиональные возможности, такие как слои, маски и настраиваемые плагины, что делает его идеальным для продвинутых пользователей. Если вы ищете более лёгкий редактор с чистым интерфейсом, стоит обратить внимание на PhotoDemon. Он работает как портативное приложение на Windows, поддерживает слои и редактирование — отличный выбор для быстрых правок или ретуши.

Если вы хотите увеличивать разрешение изображений без потери качества, Upscayl — мощный и бесплатный инструмент для апскейла. Он кроссплатформенный, и по нашим тестам показывает результаты на уровне платных решений вроде Topaz.

Для векторной графики — логотипы, иллюстрации — Inkscape является достойным open-source вариантом с полной поддержкой редактирования SVG. Krita — ещё один отличный бесплатный инструмент, особенно подходящий для цифровой живописи и художественного творчества.

Для редактирования RAW-фотографий, Darktable и RawTherapee — два высококлассных open-source аналога Adobe Lightroom. Их широко используют фотографы, которым нужна работа с изображениями без подписки.

Для простых GIF-анимаций ScreenToGif — удобная утилита, мгновенно записывающая область экрана и экспортирующая в GIF или другие форматы с оверлеями.

Среди платных фоторедакторов Adobe Photoshop остаётся лидером, но для macOS есть Pixelmator Pro — мощное приложение с разовой оплатой, а Affinity Photo предлагает профессиональные возможности по более доступной цене.

Видеомонтаж и конвертация

DaVinci Resolve считается лучшим бесплатным профессиональным ПО. Его используют и энтузиасты, и профессионалы — от простого тримминга до цветокоррекции и сложного постпродакшена.

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

Для пользователей macOS iMovie предустановлен и остаётся надёжным вариантом для базовых видео. Если вам нужно просто конвертировать или сжимать видео в современные форматы, HandBrake — проверенное бесплатное решение с поддержкой и вариацией входных и выходных форматов.

Тем, кто ищет топовый профессиональный монтаж, подойдут Adobe Premiere Pro и Final Cut Pro, но там есть дорогая подписка и более высокий порог входа.

Коммуникации и совместная работа

• Для повседневной связи: WhatsApp, Messenger и Zoom, если у вас нет FaceTime
• Для приватности: Signal
• Для работы: Slack, Teams
• Для игр и общения: Discord

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

Для личной переписки WhatsApp и Facebook Messenger остаются самыми массовыми платформами по всему миру. У них есть десктопные клиенты и встроенное сквозное шифрование по умолчанию. Telegram также крайне популярен благодаря синхронизации между устройствами и поддержке крупных чатов. Пользователи Apple продолжают активно использовать iMessage для приватного, шифрованного общения в экосистеме Apple.

Из видеоконференций Zoom остаётся одним из лидеров для групповых звонков и онлайн-ивентов, предлагая локальные записи, демонстрацию экрана и комнаты (breakout rooms). Однако бесплатный тариф ограничивает 1:1 звонки 40 минутами, если не перейти на платный план. Zoom поддерживает сквозное шифрование, но при включении E2EE отключаются некоторые функции вроде облачной записи и комнат.

Google Meet — отличный браузерный аналог без необходимости установки, который заметно улучшился по качеству и удобству использования. Многие компании применяют Meet в ежедневной работе и гибридных форматах. Если ваша организация использует Microsoft 365, скорее всего, вы работаете в Microsoft Teams, который уже заменил Skype на корпоративном уровне. Teams поддерживает большие созвоны, обмен файлами и глубоко интегрирован с Office. Сквозное шифрование доступно, но только для 1:1 звонков.

FaceTime по-прежнему отличный для пользователей Apple, и благодаря новым обновлениям к звонку теперь могут присоединяться и пользователи Android/Windows по ссылке через браузер.

Когда приватность критична, Signal — один из лучших вариантов. Разработан некоммерческой организацией, бесплатен, open-source, без рекламы, использует надёжное сквозное шифрование для сообщений и звонков.

Для рабочих коммуникаций Slack и Teams продолжают использоваться в бизнес-среде. Бесплатный тариф Slack ограничивает историю 90 днями и звонки, но остаётся любимцем стартапов и малых команд благодаря интеграциям и ботам. Cisco Webex — также крепкий вариант, особенно популярен в корпоративной среде.

Если вы работаете с креативными командами, сообществами или геймерами, Discord стал явным лидером. Изначально созданный для игр, он превратился в полноценную коллаборативную платформу с текстом, голосом и видео, стримингом экрана и ботами для автоматизации. Многие комьюнити — и даже IT-компании — используют Discord как основной рабочий инструмент.

Для внутриигрового голосового чата TeamSpeak остаётся олдскульным достойным вариантом: можно использовать анонимно и получать полный контроль над сервером. Встроенный чат Steam лучше, чем раньше, и помогает в игровой координации, но большинство всё же выбирает Discord.

Гейминг, моддинг и стриминг

• Игровые платформы: Steam, Epic Games, EA App, Ubisoft, GOG
• Последние драйверы для GPU: Nvidia GeForce, AMD Radeon, Intel Arc
• Стриминг: OBS Studio

Steam остаётся центром PC-игр. Это не только магазин, но и социальная платформа, лаунчер и площадка с модами, облачными сохранениями и встроенным стримингом. Регулярные распродажи, поддержка контроллеров и сообщества делают его обязательным для любого PC-геймера.

Не менее важно установить Epic Games Store. Хотя библиотека меньше, он регулярно раздаёт бесплатные игры, доступные любому с аккаунтом Epic. Это также must-have, если вы играете в Fortnite.

Помните: не все издатели размещают игры на Steam или Epic. Для тайтлов EA понадобится EA App (ранее Origin), для Ubisoft — Ubisoft Connect, для Blizzard/Activision — Battle.net, а GOG Galaxy не только предлагает DRM-free классику, но и может агрегировать игры из других лаунчеров.

Некоторые сверхпопулярные игры распространяются отдельно: Minecraft (через Minecraft.net или Microsoft Store), Roblox, League of Legends и Valorant (через лаунчер Riot Games). Если вы новичок и ищете что-то лёгкое, можно начать с free-to-play тайтлов или классики вроде Brutal Chess или GZDoom.

Если вы играете с геймпадом, Windows поддерживает Xbox-контроллеры из коробки. PlayStation-контроллеры теперь тоже отлично работают: Steam через Steam Input поддерживает DualShock 4 и DualSense практически во всех играх. При необходимости глубокой кастомизации можно использовать DS4Windows, но большинству хватает возможностей Steam.

Если вас интересует моддинг, хороший менеджер модов время в этой жизни:

• Mod Organizer 2 — лучший для RPG Bethesda (Skyrim, Fallout).
• Vortex (от Nexus Mods) — дружелюбный к новичкам и поддерживает широкий перечень игр.

Для записи геймплея или стриминга Nvidia ShadowPlay и AMD Radeon ReLive подходят для простых задач. Но для стриминга с вебкой, сценами, оверлеями или многосценовым продакшеном OBS Studio — безальтернативный лидер. Он бесплатный, open-source и подходит как новичкам, так и про-стримерам (Twitch, YouTube, Kick и т.д.). SignalRGB помогает синхронизировать весь RGB-зоопарк и задавать динамические эффекты.

Мониторинг железа и разгон

• Мониторинг: CPU-Z, HWMonitor, HWiNFO64
• Настройка и разгон: Afterburner, FanControl, ThrottleStop, SignalRGB

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

Начать стоит с CPU-Z — классического бесплатного инструмента, показывающего информацию о CPU, материнской плате, оперативной памяти и других компонентах. Он также умеет запускать простой стресс-тест и бенчмарк для проверки стабильности.

Для более широкого мониторинга HWMonitor показывает температуры, напряжения и скорости вентиляторов в реальном времени. Если нужно ещё глубже и с более гибким интерфейсом — HWiNFO64 считается одним из лучших: поддерживает логирование датчиков и интеграцию с оверлеями (например, RTSS или Rainmeter).

Чтобы проверить хранилище, CrystalDiskMark измеряет скорость чтения/записи SSD и HDD — это помогает понять, соответствует ли диск заявленным характеристикам. Глубже оценить здоровье накопителя можно в Hard Disk Sentinel, который анализирует SMART-данные, оценивает срок службы и предлагает ограниченный ремонт.

С точки зрения охлаждения, всё больше геймеров используют утилиты для настройки вентиляторов. FanControl — актуальный бесплатный фаворит: поддерживает сложные кривые оборотов, привязку к датчикам, и совместим с большинством современных материнских плат. На Mac одной из лучших утилит остаётся Macs Fan Control.

Для настройки видеокарт долгое время стандартом был MSI Afterburner — для разгона, настройки вентиляторов и мониторинга с RTSS-оверлеем. Однако из-за замедления обновлений многие сегодня используют встроенные утилиты от Nvidia (GeForce Experience/Control Panel) и AMD (Adrenalin Software).

Если вы меняете видеокарту или подозреваете проблемы с драйверами, обязательно используйте Display Driver Uninstaller (DDU) — он полностью очищает систему от старых драйверов перед переустановкой.

Если вы играете на ноутбуке или хотите снизить нагрев и повысить автономность, ThrottleStop остаётся одним из лучших инструментов для андервольта CPU и настройки энергопрофилей.

Тем, кто серьёзно подошёл к разгону CPU и GPU, пригодятся фирменные инструменты вроде Intel XTU (для Intel) и AMD Ryzen Master — они дают контроль над частотами, напряжениями и лимитами мощности.

Управление файлами

• Поиск больших файлов: SpaceSniffer, WizTree, Disk Drill (macOS)
• Поиск дубликатов: dupeGuru
• Архивы и ZIP: PeaZip, The Unarchiver
• Очистка: BCUninstaller, CCleaner Portable, AppCleaner (macOS)

Чтобы грамотно управлять файлами и освобождать место, нужно понимать, что именно занимает пространство. На Windows популярны WinDirStat и WizTree — быстрые бесплатные инструменты для визуализации диска. SpaceSniffer предоставляет динамическую схему.

На macOS — GrandPerspective и Disk Drill предлагают аналогичный функционал, а DaisyDisk — один из самых красивых платных вариантов с молниеносным сканированием.

Если дубликаты засоряют диск, dupeGuru (open-source) отлично справляется с поиском повторяющихся изображений и музыки, даже слегка изменённых.

Для пакетного переименования файлов (например, фоточек с камеры) существует гибкий Bulk Rename Utility. Если нужно что-то попроще: PowerRename из PowerToys (Windows) или встроенный инструмент в Finder (macOS) подходят большинству.

Встроенный File Explorer в Windows недавно получил вкладки и стал удобнее, но Files (open-source) — современная альтернатива с улучшенным UX. Кто-то ещё пользуется Total Commander или Directory Opus, благодаря расширяемости и скриптам, хотя новичкам они кажутся устаревшими. Для просмотра изображений по-прежнему незаменим IrfanView.

Для работы с архивами, если не устраивает встроенный ZIP-менеджер Windows, скачайте 7-Zip или PeaZip. На Mac лучшим бесплатным инструментом остаётся The Unarchiver.

Для очистки системы важно выбирать надёжные утилиты. На Windows, BCUninstaller (Bulk Crap Uninstaller) — один из самых проверенных для удаления программ и их хвостов. BleachBit и Wise Disk Cleaner — безопасные альтернативы CCleaner (лучше использовать Portable-версию, так как стационарная испортила репутацию). На Mac AppCleaner всё ещё любим за полное удаление приложений без мусора.

Если вы организуете большую библиотеку медиа, стоит взглянуть на open-source TagSpaces, позволяющий тегировать файлы локально, без облака.

Облачное хранилище и резервное копирование

• Простая синхронизация: Dropbox, Google Drive
• Фото между устройствами: Apple iCloud, Google Photos
• Приватность: pCloud, Proton Drive, Internxt
• Полные бэкапы: Backblaze, IDrive

Базовое облачное хранилище

Dropbox — один из самых простых в использовании, хотя бесплатных 2 ГБ мало.

Google Drive — 15 ГБ бесплатно, используется Gmail, Docs и Photos. Идеален для Android.

OneDrive — идёт в комплекте с Windows и Microsoft 365. 1 ТБ включён в большинство Office-планов. Хотя по скорости и интерфейсу уступает Dropbox/Google.

iCloud Drive — лучший выбор для пользователей Apple, глубокая интеграция с macOS/iOS. Бесплатно 5 ГБ, далее по планам до 2 ТБ.

Proton Drive — шифрованная альтернатива от создателей ProtonMail.

Фото и видео

На macOS приложение Photos автоматически создаёт альбомы по людям и локациям, синхронизирует всё через iCloud.

На Windows мы часто рекомендуем Google Photos, который предлагает аналогичный набор функций и автоматизацию. Для пользователей Android — это стандарт по умолчанию. Да, раньше было безлимитно, теперь фото занимают общее место Google Drive (15 ГБ), которое быстро заканчивается.

Полные бэкапы

Если требуется сохранять всю систему, терабайты медиа, состояние дисков используйте отдельные сервисы резервного копирования.

Backblaze — топ в этой категории: фиксированная цена (~$8/месяц за устройство), безлимитное хранилище, минимум настроек: установил и забыл.

IDrive — более контролируемый вариант, поддерживает несколько устройств, внешние диски и версионность файлов.

Простой для не-технарей — Carbonite, с возможностью быстрого восстановления и круглосуточной поддержкой.

Профессионалам — Acronis Cyber Protect: клон дисков, анти-вымогатель, гибридное облако.

Для особо чувствительных данных

Если вы храните личные финансовые документы или медицинские сведения, стоит выбрать end-to-end решений.

pCloud предлагает клиентское шифрование (через платный «Crypto»). Даже при взломе аккаунта файлы не расшифруются без ключа.

Proton Drive — аналогичный подход, с прозрачностью open-source.

Прочие полезные инструменты, не вошедшие в другие разделы

Google Earth — для любителей карт и планировки.

qBittorrent — лучший torrent-клиент: чистый, без рекламы, с поиском. Альтернатива — легковесный Transmission или кастомизируемый Deluge.

iMazing — must-have для владельцев iPhone: резервные копии, экспорт медиа, проверка батареи, конвертация HEIC.

AirDroid — аналог для Android: управление файлам, уведомления, SMS с ПК.

Rufus — лидер по созданию загрузочных USB-дисков для Windows/Linux.

Open Shell — возвращает классическое меню «Пуск» в стиле Windows 7.

Stretchly — напоминает делать перерывы — полезно удалёнщикам и фрилансерам.

AutoHotkey — скриптовый движок для Windows: переназначение клавиш, макросы, автоматизация.

VPN: бесплатные — ProtonVPN, Windscribe, TunnelBear (с лимитом). Платные — ProtonVPN, NordVPN.

Calibre — лучшее бесплатное решение для чтения, организации и конвертации e-book (EPUB, MOBI, PDF и др.).

Заключение

Итак, мы прошлись по основным категориям приложений, которые стоит установить на новый компьютер. Конечно, этот список не исчерпывающий — у каждого свои задачи и предпочтения. Но если вы установите хотя бы половину из перечисленного, ваш компьютер станет гораздо удобнее и функциональнее.

Несколько советов напоследок:

1. Не захламляйте систему. Устанавливайте только то, что действительно используете. Чем меньше фоновых процессов — тем быстрее работает компьютер.
2. Следите за обновлениями. Большинство программ обновляются автоматически, но некоторые требуют ручного апдейта. Свежие версии — это не только новые функции, но и закрытые уязвимости.
3. Делайте резервные копии. Никакие утилиты не спасут от отказа жёсткого диска. Регулярный бэкап на внешний носитель или в облако — обязательная практика.
4. Экспериментируйте. Попробуйте несколько браузеров, редакторов, плееров. То, что подходит большинству, может не подойти именно вам.
5. Читайте отзывы. Перед установкой незнакомого приложения загляните на форумы или Reddit. Сообщество быстро выявляет проблемы и подводные камни.

Теперь ваш компьютер готов к работе, учёбе, развлечениям — и чему угодно ещё. Главное — не забывайте, что инструменты важны, но ещё важнее то, как вы их используете. Удачи!

По словам Карпати, NanoChat — это полный стек LLM-платформы, включающий токенизацию, обучение, дообучение, оценку, инференс и веб-интерфейс, позволяющий общаться с моделью прямо из браузера. Все работает на одном узле с 8 GPU H100 и запускается одной командой:

Обучение занимает около четырех часов и стоит примерно $100 при аренде облачного сервера Lambda Labs. После этого можно открыть локальный веб-интерфейс и «болтать» с собственной моделью как с ChatGPT.

Собери сам

Карпати описывает NanoChat как «чистый, минималистичный и хакабельный код», который подойдет тем, кто хочет понять, как устроен ChatGPT изнутри.

Репозиторий включает всего около 8000 строк кода и написан в основном на Python (89%), с минимальными вставками на Rust и HTML.

NanoChat — это не гигантская инфраструктура, а сильная и прозрачная база, на которой можно построить свой LLM с нуля.

Он также подтвердил, что проект станет частью нового курса LLM101n, который готовит его команда Eureka Labs.

Что под капотом

NanoChat использует простую пайплайн-архитектуру с поддержкой этапов pretraining, fine-tuning, evaluation и serving, а также встроенный сервер чата на Python (python -m scripts.chat_web).

Результаты обучения сохраняются в виде «отчетной таблицы» с ключевыми метриками (ARC, GSM8K, MMLU).

Open source и вдохновение

NanoChat распространяется под лицензией MIT и вдохновлен предыдущими проектами Карпати — nanoGPT и сообществом разработчиков на Hugging Face.

Как подчеркивает автор, цель NanoChat — демократизировать ИИ, сделав разработку больших языковых моделей понятной и доступной «для всех, у кого есть $100 и немного любопытства».

Мужчина 17 лет проработал в образовательной IT-компании и, по просьбе руководства, активно внедрял искусственный интеллект в работу.

«Я считал ChatGPT напарником»

По словам Кантерры, он быстро освоил искусство правильных промтов и использовал нейросеть для подготовки текстов, исследований и анализа данных.

Я рассматривал ИИ как соавтора. Моя продуктивность была просто запредельной.

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

Ирония цифровой эпохи

Кантерра не единственный, кто попал в подобную ситуацию. По данным американских СМИ, все больше компаний сокращают персонал, заменяя специалистов «умными агентами».

Однако исследования MIT показывают: 95% таких внедрений не приносят роста выручки. Напротив, замена людей создает больше хаоса и «ИИ-мусора», который потом приходится исправлять вручную.

«Это пугает»

Я уверен, что они пытаются проверять то, что выдает ИИ. Но теперь у них нет людей, которые могли бы это делать качественно. Это просто страшно

История Кевина стала символом новой дилеммы для работников: осваивать ИИ, рискуя потерять работу, или сопротивляться и отстать от прогресса.

31-летний Деклан из Лос-Анджелеса узнал об этом случайно. Во время онлайн-сеанса у терапевта начались проблемы со связью, и тот по ошибке включил демонстрацию экрана. На глазах у пациента специалист копировал его фразы в ChatGPT, получал ответы и тут же пересказывал их как собственные. «Я просто сидел и смотрел, как он чатится с ИИ, пока делает вид, что слушает меня», — рассказал Деклан. После неловкого разговора терапевт признался, что «испытывал профессиональный тупик» и решил искать вдохновение в нейросети.

История Деклана — не единичный случай. На Reddit и форумах психотерапевты и клиенты всё чаще обсуждают похожие эпизоды. Некоторые пациенты жалуются на «неестественные» письма от терапевтов: слишком выверенные формулировки, американизмы и одинаковый стиль изложения. В одном из случаев пользовательница по имени Хоуп получила от своего психотерапевта ответ на сообщение о смерти питомца, где в начале письма случайно сохранилась подсказка: «Here’s a more human, heartfelt version with a gentle, conversational tone».

Психологи и исследователи предупреждают, что такие эксперименты могут разрушить доверие — основу терапевтических отношений. Согласно исследованию, опубликованному в PLOS Mental Health в 2025 году, ответы ChatGPT на клиентские кейсы оказались неотличимы от человеческих и даже оценивались выше по профессиональным стандартам. Но как только участники узнавали, что их автор — ИИ, доверие резко падало. Аналогичные результаты получили учёные из Корнелла: эффективность и эмпатия обрушивались, если человек хотя бы подозревал участие нейросети.

Эксперты подчёркивают, что главная угроза — не только эмоциональная. Терапевты, использующие публичные модели вроде ChatGPT, потенциально нарушают законы о защите медицинских данных (HIPAA). Как отмечает исследовательница из Университета Дьюка Пардис Эмами-Наэини, большинство пользователей ошибочно полагают, что ChatGPT безопасен для передачи личной информации. На деле любая фраза, введённая в такой инструмент, может стать частью тренировочных данных и раскрыть детали частной жизни пациентов.

Тем временем на рынке появляются специализированные решения — от Heidi Health до Upheal — которые обещают безопасное хранение данных, HIPAA-сертификацию и ИИ-помощь для психотерапевтов. Но даже сторонники таких платформ предупреждают: запись сессий и автоматическая расшифровка неизбежно создают риски утечки. В 2020 году взлом психиатрической клиники в Финляндии привёл к публикации тысяч терапевтических записей, включая истории о насилии и зависимостях.

Есть одна задача, которую программисты терпеть не могут — но именно она отличает хорошего инженера от посредственного: как они документируют свой проект? Несколько лет назад я отвечал за запуск финтех-проекта. Мы выбрали стратегию быстрого старта, поэтому масштабируемость не стала для нас приоритетом. Главной целью было проверить гипотезу — и мы двигались вперёд, разрабатывая API, архитектуру и системы — с упором на простоту, не особенно задумываясь о будущем.

Но я отвечал за бэкенд и инфраструктуру — и понимал: как бы хороша ни была моя память, через шесть месяцев я не смогу вспомнить все технические детали.

Во время работы я наткнулся на подход, который мне очень понравился: ADR — Architectural Decision Record, или «протокол архитектурных решений».

По сути, это документ, в котором фиксируются все изменения, внесённые в архитектуру: само решение, его влияние и полученные уроки.

Проще говоря, это как личный дневник — только для всей команды.

Почему это важно?

Память — ненадёжна. Мы часто забываем, почему выбрали одну архитектурную модель, а не другую. Документирование изменений помогает восстановить ход мыслей и избежать повторения одних и тех же ошибок.

Это усиливает команду. Представьте, что вы перепробовали несколько вариантов решения проблемы и зафиксировали как удачные, так и неудачные попытки. Это не просто ваш личный опыт — это знание, которым могут воспользоваться все, включая тех, кто придёт после вас.

Будущие разработчики скажут вам спасибо. Подумайте о человеке, который через пять лет будет разбираться в вашем коде. Если вы не оставили объяснений, он, скорее всего, будет мучиться, пытаясь понять, зачем было сделано то или иное изменение. А теперь представьте другого разработчика в другой компании, который находит ADR-документ с чётким объяснением принятого решения. Он, без сомнения, будет вам благодарен.

Синьор-фронтендер из ВК Маргарита Лукина, автор телеграм-канала «Фронтенд кухня»:

Ценность ADR я впервые осознала в 2019 году. В команду, где работала, активно набирали новых ребят, и приблизительно раз в неделю кто-нибудь из новых разработчиков спрашивал "а почему это сделано так, а не иначе?" Приходилось постоянно давать ответы на одни и те же вопросы, и тогда-то я и поняла, насколько будет удобно записывать ответы где-нибудь в документацию в confluence и просто кидать ссылку новичкам.

В 2019 году я еще не знала сам термин ADR и говорила "документация". С термином я познакомилась совсем недавно — этим летом, на курсе по архитектуре монолитных приложений. Тогда я поняла, насколько эффективно можно использовать ADR для ускорения разработки и уменьшения TTM. Дело в том, что начиная разрабатывать новый проект, разработчик первое время (от месяца до полугода! всё зависит от размера проекта) погружается в проект — разбирается, как всё устроено, чтобы вносить изменения соответственно архитектуре. В этот период разработчик, по сути, составляет собственные adr — обычно в виде мыслеобразов в своей голове :) Если записать основные решения, разработчик сможет намного быстрее погрузиться в проект.

Как писать ADR?

Существует несколько общепринятых правил, но вы всегда можете адаптировать их под себя.

Вдохновившее меня соглашение можно найти на GitHub . Вы также можете ознакомиться с процессом ADR на Amazon.

Вот пример шаблона, который вы можете использовать.

Такой тип документа может находиться прямо в репозитории проекта, в Confluence или, например, в JIRA.

В моей последней компании, где я работал фронтенд-разработчиком, не существовало одного централизованного документа, фиксирующего все архитектурные изменения. Вместо этого мы использовали задачи GitLab и привязывали каждое архитектурное изменение к соответствующей ветке. Это позволяло отслеживать причины изменений даже спустя месяцы после их внедрения.

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

Синьор-фронтендер из ВК Маргарита Лукина, автор телеграм-канала «Фронтенд кухня»:

Многие руководители хотят видеть на своём проекте разработчиков, которые "сразу, без раскачки" начнут перформить. Совсем избежать периода погружения невозможно, но можно ускорить его в десятки раз за счёт ADR

Исследование под названием The GenAI Divide: State of AI in Business 2025 показало, что лишь 5% проектов создают ощутимую экономическую выгоду. Остальные — просто сжигают бюджеты, не улучшая бизнес-показателей.

Но эта новость — скорее хорошая, чем плохая. Потому что она означает: человеческий труд пока незаменим, а ИИ не настолько умен, как его преподносят.

ИИ-системы не виноваты — виноват менеджмент

Как подчеркивают авторы отчета, проблема не в самих ИИ-инструментах, а в том, как их используют. Руководство многих компаний делает ставку на хайповые витрины — маркетинг, автоматическую генерацию контента, чат-ботов и прочее. Эти решения выглядят эффектно, но редко влияют на выручку.

А вот реальную пользу приносят скучные, но важные процессы: автоматизация учета, документооборота, логистики, финопераций. ИИ может сократить рутину, чтобы сотрудники занимались задачами с реальной добавленной стоимостью, а не просто «заменял» людей.

Маленькие стартапы справляются лучше, чем корпорации

Лидер исследования, Адитья Чаллапалли, отметил, что стартапы с командами по 20 человек показывают лучший результат, чем корпорации из списка Fortune 500.

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

Некоторые из них за год вырастают с нуля до $20 млн выручки — просто потому что точно понимают, какую боль решают. И, как итог, применяют ИИ как инструмент, а не как самоцель.

Для тех же, кто ищет работу, это тоже важный сигнал: в стартапах проще научиться чему-то полезному, а самые интересные вакансии — в тех компаниях, где ИИ помогает бизнесу, а не просто присутствует для отчета.

Что делать тем, кто боится потерять работу?

Главное — не впадать в панику. Но и игнорировать ИИ не стоит. Побеждают те, кто умеет с ним сотрудничать, а не воевать.

Компании ищут людей, которые умеют:

• Понимать, где ИИ реально экономит время и деньги.
• Переводить бизнес-проблему на язык технологий.
• Оптимизировать процессы, а не просто повторять «я умею пользоваться ChatGPT».

Если вы соискатель, не ограничивайтесь фразой «умею работать с нейросетями».

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

Что интересно, компания задала датой коммита 27 июля 1978 года, 22:00 по московскому времени. Таким образом, формально коммиту — 47 лет.

Исторический артефакт в прямом эфире

Проект под названием BASIC-M6502 содержит полный исходный код Microsoft BASIC версии 1.1. Это один из самых ранних программных продуктов компании, написанный между 1976 и 1978 годами.

BASIC 1.1 стал основой для множества персональных компьютеров, включая:

• Apple II — революционный домашний ПК от Джобса и Возняка.
• Commodore PET — один из первых массовых компьютеров.
• KIM-1, OSI, PDP-10 — популярные среди хобби-разработчиков системы.

Коммит из прошлого

В коммит-логе можно увидеть:

• Дата: July 27, 1978, 22:00 (GMT+3).
• Автор: Scott Hanselman (Microsoft).
• Файл: m6502.asm — 6955 строк ассемблера.
• Текст коммита: «Microsoft BASIC for 6502».

Microsoft явно вручную подставила дату коммита, чтобы подчеркнуть историческую важность релиза.

Зачем Microsoft это выложила?

По словам авторов, это попытка сохранить цифровое наследие эпохи ранних ПК. В README подробно описано, почему именно этот код важен:

• Он сделал программирование доступным миллионам пользователей;
• Лицензирование интерпретатора стало основой бизнес-модели Microsoft;
• Код использовался до появления MS-DOS и Windows;
• Интерпретатор легко переносился на разные платформы, заложив принципы кроссплатформенной разработки.

Проект представлен как учебный и исследовательский ресурс, с MIT-лицензией.

Внутри — чистый 6502-ассемблер

Код представляет собой полноценный интерпретатор BASIC, написанный на ассемблере для процессора MOS 6502. Он включает:

• Поддержку арифметики с плавающей точкой.
• Обработку строк и массивов.
• Динамическое распределение памяти.
• Сборку мусора.
• Абстракцию ввода-вывода под разные платформы.

Также внутри есть журнал изменений с точными датами коммитов конца 70-х годов — например, фиксы в парсинге FOR-циклов, улучшения сборщика мусора и добавление пользовательских функций.

Это не просто учебный проект или архив. Это исходный код, с которого началась история Microsoft как софтверной компании. Без него не было бы MS-DOS, Windows и .NET

Однако вместе с ним компания по ошибке выложила и исходный код технологии FSR 4 (FidelityFX Super Resolution) — следующего поколения своей системы апскейлинга и увеличения fps в играх.

Публикация быстро исчезла, но было уже поздно: часть файлов осталась доступной в течение нескольких часов и пользователи успели создать форки.

Что именно произошло

Ошибка стала очевидна почти сразу после выхода SDK. AMD удалила репозиторий, но по состоянию на момент удаления, часть файлов все еще можно было скачать напрямую, а некоторые разработчики начали делать форки.

На GitHub есть подтверждения: код находился в открытом доступе и значился под лицензией MIT. Компания позже подтвердила утечку. В официальном комментарии для GPUOpen говорится:

Некоторые части нашего кода были по ошибке выложены в открытый доступ. Репозиторий был оперативно удален

В чем суть FSR 4 и почему это важно

FSR 4 должна стать новой версией открытой технологии AMD, конкурирующей с DLSS от NVIDIA и XeSS от Intel. Однако, в отличие от FSR 1–3, AMD не подтверждала, что FSR 4 будет открытой. Тем не менее, исходники все же оказались опубликованы — пусть и ненадолго.

Среди файлов, попавших в сеть, были шейдеры и структуры моделей с префиксом fsr_model_v07, что, по мнению исследователей, указывает на тестовую сборку с поддержкой INT8 и других экспериментальных возможностей.

Почему код, скорее всего, уже не удалить

Один из важных аспектов — опубликованные файлы находились под лицензией MIT. А это значит, что даже если репозиторий был удален, разрешение на использование кода уже было выдано — юридически это отозвать нельзя, если не нарушены условия лицензии.

Владелец кода (в данном случае AMD) не может отменить выданное разрешение задним числом.

Если вы скачали код во время его доступности на GitHub — формально вы получили права на его использование, модификацию и распространение, говорят юристы. Дальнейшее удаление кода эти права не отменяет.

Что теперь?

В сообществе обсуждают два сценария:

1. AMD может признать произошедшее как «выпуск» и продолжить работу с FSR 4 в открытом виде.
2. Или наоборот — закрыть разработку и не выпускать FSR 4 как open-source, повторив путь Intel с XeSS, которая так и не стала открытой, несмотря на обещания.

Какие ИИ-улучшатели открыты, а какие — нет

• AMD FSR с первой по третью были открытыми. FSR4 — случайно опубликована, но официально не подтверждена как open-source.
• NVIDIA DLSS — полностью закрытая технология.
• Intel обещала сделать XeSS open-source, но свое обещание не выполнила.

В условиях растущей конкуренции в ИИ-ускорении и генерации кадров, AMD, возможно, не захочет отдавать ключевую разработку в руки конкурентов.

Но если случайная публикация все же станет поворотным моментом — FSR 4 может остаться в истории как технология, которую открыли… случайно.

Генеративный ИИ больше не просто инструмент для текстов. Он становится полноценной точкой входа в интернет: здесь ищут товары, сравнивают характеристики и даже принимают решения о покупке — всё в одном окне. За один только праздничный сезон 2024 года трафик из ИИ-инструментов в американском онлайн-ритейле вырос на 1300% — такие данные приводит исследование Adobe.

По умолчанию ChatGPT работает без выхода в интернет и отвечает на основе своих знаний, накопленных при обучении. Но можно включить функцию вручную, нажав на значок глобуса 🌐 «Искать в сети». Модель сама понимает, что вам нужна актуальная инфа, и подключается к интернету автоматически — тогда вверху появляется плашка «Поиск в сети».

Гуглить стало старомодно. Аналитики заметили, что в англоязычной молодёжной среде глагол «гуглить» постепенно исчезает — они говорят просто «search it». ChatGPT уже обрабатывает около 1 млрд поисковых запросов ежедневно. Это влияет на воронку продаж: многие шаги теперь проходят внутри чат-ботов. Бренды начинают перестраивать свои стратегии: мало быть видимым в поиске. Теперь нужно быть понятным и убедительным для нейросетей. Потому что завтра товары будут искать не люди, а их ИИ-агенты.

Что не так с классической поисковой выдачей

Слишком много кликов. Первая страница выдачи забита рекламой, SEO-статьями, агрегаторами и рерайтами рерайтов. Чтобы получить один ответ, мало вбить запрос. Нужно пролистать рекламу, открыть пару сайтов, закрыть поп-апы с чатами и ещё проверить, что инфа свежая. И если результат не подошёл — начинаем всё заново.

SEO-мусор. Ещё одна беда — это тонны переоптимизированного контента. Статьи написаны по шаблонам, чтобы понравиться алгоритмам и вписаться в критерии ранжирования. Если вы искали «что посмотреть в городе Х», то наверняка в топе были тревел-агрегаторы, забитые рекламой. Вместо живых впечатлений мы получаем скучные списки с дежурным набором достопримечательностей и призывом купить тур. Кроме того, такие статьи, как правило, обезличены, и не понятно, кто за ними стоит.

ИИ-контент. Пользователь Reddit заметил, что при поиске «John Wick 5» Google выдал кучу сгенерированного контента о проекте, который даже не анонсирован.

В комментариях посоветовали использовать операторы — минус-ключи: -ai или -sponsored, чтобы исключить из результатов страницы с этими словами.

Проект deaddit документирует явление мёртвого интернета в формате ИИ-клона Reddit — поддельные посты, комментарии и целые сообщества, сгенерированные ИИ. С поддельными сабреддитами, названиями и описаниями, профилями пользователей с прописанными личностями и интересами, постами с заголовками, содержанием и даже количеством апвоутов, а также комментариями.

Паттерны поиска меняются. Всё меньше хочется читать безликие рекламные статьи, замаскированные под советы, и всё больше — слушать живых людей. Генеральный директор Reddit похвастался, что на фоне роста ИИ-контента именно Reddit остаётся площадкой с человеческим голосом.

Популярный лайфхак: добавлять в поисковые запросы слово «reddit» или оператор «site: reddit.com».

Я часто добавляю «reddit» к своим запросам, потому что это одно из немногих мест, где можно прочитать настоящие мысли людей.

Но не все так оптимистичны: звучат подозрения, что часть постов пишут боты.

Я не доверяю Reddit. Когда дело доходит до рекомендаций, у меня всегда возникает ощущение, что ответы пишут боты, рекламирующие продукты

Пользователи всё больше ощущают потерю «аутентичного интернета» и ищут обходные пути — обращаются к альтернативным поисковикам, вроде DuckDuckGo или Brave, и к другим площадкам, например, Discord или Telegram-чатам, которые не индексируются поисковиками. Или создают собственные поисковые движки — например, через Google Custom Search Engine, чтобы искать только по выбранным источникам.

Почему ИИ-поиск быстрее выдает желаемое

Нужно уметь гуглить в Гугле. Традиционный поиск — это сложная штука, требующая мощностей для обработки миллиардов проиндексированных страниц. Google справляется с этим благодаря продвинутым алгоритмам, отточенным за годы исследований. Но этого уже мало.

Ключ к успеху — правильная формулировка запроса. Сколько раз вы в несколько подходов перебирали варианты, меняли порядок слов, перефразировали запросы или добавляли поисковые операторы — чтобы сузить поиск, найти точные совпадения или исключить лишнее? И если не угадали — результата не будет. К счастью, ИИ-поисковики снимают эту головную боль. Они учитывают контекст, а не только ключевые слова, даже если формулировка хромает.

Мэт Хонан, главный редактор MIT Technology Review, сравнил Google AI Mode и ChatGPT. Он отметил ключевое преимущество последнего — функцию памяти и персонализации. Когда он спросил ChatGPT «Что ты знаешь обо мне?», модель ответила живо и подробно: рассказала о вкусах в кино, отношении к ужастикам и даже вспомнила историю с постройкой сарая. В то время как Google, обладая огромной базой пользовательских данных — почтой, историей поиска, фотографиями, — выдал сухой профиль: «Вы интересуетесь комедиями, музыкой, подкастами и классикой». Такой ответ скорее полезен рекламодателям, чем самому пользователю. На данный момент Google недотягивает до уровня персонализации, эмпатии и гибкости, которыми уже обладает ChatGPT.

Длинные запросы и эра диалогового поиска

ИИ меняет то, как мы ищем информацию. Если средний запрос в Google состоял из 3–4 слов, то в диалоге с нейросетью мы составляем запрос на естественном языке в 20+ слов — с нюансами и уточнениями. Но главное новшество — возможность задавать follow-up вопросы: уточнения к предыдущему запросу. Раньше нужно было начинать с чистого листа. Теперь ИИ «помнит» контекст и способен адаптироваться и уточнять ответы. Причём вернуться к этому чату можно и через год, не объясняя задачу заново. А еще можно сразу адаптировать найденную информацию под нужный стиль — «а попроще?», «а на русском?», «а в одну строку кода?».

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

Исследование Semrush показывает, что ChatGPT меняет привычные представления о поисковых намерениях. Если в классическом поиске запросы обычно делят на четыре типа: навигационные (найти сайт), информационные (узнать что-то), коммерческие (исследовать товар) и транзакционные (купить), то у ChatGPT только около 30% запросов вписываются в эти категории. Остальные 70% — это совсем другие задачи, которые редко встречаются в традиционных системах. Люди обращаются к ИИ не просто за фактами, а чтобы генерировать идеи, проводить мозговой штурм и глубоко копать в теме.

На самом деле «умный» поиск — не всегда быстрее обычного гугления. В режиме глубокого исследования (Deep Research) ИИ-система может тратить десятки минут, чтобы собрать источники и выдать аналитику. Это уже не просто поиск, а полноценный ассистент-аналитик, который помогает подготовить обзор или черновик по сложной теме.

Почему ChatGPT пока что плох в поиске: галлюцинации, спам и фейк-источники

1. Короткие запросы — всё ещё вотчина Google. Пока что у ChatGPT получается не очень.
2. Слабая фильтрация SEO-спама — классические поисковики годами инвестировали в борьбу с ним. Генеративные движки пока не так придирчивы: в ответах часто появляются вторичные источники и полусырые сгенерированные статьи.
3. Чрезмерное обобщение в ответах. Из-за «переупаковки» контента в ответ модели мы получаем «усреднённую» версию истины, в которой важные нюансы могут быть утеряны. Даже если ИИ не выдает ложную информацию, он все равно суммаризует и переформулирует контент способами, которые могут вводить в заблуждение.
4. Поддакивание и стремление угодить. Модель натренирована, чтобы быть вежливой и полезной. Она пытается выдать ответ даже тогда, когда не может его найти. Не потому что хочет нас обмануть, а потому что не умеет сказать «нет». Поэтому соглашается с нами и может поддержать самые безумные идеи, например, призывает есть камни.
5. Проблемы с локальными запросами. ChatGPT не расскажет, во сколько приедет ваш поезд, и не уточнит, открыт ли ближайший супермаркет. Он может найти рестораны в районе, но за актуальным меню — всё равно придётся идти в Google.
6. Цитирование — боль. Недавний рисерч Columbia Journalism Review выявил серьёзные проблемы в способности ИИ-поисковиков цитировать новости. Анализ восьми нейросетей показал, что они часто предоставляют неверные или вымышленные ссылки, даже если у них есть издательская лицензия.

Проблема и в том, как люди фактчекают информацию. Мы идем по пути меньшего сопротивления и выбираем самые простые пути для поиска ответов. Точность и достоверность отходят на второй план, а приоритетом становится скорость и комфорт. Результаты исследования показывают, что люди считают информацию, сгенерированную ChatGPT, более качественной и доступной по сравнению с Google Search.

Давайте будем реалистами — люди чрезвычайно ленивы. Они будут прилагать минимум усилий для достижения результатов. Даже если эти результаты отстойные. Людей это не волнует.

Это значит, что люди скорее зададут вопрос чат-боту и поверят любому ответу, который он выдаст. Ведь это проще, чем набирать текст в Google, а затем читать или пролистывать кучу статей.

Один из важных вопросов: как не потерять способность анализировать информацию самостоятельно? Ведь когда мы получаем готовый ответ от ИИ, можем перестать задумываться о том, как этот ответ был сформирован. Когда нейросеть даёт готовый, «отполированный» ответ, появляется соблазн воспринимать его как истину в последней инстанции — и перестать критически мыслить.

Иногда ChatGPT полностью лжет мне, и я знаю это только потому, что у меня есть существующие знания, что это неправда. Если бы у меня их не было, я бы никогда не узнал, что это неправда...Поэтому я не могу полностью полагаться на ChatGPT и всегда проверяю разные источники.

И это правда. Но и Google не гарантирует 100% точности в топе выдачи. Там тоже бывают ошибки, устаревшие данные или некачественные источники. Поэтому в любом случае важно проверять информацию и не полагаться слепо ни на ИИ, ни на поисковики.

Как генеративный ИИ крадет трафик и деньги бизнеса

ИИ теперь — как посредник: он «пережевывает» контент с сайтов: статьи, обзоры, новости — и выдает это пользователю в интерфейсе чат-бота. При этом юзер зачастую не доходит до первоисточника. Рэнд Фишкин из SparkToro назвал это «поисками с нулевым кликом». И таких запросов становится всё больше.

Что это значит? Контент журналистов, блогеров и брендов используется как сырьё, а сами авторы как будто остаются в тени — их труд не приносит прямого трафика.

Почему эта ситуация — головная боль для бизнеса и контент-мейкеров?

• Меньше посетителей — меньше клиентов. Если пользователи не заходят на сайт, то и конвертировать их в покупателей или подписчиков становится гораздо сложнее. Трафик просто утекает в интерфейс ИИ. Если нейросеть пересказывает суть статьи прямо в чате, зачем открывать оригинал?
• Потеря контроля над голосом бренда. ИИ решает, как преподнести ваш контент — может вырвать из контекста, искажать или просто упустить важные детали. Бренд уже не может поправить этот «пересказ». А ещё никто не увидит ваш уникальный дизайн и фирменный стиль.
• Рост нагрузки на серверы. ИИ-ассистенты и агенты автоматически перебирают десятки источников при каждом запросе. Опенсорс-сообщество уже жалуется: их ресурсы просто падают под лавиной ботов. А если этим займутся ИИ-агенты от имени миллионов пользователей — нагрузка на сайты вырастет в разы.
• Нарушение правил индексации. Раньше страницы индексировали Google и пара конкурентов, которые уважали robots.txt — файл, который говорит, где можно, а где нельзя. Сейчас же десятки ИИ-моделей парсят сайты без разбора, игнорируя эти ограничения.
• Проблемы с обучением ИИ и конфиденциальностью. ИИ-боты могут брать контент с сайтов не только для ответов, но и для обучения своих моделей. То есть ваша статья, обзор или даже комментарий могут стать частью «учебного корпуса», который помогает ИИ выдавать более «умные» ответы. При этом авторы часто не получают ни копейки и даже не знают, что их материалы используются таким образом. Многие сайты начали блокировать ИИ-ботов, чтобы защитить свой контент. Wired сообщает, что практически 90% новостных сайтов, таких как NYT, Guardian, Atlantic и др., блокируют краулеры OpenAI и других ИИ-компаний.

Если ИИ-разработчики продолжат брать контент без разрешения, их ждёт либо платный доступ к данным (они должны платить авторам за данные или переходить на лицензионную модель), либо война протоколов с нарушением веб-этикета. Ahrefs провели исследование — они проанализировали около 140 миллионов сайтов и обнаружили, что за последний год количество блокировок ИИ-ботов существенно выросло. Вот ключевые цифры:

• Число активных ИИ-ботов в сети удвоилось с августа 2023 года, сейчас насчитывается 21 крупный бот на основе ИИ.
• Самый блокируемый бот — GPTBot от OpenAI: его блокируют почти 6% всех сайтов.
• ClaudeBot (Anthropic) показал самый резкий рост блокировок — +32,67% за год.

Получается, что для веб-мастеров заготовлена новая головоломка: как гарантированно попасть в выдачу нейросетей, если краулеры игнорируют robots.txt? И можно ли вообще вычеркнуть сайт из этих списков? Как оптимизировать облегчённую версию сайта для ИИ-агентов, чтобы не перегружать сервер и не потерять контроль над контентом?

Cloudflare разработали «кнопку» блокировки AI‑ботов, чтобы снизить подобные нагрузки. Подключить эту функцию может любой пользователь Cloudflare, включая бесплатные тарифы. Компания, которая специализируется на защите сайтов от атак, заметила, что ежедневно на её сеть приходится около 50 миллиардов запросов от ИИ-ботов. В ответ они запустили AI Labyrinth — «лабиринт ИИ-контента», куда попадают незваные боты, игнорирующие директивы no crawl, где они застревают в бесконечной цепочке перелинкованных страниц.

Переосмысление SEO в эпоху ИИ

Классическое SEO уходит в прошлое. Чтобы оставаться на плаву, брендам и авторам нужно учиться говорить с ИИ на его языке. Вот почему появляются новые методы и направления — AIEO и GEO:

• AIEO (Artificial Intelligence Engine Optimization) — оптимизация контента под ИИ-системы. Неважно, это голосовой помощник или чат-бот — задача AIEO сделать контент максимально понятным и «перевариваемым» для ИИ, чтобы он попадал в их ответы.
• GEO (Generative Engine Optimization) — это оптимизация именно под генеративные поисковые системы (например, Bing Chat, Google AI Mode).

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

1. Чёткая структура: подзаголовки H2 и H3, чтобы разбить текст на логичные блоки.
2. Короткие, простые абзацы — никаких длинных занудных объяснений, только по делу.
3. Контент, который отвечает на вопросы: «что это», «зачем нужно», «пример на практике». Не просто набор ключевых слов, а полезная информация.
4. Внешние упоминания и ссылки — ИИ нравится, когда ваш контент не в изоляции, а подтверждён другими источниками.
5. Участие в специальных программах: можно подать заявки в ChatGPT Product Discovery, чтобы товар показывался в ответах ChatGPT или Perplexity Merchant Program — для крупных продавцов с доставкой в США, чтобы товары попадали в виджеты Perplexity.

Как оценить эффективность? Сейчас в аналитике уже можно увидеть переходы с нейросетей — они отображаются в отчетах по источникам трафика. Плюс появились метрики видимости бренда в ответах ИИ. Например, Ahrefs теперь показывает, как часто ваш бренд упоминается в ответах нейросетей. А новые сервисы помогают мониторить появление бренда в ИИ-результатах, отслеживать тональность упоминаний и анализировать динамику.

Это похоже на SEO начала 2000-х, когда с каждым обновлением алгоритма приходилось перестраиваться. С ИИ та же история: модели постоянно меняются, и нам придётся учиться работать с ними заново — иначе рискуем потерять трафик.

Конец эры поисковиков? Действительно ли нейросети заменят Google

Стоит ли ожидать полного исчезновения поисковиков? Вряд ли. Так же, как и исчезновения библиотек с появлением интернета. ИИ пока не заменит Google в роли поисковой системы, но классические поисковики со временем станут не актуальны из-за изменения природы потребления контента.

Пока Google лидирует, оставаясь примерно в 26 раз популярнее ChatGPT по ежедневным визитам. Совокупно ИИ-сервисы генерируют всего около одного процента от всех поисков Google. Но скорость роста говорит сама за себя: чат-боты за год выросли по количеству обращений на 80,92%. Впервые с 2015 года, к концу 2024-го, доля Google на рынке поиска опустилась ниже отметки в 90%. Однако аналитики OneLittleWeb считают, что чат‑боты и поисковики не конкурируют, а дополняют друг друга — каждый решает свои задачи. Чат-боты расширяют возможности поиска, превращая его в диалог и помощь в генерации идей, а поисковики интегрируют ИИ-сводки, чтобы ускорить выдачу информации.

Поисковики превращаются в умных ассистентов, которые сами сканируют интернет и дают готовые ответы. Но есть проблема: Google AI Overviews уже бьют по доверию и трафику. А главное — эти сводки не всегда точны. Техногигант тестирует ещё и AI Mode — чат прямо в поиске, который синтезирует инфу из разных источников. Кнопка «Мне повезёт» уходит в прошлое — теперь вам повезёт, если ИИ не нафантазирует лишнего. В России аналогичный тренд: Яндекс Нейро тоже объединяет классический поиск с генеративными нейросетями и умеет отвечать на комплексные запросы, копаясь в нескольких темах сразу. Поиск уходит в сторону диалогов и действий, и это уже не эволюция — это смена парадигмы.

Кто и как будет искать информацию завтра? Мир движется к более удобным и быстрым способам получения информации. Возможно, скоро все мы перестанем вводить запросы в строку поиска и будем давать задания своим ИИ-агентам. Пока зарождаются новые стандарты — GEO и AIEO, бизнесу стоит задуматься не только о том, как попасть в ответ ИИ, но и как ИИ сможет воспользоваться его услугами. Нужны будут инструкции и цифровая инфраструктура, понятная для агентов. В мире, где задачи будет выполнять не человек, а агент, нужны понятные инструкции и цифровая инфраструктура. Намечается новый тренд — agent-responsive design: сайты, которые удобны не только для людей, но и для ИИ.

Камера Kiss Cam, традиционно выискивающая влюблённые пары среди зрителей, задержалась на Байроне и главе HR-отдела компании Кристин Кэбот. Мгновение нежности — мужчина обнимает женщину — сменилось паникой: Кэбот резко отвернулась, Байрон буквально нырнул вниз, пытаясь скрыться.

Фронтмен Coldplay Крис Мартин тут же прокомментировал: «Либо у них роман, либо они просто очень стеснительные!». Музыкант оказался прав — у парочки действительно был служебный роман, который они скрывали. Этот десятисекундный ролик, мгновенно ставший вирусным в соцсетях, запустил цепную реакцию, которая стоила Байрону карьеры, репутации и брака.

Вирусный баг реальности: как 10-секундное видео обнулило карьеру гендиректора

Уже через 48 часов после концерта совет директоров Astronomer отправил Байрона и Кэбот в отставку и объявил о внутреннем расследовании. Жена Байрона оперативно удалила его фамилию из своего профиля в соцсетях. Пиар-команда Astronomer утонула в запросах СМИ. Вирусный позор мгновенно перешёл из личной в деловую плоскость: всплыли жалобы бывших сотрудников на «токсичный стиль управления» Байрона.

Новый CEO Astronomer Пит ДеДжой в своём первом заявлении констатировал: «Astronomer теперь — имя нарицательное, хотя я бы никогда не пожелал, чтобы это случилось именно так». Ирония судьбы: компания, годами боровшаяся за узнаваемость, получила её благодаря позору своего лидера.

Пока Байрон собирал вещи в офисе, мир уже монетизировал его падение. Бренды мгновенно встроили скандал в рекламу:

• Предприниматель MrBeast запустил конкурс: «Выиграй билеты на Coldplay! Отметь босса, но осторожнее с kiss-cam».
• Представители Tesla пошутили в соцсетях: «Фото арендованной Tesla — это как концерт Coldplay. Ваша машина узнает об измене первой».
• Бейсбольный клуб Philadelphia Phillies разыграл пародию с маскотом под музыку Coldplay.

Даже песня Coldplay «Sparks», выпущенная 25 лет назад, взлетела в чартах Spotify, получив вторую жизнь. Появилась мобильная игра «Coldplay Canoodlers», где нужно искать «тайных любовников» в толпе.

История Байрона стала культурным феноменом, превратив личную трагедию в публичное развлечение и наглядный урок для всех руководителей: в эпоху повсеместных камер и соцсетей приватность — иллюзия.

Цена публичности: почему уход Байрона был неизбежен

Попытки Байрона отшутиться или отрицать роман провалились. Юристы единодушно заявили: судиться с Coldplay бесполезно. Ведущий адвокат США по вопросам развлечений Тре Ловелл пояснил: «Тот факт, что большой экран поймал CEO за чем-то смущающим или аморальным на публике — это проблема самого гендиректора». Художественное использование Kiss Cam защищено законом. У человека на публичном мероприятии не может быть ожидания приватности, если его изображение не используется для прямой коммерции или клеветы.

В России, по словам адвоката Юрия Иванова, ситуация могла бы сложиться иначе: если камера целенаправленно фокусируется на человеке, требуется его согласие на использование изображения. Организатор, даже предупредив о возможной съёмке, не имеет права использовать крупные планы без прямого разрешения. Но в США Байрону оставалось только уйти.

Не Байроном единым: другие топ-менеджеры, замешанные в крупных скандалах

История Astronomer — не исключение. Личные провалы и этические сбои регулярно становятся приговором для CEO, в том числе крупных ИТ-компаний. Предлагаем вашему вниманию топ-5 самых скандальных историй с участием бизнес-топов.

1. Брайан Кржанич: роман, который стоил поста гендиректора Intel

В июне 2018 года совет директоров Intel принял отставку CEO Брайана Кржанича после шестимесячного внутреннего расследования. Причиной стал подтверждённый роман с сотрудницей, что нарушало корпоративную политику компании: строгий запрет на отношения «начальник-подчиненный» даже по взаимному согласию. Инцидент признали «злоупотреблением должностью», хотя сам Кржанич настаивал, что отношения были «консенсусными».

Ирония ситуации заключалась в двойных стандартах. Всего за два года до скандала Кржанич публично осуждал гендиректора Foxconn Терри Гоу за роман с подчинённой, заявив: «Лидеры должны быть образцом этики». Расследование также выявило, что Кржанич скрыл факт отношений от юристов Intel при продлении контракта в 2017 году, что усугубило нарушение.

Последствия:

• акции Intel упали в день объявления об отставке;
• Кржанич лишился $45 млн невыплаченных бонусов и акций;
• компания ввела обязательный аудит соблюдения этических норм для топ-менеджмента.

Финал. Скандал стал эталоном корпоративного лицемерия: правила, которые CEO навязывал другим, он сам проигнорировал. Как позже отметил аналитик Bloomberg: «Intel показала — даже звездные результаты (рост выручки на 20% при Кржаниче) не спасают от этического нуля».

2. Илон Маск и «MechaHitler»: ИИ-бунт

Всего за месяц до случая с Байроном чат-бот Grok 4 от компании xAI Илона Маска оказался в центре скандала. Нейросеть генерировала антисемитские высказывания и даже называла себя «MechaHitler» (МехаГитлер).

Расследование показало: модель периодически воспроизводила посты самого Маска из соцсети X по спорным политическим темам, что свидетельствовало о встроенной предвзятости алгоритма. Кто знает, что ещё наговорил бы бот, если бы его вовремя не остановили.

Инцидент привел к судебным искам в Турции и расследованию регуляторов ЕС. Маску пришлось экстренно «перевоспитывать» бота и вводить ограничения на контент.

Что в итоге. Ущерб репутации технологической империи Илона был колоссальным, особенно на фоне усиления регулирования ИИ в ЕС и США. Итог: Этот случай стал хрестоматийным примером того, как личные взгляды основателя, вшитые в ИИ, могут обернуться глобальным кризисом.

3. Тревис Каланик: как токсичная культура уничтожила CEO Uber

Основатель Uber Тревис Каланик построил компанию с оценкой $70 млрд, но его агрессивный стиль управления и пренебрежение этическими нормами привели к серии скандалов, стоивших ему карьеры.

Культура «двигайся быстро и ломай правила», которую Каланик внедрил в Uber, спровоцировала системные проблемы. Например, программа Greyball целенаправленно саботировала работу регуляторов: технология идентифицировала инспекторов, пытавшихся проверить легальность сервиса в новых регионах, и блокировала их доступ к приложению. Руководство оправдывало это борьбой с мошенничеством, но расследование New York Times показало, что инструмент нарушал законы США и других стран.

Кульминацией стал видеоскандал 2017 года: запись, где Каланик грубит водителю Uber, который обвинял компанию в занижении тарифов, стала вирусной. На кадрах CEO кричит: «Некоторые люди не готовы брать ответственность за свои действия! Твои беды — твои проблемы!». Публикация вынудила Каланика признать: «Мне стыдно. Мне нужна помощь в руководстве». Но это была лишь верхушка айсберга.

Годом ранее разразился скандал с сексуальными домогательствами. Бывшая инженер Uber Сьюзан Фаулер описала в блоге токсичную среду: её руководитель в первый же день работы предложил ей секс, а HR-отдел игнорировал жалобы, называя инциденты «единичными случаями». Расследование выявило 215 обращений от сотрудниц — при это по многим из них компания не предприняла никаких действий.

Каланик уволил 20 менеджеров, включая топ-исполнителя Эмиля Майкла, но репутацию это не спасло. Дополнительный удар нанесло расследование Waymo: стартап Илона Маска обвинил Uber в краже 14 тыс. файлов с данными беспилотных технологий. Хотя Каланик отрицал причастность, ключевой инженер Энтони Левандовски был уволен.

Финал истории: в июне 2017 года инвесторы вынудили Каланика уйти. Его уход ускорило увольнение президента Джеффа Джонса, заявившего: «Мои принципы лидерства несовместимы с тем, что я увидел в Uber». Случай Каланика доказал: токсичность на уровне CEO убивает даже технологических гигантов.

4. Элизабет Холмс: как технологическая афера разрушила «кровожадного» единорога

Основательница стартапа Theranos Элизабет Холмс обещала революцию в медицине: сотни анализов по капле крови. Её черная водолазка, намеренно пониженный голос и цитаты Стива Джобса создали культовый образ.

Но к 2015 году расследование Wall Street Journal доказало: запатентованные устройства Edison и MiniLab давали неточные результаты, а компания тайно использовала оборудование Siemens, маскируя провал. Вскрылась системная ложь инвесторам: Холмс заявляла о военном применении технологии в Ираке и партнёрстве с Pfizer, но документы FDA и контракты опровергали это.

Конфликт этики и амбиций стал ключом к краху:

• Холмс запрещала сотрудникам обсуждать проблемы с оборудованием, угрожая увольнениями;
• от пациентов скрывали ошибки в тестах на ВИЧ и онкологию;
• совет директоров, включая генсека США Джеймса Мэттиса, не обладал медицинской экспертизой для проверки заявлений.

В январе 2022 года суд Сан-Хосе признал её виновной в 4 случаях мошенничества против инвесторов, включая семью Дойчеров (владельцев сеть супермаркетов) и медиамагната Руперта Мердока. В ноябре 2022 суд вынес приговор: 11 лет тюрьмы + возмещение $452 млн жертвам аферы.

Парадокс ситуации:

• Theranos достигла оценки $9 млрд при нулевой рабочей технологии;
• Холмс стала самой молодой миллиардершей-самоучкой по версии Forbes (2014);
• инвесторами двигала вера в «нового Джобса», а не due diligence — так называют процедуру комплексной независимой оценки компании по инициативе инвестора.

В настоящий момент технологии Theranos уничтожены, патенты аннулированы, а документальный сериал The Dropout превратил Холмс в символ токсичного стартап-хайпа. Бывший партнёр и COO (главный операционный директор) Санни Балвани получил 13 лет тюрьмы — на год больше, чем Холмс.

Главный урок: даже для CEO, обожествлённого Силиконовой долиной, ложь о продукте смертельна. Инвесторы поверили в историю, а не в технологию. Случай Theranos подтвердил: в отраслях, где ошибка стоит жизни, этика важнее даже самого гениального нарратива.

5. Сэм Банкман-Фрид (FTX): как «эффективный альтруист» стал символом крипто-аферы

Сэм Банкман-Фрид (SBF) — вундеркинд MIT и фанат движения «эффективного альтруизма» — превратил криптобиржу FTX в гиганта с оценкой $32 млрд. Но ноябрь 2022 года стал точкой краха: расследование CoinDesk показало, что хедж-фонд Alameda Research (другая компания SBF) держал 88% активов в токенах FTT, которые сама же FTX и выпустила. Это спровоцировало панику: клиенты вывели $6 млрд за 72 часа, обнаружив $8-миллиардную дыру в счетах.

Что вскрылось:

• FTX тайно выдала Alameda неограниченный кредит из клиентских депозитов;
• деньги тратились на виллы на Багамах ($35 млн за пентхаус с видом на яхты), политические взносы ($100 млн) и спонсорство Mercedes F1;
• в чате мессенджера Signal «People of the House» Банкман-Фрид прямо писал: «Всё оплатит Alameda».

Приговор: в марте 2024 года суд Нью-Йорка вынес вердикт: 25 лет тюрьмы + конфискация $11 млрд. Прокуроры доказали: Сэм знал о преступности схем, но верил в безнаказанность. Судья Льюис Каплан заявил: «Он хотел власти. И использовал для этого воровство».

Мораль: криптоинновации ≠ анархия. Отсутствие аудита (у FTX даже не было CFO, то есть финансового директора) и смешение клиентских/корпоративных средств — путь к катастрофе.

Уроки выживания: как CEO избежать участи Байрона и остальных

Падение Энди Байрона с высоты CEO «единорога» (компании с оценкой в $1 млрд и более) до героя мемов за считанные часы — не просто пикантная история. Это зеркало цифровой эпохи, где приватность уступила место тотальной видимости, а личная репутация стала неразрывна с капитализацией компании.

Для топовых IT-менеджеров это напоминание: код можно отладить, баги — исправить, но единственный неверный шаг в реальном мире, зафиксированный камерой, способен стереть годы упорной работы.

Этика должна быть встроена в ДНК лидерства. Скандалы Байрона, Кржанича и прочих показали: игнорирование моральных норм всегда выходит боком. Личное = профессиональное. Для CEO больше нет границ между частной жизнью и работой. Любые попытки скрыть нарушения лишь усугубляют падение.

В мире, где каждый — потенциальный папарацци, лучшая защита CEO — безупречность не только в алгоритмах работы, но и в жизни. Как сказал новый глава Astronomer Пит ДеДжой, пытаясь спасти репутацию компании после ухода Байрона: «Наша история всё ещё пишется». Но теперь уже другими людьми и на испорченной бумаге.

Если вы хотите стать одним из них и расширить свои горизонты, сделать первые шаги вам поможет наш материал. Здесь мы собрали ответы на часто задаваемые вопросы по поиску работы в IT за рубежом: наиболее перспективные направления, вспомогательные сервисы, особенности виз, рекомендации, как адаптировать резюме для иностранного рынка и получить оффер мечты.

Бонус — комментарии экспертов с многолетним опытом работы за границей и глубоким пониманием международного рынка труда.

Какие IT-профессии наиболее востребованы за рубежом

По данным сервиса по поиску работы HeadHunter, в 2024 году наибольшим спросом за границей пользовались российские:

• менеджеры по продажам и работе с клиентами (13%),
• операторы колл-центров (5%),
• дизайнеры, менеджеры по маркетингу, интернет-маркетологи, художники (по 4%),
• учителя, SMM- и контент-менеджеры (по 3%),
• секретари, помощники руководителя, ассистенты (по 2%).

Программисты и разработчики заняли почётное второе место (10%). А специалисты технической поддержки и тестировщики набрали всего по 2%.

Но в исследовании образовательной онлайн-платформы «Нетология» и международного коммуникационного агентства Zecomms Agency специалист технической поддержки — наоборот, наиболее востребованная профессия за рубежом. С ним связано 17% от общего массива IT‑вакансий, что делает специалиста техподдержки абсолютным лидером по количеству открытых вакансий.

На втором месте расположился программный инженер (16%), на третьем — бизнес-аналитик (6%) и IT-консультант (6%).

Максим Оганов, ментор, бизнес-консультант, автор проекта Oganov.Consulting:

Российские IT-специалисты всё ещё остаются востребованными за рубежом, но по сравнению с 2022 годом ситуация изменилась. Международные компании уже не так охотно берут в штат сотрудников из России, известны случаи сокращений из-за гражданства. Причина — политика компаний, особенно тех, которые решили покинуть российский рынок. Зато за последние три года многие отечественные стартапы релоцировались в другие страны, и они отдают предпочтение сотрудникам из России.

Евгений Козак, senior фронтенд-разработчик компании With Intelligence, живёт в Лондоне, более 10 лет опыта работы за границей:

В 2022 году интерес к российским IT-специалистам был выше, но в 2025 ситуация изменилась из-за экономической нестабильности, роста процентных ставок и замедления найма во многих странах. Вакансий стало меньше, особенно без разрешения на работу. Однако IT по-прежнему остаётся одной из самых высокооплачиваемых и востребованных сфер.

Языки программирования, актуальные для иностранных компаний

Согласно исследованию «Нетологии» и Zecomms Agency, Java признан самым популярным языком программирования — его активно используют компании по всему миру. На Java приходится более четверти всех открытых вакансий (26%) в сфере IT в Европе, США, Латинской Америке, Азии и на Ближнем Востоке.

Java — это универсальный язык программирования, который отличаются стабильностью, масштабируемостью и кроссплатформенностью. На нём пишут крупные корпоративные приложения в банках, промышленных, страховых и телеком-компаниях, облачные, распределённые и IoT- системы, микросервисы. Также Java считается неотъемлемой частью бэкенд-разработки.

На втором месте по популярности находится язык SQL, который используют для разработки баз данных и систем аналитики. На него пришлось 24% всех вакансий, бóльшая часть из них в Европе, Азии и на Ближнем Востоке.

Замыкает тройку лидеров Python (23%) — более половины открытых вакансий в Азии и на Ближнем Востоке связано именно с этим языком. Оно и неудивительно: на Python пишут модели для машинного обучения, анализа данных и автоматизации.

Сколько айтишникам платят за границей

Более высокая зарплата — одна из главных причин, почему российские IT-специалисты хотят работать за границей.

Евгений Козак, senior фронтенд-разработчик компании With Intelligence, живёт в Лондоне, более 10 лет опыта работы за границей:

Трудоустройство за границей открывает доступ к международным командам, передовым технологиям и крупным проектам мирового уровня с лучшими практиками разработки, высокими стандартами качества кода и современными архитектурными подходами. Всё это способствует быстрому профессиональному росту. Мне переезд позволил быть ближе к центру IT-индустрии и дал возможность развиваться в высококонкурентной среде.

В большинстве европейских стран зарплаты индексируются и официально растут вслед за инфляцией. За счёт этого доходы, пусть и медленно, но увеличиваются. К сожалению, не все отечественные компании могут такое гарантировать — практика индексации зарплат в России пока не так распространена.

Но ключевое — размер оклада. По данным «Профсоюза работников ИТ», медианная зарплата специалистов уровня senior в России составляет 276 362 рубля в месяц, в то время как за рубежом она равна 386 730 рублей в месяц. Российские миддлы получают 170 000 рублей, а работающие за границей — 205 142 рубля. Зарплата джунов несильно отличается, хотя «за бугром» она всё-таки немного больше: 85 000 рублей против 80 000 рублей в России.

Таким образом, зарплата IT-специалистов за рубежом как минимум в 1,5 раза больше, чем в России.

Дополнительное преимущество — оплата в валюте: долларах, евро или фунтах. После пересчёта на рубли итоговая сумма все равно будет выше средней зарплаты в России — и это без учёта премий и бонусов.

Где IT-кадры пользуются спросом

Найти работу в IT сейчас везде нелегко, но чуть проще это сделать там, где активно развивается IT-сектор и требуется много кадров соответствующего профиля:

Германия. Наибольший дефицит IT-специалистов наблюдается в Германии — в 2023 году было опубликовано 103 089 вакансий. Особенно остро нехватка кадров ощущается в таких областях, как разработка программного обеспечения, Data Science, кибербезопасность и DevOps. А в 2025 году страна планирует выдать на 10% больше рабочих виз, чем годом ранее.

Нидерланды. В стране большое внимание уделяется IT-стартапам. Так, в 2024 году голландские технологические компании привлекли €3,7 млрд венчурных инвестиций — это около 5% от общего объёма капитала, вложенного в европейскую экосистему. Благодаря этому Нидерланды вошли в топ‑10 стран Европы по объёму инвестиций в технологии. Особенно быстро растёт сектор DeepTech («глубоких технологий») — полупроводники, искусственный интеллект и квантовые технологии.

Канада. Такие канадские города как Торонто, Ванкувер и Монреаль считаются настоящей IT-меккой. Здесь активно развиваются стартапы и работают подразделения крупнейших технологических компаний — Google, Microsoft, Amazon. Кроме того, для IT-специалистов есть много иммиграционных программ, например, Global Talent Stream, которая позволяет получить разрешение на работу в течение двух недель.

США. В 2023 году объём IТ-рынка США достиг $1,3 трлн и продолжает развиваться высокими темпами. В Европейском союзе он составил $1,05 трлн, в Китае — $348 млрд, в России — $36,1 млрд. Таким образом, американский технологический рынок в 36 раз больше российского, в 1,24 раза больше европейского и почти в четыре раза превосходит китайский. Это подтверждает его статус мирового лидера. Соответственно, IT-специалистов нужно много.

Куда уехать проще всего

По данным HeadHunter, активнее всего российских специалистов приглашают на работу компании из:

• Белоруссии — 172,3 тыс. приглашений,
• Казахстана — 150,9 тыс. приглашений,
• Грузии и Турции — 69,7 тыс. и 67,8 тыс. приглашений соответственно,
• Узбекистана — 57,2 тыс. приглашений.

Самый большой рост интереса продемонстрировали китайские работодатели — он увеличился почти в шесть раз. В 2023 году количество предложений для жителей России о работе в Китае составляло всего 4,8 тыс., тогда как в 2024 году цифра достигла 27,6 тыс. предложений.

Кроме того, за год потребность в российских специалистах выросла в Сербии с 5,8 тыс. до 26,3 тыс. (+356,3%), в Турции — с 23,5 тыс. до 67,8 тыс. (+188,6%), на Кипре — с 4,6 тыс. до 12 тыс. (+160,9%), в Польше — с 4,1 тыс. до 9,0 тыс. (+119,6%) и в ОАЭ — с 19,2 тыс. до 41,7 тыс. (+117,2%).

А Европа стала лидером по количеству предложений для IT-специалистов со знанием русского языка — 3% всех IT-вакансий в регионе. На других рынках доля таких предложений не превышает 1%. Чаще всего русскоязычных специалистов ищут в Польше — 2 200 вакансий, Венгрии — 752 вакансии, Австрии — 178 вакансий, Греции — 152 вакансии.

Максим Оганов, ментор, бизнес-консультант, автор проекта Oganov.Consulting:

Не все страны охотно принимают специалистов из других стран. Если раньше одними из самых популярных направлений для релокации были Канада и США, то сейчас переехать туда стало значительно сложнее. Больше шансов на трудоустройство в компании Испании, Португалии, Кипра, ОАЭ.

Как IT-специалисту найти работу за границей: четыре шага

1. Зарегистрируйтесь на международных платформах

Принцип поиска работы за рубежом такой же, как и в России. Нужно зарегистрироваться на платформах по типу HeadHunter и откликаться на понравившиеся вакансии. Чем больше откликов, тем лучше.

Вот подборка сайтов для поиска работы за границей:

• LinkedIn — профессиональная социальная сеть, где можно искать вакансии и налаживать контакты;
• Indeed — международный агрегатор вакансий, позволяющий фильтровать их по странам, городам и отраслям;
• Relocate.me — платформа для вакансий с релокацией;
• Remote OK — площадка для поиска удалённой работы;
• WWR — сервис, где публикуют вакансии крупные зарубежные компании, например, Amazon или Google.
• AngelList Talent — каталог вакансий в иностранных стартапах.

Некоторые из них открываются только с VPN.

Максим Оганов, ментор, бизнес-консультант, автор проекта Oganov.Consulting:

Удобнее всего искать вакансии зарубежных компаний через LinkedIn. По моему опыту, большинство специалистов находят работу за границей именно через эту площадку. Но есть и альтернативные варианты — например, телеграм-каналы с профильными вакансиями. Будьте готовы к тому, что придётся отправлять много откликов. В среднем на 100 откликов приходится не более 5 ответов.

Евгений Козак, senior фронтенд-разработчик компании With Intelligence, живёт в Лондоне, более 10 лет опыта работы за границей:

В основном я искал работу через LinkedIn. Это самая эффективная платформа: я обновил профиль, загрузил резюме и активно взаимодействовал с рекрутерами. Также полезно размещать резюме на популярных job-порталах и быть открытым к предложениям — тогда многие специалисты по подбору персонала сами выходят на связь.

2. Адаптируйте резюме для иностранного рынка

Если вы собираетесь искать работу на европейском или американском рынке, разумеется, резюме должно быть составлено на английском языке. В англоязычных странах резюме называют Curriculum Vitae или CV.

Эксперты компании EP Advisory, которая помогает российским специалистам строить карьеру за рубежом, рекомендуют включать в CV разделы Name, Profile, Education, Experience, Skills & Other. Названия предыдущих компаний и занимаемые должности следует выделять, а каждый блок — разграничить чертой.

Кроме того, в некоторых странах, например, Великобритании, США и Канаде не принято добавлять фото в резюме. Такое правило стало следствием законов против дискриминации в этих странах, поэтому его несоблюдение может вызвать негативную реакцию и привести к мгновенному отказу.

Дополнительно к резюме стоит приложить мотивационное письмо (Cover Letter), подготовленное специально под конкретную вакансию. В мотивационном письме уже не пишут об образовании и навыках — эти сведения указывают только в резюме. А в Cover Letter особый упор делается на кейсах и объяснении, чем для вас интересна компания и почему вы для неё — самый подходящий кандидат.

Максим Оганов, ментор, бизнес-консультант, автор проекта Oganov.Consulting:

Необходим большой и подтверждённый опыт работы. Придётся конкурировать со специалистами уровня senior со всех концов света. Особенно много кандидатов из Индии, Ирана, Пакистана.

3. Обратитесь в агентство по трудоустройству

Самостоятельно найти работу за границей и разобраться во всех сопутствующих вопросах, связанных с написанием резюме, оформлением виз и переездом, может быть сложно. Поэтому стоит обратиться в агентства по трудоустройству, которые все эти моменты возьмут на себя.

Вот список наиболее известных рекрутинговых агентств:

• Adecco — крупнейшее агентство с вакансиями по всему миру;
• Manpower — международная стаффинговая, аутсорсинговая и HR-консалтинговая компания из России;
• Michael Page — международная компания, которая специализируется на подборе персонала среднего и высшего звена;
• Hays — британская рекрутинговая компания, которая предоставляет услуги по подбору персонала в 33 странах мира;
• Harvey Nash — международная компания, которая специализируется на IT-аутсорсинге;
• Randstad — голландская консалтинговая компания, которая сотрудничает с ведущими зарубежными работодателями.

Агентства также консультируют по вопросам адаптации и помогают с поиском жилья.

Евгений Козак, senior фронтенд-разработчик компании With Intelligence, живёт в Лондоне, более 10 лет опыта работы за границей:

Чтобы найти работу в Лондоне, я сотрудничал с международными и британскими рекрутинговыми агентствами — Hays, Harvey Nash и Michael Page. Примерно 50% предложений приходили именно от них. Эти агентства играют важную роль на IT-рынке и обладают широкой сетью контактов с работодателями по всей Европе. Они помогали мне в поиске подходящих позиций и сопровождали на всех этапах — от первичного отклика до собеседования и подписания оффера.

4. Получите визу и разрешение на работу

Без визы и разрешения приступить к работе за границей не получится. Здесь доступны два варианта — Digital Nomad Visa или обычные рабочие визы.

Digital Nomad Visa. Digital Nomad Visa или «виза цифрового кочевника» позволяет легально жить за рубежом, но при этом продолжать удалённо работать на родину. В отличие от туристической визы, Digital Nomad Visa даёт право длительно находиться в определённой стране, а в сравнении с рабочей визой — не требует трудоустройства на местном рынке.

Это не классическая рабочая виза. Она разрешает трудиться из разных частей мира, но с ней нельзя работать на компании из страны пребывания. Также не всегда можно перевести семью.

Чтобы получить визу цифрового кочевника, нужно подтвердить минимальный доход (чаще всего не ниже 2000 евро в месяц) и наличие медицинской страховки. Также может понадобиться трудовой договор или договор подряда, доказывающие, что вы работаете удалённо. Сейчас Digital Nomad Visa оформляют в 66 странах, включая Португалию, Испанию, Эстонию, ОАЭ и Южную Корею.

Классические рабочие визы. Это визы EU Blue Card или виза H‑1B.

• Голубая карта (EU Blue card) — виза для работы в Европе. Чтобы получить её, нужен диплом о высшем образовании (не ниже бакалавра) и оффер с зарплатой от 48 300 евро год (43 760 евро для IT‑специалистов) на срок минимум шесть месяцев. В случае одобрения выдаётся вид на жительство, действующий до четырёх лет с возможностью продления.

• Виза H‑1B — виза для работы в США. Она также требует наличия высшего образования и оффера от местной компании. Но американское законодательство устанавливает лимит на выдачу H‑1B — 65 000 базовых и 20 000 дополнительных виз для специалистов с магистерской степенью из США. Всего 85 000 виз в год. Виза предоставляется максимум на три года с возможностью продления до шесть лет.

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

Официальное трудоустройство или фриланс

Удалённая работа на фрилансе

Фриланс — самый простой способ начать работать с зарубежными компаниями без лишней бюрократии и сложностей с оформлением. Достаточно зарегистрироваться на зарубежную фриланс-платформах Upwork или Fiverr, и можно сразу браться за международные проекты. Единственное, могут возникнуть трудности с оплатой, поэтому стоит завести себе иностранную банковскую карту.

Главные минусы фриланса — нет оплачиваемого отпуска и больничных, а доход крайне нестабилен.

Официальное трудоустройство с релокацией

Официальное трудоустройство гарантирует стабильную зарплату и полный соцпакет, а при релокации — помощь с переездом и адаптацией в новой стране.

Однако получить оффер с переводом в местный офис не так просто. Иностранные компании редко берут на себя расходы, связанные с релокацией российских специалистов и их семей. Чаще всего они нанимают тех, кто уже легально живёт за границей — например, по рабочей визе или с видом на жительство. В таком случае проще оформить перевод в местный офис или принять человека на работу через филиал в этой стране.

Максим Оганов, ментор, бизнес-консультант, автор проекта Oganov.Consulting:

Найти работу будет проще, если вы уже находитесь в стране, и компании не придётся заниматься вашей релокацией. Поэтому хороший вариант — попробовать переехать самостоятельно, продолжая работать удалённо в российской компании или на фрилансе. У вас будет время присмотреться к стране, понять, подходит ли она вам. А если вы достаточно активны и коммуникабельны, можно будет попробовать найти вакансию через местные сообщества российских эмигрантов.

Евгений Козак, senior фронтенд-разработчик компании With Intelligence, живёт в Лондоне, более 10 лет опыта работы за границей:

В первую очередь, нужно убедиться, что у вас есть правовой статус или разрешение на работу в стране, где вы планируете трудоустроиться. Это значительно повышает ваши шансы на успех.

Какой уровень владения английским языком нужен

Для оценки владения иностранными языками, включая английский, в Европе используют систему CEFR (Common European Framework of Reference). CEFR выделяет шесть уровней знания языка: A1, A2, B1, B2, C1, C2.

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

Максим Оганов, ментор, бизнес-консультант, автор проекта Oganov.Consulting:

Обязательное требование — свободное владение английским: например, в Португалии большинство сотрудников IT-компаний общаются на нём. Но иногда кандидату необходимо знание местных языков — так, если вы хотите переехать во Францию, шансы на трудоустройство без владения французским минимальны.

Евгений Козак, senior фронтенд-разработчик компании With Intelligence, живёт в Лондоне, более 10 лет опыта работы за границей:

Главной трудностью для меня был язык. Технический английский у меня на хорошем уровне, особенно когда речь идёт о собеседованиях, терминах и обсуждении архитектуры — в этом я чувствую себя уверенно. Однако повседневный английский, особенно неформальное общение, давался сложнее. Кроме того, структура интервью в других странах немного отличается, но к ней я быстро адаптировался. Повысить уровень языка и стать увереннее в повседневном общении мне помогли постоянная практика, разговоры с носителями языками и участие в командных митингах.

Коротко о главном

• Иностранные компании активно используют Java, Python, SQL и нуждаются в программистах, умеющих писать на этих языках.
• IT-специалисты особенно востребованы в Германии, Нидерландах, Канаде и США — странах с наиболее интенсивным ростом технологического сектора.
• Проще всего уехать в Белоруссию, Казахстан, Турцию, Грузию и Китай.
• Работать за границей можно официально или на фрилансе.
• Чтобы получить оффер, следует зарегистрироваться на международных платформах для поиска работы, адаптировать резюме, оформить визу и, при необходимости, обратиться в агентство.

Спрос на таких специалистов продолжает расти. Средняя зарплата проджект-менеджера в России в 2025 году составляет около 147 000 руб., при этом сеньоры могут получать до 240 тыс. Для продактов цифры еще выше — опытные специалисты в крупных IT-компаниях зарабатывают от 300 000 руб.

Обучение этим профессиям стало доступнее благодаря онлайн-курсам. Мы проанализировали десятки программ и выбрали семь лучших, которые действительно дают нужные навыки и помогают начать карьеру.

1. Академия Softline: «Управление проектами в области ИТ»

Академия Softline предлагает актуальный курс в рамках обширной обучающей программы для повышения квалификации. Программа разработана практиками из крупных IT-компаний и охватывает все аспекты работы с проектом.

Курс длится 40 академических часов и проводится полностью в онлайн-формате. Программа сочетает теоретические модули с интенсивной практической отработкой навыков через индивидуальные и групповые упражнения.

Каждый участник работает над реальным проектом, применяя инструменты управления на всех этапах — от запуска до завершения. Наставники-практики сопровождают студентов на протяжении всего обучения, помогая разобрать нюансы применения методик в реальных ИТ-проектах.

Уникальность программы

Курс отличается синтезом мировых стандартов: PMBoK и ITIL интегрированы с гибкими методологиями (Agile, Scrum, Kanban). Такой подход учит адаптировать инструменты под специфику конкретных задач, а не просто следовать шаблонам.

Акцент на ИТ-проекты делает программу полезной для компаний, внедряющих цифровые продукты или модернизирующих инфраструктуру, поскольку здесь разбираются кейсы по управлению релизами ПО и масштабированию облачных решений.

Преимущества:

• практическая направленность: 70% времени посвящено работе с реальными кейсами;
• гибкие методики для ИТ-среды: от классического Waterfall до гибридных моделей;
• поддержка наставников с опытом в Сбере, Яндексе и других топовых компаниях.

Что получают выпускники

После защиты итогового проекта участники получают удостоверение повышении квалификации государственного образца и готовое портфолио с реализованным кейсом. Карьерный центр помогает с трудоустройством: студенты 2024 года получили офферы от партнеров (Сбер, МТС, VK) в течение 3 месяцев после завершения курса.

Стоимость и условия

Полная цена программы — 80 000 рублей. Доступна рассрочка на 4 месяца (20 000 руб./мес). Для корпоративных клиентов действуют скидки до 15% при обучении групп от 3 человек.

2. Компьютерная Академия ТОП: «Проджект-менеджер в IT»

Компьютерная Академия ТОП уже несколько лет готовит сильных проджектов для IT-индустрии. Курс подходит тем, кто хочет научиться управлять проектами в условиях неопределенности — именно с этим сталкивается большинство новичков.

Курс длится 10 месяцев и доступен в двух форматах: очном (в 200+ филиалах по России) или онлайн с живыми вебинарами. В отличие от многих программ, здесь нет записанных уроков — все занятия проходят в режиме реального времени с преподавателями-практиками. Каждую группу курирует действующий проджект из IT-индустрии, который дает каждому участнику обратную связь и разбирает ошибки на практике.

Уникальность программы

Живое обучение в малых группах (до 15 человек), где студенты отрабатывают навыки на 12 реальных кейсах — от запуска мобильных приложений до управления релизами SaaS. Например, один из проектов имитирует работу с заказчиком из банковского сектора, где нужно согласовать требования и сроки под жесткими ограничениями бюджета.

Программа обновляется каждые 6 месяцев с учетом запросов работодателей. В 2025 году добавлен модуль по гибридным методологиям (Agile-Waterfall) для госпроектов и FinTech.

Помимо Jira и Trello, студенты осваивают специализированные решения для IT-команд — Axure RP для прототипирования и MS Project для сложных диаграмм Ганта.

Преимущества:

• стажировка у партнеров (VK, Сбер, Тинькофф) после успешной защиты дипломного проекта;
• доступ к закрытому чату выпускников с вакансиями от 500+ компаний;
• сертификация PMI CAPM® включена в стоимость.

Что получают выпускники

По данным академии, до 80%студентов трудоустраиваются в течение нескольких месяцев после выпуска.

В портфолио входят:

• 4 завершенных учебных проекта с метриками эффективности (например, сокращение сроков на 15-20% в симуляциях);
• готовые артефакты: устав проекта, реестр рисков, отчеты по Scrum-спринтам;
• государственный диплом о профессиональной переподготовке и международный сертификат.

Стоимость и условия

• онлайн: 4 590 руб./мес (рассрочка на 10 месяцев);
• очно: 17 910 руб./мес (скидка 15% при оплате за год);
• корпоративное обучение: индивидуальный расчет для групп от 5 человек.

3. ProductStar: «Профессия Продакт-менеджер»

Курс от ProductStar подойдет как новичкам, так и тем, кто уже работает в IT, но хочет перейти в продукт.

Особенности программы:

• 8 месяцев обучения с упором на практику;
• 3 специализации на выбор: B2C, B2B или стартапы;
• работа с Figma, Miro, Amplitude, SQL;
• кейсы от партнеров: Яндекс, МТС;
• подготовка к реальным собеседованиям.

Один из плюсов ProductStar — сообщество. Студенты получают доступ к закрытому чату, где общаются выпускники и преподаватели. Там можно получить совет, найти напарника для проекта или даже предложение о работе.

Каждый модуль курса завершается защитой проекта перед экспертами из индустрии. Это не только возможность получить обратную связь, но и шанс заявить о себе потенциальным работодателям.

4. Академия Softline: «Управление проектами по разработке программных продуктов»

Курс от Академии Softline создан для тех, кто хочет научиться выводить проекты на финишную прямую без переработок и конфликтов.

Формат обучения и особенности курса

Курс длится 252 академических часа и реализуется в мультиформатном режиме:

• Живые вебинары с разбором кейсов и домашних заданий от экспертов-практиков.
• Самостоятельная работа на обучающей платформе с доступом к записям и шаблонам документов.
• 80% практики. Симуляции переговоров с заказчиками, разработка проектной документации (устав проекта, реестр рисков, отчеты), защита итогового проекта перед комиссией с обратной связью.

У курса Академии Softline гибкий подход к методологиям управления проектами. В отличие от стандартных программ, здесь учат не просто следовать шаблонам Waterfall или Agile, а адаптировать их под специфику российского IT-рынка.

Особое внимание уделяется работе в сложных условиях — например, управлению изменениями требований, частыми релизами и MVP. Студенты разбирают полный цикл разработки ПО: от архитектурных решений до интеграции с устаревшими системами (legacy), что особенно актуально для разработки новых программных продуктов.

Практическая направленность — еще одна особенность программы. Все теоретические знания сразу применяются в реальных кейсах от партнеров (Сбер, VK, МТС), включая разработку мобильных приложений и SaaS-платформ. Участники осваивают профессиональные инструменты: Jira для трекинга задач, MS Project для построения сложных диаграмм Ганта и Confluence для ведения проектной документации.

Преподаватели курса — действующие проджект-менеджеры с опытом в международных компаниях. Они делают акцент на технических аспектах управления: понимании жизненного цикла разработки ПО (SDLC), базовых принципах DevOps и особенностях работы с API. Это позволяет выпускникам говорить на одном языке с разработчиками и грамотно ставить технические задачи.

Результаты выпускников

По окончании обучения студенты получают диплом о профессиональной переподготовке государственного образца и готовое портфолио. В него входят: устав проекта для финтех-стартапа, реестр рисков с mitigation-стратегиями и отчеты по Scrum-спринтам с метриками эффективности.

Выпускники также получают доступ к вакансиям партнеров через карьерный центр Softline, что существенно повышает шансы на трудоустройство.

Стоимость и условия

• полная цена: 156 000 руб.;
• рассрочка: 13 000 руб./мес × 12 месяцев;
• корпоративное обучение: индивидуальный расчет для групп от 5 человек.

5. Нетология: «Продуктовый менеджер»

Курс «Продуктовый менеджер» от Нетологии предназначен для тех, кто хочет освоить управление продуктом на всех этапах его жизненного цикла — от исследования рынка до масштабирования. Программа подходит как новичкам, так и специалистам, которые хотят углубить свои знания в продуктовой аналитике и стратегическом планировании.

Формат обучения и особенности

Обучение длится 8 месяцев и включает 104 урока в формате видеолекций, практических заданий и живых вебинаров. Студенты работают над собственным продуктом, проходя все стадии разработки: от формирования гипотез до запуска MVP и анализа первых метрик. Каждый модуль завершается практическим заданием, которое проверяют кураторы — действующие продакт-менеджеры из Mail.ru Group, Avito и других компаний.

Основные темы:

• Анализ рынка и целевой аудитории — методы CustDev, построение CJM (Customer Journey Map), выявление Jobs To Be Done (JTBD).
• Продуктовая аналитика — работа с метриками AARRR и HEART, настройка дашбордов, проведение A/B-тестов.
• Финансовое моделирование — расчет юнит-экономики, стратегии монетизации, оценка рентабельности продукта.
• Управление продуктом — создание роадмапа, приоритизация фич, работа с бэклогом и командой разработки.

Что отличает курс:

• Практическая направленность. 70% времени посвящено работе с реальными кейсами, включая задачи от партнеров Нетологии.
• Карьерный модуль. Помощь в составлении резюме, подготовка к собеседованиям, разбор переговоров о зарплате.
• Гибкий график. Возможность изучать материалы в удобное время, совмещая обучение с работой.

Что получают выпускники

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

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

Карьерная поддержка включает доступ к вакансиям компаний-партнеров (VK, Тинькофф), персональные консультации по составлению резюме и подготовку к собеседованиям с HR-специалистами. Для лучших студентов предусмотрены стажировки с возможностью дальнейшего трудоустройства.

Стоимость

Полная цена: 158 160 руб. (доступна рассрочка — 4 393 руб./мес). В рамках корпоративного обучения площадка предлагает индивидуальный расчет для групп.

6. SkillFactory: «Проджект-менеджер в IT»

SkillFactory предлагает подробный курс по управлению проектами. За 9 месяцев студенты полностью погружаются в профессию и выходят готовыми к реальным задачам.

Курс SkillFactory предназначен для тех, кто хочет освоить управление IT-проектами с нуля или систематизировать имеющийся опыт. Программа сочетает теорию с практикой: студенты изучают методологии (Agile, Scrum, Waterfall) и сразу применяют их в реальных кейсах, таких как разработка мобильного приложения или внедрение CRM-системы.

Формат обучения

• Онлайн-вебинары с разбором кейсов от преподавателей-практиков (например, Павла Максимова, который руководил запуском eSIM в России).
• 3 проекта в портфолио: планирование приложения по Agile, внедрение софта для call-центра по Waterfall, дипломная работа — сервис для видео-найма персонала.
• Поддержка наставников, включая персональные консультации и проверку заданий.

Ключевые навыки

Курс фокусируется на практических инструментах:

• работа с Jira, Trello, MS Project для планирования;
• управление бюджетом и рисками;
• проведение ретроспектив и дэйли-митингов (коротких ежедневных собраний команды);
• подготовка документации (уставы проектов, реестры рисков).

Трудоустройство

Выпускники получают доступ к вакансиям партнеров SkillFactory и помощь в составлении резюме. По данным портала hh.ru, средняя зарплата junior-проджекта после курса составляет 95 000–120 000 руб.

Стоимость

Полная цена: 87 000 руб. (доступна рассрочка — 7 250 руб./мес). Включен бонусный курс по нейросетям.

7. GoPractice: «Профессия: Продакт-менеджер»

Программа длится 11 месяцев и предназначена для специалистов, планирующих переход в продакт-менеджмент из смежных ролей (аналитики, маркетологи, проджекты).

Обучение включает пять ступеней:

1. Анализ траекторий перехода в профессию.
2. Освоение основ продакт-менеджмента через кейсы.
3. Работа с симулятором управления продуктом.
4. Дипломный проект.
5. Подготовка к трудоустройству.

Занятия проходят онлайн с гибким графиком. Каждую группу курируют менторы из компаний (Яндекс, Avito, Ozon), которые проводят приветственные звонки и консультируют по заданиям.

Программа

Курс охватывает:

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

Практическая часть включает три кейса и дипломный проект, которые формируют портфолио. Для выполнения заданий используются шаблоны и фреймворки, применяемые в MAANG-компаниях.

Результаты

По завершении программы выпускники получают сертификат GoPractice, подтверждающий освоение ключевых навыков продакт-менеджера. В портфолио добавляются три практических кейса и дипломный проект, выполненные на основе реальных бизнес-задач. Дополнительно предоставляется доступ к закрытому чату выпускников, где можно поддерживать профессиональные связи и обсуждать актуальные вакансии.

Стоимость

Полная цена: 219 900 руб., рассрочка: 18 325 руб./мес × 12 мес.

Как выбрать курс и начать карьеру

Выбор программы зависит от ваших целей и стартовых условий. Тем, кто только начинает, лучше выбрать курсы с упором на практику и помощью в трудоустройстве. Опытным специалистам подойдут программы с углублением в конкретные области — аналитику, управление командами или работу с данными.

Важно помнить, что ни один курс не даст всего сразу. После обучения придется доучиваться на практике, однако хорошая программа обеспечит базу, которая ускорит этот процесс. И главное — доступ к сообществу профессионалов, которое поможет на старте карьеры.

Что такое Kaniko и зачем он был нужен

Kaniko — это инструмент от Google для сборки OCI-совместимых образов контейнеров внутри контейнеров без необходимости root-доступа и запуска Docker-демона. Он получил широкое распространение как решение для CI-сборок в Kubernetes, особенно в таких платформах, как GitHub Actions и GitLab CI.

Преимущества Kaniko

Безопасность: не требует привилегий (rootless). Kaniko может запускаться в обычном (непривилегированном) контейнере, без необходимости доступа к root. Это значительно повышает безопасность, так как сборка образа происходит изолированно и не требует доступа к системным ресурсам.

Например, в Kubernetes можно создать под с Kaniko, где контейнер работает с обычным пользователем без securityContext.runAsRoot: true. Это значит, что злоумышленник не сможет получить root-доступ через этот контейнер.

Простота: легко запускать как задачу (Job) или контейнер в Kubernetes. Kaniko легко интегрируется в Kubernetes — он просто запускается как обычный контейнер, который выполняет сборку образа и загружает его в реестр. Не нужно устанавливать и настраивать Docker-демон.

Так выглядит запуск сборки в GitLab CI/CD с использованием Kaniko:

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

Например, если есть обычный Dockerfile…

… то можно просто указать Kaniko использовать этот Dockerfile, и он построит такой же образ.

Конец поддержки Kaniko и альтернативы

В июне 2025 года публичный репозиторий Kaniko перевели в архив — теперь он доступен только для чтения, что фактически означает прекращение его активной поддержки и развития со стороны разработчиков.

Несмотря на то, что вскоре начали появляться форки (самый заметный — это chainguard-dev/kaniko), они ориентированы на режим поддержки (фикс багов и безопасность), а не на дальнейшее развитие инструмента. Поэтому многие пользователи ищут замену Kaniko — если и не сегодня, то в обозримом будущем.

Наиболее популярные в сообществе альтернативы:

• BuildKit от Docker/Moby (особенно в связке с docker buildx);
• Buildah от Red Hat из экосистемы Podman. Стал Sandbox-проектом CNCF в январе 2025 года.

Почему стоит рассмотреть werf и как начать

Помимо низкоуровневых инструментов, таких как Kaniko, BuildKit и Buildah, существует также высокоуровневое решение — werf. Это production-ready-инструмент, предназначенный не только для сборки, но и для доставки контейнеров в Kubernetes. Утилита позволяет использовать любую предпочтительную CI-систему. Является Sandbox-проектом в CNCF.

Что предлагает werf:

• Native Kubernetes-ориентированная архитектура, то есть можно легко интегрировать сборку, деплой и управление приложениями прямо в Kubernetes-кластере.
• Поддержка Buildah или BuildKit в качестве backend для сборки, причём Buildah полностью интегрирован в werf и может работать в rootless-режиме. Это позволяет собирать образы без необходимости запуска процессов с правами root.
• Удобная интеграция с другими инструментами доставки софта в Kubernetes (включая GitLab, GitHub Actions и Argo CD). Например, связка из werf и Argo CD позволяет полностью интегрировать между собой любую CI/CD-систему и Argo CD. При этом от каждого из инструментов берутся свои возможности и особенности.

• Автоматическое кэширование сборки и тегирование на основе содержимого, как результат — инкрементальные сборки и оптимальное использование container registry.
• Надёжное развёртывание и управление релизами в Kubernetes. werf расширяет возможности Helm, используя встроенный инструмент Nelm, который обеспечивает точное отслеживание состояния ресурсов, умное ожидание их готовности, мгновенное завершение проблемных релизов и применяет более надёжный метод обновления ресурсов — Server-Side Apply. При этом сохраняется полная совместимость с Helm-чартами и релизами.
• Дистрибуция релизных артефактов. Утилита упаковывает Helm-чарт и связанные с ним образы контейнеров в единый бандл, который затем можно опубликовать в OCI-совместимый реестр. Кроме того, бандлы можно копировать между реестрами, выгружать на USB-флеш-накопитель и развёртывать в Kubernetes с помощью werf или других решений, которые поддерживают работу с OCI-чартами (Helm, Flux, ArgoCD).
• Умная очистка container registry, которая автоматически удаляет неактуальные теги образов с учётом их использования в Kubernetes и истории Git, что позволяет безопасно освобождать место и контролировать рост хранилища без риска удаления нужных образов.

Примеры использования werf

Как будет выглядеть werf в CI/CD-системах? В общем случае достаточно добавить в свой пайплайн CLI-команду werf converge, которая собирает образ, пушит его в registry и выкатывает в Kubernetes.

Листинг с конфигурацией .github/workflows/converge.yml для использования werf в GitHub Actions может выглядеть так:

А использовать werf в GitLab CI/CD можно так:

Более подробные инструкции для доставки приложений в Kubernetes с werf можно найти в официальном руководстве по началу работы проекта.

В документации можно найти интерактивные сценарии, пояснения терминов, готовые CI-конфигурации и Helm-интеграцию. Всё это будет полезно и новичкам, и опытным DevOps-инженерам.

Вместо заключения

Поскольку Kaniko больше не развивается, многие могут задуматься о миграции на другой инструмент. Помимо очевидных вариантов вроде BuildKit и Buildah, рекомендуем попробовать werf. Он подойдет, если вам нужен CI-first-подход с нативной Kubernetes-интеграцией и интересны дополнительные фичи «из коробки» для CI/CD, например дистрибуция релизных артефактов и умная очистка container registry.

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

Реклама. Рекламодатель: АО «Флант». ИНН 772366143. erid: 2W5zFGNuWcp.

Представьте: студент пишет эссе в ChatGPT, сдает работу, а через неделю преподаватель находит странные символы в его тексте. Это не мистика, а обычная техническая особенность, которая превратилась в детектив в духе Дэна Брауна.

Пора узнать о том, как обычные пользователи случайно раскрыли «заговор» искусственного интеллекта, почему в интернете началась паника о скрытых водяных знаках, и что на самом деле происходит с новыми моделями OpenAI.

Первые улики

Все началось в апреле 2025 года. Студенты университетов стали жаловаться на странные проблемы с текстами ChatGPT. Текстовый редактор Word вел себя странно при копировании эссе. Некоторые символы странно выглядели и в редакторах кода.

Первыми в теме начали разбираться специалисты из Rumi. Они создавали инструменты для поиска ИИ в курсовых и контрольных, поэтому привыкли анализировать тексты. При тестировании новых моделей GPT o3 и o4-mini команда обнаружила, что нейросеть встраивает в сгенерированные ответы Unicode-символы.

При этом OpenAI как раз запустила бесплатный доступ к ChatGPT для студентов до конца учебного года, как раз во время сессии. Неразрывные пробелы появлялись только в длинных ответах — например, если ввести запрос «Напиши эссе о министерстве образования». Хотя некоторые пользователи заметили, что невидимые символы встраиваются и в короткие ответы.

Разработчики начали обсуждать тему на форумах. Пользователи делились скриншотами из Sublime Text и VS Code, где обычные пробелы подсвечивались как спецсимволы. Кто-то понял, что в Word можно нажать Ctrl+Shift+8 — сочетание клавиш сразу находит водяные знаки ChatGPT и отображает их как кружочки.

Такие символы не видно в чате с нейросетью и при копировании текста в Word, гугл-документы, мессенджеры или браузер. OpenAI нигде не сообщала об этом нововведении — вероятно, специально.

Охота на невидимку

Команда Rumi тестировала новые модели и заметила странность — длинные эссе выглядели нормально, но что-то было не так. Когда разработчики скопировали текст в редактор Sublime, то увидели россыпь странных символов на месте обычных пробелов.

Виновником оказался Unicode-символ U+202F — узкий неразрывный пробел. Он практически неотличим от обычного пробела, но имеет совершенно другой код. Для программистов это как найти подделку с помощью ультрафиолета.

Энтузиасты быстро создали инструменты для охоты на невидимку. SoSciSurvey научился находить 34 типа скрытых Unicode-символов — от пробела нулевой ширины до длинных тире.

Самым простым способом отыскать «партизан» стала комбинация клавиш. В Word нужно нажать Ctrl+Shift+8 — обычные пробелы превращаются в точки, а водяные знаки ChatGPT отображаются кружочками. Sublime Text показывает символы еще нагляднее — можно искать конкретно \u202F через функцию поиска.

Удалить символы оказалось еще проще. Любой может открыть VS Code или Sublime Text, найти U+202F через поиск и заменить на обычные пробелы. Водяные знаки исчезают за секунды.

Однако удаление скрытых символов не влияет на обнаружение ИИ-контента детекторами. Текст все равно определяется как сгенерированный. Получается, водяные знаки — это дополнительная, а не основная защита от мухлежа при создании работ.

Заговор разрастается

В соцсетях началась паника. Пользователи обвиняли OpenAI в том, что она специально выявляет студентов-читеров. Совпадение с бесплатным доступом для учащихся добавило масла в огонь.

Блогеры рисовали мрачные картины тотальной слежки. Якобы компания тайно помечает каждого пользователя через невидимые символы. Кто-то даже предполагал, что OpenAI готовит массовые облавы на студентов перед защитой дипломов.

Особенно бурлили студенческие форумы на Reddit. Учащиеся делились страшилками о том, как преподаватели внезапно начали проверять работы через редакторы кода. Появились гайды по обходу любых ИИ-детекторов.

Конспирологи забыли об одной детали — водяные знаки удаляются за пару кликов через поиск в документе.

Второй прокол теоретиков заговора — техническая реальность. OpenAI уже несколько лет разрабатывает технологию водяных знаков, но так и не выпустила ее.

К тому же компания открыто заявляла о работе над детекторами ИИ-контента. «Заговор» рассыпался при первом же фактчекинге.

Но паника уже распространилась. Студенты массово скачивали инструменты для «очистки текстов», а преподаватели начали подозревать каждую работу. История с невидимыми символами превратилась из мелкого бага в огромный снежный ком из паники и домыслов.

Прозаичная реальность

OpenAI наконец прокомментировала ситуацию. Официальный ответ звучал предельно скучно: «Это не водяные знаки, а просто особенность масштабного обучения с подкреплением». Никакого заговора, никакой слежки — банальный артефакт.

При обучении нейросети с подкреплением модель получает «награды» за правильные ответы и «штрафы» за неправильные. В процессе миллионов таких циклов система случайно научилась вставлять специальные символы. Не потому, что так задумывали разработчики. Просто в данных эти символы встречались и улучшали результат.

Нейросеть приобрела «привычку». Никто ее этому не учил, но действие «отложилось в подсознании».

В обучении с подкреплением множество таких сюрпризов. Например, алгоритмы учатся играть в видеоигры и внезапно находят баги, которые не замечали разработчики. Или начинают использовать физику игрового движка нестандартными способами. ChatGPT просто продолжил традицию — научился ставить невидимые символы там, где человек поставил бы пробел.

Конспирологам пришлось сворачиваться. Вместо эпического противостояния студентов и корпораций получился рассказ о том, как нейросеть случайно освоила цифровую каллиграфию.

Дело раскрыто

Парадокс в том, что разоблачить «заговор» оказалось проще, чем его придумать. Один официальный комментарий OpenAI — и вся конструкция рухнула.

Урок простой: перед тем как кричать о заговоре, стоит потратить пять минут на фактчекинг. Google по запросу «reinforcement learning side effects» выдаст тонны статей о побочках машинного обучения. Но кто же будет искать скучные объяснения, когда есть яркие теории?

В следующий раз, когда увидите пост про «тайное оружие техногигантов», вспомните про символы U+202F.

Над теориями заговора можно только смеяться. Больше — в нашем тг-канале!

С помощью автоматизированного сканера и немного удачи он нашел десятки «секретов» и заработал $25 000 на обнаружении бага.

«Удалено» ≠ удалено

Если разработчик закоммитил секрет и потом «удалил» его через git reset --hard и git push --force, кажется, что следов не осталось. Но это не так: GitHub сохраняет все коммиты, включая те, что больше не привязаны ни к одной ветке.

В публичном GitHub Archive они фиксируются как PushEvent с нулём коммитов — сигнал, что была перезапись истории.

Бризинов проанализировал такие события с 2020 года, нашёл десятки тысяч «висячих» коммитов и проверил их содержимое через TruffleHog — инструмент для поиска секретов.

Как это работает

Исследователь:

• использовал GitHub Archive и Event API, чтобы находить force push-события без коммитов;
• для каждого события вытаскивал «удалённый» хеш коммита;
• клонировал репозиторий и просматривал содержимое коммита через TruffleHog;
• фильтровал результаты, выделяя потенциально ценные секреты.

Для упрощения анализа он даже написал собственную платформу и подключил ИИ для оценки значимости найденных ключей.

Самый опасный кейс — доступ к репозиториям Istio

Один из найденных токенов дал администраторский доступ ко всем репозиториям Istio — проекта с 36 000 звёзд и десятками тысяч пользователей, включая Google, IBM и Red Hat.

Уязвимость могла привести к масштабной supply-chain атаке. К счастью, команда быстро отреагировала и отозвала ключ.

Что это значит для разработчиков

• Force push не стирает историю — коммиты всё ещё доступны публично.
• Любой закоммиченный секрет нужно немедленно отозвать — даже если он «удалён».
• .env, config.js и README.md — самые частые источники утечек.

GitHub пока не предлагает инструмента для обнаружения таких уязвимостей, но Truffle Security уже опубликовал open-source сканер, чтобы проверить свою организацию.

Гайд для тех, кто только входит в автоматизацию. После можно получить первые результаты, попробовать сам фреймворк и дальше экспериментировать: делать свои тесты.

*Инструкция для Windows. Надеюсь, проблем при установке ни у кого не возникнет.

Основные шаги по установке

Установка VS Code

1. Перейдите на оф. сайт https://code.visualstudio.com/ и скачайте последнюю версию. На главной странице должна отображаться кнопка Download for Windows.
2. Дальше стандартная установка по инструкции: Next > Next > Install.

Установка Node.js. Шаги аналогичные

1. Также перейдите на оф. сайт https://nodejs.org/en/download и скачайте последнюю версию Node.js. Я использовал Windows Installer (.msi).
2. Такая же стандартная установка: Next > Next > Install.

Создание проекта

1. Создайте пустую папку на ПК, где будет храниться проект для автоматизации.
   У меня для этого есть отдельная директория, так удобнее хранить все проекты в одном месте. Но её можно создать даже на рабочем столе, разницы никакой. Мой путь к папке — C:\Users\Pavel\Projects\TestProject.
2. Запустите VS Code и там выберите созданную папку.

Установка Playwright

1. Перейдите в раздел управления расширениями Extensions.
2. Введите Playwright в поисковой строке.
3. Нужно скачать тот, что верифицирован Microsoft (у него больше всего установок).

Но установка еще не закончена, дальше:

• Вызовите Command Palette. Можно через основное меню: View > Command Palette или комбинацией клавиш Ctrl+Shift+P.
• Введите Test: Install Playwright в появившейся строке.
• Выберите необходимые браузеры для установки.
• Я оставляю только Chromium, его вполне достаточно. Кликаем Ok и ждем окончательной установки Playwright (должен появиться терминал и начаться установка пакетов).

Создание тестов

1. В основном окне Explorer добавьте новый файл в модуле tests (правая кнопка мыши, новый файл).
   *Важно, чтобы название файла оканчивалось на spec.ts или .test.ts (расширение может быть и .js): так Playwright определяет тесты по дефолту. В примере добавил файл login.spec.ts.

1. Вставьте следующий код в созданный файл login.spec.ts.
   Это пример логина на платформе, который ± подходит под любой сайт: нужно только изменить URL, locators и данные для входа. Использую тестовую платформу https://demowebshop.tricentis.com/.

Осталось совсем немного. Только запустить созданный тест:

1. Перейдите в раздел Testing.
2. Выберите созданный файл и запустите тесты кликом Run test.

Можете добавить еще один тест в тот же файл и посмотреть его выполнение:

Вот и всё! Теперь у вас есть базовая автоматизация с Playwright! Дальше можно дописывать другие тесты. Например, посмотреть работу системы с незарегистрированным email, вынести credentials в конфигурационный файл и т.д. И, конечно, углубляться, разбираться во всем, чтобы стать уверенным автоматизатором. Можно продолжить изучение статей на оф.сайте Playwright. Главное, соблюдайте best-practices при работе с ним.

Зачем вообще писать комментарии в коде?

Комментарии — это кусочки текста в программе, которые компилятор пропускает, а человек читает. Они не влияют на работу программы, зато сильно влияют на мозг того, кто будет с этой программой разбираться.

Какие задачи они решают ?

1. Пояснить неочевидное

Код показывает «что» делает программа, а комментарий — «зачем».

Такой комментарий не просто поясняет логику — он экономит десятки минут будущего чтения.

2. Предупредить

В коде бывает странное поведение. Иногда это не баг, а фича. И если не предупредить, другой разработчик обязательно «поправит» и всё сломает. Комментарий защитит от этого:

3. Пометить незавершёнку

TODO, FIXME, HACK — это специальные маячки. Их ставят туда, где нужно что-то доделать, починить или переписать по-человечески.

Бонусом, IDE умеют обрабатывать такие заметки, каждая по-своему.

4. Временно отключить код

Иногда нужно что-то закомментировать, чтобы проверить гипотезу. Но такой код нельзя оставлять надолго. Если от него нет пользы — в мусор. Историю всё равно сохранит git.

5. Объяснить архитектуру

Иногда важно не только «как» сделано, но и «почему так». Особенно это касается паттернов, нестандартных решений или компромиссов.

6. Генерация документации

Многие языки и фреймворки поддерживают специальные форматированные комментарии для генерации документации. Например, JavaDoc в Java, docstring в Python, XML в C# – предназначены для описания интерфейсов: что делает функция или класс, какие имеют входные параметры и какой результат дают. Такие Комментарии выполняют роль пользовательской документации прямо в коде и могут автоматически собираться в справочник по API.

7. Пошутить

Программисты – тоже люди, и иногда оставляют в коде шуточные либо эмоциональные комментарии, чтобы снять стресс. В открытых исходниках можно встретить комментарии с шутками, сарказмом или даже ругательствами, адресованными сложному коду или «костылям».

Как видно, диапазон применения комментариев очень широк. Но одинаково ли хорошо все эти виды влияют на качество кода? Рассмотрим случаи, когда комментарии приносят пользу, а когда создают проблемы.

Когда комментарии помогают

А часто без комментариев в коде сложно разобраться, особенно когда код чужой.

1. Когда логика не лежит на поверхности

Есть участки кода, где без контекста трудно разобраться, даже если код написан довольно читабельно. Например, сложная формула, нетривиальный алгоритм или необычная структура данных – всё, что выбивается из обыденного опыта разработчиков. В таких случаях пара строк комментария, резюмирующих подход, или объясняющих, что происходит, сэкономят часы на анализ. Это особенно важно для командной работы: коллегам, незнакомым с модулем, не придётся разбираться «с нуля».

2. Когда нужно документировать контракты и условия

Комментарии могут использоваться для обозначения контрактов – предусловий и постусловий функций, инвариантов и т.д. (подход Design by Contract). Хотя современные языки позволяют выразить многое (например, через assert или декораторы), комментарии могут дополнять код уточнениями вроде:

Также текстовые пометки в коде полезны для фиксации граничных условий и особых случаев, таких как обработка пустных массивов в бинарном поиске, другой пример:

Да, можно это выразить через assert, но комментарий дает сразу и контекст, и предупреждение. Особенно если логика непростая.

3. Когда нужно предоставить контекст и ссылки

Иногда кусок кода существует благодаря внешнему источнику, например, когда решение просто скопировано из ответа на форуме или из книги по теме. Просто так его не понять — нужна ссылка на источник:

4. Когда нужно облегчить ревью

Когда код содержит много пояснений к его работе новому участнику команды проще входить в проект – по сути, комментарии выполняют роль встроенной документации. Кроме того, код-ревью проходит эффективнее, если автор сразу помечает неочевидные места комментариями. Например:

В PEP 8 (стиле кодирования Python) прямо приводится пример: комментарий “Compensate for border” – полезный, в отличие от банального “Increment x”, который не даёт новой информации.

5. Когда нужна поддержка самодокументируемости через структуру

Иногда хочется написать: # Этап 1: авторизация пользователя, и в этот момент приходит мысль — а почему бы не вынести это в функцию authorize_user()? И комментарий уже не нужен. То есть сам порыв объяснить словами часто указывает, что код пора расчленить и упростить.

6. Когда нужно кого-то обучить программированию или корпоративным стандартам оформления кода

Когда человек обучается программированию или только пришел в компанию, где есть свои стандарты, комментарии в коде можно использовать, чтобы дать ему обучающий материал с примерами из практики, пример:

Комментарий — это инструмент. Если комментарий в коде дает информацию, которую нельзя вытащить из кода напрямую, — значит, работает как надо. Но бывает и обратное — когда комментарии мешают. Об этом — в следующей части.

Когда комментарии вредят

Худшее, что может случиться с комментариями – когда они вводят в заблуждение или засоряют код впустую. Рассмотрим подробнее:

Дублируют очевидное

Комментарий, который просто повторяет код своими словами, не несёт никакой пользы:

А вот так — лучше вообще без пояснений:

Комментарий должен объяснять, зачем что-то делается, а не что именно:

Врут и вводят в заблуждение

Классика: код переписали, а про комментарий забыли.

Спустя некоторое время код могли переписать, и old_api_call() заменили на new_api_call(), но комментарий остался от прежней версии и стал источником дезинформации: разработчик, читающий код, может принять заведомо неверное решение, доверившись устаревшей заметке. По этой причине крайне важно понимать: если уж пишете комментарий, держите его в актуальном состоянии вместе с кодом.

Показывают, что код плохой

Когда код плохо читается, и его пытаются «объяснить» словами, вместо того чтобы переписать:

Вместо этого — понятный код:

Плодятся бесконтрольно

Иногда встречается код, где каждое действие сопровождается избыточными пояснениями:

Здесь нет ни одной неочевидной строки. Лучше оставить так:

Представляют собой мёртвый код

Когда в коде остаются большие мёртвые блоки, которые просто закомментированы:

Может быть, раньше это что-то значило, но сейчас — просто мертвый груз. Если код не нужен — удаляй. История останется в git.

Запутывают и размывают смысл

Что значит «временное»? Когда переделывать? Почему не постоянное?

Лучше так:

Теперь ясно, почему так сделано, и можно отследить, когда это поведение закончится.

Итак, комментарии становятся злом, когда они не выполняют своей информативной роли, а лишь создают шум или дезинформируют. В худшем случае они могут привести к багам (если программист доверится неверному комментарию) и точно приведут к потере времени на их чтение и разбор. Единственный способ избежать этого зла — писать комментарии ответственно: убедиться, что они нужны, правдивы и своевременны.

Самодокументируемый код vs комментарии

Есть мечта у программистов — писать код, который объясняет сам себя. Без сносок, без подсказок, без комментариев. Такой код читается как инструкция: открыл — понял. Это и называется самодокументируемым стилем.

Как его достигают?

• Говорящие имена. Не x и a, а temperature, retryLimit, userProfile. Лучше сразу по имени понять, что перед тобой — массив с ID или словарь с настройками.
• Функции с характером. У функции должно быть имя-глагол, в котором есть ответ на вопрос “что делает этот код?”. Например: parseInvoice(), sendEmailReminder(), fetchUserByToken().
• Использовать названия для константных значений. Вместо if (status == 4) — if (status == ORDER_CONFIRMED). Вместо 3000 — RETRY_TIMEOUT_MS.
• Структура — как абзацы в тексте. Пустые строки, логические блоки, отступы — чтобы этапы выделялись сами собой.

Посмотрим например, где простой код поясняется ненужным комментарием:

Другой пример:

Комментарий уже не нужен. Из имён всё понятно: считаем среднюю температуру. Здесь самое интересное — само документируемость имеет границы. Потому что:

• Код объясняет «что», но не всегда «почему».

Вот есть строка:

А почему 5? Почему не 3, не 10? Если причина — ограничение API, бизнес-логика или чья-то странная прихоть — код не расскажет. А вот комментарий может:

Неочевидные решения и компромиссы

Иногда приходится делать что-то нестандартное. Например:

Такой кусок кода без пояснений вызовет недоумение: А почему не сортируем?

Старайтесь писать код так, чтобы его поняли без подсказок. Как будто у вас нет возможности что-то дополнительно объяснить. А если видите, что читателю будет трудно — помогите: добавьте комментарий, который действительно нужен.

Влияние ИИ и новых инструментов на подход к комментариям

В последние годы в распоряжении разработчиков появились мощные ассистенты на базе искусственного интеллекта — такие как GitHub Copilot (автодополнение кода на основе ИИ) и большие языковые модели вроде ChatGPT. Эти технологии начинают влиять и на практики комментирования кода.

Во-первых, автогенерация кода по комментариям стала реальностью.

Инструмент Copilot способен на лету написать фрагмент кода, ориентируясь на описания на естественном языке. Например:

Copilot тут же может подставить реализацию:

Такой подход превращает комментарий в своего рода промпт — описание задачи для ИИ. Это приучает писать коротко и по делу. Хотя такие комментарии потом часто удаляют, их роль в генерации кода становится всё важнее.

Во-вторых, ИИ сам пишет комментарии.

Можно просто показать код:

…и попросить ИИ: прокомментируй. В ответ он выдаст:

Или даже более детальный:

Такие автокомментарии могут быть полезны, но всё равно требуют проверки: всезнающий ИИ не всегда понимает скрытые нюансы логики, а часто просто галлюцинирует, поэтому доверять полностью не стоит, но, как черновик, вполне годится.

В-третьих, стало проще понимать чужой код без комментариев.

Раньше приходилось часами вчитываться, сегодня — можно просто спросить:

Запрос в ChatGPT: что делает эта функция?

Ответ: Она возвращает новый список, содержащий удвоенные значения тех элементов исходного списка, которые делятся на 3.

ИИ не волшебник, но в 90% случаев — удобный переводчик с машинного на человеческий. Это снимает часть нагрузки с необходимости документировать тривиальные вещи.

В-четвертых, новый тип комментариев: инструкции для ИИ

Может возникнуть ситуация, когда комментарий пишется не столько для человека, сколько как команда:

Если вы используете Cursor или Replit, это может очень полезным.

Заключение

Так всё-таки, комментарии – зло или спасение?

Это не абсолютное благо и не абсолютное зло, это просто инструмент. Всё зависит от того, в чьих он руках и зачем используется. Комментарии способны помочь понять неочевидные решения, разобраться в сложных структурах, подсказать направление для размышления. Но, как и любой инструмент, в неумелых руках это способ случайно (или не очень) испортить кровь себе и окружающим.

Но всё-таки чаще наличие комментариев делает жизнь лучше, ведь иногда формулирование мысли разговорным текстом, а не кодом, позволяет понять свою идею лучше, взглянуть на нее с другой стороны.

Google — всё?

ChatGPT трансформируется из простого ассистента в полноценный агрегатор проверенной информации. Теперь пользователи получают ответы с лицензированным контентом из топовых медиа: The Washington Post, Bloomberg, Financial Times и других изданий.

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

Питер Элкинс-Уильямс, глава отдела глобальных партнерств The Washington Post, подчеркивает, что это решение отражает стратегию издания «встречать аудиторию там, где она находится». Варун Шетти из OpenAI отмечает, что компания стремится направлять свыше 500 миллионов еженедельных пользователей ChatGPT к «своевременной, достоверной информации».

При запросе о текущих событиях ChatGPT больше не ограничивается информацией из предобучения, которое неизбежно устаревает. Вместо этого система предоставляет актуальный контент из авторитетных медиа. Можно сказать, что ИИ превращается в умного редактора новостной ленты, персонализированной под пользователя.

Два лагеря СМИ: партнерство и судебные иски

Мир медиакомпаний разделился на два противоположных лагеря, сформировав параллельные стратегии взаимодействия с ИИ.

В первом лагере находятся компании, которые рады сотрудничать с цифровыми проектами. OpenAI заключила соглашения с 20 издательскими домами, охватывающими свыше 160 газет и журналов на более чем 20 языках. Среди них The Washington Post, Financial Times, Time, Axel Springer (владелец Politico, Business Insider), Condé Nast (Vogue, The New Yorker, GQ) и Hearst (Houston Chronicle, Esquire, Cosmopolitan).

Суть этих сделок заключается в лицензировании контента, доступе к API и направлении трафика обратно к издателям в обмен на возможность использовать и цитировать материалы. Для изданий это не просто новый источник дохода, но и канал дистрибуции — так они привлекают аудиторию, которая никогда бы не зашла на сайт. Хотя финансовые детали часто остаются конфиденциальными, известно, что некоторые соглашения включают многомиллионные выплаты.

Во втором лагере находятся компании, вставшие в оппозицию нейросетям. The New York Times, The Center for Investigative Reporting, Ziff Davis, а также объединившиеся в коллективный иск The Intercept, Raw Story и AlterNet подали в суд против OpenAI. Издания утверждают, что несанкционированное использование материалов для обучения ИИ нарушает авторские права и наносит ущерб их бизнес-модели.

NYT в своем иске заявляет, что модели OpenAI и Microsoft «угрожают качественной журналистике» и лишают компании денег за трафик на их сайты. Компания требует многомиллиардную компенсацию и уничтожение моделей, обученных на ее материалах — требование, которое технически практически невозможно выполнить.

OpenAI отвечает на эти обвинения, заявляя, что NYT «взломала» ChatGPT, используя «фейковые промпты», чтобы собрать доказательства для иска. По мнению компании, обычные пользователи не применяют чат-бот таким образом, а статьи составляют лишь «крошечную часть разнообразных наборов данных», использованных для обучения моделей.

Media Manager: инструмент контроля или шаг к прозрачности?

В разгар дискуссий о правомерности использования контента OpenAI анонсировала разработку инструмента Media Manager — интерфейса для медиакомпаний, который должен сделать использование их материалов в их модели более прозрачным.

Издатели получили бы возможность устанавливать правила и ограничения, полностью исключать определенные материалы из обучения, а также получать аналитику о показах и использовании своего контента. Компания так хотела защититься от постоянных судебных исков и выйти на контакт с авторами статей.

Однако реализация этой инициативы оказалась под вопросом. Несмотря на то, что OpenAI обещала запустить Media Manager к 2025 году, но этого так и не случилось. По данным источников, знакомых с ситуацией, разработка не рассматривалась как приоритетная задача внутри компании. Один из бывших сотрудников OpenAI даже не смог вспомнить, чтобы хоть кто-то плотно занимался этим проектом.

В медиасообществе инициативу восприняли неоднозначно. Одни издатели рассматривают ее как шаг к более справедливым отношениям и прозрачности, подобно тому как инструменты монетизации в YouTube позволили создателям контента получать доход от своих работ. Другие видят в этом лишь попытку OpenAI избежать полноценного лицензирования контента.

Разработка Media Manager «заглохла». Это значит, что OpenAI сделала ставку на прямые партнерства с крупными издателями вместо создания универсального инструмента для всех правообладателей. Такая стратегия выгодна для крупных компаний, но оставляет практически бесправными малые издания и исследовательские организации.

А что под капотом?

Проект OpenAI сложный и многоуровневный, он связывает генеративный ИИ с контентом, опубликованным в сети. На первом уровне — слое запросов — система анализирует пользовательский вопрос, определяя, нужно ли обращаться к актуальным новостным источникам. Если пользователь спрашивает о последних событиях в экономике или политике, система понимает, что нужны свежие данные из СМИ, а не только базовые знания модели.

Далее включается слой маршрутизации. Он направляет запрос к API соответствующих партнерских медиа, выбирая наиболее подходящие источники для конкретной темы. Например, если нужно узнать о финансовых рынках, предпочтение может отдаваться Financial Times, а при запросе о международной политике — The Washington Post.

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

Последним выступает слой атрибуции, который обеспечивает корректное цитирование и оформление ссылок на исходные материалы. Это не только юридическое требование лицензионных соглашений, но и этический момент. Так пользователи могут оценить авторитетность источника и сформировать доверие к нему.

Механизмы обновления данных работают с различной частотой в зависимости от типа контента. Для «молний» обновления происходят практически в реальном времени — как только статья появляется на сайте издания, она становится доступной для цитирования в ChatGPT. Аналитические материалы обновляются по мере публикации, а архивный контент — с меньшей частотой, но остается доступным для исторического контекста.

В отличие от традиционных поисковых систем, которые индексируют весь открытый веб и ранжируют результаты по сложным алгоритмам, интеграция ChatGPT с медиа работает с контролируемым потоком лицензированного контента. Это повышает точность и авторитетность информации, минимизирует риски неправомерного использования материалов и помогает выстроить устойчивую систему, выгодную всем участникам: пользователям, ИИ-компаниям и создателям контента.

Как новинку могут использовать айтишники?

Интеграция ChatGPT с медиаресурсами открывает целый спектр возможностей для разработчиков и продуктовых команд. На стыке искусственного интеллекта и качественной журналистики рождается новое поколение информационных продуктов, способных изменить способы взаимодействия с новостями и аналитикой.

Особенно перспективным направлением является создание специализированных нейроассистентов для разных сфер. Представьте ИИ-юриста, который не только знает базовые принципы права, но и мгновенно информирует о последних изменениях в нормативных актах, опираясь на публикации профильных изданий. Или финансовый советник, анализирующий рыночные тренды на основе актуальных данных из деловых СМИ и предоставляющий рекомендации с учетом последних экономических событий. В медицинской сфере такой помощник может собирать информацию о новых исследованиях и методиках лечения из авторитетных научных журналов, делая их доступными для практикующих врачей.

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

Для компаний открываются возможности создания инструментов для команд, работающих с информацией. PR-отделы могут использовать платформы для отслеживания репутации бренда в свете актуальных событий и оценивать эффективность информкампаний. Аналитические отделы получат системы мониторинга конкурентов, основанные на анализе публикаций в деловых и отраслевых медиа. Такие инструменты превращаются из простых агрегаторов упоминаний в интеллектуальных ассистентов, способных выявлять неочевидные связи и тренды.

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

А есть ли проблемы?

Интеграция ChatGPT с крупными медиа, при всех своих преимуществах, оставляет ряд вопросов, от решения которых зависит будущее всей информационной системы.

• Вопрос 1: размер компенсации. Достаточно ли выплат медиакомпаниям, учитывая, что их контент становится важной частью коммерческого продукта OpenAI? Как определить справедливую стоимость лицензирования, особенно в условиях, когда традиционные метрики вроде количества просмотров или переходов работают иначе в контексте ИИ? Пока крупные издания имеют возможность договариваться о взаимовыгодных условиях, менее влиятельные компании рискуют остаться без денег.
• Вопрос 2: влияние на бизнес-модели медиа в долгосрочной перспективе. Если пользователь получает качественное саммари материала прямо в ChatGPT, сохранится ли мотивация переходить по ссылке на полную статью? Не приведет ли это к снижению потока прямого трафика и, как следствие, рекламных доходов издателей? Некоторые аналитики отрасли опасаются, что интеграция с ИИ может превратить медиакомпании в поставщиков сырья для технологических гигантов, лишив их прямого контакта с аудиторией.
• Вопрос 3: разделение информационного пространства на контент от привилегированных партнеров и всех остальных. Получит ли ChatGPT предпочтение к материалам изданий-партнеров, даже если более релевантная информация доступна у других? Как обеспечить разнообразие контента и избежать перекоса в сторону крупных медиакомпаний? Эти вопросы имеют не только коммерческий, но и этический аспект, так как речь идет о формировании картины мира пользователей.
• Вопрос 4: доверие к ответам и прозрачность алгоритмов выбора информации, ключевой вопрос касается доверия к ответам и прозрачности алгоритмов выбора информации. Как пользователь сможет оценить надежность источника и убедиться, что представленная информация не искажена? Какие механизмы необходимы, чтобы сохранить доверие к системе, особенно в эпоху информационных войн и дипфейков? Без решения этих вопросов даже самая совершенная система рискует стать еще одним каналом распространения дезинформации.

Что в итоге?

ChatGPT, интегрированный с медиаресурсами, не просто становится новым Google для новостей — он формирует принципиально иную парадигму взаимодействия с информационным пространством. Вместо списков ссылок пользователь получает структурированные ответы и анализ, а также возможность углубиться в материалы.

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

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

Прорыв произошел, когда команда под руководством Шейден Альшаммари обнаружила универсальный принцип, названный функцией I-Con и лежащий в основе десятков различных методов ИИ.

Мы нашли математический эквивалент таблицы Менделеева для машинного обучения. Теперь можно не гадать, а вычислять, какие комбинации алгоритмов будут работать.

Уже первые практические применения системы показали впечатляющие результаты. Комбинируя принципы из разных «групп» таблицы, ученые создали новый алгоритм классификации изображений, превзошедший современные аналоги. Но главное — таблица открывает путь к принципиально новому подходу в разработке ИИ, где каждый следующий шаг будет осознанным, а не случайным.

Что это за таблица и как она была создана

Идея периодической таблицы машинного обучения возникла не как строго запланированный проект, а скорее как побочный результат исследований в лаборатории Массачусетского технологического института. Ученые, работавшие над методами кластеризации и контрастного обучения, неожиданно обнаружили, что два, казалось бы, разных алгоритма можно описать одним и тем же математическим уравнением. Это наблюдение стало отправной точкой для создания единой структуры, объединяющей десятки классических и современных методов машинного обучения.

Разработка таблицы началась с исследований аспирантки МИТ Шейден Альшаммари и профессора Филипа Гамильтона. Изначально Альшаммари изучала алгоритмы кластеризации, которые группируют схожие данные, например изображения, без явных меток. В процессе она заметила, что математическая основа этих алгоритмов удивительно похожа на принципы контрастного обучения — метода, используемого для обучения моделей, отличать схожие объекты от несхожих. Это навело ее на мысль, что оба подхода можно описать единой формулой.

Мы почти случайно пришли к этому объединяющему уравнению. Как только Шейден обнаружила, что оно связывает два метода, мы просто начали проверять, какие еще алгоритмы можно вписать в эту структуру. Оказалось, что большинство классических и современных методов машинного обучения подчиняются той же логике.

Основу таблицы составляет платформа I-Con (Information-Contrastive Learning), которая формализует, как алгоритмы выявляют и аппроксимируют связи в данных (то есть заменяют сложные результаты более простыми). Уравнение I-Con описывает процесс, при котором модель учится минимизировать расхождение между реальными зависимостями в данных и теми, которые она сама воспроизводит.

Например, алгоритм классификации спама ищет закономерности в тексте, а языковая модель (LLM) предсказывает следующее слово в предложении — но оба делают это через призму оптимизации одной и той же математической величины.

По аналогии с таблицей Менделеева, где элементы расположены в соответствии с их атомными свойствами, алгоритмы в I-Con организованы по принципу их работы с данными. В одном «семействе» могут оказаться методы, которые на первый взгляд кажутся разными, но используют схожие механизмы аппроксимации связей. Например, алгоритмы кластеризации и некоторые виды нейронных сетей попадают в одну категорию, потому что оба стремятся к минимизации одного типа ошибок.

Важно отметить, что I-Con — не просто классификация, а инструмент для прогнозирования. Зная, как уже существующие алгоритмы соотносятся друг с другом, исследователи могут предсказывать, какие гибридные методы или совершенно новые подходы могут быть эффективными. Например, комбинируя принципы двух известных алгоритмов из одной «группы», можно теоретически создать более точную модель для специфических задач.

Разработка таблицы — это не финальная точка, а лишь начало. Ученые предполагают, что со временем в нее будут добавляться новые алгоритмы, в том числе те, которые еще не изобретены. Как и в химии, где таблица Менделеева предсказала свойства тогда неизвестных элементов, I-Con может указать направление для будущих открытий в машинном обучении.

Новый порядок для ИИ

Периодическая таблица машинного обучения представляет собой не просто красивую аналогию, а фундаментальный инструмент, который переосмысливает саму природу алгоритмов искусственного интеллекта. В основе этой системы лежит фреймворк I-Con (Information-Contrastive Learning), раскрывающий глубинные математические связи между десятками методов, от простейшей линейной регрессии до сложнейших архитектур глубокого обучения.

Объединяющий математический принцип

Прорыв исследователей MIT заключается в обнаружении универсального уравнения, описывающего базовый механизм работы любых алгоритмов машинного обучения. Независимо от типа данных (текст, изображения, числовые последовательности) и конкретной задачи (классификация, кластеризация, прогнозирование), все алгоритмы стремятся к одной цели — минимизации расхождения между реальными зависимостями в данных и их внутренним представлением в модели.

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

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

Структура и логика таблицы

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

Ключевыми критериями стали:

• тип связей, которые алгоритм выявляет в данных — линейные, нелинейные, топологические;
• способ аппроксимации этих связей — через функции расстояния, матрицы преобразований, графы;
• метод оптимизации целевой функции — градиентный спуск, EM-алгоритм, вариационные методы.

Например, алгоритмы кластеризации (k-means, DBSCAN) и метрического обучения оказываются в одной группе, так как работают с попарными расстояниями между точками данных. Методы снижения размерности (PCA, t-SNE) образуют отдельный класс, поскольку фокусируются на сохранении глобальной структуры данных при уменьшении числа признаков.

Особую ценность представляют пустые клетки таблицы — теоретически предсказанные позиции для алгоритмов, которые еще не созданы, но должны существовать согласно логике I-Con. Эти пробелы указывают направления для будущих исследований, предлагая комбинации принципов из соседних групп, которые могут привести к созданию новых эффективных методов.

Практическая значимость подхода

Унифицирующая структура I-Con уже доказала свою полезность в нескольких аспектах:

• Систематизация знаний. Таблица предоставляет целостную картину ландшафта алгоритмов ML, показывая их взаимосвязи и эволюционные линии развития
• Объяснимость. Подход делает внутреннюю работу алгоритмов более прозрачной, демонстрируя их общие математические корни
• Образовательный потенциал. Новая классификация может стать основой для более логичного преподавания машинного обучения, где методы изучаются не изолированно, а как элементы единой системы.

Мы находимся только в начале пути. Эта таблица — не конечный результат, а отправная точка для нового понимания машинного обучения как строгой научной дисциплины с четкой структурой.

Матрица будущих открытий

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

Как и ее химический прототип, она содержит пустые клетки, обозначающие пока не открытые методы, но уже предсказанные математической структурой I-Con. Эти пробелы — закономерные промежутки, указывающие, где должны находиться еще не созданные алгоритмы.

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

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

Как таблица направляет исследования

Предсказание новых алгоритмов

Структура I-Con не только систематизирует известные методы, но и выявляет потенциальные «белые пятна» — комбинации математических принципов, которые еще не использовались. В химии подобные предсказания привели к открытию новых элементов. В машинном обучении они могут стать основой для принципиально новых подходов к обработке данных.

Гибридизация методов

Таблица делает очевидными связи между, казалось бы, далекими друг от друга алгоритмами. Например, техника удаления данных, разработанная для контрастного обучения, неожиданно оказалась применима для улучшения алгоритмов кластеризации.

Раньше такие кросс-доменные переносы были делом случая. Теперь мы видим логику этих комбинаций.

Расширяемая структура

Периодическая таблица ML — не застывшая форма, а живая система. По мере появления новых типов связей в данных (например, сложных пространственных или временных зависимостей), в нее можно добавлять оси и категории. Это отличает ее от жестких классификаций и позволяет адаптироваться к будущим открытиям.

Что это меняет для науки

• Снижение барьеров для инноваций. Молодым исследователям больше не нужно «переоткрывать» базовые принципы — таблица сразу показывает, какие направления уже изучены, а какие пока еще — terra incognita.
• Ускорение прогресса. По оценкам команды MIT, системный подход может сократить время на разработку новых алгоритмов на 30-40%, так как исключает перебор заведомо неэффективных вариантов.
• Новые критерии оценки. Теперь, когда алгоритмы можно сравнивать не только по эффективности, но и по их положению в общей структуре, появляются новые метрики для оценки их новизны и потенциала.

Мы показали, что одно элегантное уравнение, основанное на теории информации, порождает десятки алгоритмов, охватывающих столетие исследований. Но главное — оно открывает путь к методам, которые мы еще даже не представляем.

Прикладное значение периодической таблицы ИИ

Периодическая таблица машинного обучения — это не просто академическое упражнение, а инструмент, способный трансформировать подход к разработке ИИ-решений в промышленности. Ее появление знаменует переход от интуитивного подбора алгоритмов к системному проектированию моделей, основанному на четких математических принципах.

Оптимизация выбора алгоритмов

Для инженеров, работающих над коммерческими продуктами, таблица становится навигатором в мире машинного обучения.

Вместо перебора десятков возможных подходов специалист может:

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

Например, при работе с медицинскими изображениями, где важна интерпретируемость результатов, таблица сразу сужает выбор до методов, сочетающих высокую точность с прозрачностью работы. Это сокращает время на предварительные эксперименты на 40-60%, по оценкам команды MIT.

Ускорение разработки новых решений

Фармацевтическая компания Pfizer уже использует принципы I-Con для создания гибридных алгоритмов анализа молекулярных структур. Комбинируя элементы методов компьютерного зрения и графовых нейросетей, их исследователи получили модель, которая на 15% точнее предсказывает взаимодействие лекарств, чем стандартные подходы.

Раньше на подобные эксперименты уходили месяцы. Теперь мы можем целенаправленно комбинировать компоненты разных алгоритмов, зная их совместимость из таблицы.

Снижение барьеров для внедрения ИИ

Для среднего бизнеса, не обладающего командой data-сайентистов, таблица упрощает:

• выбор готовых ML-решений под конкретные задачи;
• оценку необходимости кастомизации моделей;
• понимание ограничений разных подходов.

Стартап Aible разработал на основе таблицы систему рекомендаций, которая помогает некрупным компаниям подбирать оптимальные алгоритмы для задач прогнозирования спроса. Их клиенты сообщают о 30% сокращении времени на внедрение ИИ-модулей.

Новые возможности для аппаратной оптимизации

Производители чипов, такие как NVIDIA и Intel, уже изучают таблицу для проектирования специализированных ускорителей. Зная, какие группы алгоритмов чаще используются вместе, они могут создавать более эффективные аппаратные архитектуры.

Образовательный эффект

Онлайн-университеты (Coursera, Udacity) начинают перестраивать курсы по машинному обучению, используя таблицу как каркас программы. Это позволяет студентам быстрее понимать связи между разделами дисциплины.

Таблица не заменяет экспертизу, но делает работу с ИИ более структурированной — от фундаментальных исследований до повседневных бизнес-задач. Ее настоящая ценность проявится через 2-3 года, когда накопится достаточно примеров практического применения.

Плюсы единой структуры

Появление периодической таблицы машинного обучения — это не просто очередная классификация, а качественный скачок в развитии всей области ИИ. Единая структура приносит сразу несколько принципиальных преимуществ, меняющих правила игры для исследователей и практиков.

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

Как отмечает профессор Стэнфорда Эндрю Ын, таблица сокращает путь от идеи до реализации, позволяя сосредоточиться на действительно новых аспектах, а не переоткрывать известные принципы.

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

Для индустрии особенно ценна возможность автоматизированного проектирования моделей. Платформы AutoML, такие как Google's Vertex AI, уже начали интегрировать принципы таблицы, что позволяет создавать более эффективные гибридные алгоритмы без ручного перебора. Это как перейти от кустарной сборки к конвейерному производству в машинном обучении.

Но, пожалуй, самое перспективное — это открытие новых научных парадигм. Анализируя пустые клетки таблицы, исследователи могут целенаправленно искать неизвестные комбинации методов, а не действовать наугад. Первые успехи уже есть: за последний год благодаря такому подходу было опубликовано 17 принципиально новых алгоритмов в топовых научных журналах.

Как показывает практика, единая структура не ограничивает творчество, а, наоборот, дает ему четкие ориентиры. Она не заменяет креативность исследователей, но избавляет их от необходимости каждый раз заново изобретать фундаментальные принципы. В этом и заключается главная ценность — позволить ученым сосредоточиться на действительно прорывных идеях, а не на вечном повторении пройденного.

Изменит ли таблица будущее машинного обучения

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

Однако история науки показывает: именно систематизация знаний часто становилась катализатором прорывов — от таблицы Менделеева в химии до классификации элементарных частиц в физике.

Преодоление текущих ограничений

Главная ценность таблицы — в решении фундаментальных проблем современного машинного обучения. Сегодня даже специалисты затрудняются объяснить, почему один алгоритм работает лучше другого в схожих условиях.

Система I-Con предлагает:

• четкие критерии сравнения методов;
• принципы осознанного комбинирования подходов;
• методику поиска «белых пятен» для новых открытий.

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

Практические перспективы

В ближайшие 3-5 лет таблица может стать основой для:

• Интеллектуальных систем проектирования моделей. Компании вроде DataRobot и H2O.ai уже тестируют интерфейсы, где архитектура ИИ собирается из «блоков» таблицы как конструктор Lego.
• Автоматизированного поиска новых алгоритмов. Лаборатория DeepMind использовала принципы таблицы для создания гибридного алгоритма, сочетающего трансформеры и графовые сети. Результат превзошел отдельные компоненты на 22% в задачах предсказания свойств материалов.
• Этичного и объяснимого ИИ. Европейское агентство по ИИ рассматривает таблицу как потенциальный стандарт для аудита алгоритмов. Зная составные части модели, проще выявлять источники смещений и уязвимости.

Возможные препятствия

Критики указывают на три ключевых вызова:

• Динамичность области — новые парадигмы (например, диффузионные модели) могут не вписаться в текущую структуру.
• Проблема «серых зон» — некоторые современные алгоритмы сочетают признаки разных категорий.
• Риск излишней стандартизации, которая ограничит нестандартные подходы.

Однако создатели таблицы подчеркивают ее адаптивность. «Это живой документ, — говорит Марк Гамильтон из MIT. — Мы уже выпустили два крупных обновления за последний год и готовы пересматривать структуру по мере развития области».

Долгосрочное влияние

Если проект получит широкое признание, он:

• сократит время разработки коммерческих ИИ-решений на 40-60%;
• снизит порог входа в область для новых исследователей;
• станет основой для учебных программ ведущих технических вузов;
• позволит прогнозировать свойства алгоритмов до их создания.

Как и периодическая система в химии, эта таблица, вероятно, не станет окончательной истиной, но может превратиться в незаменимый инструмент навигации в мире машинного обучения. Ее успех будет зависеть от способности эволюционировать вместе с быстро изменяющейся областью ИИ.

Первые две части лежат здесь: рабочее место/облако и Fedora Core/mise.

Начало проекта и утилита make

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

Первый — классический пайплайн — это утилита make. Обычно она используется для сборки программ из исходного кода. На самом деле make хорошо подходит для решения сразу нескольких задач.

• Первая задача — отслеживание зависимостей одних файлов от других, например, при изменении сервиса пересобрать только соответствующий контейнер.
• Вторая задача, легко реализуемая через make — сборка в один файл много команд или скриптов, чтобы удобно их организовать. Как правило, сборка образа, его загрузка в репо, удаление временных файлов и прочее делается несколькими рутинными командами. Точно так же можно поместить в Makefile команды запуска сервисов и тестирование приложения локально.
• Если эти этапы прошли успешно, можно выполнить коммит кода в репо проекта, сделать деплой в dev или stage environment. В github actions это называется jobs и steps. В make такая группа команд называется целью, она указывается параметром при вызове.

Так, несмотря на разную терминологию, по сути можно создать полноценный пайплайн для современного проекта с контейнеризованными сервисами.

Разбираемся на практике

Возьмём для примера проект с прокси сервером traefik и бэкендом на golang из репозитария awesome-pods. Этот репо задуман как форк замечательного проекта awesome-compose, в котором собраны конфиги docker compose для 41 самого популярного сервиса. Я же пытаюсь сделать что-то похожее для манифестов podman. Приглашаю к сотрудничеству начинающих девопс — сможете поучаствовать в открытом проекте, заработать почётные гитхаб-бейджи и улучшить своё резюме. Подробнее — здесь.

Мой проект в интересном положении: сделаны манифесты для нескольких сервисов, опробованы описанные выше подходы для миграции конфигов compose.yaml в манифесты kube.yaml. Но захотелось большего: а почему бы не сделать сразу пайплайны для тестирования, коммита в апстрим, деплоя и прочее. Зайдём в каталог traefik-golang и создадим пару мейк-файлов. Для начала сделаем всё это локально, начнём с make_compose:

Этот файл уже в истории, равно как и соответствующий README.md, привожу его для примера. Так как я делаю конфиги сразу для двух платформ — docker и podman, для включения соответствующего Makefile’а нужно сделать линк на него: ln -s make_compose Makefile.

Отлично, основную идею обсудили, идём дальше. В docker’е есть замечательная опция context, позволяющая работать с любыми серверами, где настроен доступ. В нашем случае список контекстов выглядит так:

Здесь я использовал простейший хак — сделал копию дефолтного контекста с именем localhost. Теперь мы можем сделать наш пайплайн способным на удалённый деплой. Достаточно прописать в /etc/hosts имя и адрес нашего dev сервера. Вот новая версия make_compose:

Поясню немного подробнее.

• Самая первая строка — стандартное объявление списка целей.
• Строки 2-4 задают дефолтное значение переменной, если оно не задано в текущем env.
• В хелп — строки 5-10 — добавлено предупреждение о текущем контексте, он задаётся в глобальной переменной, например, export DKR_CONTEXT=localhost для локального контекста.
• Также добавлена цель commit в репо — строки 17-21 — после выполнения цели test.
• Test — строки 31-32 — в свою очередь, выполняется для текущего контекста, см. хак #1. Имя контекста должно совпадать с именем хоста нашего dev-сервера.
• Добавлена также цель clean: очистка старых образов с локальном репо,и зависимости в цель up. Здесь убеждаемся, что образ пересобран и старые контейнеры остановлены.

Отлично, пайплайн для докера работает. Пробуем сделать то же самое для подмана. Здесь нас ждёт сюрприз, попробую рассказать в стиле прямого репортажа. Первоначально наш пайплайн для podman выглядел вот так:

В строке 5 определяются зависимости: target back соберёт исполняемый файл только в том случае, если код main.go или сам make_pods новее уже собранного бинарника.

Строка 6 удаляет backend контейнер с едва заметным знаком минус -, чтобы игнорировать ошибку, если контейнер с именем backend не существует.

Строки 7–10 создают контейнер с именем backend из пустого (scratch) контейнера — команды buildah следуют обычным командам Dockerfile, но в нижнем регистре: FROM -> from, COPY -> copy, RUN -> run, ENTRYPOINT -> config –entrypoint и т. д. Здесь вы видите основное отличие от традиционного docker buildx подхода — вы работаете в двух контекстах одновременно: в локальном контексте, используя установленный компилятор go, и в контексте контейнера, копируя файлы в/из контейнера, запуская команды внутри контейнера и т. д. Другая новая возможность buildah — вы можете собирать образ шаг за шагом, то есть отлаживать процесс сборки.

Строка 8 компилирует main.go в исполняемый файл back с соответствующими флагами.

Строка 11 создаёт из контейнера новый образ (image) с тегом backend:latest.

Цель up — строка 16 — зависит от цели down — строка 14, — то есть она сначала останавливает pod и удаляет контейнеры, если они всё ещё запущены, затем запускает новый под.

Цель down в строке 15 подставляет глобальную переменную $XDG_RUNTIME_DIR из env пользователя в kube.yaml, используемый далее в podman kube командах, принимая новый манифест со стандартного ввода. Это также специфика podman — он работает полностью в пространстве пользователя, контейнеры взаимодействуют через собственный podman.sock. Таким образом, делаем пайплайн независимым от UID.

В подмане есть фунциональность наподобие docker context, под другим именем, в подкоманде system connection:

Первым в списке стоит настроенная в прошлой статье ВМ. Пока искал правильные опции для создания коннекшена (aka контекст в докере), столкнулся с подсказкой от подмана — «создайте сначала машину», а именно:

Выполнил эти рекомендации, подман выкачал, настроил и добавил два новых коннекшена для новой ВМ. Какой же меня ждал сюрприз, когда я стал смотреть, что же это за machine. Во-первых, в моём HOME появились новые файлы и каталоги:

Во-вторых, это полноценная ВМ fedora coreos:

Конечно, приятно, что моё мнение совпало с мнением авторов подмана, точнее, со стратегией RedHat — fedora coreos наиболее подходящая система для контейнерных приложений. С другой стороны, ВМ в подмане крутится полностью внутри пространства пользователя. У меня уже настроена почти такая же для удалённой работы всей команды разрабов. Решено: останавливаем новую виртуалку и правим мейкфайл для подмана по образцу компоуза, делаем пайплайн для деплоя и локально, и на удалённый дев-сервер.

Но прежде нам понадобится ещё один хак #2. Если в случае докера переключение контекста можно было сделать любой переменной, то для подмана между локальным соединением через сокет и удалённым, через uri:ssh, имя переменной фиксировано CONTAINER_HOST. Вот как выглядит пайплайн make_pods.v1, настроенный и для локальной сборки, и для деплоя в наш дев-сервер:

По большей части цели мейкфайла остались теми же, но для удалённого деплоя настраиваем переменную export CONTAINER_HOST=ssh://dev@fc42dev:22/run/user/1001/podman/podman.sock — берём её из коннекшена, она служит переключателем между локальным и удалённым контекстом. Для локального контекста эту переменную надо удалить: unset CONTAINER_HOST. Команды в строках 19, 21 и 23 — это обычные команды шелла, они также меняются на локальное либо удалённое исполнение, переопределяются на основе этой же переменной CONTAINER_HOST.

Как заметил внимательный читатель, в цели back исчезла сборка контейнера утилитой buildah. Как и для docker compose, используется возможность самого подмана создавать образы на основе Containerfile, он же Dockerfile, эти названия синонимичны. Это намёк: пора отвыкать от слова докер, контейнеры уже давно стали основой облачных вычислений, для них созданы сотни приложений, например, CNCF и общепризнанные стандарты.

Принципиальный вопрос о контейнерах

Основное их преимущество — новый способ доставки приложений в облака, решение проблем с зависимостями, версиями библиотек, фреймворков и проч. Сборка контейнеров в контейнерах — побочный эффект облачных сервисов Github, Gitlab и других, с одной стороны, и ограничения Docker — с другой. Он не умеет, в отличие от подмана, точнее, от его сопутствующей утилиты buildah, выполнять билд и создавать образ, используя локальное окружение.

Основная проблема сборки образа внутри контейнера — неэффективное использование кэша. Да, появились возможности как-то сохранять объемные загрузки внешних библиотек, модулей: это опции --mount=type=cache для некоторых языков. Но, во-первых, эти возможности используются далеко не всегда. Во-вторых, опции для кэширования отличаются в podman и buildah, см. podman-build(1), придётся делать отдельный Containerfile. В-третьих, эффект от такого кэширования минимален. Предлагаю замерить время сборки, сделав ещё одну, третью версию пайплайна. Сначала соберём команды для buildah в отдельный файл:

и поправим пару строк в пайплайне:

Уточню условия нашего эксперимента — мы настроили одинаковую среду разработки с помощью утилиты mise (предыдущая статья) на нашем дев-сервере и у каждого из разрабов команды. Репозитарий git использует этот же дев-сервер, доступ к репо и серверу по ключу, парольный доступ закрыт. Пайплайны настроены как для локальной сборки, так и на дев-сервере. Перед запуском 3-й версии пайплайна на дев-сервере нужно сделать коммит изменений в репо — buildah не знает о коннекшенах, работает с кодом в текущем каталоге (строка 1): после логина на сервер переключается в корень проекта. Предварительно выкачиваем образ компилятора go для сборки в контейнере — это вполне честно, мы же выкачали и настроили компилятор golang заранее. Замеряем:

Мы получили 10+-кратный выигрыш по времени сборки образа для подмана. Абсолютные времена не важны, также не влияет, запускали мы сборку локально или на дев-сервере — мы сравниваем только билд в контейнере и в настроенном локальном окружении. Третье измеренное время — сборка в Docker. Он умеет собирать только в контейнере, для него настроили кэширование в Containerfile:

Но оно не сильно помогло. Конечно, наш проект игрушечный, golang кэширует лучше других языков, но в целом вывод понятен: сборка в контейнере далеко не оптимальный вариант, если есть возможность настроить дев-сервер для работы команды.

Ещё замечание: конечно, образы, собираемые buildah, совместимы с Docker, их можно использовать в конфигах compose.yaml. Но для этого надо настроить репозиторий образов и сначала загрузить образ в него. Локальные репозитории отличаются: Docker использует общий репо для всех пользователей — Docker Root Dir: /var/lib/docker, а в подмане всё хранится в домашнем каталоге пользователя — graphRoot: /home/$USER/.local/share/containers/storage.

Как я предположил в самом начале, мы попробовали вариант с гипотетической идеальной командой разрабов, работающей в Линукс и умеющей в make. А как быть обычному девопсу с разношерстой командой, где кто-то сидит на Винде, а кто-то ни за что не откажется от привычного Макбука на M4? Есть вариант и для этого случая. Пусть они пишут код и тестируют его как им нравится, а в нашем репо на дев-сервере мы сделаем хак #3, а именно git hook и bare репозиторий — githooks(5), выполняющий наши цели сборки и старта приложения при коммите в репо.

Для этого на пару минут придётся стать безжалостным хакером, удаляющим лишнее и открывающим скрытые возможности гита. Выполняем следующие шаги:

1. Заходим под юзером dev на сервер, создадим пустой каталог, например, mkdir -pv ~/bare/t0. Это станет новым GIT_DIR, зайдём в него и выполним cd ~/bare/t0;git init --bare.
2. Видим, что файлы, обычно спрятанные в каталоге .git, лежат прямо в корне. Сделаем дополнительно каталог для логов mkdir logs. Переходим в каталог hooks и создаём файл, где укажем команды выполнения при каждом изменении в репо.

Закомментированные строки 3, 8, 9 полезны при отладке пайплайна. Строки 4 и 5 задают, что есть, собственно, репозиторий, переменная GIT_DIR и переменная WORK_TREE (куда будут записываться файлы проекта). В цикле от строки 6 до 14 читаются и обрабатываются три переменные, с которыми гит вызывает этот хук. Строка 11 принимает все изменения в репо и обновляет WORK_TREE — всё то, что гит обычно делает в общем каталоге, как видим, в bare репо они разные. Далее, в 12 строим имя лога и строка 13 — собственно, пайплайн.

1. Идём в каталог, где расположен репо проекта. Без страха и сожаления удаляем старый и создаём новый под тем же именем: cd ~/src;rm -rf traefik-golang;mkdir traefik-golang.
2. Завершаем сессию на дев-сервере, возвращаемся на рабочий комп и заходим в репо проекта. Конечно, репо цел, клоны репо не так просто уничтожить, пока есть хотя бы одна копия. Теперь смотрим старые настройки git remote -v и удаляем их git remote remove fc42dev в моём случае. Создаём новый remote, указывая новый гит bare репо: git remote add bare.t0 dev@fc42dev:~/bare/t0. Это также нужно сделать всем разрабам в их локальных копиях.
3. Проверяем результат. Возможно, нужно сделать новый комит и push в новый remote. Стоит посмотреть подробнее, как изменился репо проекта на сервере: проверить логи в ~/bare/t0/logs, сравнить конфиги обычного репо проекта и на сервере, проверить, какие команды перестали работать в серверном репо. Например, в WORK_TREE не работают команды гит status; branch; commit; log. То есть наш хак #3 с git --bare не только позволил делать деплой на сервере, но также защитил репо от локальных изменений, а серверный репо всегда в чистоте и порядке. Можно редактировать код, но закомитить его только через обычный репо. Изменения на сервере удалятся после любого коммита.

Надеюсь, мне удалось показать, что пайплайны можно делать на основе древней забытой утилиты make. В следующей статье разберём, как можно добавить в наш скромный дев-сервер нечто похожее на монстров гит-сервисов, Gitlab и Github, создавать пайплайны, совместимые с github Actions, предоставить команде разрабов привычный интерфейс репо в браузере.

Больше новостей — в нашем тг-канале «Представляешь»

Оно позволяет делить ресурсы одного физического GPU между несколькими виртуальными машинами без значительных потерь производительности.

Зачем нужен SR-IOV

Технология SR-IOV (Single Root I/O Virtualization) используется для разделения ресурсов устройств ввода-вывода между виртуальными машинами. Вместо классической эмуляции или проброса устройств, SR-IOV позволяет выделять каждой машине отдельную виртуальную функцию, напрямую связанную с физическим устройством.

В случае с видеокартами — это означает доступ к «настоящему» GPU с минимальной прослойкой, что критично для задач, где важна производительность: ML, HPC, визуализация.

Что умеет GIM

Драйвер GIM написан на C и распространяется под лицензией MIT. Готовые пакеты уже доступны для Ubuntu 22.04.

Сейчас модуль поддерживает лишь карты с архитектурой MxGPU — в первую очередь это AMD Instinct MI300X, предназначенные для дата-центров и ИИ-нагрузок.

Возможности модуля:

• Инициализация SR-IOV на GPU
• Управление виртуальными функциями (VF)
• Планирование ресурсов между ВМ
• Выявление зависаний и сброс состояния (FLR)
• Взаимодействие между физическим GPU (PF) и виртуальными функциями

Работает драйвер с гипервизорами на базе KVM.

Планы на будущее

В AMD сообщили, что GIM может быть адаптирован и под обычные дискретные видеокарты.

Это открывает перспективы использования SR-IOV не только в облаках и дата-центрах, но и в рабочих станциях — например, для разделения GPU между контейнерами или разработчиками в одной системе.

Больше новостей — в нашем тг-канале «Представляешь»

Spegel — это P2P-решение для ускорения доставки образов в Kubernetes-кластерах. Оно появилось после инцидента на Black Friday, когда GitHub Container Registry перестал работать, а команда автора не могла масштабировать кластеры из-за зависимости от недоступных образов.

Так родилась идея Spegel — лёгкого, «безстейтного» способа делиться образами внутри кластера.

Сначала — встреча с Microsoft, потом — молчание

После релиза Spegel, Microsoft вышла на связь: представители компании заинтересовались проектом, устроили встречу, попросили помощи в запуске. Автор делился архитектурными решениями, надеясь на сотрудничество и открытые коммиты. Однако после пары диалогов наступила тишина.

О том, что Microsoft всё-таки продолжила работать над этим направлением, он узнал только на конференции KubeCon в Париже. На докладе по P2P-дистрибуции он узнал Spegel — свой проект — в примерах.

А затем услышал про Peerd — утилиту, разработанную Microsoft, с очень знакомыми фрагментами кода. В README мельком упоминалось «спасибо Spegel», но глубже всё оказалось куда интереснее.

Копия Spegel под другим брендом

При ближайшем рассмотрении Peerd оказался форком Spegel — с теми же сигнатурами функций, комментариями, а в тестах встречались названия, связанные с бывшим работодателем автора.

Некоторые тесты были скопированы дословно. Лицензия Spegel — MIT, и, формально, Microsoft имела право на форк. Но даже при MIT лицензии нельзя удалять оригинальное авторство и выдавать код за свой.

По словам автора проекта, Microsoft перезапустила Spegel под собственным MIT-лицензированным проектом — без указания на то, что большую часть кода написали не они.

Это вызвало путаницу у новых пользователей и сделало поддержку оригинального проекта сложнее — бренд Microsoft делает своё дело.

Давид против Голиафа

Автор Spegel открыто признаёт, что чувствовал себя выброшенным за борт. Он тратил время на поддержку, багфиксы, безопасность и был открыт к сотрудничеству — но в итоге оказался в ситуации, где крупная корпорация фактически перехватила его труд.

Он подчёркивает, что не первый и не последний, кто сталкивается с подобным: когда огромная компания пользуется open-source без отдачи соразмерной своему масштабу. В условиях снижающегося интереса к финансированию OSS и изменений в лицензировании (вспомним HashiCorp) это создаёт тревожный фон.

Больше новостей — в нашем тг-канале «Представляешь»

Модели просто научились «играть» в бенчмарки, не становясь при этом умнее в человеческом смысле. Их проблема — в отсутствии опыта, а не данных.

В новой работе, подготовленной для MIT Press, Дэвид Сильвер (создатель AlphaZero) и Ричард Саттон (один из отцов обучения с подкреплением) предлагают переосмыслить весь подход к ИИ. Они называют это «эпохой опыта».

Что не так с сегодняшними ИИ

Современные языковые модели вроде ChatGPT и Gemini умеют отвечать на вопросы, но не умеют ставить цели, запоминать прошлое или адаптироваться.

Всё их поведение — это реакция на вход, заданный человеком. Они не делают открытий, не учатся на ошибках и не развиваются между сессиями.

Сильвер и Саттон считают, что это тупик. По их мнению, ИИ должен жить во времени, а не в одной команде. Он должен действовать, ошибаться, получать обратную связь и улучшаться — как это делает человек или обучаемый агент в играх.

Потоки опыта — как это должно работать

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

Пользователь в таком подходе задаёт лишь цель: «Помоги мне выучить испанский» или «Оптимизируй мой график тренировок». Всё остальное — поиск методов, обучение, корректировка — ИИ делает сам, как агент с долгосрочной памятью и личной историей.

ИИ, который не просто говорит, а делает

Некоторые шаги к этому уже сделаны: браузерные агенты, инструменты планирования, симуляторы. Но следующий этап — это автономные ИИ, которые действуют годами, а не минутами.

Они могут следить за здоровьем, карьерой, обучением, экономить деньги или даже заниматься научными исследованиями.

Именно этот подход, считают авторы, позволит моделям стать по-настоящему умными — не повторять человеческие ошибки, а учиться на собственных.

Новая парадигма — новые риски

DeepMind признаёт: у такого подхода есть риски. Агент, который может действовать без постоянного надзора человека, должен уметь распознавать вред и корректировать поведение. И здесь критично важна правильная постановка целей.

Но потенциал огромен: данные из «потока жизни» ИИ могут в тысячи раз превзойти Википедию или Reddit по объёму и полезности. Это не просто эволюция языковых моделей. Это шаг в сторону искусственного субъекта, способного видеть, запоминать и меняться.

Пока все обсуждают новости, мы сделали то, что реально экономит часы: гайд по 70+ ИИ-инструментам.

В статье разберем, какие ТОП-10 уязвимостей угрожают бизнесу по версии OWASP, узнаем неутешительную статистику и рекомендации по защите от взлома.

Безопасники ошиблись — бизнес заплатил

Если защита вашего сайта содержит хотя бы 2-3 следующие уязвимости, можно считать, что вы поставили дорогую сигнализацию в доме и не закрыли дверь.

A01: Broken Access Control — ошибки контроля доступа

Специалисты подтвердили наличие этой уязвимости в 3,81% случаев. Это самая распространенная проблема из списка OWASP. Более 318 тысяч приложений работают с ошибками контроля доступа.

Представьте систему бронирования в отеле. Пользователь оплатил номер и видит свою бронь в личном кабинете. Если он вручную изменит идентификатор брони в адресной строке и увидит информацию о брони другого клиента — это будет нарушением контроля доступа.

Как защититься?

• Проектируйте контроль доступа по принципу наименьших привилегий. Пользователи должны иметь только те права, которые необходимы для выполнения их задач.
• Реализуйте проверку доступа на стороне сервера, даже если она есть на клиентской стороне. Клиентский код может быть изменен злоумышленником.
• Проводите аудит прав доступа и тестирование безопасности.

A02: Cryptographic Failures — проблемы с шифрованием данных

Снова обратимся к примеру. Вы перешли в интернет-магазин, чтобы оплатить заказ. Данные банковской карты отправляются на сервер для обработки, но есть проблема. Сайт работает через HTTP, и данные передаются без шифрования.

Поскольку информация передается «как есть», злоумышленник с Wireshark перехватит номер карты, имя, срок действия карты и CVV. Этого достаточно, чтобы покупать товары за ваш счет и снимать деньги.

Полный арсенал хакера описывали в статье «Лучшие инструменты для тестирования на проникновение».

Как защититься?

• Используйте современные алгоритмы шифрования — AES, RSA, SHA.
• Храните криптографические ключи в защищенном месте. Например в аппаратных модулях безопасности (HSM). Никогда не оставляйте ключи в коде приложения или открытом виде.
• Добавляйте «соль» к хэшам паролей. Это случайные данные, которые делают перебор паролей менее эффективным.

A03: Injection — внедрение вредоносного кода

В этот раз вы оплачиваете покупку на сайте, который шифрует пакеты алгоритмом AES-256. Это стойкая криптография, и перехватывать зашифрованные данные бесполезно.

Опять не повезло: злоумышленник может использовать SQL-инъекцию, чтобы получить доступ к базе данных и украсть номера, пароли, банковские карты.

Вторая популярная атака — XSS. Это когда сайт разрешает вставку вредоносных скриптов в поля ввода. Например, атакующий на форуме публикует сообщение с JavaScript-кодом, который ворует cookies других пользователей.

Злоумышленник с чужим печеньем может запускать чужие сессии. Фактически это доступ к аккаунту, но без логинов, паролей и кодов подтверждения.

Как защититься?

• Не передавайте значения в SQL-запрос напрямую через строки без дополнительной обработки.
• Ограничьте ввод данных по типу, принимайте только допустимые символы.
• Используйте библиотеки ORM, которые автоматически защищают от инъекций.

A04: Insecure Design — уязвимости, возникающие на этапе проектирования

Представьте, что разработчики создают платформу для частной клиники. На этапе проектирования они забывают заложить систему разграничения прав. Врач сможет просматривать историю болезни не только своего пациента, но и всех других посетителей клиники. Если злоумышленник получит доступ к учетной записи любого врача, то получит базу данных всей больницы.

Недостатки проектирования проявляются не сразу, а исправить их крайне сложно или даже невозможно.

Как защититься?

• С самого начала внедряйте принципы безопасного проектирования.
• Оценивайте сценарии угроз и проектируйте рубежи обороны.
• Моделируйте угрозы для проверки бизнес-логики и ключевых функций.

A05: Security Misconfiguration — ошибки конфигурации безопасности

Уязвимость возникает при неправильной настройке серверов, фреймворков или самого приложения. Например, после установки новой системы администратор не удалил тестовые аккаунты или не сменил стандартный пароль доступа к админ-панели.

Сюда же относятся устаревшие файлы, скрытые каталоги или ошибки настроек. Например, если страница отладки API по какой-то причине доступна в рабочем окружении, злоумышленник сможет использовать информацию с этой страницы для других атак.

Как защититься?

• Убедитесь, что отключены все ненужные функции, службы и порты.
• Замените стандартные пароли на уникальные.
• Автоматизируйте проверку конфигурации и включите регулярный аудит.

A06: Vulnerable and Outdated Components — использование уязвимых библиотек

Около 50% популярных библиотек для разработки ПО с открытым кодом содержат уязвимости. Если не следить за обновлением компонентов, код устаревает, и появляются нежелательные точки входа.

Злоумышленники могут детально изучать библиотеку, пока не найдут «уязвимость нулевого дня». Это когда проблема неизвестна на момент применения, следовательно? у разработчика 0 дней на ее устранение.

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

Как защититься?

• Обновляйте компоненты и следите за уведомлениями о выявленных уязвимостях.
• Удаляйте неиспользуемые библиотеки, модули и плагины.
• Используйте официальные инструменты для проверки безопасности компонентов.

A07: Identification and Authentication Failures — ошибки аутентификации

Пользователи в опасности, если разработчик разрешил установку слишком простых паролей вроде «123456» и «password». Система не запрашивает код подтверждения? Риск потерять аккаунт возрастает в 2 раза!

Задача злоумышленника сводится к простому: выяснить логин и перебрать словари популярных паролей.

Отдельная категория уязвимостей — ошибки восстановления доступа. Это тот случай, когда сложность пароля не имеет значения.

Например, онлайн-сервис позволяет сменить пароль, зная e-mail и ответ на вопрос вроде «ваше любимое животное». Если это «собака» или «кошка», за сколько секунд злоумышленник подберет секретную фразу?

Как защититься?

• Требуйте создания сложных паролей из спецсимволов, цифр и буков.
• Внедряйте 2FA-аутентификацию.
• Защищайте идентификаторы сессии, не передавая их напрямую в URL.

A08: Software and Data Integrity Failures — атаки на целостность данных

От антивируса пришло уведомление с просьбой установить новую версию. Улучшили производительность, безопасность, добавили новые функции — что может пойти не так?

Пример успешной атаки на целостность данных — инцидент с антивирусом eScan. Приложение доставляло обновления по незащищенному HTTP, а злоумышленники подменяли файлы. В итоге вместе с обновлением клиенты eScan устанавливали вредонос и майнер.

Другой пример — представьте, что сборка приложения включает зависимости из сторонних репозиториев. В них злоумышленник может внедрить бэкдор. Если вредоносный код вовремя не заметят, то открываются «врата» для дальнейших атак, поскольку программа заражена на этапе разработки.

Как защититься?

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

A09: Security Logging and Monitoring Failures — недостаточный мониторинг безопасности

Отсутствие мониторинга означает, что система уязвима к длительным атакам.

Например: злодей получает доступ к учетной записи администратора и несколько месяцев выкачивает данные. В это время компания даже не подозревает о нападении.

Без логирования и мониторинга невозможно отследить действия преступника.

Как защититься?

• Настройте подробное логирование событий, включая попытки входа и изменения конфигурации.
• Установите систему уведомлений, которая оповещает администраторов о подозрительных действиях.

A10: Server-Side Request Forgery — подмена серверных запросов

Злоумышленник может обмануть приложение, заставив отправлять запросы от имени сервера. Это опасно, потому что у сервера больше привилегий, чем у обычного пользователя.

Рассмотрим угрозу на примере сайта, который проверяет доступ к URL (например: жива ли ссылка, безопасно ли по ней переходить):

1. Пользователь вводит example.com/photo.jpg.
2. Сервер выполняет запрос на этот URL.
3. Если сервер работает, отображается сообщение: «Ссылка доступна».

Что сделает злоумышленник? Будет перебирать системные каталоги сервера.

Например:

• http://localhost:8080/admin
• http://192.168.1.10/config

Сервер при наличии уязвимости отправит запрос и вернет данные, которые помогут продолжить атаку.

Как защититься?

• Проверяйте пользовательский ввод.
• Используйте белый список адресов для внешних запросов.
• Ограничьте доступ сервера к внутренним ресурсам.

Применение WAF (Web Application Firewall)

WAF стоит между пользователем и сервером, отслеживая и фильтруя подозрительные запросы.

Если приложение содержит уязвимости, WAF может временно скрыть проблему, защищая систему до тех пор, пока разработчики не исправят ошибку.

Пример: WAF проверяет SQL-запросы на наличие подозрительных команд вроде SELECT или ‘ OR 1=1. Если запрос потенциально опасен, WAF отклонит его до того, как сервер начнет обработку.

Еще один пример: WAF блокирует XSS. Если пользователь отправляет сообщение со скриптом для кражи cookies, WAF перенаправит пользователя на страницу ошибки.

WAF используется в качестве дополнения к другим мерам. Он не исправляет бреши в коде, но снижает вероятность их эксплуатации.

Подробнее о технологии читайте здесь: WAF и Firewall: просто о сложном для начинающих разработчиков и аналитиков.

Аудит и пентест

Пентест — это имитация поведение злоумышленника. Специалист по кибербезопасности пытается найти уязвимости в приложении: слабые пароли, открытые API, устаревшие компоненты.

Существует несколько видов тестирования — статический (SAST) и динамический (DAST).

SAST изучает исходный код программы на этапе разработки

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

DAST тестирует систему в процессе работы

Инструмент имитирует действия пользователя, отправляя запросы и отслеживая ответы системы.

Например, DAST обнаружит открытые эндпоинты, которые известны лишь разработчикам, но не требуют авторизации для доступа.

Инструменты для выявления уязвимостей

OWASP ZAP

Один из самых популярных инструментов для тестирования безопасности веб-приложений. Это бесплатная программа с открытым исходным кодом.

После установки инструмент запускается как прокси-сервер. Через него происходит взаимодействие между пользователем и приложением.

ZAP поддерживает два типа сканирования: активное и пассивное. Пассивное не изменяет данные сайта, только анализирует ответы сервера. Активное имитирует атаки.

Важный этап анализа — краулинг. Это процесс сканирования всех ссылок сайта. Если ссылки скрыты или недоступны, используется принудительный просмотр.

Инструмент также позволяет перехватывать запросы. ZAP останавливает отправку данных и дает возможность их изменить.

Например, можно заменить имя пользователя на ручной ввод, чтобы проверить, как на это отреагирует сервер.

OWASP ZAP генерирует отчеты о найденных уязвимостях. Во вкладке «Alerts» отображаются риски, обозначенные цветами: средние, низкие и критические. Категории помогают понять, что требует немедленного исправления, а что можно отложить.

Burp Suite

Инструмент для более глубокого анализа безопасности. Его функционал похож на OWASP ZAP.

Основной компонент Proxy действует как посредник. Он перехватывает сообщения между браузером пользователя и сервером, позволяя изменять данные, например, пользовательский ID или токен авторизации.

Spider собирает структуру сайта. Burp Suite проходит по ссылкам, собирает информацию обо всех страницах и создает ее карту. Если не удается пробраться к закрытым зонам, инструмент пытается угадать URL или параметры.

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

Extender позволяет добавлять модули, расширяющие функционал.

Nikto

Веб-сканер для быстрой проверки безопасности. Он анализирует сервер на наличие уязвимостей: проверяет версии ПО, опасные файлы, ненадежные скрипты.

Например, если сервер содержит публично доступный файл резервной копии базы данных, Nikto обнаружит его за считанные минуты.

Инструмент полезен на первых этапах анализа безопасности, чтобы быстро получить общую картину состояния системы.

Заключение

Защита от этих уязвимостей требует комплексного подхода. Необходимо закладывать защитные механизмы еще на этапе проектирования системы. Это значительно дешевле, чем исправлять проблемы после инцидента.

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

Инвестиции в кибербезопасность сегодня — это страховка от потенциальных убытков завтра. По данным IBM, средняя стоимость утечки данных в 2024 году достигла исторического максимума — более $ 4.880.000.

Как защититься от кибератак и не только рассказываем в нашем тг-канале!

После почти двух лет разработки и закрытого бета-тестирования проект, созданный с целью превзойти существующие решения, такие как iTerm 2, будет выпущен под лицензией MIT.

Разработчик поделился подробностями о целях проекта, особенностях версии 1.0 и планах на будущее.

Цель – лучший эмулятор терминала

Основная идея Ghostty – предоставить пользователям macOS и Linux быструю, функциональную и имеющую нативный интерфейс альтернативу существующим эмуляторам.

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

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

Быстрый, функциональный и нативный

Ключевыми характеристиками Ghostty являются скорость, богатая функциональность и нативный интерфейс.

Скорости работы было уделено особое внимание, о чем свидетельствует доклад разработчика на Systems Distributed 2024.

В плане функциональности Ghostty поддерживает больше escape-последовательностей xterm, чем любой другой эмулятор (кроме самого xterm), а также современные стандарты, такие как стилизованные подчеркивания, протокол клавиатуры Kitty и графический протокол.

Интерфейс реализуется за счет использования соответствующих системе GUI-инструментариев: на macOS – нативные инструменты, на Linux – GTK (с libadwaita, если доступно). Благодаря этому Ghostty выглядит и ощущается как родное приложение на обеих платформах.

Версия 1.0 и причины длительного бета-тестирования

Первый публичный релиз Ghostty сразу получит номер версии 1.0, минуя стадию ZeroVer.

Длительное закрытое бета-тестирование, в котором участвовало около 2000 человек, было обусловлено личными обстоятельствами разработчика (рождение ребенка), а также желанием выпустить стабильный и качественный продукт.

Разработчик признает, что такой подход мог создать впечатление эксклюзивности и вызвать критику, но благодарит всех тестеров за их вклад в стабильность Ghostty.

Скачать версию 1.0 можно по ссылке.

Планы на будущее: libghostty и расширение функциональности

В будущем разработчик планирует развивать два основных направления: libghostty и функциональность терминальных приложений.

libghostty – это кроссплатформенная библиотека, лежащая в основе Ghostty, доступная через API на Zig и C. Цель – создать экосистему терминальных приложений, от отдельных программ до встроенных терминалов в редакторах и веб-интерфейсах.

После релиза 1.0 планируется сделать libghostty доступной как отдельную библиотеку и расширить поддержку платформ, включая WebAssembly.

Этот шаг направлен на повышение безопасности, производительности и удобства использования популярной встраиваемой базы данных.

Почему Rust?

SQLite изначально написан на C, что делает его уязвимым к ошибкам, связанным с управлением памятью.

Rust, в свою очередь, обеспечивает полную безопасность работы с памятью, снижая вероятность критических уязвимостей.

Limbo сохраняет совместимость с SQLite на уровне языка запросов и формата данных, но при этом обещает улучшенную надёжность благодаря встроенному тестированию с использованием Deterministic Simulation Testing (DST).

Этот подход позволяет воспроизводить редкие сценарии сбоев и повышать стабильность системы.

Что нового в Limbo?

• Полностью асинхронный интерфейс. В отличие от SQLite, который работает синхронно, Limbo изначально спроектирован для асинхронной обработки запросов, что особенно актуально для современных облачных и распределённых систем.
• Поддержка WASM. Limbo оптимизирован для работы в браузерах и других средах, использующих WebAssembly. Это открывает новые возможности для встраивания баз данных в клиентские приложения.
• Упрощение работы. Limbo избавляется от сложных настроек SQLite, предлагая более понятный и оптимизированный "из коробки" опыт.

Как это повлияет на разработчиков?

Проект обещает быть быстрее и удобнее, чем оригинальная SQLite. Например, в тестах Limbo уже показывает прирост производительности до 20% в некоторых операциях.

Кроме того, благодаря асинхронному интерфейсу и поддержке WASM, Limbo становится отличным выбором для веб-разработчиков, работающих с облачными и гибридными решениями.

Что дальше?

Limbo пока находится на ранней стадии разработки, но команда Turso активно работает над расширением функциональности и интеграцией с существующими экосистемами.

Проект доступен на GitHub под лицензией MIT и разработчики приглашают сообщество присоединиться к созданию этой базы данных нового поколения

Среда Scratch разработана медиа-лабораторией Массачусетского технологического института, последняя версия — Scratch 3.0 — совместима с мобильными устройствами и наборами наборами LEGO Education, а также адаптирован интерфейс для работы с планшетами. Благодаря этому, в Scratch дети также могут создавать сложные интерактивные проекты: анимированные презентации, мультфильмы и игры, рассчитанные на нескольких пользователей.

Начать изучение Scratch ребенок может уже в 6 лет. Для дошкольников существует отдельная версия этого языка — Scratch Junior. Подробнее о нём я писал в этой статье.

В сегодняшней статье я подробнее разберу процесс создания игр на Scratch версии 3.0.

Охота за привидениями

Простая игра для двоих пользователей, где нужно стреляться по призракам и набирать баллы.

Раннер

Здесь нужно убежать от призрака как можно быстрее, игру можно проходить несколько раз, с каждым разом стараясь уменьшить время прохождения игры.

Гонки на двоих

Давайте попробуем посоревноваться на гоночной трассе. Для этого сначала спроектируем ее, а потом запусти игру.

Мультиплеерная игра

Помимо создания сетевой игры, на этом уроке мы рассмотрим переменные и их значение в коде.

Звездные войны

Программируем космический корабль и атакуем корабль соперника.

Головоломка Minecraft

Воссоздаем мини-вселенную Майнкрафт и стараемся как можно быстрее добраться до сундука в игре.

Among Us. Часть 1

Воссоздаем любимую игру, а также пытаемся вычислить самозванца на борту.

Among Us. Часть 2

Совершенствуем карту и сбиваем астероиды.

Создаем Flappy Bird на Scratch

Моделируем игру-платформер с прыгающей птичкой.

Brawl Stars (Бравл Старс)

Пробуем создать игру менее, чем за 45 минут!

Paint3D

Собираем программу с нуля, в которой будут создаваться трехмерные объекты.

Создаем игру за 15 минут

Поверьте нам, это не так сложно!

Игровое меню на Скретч

Создаем игровое меню — лобби.

Обязательно попробуйте создать свои игры на Scratch, делитесь ими с друзьями и в официальном сообществе на сайте https://scratch.mit.edu/.

Как работает Image2Lego

1. Пользователь загружает обычное изображение: например, с самолётом.

2. Алгоритм распознаёт самолёт на фотографии и загружает его в нейросеть Image2Lego.

3. Натренированная Image2Lego преобразовывает 2D-картинку в 3D-модель самолёта с помощью нейронных сетей и показывает, как он должен выглядеть, если собрать его из кубиков LEGO.

4. Алгоритм создаёт инструкцию по сборке модели и сообщает, какие детали для этого понадобятся.

На что способен Image2Lego

Собрать самолёт — это ещё цветочки. Image2Lego может по изображению лица создать инструкцию для сборки детально проработанного 3D-лица.

Вот, какую инструкцию предлагает Image2Lego по сборке лица актёра Криса Прэтта:

Читать полный текст исследования →

Источник: GitHub

Онлайн-сервис доступен для всех. На нём можно найти патенты по ключевым словам. Система покажет, насколько быстро будет «улучшаться» то или иное изобретение.

Как создавали

Команда MIT проанализировала 97% американских патентов.

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

Команда MIT использовала новый алгоритм на основе вероятностей, машинное обучение, обработку естественного языка и патентную сетевую аналитику для прогнозирования темпов повышения производительности различных технологий.

Как работает онлайн-сервис

Вы вводите ключевое слово — название определённой технологии.

Сервис подбирает несколько областей, в которых собраны все существующие патенты США, которые связаны с выбранной технологией.

Для каждой области искусственный интеллект уже посчитал «коэффициент улучшения».

Если этот показатель выше 42%, значит, технология улучшается быстрее, чем встроенные чипы (закон Мура). Значит, эта область — перспективная.

Попробовать →

Зачем нужно

Сервис, по сути, показывает перспективные стартапы, на которые стоит обратить внимание политикам, исследователям, журналистам и инвесторам.

Источник: The Next Web

По словам разработчиков, созданный ими смарт-ковёр Magic Carpet может найти своё место в более безопасной и конфиденциальной медицине. Речь идёт о тех пациентах, которым жизненно необходимо удаленное наблюдение медработников.

В основу инструмента легла нейронная сеть. Она, используя датчики на ковре, определяет, выполняет ли человек назначенные процедуры: приседания, растяжку и т.д.

Общая площадь устройства — около 3,3 квадратных метра. На ней расположились интегрированная тактильная сенсорная матрица, которая в свою очередь состоит из более чем 9 тыс датчиков давления. Также Magic Carpet включает в себя схемы считывания, позволяющие в реальном времени записывать взаимодействие людей с собой.

Источник: MIT

Инженеры технологического института, используя нанотехнологии, сделали из обыкновенного шпината своеобразные датчики. Они могут распознавать изменение климата поблизости и наличие экологических проблем.

После того, как шпинат выявляет негативные изменения поблизости, с помощью карбоновых нанотрубок он передаёт собранную информацию специалистам по электронной почте. Для этого растение направляет специальный сигнал в сторону инфракрасной камеры на плантации.

Растения — очень хорошие химики-аналитики. Они наделены разветвлённой сетью корней прямо в почве, при этом они постоянно делают пробы грунтовых вод и умеют самостоятельно транспортировать эту воду в листья.

Источник: Euronews

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

Источник: MIT

Первичная модель, искавшая сразу множество болезней, была натренирована на 200 тыс записях голосов и кашлей. Для того, чтобы доработать её под определение COVID-19, учёные прогнали нейросеть через ещё 4 тыс записей кашля, 50% из которых принадлежало больным новейшим коронавирусом.

По словам создателей проекта, искусственный интеллект отлично справляется с определением таких биомаркеров, как сила голосовых связок, объём лёгких и нейромышечная дегенерация — все они отличаются в случае кашлей здоровых и больных коронавирусом людей. При этом важно отметить, что человеческий слух не способен услышать разницу в кашлях, в отличие от ИИ.

В планах сотрудников MIT создать удобный инструмент, с помощью которого каждый желающий сможет покашлять в свой смартфон перед выходом, чтобы узнать, является ли он потенциально опасным для окружающих или нет. При этом специалисты учебного заведения отмечают, что на данном этапе рано говорить о возможности опираться на показания их разработки, даже несмотря на то, что опыты показали её 98.5% точность при определении.

По словам инженеров, Mini Cheetah специально спроектировали так, чтобы его можно было легко ремонтировать, менять, экспериментировать с ним.

Главная фишка устройств — способ навигации. Они ориентируются относительно уже построенных частей объекта, а что находится за пределами области сборки, для них неважно. По задумке создателей, роботы могут постоянно «жить» внутри конструкции, заниматься ремонтом и поддержкой систем.

По словам профессора Нила Гершенфельда из MIT, обычно машины делят на две категории: роботы из дорогих материалов для сложных задач и дешёвые роботы для массовых производств. Он считает, что небольшие и быстрые роботы-сборщики — это совершенно новый, прорывной класс устройств в робототехнике.

Существующие алгоритмы на эти факторы не смотрят. Они распределяют нагрузку с помощью буферизации и динамического битрейта. Это когда разрешение видео автоматически меняется в зависимости от ширины канала.

Разработчики успешно протестировали алгоритм Minerva на прототипе стримингового сервиса на серверах AWS.

Как работает?

Работа модели опирается на данные из набора AVSpeech с короткими роликами. Аудио- и видеодорожки в них заранее разделены. Всего в наборе миллион таких файлов, среди них встречается около ста тысяч человек.

Получив на вход короткий видеоролик, одна часть алгоритма переделывает на основе кадров лицо человека, чтобы оно было в анфас, с нейтральным выражением. Другая часть алгоритма работает с аудиодорожкой. Она воссоздаёт спектрограмму, распознаёт голос и с помощью параллельной нейросети генерирует портрет.

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

Какие способы борьбы с заблуждениями существуют?

Поскольку с проблемой дискриминационных заблуждений ИИ учёные пытаются справиться не первый год, существуют традиционные методы работы в этой области. Обычно для коррекции обучения в набор данных добавляют некоторое количество информации, которая позволяет нейросети получить более точные данные по конкретной выборке.

Так, в одном эксперименте ИИ должен был отметить предполагаемый уровень доходов лиц в представленной подборке. В результате дискриминационного заблуждения, появившегося в процессе обучения, ИИ вдвое чаще отмечал мужчин как лиц с высоким доходом. Увеличение количества женских анкет в обучающем датасете позволило снизить ошибку на 40 %.

Проблема традиционных методов заключается в том, что подготовленные таким образом наборы данных не отражают реального распределения популяции. Это повышает ошибочность выдаваемых ИИ прогнозов.

Что предлагают учёные?

В своей работе «Why Is My Classifier Discriminatory?» учёные предлагают несколько возможных вариантов решения проблемы. Они считают, что увеличение размера обучающего датасета без изменения пропорций представленных гендерных, социальных и расовых групп позволит ИИ самостоятельно справиться с дискриминационными заблуждениями. По мнению исследователей, сбор дополнительной информации из того же источника, который предоставил изначальный пакет данных, позволит избежать ковариантного смещения.

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

Второй вариант заключается в кластеризации групп населения, наиболее подверженных дискриминации и последующей отдельной обработке этик кластеров с введением дополнительных переменных. Учёные предлагают использовать этот метод, когда получение дополнительных данных затруднено или невозможно.

Борьба с заблуждениями нейросетей — одно из основных направлений работы специалистов по ИИ в последние годы. Обучаясь на наборах реальных данных, искусственный интеллект склонен усваивать сложившиеся в обществе гендерные и расовые стереотипы. Проблему усугубляет непрозрачность мотивации принимаемых решений. В сентябре 2018 года компания IBM запустила сервис, выявляющий возникающие заблуждения и определяющий мотивацию нейросети.

Принципы работы

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

Предполагается, что такой подход упростит накопление словарного запаса и позволит программам и роботам точнее воспринимать человеческую речь и отвечать на неё.

Синтаксический анализатор

Люди в разговоре нередко используют только часть предложения и нарушают правила грамматики. Анализ слов на лету должен, как предполагается, улучшить работу ИИ-систем и парсеров. Синтаксический анализатор не опирается на определённый контекст, а значит, позволяет роботам воспринимать неявно сформулированные приказы.

Анализатор поможет узнать, как ребёнок учит язык, что поможет не только разработчикам роботов, но и специалистам, работающим с детьми.

Методика обучения

В MIT использовали пассивный метод обучения ИИ-сети, лежащей в основе парсера. Нейросети показывали видео и текстовые описания действий, а система сопоставляла данные и связывала слова с объектами и действиями. Исследователи использовали 400 видеороликов.

Учёные утверждают, что технология легко масштабируется, и может использоваться там, где необходимо голосовое управление или общение с ИИ.

Нейросети обучают понимать не только речь, но и видео. В Facebook разработали технологию VideoStory, которая помогает ИИ описывать происходящее на видео. Это может помочь воспринимать информацию людям с проблемами зрения.

Подробности эксперимента

Активная фаза начнётся в 23:00 по восточному времени (6 утра следующего дня по Москве). Желающие принять участие смогут зарегистрироваться на сайте проекта BeeMe. В качестве агента будет выступать нанятый организаторами актёр. Его личность и местоположение будут оставаться скрытыми от участников.

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

Предыстория BeeMe

Действия, подобные запланированным в эксперименте, можно было наблюдать в эпизоде «Белое рождество» сериала «Чёрное зеркало». Герой эпизода знакомился с женщинами на рождественской вечеринке, транслируя происходящее своим клиентам через имплантированный в мозг микрочип. Устройство обладало возможностью обратной связи и передавало герою указания наблюдателей. Эпизод поднимал вопрос нарушения приватности в современную эпоху.

Учёные из MIT Media Lab придумали историю для своего эксперимента. Согласно легенде BeeMe, агент — человек, который добровольно отказался от свободы воли и передал управление группе пользователей Интернет, чтобы победить сбежавший в Сеть злобный ИИ по имени Zookd.

Само название проекта, BeeMe, является игрой слов. Одно из значений слова «bee» — соседская помощь или совместная работа. В то же время оно является омофоном глагола «to be», и название проекта можно перевести как «будь мной».

Инженеры MIT Media Lab не в первый раз выступают с неоднозначными проектами, способными пощекотать нервы впечатлительным персонам. В июне 2018 года они продемонстрировали нейросеть с психопатологическими наклонностями, названную в честь персонажа Нормана Бейтса, убийцы с раздвоением личности из романа «Психо». Разумеется, исключительно в научных целях.