Спор о том, что AI-кодинг может помешать формированию экспертизы, неудобен для обеих сторон. Он не говорит, что coding agents бесполезны, и не требует снова писать весь шаблонный код вручную. Вопрос практичнее: что происходит с инженерным мышлением, когда компании уже внедряют Claude Code, Cursor, Codex, Copilot-подобные инструменты, Gemini CLI и OpenCode, а часть работы, на которой раньше учились разработчики, всё чаще отдаётся агенту?

Разработчик между AI-агентом, архитектурной схемой, тестами и ревью

Поводом стала дискуссия Hacker News вокруг эссе Lars Faye “AI Coding will Prevent Expertise”. Автор говорит о риске потери «когнитивного трения» — той рабочей борьбы с задачей, из которой вырастает понимание. Тред зацепил людей, потому что многие команды уже чувствуют это в работе: AI производит больше кода, Jira-текста, design notes и review comments, чем команда успевает осмыслить. Узкое место смещается с написания на понимание, тестирование, ревью и ответственность.

Что в тезисе важно

Самая сильная мысль Faye — “skilled orchestrator paradox”. Больше всего выигрывают опытные инженеры. Они замечают, когда агент выбирает плохую архитектуру, изобретает несуществующий API, прячет миграционную стоимость или делает изменение, которое потом будет трудно сопровождать. Они задают лучшие вопросы, потому что уже примерно знают, как выглядит хороший ответ.

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

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

Почему спор стал живым

В обсуждении Hacker News быстро появились два лагеря. Первый сравнивает AI с компиляторами, IDE, автодополнением и Stack Overflow: инструменты всегда снимали ручную работу, профессия адаптировалась, никто не требует писать на ассемблере для каждого веб-сервиса.

Второй лагерь отвечает: AI отличается тем, что может убрать не только ручной набор, но и сам процесс рассуждения. Компилятор не приносит готовую архитектуру. Stack Overflow давал фрагменты, которые надо было понять и встроить. Coding agent может за один проход выдать правдоподобный diff, объяснение и тесты. Принять это легко даже тогда, когда понимание автора поверхностно.

Обе стороны частично правы. Инструменты, убирающие низкоценную работу, полезны. Инструменты, убирающие обратные связи, опасны. Поэтому вопрос не в том, нужен ли AI в разработке, а в том, какие петли проверки команда обязана сохранить.

Бизнес-ловушка скорости

Компании легко измеряют AI adoption через видимую производительность: больше pull requests, быстрее закрытые tickets, больше тестов, короче cycle time. Эти метрики полезны только рядом с качественными сигналами. Команда может генерировать больше кода, чем способна прочитать и сопровождать.

Особенно опасен управленческий посыл «если пишешь вручную, ты медленный». Тогда инженер перестаёт делать работу, которая защищает продукт: читать diff, спорить с требованиями, трассировать edge cases, отклонять слишком широкий change или спрашивать, нужна ли фича вообще.

AI увеличивает и окружающий шум. Product managers генерируют длинные tickets, engineers — длинные design notes, review tools — больше comments. Команда фильтрует артефакты, которые звучат точно, но не всегда отражают реальное решение. Производительность не равна объёму текстов и PR.

Новичкам нужны не только готовые ответы

Самая уязвимая группа — junior developers. Senior может использовать агента как выносливого pair programmer, потому что умеет спорить с ним. Новичок часто использует тот же инструмент как машину ответов. Разница не в морали, а в базе знаний.

Здоровый AI-assisted learning должен заставлять модель сначала показывать рассуждение, альтернативы и риски. Пусть агент опишет текущую кодовую базу, найдёт ограничения, предложит план, задаст вопросы и назовёт тесты. Только потом стоит разрешать реализацию. Цель — превратить агента в наставника и рецензента, а не в автомат выдачи патчей.

