Почему больше разработчиков не означает меньше работы

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

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

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

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

Как проверка паспорта затрагивает обработку заявки

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

Допустим, сначала внешний сервис принимает только номер паспорта. Затем команда переходит на другой сервис, которому нужны ещё ФИО и код подразделения. Меняются состав запроса, протокол взаимодействия и формат ответа. При этом условия прохождения заявки остаются прежними. Если вызов провайдера и разбор его ответа находятся прямо в коде обработки заявки, менять придётся этот код. В одном месте оказались две причины для изменений: новые бизнес-правила и новый способ получения данных.

Из-за этого задача по замене интеграции затрагивает сценарий целиком. Чтобы ограничить объём правок, нужно отделить получение результата проверки от решения о том, что делать с заявкой.

Как отделить бизнес-правила от технических деталей

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

В модели чистой архитектуры выделяют четыре области:

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

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

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

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

Что останется прежним при смене провайдера

Вернёмся к паспорту. Адаптер получает необходимые данные, собирает запрос к внешнему сервису и преобразует ответ в результат, с которым работает приложение. В нашем примере это те же два признака: паспорт действителен, человек отсутствует в нежелательных списках.

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

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

С базой данных действует тот же принцип. Сценарий обращается к интерфейсу репозитория, а конкретная реализация работает с БД через SQL, ORM или собственный модуль доступа к данным. При переходе с PostgreSQL на Oracle это помогает сохранить код бизнес-правил, если их удалось отделить от особенностей конкретной БД.

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

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

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

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

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

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

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

Как сохранить границы, когда фича нужна вчера

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

В разборе есть три способа, рассказывающие, как с этим работать.

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

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

С чего начать в существующем проекте

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

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

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

«А если сотрудник из региональной поддержки спросит этого бота про зарплаты топ-менеджмента — что произойдёт?»

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

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

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

Контур 1. Доступы: чат-бот — это еще один источник утечки данных

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

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

Рабочие паттерны здесь давно известны из мира дата-инжиниринга, просто их надо перенести в LLM-контур:

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

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

Контур 2. Качество: как понять, что модель не «в целом хорошо отвечает», а действительно работает

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

Отсюда вырастает необходимость в “evals” — наборе тестовых вопросов с эталонными или хотя бы допустимыми ответами, который прогоняется при каждом изменении промпта, смене модели или обновлении базы знаний. Без этого набора любое «мы обновили промпт» — это эксперимент вслепую поверх продакшена.

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

• обязательное отображение источников в ответе — пользователь должен иметь возможность провалиться в документ и проверить;
• метрика заземления (grounding) — насколько ответ действительно опирается на найденный контекст, а не на веса модели;
• регулярная выборочная проверка ответов людьми, желательно из той же предметной области, что и пользователи.

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

Контур 3. Эксплуатация: то, что не видно на демо-стенде

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

Технически это означает необходимость закладывать:

• fallback-модели — если основной провайдер отвечает с задержкой или недоступен, запрос должен уйти на резервную модель, пусть и менее мощную, а не зависнуть;
• очереди и скорости запросов на уровне пользователя и команды, чтобы один активный отдел не съел весь бюджет задержек у остальных;
• мониторинг не только «жив ли сервис», но и задержка по перцентилям, долю ошибок генерации, долю отказов поиска;
• отдельное наблюдение за GPU-утилизацией, если часть моделей развернута локально, а не через внешний API.

Это тот слой, где выигрыш от готовой платформы обычно максимален: наблюдаемость, лимиты, инфраструктура и SLA закрываются AIaaS‑решением, таким как платформа ITGLOBAL.COM , куда быстрее, чем командой, которая строит это с нуля. Но метрики продукта — что считать приемлемой задержкой именно для этого сценария использования, какие тестовые кейсы прогонять при инцидентах — всё равно остаются на стороне команды, потому что это вопрос не инфраструктуры, а бизнес-требований.

Контур 4. Стоимость: токены как новая облачная статья расходов

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

Что реально работает на практике:

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

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

Контур 5. Ответственность: кто отвечает, если агент сделал что-то не то

Отдельный контур, который на демо вообще не обсуждается, — это ответственность за действие. Пока LLM просто отвечает на вопросы, риск ограничен качеством текста. Но как только появляется агент, который может, например, создать тикет, отправить письмо или изменить запись в CRM, вопрос смещается с «что ответила модель» на «что модель сделала».

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

Что делать самим, а что можно отдать платформе

Важная оговорка: этот список работает только применительно к реальному составу конкретного AIaaS-решения. Если в нём нет встроенного RBAC, нет мониторинга или нет managed RAG — не стоит проектировать архитектуру так, будто эти возможности уже есть. Разрыв между ожидаемым и фактическим набором функций платформы — ещё один способ провалить продакшен так же надёжно, как отсутствие проектирования вообще.

Вместо вывода

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

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

Реклама. ООО «Итглобалком Рус» ИНН 7838413489, erid: 2W5zFJ34gQR

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

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

История 1. Осьминог на кредитном комитете: как мы искали продуктовые идеи с помощью МФО

Полгода назад, подводя итоги 2025 года и формируя цели на 2026‑й, я поставила перед собой задачу разработать продуктовую стратегию — долгосрочный вектор, который можно перевести в конкретные решения для клиентов и бизнеса. В скором времени был и вижен, и стратегия. Но, скорее всего вы знаете, что продуктовая стратегия отвечает на вопрос «Куда мы идём». Также, скорее всего, вы знаете, что она не объясняет, какие именно продукты, сервисы и процессы должны привести нас к этой цели.

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

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

Но если вам уже надоело просто «допиливать» существующие продукты и хочется выбить команду из шаблонного мышления, попробуйте не обычный брейншторм, а метод фокальных объектов (МФО). Это метод генерации новых идей через перенос свойств случайных объектов на объект, который требуется усовершенствовать.

Фокальным он называется потому, что именно на исходном объекте сосредоточен весь перенос признаков. В МФО тренируется дивергентное мышление — расширение пространства вариантов. На этом этапе важны количество, разнообразие и неожиданные связи.

Метод состоит из нескольких последовательных действий:

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

Ключевой момент — случайные объекты не являются готовыми аналогами продукта. Они нужны как источник непривычных свойств.

Давайте покажу на примере.

Сформулировать кейс

МФО лучше начинать с чёткого описания задачи. Если этого не сделать, обсуждение быстро станет слишком абстрактным. В нашем случае фокальным объектом был процесс получения, использования и сопровождения оборотного финансирования для корпоративных клиентов.

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

Это уже достаточно конкретная задача и задаёт направление поиска.

Дальше задали контекст клиента. К примеру, у нас это была производственная компанию со следующими особенностями:

1. Выручка зависит от сезонности.
2. Закупки сырья нужно финансировать заранее.
3. Отгрузки клиентам происходят с отсрочкой платежа.
4. Часть оборотного капитала заморожена в запасах.
5. Потребность в деньгах меняется в течение года
6. Финансовый директор не всегда понимает, какой объём лимита будет доступен через месяц.
7. Важно своевременно информировать банк об изменениях в бизнесе и не допускать ухудшения качества портфеля.

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

Чтобы идеи не остались разговором, заранее определили, какой результат считаем полезным:

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

Как проходила сессия

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

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

На первом этапе мы не связываем объект с кредитованием. Просто описываем, как он устроен и как себя ведёт:

• У него несколько щупалец.
• Щупальца могут действовать параллельно.
• Часть нервной системы распределена по телу.
• Он быстро адаптируется к среде.
• Меняет цвет и фактуру.
• Исследует пространство через прикосновение.
• Умеет прятаться
• При угрозе выпускает чернила и меняет сценарий поведения.

Важно не ограничиваться очевидными прилагательными вроде «морской» или «мягкий». Для МФО полезнее свойства, функции и механики:

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

Теперь начинаем переносить признаки на фокальный объект

На оборотное финансирование в нашем случае. У корпоративного клиента редко бывает только одна потребность в ликвидности. Одновременно ему могут требоваться деньги на:

• закупку сырья;
• финансирование запасов;
• исполнение контракта;
• выплату заработной платы;
• закрытие кассового разрыва;
• …
• валютные платежи.

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

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

• закупочный подлимит;
• контрактный подлимит;
• сезонный подлимит;
• лимит на краткосрочные кассовые разрывы;
• отдельный лимит на гарантии или аккредитивы.

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

Примечание. Все свойства рассматривать нет смысла, остановимся на одном.

Как из ассоциации получить проверяемую гипотезу

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

• Какое свойство мы перенесли?
• Как оно могло бы проявляться в продукте?
• Для какого клиента это имеет ценность?
• Какую проблему клиента решает?
• Какие данные или события запускают новый сценарий?
• Что меняется в процессе?
• Какие риски появляются?
• Как проверить идею на небольшом пилоте?

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

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

Так случайная ассоциация превращается в объект продуктовой проверки.

Как провести такую сессию у себя

До встречи нужно подготовить:

• описание фокального объекта;
• цель изменений;
• краткое описание клиента и его проблемы;
• список ограничений;
• критерии оценки;
• способ фиксации идей;
• фасилитатора.

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

Этап генерации (45–60 минут):

• представить кейс и объяснить правила;
• выбрать 3–5 случайных объектов;
• выписать свойства каждого объекта;
• переносить свойства на фокальный объект;
• фиксировать все идеи без критики;
• развивать идеи уточняющими вопросами.

Фасилитатору важно останавливать фразы вроде «Это невозможно» и «Так никто не делает». Вместо этого можно спросить:

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

Этап отбора. После завершения генерации команда возвращается к конвергентному мышлению. Идеи можно оценить по пяти критериям (клиентская ценность, экономика, риск, право/комплаенс, реализуемость).

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

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

Важно. Не любая странная ассоциация превращается в хорошую бизнес‑идею. Здесь дело в другом: МФО временно снимает ограничения с этапа генерации, чтобы команда получила более широкий набор вариантов, затем ограничения возвращаются в работу, а идея проверяется на клиентскую ценность, экономику, риск, право, данные, ИТ и операционную модель.

Ограничения метода

У метода есть несколько ограничений.

• Во‑первых, МФО плохо работает, если кейс сформулирован слишком широко. «Как улучшить корпоративное кредитование?» — плохая постановка. «Как сократить неопределённость клиента при использовании возобновляемого лимита?» — значительно лучше.
• Во‑вторых, случайные объекты должны действительно быть случайными. Если команда заранее выбирает только «полезные» или технологичные предметы, метод быстро превращается в обычную аналогию.
• В‑третьих, нельзя смешивать генерацию и оценку. Если специалист по рискам начинает комментировать каждую идею в момент её появления, команда снова возвращается в конвергентный режим.
• В‑четвёртых, итогом должны быть не просто необычные сочетания, а проверяемые гипотезы. Иначе сессия останется хорошим упражнением на воображение.

Метод фокальных объектов — это не замена рискам и аналитике, а способ отключить внутренний стоп-кран ещё до того, как идея родится. В корпоративном кредитовании мы привыкли сразу искать ограничения, из-за чего часто просто «допиливаем» существующие продукты. Необычные метафоры вроде “осьминога” помогают выскочить из этой колеи и задать неудобные вопросы: “а что, если делать лимиты гибкими”, “ловить сигналы бизнеса раньше отчётности” и уйти от крайностей «всё доступно или всё заблокировано»? Смысл МФО в том, чтобы сначала выбить команду из шаблонного мышления и веером нагенерировать смелых решений, и только потом прогнать их через суровый фильтр корпоративной реальности.

Бонус‑кейсы с воркшопов: идеи, которые «созревали» вместе с рынком

Снятие налички на кассе магазинов

В своё время, на подобных воркшопах ещё в 2018 году, мы нагенерировали мысль, что можно было бы снимать деньги с карты на кассах магазинов. Тогда эта идея в прод не пошла, но уже в 2026‑м это рабочий способ получить наличку. Но некоторые идеи «созревают» вместе с рынком и инфраструктурой. Задача продакта — не убивать их сразу, а фиксировать и возвращаться, когда контекст изменится.

Досрочное погашение и онбординг в проблемных точках

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

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

История 2. Как сделать CJM, когда оно стоит как крыло от самолёта

Хватит про осьминогов, давайте ближе к привычному — к CJM.

Когда мы начали писать стратегию на будущий год (из предыдущей истории), я подумала: а что, если посмотреть на сервис не как на набор экранов и виджетов, а как на отпечаток какого‑то этапа пользовательского пути и построить CJM: с чем пришёл, зачем и что делает потом.

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

В нашем случае сервис участвует в нескольких этапах жизненного цикла корпоративного кредита:

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

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

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

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

Но наша аудитория — крупный корпоративный бизнес. В реальности это квест уровня «хард»: надо попробовать найти ЛПР какой‑нибудь авиакомпании, пробить стену службы безопасности, а потом, обойдя переносы и отмены, добраться до кабинета с табличкой «Оставь надежду, всяк сюда входящий». И вот твоё исследование умерло, так и не начавшись (но не попало в ад, потому что оно уже там).

А гипотезы и понимание направления развития продукта нужны были команде уже вчера.

Как собрать настоящий путь от триггера до результата, если твоя ЦА — крупный корп?

Ответ: бюджетно.

Однажды я подготовила фрейм в Miro, где накидала сценарии, которые пользователи могут проходить в процессе корпоративного кредитования, внезапно и без объявления собрала 20 человек из команд разработки (свою и смежную) — разработчиков, аналитиков, дизайнеров, — и разбила на группы, раздала этапы и отдала на разграбление два swimlane:

• триггеры и мотивы: какую задачу юзер на самом деле пытается решить?
• действия: что он делает фактически и где страдает от ручного труда?

Этапы кредитного процесса у юрлиц разбиваются на крупные блоки:

• осознание потребности;
• подача заявки, выбор банка для подачи заявки;
• сам старт заявки;
• заключение договора и так далее.

Каждой группе досталась часть этого этапа. Задача групп: заполнить этап по шаблону (триггер, цель, действия, инструменты, touchpoints).

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

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

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

А потом в этой пьесе появился CFO. И ему не нужен экран, перегруженный деталями каждого транша и всеми графиками погашения, ему нужно понять, может ли компания позволить себе эту сделку и не упрётся ли в ограничения лимита?

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

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

В итоге выросла солидная простыня, которая начинается от осознавания потребности и заканчивается закрытием кредита.

В процессе вылезли такие глубокие мотивы, о которых даже я — РО с 20-летним бэкграундом в финтехе — не подумала бы с ходу.

Главный эффект воркшопа

Но главный эффект воркшопа был в другом: мы увидели, насколько по‑разному внутри команды понимаем путь клиента.

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

Два часа воркшопа, на котором я «заставила» команду разработки представить себя на месте клиента — и у нас родилось десяток гипотез. Да, это пока не доказанные факты, а наши коллективные галлюцинации. Но теперь с этим объёмным, живым «монстриком» можно идти валидироваться об реальную ЦА, аналитику и саппорт.

А главный инсайт в том, что мы как раз определяем, что наш сервис далеко не везде достаёт клиента. Это раз. Второе — у клиента могут быть в одном этапе совершенно две разные роли. Например, тот же ЛПР, у которого набор информации для принятия решения отличается от операционного сотрудника, которому нужно работать с операционной выборкой траншей.

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

Ограничения внутреннего воркшопа

Воркшоп нельзя рассматривать как замену реального интервью с клиентом, потому что это некорректно. У внутреннего воркшопа есть серьёзные ограничения:

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

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

Но до воркшопа на грумингах звучало «Давайте выведем на экран ещё один финансовый показатель», команда проектировала UI/UX из позиции «Смотрите, сколько у нас данных и что мы умеем», а за спиной тихо строилась фабрика фичей.

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

Сейчас у нас вопросы другие: «Какую задачу этот показатель решает? Для какой роли? На каком этапе? Что человек сделает с ним дальше?»

И, пожалуй, в этом главный смысл карты гипотез. Она не создаёт иллюзию знания, она показывает, где именно знаний пока не хватает.

Иногда первый полезный шаг в UX‑исследовании — не бежать сломя голову «в поля», а честно зафиксировать, что именно ваша команда думает о пользователе прямо сейчас. А потом пойти и проверить это на реальных клиентах. Но это уже совсем другая история.

История 3. Как метрика Time to Interactive помогла победить «призрачный» негатив клиентов

Любой крупный финтех — это баланс между идеальной архитектурой и скоростью Time‑to‑Market. Когда‑то давно для запуска сервиса был сделан базовый заявочный процесс:

• клиент оформляет заявку в интерфейсе;
• заявка последовательно проходит через 4 банковские системы;
• на выходе она либо исполняется автоматически, либо попадает на ручную регистрацию сотруднику бэк‑офиса.

Главный нюанс: единой мастер‑системы со сквозной статусной моделью у процесса не было.

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

Последствиями были пачки негативных отзывов от пользователей, которые приносила поддержка, с одной и той же формулировкой — «Ничего не работает!». Если открыть логи, то видно, что заявки уходят, четыре банковские системы по цепочке успешно их обрабатывают, а операции исполняются. По договору у банка есть 2 дня на обработку (SLA), и система железобетонно укладывается в этот срок. Backend‑инженеры рапортуют, что всё штатно.

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

Как мы сместили фокус с серверных метрик на пользовательский опыт

Мы решили это проверить и сместили фокус с серверных метрик на пользовательский опыт и измерили Time to Interactive (TTI) — но не в классическом смысле общей готовности страницы, а точечно: разницу между моментом отрисовки страницы и моментом отрисовки нужного нам элемента — главной целевой кнопки. То есть не «когда страница в целом стала интерактивной», а конкретно «когда стала кликабельна кнопка, которая ведёт клиента дальше по сценарию».

Результаты замеров — это шок‑контент. Уберите от экранов детей, стажёров и джунов: средний TTI кнопки составлял 18 секунд.

Один час на планете Миллер равен семи годам на Земле. А 18 секунд ожидания кнопки в финтехе — это вечность для нервной системы клиента. За это время человек успевает сделать три глотка кофе, подумать, что страница «зависла» или сайт «сломался», яростно покликать по неактивной кнопке, закрыть вкладку и уйти писать разгневанный отзыв.

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

Что мы нашли в цепочке инициализации

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

Пока этот тяжёлый расчёт не завершался, фронтенд не активировал ключевое действие.

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

Выводы

Не верьте только бэкенд‑логам. Если по метрикам сервера всё «зелёное», это не значит, что пользователь счастлив. Негатив может формироваться на этапе ожидания UI.

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

Отсутствие сквозной статусной модели — не приговор. Даже если у вас нет бюджета на пересборку архитектуры и мастер‑систему статусов, оптимизация первичного взаимодействия (TTI) позволяет закрыть боль клиентов без миллионных инвестиций в бэкенд.

Заключение: что остаётся после таких историй

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

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

Если после этой статьи вы хотя бы раз спросите...:

• «А какую проблему это решает?»
• «Для какой роли?»
• «На каком этапе?»
• «Что человек сделает с этим дальше?» —

…значит, эти истории уже сработали.

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

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

Неожиданный путь к цели: от C к C++ — и обратно

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

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

За несколько лет он стал хорошо известен в C++-сообществе: писал статьи, выступал с докладами, модерировал дискуссии на митапах, а со временем вошёл в программный комитет одной из главных конференций сообщества.

Но на C++ история не закончилась. Спустя несколько лет в компании появилась возможность поработать и с C, которой Илья и воспользовался. Он перешёл в команду, которая занимается разработкой операционной системы для коммутаторов KORNFELD. Так следующим шагом его карьеры стало новое направление — и одновременно возвращение к давнему интересу. При этом C++ из его жизни уже никуда не исчез: Илья остаётся частью профессионального комьюнити и активно участвует в формировании программы конференции C++ Russia.

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

От статьи — к работе, о которой мечтал

Тохир занимался робототехникой, но всегда мечтал создавать компьютеры и серверы. Однажды на Хабре он увидел статью инженеров YADRO о том, чем они занимаются. Это была как раз та область, которая давно его интересовала. Статья вдохновила Тохира откликнуться на вакансию компании, и спустя некоторое время он и сам стал частью команды YADRO.

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

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

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

Использовала прошлый опыт, чтобы построить направление с нуля

До YADRO Елена много лет работала в Nokia в направлении телеком. В 2022 году компания закрыла R&D-центр в Санкт-Петербурге, и большая часть команды, в которой работала Елена, перешла в YADRO.

Здесь опыт Елены и её коллег пригодился уже в новых условиях. Телеком-направление в YADRO тогда только появлялось, поэтому многое предстояло выстраивать практически с нуля. Но команда уже проходила этот путь и понимала, где могут возникнуть сложности и что теперь можно сделать иначе.

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

Так накопленный опыт стал отправной точкой для новых задач и вызовов.

После 18 лет в одной экосистеме — к новым продуктам и технологиям

До YADRO Василий 18 лет проработал в IBM. Начинал инженером по серверным платформам x86, а со временем стал руководителем сервисного департамента в России и странах СНГ.

В 2022 году IBM ушла из России, а установленное у заказчиков оборудование продолжало работать и требовало поддержки. Василий вместе с командой из 20 инженеров перешёл в YADRO. Так удалось сохранить накопленную за годы экспертизу и продолжить поддерживать заказчиков уже в новых условиях.

В YADRO профессиональный маршрут команды продолжился уже с более широким набором продуктов и технологий. К накопленному опыту добавилась работа прежде всего с собственными решениями компании — например, системами хранения данных TATLIN.FLEX и коммутаторами KORNFELD, — а также с оборудованием других производителей. Для инженеров это возможность расти горизонтально, развиваться в разных технологических областях и осваивать новые продукты и технологии.

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

От самостоятельной работы — к руководству командой

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

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

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

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

У каждого свой путь

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

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

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

Реклама. Рекламодатель: ООО «КНС ГРУПП» ИНН 7701411241, erid: 2W5zFGzXHYV

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

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

Эту проблематику подробно разбирали на OFFZONE — конференции по практической кибербезопасности, которая прошла в Москве 20–21 августа. Среди тем докладов — применение ИИ для поиска уязвимостей и анализа результатов, автоматизация задач специалистов и новые риски, которые возникают вместе с этими возможностями. Два выступления особенно точно продолжили разговор о том, что происходит, когда в цепочку поиска и проверки уязвимостей всё активнее включается AI. Мы попросили их авторов подробнее прокомментировать эту тему.

Дмитрий Абрамов занимается уязвимостями, которые приносит генеративный код: что именно ломается, когда код пишет агент. Юрий Туманов отвечает за вторую половину задачи — за разбор находок. Он строит на локальных языковых моделях триаж сработок SAST: статический анализатор просматривает код и выдаёт список подозрительных мест (это и есть сработки), а триаж — разбор этого списка на настоящие уязвимости и ложные срабатывания.

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

Находок стало больше. Но не только из-за уязвимостей

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

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

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

То есть часть роста — это не новая опасность, а новая видимость. Строк стало больше, потому что их стали быстрее писать. Правила сканеров перестроили. Подключили инструменты, которые раньше в эти места не смотрели.

Но команде, которая разбирает эту очередь, от такого объяснения не легче: откуда бы ни взялся рост, вручную столько находок всё равно не обработать. И дело не только в количестве — изменилось ещё и то, как эти находки приходят.

Три механизма, из-за которых дефекты идут пачками

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

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

«Агент применяет один шаблон ко всем похожим местам — если шаблон дефектный, дефект тиражируется».

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

Третий механизм Дмитрий Абрамов называет самым коварным:

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

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

Что ушло, что пришло

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

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

Причину он называет одну:

«Но все эти ошибки чаще всего проскакивают из-за недостаточности контекста, передаваемого агенту».

Часть проблем лечится буквально этим. Заголовки и CSRF в его команде почти исчезли после того, как добавили то, что они назвали «ИБ-контекстом». Модель не отказывалась делать безопасно — ей просто не сказали, что от неё этого ждут.

А вот ролевая модель и бизнес-логика контекстом не лечатся. Здесь нужны ручные проверки или специфичные автотесты, а значит, снова человеческое время.

Кстати, он поправил саму постановку вопроса про слепые зоны:

«Слепыми называть неправильно, скорее было бы правильно — невнимательные».

Разница есть. Слепая зона — то, чего инструмент не видит в принципе. Невнимательность — то, что исправляется правильно поставленной задачей.

Ошибки не в коде, а в поведении агента

Есть категория проблем, которая не попадёт ни в один SAST, потому что это вообще не про код.

«Лишний вызов инструмента, преждевременное завершение задачи, „починил“ тест вместо кода, сфабрикованный отчёт о прогоне — как у Replit. Это не свойство кода, это свойство процесса, и статические анализаторы к нему не приспособлены по определению».

Эта мысль пригодится дальше. Модель, которая уверенно рапортует об успехе, — проблема не только на стороне написания кода, но и на стороне его проверки.

Разбирать некому. Ставим на разбор модель

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

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

«Спросить можно, и ответ придёт мгновенно — складный, развёрнутый, уверенный».

У него в докладе есть слайд, который так и называется: «Складно ≠ доказано».

Почему прямой вопрос не работает

Причин три.

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

«Само-оценка модели без внешней калибровки театральна, опираться на неё нельзя».

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

«Универсальная рамка „найди источник и сток“ на дефектах-„свойствах“ хоронит реальное: на одном моём замере неудачная постановка вопроса похоронила 140 реальных сработок из 363».

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

Здесь стоит остановиться. У Дмитрия дефект проскакивает, потому что агенту недодали контекста. У Юрия модель хоронит реальную сработку, потому что ей задали не тот вопрос и не показали нужный кусок кода. В обоих случаях дело не в модели.

Модель предполагает, правила решают

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

Второе — сработки разделены на два сорта, и доказываются они по-разному.

Уязвимость-свойство. Опасен сам факт в коде: пароль в исходниках, слабый хеш, слишком открытые права. Вопрос ровно один — настоящий секрет или заглушка. Никакого пути данных здесь нет и быть не должно. Таких сработок в потоке подавляющее большинство, около 93%.

Для них выстроена лестница проверок, и модель на ней — лишь одна из ступеней. Сначала работает алгоритмика без всякой LLM: ключ в формате боевого AWS — сразу подтверждаем, файл сгенерированный или из SBOM — сразу ложное срабатывание. Это снимает больше половины шума и не стоит ни одного обращения к модели. Дальше вопрос уходит модели, но задаётся по сути факта. Потом больше сотни детерминированных правил проверяют её ответ и могут вердикт поправить. Потом пороги по классам: слабый ответ превращается в Unknown. Последняя ступень — человек. Отдельным правилом запрещена сама формулировка «не вижу пути атаки» как причина закрытия: именно на ней система и теряла те самые 140 сработок из 363.

Уязвимость-путь. Здесь опасен маршрут данных: SQL-инъекция, XSS, обход каталогов. Вопрос другой — дошли ли данные атакующего до опасного вызова и была ли по дороге защита. Вот для этого типа и сделан evidence gate.

Evidence gate: перечисли факты — вердикт выведется сам

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

И только потом вердикт вычисляется из этой таблицы механически. Список не пуст — уязвимость подтверждена. Пуст, и происхождение всех переменных известно — ложное срабатывание. Улики повреждены — Unknown, пусть смотрит человек. Переопределять этот результат собственной интуицией модели прямо запрещено.

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

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

«Придумать вывод легко, придумать проверяемую улику сложно. <…> Фактам — да, поэзии — ни-ни».

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

И снова всё упирается в контекст. Чаще всего система отвечает «недостаточно данных» по одной причине: трасса слишком короткая. Модель видит место, где переменная попадает в опасный вызов, но не видит, откуда эта переменная пришла и проверяли ли её по дороге. Лечится это не увеличением окна и не моделью побольше, а доставкой недостающего кода. Юрий пробовал 72B через внутренний портал и получил обратный результат:

«Дисциплина важнее размера».

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

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

Почему локально

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

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

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

Со стоимостью тоже всё сходится: одна игровая RTX 4080 разбирает около восьми тысяч сработок в сутки за электричество.

История про токен

Самая показательная часть доклада— не про метрики.

«Боевой GitLab-токен, модель с уверенностью 1.0 обозвала его „placeholder in test configuration“ — заглушкой в тестовом конфиге, — поверила пути файла и похоронила. Реальный секрет, закрытый автоматом».

Доверие команды после такого падает мгновенно:

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

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

«Доверие к автомату устроено как доверие к коллеге: ошибаться можно, прятать ошибки нельзя. Система, которая сама показывает промахи и после каждого меняется, доверие возвращает. Система, которая уверенно бормочет „всё хорошо“, теряет его навсегда».

Где проходит граница

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

Дмитрий Абрамов:

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

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

Юрий Туманов отвечает про свою часть работы, но приходит к тому же. Автомат работает там, где улика видна прямо по артефакту, а полноту можно проверить канарейками. Цепочечные классы — SQL-инъекции, XSS, path traversal, всё, где нужно доказать путь данных через приложение, — идут к человеку: именно там небольшие модели выдают уверенные галлюцинации, а уверенный неверный вердикт обходится дороже, чем честный ответ «недостаточно данных». Необратимые действия без человека — ротация и отзыв секретов, блокировки, автопатчи с автомержем — тоже нет. И отдельно:

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

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

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

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

Как выбрать цифровую платформу для ведения ИТ-проектов и по каким критериям оценивать системы? На какие решения стоит обратить внимание в 2026 году? В статье разберем функциональность 5 популярных ИСУП и подсветим плюсы и минусы каждого ПО.

В чем особенность ИТ-проектов

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

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

И все же ряд особенностей у ИТ-проектов есть:

1. В основе реализации лежат Agile-подходы. Классические методы задают рамку (сроки, бюджет, контроль), но реальная работа строится через гибкие практики: внутри почти всегда используются спринты, бэклог, инкременты.

2. Итерационная поставка ценности. Управление строится не только вокруг соблюдения плана: результат создается не в конце проекта, а через регулярные релизы.

3. Работа в цифровой среде. Команда (разработчики, аналитики, тестировщики) используют информационные системы: таск-трекеры, репозитории, CI/CD. Проект «живет» в инструментах, а не в отчетах.

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

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

Какой должна быть система для управления ИТ-проектами

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

1. Поддержка гибридных подходов (Agile + Waterfall). Руководитель работает с этапами, сроками, бюджетом, исполнители — с досками, бэклогами и спринтами.

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

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

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

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

Из технологических критериев стоит обратить внимание на:

• полную импортонезависимость — чтобы вовремя получать обновления даже при кастомизации системы;

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

• масштабируемость — чтобы система могла расширяться вместе с ростом количества проектов или их сложности;

• безопасность — чтобы защитить данные и управлять правами доступа пользователей;

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

Обзор популярных российских сервисов для управления ИТ-проектами

Directum Projects — платформенное решение для управления проектами, бизнес-процессами, командами, документами, задачами и знаниями

Система полностью импортонезависима и безопасна: разработана в России и включена в реестр отечественного ПО (№4499), доступно размещение в «облаке» и на сервере предприятия.

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

• проектные инициативы и портфель: можно формировать пул идей, оценивать их и отсеивать неэффективные еще до старта. Это помогает не перегружать команды лишними проектами и концентрироваться на приоритетных задачах;

• бэклоги и задачи: приоритизация, декомпозиция задач, гибкие доски, свимлайны, WIP-ограничения. Команда получает понятные инструменты для работы и коммуницирует в системе, а не в сторонних сервисах;

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

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

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

Система совместима с отечественным и свободно распространяемым ПО. Благодаря сервисам интеграции можно объединить любые инструменты, используемые в компании, в единую экосистему. Настроить Directum Projects под требования бизнеса поможет разработка без кода или с низким его содержанием (no-low-code).

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

Цена: от 8190 рублей в год за человека.

SimpleOne SDLC — специализированная система для управления полным циклом разработки ПО: от идеи до выпуска продукта

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

Доступны:

• управление разработкой: диаграмма Ганта, гибкие методологии, ИИ-анализ кода;

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

• планирование и учет трудозатрат;

• библиотека документации: связь файлов с задачами и услугами;

• аналитика: кастомные формы отчетов, Agile-метрики;

• управление продуктом: иерархия, построение любой структуры.

Система совместима с Gitlab, имеет открытый интерфейс обмена данными (API) и возможности для гибкой кастомизации без привлечения вендора.

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

Из минусов — отсутствие сквозного поиска данных, перегруженный интерфейс и сложность координации.

Цена: по запросу.

EvaProject — отечественная система управления проектами и командами

Аналог Jira, включен в реестр российского программного обеспечения. Доступна облачная и локальная поставка.

Система дает возможность управлять:

• жизненным циклом разработки и задачами от постановки до релиза;

• бэклогом и спринтами: есть приоритизация и контроль выполнения;

• релизами и дорожной картой: можно спланировать этапы поставки и развития продукта;

• изменениями: фиксируются и контролируются все корректировки;

• импортом данных из зарубежных решений;

• прогрессом: в систему «заведены» информационные панели для мониторинга задач, загрузки и выполнения проекта.

Интегрировать EvaProject в корпоративную среду можно при помощи открытого интерфейса данных (API), также доступна кастомизация интерфейса, полей и процессов.

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

Цена: от 450 рублей в месяц за человека.

Яндекс Трекер — облачный сервис для управления проектами

Сервис входит в экосистему Яндекс 360: можно «подтягивать» почту, синхронизировать встречи с календарем и ставить задачи из писем. Включен в реестр отечественного ПО.

Ключевые возможности:

• организация совместной работы: можно объединять разные команды в одном проекте;

• учет ресурсов: у пользователей есть возможность заранее спрогнозировать трудоемкость;

• классика и гибкость: доступны доски и диаграмма Ганта;

• шаблоны проектов и автоматизация рутинных действий: создание чек-листов, рассылка сообщений и пр.;

• отдельные рабочие пространства для участников проектов.

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

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

Цена: от 399 рублей в месяц за человека.

Timetta — отечественная ИСУП, ориентированная на контроль ресурсов и экономику проектов

Программа подходит для компаний с проектной моделью бизнеса (интеграторы, консалтинг, ИТ-подразделения). Доступна в облаке и локальной поставке (on-premise).

Функциональность и особенности:

• фокус на экономике проектов, учет трудозатрат, расчет себестоимости и маржинальности;

• контроль загрузки команды, благодаря чему видно, кто перегружен, а кто только делает вид, что работает;

• связка плана и факта: есть возможность сравнить запланированные и реальные трудозатраты;

• управление портфелем через ресурсы и деньги, приоритизация с учетом загрузки и финансового эффекта;

• понятная аналитика, отчеты по эффективности проектов и использованию ресурсов в разных разрезах.

Можно адаптировать систему под потребности компании.

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

Цена: от 1105 рублей в месяц за лицензию.

Основные функциональные критерии отечественных ИСУП

Итог

Какую систему управления ИТ-проектами выбрать, решать вам. Оцените уже сформировавшиеся в компании бизнес-процессы, проанализируйте рынок и функциональность представленных ИТ-решений, посчитайте пользователей, примерьте инструменты к своим задачам, проведите пилотный проект и проанализируйте, куда и в каких масштабах будет расти бизнес в ближайшие 5 лет. Так вы получите ИСУП, которая будет максимально соответствовать вашим запросам.

Последние два года команда VK собирает такие задачи на общем технологическом фундаменте. В него входят внутренняя платформа разработки, облачная инфраструктура One-cloud, технологии видеоплатформы и единая система работы с данными и экспериментами. Команды получают готовые платформенные решения и могут тратить больше времени на задачи продукта.

Платформа для новых сервисов

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

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

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

Для типовых задач действует self-service. Команда самостоятельно проводит изменение от кода до продакшена и следит за его работой. Платформа запускает проверки, создаёт изолированную тестовую среду и помогает постепенно включать новую логику с помощью фича-флагов.

С помощью новой платформы ВКонтакте создала более 300 новых сервисов, а в 2026 году решение масштабировали на другие продукты VK. Платформа поддерживает Go, Java и Python, а в её контуре зарегистрированы тысячи сервисов, работающих во внутреннем облаке.

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

Как VK объединила инфраструктуру разных продуктов

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

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

One-cloud не проектировали сразу для всей компании. Платформа выросла из инфраструктуры Одноклассников, а следующим крупным этапом стала миграция Дзена. Затем к ней подключились ВКонтакте, VK Видео, MAX и другие сервисы. Сейчас платформа объединяет около десятков тысяч серверов, миллионы процессорных ядер и более 2 ЭБ данных. Продукты получают мощности из общего пула по мере роста нагрузки.

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

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

Как один видеоконвейер работает для разных продуктов

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

У видеоплатформы есть два основных сценария: загрузка ролика автором и его просмотр зрителем. Когда автор публикует видео, система принимает файл, присваивает ему идентификатор и отправляет на транскодирование — подготовку версий в разных разрешениях и форматах. Для этого платформа использует три кодека. H.264 поддерживает большинство устройств. VP9 сильнее сжимает видео, но требует больше вычислительных ресурсов. AV1 обеспечивает самое эффективное сжатие, однако создаёт ещё более высокую нагрузку при обработке. Поэтому с его помощью кодируют популярные ролики: их смотрит много людей, а меньший битрейт позволяет сократить объём трафика при сохранении качества.

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

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

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

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

