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

Автор: Егор Плужнов, техлид vin.team. Копирайтинг: Claude AI.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Звучит абстрактно? Покажу на примерах.

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

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

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

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

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

Заказчик

Сформулировано чисто, логика прослеживается, реализуется за день.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Как написана эта статья

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

Сам текст нейросеть пишет за минуты. А над статьёй я сидел несколько дней, и то, что вы читаете, — семнадцатая версия.

А еще обсуждали текст с командой и вносили правки

Куда ушли эти дни. Первые версии выглядели законченными: гладкий текст, правильная структура, все мои примеры на месте. Только читать это было скучно: ни сюжета, ни живого голоса, зато полно типичных нейросетевых оборотов. Потом нейросеть придумала «распространённое мнение», которого никто не высказывал, просто чтобы было с чем спорить. Мой гипотетический пример «допустим, в требованиях записано 99,9% точности» подала как реальный случай из нашей практики. Каждую такую вещь надо было заметить и объяснить, почему так нельзя.

Это ровно то, о чём статья: результат появляется быстро, выглядит законченным, и вопрос «а то ли это» легко проскочить. Разница в одном: в тексте ошибку видно глазами, а в системе она всплывает, когда систему уже сдали.

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

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