Инженер против иллюзий: почему «простые» решения в IT стоят дорого и кто на самом деле отвечает за реальность продукта

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

3DNews поговорил с Александром Моисеевым, Senior Fullstack Developer с опытом разработки платформ для миллионов пользователей, чтобы узнать, как инженеры превращают бизнес-идеи в работающие системы. В разговоре с 3DNews он объясняет, почему инженер — это медиатор между ожиданиями и ограничениями, и где проходит граница между технологическим оптимизмом и профессиональной ответственностью.

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

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

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

Даже небольшая функция означала:

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

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

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

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

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

В Ingate я занимался трансформацией нестабильных процессов и внедрением автоматизации. На уровне бизнеса задачи звучали как «ускорить релизы» или «добавить функциональность». На уровне инженерии это означало рефакторинг, перестройку процессов тестирования, внедрение CI/CD и метрик стабильности.

В результате нам удалось сократить ручное тестирование до 90% и значительно повысить устойчивость платформы. Но за этим стояла системная инженерная работа. Бизнес видит фичу. Инженер видит структуру, которая должна выдержать эту фичу.

— ИИ сегодня воспринимается как универсальное решение. Насколько это соответствует реальности?

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

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

Нужно:

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

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

— Насколько инженеру сегодня важно понимать не только код, но и продукт, и бизнес?

Александр Моисеев: Очень важно. Инженер — это переводчик между тремя мирами: бизнесом, пользователями и технологиями.

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

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

В собственных R&D-проектах я особенно остро почувствовал, что большая часть работы — это коммуникация. Клиент приносит идею, инженер должен превратить ее в реалистичную архитектуру, MVP, сроки и ограничения. Именно здесь проявляется зрелость специалиста.

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

Александр Моисеев: В конце 2025 года я был приглашен в качестве члена жюри American Business Expo Award, где оценивал международные проекты в направлениях мобильных приложений, data management и цифровой трансформации.

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

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

— Что вы считаете главным принципом своей работы?

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

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

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