Команда VK AdBlogger хотела добавлять шопсы в истории ВКонтакте без ручной подготовки контента. Для истории нужен другой формат ролика и отдельная карточка с изображением и названием товара. VK AdBlogger публикует контент через API, поэтому обработку исходного видео, добавление карточки и создание истории объединили в единый процесс.

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

От локальной метрики к общему результату: как работает OneAB

После запуска нужно проверить, как изменение повлияло на пользователей и показатели продукта. В VK Видео пользовательский путь связывает главную, подписки, рекомендации и другие разделы. Изменение одного элемента может затронуть соседние, поэтому A/B-тест оценивают в контексте всего сервиса.

Для такого анализа VK развивает единую платформу данных: она объединяет хранилище, каталог данных, управление доступами и качеством, BI-системы и инструменты для A/B-тестов. Объём данных превышает 400 ПБ.

За A/B-тестирование отвечает OneAB. Раньше продукты по-разному распределяли аудиторию и считали результаты. Новый продукт объединил настройку теста, разделение пользователей и расчёт метрик. Система сравнивает поведение контрольной и тестовой групп.

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

Аудиторию распределяет отдельный сервис на Go. Активные тесты хранятся в оперативной памяти, а продукты обращаются к системе по gRPC или HTTP. Сервис обрабатывает около двух миллионов запросов в секунду и определяет группу меньше чем за миллисекунду.

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

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

Ежемесячно через OneAB проходит более тысячи A/B-тестов. Системой пользуются ВКонтакте, Одноклассники, VK Видео и другие продукты компании.

Что изменилось для инженерных команд

Общий технологический фундамент VK вырос из задач отдельных продуктов. Решения сначала проверяли на реальной нагрузке, а затем масштабировали на всю компанию. Единая платформа разработки помогает быстро выпустить сервис, One-cloud даёт ему инфраструктуру, видеоплатформа доставляет ролики, а OneAB оценивает эффект изменений.

ВКонтакте, Одноклассники, Дзен, VK Видео, MAX сохраняют собственные задачи и логику развития. Общими стали технологии, которые не определяют продуктовые решения, а помогают быстрее воплощать и проверять их.

Claude: ставка на самопроверку

24 июля Anthropic представила Claude Opus 5. Это уже четвёртая модель компании менее чем за два месяца после Sonnet 5, Fable 5 и Mythos 5. Opus 5 сохранил цену предшественника в API Anthropic: 5 долларов за миллион входных токенов и 25 долларов за миллион выходных. По данным разработчика, по агентному кодингу он приблизился к более дорогому Fable 5.

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

Если вы выбираете с оглядкой на бюджет, можно начать с Claude Sonnet 5. Эта модель рассчитана на повседневные задачи, где важен баланс качества, скорости и стоимости. В RouterAI модели доступны под идентификаторами anthropic/claude-opus-5 и anthropic/claude-sonnet-5.

GPT: новый флагман для длинных задач

GPT-6 Astra стал новым флагманом OpenAI для сложных задач с большим числом шагов, включая программную инженерию и работу с инструментами. GPT-6 Astra Pro использует ту же базовую модель с режимом reasoning.mode: pro, который выделяет больше вычислений на рассуждение.

GPT-5.6 Sol остаётся вариантом для агентного кодинга, ревью и работы в командной строке. Его имеет смысл сравнить с Astra на собственных задачах, особенно если стоимость важнее максимального качества. Актуальные идентификаторы в RouterAI: openai/gpt-6-astra, openai/gpt-6-astra-pro и openai/gpt-5.6-sol.

Gemini: большой контекст и быстрые циклы

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

Gemini 3.8 Flash рассчитан на быстрые агентные циклы, программную инженерию и задачи с несколькими этапами рассуждения. Pro подойдёт для сложного разбора, а Flash стоит проверить на рутинных правках, где важны скорость и цена. Идентификаторы моделей: google/gemini-3.1-pro-preview и google/gemini-3.8-flash.

DeepSeek: стоимость и контроль инфраструктуры

DeepSeek V4 Pro уступает ведущим моделям OpenAI, Anthropic и Google, которые работают только через облачные сервисы разработчиков. По оценке NIST, отставание от ведущих американских моделей составляет около восьми месяцев. При этом семейство DeepSeek даёт возможность запускать открытые модели на собственной инфраструктуре и снижать стоимость типовых задач. Для части сценариев этого более чем достаточно, так что потребность в самом дорогом флагмане отпадает.

DeepSeek можно подключать через клиенты, совместимые с форматом OpenAI. В RouterAI актуальная версия доступна под идентификатором deepseek/deepseek-v4-pro-0813. Перед самостоятельным развёртыванием проверьте лицензию выбранной версии, поскольку условия релизов могут отличаться.

Qwen: общие модели и отдельная линейка для кода

В августе Alibaba расширила семейство Qwen3.8. В него вошли крупные модели общего назначения и компактные версии, которые проще запускать на собственной инфраструктуре. У Qwen есть отдельная линейка Coder для работы с репозиториями, генерации кода и агентных сценариев.

Открытые модели Qwen3 распространяются по лицензии Apache 2.0, но условия конкретного релиза всё равно нужно проверять перед внедрением. В RouterAI на момент подготовки текста доступны Qwen3.8 Max 0902 с идентификатором qwen/qwen3.8-max-0902 и Qwen3 Coder 480B с идентификатором qwen/qwen3-coder.

Как выбрать модель

Единого победителя нет. Opus 5 подходит для сложных изменений, где важна самопроверка. Sonnet 5 и GPT-5.6 Sol можно рассматривать для повседневной работы с балансом цены и качества. GPT-6 Astra рассчитан на длинные многошаговые задачи. Gemini 3.1 Pro полезен при большом объёме кода и документации, а Gemini 3.8 Flash при быстрых агентных циклах. DeepSeek и Qwen стоит проверить, если вам важны открытые модели, контроль инфраструктуры или более низкая стоимость.

Перед выбором проведите короткий тест:

1. Дайте двум или трём моделям одинаковую задачу и одинаковый контекст.
2. Проверьте качество исправлений, тестов и итогового диффа.
3. Посчитайте стоимость завершённой задачи с учётом повторных запросов.
4. Убедитесь, что выбранная модель поддерживает нужные инструменты и формат ответа.
5. Ещё раз проверьте идентификатор, доступность и цену перед запуском в проде.

RouterAI предоставляет один API, совместимый с форматом OpenAI, и позволяет переключать модели через значение параметра model. Для работы используется один API-ключ. Сервис принимает оплату в рублях российской банковской картой или по счёту, а работает без VPN. Актуальные цены и доступность моделей нужно проверять в каталоге, поскольку эти данные меняются быстрее самой статьи.

Мы решили протестировать каталог нейросетевых моделей immers.cloud, чтобы проверить, как работает в нём Qwen3.6-27B на прикладном сценарии от начала до конца. Сначала прогнали модель на задачах для разработчиков в чате, затем вызвали её через API и подключили к тестовому ИИ-агенту с локальными инструментами. По ходу теста сравнили публичный и частный эндпоинты, запустили сгенерированный код, зафиксировали время, расходы и ошибки.

immers.cloud — облачный провайдер вычислений для ИИ: аренда GPU-серверов и готовых инференс-эндпоинтов с посекундной оплатой. Сервис строит инфраструктуру на иммерсионном охлаждении оборудования и позиционирует его как способ держать тарифы ниже рынка — в нашем тесте час конфигурации на двух RTX 4090 стоил 171,77 ₽, а весь сквозной прогон обошёлся в 192,97 ₽. Сервис подходит тем, кому нужен доступ к открытым моделям вроде Qwen без закупки железа: для разовых запусков и прототипов — публичный API, для постоянной нагрузки и изоляции — частный эндпоинт.

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

Прежде чем собирать такой цикл, мы проверили базовый слой: как одна и та же Qwen3.6-27B отвечает в публичном чате, работает через API и запускается в частном инстансе immers.cloud. Это позволяет не смешивать проблемы модели, интерфейса и инфраструктуры с ошибками собственного агентного кода.

Что именно мы проверяли

• интерфейс публичного чата Qwen3.6-27B, точное название модели и доступность настроек генерации;
• три задачи разной сложности: исправление факториала, анализ JSONL-логов и ревью скрипта переименования фотографий;
• публичный OpenAI-совместимый API через Python SDK;
• создание частного эндпоинта на двух RTX 4090 и прохождение всех этапов запуска;
• те же задачи на частной модели и работоспособность сгенерированного кода;
• ИИ-агента с двумя локальными инструментами: нативные вызовы через tool_calls, выполнение функций в Python и возврат результатов модели;
• запасной сценарий с JSON-диспетчером, а также обработку неверных аргументов, отсутствующих файлов и неизвестных инструментов;
• фактические расходы и прекращение тарификации после удаления частного инстанса.

Почему взяли Qwen3.6-27B

Для сравнения публичного и частного режима важно использовать одну и ту же модель. Иначе разница в качестве или скорости может быть связана с архитектурой и размером LLM, а не с вариантом размещения. Поэтому в обоих случаях мы выбрали Qwen3.6-27B в четырёхбитной AWQ-квантизации.

Проверяем публичный чат

Публичный чат открывается со страницы модели. В интерфейсе отображается название «Инференс Модели Qwen3.6-27B», поле промпта и кнопка отправки. Отдельных настроек температуры, длины ответа или переключателя thinking mode мы не увидели.

При этом модель выводила блок «Here's a thinking process» прямо внутри ответа. В JSON публичного API поле message.reasoning оставалось null: рассуждение приходило обычным текстом в message.content. Для будущего агента это важная деталь — такой блок нельзя автоматически считать отдельным структурированным каналом reasoning.

У использованного эндпоинта параметр reasoning_parser не был включён. Это заметнее в сценариях без агента, где текст рассуждения приходится разбирать вручную, тогда как агент справляется с таким ответом и без отдельного канала reasoning. Однако есть эндпоинты, где параметр доступен, например: Qwen/Qwen3.5-35B-A3B-GPTQ-Int4 и google/gemma-4-26B-A4B-it.

Три задачи для модели

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

При анализе логов программа прочитала requests.jsonl, пропустила невалидную строку с предупреждением в stderr и вернула ожидаемую статистику:

{"total": 6, "errors": 2, "average_latency_ms": 168.3, "p95_latency_ms": 400}

Мы запускали решение на штатном Python 3.9.6 в macOS, хотя в промпте требовали Python 3.11. Использованных возможностей стандартной библиотеки хватило, и четыре теста завершились за 0,001 секунды. Это подтверждает работоспособность конкретного ответа, но не заменяет проверку на заявленной версии Python и собственных данных проекта.

Почему ревью модели всё равно нужно перепроверять

Самая показательная часть теста — ревью скрипта: там модель ошиблась увереннее всего, хотя с факториалом справилась гладко. Модель уверенно назвала итог «готовым к merge», хотя в коде сохранились технические дефекты:

• смещения ASCII-значений EXIF разрешались относительно среза ExifIFD, хотя формат TIFF хранит их относительно начала TIFF-блока;
• проверка повторного запуска не распознавала уже переименованные файлы и могла добавлять дату к имени ещё раз;
• тест коллизий не создавал настоящую коллизию двух источников;
• последовательное переименование не было транзакционным: прерывание процесса могло оставить каталог в частично изменённом состоянии.

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

Подключаемся к публичному API

На странице Qwen3.6-27B доступны примеры для cURL, PowerShell и Python. Мы использовали Python-клиент OpenAI и поменяли только токен. Ключ передавали через переменную окружения, чтобы он не попадал в исходный файл и историю команд.

На macOS окружение и запуск выглядели так:

Запрос прошёл с openai 2.48.0. Первый запуск занял 6,5 секунды по time, повторный вывод полного JSON — 4,278 секунды. В ответе были указаны модель qwen3.6-27b, 26 входных и 197 выходных токенов. Thinking process снова находился в message.content, а поле reasoning было null.

Запускаем частный эндпоинт

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

• 2 × RTX 4090 по 24 ГБ;
• 16 vCPU и 64 ГБ RAM;
• SSD на 160 ГБ;
• контекст 262 144 токена;
• один инстанс и посекундная оплата;
• 171,77 ₽ в час по странице модели и тарифу сервиса.

Запуск: около десяти минут до AVAILABLE

Запуск начался в 10:13. Сначала кабинет показал создание виртуальной машины, затем остальные стадии подготовки. В 10:23 эндпоинт перешёл в AVAILABLE, а рядом появилась ссылка на чат. Навигация в кабинете оказалась понятной: модель, контекст, конфигурация, статус и API-адрес собраны на одной странице.

На частной модели мы повторили те же задания. Факториал и анализ логов снова дали рабочий результат; четыре теста прошли без исправлений. Субъективно частный вариант отвечал почти так же, как публичный. Показатели TPS в интерфейсе также были близкими, но прямое сравнение времени сложных ответов некорректно: модель генерировала тексты разной длины.

Для более глубокой оценки производительности эндпоинта имеет смысл зайти на виртуальную машину по SSH и запустить нагрузочный прогон vLLM:

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

Публичный и частный режимы: что показал тест

В наших запросах message.reasoning оставалось null. При создании частного эндпоинта параметр reasoning_parser не включался, поэтому этот результат нельзя трактовать как отсутствие поддержки отдельного структурированного канала reasoning. В протестированной конфигурации рассуждение возвращалось внутри message.content. Чтобы получить рассуждение в message.reasoning отдельно от основного ответа, нужно включить reasoning parser в настройках частного эндпоинта.

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

Сколько стоил тест

Начальный баланс в нашем кабинете составлял 10 000 ₽. После неудачного запуска, успешного развёртывания, трёх задач на частной модели и удаления эндпоинта осталось 9 807,03 ₽. Фактический расход всего теста — 192,97 ₽.

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

От модели к ИИ-агенту

Проверенный API уже можно использовать как модельный слой приложения. Но один вызов chat.completions ещё не делает программу агентом. Для агентного цикла нужны четыре компонента:

• модель — Qwen3.6-27B через OpenAI-совместимый API;
• реестр инструментов — функции с понятными именами, аргументами и JSON-схемами;
• контроллер — код, который принимает запрос модели, проверяет аргументы, вызывает разрешённую функцию и возвращает результат;
• политика безопасности — лимиты итераций, dry run для изменений, журналирование и подтверждение опасных действий.

Выбираем полезный сценарий

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

Адаптер Qwen, который уже проверен

Начнём с небольшого слоя, который изолирует адрес immers.cloud и имя модели от остального кода агента. Этот вариант использует тот же способ подключения, который прошёл наш API-тест:

Как будет работать агентный цикл

1. Пользователь просит проанализировать requests.jsonl и предложить действия.
2. Контроллер передаёт Qwen историю диалога и описания доступных инструментов.
3. Если модель возвращает tool_calls, контроллер проверяет имя функции и аргументы по схеме.
4. Локальная функция выполняется без участия модели; её JSON-результат добавляется в messages с ролью tool.
5. Qwen получает факты и формирует итоговый разбор. Цикл завершается при обычном ответе или по лимиту итераций.

Тестируем полный агентный цикл

Во втором этапе мы подключили Qwen3.6-27B с публичного эндпоинта immers.cloud к агенту разбора инцидентов. Целью было не получить ещё один текст от модели, а проверить всю цепочку: структурированный вызов функции, валидацию аргументов, выполнение локального кода, возврат результата в контекст и безопасное завершение.

Агент работал с теми же тестовыми данными requests.jsonl. Модель не читала файл напрямую и не считала перцентиль сама. Она могла вызвать только три функции из реестра: calculate_log_metrics, lookup_runbook и prepare_incident_report.

Как устроен контроллер

Мы передали описания функций в параметре tools и включили tool_choice="auto". Если Qwen возвращала структурированный tool_calls, контроллер проверял имя функции по белому списку, разбирал аргументы, валидировал их по JSON Schema и только затем выполнял локальный код. Результат возвращался модели сообщением с ролью tool.

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

Как воспроизвести запуск

Рядом с agent.py должен лежать файл requests.jsonl. Токен, как и в базовом API-тесте, передаётся через переменную окружения и не сохраняется в исходнике.

Первая версия прошла технически, но ошиблась по смыслу

В первом запуске нативный tool calling уже работал: API возвращал структурированные вызовы, имена функций и аргументы проходили схему, цикл дошёл до финального ответа. Но контракт calculate_log_metrics отдавал только агрегаты — число ошибок, среднюю задержку и p95. В нём не было фактических пар route + status для ошибочных записей.

Qwen заметила нехватку данных и прямо написала, что не знает, для каких маршрутов нужно искать runbook. Затем всё же начала подбирать варианты. Кроме реальных /api/orders + 500 и /api/orders + 503 она запросила несуществующие в логе пары /api/payments + 500 и /api/users + 500. Все вызовы были формально валидными, но два из них опирались на выдуманные факты.

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

Добавляем error_records и запрещаем догадки

Мы расширили ответ calculate_log_metrics полем error_records и сгруппировали в нём только реальные ошибки из файла. Для тестового набора функция вернула:

В системной инструкции закрепили ещё одно правило: пары для lookup_runbook можно брать только из error_records. После этой правки модель перестала угадывать маршруты. Количество итераций и структурированных вызовов сократилось с шести до четырёх. Суммарное время ожидания ответов API в одном прогоне снизилось с 66,76 до 20,81 секунды. Это наблюдение одного запуска, а не бенчмарк производительности.

Что вернул нативный режим

Исправленный цикл завершился за четыре итерации. На первой Qwen вызвала calculate_log_metrics. На второй вернула сразу два lookup_runbook в одном ответе — для кодов 500 и 503. На третьей собрала черновик через prepare_incident_report с apply=false. На четвёртой вызовов инструментов уже не было: модель сформировала итоговый текст.

Метрики совпали с отдельным тестом утилиты: шесть корректных записей, две ошибки, средняя задержка 168,3 мс, p95 — 400 мс, одна пропущенная строка. В черновик вошли только реальные проблемы: /api/orders + 500 и /api/orders + 503 — вместе с соответствующими инструкциями runbook.

По телеметрии прогона API вернул четыре нативных вызова, текстовых псевдовызовов не было. Все четыре набора аргументов прошли схему; неизвестных инструментов, ошибок локальных функций, попыток apply=true и выхода на лимит итераций не возникло.

Проверяем запасной режим без tool_calls

Для fallback мы намеренно не передавали tools в API. Вместо этого системный промпт требовал вернуть обычным текстом один JSON-объект с действием tool_call или final. Контроллер извлекал последний валидный объект, проверял его по тому же реестру и вызывал ту же локальную функцию.

Запасной путь тоже завершил задачу: пять итераций, четыре извлечённые JSON-команды и тот же корректный отчёт. Однако Qwen не соблюдала требование «только JSON» буквально — перед объектом она печатала длинный thinking process. Парсер справился, но такой протокол зависит от разбора свободного текста и остаётся более хрупким. Сумма времени пяти ответов составила 62,72 секунды против 20,81 секунды в нативном прогоне. По одному запуску нельзя делать вывод о постоянной разнице скорости, но с точки зрения контракта tool_calls предпочтительнее.

Негативные проверки контроллера

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

Даже если модель запросит apply=true, тестовый диспетчер принудительно заменит значение на false. Это защита на уровне кода, а не надежда на системный промпт. Для реального агента к ней нужно добавить права на уровне ОС или сервиса, таймауты, лимиты размера результата, идемпотентность и подтверждение пользователя перед необратимой операцией.

Что показал второй этап

Публичный эндпоинт Qwen3.6-27B в нашем тесте корректно работал с нативным tool calling через стандартный Python SDK: модель вернула структурированные вызовы, приняла результаты с ролью tool и завершила цикл обычным ответом. Значит, проверенный ранее API можно использовать не только для одиночного чата, но и как модельный слой агента.

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

Граница эксперимента: мы провели функциональный прогон на небольшом локальном файле и одном публичном эндпоинте. Это не нагрузочный тест, не проверка SLA и не доказательство одинакового поведения на любых промптах. Реальную запись отчёта тоже не включали: весь сценарий завершился в режиме dry run.

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

Итог

immers.cloud отработал предсказуемо на всех трёх уровнях — публичном чате, публичном API и агентном цикле с tool_calls: везде задача решилась без обходных путей. Узким местом оказалась не модель, а код вокруг неё: проверка аргументов, полный контракт результата инструментов и dry run по умолчанию определили, можно ли доверять результату.

Совместимость с OpenAI SDK здесь помогла конкретно: код, прошедший базовый API-тест, перешёл в агента без единой правки. Для прототипа этого достаточно как отправной точки — дальше стоит добавить трассировку вызовов и подтверждение опасных действий человеком, то, что в проде отличает контролируемый цикл от рабочего образца.

Источники и страницы продукта

• Страница Qwen3.6-27B в каталоге immers.cloud
• Руководство immers.cloud по каталогу и эндпоинтам
• FAQ immers.cloud
• Тарифы и конфигурации RTX 4090
• О компании и заявленные особенности иммерсионного охлаждения

Реклама. Рекламодатель: ООО «ДТЛ» ИНН 9717073792, erid: 2W5zFHSiVzq

Сама GPT-6 Astra вышла 3 сентября ограниченному кругу организаций, подписчикам Plus, Pro, Business и Enterprise доступ обещали в ближайшие дни, цены и бенчмарки мы разбирали отдельно. Здесь разберём другое: что именно Провенчер советует выкинуть из skill-файлов, AGENTS.md и промптов, чем он это объясняет, где его слова подтверждаются документацией Codex и обновлённым skill-creator, а где это пока наблюдения одного инженера. Заодно посмотрим, как те же правила переносятся на Claude Code, где CLAUDE.md и skills устроены по тому же принципу, и тот же расчёт бюджета работает там точно так же.

• Имя и описание каждого skill попадают в контекст модели до выбора; в Codex этот список ограничен 2% окна контекста (или 8 000 знаками), в Claude Code бюджет 1% окна. При переборе описания обрезаются.
• Провенчер называет три исправления в обновлённом skill-creator: короткие описания, прогрессивное раскрытие (SKILL.md как маршрутизатор к references и scripts) и отказ от подробных «рецептов».
• Из AGENTS.md он советует убрать требование читать стопку доков перед каждой правкой и принуждение к тестам: Astra, по его словам, сама решает, что читать, и сама запускает тесты.
• Жёсткие формулировки «сначала спроси» Astra принимает всерьёз и может остановиться там, где вы были бы рады продолжению; определение «готово» надо задавать до старта задачи.
• По данным OpenAI, разрыв между Astra и GPT-5.6 Sol на агентных бенчмарках заметный: 57,7% против 37,3% на Terminal-Bench 4.0. Независимых замеров пока нет.
• Skills в репозитории читают и чужие агенты на других моделях, поэтому автор предлагает сначала решить, для кого пишете инструкции, и чистить выборочно.

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

Потому что большинство правил в AGENTS.md и skills написаны против конкретных ошибок конкретной модели, и новая модель этих ошибок может уже не делать. Провенчер формулирует это так: «What used to require a lot of handholding and scaffolding no longer does», то есть ручное ведение и строительные леса, которые были нужны год назад, теперь необязательны. Инструкции, по его классификации, живут в трёх местах: в skill-файлах, в AGENTS.md и в промптах конкретных задач, и пересматривать он предлагает все три.

Здесь стоит сразу отделить проверяемое от заявленного. Что Astra сильнее Sol в агентных задачах, утверждает сама OpenAI по собственным бенчмаркам: 57,7% против 37,3% на Terminal-Bench 4.0, 41,4% против 18,1% на AutomationBench, 72,6% против 65,7% на OSWorld 2.0. Сторонних замеров на момент публикации нет, и в истории с Gemini 3.8 Flash мы уже отмечали, что сравнения с конкурентами остаются словом вендора, пока нет независимых замеров. Что при этом старые инструкции мешают, это наблюдение Провенчера из практики команды Codex, и он сам оговаривается, что речь о накопленных за год привычках, а не о замерах. Но механизм, который он описывает для skills, проверяется по документации, и к нему перейдём.

Что не так со skills, когда их слишком много

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

Many people default to downloading a lot of skills into their projects, but that's a mistake. Each skill comes with a name and description that are loaded into the model's context so it knows when to use them. Many descriptions are far too long, and when you add too many skills, Codex starts shortening their descriptions to fit.

Здесь начинается задокументированное поведение. Документация Codex говорит прямо: начальный список skills, куда входит и путь к файлу каждого skill, занимает не больше 2% окна контекста модели, или 8 000 знаков, если размер окна неизвестен; при переборе Codex сначала укорачивает описания, а при очень большом наборе часть skills вовсе выпадает из списка с предупреждением. В Claude Code механика та же, но бюджет жёстче: 1% окна контекста, а объединённый текст описания одного skill по умолчанию обрезается до 1 536 знаков, это значение настраивается. Обрезка идёт с тех skills, которые вы вызываете реже всего. Проверить, сколько контекста съедает список, в Claude Code можно командой /doctor, а строка Skills в /context показывает размер списка уже после применения бюджета.

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

Три правки, которые Провенчер перечисляет для skills, совпадают с принципами обновлённого skill-creator в репозитории Codex. Важная оговорка по датам: этот файл менялся 13 августа, за три недели до релиза Astra, и в статье сказано лишь «we recently updated its guidance», так что называть его «переписанным под Astra» нельзя. Сами правила такие:

1. Описание как можно короче, но так, чтобы было ясно, когда skill применять. В skill-creator этот принцип назван «Keep discovery cheap and precise»: описывать реальную возможность и условия применения, добавлять исключения только там, где они предотвращают ложное срабатывание, избегать исчерпывающих списков возможностей и «catchalls».
2. Прогрессивное раскрытие. Для skill с несколькими сценариями корневой SKILL.md должен быть минимальным маршрутизатором, который отправляет к вспомогательным документам и скриптам. В skill-creator это три стадии: имя и описание видны при выборе, тело SKILL.md загружается при применении, а references и scripts читаются только когда нужны конкретной задаче.
3. Меньше рецептов. Многие skills написаны как подробные маршруты по шагам. Модели, по словам автора, стали лучше понимать нюансы и неоднозначность, поэтому избыточная конкретика теперь вредит там, где раньше помогала. Принцип skill-creator «Match specificity to the risk» говорит то же: фиксированные последовательности и абсолютные формулировки оставлять для операций, где отклонение приведёт к конкретной проблеме.

Как это выглядит в структуре папки, skill-creator показывает на примере skill для развёртывания в облаке: общий выбор провайдера остаётся в корневом файле, а детали каждого провайдера лежат отдельно, и при выборе AWS модель читает только один из трёх файлов:

Последний аргумент Провенчера про skills касается командной работы. Skills, закоммиченные в репозиторий, читают агенты других участников, и они могут работать на других моделях: «Guidance that helps Sol or Luna may overconstrain GPT-6 Astra». Отсюда практический вывод: прежде чем вычищать инструкции, решите, для каких моделей они останутся. Если половина команды сидит на GPT-5.6 Sol или на моделях Claude, скаффолдинг ещё пригодится.

Что убрать из AGENTS.md в первую очередь

Первыми кандидатами на вылет Провенчер называет два правила: требование прочитать стопку документации или карту репозитория перед каждой правкой и требование запускать тесты. AGENTS.md действует при любой работе модели в репозитории, поэтому он предлагает пройтись по каждой строке и спросить, нужна ли она всё ещё задаче. Для исправления опечатки обязательный обзор всего проекта избыточен, а Astra, по его словам, сама понимает, что ей нужно прочитать.

Prompting the model to read files before every edit, is a great way to burn context and slow work down.

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

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

Обратите внимание на конструкцию: в одной фразе сказано, почему действие безопасно (одноразовые фикстуры, нет доступа к проду), что именно разрешено (запускать, чинить падения от текущего изменения, перезапускать затронутые тесты) и от чего модель освобождается (спрашивать разрешение на каждом шаге). Граница описана через разрешение для конкретного сценария, и это совпадает с принципом skill-creator «Match specificity to the risk».

Как задать границы, чтобы модель не останавливалась на полпути

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

GPT-6 Astra has much better judgment, and you should treat it as such. It also takes your boundaries seriously and may stop work where you'd actually be happy for it to continue.

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

If you're used to GPT-5.6 Sol taking a request and continuing for long stretches, GPT-6 Astra can feel more tentative about when to stop. It may reach a first implementation and come back for your review while there's still work to do.

Лечение он предлагает на уровне промпта задачи. Если задача включает запуск реализации, проверку результата и исправление того, что упало, всё это надо перечислить в запросе как часть определения «готово». Требование «остановись на ревью после первой реализации» тянет модель к ранней остановке, и автор советует проверить, действительно ли это решение, которое вам нужно принимать вручную. Если хочется, чтобы модель исследовала дальше первого прохода, надо сказать, что исследовать и где остановиться. Это согласуется с тем, что OpenAI писала в анонсе: Astra задаёт вопрос, когда недостающая информация меняет результат, и заполняет пробелы сама в остальных случаях. Мы приводили это описание в новости о выходе модели, и оно тоже пока не подтверждено сторонними тестами.

Скепсис здесь уместен в обе стороны. Что Astra «осторожнее» Sol и «сама запускает тесты», мы знаем со слов инженера OpenAI, а не из воспроизводимого замера. Но и обратное утверждение, что старые инструкции безвредны, ничем не подтверждено: стоимость списка skills в контексте посчитана в документации обоих инструментов, и она не зависит от того, какая модель под капотом.

Как провести аудит своих инструкций по шагам

Ниже чек-лист, собранный из статьи Провенчера и принципов skill-creator. Он одинаково применим к Codex CLI (на 5 сентября 2026 актуальна версия 0.153.4, skills лежат в .agents/skills репозитория или в ~/.agents/skills пользователя) и к Claude Code (.claude/skills в проекте и ~/.claude/skills у пользователя, инструкции репозитория в CLAUDE.md).

1. Посчитайте, сколько стоит список skills. В Claude Code выполните /doctor: он оценит контекст, который занимает список, и назовёт самых тяжёлых. В Codex бюджет списка 2% окна, при переполнении описания укорачиваются и появляется предупреждение о выпавших skills.
2. Удалите skills, которыми не пользуетесь. В Codex skill можно выключить, не удаляя, через [[skills.config]] в ~/.codex/config.toml с enabled = false и path к его SKILL.md, после правки конфига Codex нужно перезапустить; в Claude Code низкоприоритетные skills можно оставить в списке без описания через skillOverrides со значением name-only.
3. Сократите каждое описание до одной задачи и одной границы. Образец из skill-creator: «Create or edit Word documents when formatting, tracked changes, or comments require document-specific handling». Ключевой сценарий ставьте в начало фразы: так советуют обе документации: Codex прямо говорит выносить вперёд ключевой сценарий и триггерные слова, Claude Code советует ставить ключевой сценарий первым из-за капа в 1 536 знаков.
4. Разнесите тяжёлые skills на маршрутизатор и references. Если в SKILL.md несколько сценариев, оставьте в нём общее назначение и критерии выбора, а детали каждого сценария вынесите в отдельный файл, на который есть ссылка с пояснением, когда его читать.
5. Пройдите AGENTS.md или CLAUDE.md построчно. Правила «прочитай X перед любой правкой» замените контекстными ссылками на конкретные документы. Правила «всегда запускай тесты» замените разрешением на конкретный безопасный сценарий по образцу выше.
6. Перепишите запреты в разрешения. Найдите формулировки «никогда не делай без подтверждения», добавленные из-за прошлых моделей, и решите, нужны ли они. Там, где нужны, опишите границу через причину и ограниченную область.
7. Определяйте «готово» в промпте задачи. Перечислите, что входит в завершение: запустить, проверить результат, починить упавшее. Если нужен ранний стоп для ревью, скажите это явно и убедитесь, что это осознанный выбор.
8. Проверьте skills после правки. В комплекте skill-creator есть валидатор: scripts/quick_validate.py <path/to/skill-folder> проверяет frontmatter, имена и незаполненные заготовки, но не качество решений, поэтому описания на дискриминирующую силу придётся проверять глазами.

Кому это не подходит. Если ваша команда или CI работают на GPT-5.6 Sol, Luna или моделях других вендоров, часть скаффолдинга всё ещё делает свою работу, и вычищать её из общего репозитория стоит только после проверки на этих моделях. Провенчер сам оставляет эту оговорку и предлагает думать о том, кто будет читать инструкции после вас. Сама статья заканчивается предложением попросить Astra провести такой аудит по её тезисам; это удобно, но результат аудита, сделанного моделью на собственных инструкциях, стоит просмотреть самостоятельно, прежде чем коммитить.

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

Источники: Eric Provencher. Rethinking skills and prompts for GPT-6 Astra (X, 4 сентября 2026), Профиль Эрика Провенчера в X, skill-creator/SKILL.md в репозитории openai/codex, PR #38384 «Refine skill creation guidance and validation», openai/codex, 13 августа 2026, Документация Codex: Build skills, Документация Claude Code: Extend Claude with skills, Tproger: OpenAI начала выпуск GPT-6 Astra, цены, бенчмарки и кибер-ограничения

Изображение на обложке: Иллюстрация: Eric Provencher, X

Для тех, кто держит Go-сервисы в проде, это закрывает старую дыру в инструментах. Обычный goroutine-профиль показывает, сколько горутин сейчас заблокировано, но не отличает штатное ожидание от горутины, которая уже никогда не проснётся. Раньше такие утечки искали руками по стекам или ловили в тестах пакетом goleak; сам релиз Go 1.27 вышел 19 августа, а разбор механизма команда опубликовала только сейчас.

• Профиль goroutineleak входит в Go 1.27 и доступен через runtime/pprof и net/http/pprof (/debug/pprof/goroutineleak).
• Ловит блокировки на отправке и приёме в канал, блокирующем select, Mutex, RWMutex, WaitGroup и Cond.
• Не считает утечкой ожидание файлового и сетевого ввода-вывода, системных вызовов и самодельных спинлоков.
• По словам команды Go, метод точный и почти не даёт ложных срабатываний; накладные расходы на память названы пренебрежимо малыми, худший случай для одного цикла GC оценён как O(n²).
• В примере из блога профиль нашёл 116 зависших горутин на одной строке с отправкой в небуферизованный канал.

Что такое утечка горутины и почему её было трудно найти

Утечка горутины по определению из блога Go: горутина заблокирована на операции, условие для продолжения которой больше никогда не наступит. Классический пример: воркеры пишут результаты в небуферизованный канал, а читатель вышел из функции по первой ошибке. Каждый следующий воркер зависает на ch <- result навсегда, и чем дольше живёт процесс, тем больше таких горутин копится, растёт потребление памяти и нагрузка на сборщик мусора.

До Go 1.27 инструментов было три, и ни один не решал задачу для продакшена. goleak проверяет, не остались ли горутины после конкретного теста. Пакет synctest, появившийся в стандартной библиотеке Go 1.25, помогает тестировать конкурентный код с виртуальным временем. Обычный goroutine-профиль показывает заблокированные горутины, но не доказывает, что они не проснутся: всплеск нагрузки выглядит в нём так же, как утечка.

Как профиль отличает утечку от штатной блокировки

Идея, которую описывает автор поста Влад Сайок из команды Go, опирается на работу, которую сборщик мусора и так делает. GC вычисляет достижимость памяти от корней. Команда добавила к этому анализу горутины: горутина считается живой, если она не заблокирована на примитиве конкурентности или если примитив, на котором она ждёт, достижим из какой-нибудь живой горутины. Анализ стартует с незаблокированных горутин и распространяется по доступным им каналам и мьютексам. Всё, что осталось недостижимым после этого обхода, никто уже не разблокирует, значит, это утечка.

Команда Go утверждает, что механизм точный и «почти не даёт ложных срабатываний» (перевод редакции). Есть патологический случай: цепочка горутин, где каждая ждёт примитив, доступный только следующей. Для такой «гирлянды» проверка в худшем случае занимает O(n²) шагов за один цикл GC, поэтому в блоге советуют не включать сбор профиля постоянно, а снимать его периодически, например раз в четыре часа. Память на учёт горутин авторы называют пренебрежимо малой, а GC при этом продолжает работать параллельно с пользовательским кодом.

Разработка выросла из совместного исследования Орхусского университета, Университета Вашингтона в Сент-Луисе и Uber; академическую версию представили на конференции ASPLOS 2025.

Что видно в профиле на живом примере

В блоге разобран сервис, который раз в секунду запускает обработку десяти элементов и на пятом получает ошибку. Функция делает ранний return, оставшиеся воркеры зависают на отправке в канал. Программа подключает net/http/pprof и слушает localhost:6060; профиль снимают обычным способом:

Через несколько минут работы pprof показывает Total: 116 заблокированных горутин, и все они стоят на одной операции: отправке в канал ch. Исправление для примера тривиальное: сделать канал буферизованным на число воркеров, make(chan result, len(ws)), тогда воркеры допишут результаты и завершатся, даже если читатель ушёл.

