Хозяин поля, который разучился пахать
Почему вайбкодинг — это не столько про лень или ИИ, сколько про то, кто в итоге владеет результатом работы
Представьте: вы наняли бригаду работников для своего огорода. Они трудолюбивы, быстры, не спят, не едят, не просят прибавку. Через неделю у вас прекрасный урожай. Через месяц — отличный. Через год вы уже не знаете, где у вас лук, а где морковка. Через два — боитесь выйти на грядки без бригадира, потому что сами не понимаете, что там вообще происходит.
Примерно это сейчас и случается с частью программистов, которые открыли для себя чудо-инструменты вроде ChatGPT, Claude и Cursor. Только вместо огорода — код. А вместо бригадира — очередная «самая умная модель в истории человечества».
Давайте разберёмся, что тут на самом деле происходит — без страшных слов и с парой историй из жизни.
Часть первая. Сначала был технический долг. Потом стало хуже.
В мире программирования давно есть термин технический долг. Это когда разработчик пишет код наспех, с костылями, лишь бы работало. Продукт выходит, все довольны, а потом через полгода кто-то пытается добавить новую кнопку — и неожиданно падает весь сайт. Вот это и есть технический долг: сейчас сэкономил, потом переплачиваешь.
С приходом ИИ у технического долга появился злой брат-близнец. Он называется comprehension debt — долг понимания. Это когда код не просто плохой, а чужой. Он может быть красивым, структурированным, проходить все проверки — но никто в команде не понимает, как именно он устроен и почему именно так.
Разница принципиальная:
- Технический долг — код плохой, видно по метрикам, можно взять и отрефакторить. Больно, но понятно что делать.
- Долг понимания — код выглядит хорошо, тесты зелёные, но никто не знает, почему оно так работает. Трогать страшно.
Классический технический долг хотя бы честен — он торчит из кода как гвоздь из доски. Долг понимания коварнее: прячется за красивым фасадом и ждёт своего часа.
Часть вторая. Вайбкодинг: что это вообще такое
В начале 2025 года известный исследователь ИИ Андрей Карпати придумал слово vibe coding — вайбкодинг. Звучит как название инди-группы, но смысл простой: ты пишешь код «на ощущениях», без глубокого вникания. Даёшь ИИ задачу, он что-то генерирует, ты смотришь — работает? Работает. Коммитим, идём пить кофе.
Сам Карпати описывал это почти романтично: ты полностью принимаешь то, что предлагает нейросеть, не читаешь код по-настоящему, просто проверяешь результат. Как будто программируешь не мозгом, а интуицией.
«Я даже не читаю, что она пишет. Просто запускаю, вижу что работает — и двигаюсь дальше.»
Звучит заманчиво. И поначалу — действительно продуктивно. Вот только есть нюанс.
Часть третья. Три истории: когда хорошо, когда плохо, и когда совсем труба
Давайте на конкретных примерах — потому что это не теория, а вещи, которые происходят прямо сейчас в реальных проектах.
История 1 — ИИ как учитель
Нужно было написать браузерный плагин на TypeScript: загружать страницы, отправлять данные на сервер через WebSocket. TypeScript в тот момент был новым языком, но архитектура была понятна — раньше похожее делалось на Python с WebDriver.
ИИ написал систему быстро. Но дальше — важная деталь. Разработчик не просто запустил и забыл. Он потратил значительное время на изучение того, что получилось: разобрал каждый кусок, понял паттерны TypeScript, переосмыслил структуру. Превратил чужой чёрный ящик в свой проект, где каждый элемент на месте.
Итог: работающая система плюс реальное понимание лучших практик нового языка. ИИ сработал как умный учебник с живыми примерами.
История 2 — ИИ как переводчик с легаси
Старый PHP-проект с магическими переменными, смысл которых давно утерян. Поля с загадочными именами разбросаны по десяткам файлов. Новый разработчик смотрит на это и чувствует себя Шампольоном перед Розеттским камнем.
ИИ получил задание: просканировать проект, составить сводку по использованию переменных, добавить контекст. На выходе — чёткий «слепок» системы: какие поля что означают, где используются, как связаны между собой.
Итог: вместо часов ручного копания по файлам — готовая карта. После этого можно работать руками, уже понимая что к чему. ИИ не написал новый код — он помог понять старый.
История 3 — ИИ как аналитик архитектуры
Нужно разобраться в чужой большой системе и спроектировать улучшения для своего проекта. ИИ просканировал кодовую базу, дал сводку по основным принципам работы, ответил на уточняющие вопросы, добавил деталей. Получился отчёт, который можно сохранить, связать с другими отчётами — и уже самостоятельно принимать архитектурные решения.
Ключевое: ИИ дал информацию, решение принял человек. Можно было и делегировать — «сделай прототип новой системы». Но тогда это была бы уже другая история. Из следующего раздела.
История 4 — Когда пошло не так
Классическая сцена, которую сейчас можно наблюдать в любой команде, где есть хоть один разработчик с доступом к ChatGPT.
Код-ревью. Коллега прислал правки. Открываешь, смотришь — странно. Что-то изменилось там, где не должно было. Спрашиваешь: «Зачем ты это сюда добавил?»
Ответ: «Я ничего не делал. Это ИИ сформировал.»
Всё. Разговор окончен. Никто ничего не знает. Никто ни за что не отвечает. Изменения существуют, автора у них нет.
Или другой вариант: казалось бы, простая рутинная задача, доверяешь её ИИ. Он делает. Работает. Спустя две недели что-то ломается — всплывает ошибка, заложенная с самого начала. Начинаешь разбираться — и понимаешь, что ты сам не можешь быстро объяснить, что этот код делает. Потому что ты его не писал. Ты его не читал. Ты просто запустил и пошёл дальше.
Часть четвёртая. Снежный ком, который катится с горы
Одна такая история — не беда. Ошибки бывают у всех. Беда начинается, когда это становится системой.
Вот механизм, как это работает:
- Нет чёткого промпта с контекстом системы → ИИ каждый раз «угадывает» по-своему.
- Не читаешь и не осмысляешь результат → код становится мозаикой из разных стилей и решений.
- Сложность проекта растёт, понимание падает → даже простые правки требуют часа работы с ИИ.
- ИИ получает хаотичный контекст → исправляет одну ошибку и создаёт три новых.
- Проект превращается в чёрный ящик, который страшно трогать.
В какой-то момент происходит интересная вещь: ИИ начинает давать всё более плохие ответы. Не потому что он стал хуже. А потому что проект стал настолько запутанным, что когда вы даёте ему контекст — он тонет в хаосе. Он не видит системы, потому что системы больше нет — есть мозаика решений, которая держится на честном слове.
Самое обидное: внешне всё может выглядеть прилично. Тесты проходят. Продукт работает. Инвесторы довольны. Но внутри — хрупкая конструкция из плохо связанных кусков, которую страшно трогать. Это и есть самый опасный вид долга: его не видно на графиках.
Часть пятая. Хозяин поля, который жиреет
Теперь — самая важная часть. Это не просто про плохой код. Это про то, что происходит с человеком, который долго живёт в режиме «ИИ, разберись сам».
Представьте фермера. У него большое поле. Он нанял отличных работников — они всё делают лучше и быстрее него. Сначала он руководит, объясняет, проверяет результат. Потом начинает доверять больше. Потом — почти не выходит в поле. Потом — совсем не выходит. Зачем? Работники справляются.
Проходит год. Хозяин жиреет, теряет форму. Работники собирают урожай и уходят — у них нет привязанности к этому полю, они просто решают задачи. А хозяин вдруг обнаруживает: он не знает, где у него что посеяно. Он не может сам вспахать даже маленький кусок. И вместо того чтобы взять лопату и разобраться — он нанимает новых работников, ещё более мощных и дорогих.
В науке это называется cognitive atrophy — когнитивная атрофия. Или проще: мышцы атрофируются, если ими не пользоваться. Это работает и с навыками программирования.
В реальной жизни это выглядит так: разработчик смотрит на баг. Баг элементарный — он это понимает. Но код вокруг написан ИИ, и разработчик уже не уверен: а вдруг там что-то неочевидное? А вдруг если я поправлю эту строчку, упадёт что-то в другом месте? Вместо того чтобы просто починить — он кормит контекст в ChatGPT, ждёт ответа, получает правку, применяет, проверяет. Пять минут работы превращаются в двадцать. И с каждым разом — в тридцать, сорок, час.
Он потерял уверенность в собственном коде. Точнее — в чужом коде, который теперь только числится, как его.
И вот страшная правда, которую никто не любит говорить вслух: новые, более мощные модели не решают эту проблему. Они дают отсрочку. Claude 4, GPT-5, что угодно следующее — они могут разобраться в более сложном хаосе. Но хаос растёт быстрее. И чем дальше, тем больше хозяин поля зависит от всё более дорогих работников — вместо того чтобы просто выйти на своё поле и разобраться, что там происходит.
Часть шестая. Это важно не только для программистов
Если вы не программист — это тоже про вас. Просто немного по-другому.
Вы используете ИИ, чтобы писать письма? Делать презентации? Составлять договоры? Находить ответы на вопросы?
Каждый раз, когда ИИ даёт вам готовый текст, который вы используете не читая — происходит маленькое делегирование мышления. Один раз — не страшно. Сто раз — привычка. Тысяча раз — вы уже не вполне уверены, что написали бы это сами.
Здесь важно понимать разницу между двумя режимами работы с ИИ:
- Offloading (разгрузка) — ИИ берёт рутину, вы остаётесь в контексте, понимаете результат, принимаете решения. Мышцы работают.
- Outsourcing (передача мышления) — ИИ думает вместо вас, вы принимаете результат не проверяя. Мышцы атрофируются.
Первый режим — это как использовать калькулятор, когда ты умеешь считать. Второй — это как использовать калькулятор вместо того, чтобы научиться считать.
Часть седьмая. Что делать
Хорошая новость: выход есть, и он не требует выбросить ноутбук и уйти в монастырь.
Если вы разработчик:
- Делайте код своим. Не важно, кто его написал. Если вы его закоммитили — вы несёте за него ответственность. Значит, вы его прочитали, поняли, могли бы объяснить коллеге за чашкой кофе без заглядывания в ChatGPT.
- Используйте правило «объясни перед мержем». Прежде чем принять код от ИИ, заставьте себя объяснить его вслух — или хотя бы в комментарии. Если не можете — не мержите. Это занимает десять минут и избавляет от недель боли потом.
- Оставляйте ключевые решения за собой. ИИ отлично справляется с шаблонным кодом, тестами, повторяющимися паттернами — там, где работа механическая. Но архитектура и ключевая логика системы должна быть в вашей голове.
- Время от времени выходите в поле без работников. Написать что-то самостоятельно, без ИИ. Просто чтобы убедиться, что лопата ещё в руках держится.
- Давайте ИИ чёткий контекст. Не «реши задачу», а «реши задачу вот в этой архитектуре, используя вот этот паттерн, не выходя за границы вот этого модуля». Чем точнее рамки — тем предсказуемее результат.
Если вы не разработчик:
- Когда ИИ даёт вам текст, который вы собираетесь использовать — прочитайте его. Не как вычитку, а как понимание: вы согласны с каждым словом? Вы могли бы защитить каждый тезис?
- Если да — отлично, ИИ просто сэкономил вам время. Если нет — либо перепишите, либо задайте уточняющие вопросы.
- Периодически делайте что-то без ИИ — просто чтобы почувствовать разницу между «я не могу» и «мне лень».
Самые продуктивные люди с ИИ — не те, кто ему слепо доверяет. А кто его проверяет, переваривает результат.
Вместо заключения. Про смену парадигмы
Мы живём в интересное время. Буквально на наших глазах меняется то, что значит «быть профессионалом» в работе с информацией и кодом.
Раньше главный навык программиста — писать код. Теперь всё больше — понимать, оркестрировать и владеть кодом, который пишет кто-то или что-то другое.
Это не менее сложно. Просто сложность стала другой. Раньше ошибки были следствием плохого понимания системы — написал криво, сам виноват. Теперь в эту систему добавился ещё один слой: внешний исполнитель, которого нужно постоянно контролировать.
Программист из исполнителя превращается в прораба. А это совсем другая работа. Прораб должен понимать систему даже лучше рядового строителя — иначе он не поймёт, где работник схалтурил, а где сделал всё правильно. При этом у него появляются и новые возможности: работники, которые не устают, не болеют и могут одновременно класть кирпич на десяти этажах. И новая головная боль: за каждым нужно проверять, ни один не несёт ответственности за результат, и если что-то пошло не так — крайним всё равно окажется прораб.
Инструменты стали мощнее. Ответственность за то, что с ними делать — не уменьшилась. Хозяин поля может нанять сколько угодно работников. Но если он совсем забудет, как пахать — рано или поздно поле перестанет быть его собственностью.