Как мы используем нейросети в разработке. Да, это безопасно. Да, результат есть

Как мы используем нейросети в разработке. Да, это безопасно. Да, результат есть

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

Всем привет! Меня зовут Влад Кармаков, я основатель и руководитель компании по разработке цифровых решений Siberian.pro. Я покажу реальный опыт использования ИИ в разработке продуктов и постараюсь дать практические примеры. Поехали!

С чего все началось

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

Мы в компании тоже в некотором роде сибирские мужики, поэтому, как и все, игрались с LLM еще в 2023. Однако около года назад мы от игр перешли к активным действиям, создали AI-юнит в компании и начали активно внедрять ИИ в собственные бизнес-процессы (в первую очередь, конечно, в разработку), и предлагать клиентам ИИ-решения их задач.

Прошел год. Рассказываю о результатах.

Примеры использования ИИ в разработке

1. Бизнес- и продуктовая аналитика

LLM — это идеальный инструмент для аналитики сырых данных. А именно:

  • Составлять ТЗ. Выделять бизнес-требования, риски и ключевые метрики из анализа неструктурированных коммуникаций с заказчиком. Это реально работает и это реально экономит время. Буквально: закинул запись созвона со всеми бэканьями, мэканьями и «мы хотим, как здесь, только лучше», плюс шаблон ТЗ и получил на выходе почти готовый документ в черновом варианте. Можно и HLD сразу нарисовать.
  • Выполнять аналитику для пресейла. LLM помогает быстро «въехать» в контекст рынка заказчика, понять его требования и сразу, т.е. еще до начала разработки предложить вариант решения его задач.
  • Анализировать качественные данные, например, отзывы. Это полезно при первичном аудите продукта для быстрого вычленения болей целевой аудитории. Может быть как частью пресейла, так и самостоятельной услугой.
  • Готовить первичную документацию и артефакты. Почему бы не пустить полученную от LLM на предыдущих этапах информацию дальше по пайплайну и не сформировать документацию для прототипа? А затем и сам прототип.
<i>Надиктовываем голосом будущую архитектуру системы. Закидываем текст в GPT, в промпте указываем, что требуется диаграмма HLD в формате Mermaid (на скрине). Далее полученные результат переносим в draw.io.</i>
Надиктовываем голосом будущую архитектуру системы. Закидываем текст в GPT, в промпте указываем, что требуется диаграмма HLD в формате Mermaid (на скрине). Далее полученные результат переносим в draw.io.
<i>Пример UML-диаграммы с реального проекта. Почти все для этой картинки создано с помощью LLM. Обезличивание и адаптация для этой статьи тоже.</i>
Пример UML-диаграммы с реального проекта. Почти все для этой картинки создано с помощью LLM. Обезличивание и адаптация для этой статьи тоже.

В чем тут выгода?

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

Как мы используем нейросети в разработке. Да, это безопасно. Да, результат есть

И однако даже в таком виде прирост производительности (по трекеру) составляет от 40 до 50%. На одном из реальных проектов мы смогли пройти всю фазу прототипирования где-то за 30-40 дней. Т.е. заказчик увидел, как будет выглядеть и работать будущая система, на несколько месяцев раньше, чем это происходило бы при типовых форматах разработки.

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

2. Быстрое прототипирование

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

<i>Одна из первых проб пера. Минималистичное ТЗ на этапе пресейла превращается, ТЗ превращается…</i>
Одна из первых проб пера. Минималистичное ТЗ на этапе пресейла превращается, ТЗ превращается…
<i>…в элегантный рабочий прототип. Ок, здесь - не очень элегантный, но для прототипа это не страшно.</i>
…в элегантный рабочий прототип. Ок, здесь - не очень элегантный, но для прототипа это не страшно.
<i>Еще один пример прототипа, на котором обкатывались идеи одного из актуальных проектов. Кстати, этот проект для крупного заказчика в итоге был реализован. Но это отдельная очень крутая история, расскажу ее в другой раз.</i>
Еще один пример прототипа, на котором обкатывались идеи одного из актуальных проектов. Кстати, этот проект для крупного заказчика в итоге был реализован. Но это отдельная очень крутая история, расскажу ее в другой раз.

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