Командам стоит сохранять прямую практику: отладка без AI, чтение незнакомого кода, маленькая фича с нуля, объяснение дизайна на ревью. Это не ритуалы против прогресса. Это способ сохранить навык, по которому потом проверяется ответ агента.

AI может быть хорошим учителем

Нельзя описывать AI coding tools только как угрозу. При правильном использовании они ускоряют обучение: можно попросить карту legacy-модуля, примеры незнакомого фреймворка, сравнение двух подходов к базе данных или критику тестовой стратегии. Это лучше, чем молчаливое непонимание.

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

То же касается других AI workflows: аналитики, юристы, маркетинг и support тоже могут производить черновики быстрее, чем люди успевают проверять. Если организация теряет доменную экспертизу, красивый текст становится новым источником риска.

Надо ли читать AI-код

Смежный тезис Adam Tornhill про “uncertainty machine” добавляет баланс. Возможно, цель не в том, чтобы одинаково внимательно читать каждую строку. Разработка давно живёт на абстракциях: мы доверяем библиотекам, компиляторам, базам данных и ОС, не читая их полностью.

Но выборочное доверие требует границ. Можно не инспектировать каждую строку только там, где есть контракты, тесты, наблюдаемое поведение, ограниченный blast radius и понятные архитектурные инварианты. Кто-то всё равно должен знать, какие инварианты важны. Если никто не может объяснить, почему change безопасен, зелёные тесты — слабое утешение.

Разумная политика — risk-based review. Маленькое UI-изменение не равно auth logic, payments, data migration, concurrency или security-sensitive code. AI-generated code не требует мистического страха, но требует владельца.

Auto mode повышает ставки

История с Claude Code auto mode показывает, почему вопрос актуален. Меньше prompt friction удобно: разработчик не хочет подтверждать каждый безобидный tool call. Но чем меньше агент прерывается, тем важнее заранее определить sandbox и правила.

Командам нужны явные границы: какие директории можно менять, какие команды запускать, можно ли ставить зависимости, трогать migrations, CI, generated files и когда нужен human approval. Автономия без политики превращается в доверие от усталости.

Лучший workflow начинается с контроля: агент исследует, пишет план, задаёт вопросы, ждёт разрешения на рискованные действия и меняет код маленькими diff. Так сохраняется полезное трение, а не ручная рутина.

Практическая политика

У каждого AI-assisted change должен быть human owner, который объясняет цель, риски и rollback plan. В PR description стоит отмечать AI-assisted parts, если это помогает выбрать глубину ревью.

Агент сначала планирует, потом пишет код. Для нетривиальных задач нужен короткий design note или ADR: что меняется, что вне scope, какие тесты покрывают риск, какие operational consequences есть. Большие невидимые refactors без объяснения должны быть исключением.

Тесты обязательны, но не заменяют review. Ревьюеры должны искать hallucinated APIs, лишние абстракции, широкие переписывания, hidden state changes, новые зависимости и код, который автор не может объяснить.

Нужны и no-AI drills. Пилоты тренируют ручные процедуры; инженерам тоже полезно иногда отлаживать, читать и проектировать без агента, чтобы базовые навыки не атрофировались.

Метрики тоже надо менять: escaped defects, rollback rate, review load, maintainability, incident causes и time-to-understanding важнее, чем один PR throughput. Если кода стало больше, а ревью-долг и инциденты растут, компания не стала продуктивнее.

Зрелая позиция

Вывод не в запрете coding agents. Зрелое внедрение AI — это engineering-management task, а не просто покупка tool subscriptions. Агенты сильны, когда снимают механическую работу и расширяют исследование. Они опасны, когда заменяют способность команды судить об архитектуре, риске и сопровождении.

Будущий разработчик может писать меньше сырого кода. Это нормально. Но он всё равно должен понимать системы, отказы, tradeoffs и ответственность. Команда, которая не умеет сказать «это неправильное решение, хотя оно скомпилировалось», не получила AI advantage. Она автоматизировала потерю инженерного суждения.