Что профиль не ловит

• Ожидание файлового и сетевого ввода-вывода и системных вызовов утечкой не считается: горутина, зависшая на чтении из сокета, в профиль не попадёт.
• Самодельные спинлоки и другие пользовательские механизмы блокировки не входят в гарантированный набор.
• Горутина, которая по замыслу ждёт вечно на достижимом канале (например, фоновый слушатель), утечкой не считается, потому что канал достижим из живого кода.

Кому новый профиль ничего не даст: сервисам, где горутины блокируются в основном на сети, а не на каналах, и проектам, которые ещё не перешли на Go 1.27. Профиль работает только в рантайме этой версии; для старых сборок остаются goleak и ручной разбор стеков.

Как включить у себя

1. Обновить тулчейн до Go 1.27 (релиз от 19 августа 2026 года, заметки к выпуску) и пересобрать сервис.
2. Если net/http/pprof уже подключён, новый обработчик появится автоматически по пути /debug/pprof/goroutineleak; отдельной настройки не нужно.
3. Снимать профиль периодически, а не постоянно: команда Go предлагает интервал вроде четырёх часов из-за квадратичного худшего случая.
4. Смотреть в первую очередь на места с ранним return при ошибках, таймауты без select с контекстом и воркер-циклы, у которых читатель может уйти раньше писателей.

Схемы GC и полный пример кода лежат в посте команды Go. Из соседних новостей по инфраструктуре Go-сервисов на сайте есть разбор Kubernetes 1.37 и заметка о tailcat от Tailscale, написанном на Go.

Источники: Go Blog: Goroutine leak profiles, Go 1.27 Release Notes, Go Blog: Go 1.27 is released

Изображение на обложке: Go Authors, логотип Go

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

Какие варианты у меня были

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

1. Уйти на грейд выше в другую компанию. Самый популярный ход на рынке. Ты выходишь наружу сеньором и заходишь в новую контору уже принципалом и получаешь рост в деньгах. Но насколько часто вы видите высокооплачиваемые экспертные роли в IT в последнее время, добавьте сюда текущее состояние экономики, и возможно узкую специализацию компаний, где такие вакансии всё-таки есть. Плюс сейчас всех активно возвращают в офис и в гибрид, а заодно сужают географию найма.
2. Взять три мидловые работы вместо одной сеньорской. Схема известная всем, и на удалёнке она какое-то время работала прекрасно. Но в сутках 24 часа, из которых надо ещё спать и есть. Заработать так действительно можно, но развиваться нельзя вообще: ты не углубляешься нигде, а весь день бегаешь от пожара к пожару и чинишь то в одном месте, то в другом. Через год у тебя больше денег и те же навыки, что были.
3. Завести пет-проект. Совет, который в такой ситуации дают чаще всего. Отнимает немного времени, приносит немного денег, разгружает голову. Я свой проект завёл и до сих пор не бросил, вещь полезная. Но проблему потолка он не решает, потому что пет-проект остаётся хобби с монетизацией. Ты по-прежнему разработчик, только уже для себя. Ты не разговариваешь с клиентами, не считаешь экономику, не собираешь команду и не отвечаешь за деньги, потому что денег там мало и потерять их не страшно.
4. Уйти в вайбкодинг. Я попробовал и довольно быстро поймал себя на неприятной мысли, что стал оператором конвейера: агенты пишут, я проверяю. Заодно шутка про «не наберём джунов подешевле, а лучше заменим их агентами» перестала быть шуткой, и это скорее повод побыстрее выйти из категории людей, которых можно так заменить.

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

Почему грейд упирается не в навыки

Я пошёл разбираться, как система грейдов устроена вообще, и понял, что в матрице грейдов нет денег.

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

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

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

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

Как я нашел главную проблему — люди вокруг

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

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

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

Почему я пошёл на Физтех

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

Дальше я нашёл программу МФТИ. У Физтеха есть кафедра технологического предпринимательства, которую он делает вместе со Сколково, а у кафедры есть онлайн-магистратура, которую называют ТехПред.

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

Про сам вуз. Физтех называют русским MIT, и по нагрузке он до сих пор считается одним из самых тяжёлых в стране. Среди основателей, преподавателей и выпускников есть нобелевские лауреаты. Среди выпускников хватает и учёных, и предпринимателей: физтехи стоят за ABBYY, Revolut, Veeam и другими технологическими компаниями. С 2020 года МФТИ возглавляет российский рейтинг предпринимательских университетов и бизнес-школ.

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

Иллюзия гениальности

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

Разбор проектов на программе ведёт Вячеслав Чикин, заместитель заведующего кафедрой технологического предпринимательства МФТИ+Сколково и серийный предприниматель. В интервью «Почему ваш пет-проект ещё не бизнес, а вы не предприниматель» он формулирует это так:

Предпринимательство начинается не с технологии. Оно начинается с проблем, которые есть у тех, кто будет пользоваться продуктом». Разработчик по природе смотрит на то, что он создал, и ищет, куда это применить. Предприниматель смотрит в обратную сторону: вот проблема, вот человек, который в ней застрял, — что из имеющегося в мире поможет её решить? Технология при этом не обязательно должна быть своей.

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

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

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

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

Дружба и бизнес после 30

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

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

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

Доступ к экспертизе

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

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

Системное мышление ведёт Анатолий Левенчук, директор по исследованиям русского отделения INCOSE и автор учебников по системноинженерному мышлению. Управление проектами читает Григорий Ципес, главный консультант компании IBS и вице-президент Ассоциации управления проектами. Коммерциализацию разработок ведёт Владимир Антонец, доктор физико-математических наук из Института прикладной физики РАН, который организовал первый в стране региональный технологический инкубатор. Юридическую часть закрывает Роман Янковский, автор «Закона стартапа».

Команда из своих

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

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

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

Как поступить

• Сроки. Приём заявлений идёт с июня по август 2026 года включительно, обучение начинается 1 сентября. Форма очная, занятия дистанционные, учиться четыре семестра.
• Порядок действий. Сначала разобраться в программе. Дальше оставить контакты в форме на сайте и, по желанию, уточнить, будет ли лично вам польза от этого обучения. Потом подать заявление на сайте МФТИ, пройти собеседование и сдать вступительное испытание. Вся информация и форма заявки на techpredonline.ru.
• Деньги. Есть образовательный кредит с господдержкой по ставке 3% годовых, который дают без подтверждения доходов. Есть оплата по семестрам, 445 500 рублей за семестр. Есть оплата работодателем, в том числе через корпоративные программы обучения и развития, и для корпоративных руководителей это часто самый быстрый путь, потому что бюджет на развитие сотрудников есть почти везде, просто про него редко спрашивают.

Вместо вывода

Упереться в потолок в 35-40 лет нормально, через это проходят почти все. Странно другое: решить, что дальше остаётся только доживать по инерции, добирая проценты к зарплате и меняя логотип в трудовой раз в три года.

Для меня сработала только смена среды и поступление в МФТИ, дальше подтягивается остальное: экспертиза, к которой раньше не было доступа, команда, статус и новые люди, часть из которых со временем становится партнёрами.

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

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

Приём заявлений идёт до конца августа: techpredonline.ru. Ещё есть онлайн-школа «Предпринимательское планирование» на полтора месяца, если успешно её закончите — она даёт минимальные проходные баллы в магистратуру.

Реклама. Рекламодатель: МФТИ, Физтех ИНН 5008006213, erid: 2W5zFJHUfX7

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

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

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

Без базы оценить код нечем

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

База начинается с двоичной системы и дальше идёт по языкам в порядке их появления, через Pascal, Basic и всё остальное. Человек, который прошёл весь этот путь, понимает, из чего собран код, который ему выдали, и способен сказать, где там будет баг. Без этого вайбкодинг сводится к копированию текста, который выглядит нормально, и работает до первого теста.

Хороший пример того, как это осваивают с нуля, есть в Roistat. Генеральный директор компании Наталья Арсланова Рассказала об этом в очередной встрече цикла “Беседы в МФТИ” кафедры технологического предпринимательства. Наталья по образованию управленец, написанием кода никогда не занималась. Когда фаундер принёс новость про вайбкодинг, он ничего объяснять не стал, а скинул статью с Хабра со словами «разберешься». Два дня ушло на сопротивление, потом она села и сделала. Через тот же путь прошёл весь топ-менеджмент, причём попытки купить готовый курс уперлись в то, что нормальных курсов по вайбкодингу тогда не существовало, и учились все по одной статье. Сейчас вайбкодит большая часть сотрудников. Арсланова говорит, что первый полученный результат затягивает сильнее любой игры, и на этом эффекте люди в тему и въезжают.

Половина работы теперь в самой задаче

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

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

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

За результат всё равно отвечаешь лично

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

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

С обучением ловушка ровно такая же. Человек планирует 20-30% свободного времени под книги или курсы, а в работе ничего не меняется, потому что полученные знания не подходят. Наталья Арсланова решает это правилом: из каждой прочитанной книги по бизнесу надо внедрить минимум одну идею, иначе книга засчитывается как художественная литература и время потрачено на удовольствие.

Как выбрать, чему учиться

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

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

Отдельно стоит смотреть на программы, где учиться нужно сразу на своём проекте. Предпринимательству по учебникам не научишься, поэтому в онлайн-магистратуру той же кафедры технологического предпринимательства МФТИ приходят люди в среднем около 35 лет и приносят готовый контекст: свой стартап, спин-офф внутри компании или проект в корпорации, за который они отвечают. Заявления в магистратуру принимаются до 15 августа, обучение стартует 1 сентября, для поступления нужно пройти собеседование. Программа по семестрам и условия есть на techpredonline.ru.

Что будет с образованием дальше

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

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

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

Итого

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

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

Реклама. Рекламодатель: МФТИ, Физтех ИНН 5008006213, erid: 2W5zFJBmp6d

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

Тикет закрыт, а фича не работает

Разработчик встречается с этим каждый день: тикет закрыт, а фича не работает; правка влита, но не собрана и не выкачена; ТЗ согласовано, а в проде всё по-старому. Владимир Бодров проработал в аэрокосмической отрасли 20 лет, а сейчас преподаёт на кафедре технологического предпринимательства МФТИ. Он рассказывает, что на большом производстве происходит ровно то же самое:

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

Разница простая, есть описание: ТЗ, план, код в репозитории, стратегия, презентация для инвестора. И есть реализация: работающий сервис на проде, построенная производственная линия, проданный продукт.

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

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

Сначала — зачем, потом — из чего

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

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

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

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

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

Агентом может быть и модель

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

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

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

Системное мышление работает как полка

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

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

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

Главное, что даёт системное мышление, по наблюдению Бодрова, это структура. Слушатели с опытом MBA часто говорят, что поняли смысл прежнего обучения только после курса, когда знания встали на места. Отсюда и сравнение с книжной полкой: любое новое знание, инженерное, управленческое или финансовое, начинает быть полезным только тогда, когда вы из-за правильного системного мышления научились правильно применять знания.

На кафедре технологического предпринимательства МФТИ системное мышление вы будете изучать сразу: сначала рациональная работа и моделирование, потом системное мышление и методология, потом практики системной инженерии и менеджмента. Материал построен на курсах Мастерской инженеров-менеджеров и опирается на стандарты системной инженерии ISO 15288, ISO 42010 и документы INCOSE. Читают его практики: люди из аэрокосмической отрасли, лазерной индустрии, энергетических проектов, — те, кто на своём опыте знает, где мышление ломается о физический мир. Приём заявлений в магистратуру идёт до 15 августа, старт обучения — уже 1 сентября, для поступления нужно пройти вступительное испытание в форме собеседования. Программа по семестрам и условия — на techpredonline.ru

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

Одной статьёй мыслить системно не научишься

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

1. Описание — это ещё не результат. Тикет закрыт, коммит влит, ТЗ согласовано — это пока записи. Прежде чем радоваться, проверьте, что из них уже стало работающим продуктом.
2. Сначала функция, потом конструкция. До того как выбирать стек, ответьте, что и для кого изменится в мире. Технология без функции — это риск, а не продукт; иногда даже оправданный.
3. Системному мышлению учатся. Это не врождённый талант, а навык и каркас, на который потом встаёт всё остальное — инженерия, менеджмент, работа с ИИ-агентами.

На кафедре технологического предпринимательства МФТИ этому учат первым и три семестра подряд — и не в теории: курс читают инженеры и предприниматели, которые сами прошли путь от описания идеи до успешного продукта, поэтому помогут пройти его и вам.

Реклама. Рекламодатель: МФТИ, Физтех ИНН 5008006213, erid: 2W5zFKAZY97

В августе 2026 года рынок моделей для генерации кода уперся в новый потолок: Anthropic выпустила Claude Opus 5, OpenAI показала GPT-5.6 Sol в ограниченном доступе, а китайские разработчики предложили открытые веса с результатами уровня флагманов прошлого квартала. Разбираем, что из этого реально купить и как не переплатить.

Что такое SWE-bench и почему он стал главным аргументом

SWE-bench Verified — это набор из 500 реальных задач с GitHub: модели видят описание бага и должны сгенерировать патч, который проходит существующие тесты проекта. Не задачи из LeetCode, а настоящие репозитории с чужой архитектурой и зависимостями. Для оценки кодогенерации это ближе к продакшену, чем большинство альтернатив.

С апреля 2026 года Verified «насытился»: топ выстроился в узкий коридор 95-96%. Поэтому внимание переключилось на SWE-bench Pro — 1865 более сложных задач из 41 репозитория на нескольких языках. Именно здесь видна разница между «хорошо пишет функции» и «разбирается в большом коде».

Claude Opus 5 — лучший баланс качества, цены и доступности: 96,0% на SWE-bench Verified и $5/$25 за миллион токенов.

Claude Mythos 5 лидирует на SWE-bench Pro (80,3%), но доступен лишь ~100 партнёрам программы Glasswing.

GPT-5.6 Sol теоретически первый по Verified (96,2%), но цифра не подтверждена OpenAI, а доступ ограничен ~20 партнёрами.

GLM-5.2 — сильнейший открытый вариант: 62,1% на SWE-bench Pro под лицензией MIT, но сжигает в 2-3 раза больше выходных токенов.

Gemini 3.1 Pro и DeepSeek V4-Pro предлагают ~80% на Verified за $2-3 за миллион токенов — лучшее соотношение цена/качество для массовых задач.

Как устроена верхушка рейтинга

Claude Opus 5 — практичный выбор

Anthropic выпустила Claude Opus 5 24 июля 2026 года по цене старого Opus 4.8: $5 за входящий и $25 за исходящий миллион токенов. На SWE-bench Verified модель набрала 96,0%, а на более сложном SWE-bench Pro — 79,2%. Этого хватает для большинства инженерных задач, а цена остаётся вдвое ниже, чем у Mythos-класса.

Главное ограничение Opus 5 — уступка собственным старшим собратьям на Pro. Если ваша работа связана с большими межрепозиторными изменениями, Mythos 5 и Fable 5 дают 80,0-80,3%, но вы платите $10/$50 за миллион токенов и, в случае Mythos, ещё и проходите отбор в программу Glasswing.

Mythos 5 и Fable 5 — потолок, до которого не дотянуться

В июне Anthropic представила Claude Fable 5 и Claude Mythos 5 — первые модели, преодолевшие 90% на SWE-bench Verified. Обе показывают 95,0% Verified, а Mythos 5 держит лучший результат на Pro — 80,3%. Fable 5 доступен через обычный API любому клиенту, готовому платить Mythos-тариф.

Mythos 5 закрыт примерно для 100 партнёров в рамках программы Glasswing, в основном для исследований в области кибербезопасности и биобезопасности. Это важный нюанс для российских команд: даже если у вас есть бюджет, доступ к модели зависит от одобрения Anthropic, а не только от платёжной карты.

GPT-5.6 Sol — красивое число, которое никто не проверил

OpenAI выпустила GPT-5.6 Sol в ограниченном превью для примерно 20 партнёров, прошедших правительственную проверку. Компания не опубликовала официальных результатов SWE-bench, но сторонние трекеры, включая vals.ai, сообщают 96,2% на Verified.

Пока это не результат, на который можно ориентироваться при выборе инструмента. Цена, если доступ появится, составляет $5/$30 за миллион токенов — чуть дороже Opus 5. Для российских пользователей добавляется и стандартная проблема доступа к API OpenAI, которая уже несколько лет сильнее ограничена, чем у Anthropic или Google.

GLM-5.2 — открытые веса с реальными цифрами

Zhipu AI выпустила GLM-5.2 под лицензией MIT. Модель показывает 62,1% на SWE-bench Pro — выше, чем GPT-5.5 (58,6%), и выше предшественника GLM-5.1 (58,4%). Контекстное окно составляет 1 млн токенов, а обучение проходило на чипах Huawei Ascend, а не NVIDIA.

Цена API — $1,40/$4,40 за миллион токенов, но на практике GLM-5.2 расходует около 43 000 выходных токенов на одну кодинговую задачу против 16 000 у GPT-5.5. Поэтому итоговая стоимость за выполненную задачу ближе к флагманам, чем кажется по прайс-листу. Главное преимущество — возможность скачать веса и развернуть модель у себя. Для команд с требованиями к локальному хранению кода это может перевесить экономию на API.

Gemini 3.1 Pro и DeepSeek V4-Pro — флагманы за разумные деньги

DeepSeek V4-Pro и Gemini 3.1 Pro показывают по 80,6% на SWE-bench Verified — ровно тот уровень, который в апреле считался потолком. DeepSeek стоит $1,74/$3,48 и работает с полностью открытыми весами. Gemini 3.1 Pro стоит $2/$12, имеет окно в 1 млн токенов и 91,7% на LiveCodeBench.

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

Как читать таблицу моделей

Результаты можно свести к трём осям: качество на Verified, качество на Pro и реальная доступность. Если смотреть только на Verified, четыре модели стоят плечом к плечу в диапазоне 95,0-96,2%. Разница появляется, когда добавляешь цену, условия доступа и более жёсткий бенчмарк.

Как ориентироваться в ценах:
Цены указаны за 1 млн входящих / 1 млн исходящих токенов. На практике важнее стоимость за завершённую задачу: одна модель может быть дешевле за токен, но генерировать в 2-3 раза больше текста.

Вот как распределяются роли:

• Claude Opus 5 — универсальный выбор, если нужен API без листов ожидания и цена ниже Mythos.
• Claude Mythos 5 — для команд с доступом к Glasswing, которые решают самые сложные многофайловые задачи.
• GLM-5.2 — для self-hosted сценариев и требований к открытым весам.
• DeepSeek V4-Pro и Gemini 3.1 Pro — для высоконагруженных сценариев, где важна цена за токен.

Методология: почему Verified больше не разделяет лидеров

Авторы обзора используют три сигнала. SWE-bench Verified даёт понять, справляется ли модель с реальными багами. SWE-bench Pro проверяет, как модель работает с более крупными и разнообразными репозиториями. Третий сигнал — это статус доступа и независимость проверки: официальная цифра, сторонний трекер или собственная оценка вендора.

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

Историческая динамика: бенчмарки устаревают быстрее моделей

В марте 2025 года лидером был Claude 3.5 Sonnet с около 49%. В январе 2026 четыре модели одновременно преодолели 78%. В апреле Verified «сел» на плато 76-81%, и внимание перешло на Pro. В июне Mythos-класс впервые превысил 90%, а к концу июля Opus 5 почти догнал его по цене вдвое ниже.

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

Что выбрать: чек-лист для команды

Чтобы не утонуть в таблицах, можно пройти по четырём вопросам:

1. Есть ли у вас доступ к API Anthropic, OpenAI или Google? Если нет, открытые веса DeepSeek или GLM-5.2 остаются единственной рабочей опцией.
2. Решаете ли вы локальные баги в одном репозитории или межрепозиторные изменения? Для второго важнее SWE-bench Pro.
3. Какой бюджет на 1 млн исходящих токенов? При высоких объёмах разница между $25 и $3 за миллион ощутима уже на первой неделе.
4. Нужно ли хранить код внутри периметра? В этом случае self-hosted GLM-5.2 или DeepSeek выигрывают у облачных API независимо от бенчмарков.

Когда Verified перестаёт разделять модели, выбор сдвигается с 'кто умнее' на 'кого я могу купить и сколько это будет стоить за реальную задачу'.

FAQ

Выводы

В июле 2026 года рынок моделей для генерации кода разделился на два лагеря. Первый — закрытые флагманы, которые достигли потолка Verified и теперь конкурируют по цене и доступности. Второй — открытые и полуоткрытые модели, которые отстают по верхним цифрам, но выигрывают у крупных вендоров в контроле над данными и стоимости инфраструктуры.

Для российских команд ключевой вопрос не в том, какая модель «умнее», а в том, какая из них реально доступна, не требует сложных схем оплаты и укладывается в бюджет. В этом контексте Claude Opus 5, DeepSeek V4-Pro и GLM-5.2 выглядят наиболее практичными вариантами — каждый под свои ограничения.

Источник: обзор Best AI Models for Code Generation — July 2026 на Awesome Agents. Данные по бенчмаркам и ценам приведены по состоянию на 29 июля 2026 года.

Мне пришлось разбираться самому, когда я пришёл на новый проект, где на этапе знакомства с системой я понял: сделать её на React технически можно, но нужно постоянно собирать структуру с нуля. Angular с его сложной архитектурой, сервисами и строгой типизацией казался оптимальным решением для такого масштаба.

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

Разделение ответственности и файловая структура

Главный сдвиг в голове при переходе с React — смена подхода, где компоненты несут всю нагрузку, на архитектуру, построенную на классах и ООП. В React привыкаешь думать компонентами: каждый кусок интерфейса представляет собой функцию, которая принимает пропсы и возвращает разметку. Вся логика и JSX-шаблон живут в одном файле, всё плоское и перед глазами. В Angular приходится перестраиваться и думать объектами и иерархиями.

Разделение на файлы поначалу вызывает раздражение. Вместо одного файла здесь сразу три: отдельный HTML-шаблон, стили и TypeScript-класс компонента, взаимодействующие через декораторы. Если нужно сделать маленький компонент-иконку для рендеринга SVG, Angular всё равно потребует три файла. Инлайн-шаблоны сделать можно, но это считается плохой практикой. Переключение между файлами поначалу отвлекает, но когда шаблон становится большим и сложным, работать с ним как с отдельным документом оказывается удобно.

Проект в Angular организуется по строгой структуре: сначала выделяются библиотеки (libs), внутри них — фичи (features), и только внутри фич живут компоненты. В React всё обычно проще и ограничивается папками с компонентами, которые используют друг друга.

От функций и хуков к ООП и наследованию

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

Архитектура строится вокруг базовых классов с общими методами и свойствами, от которых наследуются конкретные сущности. Если создать базовый класс Animal, дочерние классы Cat, Duck или Elephant получат его функциональность и добавят собственные уникальные атрибуты, не затрагивая родительский код. Когда нужно исправить или обновить базовую логику, нужно только внести изменения в одном месте, и они автоматически разойдутся по всей иерархии.

Асинхронные данные и реактивные потоки RxJS

Больше всего при переходе на Angular пугает RxJS. В React мы привыкли явно запрашивать данные и ждать ответа, а здесь приходится подписываться на поток и реагировать на каждое его изменение. Данные идут сами и непрерывно, а главная задача разработчика — правильно их направить: отфильтровать лишнее, объединить несколько потоков в один и вовремя отписаться, чтобы избежать утечек памяти.

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

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

Встроенный tooling: формы, CLI и декораторы

Когда от стадии “отрицания” переходишь к “принятию” подхода, начинаешь замечать вещи, за которые Angular хочется любить. Первое, что бросается в глаза после React, — работа с формами. В React каждый раз приходится выбирать между React Hook Form, Formik и другими решениями, разбираясь в новой библиотеке на каждом проекте. В Angular работы с формами встроена в сам фреймворк: есть задокументированные Template-driven и Reactive Forms. Реактивные формы позволяют прописать объект FormGroup и всю валидацию прямо в TypeScript. В сложных конструкторах с вложенной логикой и зависимыми полями это полностью закрывает задачи без поиска сторонних пакетов на npm.

Следом привыкаешь к CLI, который буквально не даёт сделать что-то неправильно. Для нового компонента достаточно выполнить ng generate component auth-form — инструмент сам создаст файлы и зарегистрирует компонент в модуле. Точно так же одной командой генерируются сервисы и модули с маршрутизацией. Инструмент выполняет рутину по единственному правильному шаблону, который при необходимости можно настроить под проект.

Приятно удивляет и декоратор @HostBinding. Если в React для добавления CSS-класса по условию приходится писать логику в JSX или выносить её в отдельную функцию, то в Angular достаточно повесить одну строчку над свойством класса. Класс сам появляется или исчезает на хост-элементе в зависимости от значения, не создавая лишнего шума в шаблоне.

Диагностика циклических зависимостей

Самая противная проблема в Angular — циклические зависимости. Это ситуация, когда Сервис А зависит от Сервиса Б, а Сервис Б где-то дальше по цепочке ссылается на Сервис А. Фреймворк далеко не всегда ясно указывает на место ошибки: приложение может просто упасть при старте или вывести в консоль сбой, указывающий совсем не на ту причину.

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

Для выхода из этой ситуации есть инструмент Nx и команда nx dep-graph (или nx graph). Она визуализирует интерактивную карту проекта прямо в браузере, рисуя дерево связей между всеми библиотеками. Если в проекте появился закольцованный цикл, команда автоматически подсвечивает его красным цветом.

Критерии выбора стека под задачи

Angular точно не подходит на роль первого фреймворка для новичка. Это логичный следующий шаг, если хочется развиваться в сторону фуллстека или бэкенда: Java и Go тоже используют классы, объекты и dependency injection как стандартную практику. Год работы с Angular помогает легче понимать паттерны того же Spring Boot, потому что основные концепции уже отработаны на фронтенде.

Если задача — быстро собрать MVP, стартап, лендинг или небольшое приложение, объективно проще взять React. Там меньше формальностей и ниже порог входа на старте. Когда же предстоит развивать сложную долгоживущую систему с крупной командой, Angular оказывается практичнее: через год любой новый разработчик сразу поймёт структуру без дополнительных объяснений.

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

Итого

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

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

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

Исследователь и корпоративный архитектор, который в конце 2025-го — начале 2026 года внедрял агентов в финтехе, медицине и compliance, провёл честный post-mortem: из 47 агентов, запущенных в продакшен, стабильную пользу через время приносили только шесть. Разница была не в LLM и не в автономности, а в том, была ли у команды система поддержания контекста в актуальном состоянии.

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

Из 47 промышленных ИИ-агентов 87% со временем пришлось отключить или серьёзно переделать.

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

Спасение — в «живой архитектуре контекста»: freshness scoring, регулярное обновление, drift detection и точки вмешательства экспертов.

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

Что такое context rot

Context rot возникает, когда окружение меняется, а представление агента об этом окружении — нет. Новые транзакционные коды, обновлённые клинические гайдлайны, свежие ESG-критерии, изменённые приоритеты бизнеса: всё это проходит мимо агента, если он не синхронизируется с источниками. Поначалу это почти незаметно на дашбордах: агент не падает, не выдаёт явную ошибку, просто постепенно отдаляется от реальности. А потом приходит звонок от финансового директора или аудиторов.

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

Три болезненных кейса из продакшена

Платёжный агент в финтехе

Агент автоматически сверял входящие wire-переводы со счетами-фактурами в трёх банковских системах и ERP. В тестах и первые четыре недели в продакшене точность достигала 96%. Затем, к шестой неделе, она тихо упала до 67%. Причина: клиент обновил план счетов и добавил два новых транзакционных кода к концу года. Агент не узнал об изменениях и продолжал формировать неверные проводки. Расчёты и ручная коррекция обошлись клиенту примерно в $340 000, после чего агента отключили.

Агент prior authorization в здравоохранении

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

Агент мониторинга compliance вендоров

Агент отслеживал рискованные платежи поставщикам и почти десять недель показывал хороший результат. Когда компания ввела новую ESG-оценку, агент продолжал действовать по старым критериям. Система сгенерировала более 180 ложных позитивов: совершенно нормальные вендоры стали помечаться как высокорискованные. Вместо помощи закупкам инструмент превратился в bottleneck и начал тормозить процессы.

Почему большинство команд это упускает

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

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

Живая архитектура контекста

Шесть агентов, которые выжили, были спроектированы не как разовые деплои, а как живые системы. Автор называет этот подход Living Context Architecture. Вот практики, которые дали наибольший эффект:

• Context freshness scoring — каждое значимое решение сопровождается оценкой 0–100, показывающей, насколько свежи и валидны данные, на которых оно основано.
• Обязательные циклы обновления — критически важная информация перепроверяется каждые 24–72 часа прямо в живых системах-источниках, а не только когда агент наткнулся на ошибку.
• Drift detection — лёгкие фоновые процессы постоянно сравнивают внутренние знания агента с текущей бизнес-реальностью и сигналят, когда расхождение превышает порог.
• Многоуровневый контекст — разделение по скорости изменения: неизменные регламенты, медленно меняющиеся политики и быстро меняющиеся операционные данные обновляются с разной периодичностью.
• Точки ввода человеческого контекста — структурированные моменты, когда доменные эксперты могут проверить вывод агента и напрямую скорректировать его понимание ситуации.

Чеклист для команды

• Перед запуском определите, какие данные агент считает источником истины и кто за их актуальность отвечает.
• Заложите метрики свежести контекста — хотя бы оценку в процентах для каждого значимого решения.
• Настройте регулярную синхронизацию с живыми системами, а не только ручное обновление при сбое.
• Добавьте drift detection: сравнивайте встроенные знания агента с текущими данными и фиксируйте расхождения.
• Разделите контекст на слои по скорости изменения и не обновляйте всё с одной частотой.
• Предусмотрите точки ручной проверки экспертами — особенно для регуляторных и финансовых решений.
• Фиксируйте post-mortem каждого инцидента context rot, чтобы не повторять одни и те же слепые зоны.

Частые вопросы

Выводы

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

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

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

Источник: How I Beat Context Rot and Saved 6 Out of 47 AI Agents in Production — HackerNoon

Арендовать мощные VPS под ресурсоемкие задачи в текущих реалиях выходит неоправданно дорого. При этом дома у меня уже был выделенный неттоп (мини-ПК) с 16 ГБ оперативной памяти на базе энергоэффективного процессора Intel N95.

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

История настройки сетевой архитектуры

Использование Tuna

В самом начале проекта я еще не думал о VPN как о способе пробития NAT и основе, на которой будет строиться вся система. Первое, к чему я пришел — сервис Tuna. Если кратко, это аналог Cloudflare Tunnel за условные 300 рублей. У него очень приятный веб-интерфейс и невероятно простая настройка. Однако для полноценной независимой архитектуры он не подошел по двум причинам:

• Сервера Tuna находятся вне контроля пользователя.
• На удаленном сервере нельзя развернуть свои сопутствующие сервисы.

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

Вот пример конфига для tuna (все максимально просто, создаем контейнеры для ssh туннеля, чтобы был доступ ssh, а также основной http туннель с привязкой к nginx или любому другому прокси если такой есть):

В поисках гибкости: тесты Pangolin и переход к FRP

После Tuna я решил двигаться в сторону собственного контроля и попробовал Pangolin. Однако решение быстро отвалилось: для дешёвого сервера оно оказалось слишком «тяжёлым» и избыточным. Главные минусы — ощутимый оверхед по ресурсам и лишний слой принудительной веб-аутентификации перед самими сервисами. Это ломало нормальное взаимодействие с родными мобильными клиентами (вроде Element для Matrix или Bitwarden для паролей), где повторная авторизация в браузере просто не нужна.

На смену пришел FRP (Fast Reverse Proxy). Он выполнял ту же функцию проброса, но хостил я его уже на собственном арендованном VPS в режиме Layer 4 (TCP). Это дало абсолютную гибкость: внешний VPS не заглядывал внутрь пакетов и ничего не расшифровывал, а просто пересылал сырой поток домой. Кроме того, это отлично оптимизировало расходы: вместо 300 рублей за Tuna и ещё 300 рублей за отдельный VPN, я стал платить всего 500 рублей за один стойкий VPS, который мог настраивать как хочу. (к тому же можно было обойтись даже дешевле, так как VPS с 4 гб оперативки загружен всего лишь на 40%, процессор всего на 20%-40%)

FRP состоит из 2 конфигурационных файлов (один на удаленном сервере frp server, другой на локальном frp client), все также довольно просто, однако его можно использовать на разных слоях. У меня он брал трафик за стандартный TCP и передавал его на локальный сервер.

Также доп. фишка в том что основная конфигурация происходит именно в frpc, который, в свою очередь, передает часть настроек на frp на удаленном сервере.

frpc.toml:

frps.toml:

Полноценный переезд на WireGuard (AmneziaWG) и 8 часов отладки

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

• Безопасность: FRP всё же открывал внутренние ресурсы в публичный интернет, оставляя их доступными для сканеров портов.
• Удобство маршрутизации: Все участники сети стали равноправными узлами в одной виртуальной локальной подсети. Больше не нужно было настраивать постоянные односторонние пробросы.
• Дополнительный бонус: Поскольку удаленный VPS был куплен в Нидерландах, через этот же VPN я автоматически получил безопасный доступ ко всем зарубежным ресурсам.

Для реализации схемы на удаленном VPS был развернут контейнер wg-easy с поддержкой AmneziaWG, а на домашнем мини-ПК — клиентский контейнер Amnezia (сборка из Dockerfile с использованием amnezia-tools и модулем ядра хоста).

И именно здесь я поймал самый изнурительный баг проекта. После развертывания трафик упорно шёл только в одну сторону. Часов 8 ушло на диагностику iptables, маршрутов и чтение зарубежных форумов (что бесполезно, учитывая специфику наших блокировок). Оказалось, провайдер просто дропал обратный трафик стандартного WireGuard, так как пакеты шли без маскировки. Причина крылась в docker-compose.yml: у меня было прописано image: ghcr.io/wg-easy/wg-easy:latest. Как выяснилось, тег latest на Docker Hub намертво прилип к старой 14-й версии, а поддержка параметров AmneziaWG появилась только в ветке 15.x. Изменение тега на конкретную версию (15.3) решило проблему за секунду.

Благодаря переходу конфигурация получилась максимально простой, основные отличия от стандартной документации выделил в коде: (в основном то, на что пришлось долго рыть информацию)

Настройка Nginx

Чтобы сервисы были доступны исключительно внутри подсети VPN, я задействовал Nginx. Доступ к приложениям был жестко ограничен на уровне конфигурации — веб-сервер принимает запросы только из диапазона IP-адресов 10.8.0.0/24. Любые попытки постучаться на сервер из внешнего интернета без активного VPN-туннеля автоматически сбрасываются Nginx.

Логика распределения завязана на proxy-протоколе: Nginx на удаленном VPS выступает основным входным узлом, принимает зашифрованный трафик, заворачивает его в заголовки с реальным IP-адресом клиента и через туннель перекидывает на локальный Nginx домашнего сервера. Локальный веб-сервер уже сам расшифровывает SSL и распределяет трафик по конечным Docker-контейнерам, сохраняя реальные IP в логах безопасности.

Вставлю один кусок кода из nginx на удаленной машине для примера, так все остальное примерно похоже (конфиги использовались в виде .template):

SSL-сертификаты

Для получения валидных SSL-сертификатов я настроил работу через автоматический Certbot по challenge-валидации DNS-01 c API Webnames. Сам домен привязан к внутреннему IP-адресу 10.8.0.1. Проверка через DNS позволила выпустить единый wildcard-сертификат на весь домен и его поддомены без необходимости держать открытым 80-й порт веб-сервера наружу.

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

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

Вот настройка certbot:

История софта

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

Первый стек и оптимизация

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

Затем встал вопрос безопасного хранения паролей. Сначала я смотрел в сторону оригинального Bitwarden, но в итоге я выбрал Vaultwarden — альтернативный сервер на Rust, полностью совместимый с API Bitwarden. Он потребляет считанные мегабайты оперативной памяти и работает идеально. Дополнительно для удобства управления всей этой распределенной Docker-инфраструктурой в локальный стек был добавлен Portainer. (+ Portainer Agent на удаленный сервер)

Из интересных моментов, где мне пришлось немного больше возиться, чем с остальными сервисами это nextcloud настройка:

Ошибки проектирования: почему я удалил Matrix (Synapse)

Не все решения прошли проверку временем. На этапе использования Tuna и FRP я развернул сервер Matrix (Synapse) для защищенного обмена сообщениями. Мне казалось это крутой идеей, но когда я окончательно перешел на AmneziaWG, целесообразность мессенджера внутри закрытого туннеля сошла на нет.

Synapse требовал слишком много ресурсов, впустую расходовал оперативку домашнего ПК и усложнял конфиг Nginx. При этом реальной пользы для семьи он не приносил. Для критических алертов инфраструктуры и повседневного общения проще и эффективнее оказалось использовать Telegram. (плюс алертинг настроен именно через него) В итоге я полностью выпилил Synapse из стека, освободив ресурсы.

