Пробуем на себе: LLM в разработке

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

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

Содержание

На излете хайпа ^[2]

Внутренний опыт ^[3]

• Бизнес- и продуктовая аналитика ^[4]

• Быстрое прототипирование ^[5]

• Код-ревью ^[6]

• Тестирование ^[7]

• Поиск по внутренним документам компании (RAG) ^[8]

• MCP-агенты и Agent Skills ^[9]

Убираем лошадь ^[10]

Итоги ^[11]

На излете хайпа

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

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

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

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

Внутренний опыт

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

Первым делом я задался вопросом: «Зачем? Чтобы что?». Иными словами, каких конкретных изменений я жду в результате плотного внедрения ИИ в процессы разработки.

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

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

Если в этой метафоре лошадь заменить на разработку, а тачскрин на LLM, то получим примерно сегодняшнюю ситуацию. Ясно, что для реальных изменений нужно отказаться от лошади ^[12].

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

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

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

• Составлять ТЗ. Выделять бизнес-требования, риски и ключевые метрики из анализа неструктурированных коммуникаций с заказчиком. Это реально работает и это реально экономит время. Буквально: закинул запись созвона со всеми бэканьями, мэканьями и «мы хотим, как здесь, только лучше», плюс шаблон ТЗ и получил на выходе почти готовый документ в черновом варианте. Можно и HLD сразу нарисовать.

• Выполнять аналитику для пресейла. LLM помогает быстро «въехать» в контекст рынка заказчика, понять его требования и сразу, т.е. еще до начала разработки предложить вариант решения его задач.

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

• Готовить первичную документацию и артефакты. Почему бы не пустить полученную от LLM на предыдущих этапах информацию дальше по пайплайну и не сформировать документацию для прототипа? А затем и сам прототип.

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

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

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

Кстати, о прототипах. К ним сейчас перехожу.

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

Довольно быстро стало понятно, что для создания прототипов, в том числе функциональных, нейросети тоже подходят идеально. Почему? 

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

В чем тут выгода? Без ИИ-инструментов подготовка такого прототипа потребовала бы серьезного объема документации. В крупных проектах это сотни часов работы аналитика. И все для того, чтобы бизнес-требования трансформировать в реально работающий прототип. Благодаря таким инструментам, как v0, Bolt.new ^[13], Lovable и Nxcode достаточно лишь аккуратно вытащить из них готовый прототип и смело пускать в работу.

ТЗ для v0 можно тоже составить с помощью LLM. Таким образом в два-три этапа получаем функциональный прототип.

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

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

Код-ревью

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

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

В чем выгода?

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

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

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

• классические юнит-тесты, задача которых — убедиться, что код работает так, как задумано;

• интеграционные тесты, задача которых — проверить целостность архитектурных решений (работа API, соответствие проекта HLD, нагрузочные тесты);

• и даже отчасти UI и End-to-end.

Пока удалось автоматизировать не все. Конечная цель — перейти к схеме, когда QA лишь описывает тест-кейсы, а LLM затем через агентов выполняет все автотесты самостоятельно. Но уже сейчас достигается реальный рост скорости и качества(!) тестирования.

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

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

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

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

В чем выгода?

О том, как внедрение LLM в процессы QA позволило ускорить работу и повысить качество, я уже сказал. Однако более важным я назову другой плюс: тестирование становится более консистентным, более полным и осознанным (да-да!). При грамотно составленном тест-плане добавление новых фич и даже серьезные изменения вектора разработки проходят безболезненно, а заказчик получает лучший продукт быстрее.

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

Едем дальше. Еще одна точка приложения LLM — базы знаний, справочники и вот это все. В тестовом режиме на базе опенсорсного Onyx в компании создали внутреннюю базу знаний с AI-ассистентом, отвечающим на вопросы по отпускам и оформлению больничных, по работе с Jira, по текущим начислениям и внутренним стандартам компании, зафиксированным в Confluence. Планируем расширять и на другие инструменты, используемые в компании.

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

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

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

MCP-агенты и Agent Skills

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

У себя в компании мы используем MCP, но ограниченно. Пространство для улучшения и роста здесь огромное, но технологию, увы, поддерживают пока не везде. Например, не вышло ^[15] прикрутить MCP к Google Drive, чтобы оттуда брать информацию для пресейлов. Кроме того, архитектурно MCP нам не сильно зашел.

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

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

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

Что это дает?

• экономия контекста LLM;

• экономия времени сотрудников;

• повышение автономности агентов, а следовательно, их производительности.

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

В чем выгода?

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

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

Убираем лошадь

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

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

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

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

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

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

• новые правки НЕ ломали то, что работало до этого — каждая итерация оканчивалась стабильной сборкой;

• использование искусственного интеллекта ^[18] НЕ исключило работу человека, но человек стал играть другую роль — архитектора.

И да, это реальный проект. Подробности уже скоро.

Итоги

Итак, что изменилось за год активного использования LLM? Да почти все.

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

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

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

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

А как прошел ваш последний год с LLM? Расскажите в комментариях.