Благодаря таким инструментам, как v0, Bolt.new, Lovable и Nxcode достаточно лишь аккуратно вытащить из них готовый прототип и смело пускать в работу.

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

Важно: в прод такие прототипы не идут.

3. Код-ревью

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

Как мы используем нейросети в разработке. Да, это безопасно. Да, результат есть
Как мы используем нейросети в разработке. Да, это безопасно. Да, результат есть

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

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

В чем выгода?

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

4. Тестирование

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

  • классические юнит-тесты, задача которых — убедиться, что код работает так, как задумано;
  • интеграционные тесты, задача которых — проверить целостность архитектурных решений (работа API, соответствие проекта HLD, нагрузочные тесты);
  • и даже отчасти UI и End-to-end.

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

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

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

В чем выгода?

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

Т.е. заказчик получает лучший продукт быстрее.

5. Поиск по внутренним документам компании (RAG)

Едем дальше. Еще одна точка приложения LLM — базы знаний, справочники и вот это все.

<i>RAG-справочник для сотрудников Siberian.pro. Можно задать любой вопрос по текущим проектам и получить приземленный к конкретным документам ответ.</i>
RAG-справочник для сотрудников Siberian.pro. Можно задать любой вопрос по текущим проектам и получить приземленный к конкретным документам ответ.

RAG можно прикрутить и к данным рабочих проектов в Confluence, и вот это вообще пушка! Команда быстрее получает необходимые сведения напрямую из подключенных источников. А дать предварительную оценку проекта на основе обернутой в RAG информации можно вообще в течение часа-двух. Это очень круто.

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

В чем здесь выгода?

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

6. MCP-инструменты и Agent Skills

Про MCP-серверы и их пользу для бизнеса я публиковал статью на Хабре. Технически, MCP — это протокол для загрузки в контекст LLM информации из разных источников.

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

Другое дело — скиллы (Agent Skills), предложенные Anthropic в 2025 году. Скиллы или навыки — это точные инструкции для LLM, как что-то сделать. Скажем, где брать исходную информацию для проекта и как ее оттуда вытащить.

Например, в команде в реальных проектах применяется скилл доступа к Confluence. В SKILL.md соответствующего навыка прописаны все необходимые данные для того, чтобы агент мог получить ссылку на документ в Confluence, сходить туда и самостоятельно все прочитать по мере необходимости.

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

Что это дает?

  • экономия контекста LLM;
  • экономия времени сотрудников;
  • повышение автономности агентов, а следовательно, их производительности.

В чем выгода?

Как Agent Skills, так и MCP — это дополнительный контекст для LLM, позволяющий более эффективно решать текущие задачи. По сути речь идет о мощном ускорении всех производственных процессов в компании. Заказчики от этого тоже выигрывают.

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

К слову, скоро расскажу, как мы научили своих сотрудников не-технарей (бухгалтеров, маркетологов, HR-ов и т.д.) писать себе скиллы, автоматизирующие их работу, и что это нам дало. Спойлер: нет, никого не уволили.

Вывсеврети! ИИ галлюцинирует, ему ничего нельзя доверить

Да, но нет.

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

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

Но уже сейчас развею частые опасения:

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

И да, это реальные проекты.

Итоги

К применению ИИ в разработке все еще относятся скептически. С позиции отдельного разработчика это даже иногда оправданно. Но с позиции бизнеса — уже нет. Просто процитирую одного из моих коллег — senior-разработчика:

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

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

***

Хотите внедрить ИИ в свои бизнес-процессы, но не знаете как? У себя в Telegram я много пишу про цифровизацию, внедрение ИИ, а также просто о буднях CEO IT-компании из топ-10 по России. Приходите, всем рад.

А за разработкой и внедрением систем автоматизации бизнеса с помощью ИИ приходите сюда. Тоже всем рады :)

44
22