Вместо него я добавил в связку к wg-easy локальный AdGuard Home. Теперь он работает прямо внутри VPN-сети: очищает весь трафик от рекламы и трекеров на лету, кэширует DNS-запросы и не дает истории веб-серфинга улетать внешним провайдерам.

Основной проблемой с которой я столкнулся при использовании AdGuard Home, так это то что я так и не понял как заставить использовать AmneziaVPN клиент AdGuard как основной DNS, при этом AmneziaWG работает прекрасно. Как я понимаю дело в том что AmneziaWG работает намного проще на уровне ip и у него нету никаких доп фильтров, настроек и подобного, поэтому он просто берет данные из конфига.

От костылей на Bash к декларативному Ansible

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

Так я пришел к декларативному подходу и Ansible. Теперь вся конфигурация описывается в виде плейбуков и ролей, отражающих конечное желаемое состояние серверов. Конфиденциальные данные перенесены в файл secrets.yml, а хрупкие конструкции автоматизированы через шаблоны Jinja2. Проект стал идемпотентным: если шаги уже выполнены, Ansible их просто пропускает.

В итоге получилось несколько yaml файлов для стандартной настройки системы (bootstrap_os.yml) и для настройки каждого из хостов (setup_local.yml и setup_remote.yml). В итоге теперь все что нужно чтобы полностью с нуля развернуть проект - скачать Ansible, несколько других зависимостей на свой рабочий пк и запустить один manage_deploy.sh, в котором можно будет выбрать сценарий как будет вести себя Ansible и спокойно дождаться разворачивания сервисов.

Также благодаря Ansible я удобно реализовал переносимость проекта. Так как я решил не использовать тома docker, и вместо этого храню все в папках, чтобы перенести старые данные проекта нужно просто скопировать папку apps-data и положить ее в нужное место и все само заработает после повторного развертывания проекта. В Ansible выделяется отдельная пауза для этого.

Вот пример основного плейбука deploy.yml:

Тестирование мультидистрибутивности с помощью Vagrant

Проект изначально затачивался под работу на трех дистрибутивах: Ubuntu, Debian и Arch Linux. Тестировать Ansible-плейбуки прямо на рабочей локальной машине (в моем случае — EndeavourOS) слишком рискованно, а создавать виртуальные машины руками — долго и неудобно.

Решением стал Vagrant, позволяющий за пару минут развернуть чистые ОС в VirtualBox из готовых образов. Но в процессе настройки мультивендорного стенда в режиме сетевого моста (public_network) всплыли две критические проблемы:

1. Конфликт DNS: По умолчанию Vagrant создает NAT-интерфейс для управления нодой. При включении второго (публичного) интерфейса для локальной сети ломался дефолтный DNS-резолвер. Проблему пришлось решать принудительной очисткой и перезаписью файла /etc/resolv.conf через inline-скрипт автоматизации Vagrant.
2. Проблема с GRUB на Debian: В используемом базовом образе generic/debian12 конфигурация GRUB сохраняла жесткую привязку к конкретному имени диска из окружения сборщика. При повторном развертывании плейбуков на тестовом стенде это приводило к сбоям загрузчика. Чтобы автоматизировать очистку, пришлось внедрить скрипт, который на лету определяет имя системного диска через lsblk и автоматически передает правильные параметры в загрузчик через утилиту debconf-set-selections.

Вот код Vagrantfile: (в node.vm.provision происходит основное решение ошибок)

Надежная система бэкапов на базе BorgmaticДля создания резервных копий я внедрил Borgmatic (удобную надстройку над дедуплицирующим инструментом Borg Backup). Весь процесс автоматизирован с помощью связки системных юнитов borgmatic.service и borgmatic.timer. В бэкап уходят две ключевые директории: apps-data (конфигурации приложений и баз данных) и PersonalData (медиатека: музыка, книги, подкасты, файлы Nextcloud).

Развертывание системы бэкапов полностью берет на себя Ansible. Мне достаточно указать UUID внешнего жесткого диска — скрипт сам проверит его наличие в системе, примонтирует в нужную директорию, создаст зашифрованный репозиторий и настроит политику ротации (хранение 7 ежедневных, 4 еженедельных и 6 ежемесячных копий). Также в Prometheus выведен мониторинг самого репозитория .borg для отслеживания его размера и статуса успешности архивации.

Главная проблема при бэкапе работающих Docker-контейнеров — риск скопировать базу данных в «битом» или неконсистентном состоянии, если в момент создания архива в нее шла активная запись. Чтобы решить эту проблему, я задействовал механизм хуков в конфигурации Borgmatic.

Перед началом резервного копирования автоматически срабатывает команда остановки контейнеров проекта (docker-compose down), а после успешного завершения (или в случае возникновения непредвиденной ошибки) контейнеры автоматически поднимаются обратно в фоновом режиме. Для удобного просмотра архивов и быстрого восстановления файлов я развернул веб-интерфейс Borg UI.

Конфигурация borgmatic: (использую как Jinja2 шаблон, чтобы Ansible в плейбуках сам подставил переменные)

Наблюдаемость (Observability) уровня Enterprise

В последних релизах (v1.2.0 и v1.3.0) фокус проекта сместился на мониторинг и работу с логами.

Эволюция алертинга и переход на Gatus

Изначально для мониторинга доступности я смотрел на Uptime Kuma, но отказался из-за отсутствия удобной декларативной настройки через конфиги. Затем я развернул связку Blackbox Exporter и Alertmanager с уведомлениями в Matrix. Но тут крылась логическая несостыковка: весь алертинг был завязан на локальном ПК, и в случае его аппаратного отказа я бы просто лишился уведомлений.

Тогда я решил вернуть Uptime Kuma, но развернуть его на удаленном VPS в качестве внешнего «сторожа» и автоматизировать его настройку через Python-скрипт с библиотекой uptime-kuma-api. Но и тут ждали «грабли» — библиотека не обновлялась три года и намертво ломалась на свежих версиях Kuma.

В итоге идеальным решением стал Gatus. Он изначально проектировался под управление через YAML-конфиги и поддерживает отправку алертов, если сервер не отвечает. Из-за специфики фронтенда Gatus (он не умеет работать из подкаталога типа /gatus), мне пришлось перенести его и wg-easy на полноценные субдомены gatus. и wireguard.

Для Gatus получился простой конфиг:

Для мониторинга аппаратных ресурсов удаленного и локального серверов была развернута связка node-exporter + cAdvisor. Все уведомления теперь приходят мгновенно в Telegram-бота. Чтобы избежать лавины одинаковых сообщений (например, при перезагрузке хоста), в Alertmanager настроена жесткая группировка и дедупликация событий. Также добавлен экспортер для AdGuard Home, выводящий статистику заблокированных запросов в Grafana.

Централизованные логи: Loki + Grafana Alloy

В релизе v1.3.0 в стек была добавлена централизованная система сбора логов Loki. Вместо устаревшего Promtail в качестве агента сбора я применил Grafana Alloy.

Он эффективно собирает логи со всех запущенных Docker-контейнеров, парсит их и передает в Loki. Теперь вся история событий, ошибок веб-сервера Nginx или падений внутренних приложений доступна в едином интерфейсе Grafana с возможностью удобной фильтрации через LogQL, что значительно упрощает отладку.

Конфиг Loki:

Конфиг Grafana Alloy: (локальный конфиг)

Интерфейс: переход на Homepage

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

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

Заключение

Постарался подробно рассказать о структуре проекта и как я к этому пришел, очень много я не добавил, если пост зайдет, то я обязательно более подробно пройдусь по некоторым моментам: как я настраивал Matrix и на каком моменте я решил его убрать, как собирал локальный amnezia контейнер-клиент, что нового я добавил в релизе 1.4.0 и другое.

Также я перешел с manage_deploy.sh на отдельный GUI клиент, который будет полностью автоматизировать процесс подготовки к deploy. (написан на Go Wails). Про это тоже возможно сделаю статью.

Вся кодовая база проекта, подробная документация, инструкции по развертыванию открыты и доступны для сообщества:

🔗 GitHub-репозиторий: https://github.com/canntstand/ServeHub-2

Это моя первая статья на этом сайте и в то же время первый личный проект, которому я отдал так много времени (3 месяца). Буду рад вашему фидбеку в комментариях!

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

Это было взвешенное решение. В какой-то момент общий фреймворк превратился в поле мерж-конфликтов, где ты уже не тесты пишешь, а разбираешься, кто чей page object сломал и почему Android отвалился после правки для iOS.

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

Как говорил один мой коллега, перефразируя классическое “вам шашечки или ехать”:

Ты сюда страдать пришёл или тесты писать?

После этого решение разделить Android и iOS на два проекта стало очевидным.

Сейчас у меня два отдельных проекта: mb-android-tests и mb-ios-tests. И знаете что? Это лучшее архитектурное решение за всё время на этом проекте. Серьёзно.

Контекст: что за проект и почему это важно

Финтех. Нативное приложение. Отдельные кодовые базы, Kotlin на Android, Swift на iOS. И UI там не «три кнопки и список», формы с десятками полей, кастомные контролы, WebView-вставки, платежи, валютные операции, бюджетные переводы. Ну вы поняли.

Стек: Java 21, TestNG, Appium 2.x, Selenide, Allure, Maven. CI на GitLab, крутится на Mac Mini. 5 Android-эмуляторов, 4 iOS-симулятора, 9 Appium-серверов — по одному на устройство.

Но это сейчас. А начиналось всё с одного жирного монолита.

Старый проект: 8 модулей и конструктор-монстр

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

8 модулей. Один mvn clean install. Все зависят от mobile-automation-framework, в котором живут DriverFactory, BaseTest, общие Page Objects и слой Steps.

А DriverFactory принимал 11 параметров. Одиннадцать, Карл.

Половина нужна только Android, другая только iOS. Но метод один. Потому что так более по программистцки, как написано в каждой второй статье про архитектуру автотестов.

Когда я работал один, было норм. Ты сам знаешь, от куда что идет.

А потом пришли люди.

Почему с людьми всё навернулось

Мерж-конфликты каждый божий день

Вот конкретная ситуация. Один человек правит LoginPage в общем фреймворке, добавляет метод для iOS, меняет локатор. Второй в тот же момент рефакторит этот же LoginPage под новую версию Android-приложения.

Мерж. Конфликт.

И тут начинается самое весёлое: какой локатор правильный? Для Android? Для iOS? Для обоих? Кто будет разбираться? Тот, кто мёрджит? А он вообще контекст понимает?

Это не единичный случай. Это было каждый день. Потому что mobile-automation-framework получился общим модулем, от которого зависят все. И все туда лезут. Постоянно.

Обновление одной библиотеки = блокировка всех

Решил обновить java-client с 7.x на 8.x. Нормальное желание — API поменялся, MobileElement удалили, capabilities переехали на типизированные Options.

Вот что произошло в реальности:

1. Меняю версию в parent pom.xml
2. MobileElement удалён → compilation error в DriverFactory, во всех DriverManager’ах
3. DesiredCapabilities → UiAutomator2Options / XCUITestOptions → переписываю все менеджеры
4. selenide-appium 1.x несовместим с java-client 8.x → обновляю до 2.x
5. selenide-appium 2.x требует Selenide 6.x → обновляю Selenide
6. Selenide 6.x ломает API page objects → переписываю page objects во всех модулях
7. А Selenide 6.x ещё и Java 8 не поддерживает → обновляю Java

Одна библиотека.

Задача «обновить одну библиотеку» превратилась в 50+ файлов, 4-5 каскадных обновлений, 2-3 недели работы. И всё это время develop нестабилен. Все заблокированы. Тесты не запускаются.

Две недели.

Из-за одной строчки в pom.xml.

Page Objects с if/else — это два page object в одном файле

Общие Page Objects звучат красиво на бумаге: пишем один раз, используем для обеих платформ. А на практике…

Это не page object. Это два page objects, запиханных в один файл через if/else. И так в каждом методе.

А сверху ещё слой Steps. Обёртки над page objects «для читаемости». И в steps тоже if (platform), потому что логика взаимодействия разная. На Android ты скроллишь через UiScrollable семантически, «прокрути до элемента с текстом X». На iOS координатами, «двигай палец из точки A в точку B». Один метод в steps, а внутри два разных мира.

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

Каждый работает в своём темпе и все друг другу мешают

У одного задача покрыть тестами новый экран на Android. У второго пофиксить падающие тесты на iOS. У третьего добавить тестовые данные.

Все трое лезут в mobile-automation-framework. Все трое меняют pom.xml, BaseTest, page objects. Каждый в своей ветке.

А потом мёрдж.

Технические причины, которые добили окончательно

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

Локаторы: работай с тем, что дают

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

В теории есть AccessibilityID единый локатор для обеих платформ. Звучит хорошо. А на практике? Попробуй попросить мобильных разработчиков расставить одинаковые accessibility-идентификаторы на сотнях экранов. На Kotlin и Swift. Одновременно. Они тебя вежливо пошлют, но скорее всего не вежливо. И будут правы, у них свои спринты, свои дедлайны, и твои автотесты в их приоритетах где-то между «поправить тень у кнопки» и «никогда».

Так что реальный выбор:

XPath - работает, но на iOS может быть тормозным. На Android через UiSelector быстро, нативно, надёжно. На iOS через NSPredicate тоже ок. А «универсальные» XPath типа //*[@text='Войти' or @label='Войти'] это путь к боли, потому что Page Source на двух платформах два совершенно разных XML-дерева.

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

OpenCV - есть ещё вариант с распознаванием элементов по картинке. Для некоторых кейсов реально выручает. Но это отдельная тема на целую статью, может напишу потом.

Суть в том, что «напиши один локатор и работай на двух платформах» это миф. Page Source на Android это android.widget.Button с resource-id. На iOS XCUIElementTypeButton с name и label. Разные типы элементов, разные атрибуты, разная глубина вложенности. Разные миры.

StaleElementReferenceException — «подарок» от iOS

Android рендерит UI через Choreographer синхронно с VSYNC. Элемент появился → стабилен → кликаем.

iOS рендерит через CoreAnimation с неявными анимациями. Элемент есть в дереве, но ещё анимируется. Формально кликабелен, фактически хрен.

Стандартный WebDriverWait с elementToBeClickable это не ловит. Элемент «кликабелен» по мнению Appium wait завершается. А потом click() падает, потому что DOM изменился между вызовами.

На Android этой проблемы нет вообще. Тот же тест, тот же wait, тот же код зелёный на Android, красный на iOS. Один и тот же метод, два разных результата. И это не баг это фундаментальное различие платформ.

Кастомные wait-стратегии для iOS отличаются от Android принципиально. Пихать их в один фреймворк строить leaky abstraction, которая протекает на каждом шаге.

Жесты — два разных мира

Свайп вниз на Android:

Свайп вниз на iOS:

Чувствуете разницу? И даже длительность свайпа важна: на Android 200мс это нормальный скролл. На iOS 200мс это fling, и элемент улетает за экран.

«Кроссплатформенная» обёртка для скролла функция на 40 строк с двумя ветками if (platform), внутри каждой и ещё if для performSwipeDown() vs performSwipeUp(). На 50+ экранах таких обёрток, которых десятки.

И каждая место для бага.

Решение: разделяй и властвуй

Решение было болезненным. Я реально откладывал, потому что казалось, что это шаг назад. Дублирование кода, нарушение DRY, всё такое. Мозг сопротивлялся.

А потом я просто сел и разделил.

Никаких общих page objects. Никаких общих steps. Никакого общего DriverFactory с 11 параметрами. Каждый проект со своим pom.xml, свои зависимости, свой BaseTest, свои локаторы.

Что осталось общего: подход к структуре (Maven + TestNG + Allure), CI-шаблоны, принципы организации. Но не код. Код полностью раздельный.

Что поменялось на практике

В Android-проекте DriverManager типизирован под AndroidDriver. В iOS под IOSDriver. Не AppiumDriver<MobileElement> с кастами и проверками, а конкретный тип для конкретной платформы. IDE подсказывает только релевантные методы. Компилятор ловит ошибки на этапе сборки, а не в рантайме.

BaseTest принимает ровно те параметры, которые нужны. Android: deviceName, platformVersion, udid, appPackage, appActivity, systemPort, serverUrl, appPath — 8 штук, все релевантные. iOS: deviceName, platformVersion, udid, appPath, serverUrl, wdaLocalPort — 6. Никаких @Optional("systemPort") со строкой “systemPort” в качестве дефолта.

А мерж-конфликты?

Когда один человек работает в mb-android-tests, а второй в mb-ios-tests то они вообще не пересекаются. Разные репозитории. Конфликт невозможен физически.

Обновление java-client в Android-проекте не затрагивает iOS. Хочешь обновить, обновляй. iOS продолжает работать на старой версии.

Добавить новый параметр для iOS? Меняешь BaseTest и testng.xml в iOS-проекте. Android даже не узнает.

Это прям кайф.

А как же дублирование кода?!

Конечно, конечно. Первый вопрос, который задают: «Но ведь ты пишешь тесты дважды!»

Нет.

Я пишу каждый тест один раз и без костылей. Без if (platform) в каждом методе. Да, для одного и того же экрана есть два теста, один для Android, один для iOS. Но каждый из них чистый, понятный, заточенный под свою платформу.

В старом варианте я тоже «писал один раз», а потом тратил столько же времени на поддержку if/else, мерж-конфликты и каскадные обновления. «Экономия» на создании оборачивалась переплатой на поддержке. С процентами.

Когда кроссплатформа всё-таки ок

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

Приложение простое, пара экранов, стандартные контролы, минимум кастомного UI.

UI реально идентичен на обеих платформах. Бывает, наверное.

Команда из одиного человека. Сам пишешь, сам мёрджишь, сам разруливаешь. Голова справляется.

Минимум жестов. Нет сложных свайпов, drag-and-drop, pinch-to-zoom.

Если у тебя финтех, банк, enterprise-приложение с сотнями экранов, кастомными контролами и тремя+ QA, то два проекта дешевле. Не в строках кода, а во времени. В нервах. В часах, потраченных на мерж-конфликты вместо написания тестов.

Итого

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

Кроссплатформенный фреймворк на Appium для сложного нативного приложения часто оказывается иллюзией экономии.

В следующей статье покажу, как у нас устроена инфраструктура для 9 параллельных устройств на одном Mac Mini: порты, bash скрипты, Appium серверы и workaround’ы, которых нет в документации. Спойлер: там тоже всё не совсем как в гайдах.

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

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

Причины этого понятны:

• Рынок ИБ испытывает серьезный кадровый дефицит, и найти опытного аналитика SOC, специалиста по расследованию инцидентов или эксперта по threat hunting становится все сложнее.
• Бизнес постоянно ищет способы повысить эффективность и сократить расходы.
• Вендоры заинтересованы в том, чтобы показать свои продукты максимально инновационными.

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

Но сначала уточним…

Что сегодня называют ИИ в ИБ

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

№1. Классические правила корреляции

Они присутствуют, к примеру, в SIEM-системах. SIEM-система может сработать, если пользователь вошёл в сеть ночью, получил административные права и начал выгружать данные. Но никакого искусственного интеллекта в них нет, а есть заранее заданные правила.

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

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

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

№2. Машинное обучение

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

Я сам экспериментировал с ML-модулем в одном из решений: подключили, обучили, запустили в пилот. Вендор обещал «снижение шума на ХХ процентов» и раннее обнаружение сложных атак.

Первые две недели только и разбирали срабатывания. Да, система честно находила аномалии: кто-то зашёл с нестандартного устройства, кто-то скачал чуть больше обычного. Но из 1000 алертов за неделю реальными инцидентами оказались ровно два. Остальное — это были легитимные процессы: работа аутсорс-команды, временные права и пр.

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

№3. Генеративный ИИ

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

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

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

А «предвыборные обещания» вендоров утомляют. Но не потому, что я против прогресса, а потому, что они создают иллюзию безопасности — и эта иллюзия опасна.

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

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

Где маркетинг пока опережает технологии

Ниже — четыре главных «обещания», которые я слышу слишком часто.

Обещание №1. ИИ сам найдет неизвестные атаки

Это один из самых популярных тезисов на рынке, и формально он не является ложью, так как современные решения класса UEBA, NDR, XDR и некоторые SIEM действительно способны выявлять аномалии, которые сложно обнаружить вручную.

Представим ситуацию:

• Сотрудник бухгалтерии никогда не подключался к корпоративной сети ночью.
• Он не использует PowerShell.
• Он не работает с серверами.

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

Однако есть важный нюанс. Система выявляет аномалию, а не атаку. Возможно, это злоумышленник. А возможно, сотрудник ИТ-службы временно использовал учётную запись для проведения работ.

Именно поэтому окончательное решение всё равно принимает аналитик.

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

А реальность оказалась банальнее: обычный рабочий процесс, просто оформленный как атака. Да, система поймала аномалию и формально была права. Но реакция на неё могла стоить компании простоя, срыва отчётности и нервотрёпки всей команде.

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

Обещание №2. Автоматическое расследование сложных инцидентов

Многие производители заявляют, что их ИИ способен самостоятельно расследовать инциденты. Частично это правда.

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

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

• какие системы критичны;
• какие подрядчики сейчас работают на объекте;
• какие последствия вызовет отключение оборудования.

Без этого контекста расследование невозможно завершить автоматически.

Обещание №3. ИИ заменит аналитиков SOC

Ооо, это одно из самых популярных заблуждений!

Причина его популярности понятна — SOC испытывают постоянную нехватку кадров, а атаки усложняются. Но если посмотреть на реальные проекты, становится очевидно: сегодня ИИ выступает скорее помощником аналитика.

Например, современные платформы могут автоматически:

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

Всё это серьёзно снижает нагрузку на специалистов.

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

• Можно ли отключить сервер прямо сейчас?
• Сколько клиентов потеряют доступ к сервису?
• Есть ли резервная площадка?
• Какие финансовые потери возникнут в случае остановки?

Ответов на эти вопросы в логах нет.

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

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

Обещание №4. Разработка стратегии безопасности

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

Однако модель не знает:

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

В итоге получится хороший шаблон. Но стратегия безопасности всегда требует участия человека.

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

А вот начинаешь копать под реальные процессы — и всё рассыпается, потому что модель не знает, что у нас аутсорс-разработка, часть команд работает в часовых поясах +7, бюджет на ИБ ограничен, а инфраструктура требует отдельного контура с шифрованием. Если бы внедряли всё это вслепую, получили бы либо неработающие процессы, либо постоянные конфликты между безопасностью и бизнес-подразделениями.

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

Где ИИ действительно приносит пользу

Читая предыдущий раздел, может сложиться впечатление, что я концептуальный враг искусственного интеллекта. Это, конечно же, не так.

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

Антифрод

Если искать область, где технологии доказали свою эффективность, то это финансовый сектор.

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

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

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

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

Антифрод-система анализирует десятки факторов одновременно: локацию, тип операции, историю поведения клиента и прочее. И если, например, клиент банка пенсионного возраста в 13:00 оплатил продукты в магазине рядом с домом, а в 14:00 купил что-то на 180 000 рублей в интернет-магазине посредством только что установленного мобильного приложения с IP-адресом Нью-Йорка, то такая операция блокируется. И здесь, как никогда, полезен ИИ.

Разница между 2018 и 2026 годами огромна — это переход от «защиты по порогам» к «защите по профилю». И этот переход был не про маркетинг, а про реальную необходимость: угрозы стали умнее, и защита должна была стать умнее тоже.

Поведенческая аналитика

Ещё один хороший пример — системы класса UEBA.

Представим системного администратора:

• В среднем он скачивает около 200 МБ данных в день.
• Работает в стандартное время.
• Подключается только из корпоративной сети.

За неделю до увольнения он начинает регулярно заходить ночью и выгружает 40 ГБ архивов с файлового сервера.

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

Именно в таких сценариях машинное обучение показывает лучшие результаты.

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

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

Или другой пример. Аналитик получает сложное правило обнаружения атаки и просит систему объяснить его простым языком. Модель формирует понятное описание логики работы этого правила.

Это не выглядит революцией. Но экономия времени весьма заметна.

Корреляция больших объемов событий

И, пожалуй, самый успешный сценарий применения технологий.

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

Как отличить реальный ИИ от маркетинговой наклейки

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

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

Как отсечь маркетинг от инженерии на этапе покупки? Когда вы видите рекламный баннер ИБ-продукта с ИИ (который, кстати, тоже сгенерирован ИИ), какие вопросы нужно задать, чтобы не купить кота в мешке?

Есть несколько простых вопросов:

• Какая именно технология используется?
• На каких данных обучалась модель?
• Какие показатели улучшились после внедрения?
• Как эти показатели измерялись?
• Есть ли реальные кейсы заказчиков?

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

И в помощь также оставлю сравнительную таблицу: «Маркетинг vs реальность». Надеюсь, эти материалы помогут вам принять правильное решение.

Рабочий день разработчика в команде обычно начинается с проверки текущего состояния проекта. В трекере могли появиться комментарии к задаче, в pull request замечания от ревьюеров, а в CI могла упасть сборка. Иногда приоритет меняется из-за стоппера в соседней команде или ошибки, найденной во время тестирования.

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

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

Если задачу можно брать в разработку, перед первым коммитом стоит ещё раз проверить её содержание. В карточке должны быть указаны:

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

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

Как задача попадает в работу

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

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

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

Готовая к разработке карточка обычно содержит:

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

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

При работе спринтами готовые карточки обсуждают на планировании. Команда определяет цель спринта, оценивает доступные ресурсы и выбирает объём работы. После планирования карточка переходит в статус To Do. Теперь у разработчика есть понятная цель, согласованный объём и условия приёмки.

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

Что проверяет разработчик перед кодом

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

• где находится код, связанный с задачей;
• какие модули, интерфейсы и пользовательские сценарии изменятся;
• какие готовые компоненты можно использовать;
• зависит ли реализация от другой задачи или сервиса;
• потребуется ли feature toggle или A/B-тест;
• какие проверки нужно добавить или обновить.

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

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

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

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

Как проходит код-ревью

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

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

Ревьюеры проверяют:

• соответствует ли реализация требованиям задачи;
• корректно ли код взаимодействует с существующими модулями и интерфейсами;
• учтены ли изменения в соседних компонентах;
• добавлены ли необходимые тесты;
• проходят ли автоматические проверки.

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

Замечания оставляют в комментариях к конкретным строкам или участкам решения. Автор исправляет код, обновляет pull request и повторно запускает проверки. Если комментариев недостаточно для обсуждения сложной реализации, участники созваниваются и разбирают решение вместе.

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

Как задачу тестируют

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

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

Тестировщик проверяет соответствие условиям приёмки, работу связанных компонентов и регрессионные сценарии. Быстрые автоматические проверки запускаются в CI, а ресурсоёмкие UI-тесты могут выполняться по расписанию или перед релизом.

Найденная ошибка возвращает карточку в статус Reopen. Разработчик исправляет код, CI выпускает новую сборку, и проверка запускается повторно. После успешного тестирования задача получает статус готовности к релизу и связывается с нужной версией продукта.

Как команда готовит релиз

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

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

Перед выпуском срабатывают quality gates:

• проект успешно собирается;
• юнит-тесты проходят;
• статический анализ не находит критических проблем;
• регрессионные и UI-тесты завершаются успешно.

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

Дальнейший процесс зависит от настроек CD. При Continuous Delivery готовая сборка ждёт ручного подтверждения выпуска. При Continuous Deployment изменение автоматически отправляется в прод после прохождения всех проверок.

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

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

Что происходит после выхода в прод

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

Команда отслеживает:

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

Набор метрик зависит от цели изменения. Для нового пользовательского сценария можно смотреть количество открытий, завершённых действий и выходов на отдельных этапах. Если фича выпущена в рамках A/B-теста, команда сравнивает поведение контрольной и тестовой групп.

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

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

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

Как рабочие встречи связаны с задачей

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

Основные встречи связаны с процессом так:

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

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

Итого

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

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

Теория — это база. Практика — это старт

На рынке IT сложилась парадоксальная ситуация: при кажущемся перенасыщении младшими специалистами и массовых выпусках курсов по Python, отрасль остро ощущает дефицит действительно квалифицированных кадров. Но это касается не тех, кто умеет писать простые веб-сервисы или верстать лендинги. Речь — об инженерах-разработчиках, которые понимают, как создавать сложные вычислительные системы, как проектировать микросхемы, как устроены сети 5G. Таких специалистов крайне не хватает: по оценкам правительства, в ближайшие пять лет стране потребуется более 1,5 млн инженеров, включая IT-разработчиков.

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

Чтобы помочь студентам получить больше практического опыта ещё во время учёбы, мы создали свои образовательные траектории в МФТИ, ИТМО, МИЭТ, ВШЭ и СибГУТИ и активно развиваем проектную работу во многих других ведущих вузах страны. Потому что считаем, что готовить инженеров нужно не теорией, а практикой, реальными задачами и живым общением с теми, кто каждый день создаёт сложные технологические продукты.

Ваш шанс: реальный опыт и работа в YADRO

Наши образовательные программы помогают сделать следующий шаг от теории к практике.

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

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

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

Востребованные навыки. Мы учим тому, что реально нужно: системному программированию на C, C++, Go, Verilog и ассемблере, проектированию микросхем на базе открытой архитектуры RISC-V, современным стандартам связи — LTE, 5G, помехоустойчивому кодированию (полярные коды, турбо, LDPC) и моделированию приёмных и передающих трактов. Это актуальные компетенции, которые останутся с вами после программы и будут востребованы на рынке в целом.

Магистратура: путь в глубину инженерии

МФТИ + YADRO: «Телекоммуникационные сети и системы». Новая магистерская программа-2026 на кафедре мультимедийных технологий и телекоммуникаций МФТИ — для тех, кто хочет разбираться в беспроводных сетях не как пользователь, а как инженер. Акцент — на физическом уровне беспроводных систем: от принципов работы до реальных исследований. Студенты выбирают темы для научных работ под свои задачи и занимаются ими в связке с практикой. Никакой оторванной от жизни теории — только то, что действительно пригодится.

МИЭТ + YADRO: «Вычислительные системы и электронная компонентная база». Хотите научиться проектировать микросхемы? Тогда вам сюда. Программа готовит специалистов по сквозному проектированию высокопроизводительных вычислительных систем и систем на кристалле (СнК), в том числе на базе открытой архитектуры RISC-V.

Обучение делится на три трека: RTL-проектирование, верификация цифрового дизайна и топологическое проектирование. На каждом из них студенты работают над реальными проектами в лаборатории Передовой инженерной школы МИЭТ. Самое крутое: лучшие командные проекты могут быть изготовлены в виде реальных микросхем на отечественной фабрике. Студенты получают стипендию от YADRO, а лучшие из них после первого года обучения могут стать частью нашей команды.

МФТИ + YADRO: «Микропроцессорные технологии». Это программа для тех, кто хочет разобраться в процессорах до последнего транзистора. Готовим инженеров для разработки микропроцессоров — одного из самых сложных и стратегически важных направлений. YADRO выступает базовым предприятием для МФТИ, давая студентам доступ к своим R&D-центрам и живой экспертизе.

МФТИ + YADRO + БЮРО 1440: «Промышленная разработка ПО». Трёхстороннее партнерство объединяет академическую базу МФТИ, индустриальный опыт YADRO и экспертизу БЮРО 1440 в области телекоммуникаций. Программа нацелена на подготовку промышленных разработчиков ПО, процессоров и операционных систем. Если вам интересно, как создают софт, который работает на оборудовании в промышленных масштабах, — это ваш выбор.

ИТМО + YADRO: «Инструменты разработки и анализа программ» — для хардкорных программистов. Здесь преподают ведущие исследователи из лучших университетов России. Студенты изучают методы конструирования компиляторов, статический анализ ПО, фаззинг программ, формальную верификацию и системное программирование.

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

Бакалавриат: фундамент для будущих лидеров

СибГУТИ + YADRO: «Программное обеспечение инфокоммуникационных систем». Обновленная программа, на которую в этом году наберут 100 первокурсников. Специализация — разработка ПО для систем мобильной связи: 4G, 5G и сетей будущих поколений. Абсолютно все студенты проходят производственную практику в ИТ-компаниях, до трети из них продолжают работу на оплачиваемых стажировках. Более 30% преподавателей — действующие разработчики из индустрии.

НИУ ВШЭ (СПб) + YADRO: «Компьютерные технологии, системы и сети». Программа, запущенная в 2024 году. Готовит специалистов на стыке теории и практики в области инфокоммуникаций. Студенты изучают алгоритмы, современные стандарты связи, помехоустойчивое кодирование, программируют на C, C++, Go и Verilog. Проектная деятельность — совместно со специалистами YADRO и на базе Научной лаборатории Интернета вещей и киберфизических систем. Выпускники идут в разработку, системный анализ, исследования. На программе — 20 бюджетных и 40 платных мест.

ИТМО + YADRO: «Беспроводные технологии». Бакалавриат от Нового физтеха ИТМО — это не стандартная программа, а пространство для реализации идей. Начиналось всё с небольшой лаборатории в 2009 году, а сегодня это уже масштабный научно-образовательный центр. Студенты осваивают инженерные навыки и превращают свои задумки в реальные проекты под руководством опытных наставников. А когда идея созревает, им помогают найти финансирование от научных или индустриальных партнёров.

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

Не расходы, а капитал

Мы вложили более 70 млрд руб. собственных инвестиций в развитие технологий и производство. Но технологии делают люди, и без специалистов, которые в них разбираются, всё это железо останется просто железом.

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

Государство даёт стандарты, бизнес — практику

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

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

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

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

Если вы сейчас выбираете свой профессиональный путь, возможно, одна из наших образовательных программ станет его частью. Подробнее — на сайтах вузов-партнёров и на сайте YADRO Образование.

Реклама. Рекламодатель: ООО «КНС ГРУПП», ИНН 7701411241, erid: 2W5zFGrvDRj

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

Деструктуризация — инструмент, а не норма. Её стоит применять там, где она правда упрощает код, а не просто экономит символы.

Объект хранит контекст. project.status понятнее, чем голая переменная status, особенно в больших функциях.

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

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

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

Деструктуризация — не религия

Несколько лет назад Мэтт Смит деструктурировал почти всё: объекты, пропсы, параметры, возвращаемые значения. Если встречался объект — он его раскладывал. Это перестало быть осознанным решением и превратилось в привычку: так пишет «современный JavaScript».

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

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

Не бойтесь повторов

Один из самых распространённых паттернов — вынесть поля из объекта, а потом передать их как пропсы в компонент:

С этим ничего не случилось. Но сегодня автор с большей вероятностью напишет так:

Да, здесь повторяется post. Но когда он вернётся к этому коду через месяц, ему не придётся вспоминать, откуда взялись title или author. Контекст остаётся на виду.

Объект несёт контекст

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

А сто строк ниже встретили такой код:

Моментальная пауза: «archived»… что именно? Сравните с вариантом, где объект сохраняет свою форму:

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

Вложенность лучше раскрывать поэтапно

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

Автор предпочитает писать иначе:

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

Деструктурируйте позже, а не раньше

С параметрами компонентов ситуация похожа. Для маленьких компонентов деструктуризация пропсов отлично работает:

Но по мере роста компонента автор чаще пишет так:

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

Каждая переменная — цена для читателя

Каждая локальная переменная просит читателя запомнить ещё одно имя. Иногда это стоит того, иногда — нет.

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

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

Когда деструктуризация всё ещё уместна

Всё вышесказанное — не аргумент против деструктуризации. Автор по-прежнему применяет её постоянно.

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

Объект существует всего несколько строк, поэтому автор не чувствует, что теряет контекст. Иногда имеет смысл даже переименовать извлечённое свойство: const { status: projectStatus } = project;.

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

Разница в том, что автор больше не деструктурирует просто потому, что объект существует.

Главный вопрос

Автор всё ещё любит деструктуризацию. Есть множество мест, где она заметно очищает код. Просто он больше не хватается за неё автоматически.

Перед тем как убрать объект, он спрашивает себя: удаление объекта действительно облегчает понимание или просто делает код короче?

Если деструктуризация даёт коду лучший словарь — автор её использует. Если она только экономит несколько символов — обычно нет.

Выводы

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

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

Источник: Matt Smith — I stopped destructuring everything

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

Современные LLM устроены так, что качество ответа зависит не только от модели, но и от того, какую информацию она получает в запросе. Поэтому по мере увеличения кодовой базы самым сложным для модели становится управление контекстом. Уже даже появился термин — context engineering (передаем привет промт-инжинирингу), и сейчас команды, работающие над агентами, все больше внимания уделяют правильному формированию контекста.

В статье рассказываем, почему теперь недостаточно просто написать хороший промпт.

Контекстное окно — не равно память

Многие разработчики воспринимают контекстное окно как память модели, но это не совсем так. У LLM нет долговременной памяти в привычном смысле. При каждом запросе модель получает некоторый объем информации: промтп, историю диалога, файлы, ссылки, сообщения пользователя и найденные в поиске части кода. Это превращается в последовательность токенов, которая называется контекстным окном.

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

Если нужного файла нет в контексте — для модели он буквально не существует.

