Я использую AI-инструменты каждый день. Я веду курсы по разработке с ними. Я не из тех, кто говорит, что это хайп. Но за два года наблюдений за инженерами — включая себя — я могу назвать ситуации, в которых AI стабильно делает работу хуже.
Если в этом году вы прочитаете одну контр-статью про AI в разработке — пусть это будет эта. Цена злоупотребления реальна и в основном невидима до момента, когда становится дорогой.
Правило 1: не учите фундамент через AI
Это то, что я бы написал на билборде.
Когда вы junior или подбираете новый язык, соблазн непреодолимый. Спрашиваете Claude или Copilot, получаете рабочий ответ за 10 секунд, вставляете, релизите. Баг исправлен. Дальше.
Что вы не сделали: не прочитали доку, не держали структуру данных в голове, не боролись с системой типов, не построили ментальную модель. Через полгода вы не можете дебажить свой код без AI. Не узнаёте паттерны. Ваши code review поверхностны, потому что без AI не видите, что не так.
Я наблюдал это у нескольких junior-инженеров, которых менторил. Они шипят больше за первые три месяца, чем junior’ы раньше. К девятому месяцу — плато, из которого тяжело восстановиться, потому что фундаментальные повторения не случились.
Эвристика: если вы не можете написать код без AI — вы не знаете тему. AI ок для второго раза, не для первого.
Правило 2: не используйте AI для имён, дизайна API и абстракций
Это то, что больше всего удивляет инженеров, когда я говорю это вслух.
LLM производят технически корректные имена и API. Они почти никогда не производят хороших. Разница — во вкусе: знать, что processData() — это запах, что метод с 7 параметрами просится в класс, что эта абстракция преждевременна, а та запоздала. Вкус строится годами поддержки чужого кода, особенно собственного прошлого.
Я перестал делегировать агенту:
- Имена функций и методов
- Границы классов и зоны ответственности
- Дизайн API (какие аргументы, какая форма возврата, какие ошибки)
- Когда выделять абстракцию
- Когда не выделять
Агент даст защищаемый ответ на всё это. Редко правильный. Цена всплывает через месяцы, когда никто уже не может прочитать код.
Правило 3: не дебажьте production через AI без observability
Эта ловушка чаще ловит senior’ов, чем junior’ов.
Баг в проде. Вы вставляете стектрейс в Claude. Он правдоподобно угадывает. Вы внедряете фикс. Ошибка перестаёт появляться в тестовой среде. Шипите. Через две недели ошибка возвращается.
Что произошло: стектрейс был симптомом, не причиной. Агент угадал причину по симптому — без ваших distributed traces, метрик, истории деплоев и четырёх связанных ошибок в тот же час. Он произвёл фикс, который адресовал что-то, но не проблему.
Дебаг production требует:
- Воспроизвести или точно охарактеризовать сбой
- Изолировать, какое изменение его внесло
- Построить гипотезу из реальных сигналов (логи, traces, метрики)
- Проверить, что фикс реально адресовал root cause
AI полезен на шагах 3 и 4 — но только после того, как вы сделали 1 и 2. Пропустите — и применяете правдоподобные пластыри вечно.
Правило 4: не делайте через AI того, что не можете оценить
Если не можете отличить хороший ответ от плохого — у вас нет дела спрашивать AI.
Звучит очевидно. Но это не так. Где это кусает:
- Пишете на языке, который плохо знаете. Агент пишет Rust, который компилируется и работает, но не идиоматичен. Шипите. Реальный Rust-инженер потом ревьюит репо — и там начинающие антипаттерны.
- Архитектурные решения вне вашего опыта. «Kafka или RabbitMQ?» — не вопрос с одним ответом; зависит от operational concerns, которых агент не видит.
- Security-чувствительный код. Агент даст код, выглядящий безопасным. Узнать, реально ли — только если понимаете threat model сами.
Во всех случаях AI не заменяет экспертизу. Он отмывает невежество в output, который вы шипите, не понимая, что не понимаете.
Правило 5: не используйте AI для однострочных правок
Эта мелочь, но реальная. Инженеры тянутся к AI, чтобы вставить одну строку или переименовать переменную. Ждут 4 секунды. Ревьюят результат. Принимают.
Та же правка занимает 1 секунду руками, если бы просто сделали. Совокупное время ожидания агента на тривиальных правках, по моим замерам, больше времени, которое он экономит на средних.
Эвристика: если пальцы знают, что набирать — набирайте. Агент — для случаев, когда работа в том, чтобы решить, что набирать.
Правило 6: не используйте AI для того, что должно быть в памяти
Что должно жить в голове — договорённость с другой командой, ограничение, которого нет в коде, политически тонкий компромисс, объясняющий странность кода — это нельзя делегировать агенту. У агента нет памяти этого между сессиями. Он отрефакторит странный код, существующий по причине, которую никто не задокументировал.
Документируйте почему. В комментариях кода где уместно, в CLAUDE.md если агенту нужно знать, в design docs. «Почему» — часть инженерии, не передающаяся AI, и самая ценная часть.
Правило 7: не используйте AI, чтобы пропустить code review
Вы написали код. (Даже если набирал агент — вы написали, вы отвечаете.) Прочитайте. Строка за строкой. Вслух, если помогает.
Инженеры, пропускающие этот шаг потому что «агент уже валидировал», копят невидимый долг до момента, когда он становится подавляющим. Валидация агента — статистическая: этот код похож на код, который работает. Это не то же, что валидация вдумчивого человека: этот код корректен для этой системы, в этом контексте, для того, чего я хочу достичь.
За два года это паттерн, наиболее коррелирующий с инженерами, чьи карьеры стопорятся: они относятся к AI как к gate’у качества. Это не он.
Что я делаю вместо
Для каждого случая — что я реально делаю:
| Ситуация | Что я делаю |
|---|---|
| Учу новую тему | Сначала строю ментальную модель. AI — для второго проекта, не первого. |
| Имена | Пишу три варианта руками. Выбираю лучший. Иногда прошу AI критику. |
| Production-дебаг | Подтягиваю логи, traces, метрики. Формирую гипотезу. Потом AI помогает с фиксом. |
| Код вне моей экспертизы | Парю с человеком-экспертом, когда ставка оправдывает. AI — не замена. |
| Тривиальные правки | Набираю. Быстрее, без переключения контекста. |
| Важный контекст | Документирую. В коде, в CLAUDE.md, в design doc. |
| Code review | Читаю каждую строку, каждый раз. AI — junior-коллаборатор, не senior. |
Глубже
Фрейм, который я бы предложил каждому инженеру задавать перед тем, как тянуться к AI:
Какой навык я строю — и AI делает меня сильнее или слабее в нём?
Для механической работы AI делает сильнее, освобождая время для важной работы.
Для работы суждения AI делает слабее, позволяя аутсорсить повторения, строящие суждение.
Инженеры, которые будут процветать в следующее десятилетие — те, кто видит разницу. Не те, кто использует AI агрессивнее, и не те, кто его отвергает. Те, кто точно знает, когда отложить.
Если хотите структурированный путь к работе с AI как реальным инженерным инструментом — с честным разбором tradeoffs — начните с Prompt Engineering и автоматизации AI-воркфлоу. Глубже в production AI-системы — курсы Разработка на Claude API и Claude Code Mastery подхватывают там, где статья заканчивается.
