Недавно мы с командой проанализировали инфополе Хабра и обнаружили, что эйфория от внедрения ИИ в разработку сменяется разочарованием, senior-разработчики тонут в ревью некачественного кода, а техдолг растет как снежный ком. Мы сами проходим через этот путь, внедряя GenAI в SimpleOne, и прекрасно понимаем вашу боль.
Всем привет, я Артем Герасимов, владелец продукта SimpleOne SDLC. В этой статье я расскажу о реальных проблемах ИИ-генерации кода и о том, какие механизмы помогают нам с ними справляться.
Отдельную благодарность за помощь в написании статьи выражаю автору SimpleOne Панфиловой Яне.
Почему ИИ не работает так, как обещали
Когда мы начали активно использовать ИИ в разработке, наши мечты разбились о скалы реальности. Коллеги из других компаний делились похожими историями: внедрили инструменты, а они либо не работают вообще, либо создают больше проблем, чем решают.
Локальные модели показывают слабые результаты
Многие компании пытаются использовать локальные ИИ-модели из соображений безопасности. Проблема в том, что качество генерации кода у них значительно ниже, чем у облачных решений. Код получается шаблонным, с ошибками, требует столько доработок, что проще было бы самому написать.
ИИ теряет контекст и важные детали
У современных моделей есть фундаментальное ограничение: даже при миллионе токенов контекста, когда ИИ начинает сжимать информацию, он теряет критически важные части задачи. Это особенно заметно в больших проектах, где нужно учитывать множество взаимосвязей.
ИИ не учитывает накопленные знания
Самая болезненная проблема: ИИ не вычитывает историю проекта, архитектурные решения, договоренности команды. Как недавно писали ребята из BotHub, для ИИ важнее сгенерировать статистически правдоподобный результат, чем реально учесть ваш контекст. Код генерируется в вакууме, игнорируя специфику проекта. В итоге получается технически правильный, но конце��туально неверный код.
У нас было так же
Когда SimpleOne начала переход на ИИ-инструменты, мы столкнулись с теми же проблемами, что и многие. Сейчас мы внедряем GenAI и на собственном опыте понимаем все нюансы этого процесса.
У нас возникли дополнительные сложности, которые, возможно, знакомы и вам:
Специфика Low-code платформы
Мы пишем не чистый исходный код, а работаем через Low-code конструктор, что требует от ИИ понимания специфических правил и ограничений платформы.
Текучка кадров
Не всем разработчикам нравится тренд перехода на ИИ, многие воспринимают это как угрозу своему профессиональному развитию. Новых сотрудников тяжело удерживать, когда они понимают, что могут потерять опыт классической разработки. Но это нормальная реакция на любые изменения в компании — точно такая же текучка происходит при переходе на Agile или внедрении DevOps.
Деградация навыков разработчиков
Исследователи из METR недавно обновили свой эксперимент про то, как ИИ влияет на продуктивность разработчиков. Провести чистый A/B-тест оказалось нереальным, потому что разработчики, начавшие писать через ИИ, уже не хотели возвращаться к обычной работе. Более того — они в целом начали меньше думать над задачами, делегируя это машине.
Сложность перестройки процессов
Внедрение ИИ требует пересмотра всех этапов разработки — от постановки задач до code review. В средних и крупных компаниях это нельзя сделать за один день. Мы до сих пор итеративно адаптируемся и подстраиваем процессы под работу с ИИ.
Что помогает нам справляться с этими проблемами
Мы не бросили идею работы с ИИ, а нашли механизмы, которые позволяют минимизировать риски и получать реальную пользу.
Настройка агентов и распределение задач
Мы настраиваем работу так, чтобы агенты стирали память перед каждой новой задачей, но работали по четкому плану. План делаем коротким, чтобы агент мог быстро его понять и начать работу. Вместо того, чтобы запихивать одну большую задачу в единый контекст, распределяем её между несколькими агентами. Это снижает риски потери информации и повышает качество результата.
Вообще мы не всегда так делаем, но когда делаем — это работает
MCP для работы со спецификой платформы
Мы разработали собственный MCP-протокол, который умеет работать с нашей Low-code платформой и её нюансами. Он понимает правила SimpleOne, может настраивать продукт и обучен специфике работы с нашим конструктором. Если у вас есть продукты со своей спецификой, рекомендую рассмотреть разработку MCP-адаптера — это позволит ИИ качественнее помогать в донастройке и развитии.
Управление контекстом через SimpleOne SDLC
Когда мы начали разрабатывать продукт для управления разработкой (SDLC-систему) поняли, что недостаточно не терять контекст внутри одной задачи — нужно не терять контекст всего продукта. С новой скоростью ИИ-разработки управление бэклогом и стратегическим видением становится еще важнее. Нужно понимать, какие задачи берем, что от чего зависит, как всё это связано.
SimpleOne SDLC позволяет подключить базу знаний к ИИ через MCP. Аналитик управляет высокоуровневой документацией в системе, а разработчик подключается и получает доступ ко всему контексту: базе знаний, связанным задачам, коду через интеграцию с GitLab. Не нужно погружаться в детали вручную — ИИ сам подтягивает нужную информацию.
Гибкость настройки процессов
За счет гибкости настройки под каждый проект и команду есть возможность адаптировать процессы под специфику работы с ИИ. Это не обязательно должен быть SimpleOne SDLC — подойдет любой инструмент, который позволяет гибко настраивать workflow.
Резюме
ИИ действительно меняет разработку, но не так, как обещала реклама. Это не волшебная кнопка, которая мгновенно ускорит вашу команду в десять раз. Это инструмент со своими ограничениями, который требует выстраивания процессов, контроля качества и постоянной адаптации. Мы прошли через разочарование и нашли рабочие подходы, но продолжаем учиться и совершенствовать наши методы.
Главное, что мы поняли: ИИ нужно не бездумно внедрять, а интегрировать в существующую экосистему разработки, дополняя его системами управления знаниями, четкими процессами и инструментами контроля качества.
Вы уже пожалели о внедрении ИИ в разработку или еще нет?
