Как мы используем ИИ в разработке CRM, ERP и других корпоративных систем

Сегодня почти каждый подрядчик скажет вам: «Мы используем ИИ». Проблема в том, что за этой фразой скрываются совершенно разные вещи: от «наш стажёр иногда спрашивает что-то у чат-бота» до выстроенного конвейера, где ИИ проверяет каждую строчку кода.

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

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

Рынок заказной разработки сейчас разделился на три лагеря.

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

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

Третий лагерь: те, кто встроил ИИ в процессы как систему. Не «кто хочет, тот пользуется», а обязательные этапы работы, где ИИ участвует в проектировании, помогает программистам и проверяет весь код. Мы в «Лонг Кэт» относимся к этому лагерю, и дальше покажем, как это выглядит на каждом этапе.

Но сначала про четвёртый лагерь, о котором нужно предупредить отдельно.

Вместе с ИИ на рынке появился новый тип исполнителей. Их называют вайбкодерами (от английского vibe coding, «программирование по наитию»). Это люди, которые отдали написание кода полностью на откуп нейросетям. Сами они код не читают, часто потому, что и не умеют.
Схема в самом рискованном варианте выглядит так: вайбкодер общается с клиентом, по ходу дела спрашивает, что нужно сделать, пересказывает это нейросети, а она пишет код. Ни один живой программист этот код не видит. Ни архитектор, ни тимлид, ни специалист по безопасности к проекту не привлекаются.

Чем это оборачивается для бизнеса:

1. Архитектура наслаивается стихийно. Система проектируется не заранее, а по мере поступления пожеланий. Каждая новая функция приклеивается к предыдущим как попало. Это как строить дом без проекта: первый этаж ещё стоит, но на третьем начинаются трещины. В какой-то момент добавление простой, казалось бы, функции ломает половину системы. Почему архитектура важна именно заказчику, мы писали в статье об архитектуре информационных систем.
2. Код никто из людей не проверял. ИИ ошибается, причём уверенно и убедительно. Если его работу не контролирует специалист, ошибки просто остаются в системе. Включая дыры в безопасности, через которые могут утечь данные ваших клиентов. А за утечку персональных данных по закону отвечает ваша компания, а не вайбкодер.
3. Систему невозможно развивать. Когда вы через полгода придёте с доработками, выяснится, что разобраться в этом коде не может никто, включая автора, который его никогда и не читал. Нормальная команда, посмотрев на такой проект, чаще всего скажет: «Дешевле переписать с нуля».
4. Цена ошибки растёт со временем. Пока в системе три пользователя и тестовые данные, всё выглядит отлично. Проблемы вылезают, когда появляются реальные клиенты, реальные деньги и реальная нагрузка. То есть в самый неподходящий момент.

Для одноразового прототипа, лендинга или маленькой внутренней утилиты вайбкодинг может подойти: быстро и дёшево. Но CRM или ERP хранит ваших клиентов, сделки и деньги и должна жить и развиваться годами. Доверять такую систему тому, кто не читает собственный код, плохая идея.
Ирония в том, что мы используем ИИ едва ли не больше, чем вайбкодеры. Разница в контроле. Дальше по этапам.

Любой наш проект начинается с прототипа и технического задания (как мы это делаем, описано здесь). ТЗ на средний проект занимает от 50 до 300 страниц. В таком объёме неизбежно встречаются логические дыры: ситуации, которые не предусмотрели, и противоречия между разделами.

Раньше такие дыры находились одним способом: программист в ходе разработки упирался в неописанную ситуацию, работа вставала, начинались уточнения с заказчиком. Теперь у аналитика есть второй читатель. Готовое ТЗ мы отдаём на проверку ИИ, и он вычитывает документ целиком, задавая неудобные вопросы.

Два примера из наших рабочих переписок (детали проектов изменены).

Мы: Вот ТЗ на модуль документооборота, найди слабые места.
ИИ: В разделе про акты написано: «Два документа объединяются в один PDF-файл и скачиваются». А если один из документов ещё не загружен, что увидит пользователь? А если загружен файл другого формата, например фотография? В ТЗ ответов нет.
Кажется мелочью, но для программиста каждый такой пробел означает остановку работы и переписку с заказчиком посреди разработки. А подобных вопросов ИИ задаёт десятки по одному документу.

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

Все замечания ИИ разбирает аналитик: часть уходит в правки, часть отклоняется. В разработку ТЗ приходит с меньшим количеством дыр, а значит, проект идёт с меньшим количеством остановок, переделок и разговоров в духе «а мы думали, вы имели в виду другое».

Теперь про сам код. Здесь важно понять отличие профессиональной работы с ИИ от вайбкодинга.
Вайбкодер пишет нейросети: «Сделай мне модуль заявок для CRM». Получает простыню кода, вставляет в проект и надеется, что заработает.

