Чем умнее ИИ, тем дороже обходятся плохие инженерные решения
Как превратить «грязные» наработки дата-саентистов в стабильный продакшн? Что делать, когда бизнес требует точных сроков по неизвестным задачам, а новые SOTA-модели выходят каждый день? Мы поговорили с руководителем группы разработки направления анализа данных АО «Сайберок» Михаилом Мосиным о суровой реальности промышленного ML, архитектурных факапах, «красных флагах» на собеседованиях и о том, почему в 2026 году кодогенераторы не отменяют инженерное мышление.
«Всё начинается с контракта: фиксируем рамки на вход и на выход, а уже потом убираем ручные костыли»
Basis.press: Михаил, как вы превращаете исследовательские наработки Data Scientist-ов (часто грязные и «одноразовые») в стабильный, тестируемый и масштабируемый продакшн, который не падает при первой нагрузке?
Михаил Мосин: Всё начинается с контракта. Когда появляется рабочий прототип, я первым делом фиксирую жёсткие рамки: что сервис принимает на вход и что должен отдавать на выходе. Затем мы переносим логику в полноценный пайплайн, убираем ручные костыли, внедряем строгую валидацию данных, тесты, логирование и метрики. Тяжёлые процессы обязательно бьём на независимые этапы – так, чтобы любой упавший шаг можно было безопасно перезапустить. Обязательный этап – проверка: результат должен тютелька в тютельку совпасть с исследовательским прототипом, а система – выдержать стресс-тест. При проектировании я всегда смотрю на реальные ресурсы баз данных и сервисов, уделяя максимум внимания интеграционным тестам. Если решение стабильно зеленеет в dev-среде после серии прогонов – добро пожаловать в продакшн.
Basis.press: Когда фундамент продакшн-системы построен, следующий вопрос — из чего его строить. В 2026 году новые фреймворки и SOTA-модели сыпятся как из рога изобилия. Как Вы решаете: брать готовое с GitHub и рисковать поддержкой или писать своё с нуля? Где грань между «изобретением велосипеда» и «библиотечным адом»?
Михаил Мосин: Главный критерий для меня – не хайп вокруг проекта, а его зрелость. Я смотрю на активность коммитов, качество документации, покрытие тестами, вес зависимостей и долгосрочные перспективы поддержки. Готовое решение беру, если задача типовая, чужой код легко заменить, и он не зашит в самую сердцевину архитектуры. Свою реализацию пишем тогда, когда нужна уникальная бизнес-логика, бескомпромиссная производительность или когда внешняя библиотека тащит за собой больше рисков, чем пользы. Иногда идеальный компромисс – сделать форк и допилить под себя. Правило простое: глупо писать с нуля то, что уже блестяще реализовано до нас, но строить ключевой контур системы на хрупкой башне из чужих нестабильных зависимостей – путь в никуда.
«Починить архитектуру превентивно всегда в разы дешевле, чем тушить пожары на выходных и платить за раздутое железо»
Basis.press: Даже если стек выбран удачно, в реальных проектах редко удаётся избежать компромиссов. Михаил, давайте начистоту: бывали ли случаи, когда ради скорости релиза приходилось выпускать откровенный «костыль»? Как Вы потом лечили этот техдолг и объясняли бизнесу, что на него стоит тратить время вместо разработки новых фич?
Михаил Мосин: Регулярно! Бизнесу результат нужен «ещё вчера», поэтому компромиссы неизбежны. Если я вижу, что временное решение оседает в проде надолго или становится частью кор-пайплайна, я сразу закладываю рефакторинг в бэклог. Жду момента, когда этот костыль начинает реально тормозить процессы, плодить баги или мешать масштабированию. Как объяснять это бизнесу? Через язык денег и рисков. Починить архитектуру превентивно всегда в разы дешевле, чем потом тушить пожары на выходных, терять пользователей, платить за раздутое «железо» и судорожно латать дыры в самый неподходящий момент.
«Прежде чем запустить что-то в продакшн, я спрашиваю себя: «А что будет с этой схемой через три года?»»
Basis.press: Индустрия почему-то обожает говорить только о победах, хотя учатся все на провалах. Расскажите, какой архитектурный просчёт стоил вашей группе больше всего нервов, времени или денег? Чему этот провал вас научил?
Михаил Мосин: Самым болезненным оказался просчёт со схемой хранения данных. Мы заложили хорошую базу под текущий объём, но абсолютно не учли скорость его экспоненциального роста. Через некоторое время тяжёлые запросы и фоновые процессы начали просаживать систему, а миграция на новую схему превратилась в операцию на открытом сердце – всё это без остановки работающих сервисов. Этот холодный душ научил меня смотреть на несколько шагов вперёд. Теперь любое архитектурное решение оценивается через призму будущего роста, стоимости неизбежных переделок и возможности бесшовной миграции. Прежде чем запустить что-то в продакшн, я мысленно задаю вопрос: «А что будет с этой схемой через три года, когда данных станет в сто раз больше?».
Basis.press: Архитектурные решения влияют не только на стабильность системы, но и на стоимость её эксплуатации. Был ли в вашей практике случай, когда оптимизация кода или архитектуры радикально сократила расходы на инфраструктуру? И где, на ваш взгляд, проходит граница экономической целесообразности такой оптимизации?
Михаил Мосин: Да, классический пример: рост облачных копеек (или уже миллионов) из-за кривых запросов, избыточных пересчётов и хранения тонн «мусорной» истории. Мы пересмотрели TTL (время жизни данных), внедрили партиционирование, переписали логику обработки – и нагрузка на кластер упала в разы, а кошелёк компании вздохнул свободнее. Оптимизация имеет смысл ровно до тех пор, пока затраты на инженерные часы ниже предполагаемой экономии. Если рефакторинг требует месяца работы синьора, а ту же проблему можно временно закрыть докупкой серверных мощностей без критических последствий – экономически грамотнее сначала масштабировать инфраструктуру.
«Понимание того, как система ведёт себя в продакшне под нагрузкой, приобретается только через боль реального опыта»
Basis.press: Чтобы архитектура не трещала по швам, а оптимизация не съедала весь бюджет, нужна сильная команда. Но найти её – отдельный квест. Поделитесь, какие у Вас «красные флаги» на собеседованиях? Что важнее: зубрящая теорию молодежь или крепкие практики продуктового кода?
Михаил Мосин: Главные красные флаги – это заученные ответы без понимания базовой физики процессов, категорический отказ признавать свои ошибки, токсичность и привычка перекладывать вину на бывших коллег, а также неумение объяснить сложные вещи простым языком. Если передо мной встанет выбор между ходячей энциклопедией теории алгоритмов и инженером, который глубоко понимает, как устроен код в боевых продуктах, я без раздумий выберу второго. Зубрёжку можно подтянуть за пару недель, а вот понимание того, как система ведёт себя в продакшне под нагрузкой, приобретается только через боль реального опыта.
Basis.press: Вы упомянули, что цените не заученную теорию, а глубокое понимание работы систем. Насколько глубоко разработчик в 2026 году должен понимать внутреннее устройство технологий, если сегодня существуют фреймворки практически для любой задачи?
Михаил Мосин: Знать исходный код каждой сторонней библиотеки наизусть не нужно. Но фундамент – то, как устроена работа памяти, потоков и процессов, сетевой стек, базы данных и рантайм – знать обязан каждый, кто метит выше джуниора. Фреймворки ускоряют старт, но они бессильны, когда система начинает неожиданно деградировать, течь по памяти или сыпать таймаутами. Настоящий инженер отличается от оператора фреймворков тем, что при аварии он может опуститься на уровень ниже и найти первопричину сбоя.
Basis.press: Но по мере профессионального роста инженер всё чаще отвечает уже не только за технологии, но и за решения. Михаил, что, на Ваш взгляд, сложнее для руководителя: принять заведомо неверное решение или вовремя признать собственную ошибку?
Михаил Мосин: Ошибаются все, особенно в условиях дефицита информации. Самое опасное – упрямо защищать факап, когда все метрики кричат об обратном. Сила руководителя не в том, чтобы быть непогрешимым оракулом, а в том, чтобы вовремя поднять руку, признать промах, локализовать ущерб, пересобрать план и честно объяснить команде, куда и зачем мы идём дальше.
«ИИ предложит тысячу вариантов реализации, но выбрать единственно верный сможет только человек с инженерным опытом»
Basis.press: Отказываться от иллюзий и признавать промахи – половина дела. Гораздо сложнее бывает отстоять реальность перед лицом бизнеса, которому результаты нужны были ещё вчера. Что делать, когда бизнес требует точный дедлайн по задаче с кучей неизвестных?
Михаил Мосин: Я никогда не беру цифры с потолка. Если вводных нет, я честно делю задачу на фазу R&D (исследования) и фазу реализации, фиксирую риски, накидываю сверху 20-30% буфера на форс-мажоры и озвучиваю бизнесу вилку оценок. После быстрого технического тайм-аута или создания прототипа туман рассеивается, оценка уточняется, и дальше мы принимаем решения уже на основе фактов, а не гадания на кофейной гуще.
Basis.press: Сегодня всё чаще звучит мнение, что часть подобных задач скоро возьмут на себя ИИ-агенты. Михаил, не боитесь ли Вы превратиться в «надсмотрщика за машинами» и постепенно потерять связь с живым кодом?
Михаил Мосин: Этот процесс уже идёт полным ходом. Сегодня львиная доля рутинного кода, тестов и базовых заготовок пишется ИИ-агентами быстрее и чище, чем человеком. Но я не вижу в этом угрозы. Ценность сильного тимлида или архитектора никогда не измерялась количеством настуканных по клавиатуре строчек. Бизнесу по-прежнему нужны люди, которые умеют слышать реальные потребности рынка, переводить их в технический контекст, принимать судьбоносные архитектурные решения и нести за них персональную ответственность. ИИ – мощный ускоритель, но он лишён инженерного чутья и понимания бизнес-контекста.
Basis.press: Каким тогда будет «высший пилотаж» для разработчика через три года? За что компании будут готовы платить зарплаты уровня Senior+?
Михаил Мосин: Уровень Senior+ будет определяться не тем, как быстро ты пишешь код, а твоей способностью понимать, что именно и зачем нужно построить. Архитектурное видение, системное мышление, умение увязать технологии с бизнес-целями компании и готовность отвечать за конечный продукт – вот что останется за пределами автоматизации. ИИ предложит тысячу вариантов реализации, но выбрать единственно верный под конкретные ограничения компании сможет только человек с инженерным опытом.
«В индустрии выживают не те, кто знает синтаксис пяти языков, а те, кто умеет думать, договариваться и доводить дело до конца»
Basis.press: В завершение нашего разговора хочется заглянуть в прошлое. Какой один совет Вы дали бы себе в начале пути? Чему не учат в университетах, но без чего в IT не выжить?
Михаил Мосин: Я бы посоветовал себе гораздо раньше перестать быть просто «кодером» и начать разбираться в экономике бизнеса: какую конкретно боль клиентов решает моя строчка кода? В университетах дают прекрасную теоретическую базу, но там совершенно не учат работать в условиях абсолютной неопределённости, признавать собственные провалы и брать на себя ответственность за результат. На практике в индустрии выживают не те, кто знает наизусть синтаксис пяти языков программирования, а те, кто умеет думать, договариваться и доводить дело до конца.
Мнение редакции Basis.press:
В эпоху, когда ИИ штампует базовый код за секунды, а новые фреймворки устаревают раньше, чем успевают выйти из бэклога, ценность чисто механической разработки стремительно стремится к нулю.
Разговор с руководителем группы разработки направления анализа данных АО «Сайберок» ценен тем, что в нём нет маркетингового шума и «розовых очков». Это трезвый манифест промышленного инженера о том, как выживать на стыке хаотичного R&D и жёстких бизнес-требований.
Редакция Basis.press уверена – эпоха «гаражного» машинного обучения и слепой веры в то, что любые проблемы решит очередной модный фреймворк или свежая нейросеть, окончательно уходит в прошлое. Побеждают те, кто обладает системным мышлением, умеет просчитывать риски на три шага вперёд, честно признавать свои факапы и говорить с бизнесом на одном языке.
В эпоху, когда ИИ штампует базовый код за секунды, а новые фреймворки устаревают раньше, чем успевают выйти из бэклога, ценность чисто механической разработки стремительно стремится к нулю.
Разговор с руководителем группы разработки направления анализа данных АО «Сайберок» ценен тем, что в нём нет маркетингового шума и «розовых очков». Это трезвый манифест промышленного инженера о том, как выживать на стыке хаотичного R&D и жёстких бизнес-требований.
Редакция Basis.press уверена – эпоха «гаражного» машинного обучения и слепой веры в то, что любые проблемы решит очередной модный фреймворк или свежая нейросеть, окончательно уходит в прошлое. Побеждают те, кто обладает системным мышлением, умеет просчитывать риски на три шага вперёд, честно признавать свои факапы и говорить с бизнесом на одном языке.