Размер окна — не единственная проблема

В базовой модели ChatGPT 5 — 16 000 токенов, в платных число доходит до 400 000. Если вы используете API-платформы, такие как RouterAI, то вам доступен 1 млн токенов — это примерно 750 000 слов. Вот как модели переводят слова в токены:

Действительно, миллион токенов — огромное количество, но есть важный нюанс: возможность прочитать миллион токенов совсем не означает, что модель способна одинаково хорошо использовать каждую их часть. Это подтверждает исследование Lost in the Middle 2023 года: авторы показали, что модели с большим контекстом лучше всего обрабатывают информацию, которая находится в начале или конце входного текста, а то, что в середине, можно сказать, ей упускается.

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

Почему большие проекты особенно сложные

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

Здесь важно учитывать, что разработчик выстраивает архитектуру и карту проекта постепенно (и зачастую не в одиночку), а модель вынуждена анализировать ее практически мгновенно. Следовательно, чем больше проект, тем выше вероятность того, что важная зависимость банально не попадет в текущий контекст. Именно поэтому агенты начинают использовать старый UI, дублировать код, нарушать архитектуру или генерировать ломающие друг друга изменения.

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

«Так я могу взять и загрузить весь репозиторий»

Логика в этом есть, но на практике это почти никогда не работает. Во-первых, даже большое контекстное окно остается ограниченным: огромный репозиторий наверняка перевесит сотни тысяч и иногда миллионы токенов. Во-вторых, стоимость использования одной нейросети растет вместе с объемом входных данных: чем больше токенов загружается в модель, тем выше задержка и стоимость каждого запроса.

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

Как бороться с деградацией контекста

Может показаться, что современные AI-инструменты научились работать с огромными репозиториями — этим славятся GitHub Copilot, Claude и Cursor. Но на самом деле мало кто пытается загрузить в модель репозиторий целиком — поскольку важнее не размер контекстного окна, а качество информации. Именно поэтому нужно знать несколько архитектурных приемов.

Chunking

Это первый и самый очевидный прием: вместо хранения одного репозитория в виде одного огромного текста его заранее разбивают на смысловые фрагменты (chunks).

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

Поэтому в современных инструментах есть структурный чанкинг. В нем границы определяются элементами синтаксического дерева (AST — Abstract Syntax Tree): классом, функцией, UI, модулем, SQL-запросом и т.д. Такой подход позволяет сохранить логическую целостность кода.

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

И здесь на помощь приходит RAG.

Retrieval Augmented Generation

Сейчас RAG чаще ассоциируют с чат-ботами, которые ищут ответы в документации. Но принцип работает абсолютно так же и для кода.

Вот пример классической архитектуры:

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

Если в процессе retrieval нашлись не правильные файлы, даже GPT-5, Claude 4 или Gemini 2.5 будут уверенно рассуждать на основе неверных данных. Поэтому современные агенты все больше напоминают поисковые системы, а не просто оболочку вокруг LLM.

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

Суммаризация

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

Реализовал новую версию UserRepository, обновил миграцию, синхронизировал тесты с новой схемой.

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

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

Когда большой контекст необходим

Вот основные кейсы, когда переход на модель с большим контекстным окном полностью оправдан:

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

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

Что делать, если одной модели недостаточно

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

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

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

Итоги

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

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

Редакция Tproger недавно была нескольких таких ивентах и на партнёрском дне Диасофт пообщалась с членом правления Диасофт и директором по работе с партнёрами Александром Сахаровым. Мы поговорили о том, почему агентская разработка в её нынешнем виде — тупик, как строить эффективные AI-процессы разработки, почему фреймворк теперь важнее модели и что нового в AI-обновлении платформы Digital Q.

Digital Q — российская low-code экосистема разработки от «Диасофт» с готовым «заводом» инструментов для сборки корпоративных приложений: от проектирования бэкенда, дизайна интерфейсов до DevOps. В мае 2026 года вышла AI-driven версия, где искусственный интеллект встроен в саму платформу — он проектирует архитектуру, генерирует код, фронтенд и бизнес-процессы по человекочитаемой спецификации, оставляя разработчику работу с замыслом, а не с рутиной.

AI добрался до фундамента

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

— Главный сдвиг — это то, что AI добрался до вещей, которые казались незыблемыми. ERP-системы — это же фундамент крупного предприятия. И мы своими глазами видим, как крупные компании переходят на вайб-кодинг ERP. Звучит страшновато, но это факт, это происходит не в стартапах, а в очень больших организациях. Банки, промышленность, энергетика — везде одно и то же.

А шум — это вера, что AI всё решит сам по себе. Что можно купить лицензии Copilot, посадить за них разработчиков и они вам начнут производить продукты в десять раз быстрее. Нет, не начнут. Точнее, начнут, но счета вас очень неприятно удивят.

От агентов к AI-native платформе

Агентская разработка как самостоятельный подход не работает. Не масштабируется. Подход должен быть AI-native

— Вы на сцене показывали, как обновился Digital Q с декабря. Что конкретно поменялось за эти полгода?

— В декабре, на зимнем партнёрском дне, мы представили платформу Digital Q.GPT — на ней можно реализовывать агентский workflow. Интеграция со всеми LLM-моделями, экосистема построения агентов, мультиагентные системы. На тот момент это было супер актуально.

К маю выяснилось, что этого недостаточно. За последние шесть месяцев все — Anthropic, Google, Gartner, Amazon, Сбер на ЦИПР — пришли к одному и тому же выводу: агентская разработка как самостоятельный подход не работает. Не масштабируется. Подход должен быть AI-native, то есть AI вшит в саму экосистему разработки, а не прикручен сбоку отдельными агентами.

— А что плохого в агентах?

— С агентами ничего плохого, они нужны. Плохо, когда вся разработка строится только вокруг них. Если кто-то хочет писать агенты — пожалуйста, в Digital Q.GPT весь функционал остался: workflow, мультиагентные системы, всё это работает. Но это уже не центральная история. Центральная история теперь — единая экосистема, в которую AI встроен на каждом этапе процесса.

Три способа потерять деньги на AI

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

— Давайте про антипаттерны. Вы на сцене перечислили целый список — что точно делать не надо. Какой из них самый болезненный?

— Самый болезненный — вендорлок на конкретную LLM. Если вчера вы платили 20 долларов на разработчика в месяц, завтра это 100, послезавтра 200. Скоро будет дороже, чем один разработчик в месяц. И весь ваш контекст — спецификации, история, наработки — лежит у этой модели. Вы заложник. Они вам говорят: «не парьтесь, весь контекст у нас, всё будет хорошо». Хорошо у них будет, а у вас потом будут проблемы.

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

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

— Как можно решить эти проблемы?

— Главный тезис: фреймворк важнее модели. Они это называют harness, мы называем экосистема разработки. Есть термины IDP — Integrated Development Platform, IDE — Integrated Development Environment. Суть одна. Ваш фреймворк должен быть локально у вас, весь контекст — локально у вас, модели должны быть взаимозаменяемые. Тогда вы можете переключаться между ними и управлять стоимостью.

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

Как теперь устроена разработка

— Вы говорили про два контура разработки. Объясните для тех, кто услышит об этом впервые.

— Раньше был один контур: ТЗ — постановка — кодирование — тестирование — релиз. Долго, последовательно. Цифровая трансформация это ускорила: годы превратились в кварталы и месяцы. Но всё равно один линейный процесс.

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

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

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

— Это та же мысль, что и про вендорлок, по сути?

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

— Вернёмся к Digital Q. Как она теперь устроена? Если разобрать на компоненты — что там лежит?

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

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

Разработчик всегда идёт на самую дорогую модель — она же лучшая. И запускает её сто раз в день. Ему кажется, что это бесплатно. Извините, не бесплатно.

— Почему вы так настойчиво возвращаетесь к теме денег? Ведь все маркетинговые материалы AI-вендоров обещают именно экономию.

— Потому что это самая опасная иллюзия сейчас. Uber, пытаясь сэкономить на разработчиках, потратил больше трёх миллиардов долларов на AI-генерацию кода. Японская компания за несколько месяцев потратила 500 миллионов долларов вместо тех людей, которых сократили. Долларов, не рублей. И это уже не теория, это свежие кейсы 2025–2026 годов.

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

— И как вы с этим боретесь технически?

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

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

— Расскажите про демо с CRM. Вы показывали, как из 400-страничного ТЗ получается работающее приложение. Это правда один день двух человек, или там есть нюансы?

— Один день двух человек — это правда. Нюансы есть, конечно. Главный: это не black box, который сгенерил вам что-то непонятное. Это полностью оснащённый артефактами IT-проект. Можно пойти и сдать любому госзаказчику по ГОСТу. Полная документация — техническая, пользовательская, финансовая. Полный набор описанных бизнес-процессов. Полный набор тестов, включая тесты на уязвимости.

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

Дальше прорисовывает архитектуру бэкенда. Здесь критически важный момент: она смотрит на репозиторий и решает, что писать с нуля, а что переиспользовать. У неё в инструкциях жёстко зашито: инфобез не писать, использовать готовый. Логирование не писать. Справочники, типовые штуки — не переписывать. Только то, что реально новое.

— А фронтенд?

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

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

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

— Вы говорили, что AI-агенты теперь работают не только в коде, но во всех ролях — от аналитика до девопса. Как это устроено?

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

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

Что доступно прямо сейчас

С июля начинаем публиковать обновлённую версию. Можно скачать, развернуть, запускать.

— И эта экосистема действительно доступна партнёрам?

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

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

— Возвращаясь к началу разговора. Вы фактически заявляете, что Диасофт — единственный, кто отдаёт такую экосистему рынку. Это правда так, или маркетинг?

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

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

Если такого человека нет — никакая AI-генерация вас не спасёт. Будет только дороже и хуже.

— Какой главный совет тем, кто только сейчас задумывается о собственной AI-трансформации разработки?

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

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

Бонус: чек-лист «AI-разработка без иллюзий»

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

Чего точно не стоит делать:

— Сажать команду на одну LLM-модель — это вендорлок, и он будет дорожать;

— Разрешать разработчикам неограниченно гонять самую дорогую модель;

— Использовать AI только в кодировании, без интеграции в остальной процесс;

— Накупить разных инструментов и надеяться, что они потом «как-нибудь соберутся»;

— Сокращать разработчиков в расчёте на «бесплатные» токены.

Что стоит сделать:

— Держать экосистему разработки и весь контекст локально;

— Зашить в платформу переиспользование кода — половину нового модуля собирать из готового;

— Настроить лимиты: дешёвые модели для простых задач, перегенерация только изменённых частей;

— Разделить процесс на два контура — замысла (где работает человек) и исполнения (где работают агенты);

— Растить продуктовых инженеров — людей, умеющих формулировать задачу, а не только писать код.

Реклама. Рекламодатель: ООО «Диасофт», ИНН 7715560268, erid: 2W5zFJRM88q

Почему стать тимлидом — это не повышение, а смена профессии

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

Но в реальности часто всё по-другому. У тимлида есть свой список обязанностей:

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

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

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

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

Трек 1. Тимлид — если всё-таки хочется к людям

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

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

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

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

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

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

1. Сначала присмотритесь, чем на самом деле занят тимлид в вашей компании: возможно, вы представляете себе эту позицию неверно.
2. Затем скажите своему руководителю, что хотите попробовать.
3. Скорее всего, вам выдадут перечень базовых обязанностей, которые можно подхватить заранее, например починить давнюю процессную проблему команды.
4. Так вы примерите роль до формального назначения, и если через полгода станет ясно, что созвоны и координация вас выматывают сильнее любого легаси, откажетесь без потерь для карьеры.

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

Трек 2. Архитектор — рост в глубину без перформанс-ревью

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

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

Внутри самой профессии есть свои виды архитекторов:

1. Софтверный архитектор решает технические задачи: как скомбинировать компоненты, как интегрировать системы между собой. Бизнес-контекст на этом уровне знать необязательно, схема с базой, кэшем и очередью может обслуживать что угодно.
2. Солюшен-архитектор добавляет к этому бизнес-фокус. Ему приносят проблему на языке заказчика, например «падает конверсия» или «выходим на рынок с другим регулированием», и он переводит её в структуру работ, понятную командам. На этом уровне приходит осознание, что иногда лучшим решением оказывается таблица с формулами на общем диске, а вовсе не система на год разработки.
3. Матёрый солюшен-архитектор учитывает ограничения: бюджет, сроки, зрелость инфраструктуры, скиллы команды. Отличная технология без инженеров, умеющих её эксплуатировать, превращается в обузу, поэтому одинаковая бизнес-задача в двух компаниях даёт два разных решения.
4. Уровень выше подразумевает масштаб в десяток команд и стратегический горизонт: решения должны оставаться валидными десять лет, а конфликты стейкхолдеров приходится разруливать самому, потому что эскалация наверх заканчивается ответом «разбирайтесь сами».

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

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

Трек 3. QA — горизонтальный манёвр, который недооценивают

У разработчиков к этому треку предвзятое отношение. QA многие держат в голове как стартовую площадку для входа в отрасль, поэтому движение туда после нескольких лет разработки выглядит понижением. Такое представление опирается на образ тестировщика, который вручную прокликивает формочки по чек-листу. Современное QA устроено сложнее: инженер по качеству проектирует стратегию тестирования, строит автоматизацию, встраивает проверки в CI/CD и влияет на процессы всей команды, включая то, в каком виде задачи вообще доезжают до разработки.

Бэкграунд разработчика конвертируется здесь напрямую, и лучше всего в автоматизации. Автотесты пишутся на тех же языках, на которых вы уже работаете: Java, Python, JavaScript, C#. По сути автоматизатор разрабатывает отдельный программный продукт, у которого есть своя архитектура, свои паттерны и своё легаси, если писать его небрежно. Умение проектировать код, разбираться в чужих API и настраивать пайплайны сразу выделит вас среди коллег, пришедших в QA с нуля.

Кроме автоматизации, инженерный опыт открывает для вас новые специализации:

• нагрузочное тестирование, где нужно понимать, как система ведёт себя под трафиком и где искать узкие места;
• security-тестирование, где пригодится знание типовых уязвимостей и того, как разработчики их создают;
• инфраструктура качества: тестовые окружения, генерация данных, интеграция проверок в сборку;
• процессная часть, когда вы помогаете команде ловить дефекты на этапе постановки задач, а не после релиза.

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

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

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

Как выбрать трек и что делать

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

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

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

Примерять треки удобнее всего там, где проектов много и они разные. В сервисных компаниях вроде Centicore Group, которая занимается заказной разработкой, контролем качества ПО, ИТ-консалтингом и модернизацией легаси-систем, в которой за 13 лет накопилось более 500 выполненных проектов, и на такой ротации можно попробовать роль автоматизатора, архитектора или тимлида без смены работодателя: закончился один проект, на следующем берете другую зону ответственности. Посмотреть, с какими задачами там работают, можно на сайте Centicore.

***

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

У всех направлений есть два главных правила:

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

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

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

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

Почему не курсы и не стартап

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

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

1. Самый прямой вариант — запустить проект самому. Евгений этот путь не выбрал: если нет базы, самостоятельный запуск быстро превращается в оплату собственных ошибок. Можно много работать, долго пилить продукт и слишком поздно понять, что бизнес из этого не собирается.
2. Второй вариант — пойти работать в стартап. Формально это ближе к реальности: рядом фаундеры, гипотезы, продукт, пользователи, дедлайны. На практике разработчик в стартапе часто остаётся исполнителем. Он закрывает задачи, пишет код, чинит конкретные проблемы, но не всегда участвует в решениях, где определяют рынок, бизнес-модель и стратегию проекта.
3. Третий вариант — пройти все курсы по предпринимательству на онлайн-платформах (Яндекс.Практикум, Skillbox, Нетологии и т.д.) Евгений так уже пробовал: регистрировался, начинал проходить программы, но часто не заканчивал. Причина была в формате: отдельные курсы дают куски знаний, но не собирают вокруг человека среду, расписание, группу, преподавателей и обязательство довести проект до результата.

Он выбрал онлайн-магистратуру МФТИ как более строгий формат с понятным процессом и результатом: есть расписание, дедлайны, группа, преподаватели и постоянная привязка заданий к своей идее. В магистратуре вы будете два года проверять гипотезы, разбирать рынок, считать деньги, собирать бизнес-план и доводить проект до защиты.

Кто там учится

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

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

По данным программы, выпускники дальше работают продакт-менеджерами и руководителями проектов в высоких технологиях, становятся CEO и основателями технологических стартапов, занимают позиции CTO и руководителей R&D. Сюда идут не за тем, чтобы попробовать IT, а чтобы докрутить уже имеющийся инженерный, продуктовый или предпринимательский опыт до уровня проекта.

Как устроен процесс

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

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

В программе есть персональный ментор и 1000 часов работы над проектом. Это главный объём, который нужно учитывать до поступления. Магистратура забирает не только вечера на созвонах, а ещё время на исследования, расчёты, упаковку идеи, обсуждения с группой и подготовку проекта к защите.

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

Реальная нагрузка

Если нормально вникать в материалы, делать задания и двигать свой проект, реальная нагрузка выходит ближе к 20–25 часам в неделю. Два года учёбы при такой нагрузке превращаются примерно в 2000–2500 часов общей занятости, если считать по 50 учебных недель в год.

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

Где ломается

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

По одним предметам фидбек был сильнее, по другим запаздывал; с менторами опыт тоже различался: кому-то везёт больше, кому-то меньше. Преподаватели заняты, поэтому ждать, что они сами будут вытаскивать каждый проект, смысла мало.

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

Что окупается

Главная ценность программы держится на людях, с которыми студент работает два года, в магистратуре преподают люди с опытом в технологическом предпринимательстве, системном мышлении, праве и управлении: Вячеслав Чикин, Анатолий Левенчук, Артемий Малков, Андрей Бодиловский.

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

Третья часть — диплом МФТИ государственного образца со степенью магистра. Сам по себе диплом не делает человека предпринимателем. Зато он фиксирует, что студент прошёл двухлетнюю программу, защитил проект и получил формальный результат, который ценится больше набора разрозненных сертификатов.

Как поступить и сколько это стоит

Набор на программу 2026 года идёт летом. Заявления принимают с июня по август, обучение стартует 1 сентября 2026 года. Для поступления нужно пройти собеседование и вступительное испытание.

На 2026 год стоимость указана по семестрам: 445 500 рублей за семестр, всего четыре семестра. Для оплаты частями также есть образовательный кредит под 3% годовых.

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

Подать заявку можно на сайте программы: https://techpredonline.ru

Итого

Онлайн-магистратура МФТИ по технологическому предпринимательству имеет смысл для разработчика, у которого уже есть идея, проект или хотя бы нормальная заготовка для проверки. Программа даёт расписание, группу, преподавателей, ментора, проектную работу, диплом и двухлетний режим, в котором нельзя просто посмотреть пару лекций и исчезнуть.

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

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

Реклама. Рекламодатель: МФТИ, Физтех ИНН 5008006211, erid: 2W5zFJn2Et9

Но однажды в марте этого года прошла новость: Альфа заводит в контур GLM‑5 с плагином KiloCode для редактора кода. Руководители разработки в HR Tech раздали доступ 15 разным командам и попросили собрать на вайб-кодинге что-нибудь полезное — сервис каждая команда придумывала сама. И, что интересно, со мной в команде оказались такие же, как и я — лютые скептики. Видимо сделали специально, чтобы проверить, кто из нас первый сдастся (шутка!).

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

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

Первая проблема — а что вайб-кодить?

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

Я предложил конструктор процессов с визуализацией в духе Miro — штука, провал которой бизнес бы не убил. Маша зашла с другой стороны и захотела собрать сервис для рекрутеров прямо внутри Alfa People — но это оказалось слишком большой задачей.

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

Сроки поджимали с самого начала. Сперва релиз назначили на 1 апреля, потом сдвинули на 26 марта, а ещё через день — на 23-е.

На раскачку оставалась пара дней, но часть работы уже была сделана: коллеги провели discovery, собрали боли пользователей и описали минимальные решения. Всё это мы отдали GLM-5 с запросом «готовь бизнес-требования». Модель выдала черновик, Маша как продакт вычистила лишнее — можно было стартовать.

Первый прототип собирали «на коленке». Маша описывала интерфейс репликами вроде «хочу зелёную кнопку справа, при клике открывается модальное окно», GLM-5 генерировал HTML, а я потом прикручивал к этому бэкенд. Так родились 19 версий, и последняя стала основой финальной разработки.

Вторая проблема — никто не говорит про Git

Мы часто упускаем из виду базу. Курсы по вайб-кодингу учат писать промпты и собирать интерфейсы, но почти никто не говорит про Git. А зря: когда в команде работают не‑программисты, конфликты в ветках появляются на каждом шагу.

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

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

Третья проблема — нагрузка

Вторая проблема пришла со стороны инфраструктуры. Пилот одновременно проходили 15 команд, и все обращались к GLM‑5 через общий веб-чат. Днём модель выдавала всё медленно: ответ приходил через две-три минуты, и работать становилось невозможно.

Мы подстроились и переехали на ночь: кодили с 23:00 до 04:00, когда трафик падал и модель снова отвечала быстро. Маша уходила спать в три-четыре ночи, я сидел до часу, вставал в 8:00 — и снова садился за сервис. Позже коллеги с ИИ-платформы добавили приоритет для тех, кто работает прямо из редактора кода, но первое время выручали только ночные смены.

Четвёртая проблема — где ставить границы

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

Развязка случилась в последнее воскресенье перед дедлайном. В четыре утра Маша уснула прямо на созвоне, Костя ушёл спать, а я остался один доправлять последние баги руками — спорить с GLM-5 в чате уже не было сил. В понедельник в восемь утра я отдал сервис в поставку: релиз прошёл, оставалось закрыть три мелких корнер-кейса.

В тот же день GLM-5 ушёл на техобслуживание. Демо стояло в расписании на 17:00, KiloCode перестал работать, а в запасе было всего два часа на фикс багов. Помощи ждать неоткуда: Маша и Костя писать код без модели не умели, так что мне пришлось в одиночку бегать между фронтом и бэком.

За час до презентации я заглянул в логи и увидел, что ИТ-директор уже создал цель в сервисе и успел её отредактировать. Руки затряслись — первая мысль была про упавшую токенизацию. Но логи показали, что всё работает штатно: директор просто протестировал продукт до демо. Заодно выяснилось, что в проде заработал глобальный поиск по сотрудникам — фичу мы реализовали раньше, но к другим сервисам Alfa People ещё не подключали. Из-за маскирования данных в тестовой среде её толком не проверяли, а на проде она внезапно ожила.

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

Результаты были уже после первой недели: в «Моих целях» набралось 10 000 уникальных пользователей, они поставили 9240 целей и прикрепили к ним 981 задачу. Позже сервис забрали развивать другие коллеги — у моей команды «Подбор» хватало своих задач, и я отдал продукт, который считал перспективным.

Пятая проблема — без программистов вы не обойдётесь

Наша команда из меня, Кости и Маши была временной. Сейчас в моей постоянной команде «Подбор» работает шесть человек — после эксперимента их разбили на две подгруппы по трое, на фронтенд и бэкенд. Разработчики периодически меняются местами, чтобы держать процесс под контролем и подстраховывать аналитиков, тестировщика и продакта. Эксперимент с вайб-кодингом в HR Tech на этом не закончился — его продолжают.

Если бы задачу не поставили сверху, сам я вряд ли перешёл бы на кодинг с нейросетями так быстро. Скепсис у меня, честно говоря, никуда не делся, но стал другим. Теперь это скепсис с опытом: я знаю по конкретным задачам, где ИИ помогает, а где нет.

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

Сейчас я смотрю на GLM-5 как на ассистента. Типовые задачи, которые раньше съедали по часу, я теперь отдаю модели: нарисовать кнопку, выровнять форму, написать валидатор. Пока я на созвонах — ИИ верстает, пока копаюсь в бэкенде — тот правит фронт. Получилось вести два потока разработки одновременно, и это заметно разгрузило рутину.

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

Что я могу сказать тем, кто только начинает

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

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

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

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

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

Главный риск: обмануться быстрой победой

На следующий день после старта сайт уже работал. Интеграция с Apple Health подключилась с первого промпта, тренировки сотрудников отображались и ранжировались по системе начисления баллов.

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

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

Спроектируйте архитектуру раньше, чем напишете первый экран

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

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

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

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

Сначала бэкенд и контракт, потом клиенты

Соблазн делать клиентское приложение «по фиче» и откладывать бэкенд велик, особенно когда фронт оживает за секунды. Это прямой путь к расхождению версий, когда веб, iOS и Android начинают жить своей жизнью.

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

AI-тесты не заменяют ручное тестирование и фокус-группу

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

Автотесты Claude проверяют то, что поддается формализации. Правильно ли считаются баллы по заданному алгоритму, корректно ли обрабатываются зависимости, верно ли отрабатывают условные конструкции. За пределами их охвата остается всё, что происходит в реальной эксплуатации. Например, когда пользователь с конкретной версией Android и конкретными смарт-часами пытается загрузить тренировку, которую его трекер назвал иначе, чем ожидает система. Или когда два пользователя одновременно обращаются к одной записи. Это принципиальное ограничение автоматического тестирования, и оно не отменяет важности функциональных автотестов.

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

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

Как собрать AI-driven команду под такой проект

За три месяца сложилось понимание оптимального состава для подобного проекта:

• 1 архитектор — человек, который понимает, как обеспечить стабильность многопользовательского сервиса под нагрузкой;
• 2 продакт-инженера — берут на себя и проработку пользовательских сценариев, и собственно вайбкодинг;
• UX/UI-дизайнер;
• QA-инженер.

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

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

Что в итоге

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

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

Игнорирование в Git — это не магия, а просто набор шаблонов. Когда вы запускаете git status, Git сверяет имена файлов с тремя списками и решает, показывать их или нет. Важно: игнорируемый файл всё ещё лежит в рабочей директории, просто Git не предлагает его добавить в индекс.

• .gitignore — правила для всего репозитория, версионируются и делятся с командой.
• .git/info/exclude — локальные правила одного клона, не попадают в коммиты.
• ~/.config/git/ignore — глобальные правила для всех репозиториев на машине.
• git check-ignore -v filename покажет, какой именно файл игнорирует файл.
• Правильный выбор уровня избавляет команду от конфликтов и лишних правок .gitignore.

Три файла, которые говорят Git «не замечай»

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

.gitignore — общие правила репозитория

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

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

.git/info/exclude — личные правила для одного репозитория

Внутри каталога .git каждого клона есть файл info/exclude. Он устроен так же, как .gitignore, но не входит в коммиты. Это идеальное место для файлов, которые есть только у вас: черновики, личные заметки, экспериментальные скрипты, локальные дампы.

Сценарий простой: вы держите в репозитории файл notes.txt с личными пометками. Добавлять его в .gitignore не хочется — коллегам он не нужен, а в .git/info/exclude он исчезает из git status только на вашей машине.

~/.config/git/ignore — глобальные правила для всей машины

Третий уровень действует на все репозитории текущего пользователя. Если у вас macOS, вы наверняка устали видеть .DS_Store в выводе git status. Вместо того чтобы добавлять его в каждый .gitignore, проще вынести на глобальный уровень.

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

Вернуть значение по умолчанию можно командой git config --global --unset core.excludesFile.

Как проверить, кто именно игнорирует файл

Когда правил много, легко забыть, какой файл за что отвечает. Git предоставляет команду git check-ignore -v, которая показывает источник игнорирования: название файла с правилами, номер строки и сам шаблон.

Если файл игнорируется .gitignore, вывод будет начинаться с .gitignore; если локальным exclude — путь к нему; если глобальным ignore — путь в домашней директории. Если команда ничего не выводит, значит файл никто не игнорирует.

Полезно:
git check-ignore работает и с каталогами. Передайте путь к папке, чтобы узнать, почему она не попадает в индекс.

Когда какой уровень использовать

• .gitignore — правила, общие для всей команды: зависимости, сборочные артефакты, секреты.
• .git/info/exclude — персональные файлы внутри одного репозитория, которые не должны светиться в коммитах.
• ~/.config/git/ignore — файлы ОС и редактора, которые мешают в любом проекте на вашей машине.

Главный принцип: чем шире правило, тем реже его стоит менять. Глобальный ignore настраивается один раз при настройке рабочей машины, а .gitignore живёт вместе с проектом и развивается вместе с ним.

Выводы

Git предлагает не один, а три уровня игнорирования, и каждый решает свою задачу. .gitignore отвечает за командные договорённости, .git/info/exclude — за личный порядок в одном репозитории, а ~/.config/git/ignore — за чистоту рабочей машины в целом. Разделение уровней помогает не засорять общие правила личными исключениями и не тащить в коммиты то, что нужно только вам.

Хороший .gitignore защищает команду, а правильное использование exclude и global ignore защищает ваше собственное ментальное здоровье при работе с кодом.

Источник: Nelson Ameyin, «.gitignore isn’t the only way to ignore files in Git».

Попробуйте проверить свои репозитории: запустите git check-ignore -v на паре подозрительных файлов — возможно, вы найдёте правила, про которые давно забыли.

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

Selectel: серверные платформы с полным циклом разработки

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

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

От эксплуатации к разработке

Требования к новой платформе формируются на основе собственного опыта работы с железом. С 2008 года Selectel накопил большую экспертизу в эксплуатации серверов различных поколений и конфигураций и использует этот опыт при определении требований к новым платформам.

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

Собственная аппаратная архитектура

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

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

Платформа Selectel поддерживает процессоры Intel Xeon 6, память DDR5, интерфейс PCI Express Gen5, модуль доверенной платформы TPM 2.0, а также предусматривает установку современных сетевых адаптеров и ускорителей вычислений.

Для задач искусственного интеллекта и высокопроизводительных вычислений используются серверы форм-фактора 8U с несколькими GPU, тогда как платформы 1U и 2U применяются для виртуализации, корпоративной инфраструктуры, баз данных, облачных сервисов и других сценариев эксплуатации.

BIOS, BMC и управление платформой

Разработка аппаратной части ведется одновременно с развитием встроенного программного обеспечения.

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

Для управления оборудованием Selectel использует собственный интерфейс Selectel Management Interface (SMI), разработанный на базе OpenBMC.

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

Программный уровень платформы

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

От платформы к решению под конкретную задачу

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

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

Для CPU-интенсивных задач приоритетом становятся вычислительные ресурсы процессора и организация многопоточной нагрузки. Для систем хранения — производительность дисковой подсистемы и сетевых интерфейсов. При работе с GPU оцениваются баланс между центральным и графическими процессорами, пропускная способность PCI Express, требования к питанию и охлаждению. При необходимости проектируются конфигурации под storage- и backup-системы.

На этапе проектирования также анализируются особенности будущей инфраструктуры: тип рабочей нагрузки (CPU-bound, memory-bound, IO-bound или GPU-bound), требования к доступности и SLA, особенности электропитания, тепловыделения, размещения оборудования в стойке и существующей сетевой инфраструктуры.

Проверка гипотез до закупки оборудования

Для проверки используется Proof of Concept (PoC) — инженеры воспроизводят профиль нагрузки клиента на тестовом стенде, сочетая синтетические и прикладные тесты. Это помогает заранее оценить производительность, задержки, температурные режимы и запас вычислительных ресурсов.

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

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

Проверка совместимости и стабильности

После формирования конфигурации сервер проходит комплексную проверку.

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

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

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

Что отличает подход Selectel

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

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

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

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

Deckhouse: Kubernetes-платформа и экосистема для Cloud Native

Deckhouse — экосистема инструментов для разработки, доставки и эксплуатации Cloud Native-приложений. В основе — Deckhouse Kubernetes Platform (DKP), которая автоматизирует управление кластерами Kubernetes поверх любой инфраструктуры: публичные и частные облака, bare metal, закрытые контуры без доступа в интернет. Вокруг платформы выстроен набор продуктов — управление виртуализацией, хранение секретов, CI/CD, мониторинг — всё в одной экосистеме с общим API и интерфейсом.

Продукты разрабатываются и размещаются на территории РФ. Платформа поддерживает российские ОС: РЕД ОС, Astra Linux, ALT Linux. Deckhouse Kubernetes Platform CSE имеет сертификат ФСТЭК России №4860, платформа внесена в реестр российского ПО.

Что входит в экосистему

Deckhouse Kubernetes Platform (DKP) — ядро. Управляет кластерами Kubernetes, системным ПО на узлах, базовыми компонентами. После установки платформа готова к работе: автомасштабирование, мониторинг, мультитенантность — из коробки, без ручной сборки из отдельных компонентов.

Deckhouse Virtualization Platform (DVP) — управление виртуальными машинами и контейнерами из одного интерфейса. Масштабируется до 1000 серверов и 50 000 виртуальных машин. Поддерживает IaC-подход через открытый API, что позволяет автоматизировать развёртывание и управление средой полностью декларативно.

Deckhouse Stronghold — управление жизненным циклом секретов: пароли, ключи API, сертификаты, SSH-ключи, токены. Совместим с API HashiCorp Vault, что упрощает миграцию с него — без выгрузки секретов наружу через внешние утилиты. Поддерживает двойное шифрование через внешние HSM (AES + ГОСТ, AES + RSA), автоматическое резервное копирование и межкластерную репликацию.

Как устроен процесс работы

Установка и конфигурация

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

Развёртывание в закрытых контурах

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

DevSecOps-практики

Сквозное применение DevSecOps на всех этапах поставки: управление сетевыми политиками, аутентификация и авторизация, заказ TLS-сертификатов, аудит-логирование, изолированные контейнеры.

Для кого это полезно

• Техлиды и архитекторы получают платформу, которая закрывает инфраструктурный слой: не нужно собирать стек из отдельных компонентов — мониторинг, service mesh, хранение секретов, балансировка уже встроены.
• Разработчики получают сокращение времени подготовки среды разработки до 15 раз, единый UI и API для управления всей инфраструктурой, понятный CI/CD-конвейер. DVP позволяет использовать IaC для управления виртуальными машинами так же, как контейнерами — через манифесты.
• QA-инженеры и SRE работают с уже настроенным мониторингом из коробки, автоматическими алертами и механизмами восстановления.

Что отличает подход

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

Кластеры поддерживают любой тип инфраструктуры без изменения подхода к управлению: одни и те же практики работают в Yandex Cloud, в собственном ЦОД и на bare metal одновременно. В кейсе «Лемана ПРО» именно это позволило объединить кластеры из разных облачных провайдеров и дата-центров в единую инфраструктуру.

Высокая доступность из коробки: SLA 99,99% достигается за счёт отказоустойчивости компонентов платформы, геораспределённых конфигураций (Multicluster на базе Istio, MetroCluster) и fencing-механизмов для безопасного восстановления при сбоях узлов.

Техническая база

• Поддерживаемые ОС (host): Astra Linux SE, РЕД ОС, РОСА Сервер, ALT Linux, CentOS, Debian, Ubuntu
• Поддерживаемые ОС (guest в DVP): любые ОС на x86-64
• Интеграции: LDAP, OIDC, внешние HSM, аппаратные СХД (TATLIN, Huawei, HPE, NetApp), SCSI-протокол, LACP, VLAN
• API: открытый, совместим с HashiCorp Vault API (для Stronghold)
• Форматы дисков ВМ: VMDK, Qcow2, Raw
• Сертификация: ФСТЭК России №4860, реестр российского ПО

Управление и поддержка

Единый канал поддержки покрывает все продукты экосистемы. Для обучения работает Deckhouse Академия с курсами по платформе и инструментам безопасности. Обновления платформы приходят автоматически в выбранное окно обслуживания. Для знакомства с продуктами доступна 30-дневная пробная версия.

ELMA365 BPM: автоматизация бизнес-процессов на Low-code платформе

ELMA365 — Low-code BPM-платформа для оцифровки, автоматизации и оптимизации бизнес-процессов. В основе — процессный движок, который автоматически ставит задачи участникам, маршрутизирует процессы по заданной логике и собирает данные на каждом этапе. Моделирование ведётся в визуальном дизайнере по нотации BPMN 2.0 — без привлечения разработчиков. Сценарии и кастомная бизнес-логика пишутся на TypeScript с подсветкой синтаксиса и автодополнением прямо в интерфейсе.

Платформа разворачивается в облаке на серверах Яндекса — без установки дополнительных компонентов, всё работает через браузер. По данным TAdviser, ELMA BPM — самая внедряемая BPM-система в России и СНГ.

Продукт используют в корпоративной автоматизации: согласование документов, управление задачами и поручениями, электронный документооборот, CRM-процессы, КЭДО.

Как устроен процесс работы

Моделирование процессов

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

Формы и данные

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

Запуск и исполнение

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

Отладка и мониторинг

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

Быстрая оптимизация

Процессы редактируются без остановки уже запущенных экземпляров. Изменения вступают в силу сразу после публикации. Платформа поддерживает версионность процессов — можно откатиться к предыдущему состоянию, если что-то пошло не так. Это важно для компаний, у которых одновременно живут десятки «живых» процессов: по оценке ELMA, для компании в 500 человек таких процессов от 50 до 100, и каждый меняется со временем.

