AI каждый день: где заканчивается модель и начинается ответственность

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

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

Я пользуюсь AI каждый день. Архитектура, компромиссы и то, что доезжает до продакшена, остаются на мне. AI закрывает рутину. Решения, риски и финальный merge остаются человеческими. Вся практика в этом разделении.

Это не война с AI и не история про то, что «AI заменит senior». Это граница ответственности. Сначала ты решаешь, за что отвечаешь. Ассистент только ускоряет работу внутри этих рамок.

Что я отдаю AI

Отдаю работу, где продуктовый риск низкий, а решение уже принято. Критерий простой: ошибку дёшево поймать при проверке кода, и она не меняет саму продуктовую ставку.

Обычно это:

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

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

Что я не отдаю

Этот список и есть граница ответственности. Модели его не получают, и тем, кто нанимает, это стоит слышать прямо:

• архитектура и границы модулей
• стратегия рендера (SSR, клиент, кэш), привязанная к метрике
• что сознательно не делаем в этом спринте
• оценка риска на плотных данных, realtime и экранах с деньгами
• критерии готовности и можно ли мержить PR

На Clipshub и WhatToFarm AI не выбирал ставку «быстрее интерфейс → люди остаются». Этот вызов был моим. Его нужно было проверить на реальных путях: сканеры под нагрузкой, дашборды кампаний, страницы привлечения. Не на правках, которые просто уверенно выглядят. Модель может набросать таблицу. Она не решает, что двигает метрику: виртуализация, SSR или отказ от лишней работы в спринте.

Рабочий цикл: AI → проверка → прод

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

1. Ограничение. Я называю метрику, путь и сценарий поломки до открытия чата.
2. Задание. Я даю ассистенту короткое ТЗ: входы, выходы и что делать не надо. Не «сделай красиво».
3. Проверка. Я читаю правки как PR джуна: корректность, краевые случаи, скорость, доступность и уложился ли ответ в ТЗ.
4. Доказательство. Я решаю, что мержим и чем меряем после: LCP, срочные правки после релиза, конверсия, время на пути.

type AiAssistBet = {
  constraint: string;
  delegated: string[];
  owned: string[];
  rejectIf: string[];
};

const bet: AiAssistBet = {
  constraint: "LCP on /campaigns under load",
  delegated: ["table skeleton", "prop types", "lint fixes"],
  owned: ["cache boundary", "scope cut", "merge gate"],
  rejectIf: ["touches auth", "new design-system layer", "unmeasured ‘polish’"],
};

Модель ускоряет шаги два и три. Шаги один и четыре остаются у того, кто ответит, когда прод сломается. Если задание размытое, проверка превращается в театр. А театр как раз превращает «AI написал» в «никто не отвечает».

Где AI ломает продукт

Три паттерна, которые я отсекаю:

• сгенерировал и сразу влили, и за важный путь никто не отвечает. Правки выглядят готовыми, а что может сломаться так и не назвали.
• раздувание объёма: «раз уж здесь, пересоберём дизайн-систему». С ассистентом лишнее дёшево набрать, но не дёшево потом поддерживать.
• ложная уверенность на плотных данных, авторизации или UI с деньгами. Гладкий TypeScript прячет дорогие ошибки: гонки, пустые состояния и вопрос, кто платит, когда упадёт.

Для тимлида AI без ответственности не ускоряет поставку. Он чаще приводит к инцидентам, которые команда не может объяснить. Это не усиление, а наоборот.

Что видно через девяносто дней

Ты должен уметь показать сигналы, которые продукт уже считает:

• типовые фичи выходят быстрее, а срочных правок после релиза на твоих экранах не становится больше
• сильные инженеры сидят на узких местах, а не в шаблонном коде и бесконечных переименованиях
• junior и middle учатся на твоей проверке правок от AI: почему эту границу кэша оставили, почему тот «polish» PR не взяли. Не на слепом копировании

AI ускоряет команду только когда ответственность остаётся человеческой. Эту фразу я спокойно вписал бы в описание вакансии для команд, которым нужна поставка, а не демонстрация инструментов.

AI это рычаг. Ответственность это роль.

Я и дальше буду отдавать скучную работу. Ставку, список отказов и решение о merge нет. Производительность, процесс поставки и продуктовый риск остаются на человеческой стороне.

Это та же привычка, что и разобрать узкое место до выбора стека. Инструмент сменился. Ответственность нет. К производительности и процессу поставки то же правило: ускорять полезно, отдавать модели опасно.