«ИИ не сделал разработку проще, но ускорил процессы»

За последние два года генеративный искусственный интеллект стал привычным инструментом разработки. С его помощью не менее 70% российских компаний уже собирают прототипы, пишут тесты и реализуют отдельные функции. Но вместе с ускорением процессов появляются новые ограничения. Максим Качурин, технический директор Flexbe и сооснователь компании Reforma, более 15 лет работает в области разработки сложных веб-продуктов. Он создавал решения для браузерных IDE, участвовал в развитии международных проектов Riot.js и Storybook, а также руководит развитием популярной SaaS-платформы (модели предоставления программного обеспечения, при которой приложение и все данные к нему хранятся на серверах провайдера). Эксперт поделился идеями и мыслями о том, как российским компаниям адаптироваться к новым технологиям.

Выйти из полноэкранного режима

Развернуть на весь экран

— Какие три вызова в профессии разработчика вы бы назвали главными в 2026 году?

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

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

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

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

— Какими будут продуктовые команды через два-три года? Изменится ли набор ключевых навыков?

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

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

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

— Это общемировой тренд, который уже не остановить. В России вайб-кодинг (подход к программированию, при котором разработчик описывает задачу на естественном языке, а искусственный интеллект генерирует соответствующий код.— Прим. ред.) тоже будет расти высокими темпами, если на уровне закона не появятся ограничения на обучение и использование моделей. При этом я прогнозирую проблемы с экономикой токенов. Для большинства компаний расходы на ИИ в размере $200 в месяц на сотрудника легко окупаются за счет роста эффективности этого сотрудника. Но для конечных пользователей SaaS-сервисов подписки будут дорожать и все сильнее бить по карману. Разработчики ИИ-сервисов просто не могут продавать доступ дешевле из-за высоких расходов на модели и серверную инфраструктуру. С другой стороны, пользователи смогут самостоятельно решать все больше задач с помощью таких сервисов — без промежуточных звеньев в виде студий и фрилансеров. В итоге более дорогая подписка все равно обойдется дешевле, чем работа через посредника.

— Вы внедряете в разработку ИИ-функции. Что, на ваш взгляд, важнее для работы агента с кодом: выбор модели или качество предоставленного контекста о проекте?

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

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

Мир разработки уже переориентируется на предоставление программной документации в формате, удобном для ИИ. Например, такие инструменты, как Storybook, обзаводятся MCP-серверами (такие сервера дают возможность для ИИ-приложений подключаться к внешним системам, данным и инструментам через единый, стандартизированный протокол.— Прим. ред.), чтобы агенты могли напрямую получать информацию о компонентах. Появляются инструменты для управления системами через сторонних агентов и специальные стандарты описания документации. В своих проектах я целенаправленно работаю над тем, чтобы улучшить качество контекста и предоставить ИИ-агентам инструменты для управления внешними системами.

— Как техническому директору понять, в каких направлениях продукта нужно сделать акцент на ИИ-функционале?

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

Именно поэтому такие продукты сейчас захватывают рынок. Правда, у них есть другая проблема: ИИ уже есть, а полноценного продукта вокруг него часто нет, то есть пользователь вынужден все делать через чат. Это одна из причин, почему я создал Reforma. Я хочу выйти за рамки стандартных конструкторов сайтов и объединить AI-native-подход (подход, при котором продукт изначально создается для работы с ИИ.— Прим. ред.) с полноценным визуальным редактированием и ручным контролем, как в привычных профессиональных инструментах.

— Есть мнение, что ИИ-агенты полностью заменят junior-специалистов. Что вы думаете о способах развития инженерного мышления и подготовке middle- и senior-разработчиков?

— Да, наем специалистов начального уровня сократился примерно на 65% за последние пять лет. Сегодня компании выгоднее нанять middle+/senior-разработчика, который с помощью агента будет быстрее решать сложные задачи. Но ИИ-агенты меняют не профессию, а порог входа в нее. Индустрия всегда двигалась в сторону повышения уровня абстракции: от ассемблера к языкам высокого уровня, фреймворкам и облачным технологиям. ИИ продолжает эту логику. Я считаю, не нужно пытаться сохранять старую модель обучения. Лучше развивать у начинающих инженеров продуктовое видение: умение понимать задачу, самостоятельно принимать решения, видеть продукт целиком и эффективно работать с ИИ.

— Вы создали официальную интеграцию «живой библиотеки» Storybook для SolidJS (реактивной высокопроизводительной библиотеки для создания пользовательских интерфейсов) — уникальную инфраструктуру для фреймворка из 75 тыс. репозиториев. Расскажите об этом инструменте.

— Storybook — это индустриальный стандарт для разработки, документации и тестирования компонентов пользовательских интерфейсов в изоляции от основного приложения. Им пользуются команды по всему миру, включая больше половины компаний из Fortune 100 — ежегодного рейтинга крупнейших по годовой выручке компаний США, в числе которых, например, Microsoft, IBM, OpenAI, Amazon, Netflix, Spotify, Airbnb и многие другие.

Я сам применяю его в своих проектах. Отсутствие возможности использовать Storybook было огромной проблемой для меня и моих команд. Поэтому я сам реализовал эту интеграцию и довел ее до уровня официального решения как со стороны сообщества SolidJS, так и со стороны самого Storybook. В результате разработчики на SolidJS получили возможность использовать Storybook без ограничений, так как я поддерживаю весь функционал, доступный в основной React-версии. Интеграция включена в официальную документацию, доступна через официальный установщик Storybook, активно поддерживается мной и используется командами по всему миру. На текущий момент ее устанавливают больше 450 тыс. раз в месяц, и это число продолжает расти.

— Что меняется внутри команды, когда у дизайнеров и разработчиков появляется единая база готовых компонентов?

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

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

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

— За время вашей работы в Flexbe компания выросла от конструктора до полноценной платформы для создания сайтов. Каким принципом вы руководствовались при масштабировании?

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

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

— В 2026 году вы оценили сотни веб-продуктов на международных премиях (Web Award, Digiday Technology Awards, Silicon ANGLE Tech Forward Awards и другие). На что вы обращаете внимание при оценке инноваций?

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

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

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

Полина Корнилова