Рабочий скрипт — это ещё не рабочая система

Два часа до работающего прототипа. Два дня до того, чтобы он заработал по-настоящему. Разрыв между этими двумя цифрами — самое полезное, что я вынес из собственного опыта разработки с AI.

Зачем я вообще в это полез

Первую половину года я провёл с устойчивым ощущением, что отстаю. Вокруг люди собирали себе CRM из промпта, а я использовал AI для конкурентной разведки и подготовки контента — полезно, но как-то мелко для человека, который продаёт другим цифровую трансформацию.

Решение принял простое: каждую задачу пробовать делать вместе с AI и ждать, пока попадётся такая, где реально понадобится написать код. Перебрал три подхода — базу знаний по решениям, аналитическую систему на естественном языке и синхронизацию контактов между Telegram и Google. Последняя и стала кандидатом: у меня в Telegram куча контактов, которых нет в Google Contacts, и это давно раздражало.

Стартовая позиция: ни Python, ни API Google, ни API Telegram я не знал.

Первые два часа

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

Это было настоящее счастье. Работает. Я сам. Без разработчиков.

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

Проблема в том, что задача на этом не закончилась.

Что оказалось между прототипом и системой

Мне нужна была не демонстрация, а работающий инструмент. То есть такой, который:

• корректно разбирает дубли — а их оказалось много и они разные: один человек с двумя номерами, два человека с одинаковым именем, контакт без имени вовсе
• умеет спросить меня в сложных случаях, а не молча выбрать вариант
• обрабатывает ошибки API, а не падает на середине
• восстанавливает процесс с прерванного шага, а не начинает с нуля после сбоя
• не зависит от AI в момент выполнения и работает самостоятельно

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

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

Момент, когда я остановился

В какой-то момент я поймал себя на том, что делаю очередной микропатч одной и той же проблемы — и не понимаю, приближает ли это меня к цели.

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

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

Индустриализация

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

Контроль версий. Банально, но именно с него всё поменялось: стало возможно откатиться и, главное, увидеть, что вообще менялось за последние два часа.

Зафиксированное целевое состояние. Что именно считается готовым. До этого «готово» плавало вместе с моим настроением.

Роудмап. Порядок задач вместо реакции на то, что сломалось прямо сейчас.

Выделение переиспользуемых частей. То, что повторялось из промпта в промпт, я вынес в явно описанные блоки — и перестал каждый раз объяснять одно и то же заново.

Оптимизация промптов. Отдельная дисциплина, которая напрямую влияет и на качество результата, и на стоимость.

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

Три вывода

Пробовать обязательно самому

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

Self-service Dev нужно выстраивать так же, как когда-то self-service BI

Мы годами объясняли компаниям: раздать доступы к BI недостаточно, нужны согласованные метрики, обучение и правила. С разработкой сейчас ровно та же история. Дать сотрудникам AI-инструмент — не то же самое, что дать им возможность делать системы. Нужны общие подходы, архитектурные практики, переиспользуемые заготовки.

Классика проектирования не устарела, а стала нужнее

В институте я много читал Кнута, Вирта, Брукса — и было ощущение, что в век AI это уже музейная ценность. Оказалось наоборот. Когда код пишется за минуты, единственное, что отличает работающую систему от свалки, — понимание, как она должна быть устроена. Генерация подешевела, а проектирование нет.

Почему это важно не только для меня

Своя история интересна ровно настолько, насколько она типична. А эта — типична вполне.

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

Дальше есть два пути. Либо решение остаётся личным инструментом автора и умирает вместе с его отпуском. Либо кто-то доводит его до системы — с архитектурой, документацией и поддерживаемостью.

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