Последние месяцы в профессиональных сообществах и социальных сетях не утихает эйфория вокруг феномена «вайбкодинга» (vibe coding). Концепция рисует идиллическую картину будущего: программисту больше не нужно всматриваться в строчки кода, разбираться в алгоритмах и вручную возиться с синтаксисом. Достаточно набросать спецификацию или промпт на человеческом языке в чат кодинг-агента, и нейросеть услужливо сгенерирует реализацию, напишет тесты и сама проверит их прохождение. Появился даже популярный лозунг: «Не читай код, просто доверяй процессу».
На первый взгляд, искушение велико. Скорость появления прототипов действительно поражает воображение. Однако за этим внешним лоском скрывается серьезная инженерная ловушка.
Известный популяризатор фундаментальных принципов программирования Тимур Шемсединов (HowProgrammingWorks) в докладе «Не читай код: худший совет эпохи ИИ» (первой части фундаментального цикла «Архитектура и ИИ») провел безжалостный разбор этого заблуждения. Его главный тезис звучит отрезвляюще: отказ от вдумчивого чтения кода — самый опасный совет текущей технологической волны, гарантированно ведущий к архитектурному коллапсу системы на дистанции в несколько месяцев.
Код как единственный формальный контракт системы
Чтобы понять корень проблемы, нужно задать себе простой вопрос: чем на самом деле является программный код?
Многие воспринимают код как чисто техническую инструкцию для компилятора или виртуальной машины — некий неизбежный низкоуровневый бойлерплейт, от которого хочется поскорее избавиться. Это глубокое заблуждение. Программный код — это единственная строгая формальная модель системы, фиксирующая правила предметной области, обработку граничных состояний, владение памятью и поведение при сбоях.
Естественный человеческий язык по своей природе диффузен, размыт и полон контекстных допущений. Когда ты пишешь в промпте: «Создай сервис подписок и списывай деньги раз в месяц», ты неизбежно опускаешь сотни невидимых деталей. Что делать при частичном возврате средств? Как обрабатывать повторные вебхуки от банка? Где проходят границы транзакций?
Нейросеть сгенерирует код, опираясь на усредненные вероятности из своего обучающего датасета. Но если разработчик не читает получившийся результат, система начинает жить собственной скрытой жизнью. Отказ от чтения кода означает добровольный отказ от контроля над тем, как именно программа выполняет бизнес-задачу.
Иллюзия взаимной проверки: почему агентное ревью дает сбой
Сторонники полной автономии ИИ часто парируют: «Но ведь мы можем настроить второго агента! Пусть один бот пишет код, а второй бот в роли тимлида проводит код-ревью и отклоняет плохие решения».
В теории это звучит убедительно. На практике возникает так называемая ошибка взаимного ослепления (AI self-verification fallacy).
Обе модели — и генератор, и проверяющий — обучались на одних и тех же корпусах исходников и обладают одинаковыми вероятностными искажениями. Модели превосходно умеют генерировать локально валидный код: отдельная функция будет аккуратно отформатирована, снабжена красивыми комментариями и успешно пройдет 95% синтетических тестов. Но генеративные модели практически не способны удерживать глобальный архитектурный контекст крупного репозитория на тысячи файлов.
Агент-ревьюер радостно подтвердит Pull Request, потому что функция синтаксически безупречна. Но он не заметит, что эта функция втайне нарушила границу слоев абстракции, обратилась напрямую к чужой таблице базы данных в обход доменного сервиса или создала скрытую гонку за ресурсы в многопоточной среде.
Деградация архитектурных швов: скрытая связность
Главная катастрофа слепой генерации наступает не в первый день, а через полгода активной эксплуатации. В классической архитектуре ПО ключевыми метриками здоровья кодовой базы служат слабая связанность (low coupling) и высокая зацепленность (high cohesion). Каждый модуль должен отвечать за одну понятную задачу и взаимодействовать с остальным миром через строго зафиксированные контракты интерфейсов.
Когда кодом заправляет агент, границы модулей размываются с пугающей скоростью:
- Модель ради быстрого закрытия тикета дублирует структуры данных в пяти разных местах, вместо того чтобы переиспользовать общий тип.
- В код незаметно просачиваются сайд-эффекты: мутация глобальных переменных, неявные зависимости от состояния системных таймеров, неконтролируемые обращения к файловой системе.
- Слои архитектуры проваливаются друг в друга: контроллеры начинают напрямую выполнять SQL-запросы, а утилиты форматирования дат внезапно отправляют сетевые запросы.
Система стремительно превращается в хрупкий монолит из «спагетти-кода». В какой-то момент наступает точка невозврата: попытка исправить опечатку в модуле уведомлений ломает расчет корзины покупок на противоположном конце проекта. Стоимость владения (TCO) таким кодом улетает в космос, а команда признает, что проект проще переписать с нуля.
Смена парадигмы: от набора символов к аналитическому чтению
Означает ли критика Шемсединова, что мы должны выбросить нейросети и вернуться к ручному набору бойлерплейта в Vim? Разумеется, нет. ИИ — великолепный умножитель продуктивности, если использовать его с открытыми глазами.
Просто в профессии программиста происходит тектонический сдвиг:
- Навык механического кодинга (быстро набивать пальцами шаблонные классы, циклы и структуры данных) действительно стремительно обесценивается. С этим машина справляется лучше и быстрее человека.
- Навык глубокого аналитического чтения кода, напротив, становится главным профессиональным суперсилой инженера.
Разработчик эпохи развитых кодинг-агентов и борьбы с архитектурной эрозией систем, о которой мы рассуждали в предыдущих разборах, больше не каменщик, укладывающий каждый кирпич вручную. Он становится генеральным архитектором и строгим инспектором технадзора.
Инженер должен бегло просканировать сотню сгенерированных строк и за тридцать секунд увидеть: ага, вот здесь квадратичная сложность $O(N^2)$ на ровном месте, вот тут пропущен сброс дескриптора файла, а вот эта строчка нарушает транзакционную изоляцию.
Чтобы защитить кодовую базу от архитектурной эрозии при работе с агентами, внедрите в CI архитектурные линтеры (например, dependency-cruiser для TypeScript/JavaScript или ArchUnit для Java). Зафиксируйте в конфигурации жесткие правила: слой контроллеров не имеет права импортировать слой работы с БД напрямую. Если агент сгенерирует кривой импорт, линтер моментально заблокирует билд.
Зрелый инженерный баланс
Практический вывод прост и прагматичен. Делегируй агентам черновую работу: генерацию шаблонов тестов, парсинг форматов, рутинные миграции и создание документации. Но никогда не выключай собственное критическое мышление.
Если ты не понимаешь, как работает каждая строчка закоммиченного в мастер кода, ты больше не контролируешь свой продукт. Настоящая инженерная зрелость заключается не в том, чтобы быстрее всех нажать кнопку «Сгенерировать», а в том, чтобы вовремя заметить архитектурную трещину до того, как здание рухнет под нагрузкой.