Для кого это полезно

• Разработчики и аналитики работают в среде с подсветкой синтаксиса, автодополнением и встроенным отладчиком — TypeScript-сценарии пишутся прямо в интерфейсе. Сторонние библиотеки и внешние системы подключаются через готовые скрипты и вебхуки. Стандартный API открывает возможности для интеграции с любыми внешними сервисами, веб-сайтами и базами данных.
• PM получает полную видимость по задачам и срокам: канбан, мониторинг процессов в реальном времени, автоматические уведомления при просрочке или ошибке. Перераспределение задач при отпусках и болезнях закрывается механизмом замещения — администратор назначает замещающего и выдаёт временные доступы.
• QA-инженеры могут использовать версионность процессов для контроля изменений и отладчик для проверки бизнес-логики до выхода в продакшн.

Что отличает подход

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

Версионность и редактирование «на лету» — принципиальная особенность для enterprise: процессы живут годами и постоянно меняются. ELMA365 позволяет управлять этим циклом без остановки операционной работы и без риска сломать уже запущенные экземпляры.

Интеграционная шина покрывает основные корпоративные сценарии: ЭДО через операторов ЮЗДО и Контур.Диадок, CRM с встроенной телефонией и мессенджерами через ChatDesk, КЭДО с электронной подписью, которая полностью легитимна и позволяет убрать бумажные носители.

Техническая база

• Язык сценариев: TypeScript (встроенная IDE с автодополнением и отладчиком)
• Нотация процессов: BPMN 2.0
• API: стандартный REST API для запуска процессов и управления ими из внешних систем
• Интеграции: ЭДО (ЮЗДО, Контур.Диадок), мессенджеры (ChatDesk), телефония, внешние БД и веб-сервисы через вебхуки и скрипты
• Развёртывание: облако (серверы Яндекс), браузерный интерфейс без установки компонентов

Управление и поддержка

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

Т1 Сфера: платформа полного цикла производства ПО

«Сфера» (SFERA — Scaled Framework for Enterprise Resilience and Agility) — платформа для управления разработкой, тестированием, эксплуатацией и поставкой ПО. Более 40 инструментов в одном контуре: таск-трекер, Git-репозиторий, CI/CD-конвейер, хранение артефактов, управление тестированием, мониторинг, документация. Платформа разрабатывается с 2020 года на основе опыта внедрения ИТ-конвейеров в крупнейших российских компаниях, включая банковский сектор.

В реестре российского ПО. Работает на инфраструктуре без выхода в интернет — подходит для закрытых корпоративных контуров. Применяют в enterprise-компаниях с большими ИТ-командами: финансовый сектор, ретейл, телеком, госструктуры. Поддерживает команды от нескольких человек до десятков тысяч специалистов одновременно.​

Как устроена платформа

Управление процессами и задачами

Сфера.Задачи — таск-трекер с настройкой под любую методологию: Agile, Scrum, SAFe, Kanban. Управляет бэклогом, декомпозицией задач, приоритизацией, назначением ответственных и дедлайнов. Закрывает те же сценарии, что Jira, Notion, Trello и Azure DevOps — в одном инструменте.

Сфера.Знания и Сфера.Документы обеспечивают базу знаний и документооборот — аналог связки Confluence + Notion. Здесь хранятся архитектурные решения, регламенты, технические спецификации и всё, что обычно теряется в чатах и почте.​

DevOps-инструментарий

Сфера.DevOps — сквозная автоматизация цикла от написания кода до деплоя. Включает:

• Git-инструмент для хранения, рецензирования и версионирования кода
• CI/CD-конвейер для непрерывной интеграции, тестирования и развёртывания
• Единое хранилище артефактов разработки
• DevOps-сервис самообслуживания для операций первого и второго дня — создание компонентов, сборка, проверка, раскатка

Тестирование

Комплекс инструментов для автоматизированного тестирования встроен в DevOps-конвейер. Поддерживает быстрый и автоматизированный процесс проверки на всех этапах жизненного цикла — от написания тест-кейсов до интеграционного и регрессионного тестирования в пайплайне.​

Мониторинг и эксплуатация

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

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

Для кого это полезно

Техлиды и архитекторы получают единую среду, в которой живут архитектурные схемы, API-документация, код и задачи — всё связано и не расползается по разным системам. Инструмент для проектирования архитектуры на разных уровнях входит в состав платформы отдельным модулем.​

Разработчики работают в знакомом Git-workflow с code review, CI/CD-конвейером и хранилищем артефактов — без необходимости настраивать интеграции между десятком разных инструментов. DevOps-сервис самообслуживания сокращает время на рутинные операции: создание компонентов, настройку сборок, деплой.​

QA-инженеры используют встроенный тест-менеджмент в связке с CI/CD — тест-кейсы, автоматизация, отчётность по покрытию в одном контуре.

Что отличает подход

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

Техническая база

• Методологии: Agile, Scrum, SAFe, Kanban​
• Инструменты: таск-трекер, Git, CI/CD, хранилище артефактов, тест-менеджмент, база знаний, документооборот, мониторинг, управление инцидентами​
• Интеграции: существующие системы контроля версий (GitLab и другие), внешние DevOps-инструменты​
• Развёртывание: корпоративный контур без выхода в интернет​
• Реестр: входит в реестр российского ПО​

Управление и поддержка

Платформа разработана совместно с VK, «1С», Лабораторией Касперского и Ростелекомом в рамках дорожной карты «Новое общесистемное ПО». Поддержка охватывает все модули платформы через единый канал. Новые команды могут опираться на встроенный методологический фреймворк для выстраивания процессов производства ПО с нуля.

Comindware Platform: Low-code BPM для автоматизации сложных процессов

Comindware Platform — Low-code BPM-платформа для моделирования, автоматизации и оптимизации бизнес-процессов предприятия. В одной среде работают корпоративная архитектура, процессный движок, кейс-менеджмент, управление данными и интеграции с внешними системами. Процессы описываются в визуальном дизайнере по нотации BPMN, исполняются движком точно в соответствии с моделью — без разночтений при переносе логики из схемы в код.

Среднее время реализации MVP на стороне клиента — 4 недели. Один из подтверждённых кейсов: бизнес-аналитик ABPMP в одиночку автоматизировал процесс обработки заявок за 30 часов, ускорив его в пять раз. Платформа применяется в промышленности, финансовом секторе, ритейле, телекоме, строительстве, медицине и государственных структурах. Среди кейсов нашла проекты для Газпром Авиа, НСПК, UCS, UserGate.

Как устроен процесс работы

Моделирование и автоматизация процессов

Процессы моделируются в BPMN-нотации, движок исполняет их в точности с моделью. Настройка большинства сценариев ведётся без написания кода, для сложной кастомной логики доступны C# и N3.

Управление данными и интерфейсами

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

Событийная оркестрация

Самогенерирующийся REST API развивается вместе с платформой и клиентскими приложениями, оставаясь обратно совместимым. Документирование через Swagger/OpenAPI: разработчики получают подробное описание каждого с примерами и возможностью тестирования на реальных данных без сборки приложения.​

Встроенные коннекторы покрывают стандартные корпоративные интеграции: Git, OpenLDAP/Active Directory, SMTP/IMAP, Exchange, OData (ERP), RabbitMQ/MSMQ, MSSQL/MySQL. Для событийных сценариев поддерживаются вебхуки — обмен данными с Telegram, Viber, JivoSite, телефонией (Novofon, Mango Office), почтовыми сервисами и любыми внешними системами через HTTP.

Для кого это полезно

• Архитекторы и аналитики управляют всей картой процессов компании в одной среде — от верхнеуровневой модели до исполняемых процессов. Изменения вносятся без остановки запущенных экземпляров, логика модели напрямую транслируется в поведение системы без ручной интерпретации.​
• Разработчики работают с самогенерирующимся REST API с Swagger-документацией, встроенными коннекторами к популярным сервисам и возможностью подключать кастомную логику на C#.
• PM получает прозрачность по статусу процессов в реальном времени и аналитику по отклонениям.
• QA и аналитики проверяют логику процессов на моделях до выхода в прод. Изменения можно откатить или протестировать на отдельном контуре.

Что отличает подход

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

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

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

Техническая база

• Нотация процессов: BPMN 2.0
• Языки кастомной логики: C#, N3
• API: самогенерирующийся REST API, документирование через Swagger/OpenAPI​
• Коннекторы: Git, Active Directory/OpenLDAP, Exchange, SMTP/IMAP, OData, RabbitMQ, MSMQ, MSSQL, MySQL​
• Интеграции через вебхуки: Telegram, Viber, JivoSite, Novofon, Mango Office, Unisender, Mailchimp, CRM-системы (Bitrix24, Megaplan, MS Dynamics)​
• Развёртывание: on-premise, частное и публичное облако, гибридная схема​

Управление и поддержка

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

***

Общая закономерность у всех рассмотренных решений одна: экспертиза видна в глубине проработки конкретного слоя. Selectel копает до уровня BIOS/BMC и изучает, как ведёт себя железо под нагрузкой — потому что сами на нём работают. Чек-лист, который стоит держать в голове при выборе инструментов и подрядчиков для сложных задач:

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

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

С практической точки зрения проект на**й не нужен. Есть 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.

Android 17 вышел 16 июня. API 37, AppFunctions для ИИ-агентов, adaptive-first и Compose-first, строгие лимиты памяти и новые API приватности.

Google Play расширяет выбор платёжных систем и снижает комиссии: с 30 июня 2026 сервисный сбор отдельно от платёжного, первый $1M — 10%.

Безопасность: июньский бюллетень закрыл 124 уязвимости, включая zero-day CVE-2025-48595 в Framework. С 30 сентября 2026 начинается обязательная верификация разработчиков в четырёх странах.

Инструменты: Android CLI 1.0, 17+ Android skills, Android Bench с Gemma 4 и Gemini 3.5 Flash, Android XR SDK DP4 и Eclipsa Video для HDR.

Android 17: релиз 16 июня и API 37

16 июня 2026 года Google выпустил Android 17. Платформа переходит от «операционной системы» к «интеллектуальной системе»: центральную роль занимают AppFunctions — функции приложений, которые ИИ-агенты могут обнаруживать и вызывать через Jetpack-библиотеку. Разработчики аннотируют класс, добавляют KDoc, и Gemini получает доступ к локальному состоянию приложения.

Главное архитектурное изменение — adaptive-first: на больших экранах (sw > 600 dp) для приложений с targetSdk 37 игнорируются ограничения ориентации и размера. Вместе с этим появились App Bubbles, Bubble Bar и интерактивный Picture-in-Picture для десктопа. Google заявляет, что Compose теперь является первым классом UI: View-компоненты и View-based библиотеки переведены в режим обслуживания.

Производительность и приватность

Android 17 вводит лимиты памяти на основе объёма RAM устройства и убивает процессы, их нарушающие. Для диагностики добавили интеграцию LeakCanary в Android Studio Panda и on-device аномалию в ProfilingManager. ART получил generational GC, а MessageQueue для targetSdk 37 стал lock-free — это ускоряет старт и снижает пропуск кадров, но ломает рефлексию над приватными полями.

Из приватных нововведений — системный Contact Picker без разрешения READ_CONTACTS, системный Eyedropper для выбора цвета, временный доступ к локальной сети через ACCESS_LOCAL_NETWORK и post-quantum криптография с ML-DSA и гибридной подписью APK v3.2.

Инструменты и продуктивность: Android CLI 1.0, skills и Bench

9 июня в блоге Android Developers подвели итоги I/O по продуктивности. Главное — стабильный релиз Android CLI 1.0: теперь инструмент доступен через npm и Homebrew, умеет Journeys и команду studio для моста с Android Studio, а также интегрируется с Google Antigravity.

Каталог Android skills вырос до 17+ сценариев: адаптивный UI, CameraX, Perfetto SQL, Engage SDK, Wear OS, AppFunctions и другие. А Android Bench обзавёлся открытыми моделями, включая локальную Gemma 4, и свежими Gemini 3.5 Flash. В ближайшее время в бенчмарк добавят долгие многошаговые задачи.

Google Play: биллинг, комиссии и поиск

24 июня Google расширила выбор платёжных систем в Великобритании, ЕЭЗ и США. Разработчики могут предлагать альтернативный биллинг или внешние ссылки на свой сайт. С 30 июня 2026 сервисный сбор отделяется от платёжного: первый $1M в год — 10%, все автообновляемые подписки — 10%, остальное зависит от новой/существующей установки. Платёжная комиссия при использовании Google Play billing — 5% в этих регионах; при альтернативном биллинге она не берётся.

Также Google запустила программы Games Level Up и Apps Experience с пониженными ставками, а в Play Store появился AI-поиск Ask Play, Trusted Contributor-значки и более заметные скидки. Для разработчиков это означает, что ASO и монетизацию придётся пересматривать под новые механики отображения цен.

Безопасность: zero-day и верификация разработчиков

Июньский Android Security Bulletin закрыл 124 уязвимости. Самая неприятная — CVE-2025-48595 в Framework, уже эксплуатируемая в ограниченных целевых атаках. Она затрагивает Android 14–16 QPR2 и позволяет повысить привилегии без взаимодействия с пользователем. Критичный патч — уровень 2026-06-05, так как он включает исправления чипсетов Qualcomm и MediaTek.

18 июня Google обновила статус верификации разработчиков. С 30 сентября 2026 в Бразилии, Индонезии, Сингапуре и Таиланде станут обязательными регистрация приложений в семи магазинах. В июне на устройствах начали раскатывать системный сервис, который позже будет проверять регистрацию. В июле–августе появятся Android Developer ID Status API и Developer Console API для массовой регистрации через CI/CD.

Android XR: DP4, движки и Geospatial API

15 июня вышел Developer Preview 4 Android XR SDK. Для очков дополненной реальности добавили Jetpack Projected с Device Availability API, а Compose Glimmer оптимизирован под прозрачные дисплеи и тачпад. Для иммерсивных приложений — ранняя версия Geospatial API на базе ARCore и Visual Positioning System.

Кроме Unity для проводных XR-очков появилась официальная поддержка Unreal Engine и Godot, а также Android XR Engine Hub — десктопный инструмент для Windows с real-time тестированием прямо во вьюпорте движка. Программа Android XR Developer Catalyst Program открыта для заявок и даёт доступ к pre-release железу.

Premium-опыт: R8, Glance и Media3

В посте 2 июня о премиум-опыте Google акцентировала R8 Configuration Analyzer: он показывает, какие keep-rules мешают оптимизации. Monzo за счёт настройки R8 получили 30% прирост холодного старта и 35% снижение ANR.

Jetpack Glance теперь унифицирует виджеты для телефонов, часов и автомобилей на базе Compose, а RemoteCompose позволяет рендерить UI на внешних поверхностях. Media3 получил AI Effects, CodecDB, Scrubbing Mode в ExoPlayer и улучшенный CastPlayer. CameraX 1.5+ добавляет CameraXViewfinder Composable и динамические диапазоны.

Eclipsa Video: единый стандарт HDR

29 июня Google представила Eclipsa Video — стандарт HDR на базе SMPTE ST 2094-50, разработанный совместно с Apple и NBCUniversal. Он задаёт единый HDR reference white, адаптирует яркие участки под возможности дисплея и сохраняет творческий замысел кадр за кадром. Поддержка встроена в Android 17, ExoPlayer/Media3 обрабатывают метаданные автоматически.

FAQ

Выводы

Июнь 2026 показал, что Google делает ставку на три вещи: ИИ-агентов как часть рабочего процесса (AppFunctions, Android CLI, skills), адаптивность интерфейсов под любые форм-факторы и жёсткий контроль за безопасностью экосистемы. Разработчикам стоит в первую очередь протестировать приложения под Android 17, проверить R8-конфигурацию и подготовиться к новым правилам биллинга и верификации.

Самый быстрый способ не отстать — поставить Android CLI, добавить пару skills под свой проект и прогнать релиз на Android 17 эмуляторе, прежде чем OEM-партнёры начнут массово раскатывать обновление.

Источники: Android 17 is here, Top 3 updates for Android developer productivity, Expanded billing choice and lower fees on Google Play, Android developer verification, What's New in Android XR, Building Premium Android Experiences, Eclipsa Video.

Для российских разработчиков это особенно близкая история: Kotlin создавался в JetBrains, компании, основанной выпускниками Санкт-Петербургского политехнического университета. Язык, названный в честь острова в Балтийском море, стал одним из самых заметных российских технологических экспортов последнего десятилетия.

15 лет Kotlin. Первый анонс состоялся в июле 2011 года, стабильная 1.0 — в феврале 2016-го.

Kotlin 2.4.0. Стабильные context parameters, explicit backing fields, поддержка Java 26, Swift packages в Kotlin/Native и совместимость с Gradle 9.5.0.

Kotlin Toolchain 0.11. Amper эволюционировал в единый инструментарий: одна команда kotlin для создания, сборки, тестирования и публикации проектов.

Koog 1.0. JetBrains выпустила стабильный фреймворк для AI-агентов на Kotlin и Java с годовой гарантией совместимости ядра.

Compose Multiplatform 1.12.0-beta01 и Compose Hot Reload 1.2.0-beta01 развивают shared UI и экспериментальный MCP-сервер для AI-агентов.

Гранты Kotlin Foundation 2026. Приём заявок на финансирование open-source библиотек и инструментов открыт до 14 июля 2026 года.

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

История Kotlin началась в 2010 году как попытка JetBrains решить собственные проблемы с Java. В 2011-м язык впервые показали публике, а в феврале 2016 года вышла стабильная версия 1.0. Переломным моментом стал Google I/O 2017: Kotlin получил статус первоклассного языка для Android, после чего интерес к нему резко вырос.

Сегодня Kotlin используется не только в мобильной разработке. На нём пишут backend на Spring и Ktor, делают кроссплатформенные приложения через Kotlin Multiplatform, экспериментируют с Kotlin/Wasm и даже строят AI-агентов. По данным ежегодных опросов JetBrains, доля Kotlin в коммерческих проектах стабильно растёт как в Европе, так и в России, несмотря на санкционные ограничения в части корпоративных лицензий.

If I were to choose one word to describe Kotlin's design, it would be pragmatism. For us it means caring about the usefulness.

Kotlin 2.4.0: что вошло в релиз

3 июня 2026 года JetBrains выпустила стабильный Kotlin 2.4.0. Это не инкрементальный патч, а полноценная мажорная версия с изменениями в языке, стандартной библиотеке, компиляторе и всех целевых платформах.

• Язык. Стабилизированы context parameters и explicit backing fields, добавлены новые target'ы для аннотаций.
• Стандартная библиотека. UUID API вышел из экспериментального статуса, появились функции для проверки отсортированности коллекций.
• Kotlin/JVM. Поддержка Java 26 и аннотации в метаданных включены по умолчанию.
• Kotlin/Native. Swift packages можно использовать как зависимости, обновлён Swift export, по умолчанию включён CMS GC.
• Kotlin/Wasm. Инкрементальная компиляция по умолчанию и поддержка WebAssembly Component Model.
• Kotlin/JS. Экспорт value-класс и возможности ES2015 при инлайнинге JS-кода.
• Gradle. Совместимость с Gradle 9.5.0.
• Maven. Автоматическое выравнивание версий Java и JVM target.
• Компилятор. Более предсказуемое поведение inline-функций при компиляции .klib.

Для практики это означает: если ваш проект живёт на JVM, можно обновляться ради Java 26 и улучшений stdlib; если вы работаете с iOS через Kotlin/Native — стоит посмотреть на Swift packages; для WebAssembly-экспериментов 2.4.0 делает сборку заметно быстрее.

Как обновиться

Обновление до 2.4.0 проходит через указание версии в Gradle или Maven. В Android Studio и IntelliJ IDEA новая версия уже включена в последние сборки.

Kotlin Toolchain 0.11: Amper уходит в прошлое

В июне 2026 года JetBrains окончательно переименовала Amper в Kotlin Toolchain и выпустила версию 0.11. Это не просто ребрендинг: инструмент позиционируется как единая точка входа для работы с Kotlin-проектами. Одной командой kotlin можно создать, собрать, протестировать и опубликовать проект.

В 0.11 появилась возможность публиковать JVM-библиотеки, улучшена разработка плагинов и упрощена начальная настройка. Для российских команд, часть которых уходит от корпоративных Gradle-лицензий к open-source инструментам, Kotlin Toolchain может стать интересной альтернативой для новых проектов и прототипов.

Важно: Kotlin Toolchain пока в статусе Alpha. Для существующих Gradle-проектов массово мигрировать смысла нет — инструмент ещё не покрывает все сценарии зрелых сборок. Но пробовать на небольших сервисах и pet-проектах уже можно.

Koog 1.0: AI-агенты на Kotlin

Фреймворк Koog от JetBrains вышел в версии 1.0. Он предоставляет примитивы для построения агентных приложений: инструменты, workflow, персистентность, память, observability и интеграции с JVM/KMP-проектами. Главное для Java-команд: Koog теперь предлагает идиоматичный Java API, то есть переходить на Kotlin ради агентов не обязательно.

Koog интегрируется со Spring AI, что делает его естественным выбором для backend-разработчиков, которые уже используют Spring Boot. Появилась мультиплатформенная observability и годовая гарантия совместимости ядра — это важно для команд, которые рассматривают агентов не как прототип, а как часть продакшена.

Compose и инструменты UI

Для UI-разработчиков в выпуске два значимых обновления. Compose Multiplatform 1.12.0-beta01 продолжает развивать shared UI: новые графические возможности, улучшения accessibility на iOS, обновления поведения UI-тестов и исправления для десктопа, веба и Gradle-плагина.

Отдельно стоит Compose Hot Reload 1.2.0-beta01. В нём развивается экспериментальный MCP-сервер: AI-агенты получают доступ к логам, ошибкам UI, могут перезапускать приложение и управлять его жизненным циклом. Это ещё не production-ready, но демонстрирует направление: разработка интерфейсов становится более визуальной и интерактивной.

Экосистема: библиотеки, гранты и корпоративный опыт

В обзоре JetBrains упомянуты три KMP-библиотеки, которые стоит изучить: ComposeMediaPlayer для кроссплатформенного видео, NSExceptionKt для улучшенной обработки крэшей на Apple-платформах и multiplatform-settings для хранения key-value данных в shared-коде.

Кроме того, Kotlin Foundation открыл грантовую программу 2026. Финансирование могут получить open-source проекты вокруг Kotlin Multiplatform, AI и больших языковых моделей. Заявки принимаются до 14 июля 2026 года. Для российских авторов библиотек это реальный способ поддержать проект, особенно если он пользуется спросом у зарубежного комьюнити.

Ещё один сигнал зрелости экосистемы — история Booking.com. Компания внедрила Kotlin Multiplatform для экспериментальной библиотеки и получила результаты выше ожиданий: улучшилась консистентность между Android и iOS, при этом команды не отказывались от платформенно-специфичной разработки.

Обучение: бесплатные курсы на Hyperskill

К юбилею JetBrains сделала часть Kotlin-курсов на Hyperskill бесплатными. Это проектно-ориентированная платформа: можно укрепить основы или пойти в сторону мобильной и backend-разработки. Для тех, кто только начинает или переходит с Java, это удобный способ получить практику, а не только теорию.

Выводы

15 лет Kotlin — это не только юбилей, но и точка, где язык перешёл из фазы «быстрого роста» в фазу «экосистемного инструмента». Kotlin 2.4.0 делает язык зрелее на всех платформах, Kotlin Toolchain упрощает вход в экосистему, а Koog и Compose Hot Reload показывают, что Kotlin активно используется в новой волне AI-разработки.

Для работающих проектов самый безопасный шаг — обновиться до Kotlin 2.4.0 в тестовом окружении и проверить совместимость. Новые инструменты вроде Toolchain и Koog стоит пробовать на pet-проектах, прежде чем тащить в продакшен. А если у вас есть open-source библиотека вокруг Kotlin — грантовая программа Kotlin Foundation может стать хорошим подспорьем.

Источник: Kodee's Kotlin Roundup: Kotlin Turns 15, Kotlin 2.4.0, and the Kotlin Toolchain — блог JetBrains.

Поэтому считать стоит не “сколько стоит разработчик”, а “сколько стоит довести задачу до продакшена”. Для этого и нужен TCO (total cost of ownership): полная стоимость владения командой, процессом или внешним контуром разработки.

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

Почему ставка разработчика ничего не объясняет

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

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

TCO появляется как раз между “купили часы разработчиков” и “получили работающую фичу в продакшене”. В расчет попадают дополнительные расходы:

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

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

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

В выделенной команде легко попасть в ловушку “возьмём человека и ускоримся”. Ускорение появится, если внутри уже есть техлид, код-ревью и понятный процесс.

Базовая формула такая:

TCO разработки = прямые расходы + управление + запуск + простои + риски + передача знаний.

Где:

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

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

Как считать TCO инхауса

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

Формула может быть такой:

TCO инхауса = зарплата + налоги + инфраструктура + найм + онбординг + управление + простой + риск замены

• Зарплата и налоги можно посчитать сразу. Остальное часто всплывает позже. Разработчику нужны ноутбук, монитор, доступы, IDE, таск-трекер, облачные сервисы, тестовые стенды и корпоративные инструменты.
• Найм тоже входит в TCO. Вакансию нужно описать, кандидатов найти, провести скрининг, техническое интервью, тестовое задание и согласование оффера.
• После выхода человека начинается онбординг. Разработчик разбирается в кодовой базе, архитектуре, локальном окружении, правилах ревью и деплоя. Первые недели он часто требует больше внимания, чем отдаёт команде пользы. Это нормальная часть штатной разработки, её просто нужно считать заранее.
• Отдельная статья расходов — текучка. Когда разработчик уходит, компания теряет часть контекста. Потом нужно снова искать человека, вводить его в проект и ждать, пока он выйдет на нормальную скорость.

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

Инхаус окупается, когда разработка завязана на сложную бизнес-логику, безопасность, внутренние интеграции или долгую архитектурную стратегию. Для короткого проекта инхаус получается слишком дорогим. Если задача нужна на несколько месяцев, в TCO попадает вся стоимость запуска штатной команды ради ограниченного объёма работ.

Как считать TCO аутсорса

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

Формула может быть такой:

TCO аутсорса = стоимость договора + подготовка требований + управление со стороны заказчика + приёмка + изменения цели + передача результата

• Стоимость договора обычно включает работу команды, PM, тестирование, инфраструктуру подрядчика и его маржу. Маржа в этой модели нормальна: подрядчик держит команду, управляет загрузкой, закрывает внутренние риски и отвечает за процесс на своей стороне.
• Главная точка роста стоимости — требования. Когда финальная цель понятная, подрядчик быстрее оценивает задачу, планирует этапы и показывает результат.
• Заказчику всё равно нужно управлять проектом со своей стороны. Подрядчик не знает продуктовый контекст по умолчанию. Ему нужны ответы на вопросы, доступы, обратная связь и приёмка промежуточных результатов.
• В TCO аутсорса стоит сразу закладывать передачу результата. В договоре нужно зафиксировать права на код. Документация должна позволять поддерживать проект другой команде. Деплой, окружения и API тоже лучше описать до финальной приёмки.

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

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

Как считать TCO выделенных команд

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

Формула может быть такой:

TCO выделенных команд = ставка специалиста + подбор + онбординг + управление + ревью + коммуникация + риск замены

• Ставка специалиста даёт доступ к человеку, а готовый результат всё равно собирает ваша команда. Подрядчик может помочь с подбором, оформлением, заменой и административной частью. Заказчик отвечает за ежедневную работу специалиста.
• Самая важная статья расходов здесь — время техлида. Он проводит техническое интервью, вводит человека в проект, объясняет архитектуру и проверяет решения.
• Онбординг в аутстаффинге обычно короче, чем в инхаусе: компания не проходит полный цикл найма и оформления, но контекст проекта всё равно нужно передать.
• В TCO нужно заложить коммуникацию с провайдером. Если специалист заболел, не подошёл по уровню или проекту нужна замена, порядок действий должен быть понятен заранее.

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

Где здесь место внешней команды

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

Здесь помогает простой вопрос: что сейчас нужно купить. Часы специалистов, готовый контур разработки или помощь с постановкой задачи. Centicore Group работает с выделенными командами IT-специалистов, заказной разработкой и IT-консалтингом. Поэтому формат можно подбирать под ситуацию: усилить свою команду, передать отдельную часть разработки внешней команде или начать с анализа требований и архитектуры.

Посмотреть услуги Centicore Group

Чек-лист перед выбором модели

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

1. Сначала — управление. Если внутри есть CTO, техлид или сильный PM с техническим бэкграундом, можно рассматривать аутстаффинг и гибридную модель. Если управленца нет, аутстаффинг быстро станет проблемой. В этом случае безопаснее смотреть на аутсорс, где управление разработкой берёт на себя подрядчик.
2. Дальше — срок проекта. Для задачи на несколько месяцев инхаус часто слишком дорогой: найм, адаптация и настройка процессов могут занять больше времени, чем сама разработка. Для продукта на долгосрок, наоборот, стоит заранее думать о своём техническом ядре.
3. Третий пункт — требования. Чем понятнее сценарии, интеграции, ограничения и критерии готовности, тем проще считать TCO аутсорса. Если требования ещё меняются, в бюджет нужно сразу закладывать аналитику, дополнительные итерации и переприёмку.

Перед решением ответьте на несколько вопросов:

• кто владеет архитектурой и техническими решениями;
• кто принимает код, документацию и деплой;
• что будет, если ключевой специалист выпадет из проекта.

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

Итого

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

• Инхаус подходит для долгих продуктов, где важны контроль, архитектура и накопление экспертизы внутри команды.
• Аутсорс удобен для MVP, интеграций, миграций и отдельных сервисов с понятными границами. Здесь важно заранее считать требования, приёмку, документацию и передачу результата.
• Аутстаффинг помогает быстро усилить команду, если внутри уже есть техлид, бэклог, ревью и нормальный процесс разработки.
• Гибридная модель нужна, когда продукт проходит разные этапы. На старте можно подключить внешнюю команду, после проверки гипотезы собрать своё ядро, а пиковую нагрузку закрывать аутсорсом или аутстаффингом.

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

Харнесс не привязан к одной модели: одна модель ищет уязвимости в VDH, а другая модель в VVS независимо валидирует находки, включая оценку риска в продакшене. Так Model B оценивает вывод Model A с другими весами и другими обучающими данными, словно независимый адвокат дьявола. Это не просто безопасность: провайдеры моделей меняют температуру, кэширование и бюджеты инференса даже в рамках одной версии, а харнесс умеет поглощать эту волатильность, не ломаясь.

Харнесс — это не модель, а оркестрация. Ценность в конвейере с сохранением состояния, а не в очередном промпте.

Две стадии: Vulnerability Discovery Harness (VDH) ищет баги, Vulnerability Validation System (VVS) проверяет, дедуплицирует и чинит их.

Контекст держится под контролем. Каждый агент решает узкую задачу и использует менее 25% окна.

Доверие через adversarial verification. Охотник должен предъявить модель угрозы, рабочий PoC и патч; валидатор обязан опровергнуть находку.

Цифры масштаба: VDH охватывает 128 репозиториев; в общий VVS на момент публикации попало 13 841 находка по 145 репозиториям, из которых 7 245 — находок, по которым можно действовать, отправлены инженерам на исправление.

Почему обычный кодинг-агент не справляется

Cloudflare начинала с 450-строчного скилла security-audit, который проходил семь фаз в одной сессии: три агента-разведчика писали архитектуру, охотники атаковали код по классам угроз, валидаторы пытались опровергнуть находки, а финальный агент перепроверял выжившие баги. Скилл работал, но быстро уперся в потолок.

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

Три стены, которые ломают односессионный подход

• Исчерпание контекста. Через час модель начинает «пожирать» собственную память и забывает баги, которые искала утром. Решение — вынести состояние наружу и считать LLM stateless-движком.
• Отсутствие персистентности. Ошибка API или обрыв соединения обнуляют часы работы. SQLite, ключированная по (run_id, repo, stage), позволяет возобновлять любой этап.
• Слепота к межрепозиторным связям. Уязвимость в библиотеке проявляется только там, где её используют. Без трассировки зависимостей такие баги остаются незамеченными.

Совет: настоящий минимальный харнесс — это только Recon, Hunt и Validate, записанные в базу, плюс валидатор, который не может заводить собственные находки. Кросс-репозиторную трассировку и дедупликацию можно добавить позже, когда без них станет невыносимо.

Две стадии: открытие и триаж

Вся система разбита на два независимых контура. Первый — Vulnerability Discovery Harness (VDH), движок обнаружения, который сканирует код и выдаёт сырые кандидаты. Второй — Vulnerability Validation System (VVS), куда попадают находки из нескольких харнессов.

Главный архитектурный трюк — разные модели на разных стадиях. VDH работает на одной модели, VVS — на другой. Так Model B оценивает вывод Model A с другими весами и другими обучающими данными, словно независимый адвокат дьявола. Это не просто безопасность: провайдеры моделей меняют температуру, кэширование и бюджеты инференса даже в рамках одной версии, а харнесс умеет поглощать эту волатильность, не ломаясь.

VDH: как устроен конвейер обнаружения ИИ-харнесса

VDH состоит из восьми стадий. Первые три — разведка, охота и валидация. Остальные пять работают как конвейер «производитель—потребитель»: пока идёт первичный поиск, Gapfill, Feedback и Trace порождают новые задачи, Dedup сворачивает дубли, и цикл продолжает потреблять очередь.

• Recon. Три параллельных агента-разведчика строят architecture.md и пишут собственную таксономию атак под конкретный репозиторий.
• Hunt. Охотники атакуют код по классам угроз. Они компилируют фрагменты, запускают бинарники и используют песочницу на базе unshare.
• Validate. Детерминированный код проверяет схему и пути, затем изолированный агент пытается опровергнуть находку.
• Gapfill. Генерирует новые задачи охоты для недостаточно покрытых ячеек «область × класс атаки».
• Dedup. Детерминированный код + агент кластеризуют находки по корневой причине в реальном времени.
• Trace. Трассирует граф зависимостей и порождает задачи в потребляющих репозиториях.
• Feedback. Переписывает промпты в очереди на основе провалов валидации, поверхностных прогонов (shallow runs) и повторных промахов.
• Report. Рендерит человекочитаемый отчёт; здесь модель не нужна.

Динамическое моделирование угроз

Recon пишет модель угроз самостоятельно, а не получает её сверху. Помимо десяти встроенных классов атак (инъекции, повреждение памяти, парсинг протоколов, тайминговые side-channel и другие), агент может изобрести собственные классы, специфичные для кодовой базы, с собственной методологией. Это делает охоту точнее, чем любой универсальный чек-лист.

Охотники выходят за рамки чтения кода и переходят к активному выполнению. Они компилируют фрагменты, собирают мини-версии и атакуют их. Качество сильно выросло, когда охотникам дали песочницу на базе системного вызова unshare (изолирует пространства имён Linux), в которой можно падать. Если харнесс сам бежит внутри Docker, песочнице нужны флаги seccomp=unconfined (отключает фильтр системных вызовов) и apparmor=unconfined (отключает профиль мандатного доступа), иначе она молча не запустится.

Братские форки и список пожеланий

Два механизма дают охотникам автономию, не позволяя сбиться с курса. Братское форкание: если охотник натыкается на интересный путь вне текущей области, он создаёт «брата» с точным структурным заданием. По флоту это даёт 9–20% задач в зависимости от модели.

Список пожеланий — центральный список запросов на инструменты и ресурсы. Охотник или валидатор может написать: «мне нужна виртуальную машину на FreeBSD, чтобы подтвердить сквозной PoC». Система автоматически перезапускает задачу, когда человек предоставит зависимость. Список пожеланий уже записывался 25 472 раза за 128 репозиториев.

Кросс-репозиторная трассировка

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

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

Как не превратиться в генератор мусора

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

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

• Каждая подтверждённая находка сопровождается рабочим PoC в виде теста против неизменённой кодовой базы.
• Каждая находка должна включать предложенный патч в виде рабочего git diff.
• Детерминированный валидатор проверяет, что указанные файлы и пути существуют, а патч и тест парсятся.
• Валидатор не может заводить собственные находки; его единственная работа — агрессивно опровергать теорию охотника.

Cloudflare не заявляет о доле ложноотрицательных срабатываний: невозможно знать все баги в кодовой базе. Вместо этого они отслеживают, находят ли повторные прогоны новые баги и растёт ли покрытие областей атак (area × attack-class). Это прокси-метрика, но она достаточно хороша для измерения эффективности.

VVS: триаж, который превращает шум в работу

Находка из харнесса — только начало. В общий VVS вливаются находки из разных источников; на момент публикации там было 13 841 находка по 145 репозиториям. Триаж разбит на три работы: Dedup, Judgment и Fixing.

