У нас в команде появился новый участник. Он очень умный. Он мгновенно отвечает на любой вопрос. Он никогда не устаёт и не уходит в отпуск. Он генерирует идеальные документы, красивый код и убедительные презентации.
У него только один недостаток: он понятия не имеет, что происходит в нашем продукте.
Кейс первый: ТЗ из вакуума
Бизнес-аналитик получает задачу: нужна система скидок. Он открывает ChatGPT и пишет: «Опиши функциональные требования для системы скидок в e-commerce».
ChatGPT выдаёт прекрасный документ. Двадцать страниц. Процентные скидки, фиксированные скидки, накопительные программы, промокоды, скидки по времени, персональные предложения, A/B-тестирование скидок. Диаграммы. User stories. Acceptance criteria.
Документ приходит на разработку. Разработчики смотрят и говорят: «Э-э-э...»
Потому что:
- У нас уже есть система промокодов. Она кривая, но она есть. И с ней интегрированы три внешних сервиса.
- Наша архитектура цен — это легаси-монстр, где цена вычисляется в четырёх разных местах и собирается где-то в недрах checkout.
- Мы работаем с пятью валютами, и округление скидок — это отдельный ад, про который AI не знает.
- Бухгалтерия требует, чтобы скидки отражались определённым образом в отчётности, и это не «лучшая практика», это требование нашего конкретного бухгалтера Марины Сергеевны.
ТЗ идеальное. Для сферического e-commerce в вакууме. Для нашего продукта оно означает переписать половину системы ради фич, которые, возможно, и не нужны.
Кейс второй: роадмап мечты
Product manager готовит квартальный роадмап. Спрашивает AI: «Какие фичи должны быть в современном B2B SaaS для управления проектами?»
AI выдаёт список на сорок пунктов. Интеграции со всеми возможными сервисами. Мобильное приложение. Оффлайн-режим. AI-ассистент внутри продукта. Геймификация. Кастомные дашборды. API для всего.
PM приходит к стейкхолдерам с этим списком. Стейкхолдеры в восторге. «Да, нам нужно всё это! Почему у нас этого ещё нет?»
Разработчики смотрят на роадмап и понимают:
- Технический долг не заложен. Вообще. А у нас сервис авторизации на честном слове держится.
- Инфраструктура не потянет половину этих фич. Нужен рефакторинг, который никто не запланировал.
- Команда из пяти человек физически не может сделать сорок фич за квартал. Даже десять не может.
Но роадмап уже согласован. Ожидания установлены. Через квартал будет разочарование, и виноваты будут «медленные разработчики».
Кейс третий: дизайн без оглядки
Дизайнер получает задачу: редизайн страницы профиля. Просит AI сгенерировать «современный UI для профиля пользователя в SaaS-приложении».
Получает красивые макеты. Glassmorphism, микроанимации, нестандартные контролы, кастомные графики. Figma-файл выглядит как с Dribbble.
Проблема:
- У нас есть дизайн-система. В ней определённые компоненты, цвета, отступы. Новый дизайн не использует ни один из них.
- Кастомные контролы означают кастомную разработку. Каждый нестандартный элемент — это дни работы фронтендера.
- Микроанимации — это ещё дни. И потом ещё дни на оптимизацию, потому что на слабых устройствах будет тормозить.
- Графики предполагают библиотеку, которой у нас нет. Интеграция — неделя минимум.
Дизайнер показывает макеты клиенту. Клиент в восторге: «Хотим так!» А потом приходит оценка в три месяца вместо двух недель. И начинаются переговоры, урезания, компромиссы. Все недовольны.
Кейс четвёртый: тест-кейсы по учебнику
QA-инженер пишет тест-кейсы для новой фичи. Просит AI: «Напиши тест-кейсы для функции восстановления пароля».
AI выдаёт образцовый набор:
- Валидный email — успешная отправка письма
- Невалидный email — ошибка валидации
- Несуществующий email — сообщение «если аккаунт существует, письмо отправлено»
- Истёкшая ссылка — ошибка
- Повторное использование ссылки — ошибка
Прекрасно. Это покрывает стандартные сценарии. Это не покрывает:
- Что происходит, когда почтовый сервер лежит (у нас падал три раза за год)
- Как работает rate limiting (его настраивал Петя, который уволился)
- Что если пользователь зарегистрирован через OAuth и у него нет пароля
- Как это работает с нашей кастомной системой ролей, где у одного email может быть несколько аккаунтов
Тесты проходят. Баги находят пользователи. В проде. В пятницу вечером.
Кейс пятый: код, который работает
Разработчик получает задачу: добавить кэширование в API. Спрашивает AI: «Как реализовать кэширование в Node.js с Redis?»
Получает красивый код. Паттерн cache-aside, TTL, инвалидация. Всё по best practices.
Копирует в проект. Работает. Мёржит.
Через неделю — инцидент. У пользователей показываются чужие данные. Потому что:
- В нашем API есть контекст пользователя, и его нельзя кэшировать глобально
- Ключ кэша не учитывал права доступа
- Инвалидация не была связана с нашей системой событий
AI написал код для абстрактного API. Разработчик вставил его в конкретный продукт, не подумав о контексте. Код работал. Код был неправильным.
Почему так происходит
AI — это сжатый интернет. Он знает всё, что написано в документациях, туториалах и Stack Overflow. Он знает best practices и паттерны. Он знает, как «обычно делают».
AI не знает:
- Историю твоего продукта и почему вот этот костыль здесь не просто так
- Ограничения твоей команды, бюджета и сроков
- Политику: кто с кем не разговаривает, кто что заблокирует, кого надо спросить
- Реальных пользователей, которые используют продукт не так, как задумано
- Технический долг, который незаметен снаружи, но определяет каждое решение
Когда человек спрашивает AI в отрыве от контекста, он получает ответ для сферического продукта в вакууме. Этот ответ может быть правильным в теории и катастрофическим на практике.
Эффект уверенности
Есть ещё одна проблема. AI отвечает уверенно. Без «может быть», «в некоторых случаях», «зависит от». Просто выдаёт ответ как истину.
И человек, особенно неопытный, принимает это за экспертизу. «AI же сказал». Документ выглядит профессионально. Код компилируется. Тест-кейсы выглядят логично.
Раньше, когда человек чего-то не знал, он шёл к эксперту. Эксперт задавал вопросы: «А какой у вас контекст? А что уже есть? А какие ограничения?» Диалог рождал правильное решение.
Теперь человек идёт к AI. AI не задаёт вопросов. AI просто отвечает. И человек несёт этот ответ дальше, не понимая, чего он не учёл.
Цена переделки
Чем раньше ошибка попадает в процесс, тем дороже она стоит. Это известно давно.
Ошибка в требованиях, пойманная на этапе требований — час работы аналитика.
Ошибка в требованиях, пойманная на этапе разработки — дни переписывания.
Ошибка в требованиях, пойманная в проде — откат, хотфикс, недовольные пользователи, письмо от CEO.
AI-сгенерированные требования, не проверенные на соответствие реальности — это ошибки, заложенные в фундамент. Они прорастут. Они всегда прорастают.
Как правильно
AI — инструмент. Хороший инструмент. Но инструмент усиливает того, кто им пользуется. Если человек понимает контекст — AI помогает быстрее сформулировать то, что человек и так знает. Если человек не понимает контекст — AI помогает быстрее произвести мусор.
Несколько правил:
Для аналитиков:
Прежде чем спрашивать AI «как должно быть», узнай у разработчиков «как есть». Попроси показать текущую архитектуру. Спроси, какие ограничения. Потом используй AI для оформления — но не для придумывания.
Для продактов:
AI не знает твой рынок, твоих пользователей и твою команду. Он знает, что написано в блогах. Используй AI для структурирования идей, но не для их генерации. Идеи должны идти от пользователей и данных.
Для дизайнеров:
Красивое ≠ реализуемое. Прежде чем генерировать макеты, посмотри на компонентную библиотеку. Поговори с фронтендером. Узнай, что можно сделать за неделю, а что за месяц.
Для разработчиков:
Код, который компилируется — это не код, который работает. AI не знает твоей системы. Каждый сгенерированный кусок должен пройти через твою голову с вопросом: «Как это ляжет на наш контекст?»
Для QA:
Стандартные тест-кейсы — это минимум. Реальные баги живут на стыках. На edge cases, специфичных для твоего продукта. AI их не знает. Ты должен знать.
Контекст как конкурентное преимущество
Вот что интересно. AI всем доступен одинаково. Любой конкурент может сгенерировать те же требования, тот же код, те же тест-кейсы.
Что не может сгенерировать AI — это понимание твоего конкретного продукта. Историю решений. Знание пользователей. Понимание, почему тут так, а не иначе.
Это знание живёт в головах команды. Это и есть конкурентное преимущество. И когда люди перестают думать, полагаясь на AI, это преимущество теряется.
Продукт становится generic. Таким же, как у всех, кто спросил AI тот же вопрос.
Когда AI полезен
Чтобы не было ощущения, что я против AI — вот где он реально помогает:
- Оформление: ты знаешь, что хочешь сказать, AI помогает сказать это красиво
- Проверка: ты написал документ, AI находит несостыковки и пробелы
- Варианты: ты понимаешь проблему, AI предлагает подходы, из которых ты выбираешь
- Скорость: рутинные задачи, где контекст не важен
- Обучение: понять концепцию, с которой потом работаешь головой
Общий принцип: AI помогает, когда человек остаётся думающим. AI вредит, когда человек перестаёт думать.
Финал
У нас в команде появился новый участник. Он очень полезен, когда мы используем его правильно. Он катастрофичен, когда мы используем его вместо собственной головы.
AI не знает нашего продукта. AI не несёт ответственности за результат. AI не будет чинить прод в три часа ночи, когда его красивое решение сломается на реальных данных.
Это делаем мы. Люди. Которые понимают контекст.
AI — это усилитель. Он усиливает и компетентность, и некомпетентность. Он ускоряет и хорошие решения, и плохие.
Выбор — за нами.