Проблема не в коде от AI, а в том, что никто ничего не знает

Саймон Шпэти (Simon Späti), автор блога о data engineering и втором мозге, сформулировал мысль, которую многие разработчики сейчас проглатывают молча. Мы обсуждаем, убьёт ли написание кода руками профессию. Согласимся, даже пойдём дальше: код пишет AI, кодовые базы создаёт AI. По мнению автора, это всё равно не главная проблема. Главная — люди и целые команды перестали что-либо понимать в собственной системе.

«Средний» код — это не страшно, отсутствие плана — страшно

В обсуждении под одним из постов автор встретил такой комментарий:

Я думаю, AI пишет в среднем неплохой код — всё зависит от задачи и размера проекта. Так что если ваша кодовая база была хуже среднего, AI вполне может улучшить её до среднего уровня. По крайней мере, я наблюдал именно это.

С этим не поспоришь. Написать «средний» код модели удаётся. И если ваш проект был сделан наспех, без продуманной архитектуры, AI честно его поднимет до крепкого среднего уровня. Вот этого автор не пугается. Его пугает другое.

Проблема не в коде, который пишет AI. Проблема в том, что никто ничего не знает, а все просто спрашивают Claude. В итоге у вас не остаётся вообще никакого плана. Никакого.

Что происходит в быстрорастущих компаниях

Состояние дел в стартапах, которые быстро растут, — а также в крупных компаниях, где средний менеджмент сверху давит на использование AI — хорошо передаёт один пост в X:

Я всё, с этим покончил. Это конец. Состояние инженерной работы сейчас ужасное. Я работаю на новой должности в большой компании уже полмесяца. Здесь никто ничего не знает. Спецификации, код, тесты, PRD, задачи, решения по задачам, отчёты — всё делает Claude Code.

Никто в моей команде это не любит. Нас заставляют выкатывать как можно больше. Я несколько раз слышал от вышестоящего руководства: отправка кода не узкое место, так почему мы медленные? Люди работают по 12–13 часов в день только ради того, чтобы нажать Enter. Никто ничего не читает. Люди в корпорации сами по себе не делают ничего.

Все, буквально все, от инженера первого уровня до инженера седьмого уровня делают одно и то же. Разговаривают с Claude. Чувства победы нет. Баги никто не разбирает. По факту никто больше не думает. Всё делают LLM.

Это невыносимо. Мне, честно говоря, было бы всё равно, если бы нам хотя бы давали время посмотреть код и понять, куда что идёт. Но нет, цель — просто выкатить. Что бы ни случилось.

Разбор этого поста по существу, без эмоций.

• «Код отправляется — значит, узкого места нет». Руководство перестало видеть разницу между «код написан» и «код проверен». Количество PR перестало быть метрикой прогресса.
• 12–13 часов работы, из которых уходит на нажатие Enter. Труд перестал быть интеллектуальным. Это чистая транскрипция чужих намерений в синтаксис.
• «Никто ничего не читает» — ключевая фраза. Чтение кода было главным инструментом проверки. Оно исчезло.
• Все уровни, от первого до седьмого, делают одно и то же. Иерархия компетенций сгладилась не потому, что стала ненужной, а потому, что её выключили.
• «Чувства победы нет». Работа без обратной связи о качестве не даёт ощущения результата. Это прямой путь к выгоранию.

Data engineering — исключение?

Обычно на такое жалуются разработчики. Но в data engineering, по мнению Хойта Эмерсона, люди устроены иначе:

Я думаю, что те, кто работает с данными, устроены по-другому. Мы всё время должны были знать всё о продукте и бизнесе с первого дня. AI просто убирает для нас трение.

Автор согласен с первой половиной. Data-инженеры, которые начинали до прихода AI, действительно должны были знать очень многое. Либо сами, либо через привлечённых экспертов по предметной области. Чтобы разобраться, как устроен продукт и как он работает в реальном мире, своих знаний не хватало, и их приходилось добывать.

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

В этом и заключается ловушка. Те, кто начинает сейчас — и сам автор, если бы он начинал с нуля в новой области, — упускают именно те знания, которые раньше приходилось добывать как обед.

Продакт-менеджер может построить что угодно. И это проблема

Отличное замечание Шэна Бина: всегда вызывали уважение продакт-менеджеры, которые не умеют писать код, но умеют собрать команду и получить нужный софт. Понимать, чего ты хочешь, всегда было самой сложной частью.

Теперь, по мнению автора, хороший продакт-менеджер может построить вообще что угодно: найти рынок, придать этому приличный вид и так далее. Звучит как победа. Но есть обратная сторона.

Если вы не умеете писать код, вы построите очень плохую основу для продукта. А продукт на плохой основе потом тяжело сопровождать. Автор тут же делает поправку: AI с каждым годом лучше справляется и с сопровождением, особенно если часто переделывать код. Так что не всё так мрачно.

Но выбрав не тот язык или не ту модель мышления, вы стартуете неправильно с самого начала. И никакой AI это не исправит.

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

Финальный босс — сопровождаемость

Автор сводит всё к одному пункту: сопровождаемость. Финальный босс, который никуда не денется, — это сопровождаемость.

Логика простая. Чем проще сгенерировать быстрый пайплайн, приложение или BI-дашборд, тем больше этого добра вам потом придётся сопровождать. Простота создания не создаёт простоту поддержки — она её покупает. Каждая сгенерированная штука — это долг, который кто-то должен обслуживать. И если в команде никто ничего не знает, обслуживать будет некому.

Это ровно тот случай, когда отсутствие плана становится не методологической ошибкой, а прямой угрозой проекту.

AI не может вести себя сам

Конечно, AI не умеет формулировать себе задачи. Отсюда естественный вопрос: зачем вообще нужны люди?

Ответ автора: это как раз явный признак того, что люди по-прежнему нужны. Нужны, чтобы направлять и координировать работу AI. Поэтому намерение, вкус, дизайн и архитектура до сих пор остаются killer features сегодняшнего мира.

Вот только когда всего этого нет — или, что хуже, оно не просто отсутствует, а считается ненужным, — становится по-настоящему опасно.

Автор читал, что это проблема, которую создали сами себе. И что если бы компании по-прежнему нанимали джунов, проблемы бы не было. И тут же добавляет: да, но это не так просто.

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

Что почитать

Автор собрал несколько материалов по теме:

• Writing code by hand might be dead, but it certainly helps — его же размышление о том, писать ли код руками
• Having Taste (with AI) — почему вкус стал важнее, чем раньше
• If Consumed by a Human, Should Be Written by Human
• What I Learned Writing with AI — материал, к которому автор отсылает как к основному источнику
• Пост Криса Дженкинса о том, что людей волнует не вайб-кодинг, а напористый средний менеджмент

Истоки мысли, по словам автора, — видео Примагена и его разбор ограничений LLM.

Главное

«AI пишет средний код» — это не проблема. Проблема в том, что команда не знает, зачем этот код написан, как он устроен и что будет с ним через год. Пока никто не понимает систему, сопровождаемость нельзя отдать на откуп модели. Поэтому в основе остаётся то, что модель заменить не может: замысел, архитектура и люди, способные их объяснить.