• Dedup. Детерминированный код строит инвертированные индексы по файлам, функциям, границам доверия и редким токенам, чтобы сократить список кандидатов. Затем Dedup-агент решает, не закрывается ли несколько находок одним патчем. Стабильные межпрогоновые ключи возобновляют старые записи вместо создания новых.
• Judgment. Агент собирает контекст из продакшена: wiki, Jira, git, конфиги. Он проверяет, воспроизводится ли баг на последнем main, доступен ли путь извне, и кто владелец репозитория. Результат — разделение на «эксплуатируется сейчас», «реальный, но латентный» и «заведён не в тот компонент».
• Fixing. Fixer переписывает патч и тесты в стиле репозитория, накладывает diff и запускает таргетированные тесты. Чистый переход fail→pass — единственный случай автоматического cleanup. Если пост-патч тест падает или находит регрессию, коммит блокируется. Fixer никогда не мержит сам: всегда нужен человек.

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

Сколько это стоит и как понять, что работает

Большая часть бюджета уходит на стадию Hunt. Поэтому Gapfill становится рычагом соотношения цена/покрытие: каждый дополнительный проход стоит примерно вдвое меньше первичной охоты. Cloudflare бюджетирует не на прогон, а на репозиторий, с жёстким лимитом задач на репо и пулом из 50–200 воркеров. Так деньги тратятся там, где находятся баги, а не на «чистые» репозитории.

Полное сканирование сложного репозитория может занять несколько часов; худший прогон длился чуть более 14 часов. Поэтому большие сканы — это периодическая зачистка бэклога, а не проверка на каждый PR. Для CI/CD подходят более дешёвые и маленькие харнессы.

Цифры фильтрации

• VDH выпустил 20 799 сырых кандидатов.
• После независимой валидации осталось около 12 057 находок.
• В VVS, объединившись с находками из другого харнесса, общий пул вырос до 13 841.
• Dedup-агент свернул 5 442 дубля.
• 1 154 были отмечены как «не тот репозиторий» или «низкий риск» и возвращены в систему для повторной обработки там, где это уместно.
• В итоге 7 245 находок, по которым можно действовать, ушли инженерным командам.

Ещё один пример: для стандартного репозитория примерно на 30 000 строк кода система выдаёт около 100 начальных находок за 3–4 часа, затем в течение 3 часов сжимает их до 80 уникальных багов, а Fixer обрабатывает их со средней скоростью 5 минут на баг. Весь цикл «найти → валидировать → дедуплицировать → открыть PR» занимает примерно 14 часов.

Распространение патчей

80 патчей за раз в прод не выкатить. Cloudflare использует многоуровневый выкат: критические, высокие и эксплуатируемые извне баги (в среднем 10 из 80) уходят на ускоренное ревью и закрываются в продакшене за 5 дней. Оставшиеся латентные риски и мелкие аномалии конфигурации раскатываются в течение 15–20 дней, чтобы не ломать платформу.

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

Часто задаваемые вопросы

Выводы

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

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

Компания выложила исходный security-audit skill на GitHub: cloudflare/security-audit. Это не сам харнесс, но рабочая отправная точка. Если хотите развивать тему дальше, полезно почитать про автоматизацию безопасности с помощью DevSecOps и ИИ и про SCA-анализаторы, которые решают смежную задачу в сторонних зависимостях.

Источники

Build your own vulnerability harness — Cloudflare Blog, 18 июня 2026.

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

worktree — это дополнительная рабочая копия репозитория на другой ветке, привязанная к тому же .git.

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

Они особенно полезны при параллельной работе с ИИ-агентами и в приложении GitHub Copilot.

У worktrees есть ограничения: раздувание зависимостей, необходимость убирать папки, правила .gitignore и запрет на одновременный checkout одной ветки в нескольких worktrees.

Переключение контекста через ветки и stash

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

Сначала, скорее всего, спрячете текущие изменения в stash:

Потом перейдёте на main и обновите её:

Затем создадите ветку с хотфиксом:

Пофиксите, закоммитите и запушите ветку:

После слияния pull request вы вернётесь к компьютеру, подтянете main и удалите ветку с багфиксом:

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

Фух. На чём мы остановились?

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

Это базовый пример, но иногда разработчики справлялись с таким хаосом сложными командами git stash или даже несколькими клонами одного репозитория (я сама грешила этим).

А потом появились… worktrees!

Переключение контекста через worktrees

С worktrees вы никогда не покидаете свою ветку и не используете stash, а редактор с вашей текущей фичей остаётся нетронутым.

Эта команда мгновенно создаёт соседнюю папку hotfix-workspace, базирует её на main и создаёт новую ветку hotfix-bug.

Теперь можно открыть эту папку в новом окне редактора (или перейти в неё через cd) и чинить баг. Исходное окно редактора остаётся в том же состоянии, в котором вы его оставили.

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

Гораздо плавнее! Нет риска конфликтов stash, редактор не перезагружается, и вы действительно можете работать параллельно.

Так почему же сейчас?

Долгое время worktrees были относительно неизвестны. Большинство разработчиков никогда о них не слышали, потому что либо Git GUI не поддерживали их (или относились как к второсортной функции), либо все привыкли к знакомой схеме: feature-ветка, работа, PR, merge и повтор.

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

Агенты и люди могут делать больше параллельно с помощью worktrees. Это режим по умолчанию в приложении GitHub Copilot и во многих других современных инструментах.

Агенты и люди могут делать больше параллельно с помощью worktrees.

В чём подвох?

Worktrees решают кучу проблем, но есть нюансы, на которые стоит обращать внимание.

• Раздувание зависимостей: каждая папка worktree требует собственную копию зависимостей проекта. Если запускать npm install или pip install в нескольких worktrees, диск может быстро закончиться.
• Управление папками: нужно удалять папки worktree, чтобы со временем не засорять родительский каталог. Приложение GitHub Copilot часто делает это за вас, но если вы работаете в терминале, придётся следить самостоятельно.
• Требования к глобальному .gitignore: если создавать worktree внутри основного репозитория, их нужно вручную добавить в .gitignore, чтобы случайно не закоммитить. Можно создавать worktree за пределами основного репозитория (GitHub Copilot делает это по умолчанию), но это стоит учитывать.
• Ограничение «одна ветка»: Git не позволяет одновременно checkout’ить одну и ту же ветку в двух разных worktrees, чтобы избежать повреждения данных.

Как использовать git worktrees в приложении GitHub Copilot?

Отличный вопрос! Здорово, что там всё работает «из коробки». Когда вы открываете приложение, на главном экране есть выпадающий список, который спрашивает, где запускать новую сессию. По умолчанию выбран новый worktree.

Когда вы запускаете новую сессию, можно нажать на имя сессии вверху приложения и увидеть (забавное!) сгенерированное имя вашего worktree, а также путь, где он находится, проект, для которого он создан, и сведения о внесённых изменениях.

Проще простого!

Стоит ли использовать worktrees?

Я дам вам самый senior-ответ, который только можно: зависит от ситуации! Вам может быть удобнее работать по-другому. Возможно, вы не так много работаете параллельно и привыкли к ментальной модели веток и stash. Возможно, теперь вы будете использовать только worktrees. А может, захотите и то, и другое!

Мир у ваших ног, и попробовать всё это можно уже сегодня в приложении GitHub Copilot.

Об авторе. Cassidy Williams — старший директор по адвокации разработчиков в GitHub. Она создаёт ПО, консультирует стартапы и учит разработчиков строить лучше. Подписаться на её еженедельную рассылку можно на cassidoo.co/newsletter.

Выводы

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

Через четыре месяца четырёхагентный пайплайн на LangChain крутился одиннадцать дней и стоил 47 000 долларов. Никто не заметил, пока не пришёл счёт. Тот же паттерн: цикл работал корректно, но у него не было условия выхода.

Проблема не в моделях, а в отсутствии условия остановки. В этой статье разберём, как собрать минимальный, но production-ready каркас агентного цикла: спецификацию до запуска, предохранитель по токенам и ходам, неизменяемый аудит и поверхность для человеческого согласования. Полный код и 80 тестов с 100% покрытием доступны в репозитории автора оригинала.

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

Спецификация должна отвечать на три вопроса: что делает, что не делает и что значит «готово» — в одном предложении.

Circuit breaker режет цикл по жёстким потолкам: число ходов и суммарные токены. Проверка — до вызова модели, а не после.

Ledger в SQLite фиксирует каждый ход: хеш входа, дельту токенов, время, результат. Это аудит, а не лог для отладки.

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

Что такое агентный цикл и почему он уходит в бесконечность

Агентный цикл — это конструкция вида while True, внутри которой языковая модель получает задачу, вызывает инструменты, анализирует результат и решает, продолжать или закончить. Такие циклы лежат в основе оркестраторов вроде LangGraph, CrewAI и AutoGen, а также внутри coding-агентов. Если только начинаете разбираться с LLM, полезно сначала понять, как устроены большие языковые модели, а для практики — заглянуть в основы Python.

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

Почему дорожает каждая итерация:
Агент не начинает с чистого листа. Он каждый раз перечитывает всё предыдущее окно контекста — все неудачные попытки, все промежуточные выводы. Итерация 1 стоит 100 токенов, итерация 10 — уже тысячи. Вы платите за каждый провал снова и снова.

Почему компании сначала платят за чатбота, а потом за агентный рабочий процесс

Gartner фиксирует разрыв в потреблении токенов между пилотными чатботами и production-агентными рабочими процессами в 5–30 раз. А отчёт FinOps Foundation за 2026 год говорит, что 73% компаний превысили изначальный бюджет на ИИ. Цифры взяты из оригинального туториала; полные отчёты Gartner и FinOps Foundation доступны по платным подпискам. Причина разрыва — в неправильном масштабировании: команда планировала стоимость чатбота (~0,04 USD за взаимодействие), а в прод ушёл мультиагентный оркестр (~1,20 USD за взаимодействие, до 70x на сложных задачах).

A loop that runs without an exit condition isn't autonomous. It's a billing event waiting to happen.

Пять примитивов, которые ловят большинство отказов

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

1. Spec writer — заставляет ответить на три вопроса до первого вызова модели.
2. Circuit breaker — режет цикл, если превышены потолки по ходам или токенам.
3. Ledger — ведёт append-only журнал каждого хода в SQLite.
4. Agent loop — связывает три компонента в единый цикл.
5. Review surface — собирает пятиэлементный фрейм и требует человеческой аттестации перед выдачей результата.

Фаза 1. Определить «готово» до первой строчки кода

Самая дорогая ошибка в разработке агентов — не выбор модели, а начало кодинга до того, как команда может одним предложением описать условие завершения. «Агент проверит сайт» — не подходит. «Агент обходит целевой URL, извлекает все теги <title> и <meta name="description">, помечает отсутствующие или слишком длинные и останавливается» — подходит.

Spec writer интерактивно запрашивает три поля, сохраняет их значения в SQLite и возвращает неизменяемый SpecResult(frozen=True). Полученный session_id связывает спецификацию, строки журнала и итоговый результат в одну трассируемую сессию.

Почему frozen=True:
Спецификация — это обязательство, а не черновик. frozen=True запрещает переприсваивать поля объекта SpecResult, поэтому код цикла не может «подвинуть» условие завершения посреди запуска.

Фаза 2. Принудить «готово» на лету

Circuit breaker задаёт два жёстких потолка: turn_limit — максимальное число обращений к модели, и token_limit — суммарное число токенов за всю сессию. Каждый потолок — «строго больше»: если лимит 5 ходов, пятый ещё разрешён, шестой выбросит исключение.

Ключевое правило: breaker.check() вызывается до запроса к модели, а не после. Постфактум проверка бессмысленна: токены уже сожжены. Исключение, а не код возврата, — чтобы нельзя было промолчать.

Как подобрать лимиты для продакшена

Демонстрационные значения 5 ходов / 15 000 токенов слишком жёсткие для реальных задач. Для продакшена автор предлагает настроить лимиты под свой бюджет; в туториале приведён пример breaker = CircuitBreaker(turn_limit=10, token_limit=50000). Если одна сессия должна стоить не дороже 1 USD, а средний ход — 0,10 USD, получается порядка 10 ходов. Конкретный token_limit выбирается исходя из прайсинга модели и среднего размера контекста: чем длиннее история диалога, тем раньше сработает потолок.

• Стартуйте с жёсткими лимитами и разрешайте рост только по метрикам, не по интуиции.
• Отдельно лимитируйте retry-политику: каждый повторный запрос увеличивает и turn_count, и объём контекста.
• Не смешивайте лимит токенов с лимитом выходных токенов модели; circuit breaker считает сумму input + output.

Фаза 3. Записывать всё, что нельзя подделать

Circuit breaker защищает бюджет. Ledger защищает понимание того, что произошло. Это не лог для отладки, а журнал аудита: каждая строка — один ход, append-only, без обновлений и удалений.

Три решения стоит взять на заметку. Во-первых, вместо исходного текста сохраняется SHA-256 хеш входа: так не утекают персональные данные, а одинаковые входы разных запусков можно сравнивать. Во-вторых, pass_fail хранится как INTEGER (1/0), потому что у SQLite нет булева типа. В-третьих, временная метка — datetime.now(timezone.utc).isoformat(), так как datetime.utcnow() объявлен устаревшим в Python 3.12.

Фаза 4. Цикл, который уважает границы

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

Анатомия одного хода простая и строгая: сначала breaker.check(), потом вызов модели, потом ledger.write(), потом проверка stop_reason. Если модель вернула end_turn — возвращаем результат. Если нет — добавляем сообщение continue и идём на следующий круг.

Этот вариант цикла — минимальный текстовый. Если агент использует инструменты, в Anthropic API stop_reason может быть tool_use: тогда нужно выполнить инструмент, вернуть его результат в messages и только потом решать, продолжать или завершать.

Системный промпт обязательно включает все три поля спецификации, а не только done_looks_like. Модели нужна негативная область — то, что агент делать не должен (what_it_does_not), — не меньше, чем позитивная: иначе она начнёт «добавлять ценность» за рамками задачи.

Фаза 5. Поверхность согласования: цикл бежит к человеку

Circuit breaker и ledger решают технические проблемы, но не отвечают на вопрос: «Соответствует ли результат тому, что обещали?» Именно здесь ошибки проходят в прод: вывод выглядит аккуратным, дашборд зелёный, ревьюер ставит галочку.

Review surface собирает пятиэлементный фрейм из SQLite и требует явной аттестации:

1. Исходное обещание — три поля спецификации.
2. Критерий приёмки — поле done_looks_like как явный бенчмарк.
3. Diff — вход первого хода, выход последнего, число ходов, токены, сработал ли breaker.
4. Доказательства — все строки ledger за сессию.
5. Неразрешённые допущения — строки с breach_reason и failed-ходами.

После согласования ревьюер вызывает attest(). Функция собирает пятиэлементный фрейм в каноническом порядке и считает от него SHA-256 — получается frame_hash. Это аудиторская квитанция: она доказывает, что ревьюер видел именно этот фрейм, а не краткое резюме.

Практический пример: SEO-аудит по расписанию

Автор приводит пример SEO-аудита. SEO-аудит имеет естественный ритм: обход, выявление проблем, исправление, ожидание переиндексации. Запускать агента 24/7 бессмысленно — он будет сжигать токены в паузах между событиями. Честная архитектура — cron-задача, которая запускает цикл по расписанию.

Пример упрощён:
В production-варианте стоит проверять URL (допустимые схемы и хосты) и оборачивать requests.get в try/except requests.RequestException, чтобы агент не падал при недоступности сайта.

Cron-строка выглядит так:

Агент выполняет работу, записывает ходы в ledger, и если circuit breaker сработал — результат уходит на человеческую проверку, а не в прод.

Провайдер-независимость через адаптер

Цикл работает с любым клиентом, удовлетворяющим протоколу LLMClient. По умолчанию используется Anthropic, но через адаптер можно подключить OpenAI, Gemini, Ollama, локальные модели или собственный сервер. В репозитории автора показан иллюстративный пример адаптера для OpenAI. Главное — привести ответ к форме, которую ожидает AgentLoop: usage.input_tokens, usage.output_tokens, content[0].text, stop_reason.

Выводы: дисциплина дороже модели

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

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

Define what done looks like before you start. That's the job, and always has been.

Полный код и 80 тестов с 100% покрытием доступны в репозитории автора оригинала: github.com/dannwaneri/production-safe-agent-loop.

Источник: How to Build a Production-Safe Agent Loop — From Exit Conditions to Audit Trails, freeCodeCamp.

Таковы результаты ежегодного исследования компании Checkmarx — вендора инструментов для анализа безопасности приложений. В опросе участвовали 2350 разработчиков, CISO (Chief Information Security Officer) и AppSec-менеджеров (application security) по всему миру. Выборка выросла на 54% по сравнению с прошлым годом, что делает данные ещё более репрезентативными.

70% разработчиков считают ИИ-код более уязвимым, чем человеческий.

30% всех опрошенных сознательно деплоят уязвимый код в продакшен.

93% компаний пережили хотя бы один инцидент безопасности из-за уязвимых приложений.

Организации, где 81–100% кода генерируется ИИ, деплоят уязвимости в 3,4 раза чаще, чем те, где ИИ-генерация составляет 1–20%.

59% кода в продакшене — open source, который тоже не идеален с точки зрения безопасности.

ИИ пишет половину кода — и это проблема

По данным Checkmarx, сегодня примерно 49% кода в продакшене создаётся с помощью ИИ. Это немного меньше, чем 54% в прошлом году, но всё ещё колоссальная цифра. Почти каждая вторая строка в вашем приложении может быть рождена нейросетью, которая обучалась на публичных репозиториях — со всеми их багами, устаревшими паттернами и скрытыми уязвимостями.

Причина проста: языковые модели обучаются на огромных массивах существующего кода, включая устаревшие практики и известные CVE (Common Vulnerabilities and Exposures). Исследователи из University of Central Florida и Birzeit University в 2025 году провели сравнительный анализ безопасности кода, сгенерированного разными LLM для Java, Python, C и C++. C-код оказался самым дырявым, Python — относительно чистым. Но ключевой вывод исследования шире: модели «недоиспользуют современные языковые и компиляторные возможности, предпочитая устаревшие практики более безопасным альтернативам». Сами исследователи оговаривают: LLM эволюционируют быстро, и их выводы — это «снимок во времени» (time-stamped view), а не вечная истина.

Почему разработчики деплоят то, что не доверяют

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

• Давление сроков и необходимость быстро деплоить фичи.
• Уязвимости слишком сложно или дорого исправлять постфактум.
• Надежда на то, что «другие инструменты безопасности подхватят» на поздних этапах.
• Нормализация риска: когда все вокруг деплоят с багами, это перестаёт восприниматься как катастрофа.

Checkmarx прямо констатирует: «Risk is normalized» — риск стал нормой. 93% респондентов сообщили о как минимум одной бреши в безопасности, связанном с уязвимыми приложениями. В прошлом году это было 98% — статистика чуть улучшилась, но не кардинально. Когда девять из десяти компаний регулярно взламывают, инцидент перестаёт быть новостью и становится рутиной.

Объём ИИ-кода напрямую коррелирует с частотой деплоя уязвимого кода, которая, в свою очередь, коррелирует с частотой инцидентов безопасности.

Самая тревожная цифра: организации, где 81–100% кода генерируется ИИ, деплоят уязвимый код в 3,4 раза чаще, чем компании с умеренным использованием ИИ (1–20%). Это прямая корреляция: чем выше доля ИИ-генерации, тем чаще в прод попадают уязвимости. Причина не только в самом коде, но и в том, что высокая скорость разработки часто сопровождается слабыми процессами безопасности.

Open source как фундамент — и фундамент трещит

Ещё один слой проблемы — open source. По оценкам респондентов, 59% кода в продакшене приходится на открытые библиотеки. Это самооценки, но они отражают реальность: современный проект без node_modules, requirements.txt или Cargo.toml немыслим. Проблема в том, что мейнтейнеры этих библиотек часто не успевают закрывать уязвимости, а злоумышленники активно внедряют вредоносные пакеты в npm, PyPI и другие репозитории.

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

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

pickle.load выполняет произвольный Python-код при десериализации — классическая уязвимость из списка OWASP Top 10. Аналогичные проблемы часто встречаются в SQL-запросах без параметризации, использовании eval() и устаревших криптографических функциях. Проверяйте каждый snippet перед мержем.

Как не превратить ИИ-ускорение в ИИ-катастрофу

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

1. Проверяйте ИИ-код так же тщательно, как человеческий. Не предполагайте, что нейросеть знает лучше.
2. Автоматизируйте сканирование уязвимостей в CI/CD. SAST (Static Application Security Testing) и DAST (Dynamic Application Security Testing) должны быть обязательным шагом пайплайна, а не опцией.
3. Аудитируйте зависимости. Используйте инструменты вроде npm audit, Snyk или OWASP Dependency-Check.
4. Обучайте команду безопасности. Разработчики должны понимать, какие уязвимости чаще всего генерирует ИИ для вашего стека.
5. Не жертвуйте безопасностью ради скорости. Если уязвимость критична — отложите релиз. Технический долг в безопасности обходится в разы дороже, чем в производительности.

Выводы

ИИ — это не замена разработчику, а ускоритель. Как любой ускоритель, он требует тормозов. Когда 30% всех опрошенных сознательно деплоят код, в котором сами признают уязвимости, проблема не в технологиях — а в отсутствии дисциплины. Не верьте нейросети на слово: проверяйте зависимости, сканируйте код, требуйте ревью. Ускорение без контроля — это не оптимизация, а авария в замедленной съёмке.

Источник: The Register — Devs know AI code is riddled with holes, but ship it anyway

Что такое протокол передачи данных

Под протоколом передачи данных здесь понимается формат пакетов (кадров), которые строятся поверх физического уровня. Физический уровень — это уже выбранный интерфейс: RS-232, RS-485, инфракрасный канал, радиомодуль или оптоволокно. От него мы получаем две базовые операции: отправить один байт и принять один байт. Всё остальное — наша задача.

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

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

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

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

На хосте данные почти всегда буферизуются; на простых МК часто выгоднее передавать напрямую, чтобы сэкономить ОЗУ.

Структура кадра: из чего собирать пакет

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

Заголовок и концевик

Заголовок (frame header) и концевик (frame tail) отмечают границы кадра. Главное требование — минимизировать вероятность случайного совпадения этих байтов в потоке данных. Есть два подхода:

• Подбор характерных байтов. Если данные предсказуемы (например, только ASCII-текст), можно выбрать заголовок из диапазона непечатаемых символов.
• Увеличение длины. Для случайных данных лучше сделать заголовок многобайтовым — например, 0x55 0xAA 0x7E. Вероятность случайного совпадения трёх конкретных байтов подряд падает экспоненциально. Даже если совпадение произойдёт, его отловит контрольная сумма.

Адресация

Адрес назначения нужен в системах типа «один к многим» — например, когда один хост управляет несколькими датчиками по общей шине RS-485. В сложных сетях добавляют ещё и адрес источника, чтобы получатель знал, от кого пришёл пакет.

Тип, длина и данные

Тип данных (data type) говорит, что дальше идёт команда или полезная нагрузка. Длина (data length) указывает число значащих байтов в блоке данных. Вместе они образуют «тело» кадра — ту часть, которую мы действительно хотим доставить.

Контрольная сумма

Контрольная сумма проверяет целостность кадра. Простейший вариант — арифметическая сумма всех байтов тела. Для более серьёзной защиты применяют CRC (циклический избыточный код): он ловит пакетные ошибки и перестановки битов, которые простая сумма пропустит. Выбор алгоритма — компромисс между скоростью вычисления на МК и требуемой надёжностью.

Передача: хост и микроконтроллер

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

Передача с микроконтроллера

На простых контроллерах вроде семейства 8051 часто используют прямую передачу: процессор загружает байт в буфер UART и ждёт флага готовности. Плюс — данные моментально оказываются на линии. Минус — процессор занят на всё время отправки.

Альтернатива — передача по прерыванию: байты складываются в кольцевой буфер, а прерывание UART отправляет их фоном. Экономит процессорное время, но требует ОЗУ под буфер. На 8051 с его скудной памятью прямая передача часто выигрывает.

Передача с хоста

На ПК данные почти всегда буферизуются операционной системой. Программист работает с тремя уровнями абстракции:

1. Контролы ОС. В Windows — компоненты вроде MSComm (устаревший 32-bit ActiveX, не рекомендуется для новых проектов). Просто, но нужно следить за блокировками при приёме и многопоточностью.
2. Системные API. В Windows и Linux последовательный порт — это файл. Открываем через CreateFile или open(), но перед чтением и записью требуется настройка параметров порта (в Linux — termios со скоростью, чётностью и размером слова).
3. Класс-обёртка. Например, CSerialPort для Windows: он инкапсулирует инициализацию, поток приёма и отправку. После открытия порта вызов WriteToPort отправляет массив байтов, а внутренний поток следит за входящими данными и шлёт сообщения родительскому окну.

Приём и парсинг на конечном автомате

Приём данных на стороне микроконтроллера тоже бывает двух видов: опрос (поллинг) и прерывание. Опрос проще, но отнимает процессорное время. Прерывание эффективнее: байт пришёл — сработала процедура обработки прерывания (ISR, Interrupt Service Routine), процессор отвлёкся на доли миллисекунды и вернулся к задаче.

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

Пример: разбор кадра по состояниям

Рассмотрим конкретный формат кадра:

Парсер реализуем через переменную state_machine. Каждое состояние соответствует ожидаемому байту. Если пришёл не тот байт — автомат сбрасывается в ноль. Это защищает от «залипания» в промежуточном состоянии при обрыве связи или помехах.

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

Приём на стороне хоста

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

Таким образом, логика разбора протокола единая для обеих сторон. Различается только способ доставки байтов в парсер: прерывание ISR на МК и поток ОС на хосте.

Выводы

Проектирование протокола связи для микроконтроллера — это не ракетостроение, но требует дисциплины. Хороший кадр защищает границы (заголовок + концевик), адресует получателя, указывает длину и проверяет целостность. Парсинг на конечном автомате делает код предсказуемым и устойчивым к сбоям.

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

Хороший протокол — это не тот, который передаёт быстрее всех, а тот, который не ломается при помехах.

Источник: оригинальная статья Leo Liu — Microcontroller Communication Protocol Design (DEV Community).

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

Зачем вообще нужны метрики и причем тут команда разработки

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

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

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

Еще раз скажу: разработка — это «поток», а не магия.

Как мы искали идеальную метрику (и почему из семи оставили только одну)

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

1. Отработанные часы в Jira (с точностью до 15 минут — чтобы видеть, куда уходит время).
2. Индивидуальная Velocity (сжигание Story Points на конкретного разработчика).
3. Time to Market (считали от первой идеи бизнес-заказчика до продакшена).
4. Throughput (пропускная способность — сколько карточек мы закрываем).
5. WIP (лимиты на количество задач в работе).
6. DORA (метрики частоты деплоев и стабильности).
7. Cycle Time (время выполнения задачи от «In Progress» до «Done»).

Что произошло дальше? Классическое «KPI-караоке» методом перебора

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

Сначала мы попробовали трекать часы в Jira. Хотели кристальной прозрачности, но в итоге товарищи разработчки тратили по полчаса в день просто на то, чтобы вспомнить и аккуратно раскидать свои 8 часов по таскам. Мы быстро поняли, что это бессмысленная рутина, и отказались от нее.

Следующей гипотезой стала Индивидуальная Velocity. И тут сработала психология: люди (сами того не замечая) перестали брать сложные задачи или очень сильно дробили их. Зачем рисковать закопаться и испортить свою красивую статистику спринта? Вместо этого разработчики начали наперегонки разбирать легкие минорные баги. Увидев, что командная работа превращается в соревнование, мы свернули и этот эксперимент.

Дальше мы взялись за Time to Market. Ситуация стала еще абсурднее. Задача могла месяцами лежать в бэклоге, пока бизнес писал аналитику, а итоговый график TtM показывал «медленную команду». И хотя санкций не следовало, ребят это дико демотивировало — цифры выглядели так, будто мы плохо работаем. Мы осознали, что оценивать инженерию метрикой, на которую она влияет лишь частично, бессмысленно.

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

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

Мы остановились только на Cycle Time. Почему? Потому что это единственная метрика из списка, которая честно оценивает работу всей системы (процесса), а не утилизацию конкретного человека. Она показала нам, где лежат реальные проблемы в разработке, не заставляя инженеров подстраиваться под графики.

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

Значит ли наш опыт, что Throughput, WIP или DORA — это плохие метрики? Абсолютно нет. Главный вывод, который мы сделали на своих ошибках: не все метрики подходят друг другу, и не все можно безболезненно внедрять в любой момент.

У каждой команды должен быть свой эволюционный путь. Нашим ключом к выздоровлению стал Cycle Time — именно с него мы начали распутывать процессный клубок. Другой команде, возможно, жизненно необходимо прямо сейчас ввести жесткие лимиты WIP, чтобы перестать тонуть в незавершенке. Третьей — посмотреть на DORA, чтобы перестать ронять прод каждую пятницу.

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

Базовый минимум по цифрам, которые объясняют, «Почему мы не успеваем»

Cycle Time: сколько задача живёт «в работе» на самом деле

Что это такое

Cycle Time — это время от момента, когда команда действительно начала работать над задачей, до момента, когда результат можно считать завершённым (обычно — до состояния «в проде» или хотя бы Done, если релизы батчевые). В классическом определении это от входа в «In Progress» до попадания в «Done».

Когда начинается и когда заканчивается

Чтобы Cycle Time не превратился в хаос, в команде нужны чёткие правила:

· Старт цикла: задача переведена из To Do в первый «рабочий» статус — например, In Progress или «В разработке».

· Конец цикла: задача в статусе Done или «В продакшене» — главное, договориться, учитываете ли вы время релиза внутрь Cycle Time.

Важный момент: ожидание в бэклоге — это не Cycle Time, это lead time и вопросы приоритизации, поэтому «лежит в backlog две недели» не должно портить вам картину по скорости выполнения.

В чём измерять

· В большинстве продуктовых команд имеет смысл мерить Cycle Time в рабочих днях; для инцидентов и срочных багов — в часах.

· Для анализа удобно смотреть не только среднее, но и медиану и, например, 85‑й перцентиль: «половина задач закрывается за 2 дня, 85% — не дольше чем за 5 дней».

Как читать Cycle Time

Cycle Time — это не просто «2,7 дня», это ответ на вопрос: сколько времени задача проводит внутри системы разработки. Если вы видите рост Cycle Time, значит:

· где‑то появилось узкое место (ревью, тесты, деплой);

· или раздут WIP, и задачи просто толкутся в очереди.

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

К примеру, в одной из моих команд бизнес постоянно жаловался: «Разработчики делают интеграцию с новым шлюзом уже три недели, почему так долго?!». Разработчики же клялись, что код написан за пару дней. Мы включили трекинг Cycle Time с разбивкой по статусам и увидели шокирующую картину: медианное время в статусе «In Progress» (написание кода) составляло 2,5 дня.

А вот время в статусах «Code Review» и «Ожидание AppSec» (проверка безопасниками) составляло суммарно 14 дней! Задача просто лежала и ждала, пока у смежного отдела появится окно. Метрика Cycle Time спасла команду от выгорания: мы перестали давить на разработку и пошли договариваться с отделом ИБ о том, что наши фичи не такие страшные как платежи или кредиты и можно проявить немного спокойствия и лояльности(менеджерские хитрости). Скорость доставки выросла кратно.

Как внедрить Cycle Time у себя

1. Договоритесь, какие статусы считаются началом и концом работы для задач вашей команды.

2. Включите отчёт по времени в статусах в Jira/YouTrack или используйте плагины «time in status» — большинство трекеров это умеют.

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

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

Throughput: сколько готовых задач вы реально выдаете

Что это такое

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

Как измерять

· Самый простой вариант: посчитать задачи, переведённые в Done за спринт или неделю.

· Лучше разделять типы задач: фичи, баги, техдолг — иначе есть соблазн «набить Throughput» мелкими фиксками.

· После нескольких итераций можно смотреть средний Throughput и доверительные интервалы, чтобы использовать это для планирования.

Как читать Throughput

Throughput отвечает на вопрос «сколько мы реально успеваем», а не «сколько хотим успеть». Его удобно использовать так:

· для планирования спринтов: ориентироваться на прошлый Throughput вместо «оптимистичных хотелок»;

· для отслеживания тренда: если состав команды не менялся, а Throughput падает — где‑то ухудшился процесс или накопился техдолг.

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

WIP: сколько «незавершёнки» висит в системе

Что это такое

WIP (Work in Progress) — количество задач, которые уже начаты, но ещё не завершены в текущий момент. В канбан‑терминах это всё, что находится между колонками In Progress и Done.

Как измерять

Чтобы посчитать WIP, достаточно:

· определить, какие статусы считаются «в работе» — обычно это разработка, ревью, тесты, готово к релизу;

· подсчитать количество карточек в этих колонках; можно делать это ежедневно или раз в несколько часов, если хотите строить графики.

Некоторые команды дополнительно смотрят WIP в сторипоинтах — так видно не только количество задач, но и их суммарный «вес».

Как читать WIP

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

Высокий WIP = много переключений внимания, очереди перед узкими местами и затянувшийся Cycle Time. Если WIP растёт, а Throughput и число задач в Done не растут, система перегружена.

Как внедрить управление WIP

1. Явно установите WIP‑лимиты на ключевых стадиях: например, не больше 2 задач на разработчика в In Progress и не больше 5 задач в Testing.

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

3. Отслеживайте, на каких стадиях лимиты постоянно пробиваются: это хороший индикатор узких мест.

Узкие места: где «бутылочное горлышко» съедает релизы

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

Типичный симптом: в одной колонке доски скапливаются карточки, а время ожидания там непропорционально большое (например, разработка 1 день, ревью 3 дня).​

Чтобы искать такие места не на глаз, используют разбор времени по статусам (это часто умеют трекеры задач) и визуализации потока вроде value stream mapping и cumulative flow diagram (CFD).​

А есть еще что-нибудь из метрик?

Можно ли брать на вооружение другие метрики, которые не указаны в статье? Но тут как говорили классики. “Можно, а зачем?”

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

Мини‑шпаргалка (что мерить и зачем)

Как внедрять метрики и не устроить “KPI-казнь”

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

План на месяц (лёгкий, но действенный):

• Неделя 1: договориться о дефинициях (что такое “начали”, что такое “done”, включаем ли релиз).

• Неделя 2: включить сбор Cycle Time/Throughput/WIP из трекера и посмотреть, где накапливаются очереди.

• Неделя 3-4: выбрать одно узкое место и провести маленький эксперимент.

• Неделя 4: добавить DORA‑метрики из CI/CD/инцидентов и проверить баланс «скорость vs надежность».

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

• Трекеры задач (Jira, YouTrack и др.) дают доски, лимиты WIP, контроль времени в статусах и отчёты по циклу задач, если команда честно обновляет статусы.
• CI/CD‑системы (GitLab CI/CD, GitHub Actions и т.п.) автоматизируют сборку, тестирование и деплой, убирая ручные узкие места и зависимость от «того самого человека, который умеет катить релизы».
• Мониторинг и observability‑платформы помогают быстро находить проблемы в продакшене и снижать MTTR, чтобы команда меньше жила в режиме бесконечных пожаротушений.

ESLint — это де-факто стандарт статического анализа JavaScript-кода. Инструмент работает поверх Node.js и V8, поддерживает сотни плагинов и позволяет настраивать правила под любой проект. По данным опроса State of JavaScript 2025, ESLint остаётся самым популярным вспомогательным инструментом среди фронтенд-разработчиков.

Новый проект развивается в рамках экосистемы Oxc, поддерживаемой командой VoidZero.

Oxlint на Rust обгоняет ESLint в 50–100 раз на крупных репозиториях вроде Vue Core и React Router.

Из коробки включено 107 правил, тогда как ESLint требует ручной настройки даже для базовых сценариев.

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

Миграция возможна постепенно: оба линтера можно запускать параллельно.

Если ваш проект завязан на редкие плагины или пользовательские правила — спешить не стоит.

Почему ESLint начинает раздражать

Несмотря на зрелость экосистемы, у ESLint накопился приличный багаж архитектурных ограничений:

• Производительность. Код ESLint выполняется в однопоточном режиме поверх JavaScript-движка. В небольших проектах это незаметно, но в монорепозиториях с сотнями тысяч строк проверка легко растягивается на две минуты и больше.
• Конфигурационный ад. Новичкам приходится разбираться в иерархии конфигов, flat config, shared presets и compatibility layers. Документация исчерпывающая, но порог входа остаётся высоким.
• Минимум из коробки. Базовая установка ESLint практически ничего не проверяет. Для получения хоть какой-то пользы нужно ставить плагины, изучать правила и собирать конфигурацию с нуля — в отличие от Prettier или Biome, которые работают сразу после установки.

Чем Oxlint лучше привычного линтера

Скорость, которую можно измерить

