Скорость без процесса - это не скорость, а техдолг

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

И вот за эти два часа я понял, почему мой инстинкт «давайте просто сделаем» - правильный по направлению, но наивный по исполнению.

Маленький проект врёт тебе

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

Это ловушка. Потому что маленький проект тебе врёт.

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

То есть фокус не в том, чтобы сгенерировать код. Сгенерировать код - это сегодня вообще не достижение. Фокус в том, что с этим кодом можно будет жить дальше.

Где на самом деле всё ломается

Я для себя сформулировал так: код генерируется легко, а ломается всё на передаче.

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

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

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

Поэтому ускорение - это не про код. Это про процесс

Самое контринтуитивное, к чему мы пришли: чтобы ускориться с ИИ, надо сначала замедлиться и построить инфраструктуру.

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

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

Звучит как много работы? Это и есть много работы. Поэтому я больше не считаю, что «давайте просто всем раздадим инструмент и завтра работаем по-новому» - это план. Это способ похоронить продукт за месяц.

Как мы решили действовать

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

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

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

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

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

Зачем мы вообще в это идём

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

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

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

Будущее тут очевидное, деться от него некуда. Вопрос только один: научимся ли мы работать с этими инструментами так, чтобы получать качественный результат, - или нет. Узнаем на цифрах.

А вы у себя как подходите - раздаёте инструмент всем сразу или сначала обкатываете малой группой? Где спотыкались?