Код всё чаще пишет нейросеть. Чем тогда занимаемся мы

Вопрос, который висит почти на каждых переговорах, где-то между первым созвоном и коммерческим предложением: зачем вообще нанимать команду разработки, если нейросеть соберёт систему сама?

Этот вопрос я задаю себе и сам. Нейросети сейчас участвуют почти во всём, что мы делаем: пишут код и помогают разбирать требования. Чёрт! Да я с Claude Code общаюсь чаще, чем с матерью.

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

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

Систему сдали, заказчик отказался её принимать

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

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

Дальше со слов заказчика. Подрядчик почти месяц не выходил на связь и ни о чём не спрашивал. В конце, ровно по договору, прислал ссылку на демо готовой системы.

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

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

Как нейросети встроились в нашу работу

Мы не просто даём модели задания. Под неё выстроено окружение: свои правила и инструкции (riles, skills), подключённые рабочие инструменты (mcp), накопленная за годы библиотека решений и архитектурных заготовок. Модель работает внутри наших наработок, и правила мы дописываем постоянно. Код в таком виде пишется заметно быстрее, чем два года назад.

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

ТЗ, которое помогала писать нейросеть

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

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

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

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

В целом описано ок, и реализовать такое можно за день.

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

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

Требование при этом нормальное и написано аккуратно. Просто в системе собранной по нему, было бы неудобно работать. Раньше сомнительное требование выдавало себя кривой формулировкой когда описываешь. Теперь оно приходит структурированным документом с нумерацией, и уточнять вроде бы нечего.

Десять видов заявок

Ещё пример из того же проекта. Заявка состоит из блоков: гонорары, обслуживание, командирование. За годы у компании накопилось больше десяти видов заявок, и отличались они друг от друга тем какие блоки в них есть, а каких нет.

В задании все десять были перечислены как отдельные сущности.

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

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

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

Откуда берутся такие решения

Ни одно из них не пришло в голову за один созвон. И вряд ли пришло бы при чтении задания, даже очень внимательном.

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

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

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

С проектом так же: понимание появляется от усилия, а не от контакта с информацией.

Кстати, так можно проверить и подрядчика. Спросите на созвоне о чём-нибудь, чего нет в документе: а что будет, если состав участников поменяется после того, как смету уже согласовали? Если картина у него в голове есть, он ответит сразу. Если каждый раз слышите «надо посмотреть», вы платите за чтение вашего же ТЗ.

Макеты: где ошибаться дешевле всего

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

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

У этого есть обратная сторона

Один из закзчиков однажды сказал нам, по-доброму, но прямо: они устали от того, что мы столько всего пытаемся продумать заранее, выискиваем проблемные случаи и всё это согласовываем.

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

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

Решения у меня нет. Выбор идёт между усталостью на согласованиях и переделками после запуска, и граница выясняется каждый раз заново. Бывает, что заказчик со своим «потом посмотрим» оказывается прав, а мы к тому моменту уже потратили его деньги на разбор случая, который так и не наступил.

Что с этим делать, если вы сейчас выбираете подрядчика

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

• Есть ли аналитика отдельным оплачиваемым этапом или работа начинается сразу с кода по вашему заданию?

• Есть ли макеты до разработки, то есть то, на чём можно отсеять гипотезы, пока это ещё ничего не стоит?

• Что происходит после запуска: заложен ли период доработок или проект заканчивается в день сдачи?

• Готов ли подрядчик спорить с вашим техническим заданием?

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

Собрать систему сегодня правда можно быстро. А вот понять, какую именно, по-прежнему долгая работа с людьми, регламентами и макетами, и её никто не отменял.

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