Главное преимущество Oxlint — скорость. В тестах на репозитории Vue Core с type-aware правилами Oxlint справляется за 1,3 секунды, тогда как ESLint с typescript-eslint тратит 133,8 секунды. Это почти в 100 раз быстрее. На репозитории React Router разрыв меньше, но всё равно впечатляет: 435 мс против 29,5 с — ускорение в 68 раз.

Type-aware линтинг без тормозов

ESLint для type-aware правил использует typescript-eslint, который перед проверкой запускает полный анализ через tsc. Это наследует все накладные расходы компилятора TypeScript. Oxlint делает это иначе: type-aware функциональность реализована через oxlint-tsgolint на Go, который в связке с TypeScript 7 и компилятором tsgo работает в 20–40 раз быстрее привычного пайплайна.

Настройка за минуту, а не за час

После установки Oxlint сразу активирует 107 правил. Конфигурация проще, документация понятнее, а сообщения об ошибках структурированы так, что и человек, и LLM-ассистент разберутся с первого взгляда.

Постепенная миграция без боли

Oxlint не требует выбросить ESLint в один день. Инструменты можно запускать параллельно: Oxlint берёт быструю проверку на pre-commit, а ESLint остаётся в CI до полного перехода. Экспериментальная поддержка JavaScript-плагинов ESLint уже работает, хотя и не покрывает всю экосистему.

Реальные цифры: бенчмарки на популярных репозиториях

Автор оригинального материала воспроизвёл тесты на ноутбуке HP EliteBook 1040 G7 (16 ГБ ОЗУ, 4 физических ядра, 8 потоков). Результаты для Vue Core с type-aware правилами:

Результаты для React Router (без type-aware правил):

Цифры подтверждают заявленные разработчиками 50–100-кратное ускорение. Для разработчика это разница между «пойду за кофе, пока линтер работает» и «результат на экране мгновенно».

Когда ESLint всё ещё нужен

Несмотря на впечатляющие цифры, спешить со сносом ESLint не всегда разумно. Вот сценарии, где старый инструмент остаётся предпочтительнее:

• Редкие плагины и пользовательские правила. Если ваш проект завязан на специфические ESLint-плагины, которых ещё нет в Oxlint, миграция потребует дополнительной работы.
• Малые проекты. В репозиториях до 10–20 тысяч строк разница между 1 секундой и 30 секундами линтинга не критична.
• Сложные рабочие процессы. Глубокая интеграция ESLint в CI/CD, пользовательские форматтеры и специфические пайплайны могут быть дорого переносить.
• Сообщество и экосистема. ESLint остаётся доминирующим линтером. Вокруг него больше обучающих материалов, примеров конфигураций и поддержки со стороны LLM-ассистентов.

Как мигрировать с ESLint на Oxlint

Команда Oxlint подготовила утилиту @oxlint/migrate, которая автоматически преобразует конфигурацию ESLint в формат Oxlint. Выбор пути зависит от текущего состояния проекта:

1. Для ESLint v9/v10+ с flat config: запустите npx @oxlint/migrate — утилита преобразует поддерживаемые правила и сообщит о несовместимых.
2. Для ESLint v8 и старше (в v10 поддержка legacy-конфигов полностью удалена): сначала мигрируйте на flat config через npx @eslint/migrate-config, затем примените @oxlint/migrate.
3. Если нужны type-aware правила: добавьте флаг --type-aware к команде npx @oxlint/migrate и установите oxlint-tsgolint.
4. Для экспериментальной поддержки JS-плагинов: используйте флаг --js-plugins в команде npx @oxlint/migrate.
5. Не уверены в безопасности? Запустите оба линтера параллельно на несколько недель и сравните результаты.

Совет:
Начните миграцию с новых модулей или микрофронтендов, а не с устаревшего кода, где линтер и так давно отключён.

Выводы

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

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

Источник: LogRocket — Retire ESLint: How (and why) to migrate to Oxlint

Репозиторий проекта: github.com/oxc-project/oxc. Документация: oxc.rs.

Попробуйте запустить npx @oxlint/migrate на своём проекте и сравните цифры. Возможно, вы больше никогда не захотите ждать, пока закончится npm run lint.

О том, в каких точках жизненного цикла проекта QA приносит максимальную пользу и как инженерный подход помогает предотвращать критические ошибки, рассказывает Екатерина Акименко, ведущий QA-инженер Embedika.

Анализ требований как способ снизить стоимость ошибок

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

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

• Согласованность: насколько новое требование стыкуется с общей логикой и уже работающими модулями системы?
• Техническая реализуемость: возможно ли воплотить задуманное без «костылей» в рамках текущих ограничений платформы?
• Влияние на данные: как изменение повлияет на целостность данных, интеграции и существующие бизнес-процессы?
• Риск-менеджмент: какие скрытые угрозы и неочевидные ограничения несет в себе эта реализация?

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

Проверка проектных решений и пользовательских сценариев

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

1. Соответствие бизнес-цели. Если интерфейс перенаправляет пользователя в общий реестр вместо карточки только что созданного объекта — это дефект соответствия, даже если технически всё сработало без ошибок. Пользователь теряет контекст и вынужден искать объект вручную, что противоречит исходной постановке.
2. Консистентность и логика. В крупных продуктах формируются единые принципы навигации и UI-гайды. Если во всех разделах кнопка сохранения находится вверху, а в новой фиче она переезжает вниз, QA подсвечивает это как нарушение консистентности пользовательского опыта и внутренних продуктовых стандартов. Сюда же относится путаница в терминологии: нельзя использовать «Применить» в одном месте и «Сохранить» в другом для идентичных действий.
3. Общепринятые паттерны. Существуют универсальные правила юзабилити и доступности. Если кнопка удаления оформлена зеленым цветом, это вводит в заблуждение, так как цвет ассоциируется с подтверждением или запуском. Форма, требующая обязательного заполнения поля без соответствующей маркировки, — еще один пример нарушения базовых практик.
4. Безопасность действий. Выполнение критических операций (удаление данных, изменение прав) без подтверждения — QA должен подсветить архитектурный риск до того, как он станет дорогостоящей проблемой в продакшене.

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

Тестирование в активной фазе: что проверяет QA проверяет помимо функциональности

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

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

Ответственность за релиз

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

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

Поддержка, анализ инцидентов и влияние на архитектуру

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

В качестве примера можно привести кейс с падением таск-трекера, управлявшего массовыми операциями. Во время тестирования массовые операции работали стабильно, однако в продакшене система столкнулась с реальной конкурентной нагрузкой. Пользователи запускали параллельные операции по одним и тем же сущностям, что приводило к race conditions и переполнению очередей. Анализ логов и трассировок показал, что архитектура не предусматривала ограничения конкурентного выполнения. Для решения проблемы команде пришлось внедрить throttling и переработать механизм обработки очередей. Решение проблемы потребовало архитектурных доработок: внедрения механизмов защиты от параллельного запуска (throttling) и переработки логики обработки очередей.

Другой пример связан с интеграцией через внешнюю платформу, которая исправно функционировала в течение года. С ростом объема данных обмен начал прерываться с нечитаемыми ошибками. Анализ сетевого взаимодействия и логов интеграции показал, что размер сообщений превысил жесткий лимит внешней платформы в 5МБ. Проблема заключалась в том, что первоначальная схема обмена не учитывала рост объема данных и ограничения внешней платформы. Результатом стала разработка нового формата обмена с пакетированием данных.

Вектор на инженерию

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

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

Vim Classic — это форк текстового редактора Vim, поддерживаемый без помощи генеративного ИИ. Проект возглавляет известный разработчик open source Дрю Дево (Drew DeVault). Цель форка — сохранить и поддерживать классическую версию Vim, которую считают стабильной и предсказуемой.

Релиз Vim Classic 8.3.0 основан на Vim 8.2.0148. Разработчики консервативно перенесли (бэкпортировали) исправления ошибок и патчи безопасности из последующих версий оригинального Vim. При этом в форке намеренно не используется Vim9 script — относительно новый диалект скриптования, который появился в Vim 9 и вызвал дискуссии в сообществе.

Vim Classic 8.3.0 — стабильный LTS-форк классического Vim от Drew DeVault.

Основан на Vim 8.2.0148 с бэкпортом багфиксов и патчей безопасности.

В форке намеренно нет Vim9 script — только классический синтаксис.

Отдельные плагины могут быть несовместимы из-за отсутствия новых фич.

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

Почему появился форк

В 2022 году Bram Moolenaar выпустил Vim 9 с новым диалектом Vim9 script. Он обещал прирост производительности в 10–100 раз по сравнению с классического скриптования. При этом новый диалект не обеспечил полную обратную совместимость, поэтому для полного использования преимуществ плагины желательно адаптировать. Часть сообщества восприняла это как разрыв с традициями.

Drew DeVault, создатель платформы SourceHut и автор оконного менеджера Sway, предложил альтернативу: взять проверенную базу Vim 8.2, аккуратно добавить важные исправления и выпустить её как Vim 8.3 — ту версию, которой, по его мнению, мог бы быть Vim без революционных изменений.

Что внутри Vim Classic 8.3

• Стабильная кодовая база Vim 8.2.0148.
• Перенесённые патчи безопасности (CVE, выявленные между версиями 8.2 и современным Vim).
• Сохранение классического скриптового движка без Vim9 script.
• Поддержка благотворительности в Уганде (charityware), как и в оригинальном Vim.

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

FAQ

Выводы

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

Мы представляем альтернативную историю, в которой Vim 8.3 был выпущен без Vim9 script.

Источник: vim-classic.org

AI Engineer работает на прикладном слое: берёт готовые модели и превращает их в продукты, которыми пользуются реальные люди. Не обучает модели с нуля — делает так, чтобы они не врали пользователям в продакшене.

• AI Engineer — не ML-инженер и не fullstack-разработчик. Это прикладная дисциплина между моделью и пользователем.
• Главная задача — превратить демо в надёжную систему: цикл build-eval-improve (сборка, оценка, улучшение) никогда не заканчивается.
• Четыре ключевых навыка: RAG, evals, агенты и продакшен-деплой.
• OpenAI и другие лидеры уже нанимают целые команды под отдельные подсистемы агентов.
• Самое сложное — не код, а выбор правильных метрик для оценки качества.

Демо собрать легко. Надёжность — работа

Собрать демо с LLM проще простого. Пять минут «вайб-кодинга», чистый промпт, happy path (основной сценарий) — и у вас есть ролик, достойный твита. Но стоит бросить в промпт три нестандартных запроса, и всё рассыпается. Потому что LLM — не интеллект, а предиктор. Вся работа AI Engineer сидит в промежутке между «классно демонстрируется» и «не падает в продакшене».

Если система ненадёжна, она бесполезна. Этот разрыв — полноценная рабочая задача, а не побочная обязанность fullstack-разработчика.

AI Engineer и ML-инженер: в чём разница

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

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

Четыре навыка, которые встречаются в вакансиях

Автор статьи проанализировал вакансии AI Engineer на LinkedIn. Четыре навыка всплывали снова и снова:

• RAG — поиск по векторным базам и контексту
• Evals — оценка качества ответов модели
• Агенты — системы, которые вызывают инструменты и принимают решения
• Продакшен-деплой — запуск в реальную эксплуатацию

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

Цикл сборки, оценки и улучшения

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

Этот цикл никогда не заканчивается. Для недетерминированной системы, которая должна быть надёжной, нет статуса «готово». Есть только итерация. Программист оптимизирует детерминированные пути. ML-инженер оптимизирует модель. AI Engineer оптимизирует цикл обратной связи поверх недетерминированной системы, и большая часть результата — в том, что именно измерять.

Почему это целая команда, а не один человек

Если AI Engineer — всего лишь побочная обязанность fullstack-разработчика, посмотрите на вакансии OpenAI. Они нанимают людей не абстрактно, а под конкретные подсистемы: одна команда отвечает за выбор инструментов, другая за human-in-the-loop, третья — за безопасность, а четвёртая — за снижение расхода токенов без потери точности.

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

Самое сложное — выбрать метрики

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

Неправильные метрики ведут цикл в никуда. Правильные — запускают накопительный эффект. В этом — суть роли: оптимизировать обратную связь, а не просто писать код.

Выводы

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

Агент — это лёгкая часть. Цикл — это работа.

Источник: Frontend Masters — AI Engineer Is a New Role

В agile-средах расползание объёма (scope creep) начинается тогда, когда продакт-менеджер теряет из виду цель и аудиторию. В попытке впихнуть в продукт побольше функций «чтобы всем угодить» команда каменеет, как от взгляда Медузы Горгоны: больше никакой гибкости, остаётся либо погибнуть в analysis paralysis, либо вязнуть в болоте.

• Хорошие проектные менеджеры закладывают в план буфер на 15–30% незапланированной работы; скрам-команды планируют только 70–80% мощности спринта.
• Расширять объём стоит, если новая фича повышает удовлетворённость клиента, ускоряется через AI-инструменты или работает как «множитель силы» — открывает возможности с отдачей минимум 10x.
• AI-инструменты вроде Claude Code, Figma Make, Gemini, NotebookLM и ChatGPT помогают доставить больше за то же время — это и превращает scope creep в управляемую гибкость.
• Главный тест: «то же усилие — лучший результат». Если для нового пункта нужно столько же часов, сколько на исходные фичи, это не хорошее расползание, а просто новая работа.
• Guardrails против перегрузки: формальный change management, защита буфера, лимит расширения объёма (например, 20% сверх MVP) и мониторинг выгорания команды.

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

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

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

Зачем продуктовым командам нужен буфер мощности

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

Хорошие проектные менеджеры резервируют около 15–30% общей длительности или мощности проекта под незапланированную работу. Аналогично скрам-команда планирует на спринт только 70–80% своих мощностей, оставляя 20–30% на непредвиденные баги и изменения объёма.

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

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

Когда стоит расширять объём

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

Рост удовлетворённости клиентов

В недавнем проекте мы выкатили 22% post-MVP требований уже на момент сдачи MVP — перенесли вперёд то, что иначе попало бы в следующие релизы.

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

Делать это было необязательно, но в обоих случаях расширение объёма имело смысл — оно повышало удовлетворённость клиента.

Чёткие компромиссы в дорожной карте

Сказать «да» одной задаче должно по умолчанию означать «нет» какой-то другой.

Что вы готовы выменять, чтобы взять в работу новый пункт? Как использовать новый объём себе на пользу?

Ускорение разработки через AI-инструменты

Расползание объёма почти не проблема, если у вас неограниченные ресурсы — но это нереалистично.

Вместо того чтобы доводить команду до медленного кипения, используйте AI-инструменты для ускорения выхода на рынок: Claude Code, Figma Make, Gemini, NotebookLM, ChatGPT.

Подключите дизайнеров и продактов к vibe coding (создание прототипов через диалог с AI-инструментом) вместе с разработчиками — и наблюдайте, как растут мораль, увлечённость и пропускная способность команды.

Возможности-множители (force multipliers)

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

Например, дождаться API-фида данных вместо ручной синхронизации файлов. Но как общее правило: расширяйте объём только под то, что даёт минимум 10x отдачу.

Давление тайминга на рынке

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

Опровергнутые предположения о пользователях

Если вы используете hypothesis-driven development (разработка через проверку гипотез о пользователях) и наблюдаемое поведение или фидбэк опровергают гипотезу, имеет смысл сдвинуть рамки под реальную потребность — а не упрямо продолжать строить не то.

Реальный пример контролируемого расширения объёма

Когда в прошлом году Figma выкатила бета-версию Figma Make, я бросилась подключать команду к раннему доступу. Этот новый инструмент на базе LLM позволял запросить у Figma не просто дизайн, а полноценный концепт: он выдавал прототипы для быстрого тестирования на клиентах и frontend-ready код, ускоряющий работу разработчиков.

До этого мы играли с другими инструментами вроде Firebase и Loveable, но именно Figma Make оказался самым ожидаемым релизом.

Figma анонсировала постепенную раскатку — я проверяла доступ по нескольку раз в день, и наконец — та-дам! Это было как получить волшебную палочку.

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

Единственная проблема? Инструмент оказался слишком хорош. Часть идей из vibe coding-сессий была настолько продвинутой, что с самого начала было понятно: мы не сможем реализовать даже половину видения.

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

Guardrails: ограничители для управления расширением объёма

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

Формальный процесс change management

Документируйте каждое дополнение через лёгкий change request. Фиксируйте, что добавляется, как это служит стратегической цели и какие компромиссы вы принимаете. Это предотвращает бессознательный дрейф и создаёт ответственность за решения.

Берегите буфер мощности

Если вы уже выбрали 25% своего буфера, добавление нового объёма становится рискованным. Резерв нужен под реальные форс-мажоры, а не только под возможности. Защищайте буфер!

Тест «то же усилие — лучший результат»

Инструменты-ускорители вроде Claude Code и Figma Make должны позволять выпускать больше ценности без пропорционального роста усилий.

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

Лимит на расширение объёма

Установите максимальный порог (например, не более 20% сверх требований MVP).

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

Мониторинг сигналов выгорания

Регулярные one-to-one с командой про нагрузку и моральное состояние — обязательное условие. Если расширенный объём выливается в шестидесятичасовые недели и сессии в туалете со слезами, это уже не контролируемое расширение — это неустойчивая перегрузка.

Хорошее расползание объёма должно заряжать команду, а не выматывать.

Заключение

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

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

С современными AI-инструментами расползание объёма больше не обязано означать сожжённую мощность разработки. Дайте команде правильные опоры — и каждый сможет активно участвовать в доставке. Соблюдайте guardrails — и сможете заменить цинизм оптимизмом: будете знать, что добавление фичи — это умное стратегическое решение, а не компульсивное «лишь бы согласиться».

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

Оригинал статьи: How to rethink scope creep as strategic flexibility — Кимберли Шу, LogRocket Blog.

Хотя до этого ни с какой тысячью, да даже с пятьюстами нашему агентству ещё сталкиваться не приходилось. Но я был уверен в себе и своей команде. Команда у меня по умолчанию классная, а сам я в последнее время неплохо так себя прокачал: подтянул навык переговоров и лидерские качества, активно выстраиваю процессы в компании, потихоньку вайб-кодю. Так что решил, что потяну.

Как всё начиналось

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

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

А ещё скинул официальный регламент, в котором просил обозначить: как будут храниться персональные данные гостей, какое шифрование, у кого есть доступ к базе, какой регламент при утечке и соответствует ли система требованиям ФЗ-152. Я сел разбираться.

… и перевёл с корпоративного на человеческий

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

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

Вопрос про шифрование поначалу вообще казался мне каким-то птичьим языком. Оказалось, что речь про то, передаются ли данные по защищённому соединению. Я проверил — с соединением всё было в порядке, https стоял.

Про ФЗ-152. Он же Федеральный закон о персональных данных. Если ты собираешь у людей имена, телефоны и почту (а любая форма регистрации на то и рассчитана), ты автоматически становишься оператором персональных данных. Со всеми вытекающими: нужно уведомить Роскомнадзор, разместить на сайте политику конфиденциальности, получить у пользователей явное согласие на обработку данных.

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

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

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

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

Что в итоге

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

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

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

• понимать, как устроена ИТ-инфраструктура, чтобы управлять ею (а не кодить её самому);
• оценивать реальные риски безопасности и соответствие законам;
• знать, какие вопросы задавать техническому специалисту, когда подрядчик или штатный разработчик предлагает решение;
• выстроить процессы так, чтобы крупный проект не развалился из-за моей же неопытности в управлении.

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

Как раз для таких предпринимателей и существует курс «ИТ-директор». Что там внутри — подсвечивать не буду, если надо, сами разберётесь. А вот для себя уже подметил суперважные моменты про айти-инфраструктуру в контексте управления и рисков. Ещё впереди 4 созвона с техническим директором. Может, тоже что-нибудь расскажу, если что-то полезное вынесу.

По промокоду ДИРЕКТОР на данный момент доступна скидка 65% + открывают доступ ко второму курсу сверху. Если нужно уберечь себя от критичных ошибок, то лучшего варианта, чем обучиться заранее, не найти!

Реклама. Рекламодатель: ООО «Эдюсон» ИНН 7729779476, erid: 2W5zFHCCh5K

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

• Базовый линтинг (ESLint) с правилами под ИИ-ошибки — дешёвый и эффективный сенсор, которого раньше избегали из-за накладных расходов
• Кастомные lint-сообщения с инструкциями по самокоррекции заметно меняют поведение агента
• Правила зависимостей (dependency-cruiser) надёжно держат архитектурные слои — хорошая замена markdown-гайдам
• Метрики связанности (coupling data) мало полезны ИИ сами по себе: нужна семантическая интерпретация
• ИИ-ревью модульности находит реальные архитектурные проблемы, накопленные агентами, — даже без coupling-данных

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

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

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

Приложение

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

Стек: TypeScript, Next.js и React. Бэкенд читает и объединяет данные из API. Приложение существует давно, но для этих экспериментов я пересобрала его с нуля с помощью ИИ. Гайдов для ИИ о качестве кода и поддерживаемости почти нет — хотелось понять, насколько хорошо агент справляется, опираясь только на обратную связь от сенсоров.

Обзор всех используемых сенсоров

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

Во время сессии кодирования — сенсоры с непрерывной быстрой обратной связью:

• Проверка типов (вычислительный)
• ESLint (вычислительный)
• Semgrep — SAST-инструмент, предписанный внутренней командой AppSec (вычислительный)
• dependency-cruiser — структурные правила для внутренних модульных зависимостей (вычислительный)
• Результаты тест-сьюта с покрытием (вычислительный, хотя тест-сьют генерируется ИИ — то есть создаётся инференциально)
• Инкрементальное мутационное тестирование (вычислительный)
• GitLeaks в pre-commit хуке — тоже считаю сенсором, потому что даёт обратную связь, когда агент пытается сделать коммит (вычислительный)

После интеграции — пайплайн. Те же вычислительные сенсоры запускаются в CI. Внутрисессионные сенсоры дают агенту раннюю обратную связь, CI подтверждает результат на чистой инфраструктуре и после интеграции.

Периодически — сенсоры с медленным циклом для обнаружения накапливающегося дрейфа:

• Ревью безопасности: промпт из чеклиста AppSec для внутренних приложений (инференциальный)
• Ревью обработки данных: промпт описывает вещи вроде «имена пользователей не должны отправляться на фронтенд» (инференциальный)
• Отчёт о свежести зависимостей: скрипт собирает возраст и активность библиотек, ИИ создаёт отчёт с рекомендациями (вычислительный + инференциальный)
• Ревью модульности и связанности (вычислительный + инференциальный)

Базовые харнесы и модели

На протяжении всей работы я использовала смесь Cursor, Claude Code и OpenCode (в порядке убывания частоты). Основной моделью обычно был Claude Sonnet, для планирования и анализа — Claude Opus, для задач реализации — часто Cursor composer-2.

Статический анализ: базовый линтинг

Начнём с опыта использования ESLint в этом приложении. Базовые линтеры вроде ESLint в основном нацелены на риски поддерживаемости на уровне отдельных файлов и функций.

Правила под типичные ИИ-ошибки

На мой взгляд, самые очевидные мишени для статического анализа — это типичные сбои ИИ:

• Максимальное количество аргументов у функций
• Длина файла
• Длина функции
• Цикломатическая сложность

Однако всё это не было активировано в ESLint-пресете по умолчанию — пришлось настраивать лимиты вручную. Хочется верить, что инструменты статического анализа постепенно предложат лучшие пресеты для работы с ИИ. Небольшое исследование показало, что люди уже начали публиковать ESLint-плагины с наборами правил, специально нацеленными на известные сбои агентов, — например, Factory с правилами о наличии тест-файлов или структурированного логирования.

Руководство для самокоррекции

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

Вот пример руководства для предупреждения no-explicit-any:

Управление предупреждениями: теперь реально?

Статический анализ существует давно, но команды нередко применяли его непоследовательно, даже если инструмент был настроен. Одна из причин — накладные расходы на управление. Эффективное использование требует «чистого дома»: иначе метрики превращаются в шум. Особенно сложны предупреждения вроде no-explicit-any: не всегда нужно их исправлять — это ситуативно. А подавлять их по одному всегда казалось муторным.

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

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

Наблюдения

• Изучение исключений, которые создавал ИИ (подавленные предупреждения, увеличенные пороги), стало отличной отправной точкой для моего код-ревью.
• ИИ часто решал увеличить порог цикломатической сложности, но предлагал хорошие рефакторинги, когда я его дополнительно подталкивала. Это единственная категория, где он так делал — и позже я обнаружила, что не включила для неё руководство по самокоррекции. Индикатор того, что кастомные lint-сообщения действительно имеют значение.
• Иногда правила нужно применять по-разному в разных частях кода. Например, no-console: на бэкенде я хочу, чтобы ИИ использовал компонент логгера; на фронтенде — чтобы не использовал прямое логирование или применял другой компонент. Это ещё один пример силы руководства по самокоррекции и того, где ИИ помогает с семантическими суждениями.
• Наблюдала случаи компромисса между правилами: max-lines и max-lines-per-function. ИИ делал полезные рефакторинги, разбивая код на меньшие функции и компоненты. Однако в React-фронтенде возникла тревожная тенденция: компоненты с огромным количеством свойств, через которые значения передаются по нарастающей цепочке всё более мелких компонентов.

Главные выводы

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

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

Статический анализ: правила зависимостей

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

Для изучения потенциала сенсоров модульности я исследовала три области:

• Правила зависимостей (детерминированный подход)
• Анализ связанности (детерминированный + инференциальный)
• Ревью модульности (инференциальный)

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

Одно из правил, например, обеспечивает, чтобы код в папке clients никогда не импортировал ничего из папки services:

Как и с сообщениями ESLint, сообщения об ошибках я расширила до руководств по самокоррекции, кратко пересказывающих концепцию слоёв:

Наблюдения

• Без ИИ настроить эти правила быстро было бы нереально: у инструмента высокий порог входа, и ИИ почти полностью поглотил эти затраты.
• Агент нарушал правила несколько раз после их введения, но каждый раз самостоятельно исправлялся на основе обратной связи от dependency-cruiser — инструмент действительно помог удерживать концепции папок.
• Тот же подход применила для структуры React-хуков на фронтенде.
• Пришлось разобраться, как ловить ситуации, когда ИИ создаёт новые папки за пределами заданной структуры — с правилом, требующим, чтобы каждый новый файл находился в предопределённой структуре папок.

Главные выводы

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

Статический анализ: данные о связанности

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

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

Для людей

Большинство визуализаций — это известные концепции вроде матрицы структуры зависимостей (DSM). Они оказались утомительными в интерпретации. Мне кажется, детальные данные о связанности требуют много контекста и опыта для интерпретации и соотнесения с практиками высокого уровня. Поэтому у меня ощущение, что инструменты этого типа всё равно не сильно снизят когнитивную нагрузку человека при проверке кодовых баз, изменённых ИИ.

Для ИИ

Я дала агенту доступ к кастомному CLI (coupling-analyser) и попросила создать отчёт на основе данных с предложениями по улучшению. Важно: агенту не давалось чёткого определения «хорошей» и «плохой» модульности — интерпретация была делегирована модели.

Создай markdown-отчёт о модульности и качестве связанности для целевой TypeScript-кодовой базы, основанный на реальных данных CLI из npx coupling-analyser, а не на догадках от статического просмотра кода.

Наблюдения

Результаты оказались довольно слабыми (использовался Claude Opus 4.7):

• Как одну из главных проблем ИИ назвал фабрику, инициализирующую все необходимые компоненты — хотя она была намеренно введена как лёгкий фреймворк внедрения зависимостей.
• Другой «проблемой» оказалась общая схема (zod) между фронтендом и бэкендом, объявленная ИИ «God-модулем». Это распространённый паттерн для создания явного контракта между клиентом и сервером — не проблема, когда они эволюционируют вместе.
• Когда легитимные паттерны выглядят как хабы с высокой связанностью, нужен способ исключать их из будущих анализов — иначе это просто шум.
• Одна интересная находка: файл index.ts в папке domain без разбора экспортировал все файлы из ./domain и импортировался множеством мест. Распространённый паттерн для создания явных контрактов слоя, но у него есть плюсы и минусы — стоит разобраться, уместен ли он.

Главные выводы

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

Более практичное применение — приоритизация рисков при код-ревью. Зная радиус влияния изменённых файлов, можно уделять больше внимания, если меняется файл с 10+ зависимыми. Агент ревью мог бы использовать эти данные для расстановки приоритетов.

Статический анализ: ИИ-ревью модульности

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

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

Наблюдения

Основные находки (Claude Opus 4.7, как и для анализа связанности):

• Дублирование кода роутов — три бэкенд-эндпойнта имели почти идентичные реализации. При желании изменить общий принцип API (например, добавить request ID или изменить подход к логированию ошибок) потребовалось бы менять несколько файлов. Агенты обычно не начинают рефакторинг без явного указания, копируя паттерн третий-четвёртый раз.
• Несоответствие в вызовах бэкенда — семантическое дублирование. Три страницы приложения вызывают бэкенд с одним набором параметров. Две страницы использовали одинаковый хук и подход, но при создании третьей ИИ отклонился и переосуществил аналогичное поведение по-своему. Это ведёт к несоответствиям в обработке ошибок и необходимости менять несколько файлов при изменении API.
• Неэффективная передача ключевых аргументов — параметры chat space ID и диапазон дат передаются через 40+ файлов. Ревью подтвердило проблему: «Issue: Request parameters repeated at every level». ИИ уже частично решил её, но никогда не довёл до конца, создав непоследовательный беспорядок.
• Ответственности не на своём месте — код аутентификации оказался внутри фабрики, отвечающей только за сборку модулей. Неожиданное место создаёт риск пропустить это при добавлении новых роутов.
• Лучшая интерпретация «хабов» с высоким импортом — в отличие от анализа данных связанности, ИИ при полном чтении кода замечал, что хабы с высокими показателями оправданы в контексте приложения. Это связано либо с качеством промптинга, либо с тем, что анализ читал сам код.

Главные выводы

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

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

Выводы

Böckeler продолжает эксперименты: следующая часть статьи будет посвящена роли регрессионного тестирования как сенсора, а также опыту с покрытием и мутационным тестированием ИИ-сгенерированных тест-сьютов.

Главный вывод этих экспериментов: вычислительные сенсоры снижают порог входа в статический анализ — ИИ берёт на себя настройку инструментов с высоким порогом входа (dependency-cruiser, кастомные форматтеры). Но ни один детерминированный инструмент в одиночку не даст полной картины поддерживаемости. Необходима комбинация: линтинг — правила зависимостей — периодическое ИИ-ревью модульности.

Оригинал статьи опубликован 19–20 мая 2026 года на martinfowler.com. Следующая часть выйдет в том же месте.

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

• Промпт — задание, не процесс: без бэклога, критериев готовности и ревью-гейтов агент дрейфует
• Документация (CLAUDE.md, AGENTS.md, STYLE.md) — интерфейс между человеком и агентом, а не README для людей
• Тикет с acceptance criteria — контракт выполнения: агент работает против спецификации, а не открытого промпта
• Governance с первого дня: CI/CD, линтер и автотесты — первый тикет в бэклоге, не последний
• Ретроспектива с агентом: анализ git-логов и PR-комментариев помогает найти, где процесс ломается

Почему промпт не масштабируется

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

• Нет бэклога — работа обнаруживается в процессе реализации, а не планируется заранее
• Нет понятия «готово» — сессия заканчивается, когда разработчик доволен, а не когда выполнен контракт
• Нет поэтапной доставки — всё делается сразу, без возможности остановиться и переориентировать
• Нет governance — ограничения безопасности и правила валидации добавляются в конце, если добавляются вообще

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

Плохая система победит хорошего человека — или агента — в любое время.

Документация как интерфейс между людьми и агентами

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

Типичный набор файлов в репозитории, использующем эту методологию:

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

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

Агент как участник команды, а не инструмент

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

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

Та же инженерная дисциплина, которая не позволяет человеческим командам выкатывать сломанное ПО, применима и к командам «человек + агент»: структурированное планирование, чёткие acceptance criteria, инкрементальная доставка и ревью-гейты.

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

Тикеты со спецификацией вместо открытых промптов

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

Шаблон agentic story включает:

• Summary — одно предложение: что именно доставляет эта история
• Scope — явный список файлов, которых касается история (предотвращает конфликты при параллельной работе агентов)
• Acceptance Criteria — конкретные, проверяемые условия, которые должны выполняться по завершении
• Negative Constraints — что история явно НЕ делает (предотвращает scope creep)
• File Ownership — карта владельца каждого файла в этой волне (critical для multi-agent parallelism)

Ключевая идея: агент работает против спецификации, а не открытого промпта. Условие завершения — не «хватит» или «мне нравится», а «контракт выполнен». Это устраняет «good enough» culture, которая иначе просачивается в каждую агентную сессию.

Волновое планирование для параллельной работы

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

Каждая волна — это набор историй, которые можно безопасно выполнять параллельно (нет конфликтов по файлам и контрактам). Между волнами — ревью-гейт: интеграция результатов, запуск CI, проверка инвариантов. Только после прохождения гейта запускается следующая волна.

В секции File Ownership тикета явно прописано: этот файл принадлежит данной истории в данной волне. Никакая другая история в той же волне не должна его касаться. Это не договорённость — это часть спецификации.

Governance с первого дня, а не в конце

Самая дорогостоящая ошибка при agentic-разработке — отложить governance на потом. Governance в этом контексте — это система контрольных гейтов: ограничения безопасности, правила валидации, обязательные ревью и автотесты. «Сначала поймём, что строим, потом добавим гардрейлы» — в человеческой разработке это спорно, в агентной — катастрофично. Агенты принимают решения на скорости выполнения, и без явных ограничений они успевают нарушить архитектурные инварианты или создать уязвимости задолго до того, как человек это заметит. Microsoft столкнулась с этим в собственном проекте: CI-пайплайн не был первой историей в бэклоге, и к моменту его добавления уже накопились проблемы, основанные на допущениях, которые никто не проверял. Это потребовало вернуться и переделать несколько фич.

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

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

• Ограничения безопасности — это acceptance criteria в тикетах, не отдельная фаза
• Ревью-гейты стоят между волнами выполнения, не в конце проекта
• CI/CD, линтер и автотесты — первая история, которую реализует команда
• Ревью «найди всё плохое» (adversarial code review) на каждой волне — агент специально проверяет свой код на уязвимости и несоответствие контрактам, а не просто убеждается, что «всё работает»

Ретроспектива с агентом

После нескольких волн разработки команда Microsoft ввела ретроспективный процесс: агент анализирует файлы сессий, git-логи, PR-комментарии и другие данные, ищет паттерны сбоев и формулирует конкретные рекомендации по процессу. Например: «в волне 3 у нас было 4 конфликта по файлу X — в следующей волне разбить его на два отдельных владельца» или «acceptance criteria в 6 историях не были проверяемы автотестами — нужен шаблон с обязательным полем test_coverage».

Это замыкает петлю: агент не только выполняет работу, но и участвует в анализе качества процесса. Закрытые тикеты и PR-комментарии становятся исторической базой для последующих итераций — что было сделано и почему. Новые требования фиксируются в новых тикетах с явными связями parent-child, а паттерны улучшений переходят в обновлённые context-файлы (CLAUDE.md, AGENTS.md), которые агент читает на следующей сессии.

Как начать: пошаговый план

Методология переносима: Microsoft проверила её на нескольких несвязанных проектах разных доменов. Паттерны (spec-first бэклог, поэтапное планирование, context-файлы для агентов) работают без привязки к конкретному стеку или модели.

1. Скопируйте agentic-agile-template — там готовые шаблоны тикетов, context-файлы и стартовая структура бэклога
2. Создайте context-файлы для агентов: CLAUDE.md / AGENTS.md / copilot-instructions.md с описанием проекта, стиля кода и процесса
3. Составьте высокоуровневые тикеты для основных capabilities проекта — включая отдельный тикет на CI/CD и автотесты
4. Попросите агента отсортировать и сгруппировать тикеты по волнам, учитывая зависимости и конфликты файлов
5. Возьмите первый тикет, уточните его structure по шаблону agentic story (scope, acceptance criteria, negative constraints)
6. Запустите агента с явной инструкцией: работать только по спецификации в тикете, никакой работы без associated issue
7. После каждой волны — ревью-гейт: интеграция, CI, проверка инвариантов
8. После нескольких волн — ретроспектива: попросите агента найти паттерны сбоев в логах

Выводы

Идея Agentic Agile не нова по сути — это фундаментальное наблюдение Agile, применённое к новой модели коллаборации. Что Agile обнаружил для человеческих команд, Agentic Agile обнаруживает для команд «человек + агент»: итерация, контракты и рефлексия предотвращают одни и те же классы проблем.

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

Методология проверена Microsoft на нескольких разных проектах и оказалась по-настоящему переносимой — работает без привязки к конкретному стеку, модели или домену. Это и есть настоящий тест: методология, работающая только там, где она была изобретена, — это не методология.

Полный манифест, шаблоны тикетов и context-файлы для агентов: microsoft/agentic-agile-template на GitHub. Оригинальная статья: Agentic Agile: Why Agent Development Needs Agile, Not Just Prompts.