Два вечера до магазина: что на самом деле происходит
Человек за два вечера собирает с помощью ИИ работающий интернет-магазин кормов для кошек, показывает его знакомым и объявляет о наступлении новой эры разработки. Порог входа в создание софта действительно упал до пары свободных вечеров, и спорить с этим бессмысленно. Непонятно другое: что произойдёт с этим кодом через месяц, когда придёт первое требование на изменение. Автор колонки на Хабре предлагает дождаться хотя бы этого момента, прежде чем хоронить профессию.
Разница между «работает у меня на ноутбуке» и «работает у клиента» никуда не исчезла. Она сместилась: раньше основное время уходило на набор кода, теперь узким местом стало понимание того, что система обязана сохранять при изменениях.
Инструмент годный, но прогнозы преждевременны
ИИ-инструменты разработки годные, и желание применить их всюду понятно: интересно, что ещё получится. Проблема не в инструменте, а в скорости выводов о профессии. Автор колонки описывает знакомую картину: человек ещё не закончил пробовать инструмент, а уже делает далеко идущие прогнозы.
Один вечер с генератором кода закрывает только видимую часть цикла. Требования, тесты, интеграции, безопасность и поддержка остаются за кадром, они не исчезли, просто пока не проявились.
Пример с самовывозом и скидкой: где ломается
Простой тест на качество сгенерированного проекта: добавить скидку. Если после этого пропадает самовывоз, значит, связь между модулем акций и логикой доставки нигде не зафиксирована: ни в типах, ни в тестах, ни в описании. Модель писала обе части по отдельности и не знала, что их нужно согласовать, а спросить было некому. Автор сравнивает это с автополивом: вода течёт, помидоры растут сами, но между «я настроил автополив» и «агрономы больше не нужны» есть принципиальная разница.
Такая поломка не редкость. Она показывает, что приложение собрано как набор независимых фрагментов, а не как система с явными контрактами. Правка в одном месте тянет последствия в другом, и первый же рефакторинг обнажает реальную стоимость владения сгенерированным кодом.
Где ИИ можно отдать работу, а где придётся проверять каждый шаг
Делить задачи стоит не по типу технологии, а по цене ошибки. Шаблонный код, тесты, миграции и рефакторинг генерация переносит дешево. Бизнес-логика, интеграции и всё, что связано с деньгами, требует пошаговой проверки. Архитектурные решения и безопасность дешевле делать самому. Ориентир по ускорению известен: на шаблонных задачах ИИ-ассистенты дают заметный выигрыш, на сложных могут замедлять работу, а часть понимания при этом уходит в сторону модели (разбор ускорения и потери экспертизы).
| Категория задач | Примеры | Режим работы |
|---|---|---|
| Шаблонный код и рутина | CRUD, DTO, миграции, тесты, документация | Отдать ИИ, проверять выборочно |
| Бизнес-логика и интеграции | Скидки, доставка, платежи, обмен с внешними API | Проверять каждый шаг |
| Архитектура и критичные участки | Схема данных, безопасность, биллинг, доступы | Делать самому |
Роли Coder, Reviewer, QA: как разделить контексты
Один агент, который сам пишет, сам проверяет и сам подтверждает, что всё хорошо, повторяет главную ошибку ручного процесса: исполнитель оценивает собственную работу. В методических материалах по агентам роли разводят. Coder пишет код, Reviewer сверяет его с требованиями и архитектурой, QA проверяет поведение, Gate решает, идёт изменение дальше или нет. Каждой роли назначают отдельный контекст и права, а количество циклов Coder ↔ Reviewer ограничивают, чтобы правки не шли по кругу (pytex.school).
Контекст важнее выбора модели. Проект готовят к работе с агентом заранее: задают стек, ограничения и критерии готовности вместо того, чтобы оставлять все решения на усмотрение модели. Правила и команды удобно держать в файле вроде AGENTS.md, который агент читает перед началом работы (fix-course.ru).
Результат проверяют по одним и тем же вопросам: он сделал то, что просили, или сам додумал требования? Можно ли внести небольшую правку, не переделывая остальное? Проверена ли мобильная версия? Эти три вопроса ловят большую часть расхождений между ожиданием и результатом.
Часть разработчиков сопротивляется такому делегированию даже при очевидном ускорении генерации: вопрос авторства и ответственности за код никуда не уходит (почему не все отдают код агентам).
Characterization tests и blast radius: инструменты контроля
Characterization tests фиксируют текущее поведение системы, включая странное и неочевидное. Их ценность видна при правках: тест падает, и о сломанном самовывозе вы узнаёте до того, как это заметит покупатель. Для системы, собранной агентом, такие тесты часто единственный способ узнать, что именно считается нормой.
Вторая метрика - blast radius, радиус влияния правки. Оценка простая: сколько модулей зависит от того, что вы меняете. Правка в модуле скидок с неявной связью с доставкой даёт широкий радиус и требует ручной проверки сценариев. В методических материалах предлагается построить карту модулей и определять границы изменений заранее, а автономность агенту выдавать постепенно: знания, затем тесты и quality gates, потом права (pytex.school).
Как понять, что подход перестал оправдывать себя
Границу применимости нельзя вывести из общего принципа, её определяют на своих задачах. Автор колонки предлагает простой критерий: на собственных экспериментах понять, где ИИ можно отдать работу, где придётся проверять каждый шаг, а где дешевле сделать самому, и в какой момент выбранный способ перестаёт себя оправдывать. Практический сигнал, что пора остановиться: помощник уже третий раз исправляет последствия предыдущего исправления (habr.com).
Метрики для самооценки: время, итерации, стоимость
Спорить о пользе ИИ бесполезно, если нет замеров. Минимальный набор: время до рабочего результата, число итераций правок, доля кода, переписанного вручную, и стоимость токенов, если вы платите за API.
| Метрика | Что показывает | Тревожный сигнал |
|---|---|---|
| Время до рабочего результата | Полный цикл: постановка, генерация, отладка, проверка | Больше, чем оценка ручной работы |
| Число итераций | Сколько раз правили результат | Каждая правка ломает предыдущую |
| Доля переписанного вручную | Сколько кода пришлось заменить | Больше половины сгенерированного |
| Стоимость токенов или подписки | Цена попытки и цена сценария | Расходы растут, время не сокращается |
Если задача с ИИ занимает два часа и пять итераций, а без него час, подход в этой точке не окупается, каким бы приятным ни был процесс. Полезно отдельно проверить, сколько вы способны сделать без модели: это показывает, что именно вы делегировали и не потеряли ли навык (ИИ-усилитель или замена).
Устойчивость AI-first процессов: что если модель подорожает или станет недоступна
Процесс, целиком построенный вокруг одного внешнего сервиса, зависит от решений, которые принимает не ваша команда. В исходной колонке вопрос устойчивости поставлен, но конкретных расчётов там нет, поэтому считать придётся по своей экономике: какую долю себестоимости составляет оплата инференса и сколько простоит продукт, если цена умножится.
Сценарии отказа: рост цены, блокировка, смена условий
- Рост цены. Если в пользовательском сценарии тысячи вызовов модели в день, подорожание токена делает маржинальный продукт убыточным. Считайте стоимость одного сценария, а не цену подписки на команду.
- Недоступность модели. Отключение доступа, региональные ограничения или снятие версии с поддержки останавливают работу, если других маршрутов нет. Проверьте, сколько времени вы продержитесь с неработающим API.
- Смена условий. Запрет на коммерческое использование, новые требования к логированию и хранению данных требуют пересмотра процессов, иногда вместе с архитектурой.
Полный отказ от ИИ тоже имеет цену: он бьёт по конкурентоспособности и требует отказаться от части привычных инструментов (цена отказа от ИИ). Выбор не сводится к двум крайностям, важно, чтобы зависимость была осознанной.
План Б: локальные модели, мультипровайдерность, абстракции
- Локальная модель для критичных задач. Менее мощная, зато не зависит от чужого прайса и наличия ключа. Для классификации, черновой генерации и рутинных операций этого часто хватает.
- Тонкий слой абстракции над API. Один интерфейс для вызовов модели, чтобы провайдер менялся конфигурацией, а не переписыванием кода по всему проекту.
- Мультипровайдерность. Два рабочих маршрута вместо одного плюс заранее известные различия в качестве и цене.
- Проверка на переключение. Раз в квартал прогоняйте ключевой сценарий на резервной модели и смотрите, что ломается.
AI-first не означает AI-only. Возможность выполнить работу без ИИ, пусть медленнее, и есть страховка от изменения внешних условий.
Организационные и карьерные последствия: как продавать вывод «здесь пока не надо»
Разговор об ограничениях начинается не с технологии, а с ожиданий внутри компании. Прототип показать легко, отказ от участка работы объяснить сложнее.
Почему «здесь пока не надо» - сложный разговор
Автор колонки замечает, что с выводом «вот здесь пока не надо» неудобно выступать с позиции Chief AI Transformation & Visionary Strategist, и ещё неудобнее приходить к руководителю, которому уже объяснили потенциальную экономию. Обещанные четыре недели при предметном разборе превращаются в восемь, а за требованием «ускорить работу команды» регулярно обнаруживается желание хоть как-то планировать работу.
Признание ограничений читается как отказ от инноваций, хотя это способ не потерять деньги на масштабировании неудачного пилота. Пилоты часто умирают не из-за качества модели, а из-за отсутствия владельца результата и понятных метрик (почему корпоративный ИИ не взлетает).
Как аргументировать: метрики, пилоты, критерии успеха
- Сформулируйте критерии успеха до начала пилота: время до результата, доля переделок, стоимость сценария. Без них спор перейдёт в оценки на вкус.
- Замерьте один и тот же участок работы с ИИ и без него, ограничив пилот одной командой и одним процессом.
- Принесите результат в виде цифр и рисков. Отсутствие выигрыша тоже результат эксперимента, а не провал.
- Предложите гибридный режим: ИИ на одних участках, человек на других, с явными правилами перехода между ними.
Практические эксперименты: как определить границы на своих задачах
Порядок действий простой: выбрать типовую задачу из своей практики, выполнить её с ИИ и без, замерить время и качество, разобрать, где ИИ помог, а где создал проблемы, повторить на разных типах работ (код, рефакторинг, тесты, документация) и собрать личную карту применимости.
Шаблон эксперимента: задача, время, итерации, вывод
| Задача | Время с ИИ | Время без ИИ | Итераций | Доля переделок | Вывод |
|---|---|---|---|---|---|
| Добавить скидку в магазин | 2 ч | 1 ч | 5 | 40% | Проверять каждый шаг |
| Написать тесты на модуль доставки | 25 мин | 1,5 ч | 1 | 10% | Отдать ИИ |
| Спроектировать схему заказов и оплат | 3 ч | 2 ч | 4 | 60% | Делать самому |
Цифры в таблице условные, подставьте свои замеры. Задача шаблона - превратить спор о пользе ИИ в набор наблюдений, на которые можно опереться в разговоре с командой и руководством.
Учитывайте ограничения, в которых вы работаете: требования компании, специфику домена, характер прикладной деятельности и ограничения по копирайту. Один и тот же инструмент в разных условиях даёт разный результат, поэтому чужие выводы переносятся плохо.
Инструменты меняются быстро: то, что сегодня требует ручной проверки, через полгода может уйти агенту целиком. Карту применимости придётся пересобирать, и это нормальная часть работы, а не разовая настройка. Начните с одной задачи на этой неделе, в пользе ИИ для которой вы сомневаетесь: два прогона, замер времени и итераций, одна строка в таблице. Через десяток таких строк у вас будет собственный ответ на вопрос, где ИИ действительно ускоряет разработку, а где создаёт цикл исправлений.