Вопрос, который висит почти на каждых переговорах, где-то между первым созвоном и коммерческим предложением: зачем вообще нанимать команду разработки, если нейросеть соберёт систему сама?
Этот вопрос я задаю себе и сам. Нейросети сейчас участвуют почти во всём, что мы делаем: пишут код и помогают разбирать требования. Чёрт! Да я с Claude Code общаюсь чаще, чем с матерью.
Работа стала заметно быстрее. Но когда собрать систему стало легко, на первый план вышло другое: понять, какую именно систему собирать.
За последние месяцев пятнадцать у нас поменялось многое: как пишется код, как готовится аналитика, что присылают заказчики и с чем они вообще приходят. Часть процессов пришлось перестраивать на ходу. Дальше — что из этого вышло, на примерах проектов, которые сейчас в работе. Это заметки по итогам года, и выводы у меня пока не окончательные.
Систему сдали, заказчик отказался её принимать
В конце прошлого года мы начинали проект электронного архива. Компания оцифровывает документы: сканы загружаются в систему, из них извлекаются нужные данные, операторы проверяют результат и правят ошибки.
На одной из первых встреч выяснилось, что эту разработку уже заказывали. Заметно дешевле, у другого подрядчика.
Дальше со слов заказчика. Подрядчик почти месяц не выходил на связь и ни о чём не спрашивал. В конце, ровно по договору, прислал ссылку на демо готовой системы.
Мне это демо показали. Система работала. В ней было много того, чего заказчик не просил, части нужных функций не было, а часть была сделана, но не так, как им нужно. Работу не приняли, деньги вернули, и всё пришлось начинать сначала.
Я вспоминаю этот случай каждый раз, когда слышу, что систему теперь можно просто сгенерировать. Технически там всё было в порядке. Система была. Просто не та.
Как нейросети встроились в нашу работу
Мы не просто даём модели задания. Под неё выстроено окружение: свои правила и инструкции (riles, skills), подключённые рабочие инструменты (mcp), накопленная за годы библиотека решений и архитектурных заготовок. Модель работает внутри наших наработок, и правила мы дописываем постоянно. Код в таком виде пишется заметно быстрее, чем два года назад.
Аналитика тоже ускорилась. Разобрать длинный регламент или найти противоречия в требованиях с моделью получается заметно быстрее.
А изменилось вот что. Раньше путь до работающей системы был долгим, и по дороге сами собой всплывали вопросы, правильно ли мы её строим. Теперь путь короткий. Работающий результат появляется быстро, выглядит законченным, и вопрос «а то ли это» легко проскочить: его просто не успеваешь задать.
Звучит абстрактно? Покажу на примерах.
ТЗ, которое помогала писать нейросеть
Сейчас мы делаем внутреннюю систему для компании, которая организует медицинские мероприятия для фармкомпаний: лекции, круглые столы, исследования. Процесс у них годами строился в почте, мессенджерах и Excel. Заявку ведут несколько человек: финансовый менеджер, тревел и кадровик. Как всё устроено, знают конкретные люди, и за годы накопилось много особых правил под отдельных клиентов.
В какой-то момент компания устала от ручной работы и решила собрать всё в одну систему. Правила и условия описали в подробном задании, часть требований прорабатывали через нейросеть. Когда процесс переносят в систему, почти всегда хочется заодно его улучшить и заложить каждый особый случай, чтобы ничего не забыть. Так было и здесь.
Задание получилось объемным, подробным, стройным, красивым и понятным. Но прежде чем строить из него систему, каждое правило мы все равно расшатывали: проверяли, выдержит ли оно реальную работу. Вот одно из них, дословно:
«При этом для отдельных заказчиков может существовать настройка: "Заявки данного заказчика обрабатывает Travel-менеджер". Но даже в этом случае финансовый менеджер в любом случае регистрирует заявку, после чего передаёт её Travel-менеджеру».
В целом описано ок, и реализовать такое можно за день.
Требование пыталось закрепить настройкой тот особый порядок, который годами сложился с несколькими клиентами. И такое решение вводит системные проблемы. Появляется согласование в обход ролей: тревел-менеджеру придётся показать разделы, которые он видеть не должен, и в части заявок он начнёт работать за финансового. Получается, что в части заявок уже непонятно, кто за них отвечает. А систему заказывали как раз для того, чтобы это было понятно.
Мы разделили это на две вещи. Добавили возможность передать заявку на согласование любому менеджеру с обязательным комментарием, зачем передаёшь, — это оказалось полезно само по себе, внутренних сценариев обмена информацией стало больше. И отдельно настаивали, что смешивать роли нельзя: обосновывали это команде заказчика, спорили и в итоге согласовали.
Требование при этом нормальное и написано аккуратно. Просто в системе собранной по нему, было бы неудобно работать. Раньше сомнительное требование выдавало себя кривой формулировкой когда описываешь. Теперь оно приходит структурированным документом с нумерацией, и уточнять вроде бы нечего.
Десять видов заявок
Ещё пример из того же проекта. Заявка состоит из блоков: гонорары, обслуживание, командирование. За годы у компании накопилось больше десяти видов заявок, и отличались они друг от друга тем какие блоки в них есть, а каких нет.
В задании все десять были перечислены как отдельные сущности.
Менеджеры считали это удобным и прямо так и говорили: видишь, что это круглый стол, значит, там точно есть гонорары и обслуживание. Знание держалось в головах и работало.
Мы предложили оставить один тип заявки, в котором нужные блоки включаются. Включили обслуживание — подключился тревел-менеджер. Тогда менеджеру не надо помнить, что означает название: он просто видит, что в заявке есть.
Звучит как мелочь, но правка была не технической. Пришлось усомниться в регламенте, который складывался в компании годами, собрать аргументы, вынести на обсуждение и согласовать. По отзывам команды заказчика, работать стало понятнее.
Откуда берутся такие решения
Ни одно из них не пришло в голову за один созвон. И вряд ли пришло бы при чтении задания, даже очень внимательном.
Работа устроена скучно. Каждый день разбираешь очередной кусок, что-то понимаешь сразу, что-то откладываешь до следующей встречи. Постепенно в голове собирается картина: кто кому передаёт работу, где обычно затык, что сотрудники делают в обход регламента и почему. На следующем проекте эта картина не пригодится: там другая компания со своими исключениями, и собирать всё придётся заново.
Если отдать проработку целиком модели, на выходе будет хороший документ. Аккуратный, структурированный, возможно, с дельными замечаниями. Только вы его прочитаете, а не построите.
Разница примерно как между поездкой по навигатору и поездкой по городу, который вы знаете. По навигатору можно проехать один и тот же маршрут пять раз и не суметь повторить его без подсказок: голос говорит, куда поворачивать, и запоминать незачем. Дорога складывается в голове в карту тогда, когда вы сами решаете, где свернуть, и иногда сворачиваете не туда. Проверьте на себе: попробуйте без телефона доехать туда, куда на прошлой неделе ехали по навигатору.
С проектом так же: понимание появляется от усилия, а не от контакта с информацией.
Кстати, так можно проверить и подрядчика. Спросите на созвоне о чём-нибудь, чего нет в документе: а что будет, если состав участников поменяется после того, как смету уже согласовали? Если картина у него в голове есть, он ответит сразу. Если каждый раз слышите «надо посмотреть», вы платите за чтение вашего же ТЗ.
Макеты: где ошибаться дешевле всего
Собрать картину помогают макеты. Перед разработкой мы делаем интерактивные макеты, по которым можно кликать и проходить сценарии. На этом этапе отсеивается примерно половина гипотез, а ошибаться здесь ещё почти ничего не стоит.
Например в том самом электронном архиве мы только под расположение фильтров на экране со списком документов собрали три варианта. На этом экране одновременно нужны несколько видов обработки, массовые действия, фильтры, сортировка, поиск и настройки, и варианты мы смотрели с уже применёнными фильтрами, специально имитируя рабочее состояние. Экран с большим количеством функций разваливается в работе, когда включено пять фильтров и отмечено тридцать документов.
У этого есть обратная сторона
Один из закзчиков однажды сказал нам, по-доброму, но прямо: они устали от того, что мы столько всего пытаемся продумать заранее, выискиваем проблемные случаи и всё это согласовываем.
Возражение справедливое. Мы менее поворотливы, чем многие, и это заметно. Заказчик говорит «сделайте пока вот так, потом посмотрим», а мы те самые зануды, которые в ответ спрашивают «а что будет, если…». Вместо того чтобы просто сделать, начинаем разбирать, как это ляжет на остальные сценарии и что при этом может сломаться. Человеку, которому надо быстро проверить идею, такое трение ни к чему.
Проработка стоит не только наших часов, но и внимания заказчика, а внимания у собственника и так нет. Каждый согласованный сценарий — это его время, потраченное не на бизнес.
Решения у меня нет. Выбор идёт между усталостью на согласованиях и переделками после запуска, и граница выясняется каждый раз заново. Бывает, что заказчик со своим «потом посмотрим» оказывается прав, а мы к тому моменту уже потратили его деньги на разбор случая, который так и не наступил.
Что с этим делать, если вы сейчас выбираете подрядчика
Когда предложения отличаются в разы, посмотрите, какие этапы вообще есть в каждом из них.
Есть ли аналитика отдельным оплачиваемым этапом или работа начинается сразу с кода по вашему заданию?
Есть ли макеты до разработки, то есть то, на чём можно отсеять гипотезы, пока это ещё ничего не стоит?
Что происходит после запуска: заложен ли период доработок или проект заканчивается в день сдачи?
Готов ли подрядчик спорить с вашим техническим заданием?
Последний пункт на практике самый показательный. Подрядчик, который принимает ваше задание без единого вопроса скорее всего в нём не разобрался.
Собрать систему сегодня правда можно быстро. А вот понять, какую именно, по-прежнему долгая работа с людьми, регламентами и макетами, и её никто не отменял.
А теперь мне интересно, как это устроено у вас. За этот год процессы перетряхнуло у всех. Что вы отдали нейросетям, что не отдали и почему, где обожглись — расскажите в комментариях, правда интересно.
Комментарии (24)
m1221
29.09.2026 07:02Я вспоминаю этот случай каждый раз, когда слышу, что систему теперь можно просто сгенерировать. Технически там всё было в порядке. Система была. Просто не та.
Как я вас понимаю. Когда слышу, что сейчас всё можно "навайбкодить" - сразу понимаю, что такие комментарии осталяют люди, которые сами еще не пробовали "навайбкодить" реальный продукт. Я свой продукт делаю уже несколько месяцев, и постоянно возникают всё новые и новые доработки. ИИ сейчас очень силен, но всё же ему еще далеко до человеческого понимания природы вещей, на мой взгляд. Именно человеческого.
DrZhmurge Автор
29.09.2026 07:02Все так. Я тоже свои личные (даже коммерческие) сервисы преимущественно пишу "вайбкодом". И новая жизнь у проекта начинается когда его начинают использовать настоящие пользователи. Тут и эдж-кейсы и гонки в бд и прочие прелести.
В b2b системах это не так чувствительно, там обычно не работают сотни тысяч людей, но продуктовые ошибки возникают и через год и через 5 лет. С накоплением данных появляются новые случаи. Это если не брать в расчет, что бизнес развивается и у него меняются процессы и требования.
ToxaBes
29.09.2026 07:02Последний пункт на практике самый показательный. Подрядчик, который принимает ваше задание без единого вопроса скорее всего в нём не разобрался.
В этом случае я начинаю сам задавать вопросы и сам же на них отвечать, потому что я больше всего заинтересован в том, чтобы заказчик понимал, что происходит и как работает.
Если заказчик не может эксплуатировать созданную систему, он будет пытаться эксплуатировать разработчика. А кому это надо? Никому это не надо.
Даже на собеседованиях и при обсуждении ТЗ, регулярно приходится: "позвольте подсветить еще несколько моментов, которые не прозвучали, но также важны, начнем с лицензирования компонентов участвующих в системе... все модели используемые в системе являются национальными...система удовлетворяет требованиям класса защищенности 1Г в соответствии с РД ГТК РФ... и тд".
Dhwtj
29.09.2026 07:02Причём тут "спорить", "вопросы"?
Собирается ли заказчик автоматизировать и консервировать существующие бизнес процессы или собирается их менять?
Вещи совершенно разные, а вы их смешали
DrZhmurge Автор
29.09.2026 07:02А что вас смущает? К примеру он хочет законсервировать процессы. Как довести систему максимально быстро и дешево до гарантированно подходящего заказчику результата не проводя такие работы? В своей статье размышляю что по-моему опыту никак. Только чисто на рандоме если.
Суть «спора» не чтобы поменять процессы, а чтобы помочь их правильно выстроить.
titan_pc
29.09.2026 07:02ИИ - интеллект искуственный. Не настоящий.
Сильный сейчас не ИИ, а скрещивание тонны бекенд булевой логики с ИИ оркестратором под флагом - агент.
Вайбкодят все агентами. Сделать за день можно что угодно - да, размером с игрушку. Как танк из картона, у него вроде и пушка на месте и цвет зеленый и кабина есть - только посадить туда можно одного человечка - и тот покемон.
Переделать то что навайбкожено - проще заново навайбкодить. Это и назвали макетами.
Создать боевой танк без настоящего интеллекта невозможно. В ИИ агентов на все 50 ультра подписок можно спихнуть изготовление 100 000 деталей игрушечного размера. И потом ещё в агентов на агентов сборку в продукт. И всё равно нужен постоянный надзор за происходящим.
И времени в итоге уходит не чуть не меньше на продукт, чем раньше. Просто оно тратиться на вообще другие вещи. У вас армия бестолковых миньонов, у которых ограничено контекстное окно и у них всё каждый раз как в первый раз. И они ещё на пределе всегда и генерируют код на все ваши бабки с такой же суммарной скоростью, с какой вы его и печатали всегда. Поставил задачу - прошло пол часа, произошло по 4-5 строк кода изменений в 50 файлах. Запустили ии ревьювера, ии тестировщика - они вроде всё проокали, потом через 2 часа всё померло, потому что они окали баги и думали что всё прекрасно. Хьюман ин зе лупа - сказали надо - ревью на нас и точка. Теперь снова 30 минут шкодит армия желтых психов в подгузниках - и теперь мы за ними проверяем всё тщательно. 2 часа спустя кейс закрыт, колонка прокинута с фронта на бек до субд. Миграция написана - счастье радость авации.... Сам бы за 5 минут сделал, а тут гордость испытываешь как за дитя, которое сделало первый шаг. И думаешь ну да код писать руками уже лень и не модно.
Но вмять за ногу - у кого и когда вообще были проблемы с написанием кода? У джунов? Которые только первую книгу про код прочитали? Все эти болячки после года энтерпрайза заканчивались у всех и сразу и за быстро.
И вот процессы перевенулись) С написания кода в болтовню с заказчиком. Куда и с чего? Примерно никогда не было важно какой там код у тебя красивый или правильный. Хотя были там всякие инфоцигане и курсопродажники, утверждающее иное. Но они просто бабло стригли на маглах, нельзя их винить за это. Реальным разрабам, которые собирали эти порталы с курсами - надо было платить зп с чего то. Машина капитализма - вся херня, так бывает.
Важно всегда было что код делает, зачем и за какой бюджет рантайма по железу. За чей счет банкет по бабкам на проекте и какую пользу он принесет бизнесу. И где то там в конце списка код.
И про заказчиков - матрицы требований и всякое "занудное" существовало и до ии. Как компьютерное зрение, распознование речи и эмбеддинги с векторными базами.
И как бы странно ни было - обычно есть такой человек у бизнеса - методолог. Который понимает почему у бизнеса такие процессы сейчас, как бизнес работает, зачем в текущем бизнесе такие системы, и что в итоге они хотят изменить. Если конечно гендир выполняет там такую роль и бизнес не супер крупный - ну ему никуда не убежать от вопросов. И Ваша задача всегда стать по сути учеником методолога - чтобы понять его боли. Придется разобраться в предметной области, а не только в том как в ии пихать задачи. И понять мир где варится закзачик. Тогда вы и сделаете систему какую надо. Потому что не Вам расскажут что надо. А вы сами поймёте что надо Вооооот что. Это как дип рисёч, но только не в то как распознать картинку с точностью до 100% - а в то как понять боль заказчика по двум его предложениям - я бизнес такой то, численность такая то, в процессах таких то нам не хватает вот этого.
И Вы пошли через ии агентов копать и учиться что за бизнес, какие там процессы, что с чем связано. Как там работают люди, в чем. Что едят на завтрак и почему это влияет на пропускную способность цеха. Раскопали всё что ток могли. Поняли и тут бац - вернулись к заказчику как его заместитель и такие - ну вот так делаем.
Вот чего все хотят сейчас. Чтобы всё само делалось)
DrZhmurge Автор
29.09.2026 07:02Спасибо за такой обширный комментарий! Мне понадобится пару дней чтобы разобраться что к чему чтобы ответить)
mist56
>Выбор идёт между усталостью на согласованиях и переделками после запуска
Нет такого выбора. Это лишь перекладываение ответственности за принятие решений на заказчика до того, как работа будет начата. Больше ничего. Заказчику реально это не надо, так как он редко сам ещё понимает, что хочет. Всем надо поиграться с каким-то прототипом и осознать, как лучше делать и делать ли после прототипа что либо вообще. Это естественный жизненный цикл нормальной разработки (при условиях, что разрабатывается новая для заказчика тема и есть возможность дорабатывать потом, либо всё выкинуть).
И да, это всё полностью противоречит следующему вопросу заказчика, а сколько это всё будет стоить, при полном нежелании включать голову в продумывание требований. И решений этому не особо, кроме как оценивание и выполнение мелких этапов, где все осознанно идут на риск. Одни не знают, что получат, другие не знают - попали ли в оценку. Либо полный ТМ где риск берёт на себя заказчик и опытные заказчики вполне осознанно на это идут.
DrZhmurge Автор
Нормальная работа и ведется этапами. А чтобы заказчик понял что он хочет и делаются сначала макеты, потом прототипы, потом собирается обратная связь и проводятся доработки. Я в целом об этом и пишу в статье. Тут и возникает та самая усталость.
А иначе мы просто делаем «как в тз» быстро и потом получаем «мины» уже на проде в готовой системе.
Если делать так, то проще вообще купить подписку на нейросети и писать себе сервисы самостоятельно. Многие так и делают.
mist56
Все уже друг от друга устали. И от расходов и от "качества" и от суровой реальности, где куча граблей и проблем, которые вдруг чудесным образом не исчезают с новым поделием. Поэтому SaaS и прочие силвер буллеты взлетали, теперь падают, ибо не буллеты по факту. Скоро и от агентов устанут, так как тоже не буллет.
DrZhmurge Автор
Я с вами согласен! В первых версиях статьи у меня был блок посвященный усталости. Я его оставил для отдельного материала.
Anarchon
Как-то многовато у вас спорных утверждений на один комментарий. SaaS давно взлетел и оснований его хоронить нет. Хоронить агентов, которых пока никто ничем не заместил - это вообще чудовищно преждевременно. Да и любое решение пришедшее им на смену все равно будет базироваться на ИИ, это уже аксиома.
mist56
Заметьте, слова хоронить в моём посыле нету. Есть про усталость. По графику акций SaaS компаний восторга по их перспективам не прослеживается, и оно понятно, когда половину SaaSов себе на коленке стало возможным собрать за адекватное время.
roudakov
Если заказчик сам не понимает, что он хочет - вы никогда не сдадите такую систему.
Заказчик должен понимать, что он хочет. Требования могут меняться и дорабатываться при разработке системы.: что-то не предусмотрели, что-то поменялось, для чего-то нашли лучшее решение... Но "то что заказчик хочет" не меняется. Меняться может "то как он это хочет получить".
В противном случае, получится система которая будет соответствовать формальным требования ТЗ, но будет совершенно не рабочая и бесполезная для заказчика.
DrZhmurge Автор
В том числе об этом и статья и ответ на прошлый коммент. Наша задача помочь заказчику понять что он хочет. И улучшить то, что он уже придумал.
Alex_Hi
Я почти всегда пытался добиться от клиента, а точнее от тех кто с ним связываются, узнать не "чего клиент хочет [чтобы мы сделали]", а "чего клиент хочет добиться, какая цель".
Чаще всего бывало так что то что хочет либо было мимо цели, либо до цели добирались окольными путями. Это в основном либо от незнания специфики софта, либо нюансов нашего направления, с которыми мы уже часто сталкивались и могли подсказать и решить проблему/задачу гораздо эффективнее, зная какие решения добьются цели скорее.
roudakov
Это вы описываете идеального исполнителя. А такие встречаются редко.
Если заказчик сам не разбирается в системе - подход правильный. Он не знает продукт и объясняет на своих процессах, что ему нужно. Исполнитель вникает в процессы заказчика и предлагает грамотное решение.
Однако, мне встречалось другое: исполнитель приносит решение, которое не ложится на процессы заказчика. Всё по методологии вендора, красиво расписано, хорошо задокументировано (и даже идеально реализовано), но на практике это не просто неудобно, а разрушает рабочие процессы.
Либо у исполнителя не было специалиста, который способен это увидеть, либо не было желания вникать в процессы заказчика.
Всё зависит от того, есть ли у сторон нужные компетенции и насколько сильны специалисты.
mist56
Фиксед прайс - не единственная модель разработки софта. Многие опытные заказчики вполне осознанно выбирают ТМ, так как понимают, что им нужен результат, а не абстрактная цифра с гарантированными тёрками.
roudakov
Это не опытный заказчик, а заказчик хорошенько обработанный меркетолагами. Ни один адекватный заказчик не будет вливать деньги не имея представления о том когда это кончится и что он получит в результате.
Внедрение программного продукта это вполне себе фиксированный процесс с началом и концом.
Потом, уже работающий продукт, можно дорабатывать. Внедрить новые модули, менять уже внедренные и т.д.
Но даже в этом случае, это будут отдельные проекты с началом и концом.
Ну и да, не стоит путать внедрение с сопровождением и поддержкой. Это очень разные процессы с разными задачами и методами.
mist56
В моём пузыре большинство заказчиков ТМ, так как целенаправленно их выбираем, вдоволь походив по граблям с фиксом. И как правило фикс требуют именно малоопытные заказчики. Те, кто уже годами разрабатывает, прекрасно знает, что жизнь продукта не заканчивается деплоем первой версии на сервер и именно после релиза и начинаются пляски. Поэтому ТМщики берут себе по сути на аутстафф как часть своей команды и владеют своим софтом.
roudakov
То что описано у вас не внедрение. Это что угодно: поддержка, сопровождение или доработка — но не внедрение.
Внедрение — это реализация конкретных процессов на конкретной платформе в заданных временных рамках. Его цель — перевести эти процессы на новую платформу. Внедрение почти всегда разбито на этапы, и первый релиз никогда не бывает финальным. Но у него всегда есть перечень целей и задач, которые должны быть решены, и сроки, в которые они должны быть решены.
Когда внедрение завершено, предприятие получает систему, в которой может полноценно вести свои процессы. Не обязательно все сразу и не обязательно идеально — но поставленные цели и задачи внедрением решены.
Дальше начинается сопровождение продукта: силами заказчика или сторонней организации. На уже работающей системе в рамках сопровождения можно менять процессы, оптимизировать их, добавлять новый функционал. Но это именно сопровождение, и у него другая логика управления: не фиксированный объём работ до результата, а регламент, SLA, приоритеты и поток задач.
И даже в сопровождении заказчик и исполнитель согласовывают стоимость и сроки работ. Просто согласовывают их иначе, чем при внедрении.
arsmerk777
+100 - много раз наблюдал что такие вопрошающие просто боятся брать ответственность за решения и им все надо согласовать 10 раз
DrZhmurge Автор
Раскройте немного подробнее позицию, не до конца понял что имеете в виду.