Наш программист работает иначе. Код он ведёт сам и знает его досконально, а ИИ подключает точечно, к конкретным функциям и строкам: «Допиши эту функцию, она получает данные вот из этого метода в соседнем файле», «предложи, как ускорить этот запрос к базе», «напиши тесты для этого класса». Чем точнее программист описывает связи в коде, тем полезнее ответ. И каждую предложенную строку он понимает, потому что мог бы написать её сам, просто медленнее.

В повседневной работе это выглядит так:

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

Аналогия простая: электроинструмент в руках профессионального строителя. Шуруповёрт не делает человека мастером, но мастера делает заметно быстрее. А в руках того, кто строить не умеет, он лишь ускоряет строительство кривого сарая.

В разработке код попадает в проект не сплошным потоком, а порциями: программист завершает кусок работы и отправляет его на слияние с основным проектом (на профессиональном языке это называется merge request, или MR).

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

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

Почему это важно понимать заказчику? Тщательное ревью каждого куска кода относится к вещам, о которых в отрасли все говорят, но которые мало кто делает по-настоящему. Внимательно читать чужой код долго и дорого, поэтому в реальности ревью часто сводится к беглому взгляду «вроде нормально». ИИ вычитывает всё, всегда и с одинаковой дотошностью, а тимлид тратит время не на рутинную вычитку, а на проверку выводов и архитектурные решения. Получается двойной контроль на каждой порции кода: машинный и человеческий.

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

Как это устроено, простыми словами:

1. Проект нарезается на модули по бизнес-смыслу: заявки, платежи, права доступа, интеграции и так далее. Каждый модуль должен быть таким, чтобы его можно было прочитать целиком, ничего не пропуская.
2. На каждый модуль запускается отдельный ИИ-агент. Десятки агентов работают параллельно, и каждый читает весь код своего модуля, проверяя его сразу по четырём направлениям: безопасность, корректность работы, производительность и качество архитектуры.
3. Каждую серьёзную находку пытается опровергнуть отдельный агент-скептик. Это ключевая часть метода. Скептик по умолчанию считает находку ложной и ищет в коде всё, что могло бы проблему нейтрализовать. В отчёт попадают только находки, пережившие такую проверку на прочность. Иначе получился бы не аудит, а список догадок.
4. По каждой находке указывается конкретный файл и строка кода. Любую находку разработчик может открыть и проверить своими глазами.

Несколько цифр из реальных прогонов: аудит системы из 18 модулей занял 33 минуты работы 43 агентов, аудит проекта из 15 модулей занял 28 минут и 98 агентов. Человеку, чтобы прочитать столько кода с сопоставимой внимательностью, понадобились бы недели. Именно поэтому полные аудиты в отрасли до сих пор экзотика: вручную они непозволительно дороги.

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

Вопрос, который возникает почти у всех, и он правильный. Раз ИИ читает код, значит, код отправляется на серверы ИИ-сервисов. Да, это так. Разберём, что это означает на практике.

Сначала о том, что не отправляется никогда:

• Данные ваших клиентов. ИИ работает с кодом системы, а не с информацией, которая в ней хранится. Рабочая база данных живёт на вашем сервере, разработка и все проверки идут на тестовых данных. Ваши клиенты, сделки и суммы во внешние сервисы не попадают.
• Пароли и ключи доступа. По стандартам разработки секреты (пароли от баз данных, ключи интеграций с другими сервисами) хранятся не в коде, а в отдельных файлах настроек, так называемых env-файлах. Эти файлы исключаются из передачи, ИИ их не видит.

Остаётся сам код. И здесь стоит знать одну вещь: в большинстве современных проектов код и так давно хранится вне компьютеров разработчиков, на GitHub или GitLab. Это облачные сервисы для хранения кода, которыми пользуется практически вся отрасль, включая крупнейшие корпорации. То есть код вашего проекта, скорее всего, уже расположен на чужих серверах, индустрия много лет живёт с этим и считает нормой. Передача фрагментов кода ИИ-сервису по уровню риска сопоставима с этой давно привычной практикой.

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

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

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

1. Попросите на созвоне показать экран: как выглядит ИИ-ревью последнего MR в действующем проекте. У команды с настроенным процессом это займёт минуту. Тот, у кого процесса нет, начнёт объяснять, почему именно сейчас показать неудобно.
2. Попросите пример отчёта аудита кода. В настоящем отчёте у каждой находки указан файл и строка. Общие слова «код качественный, замечаний нет» отчётом не являются.
3. Дайте кусок своего ТЗ или описания задачи и попросите при вас прогнать его через их проверку. Заодно увидите, какие вопросы вам зададут. По качеству этих вопросов о команде понятно очень многое.

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

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

Менеджер проекта по-прежнему контролирует сроки и общается с заказчиком, и здесь ИИ мало что изменил: договариваются люди с людьми.

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

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

QA-специалисты стали важнее, чем когда-либо: теперь проверять нужно не только за людьми, но и за ИИ, и финальное «система работает правильно» произносят именно они.

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

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