Поводом для этой статьи стали неутихающие споры о вайбкодинге. В узком смысле так называют способ создания программ, при котором человек формулирует пожелания на естественном языке, оценивает получившийся результат и направляет модель новыми указаниями, не обязательно изучая созданный код. Этот режим следует отличать от AI-ассистированной разработки, где модель генерирует или изменяет код, но человек сохраняет контроль над архитектурой, проверкой и выпуском продукта. Ниже я рассмотрю оба режима и постараюсь выяснить, что изменилось в создании программного продукта, какие задачи можно передать вычислительной системе и какая ответственность остаётся у человека.
1. Программирование на уровне намерений
Начать следует с определения места вайбкодинга среди уже известных способов создания программ. Сделать это не так просто, поскольку вайбкодинг — не новый язык программирования в привычном смысле. У него нет формальной грамматики, однозначной семантики или собственного исполняющего устройства. Это способ взаимодействия с системой, способной превращать человеческое намерение в программный код.
Историю программирования можно представить как последовательное повышение уровня абстракции. Первые программисты непосредственно задавали машинные команды. Ассемблер заменил числовые коды символическими обозначениями. Языки высокого уровня позволили описывать алгоритмы независимо от конкретной архитектуры процессора. Предметно-ориентированные языки подняли описание ещё выше: вместо алгоритма программист получил возможность формулировать операции в терминах конкретной области — таблиц, документов, математических моделей или электронных схем.
Вайбкодинг можно рассматривать как попытку поднять интерфейс разработки на уровень намерений. Однако это не просто очередная ступень той же лестницы. Компилятор или SQL-интерпретатор работают с формальным языком, значение конструкций которого задано спецификацией. Естественно-языковое указание допускает несколько интерпретаций, а генеративная модель ещё и восполняет отсутствующие требования. Поэтому перед нами одновременно новый уровень абстракции и новый источник неопределённости.
Рисунок 1. Вайбкодинг как следующая ступень абстракции в программировании.
На верхней ступени человек уже не сообщает машине точную последовательность действий. Он может сказать: «Создай форму регистрации с подтверждением электронной почты». Такое указание выражает желаемый результат, но не определяет структуру кода, срок действия проверочного токена, правила повторной отправки письма, обработку ошибок и множество других деталей. Эти пробелы заполняет генеративная модель.
Поэтому естественный язык в вайбкодинге следует считать метаязыком постановки намерения. Фактически программист описывает цель, относительно которой машина должна построить формальную реализацию.
С точки зрения парадигм вайбкодинг ближе всего к декларативному программированию. Человек указывает, что требуется получить, а система выбирает, как именно это сделать. Однако между традиционным декларативным языком и естественно-языковым запросом существует принципиальная разница. Значение SQL-запроса определяется спецификацией, тогда как фраза «покажи активных пользователей» допускает несколько разумных толкований. Модель выбирает наиболее вероятную интерпретацию намерения автора.
Цикл разработки с использованием вайбкодинга не сильно отличается от обычной разработки: программист также последовательно пишет код, запускает его, наблюдает результат и вносит исправления. Различие заключается в том, что при традиционной разработке человек непосредственно преобразует требования в формальные конструкции, тогда как при вайбкодинге между намерением и программой появляется вероятностный посредник. Дополнительно модель самостоятельно восполняет недостающие требования, выбирает архитектурные приёмы, библиотеки, структуры данных и способы обработки ошибок.
Рисунок 2. Диалоговый цикл программирования на уровне намерений.
Вайбкодинг также нельзя назвать просто компилируемым или интерпретируемым. Он образует дополнительный слой над обычными способами исполнения. Модель сначала преобразует естественно-языковое описание в исходный код, после чего этот код проходит привычный путь: Rust компилируется в машинные инструкции, Java — в байт-код виртуальной машины, Python выполняется интерпретатором, а JavaScript может быть обработан JIT-компилятором. Вайбкодинг в целом представляет собой генеративно-транслируемый способ разработки.
Не менее важна проблема типизации. Естественно-языковое указание почти всегда неполно. Фраза «добавь пользователя к заказу» не сообщает, передаётся ли объект или идентификатор, может ли пользователь отсутствовать, требуется ли проверка прав и что должно произойти при конфликте данных. На уровне намерения эти условия остаются неявными. Модель вынуждена вывести их из контекста или предположить самостоятельно.
После генерации начинают действовать ограничения целевого языка. Компилятор Rust способен обнаружить многие противоречия типов и владения; в Python часть аналогичных ошибок проявится только при исполнении или тестировании. Таким образом, система существует сразу на двух уровнях: неформальном, практически нетипизированном уровне человеческого намерения — и формальном уровне реализации.
Дополнительно необходимо различать два независимых измерения: автономность вычислительной системы и степень человеческого контроля над результатом.
Средство автодополнения обладает небольшой автономностью: оно предлагает отдельные фрагменты, а человек определяет архитектуру и непосредственно принимает каждое изменение. Программный агент может действовать гораздо самостоятельнее — изучать проект, редактировать несколько файлов, запускать проверки и исправлять ошибки. Однако высокая автономность ещё не означает отсутствия контроля: человек может заранее задать ограничения, проверить план, изучить изменения и разрешить выпуск только после независимых испытаний.
Вайбкодинг характеризуется не столько автономностью инструмента, сколько отношением человека к реализации. В строгом варианте человек оценивает главным образом наблюдаемое поведение программы и направляет дальнейшие изменения, не стремясь понять созданный код. Поэтому вайбкодинг и агентную программную инженерию нельзя располагать на одной линейной шкале.
Полезнее различать несколько режимов:
ИИ-дополнение: система предлагает локальные фрагменты кода;
ИИ-ассистированная разработка: система создаёт изменения, а человек сохраняет контроль над архитектурой и проверкой;
агентная программная инженерия: система самостоятельно выполняет многошаговую задачу внутри заданных полномочий;
вайбкодинг: человек управляет результатом преимущественно через естественный язык и наблюдаемое поведение, не обязательно изучая реализацию.
Эти режимы могут пересекаться. Агентная работа бывает строго контролируемой, а вайбкодинг — как ручным диалогом с моделью, так и почти автономным. Предметом спора поэтому является не само количество сгенерированного кода, а то, какие решения, проверки и знания человек передаёт системе.
Именно этот перенос контроля делает вайбкодинг предметом принципиального спора. Повышает ли естественный язык уровень программирования или заменяет точность догадкой? Освобождает ли машина человека от механической работы или от понимания собственной системы? Можно ли считать программу инженерно созданной, если её автор формулировал намерения, но не изучал реализацию?
Чтобы ответить на эти вопросы, рассмотрим вайбкодинг как новую границу между намерением, формальной программой и ответственностью за её поведение. Начнём с вопроса: «Может ли машина программировать?»
2. Игра в программирование
Вопрос «Может ли машина программировать?» напоминает поставленный Аланом Тьюрингом вопрос «Могут ли машины мыслить?». В статье 1950 года Тьюринг не пытался дать исчерпывающее определение мышления, а предложил операциональное испытание — игру, в которой о возможностях системы судят по наблюдаемому взаимодействию.
Эту идею можно осторожно перенести на программирование. Представим два процесса разработки. В первом задачу выполняет разработчик без генеративного ИИ. Во втором разработчик формулирует требования программному агенту, проверяет его действия и уточняет ограничения. Независимая группа оценивает полученные продукты: проверяет соответствие требованиям, безопасность, сопровождаемость, производительность, происхождение зависимостей и поведение при отказах.
Рисунок 3. Мысленный эксперимент: можно ли определить способ создания программы только по результату?
Если группа не может надёжно определить, какой процесс создал каждый продукт, это показывает, что в данной задаче оба процесса дали сопоставимый результат. Но такой эксперимент ещё не доказывает, что машина понимает программу, самостоятельно определила её цели или несёт ответственность за последствия. Во втором случае продукт создаёт социотехническая система: человек, модель, инструменты, документация и процедуры проверки.
Поэтому наблюдаемая равноценность результата отвечает только на ограниченный вопрос: способна ли связка человека и вычислительной системы при данных условиях получить продукт заданного качества? Для инженерии этого может быть достаточно, но для разговора об авторстве, понимании и ответственности потребуются дополнительные критерии.
Так исходный вопрос распадается на несколько более точных:
какие части разработки система способна выполнять без постоянного вмешательства;
какие свойства результата можно проверить независимо от способа его создания;
какой объём понимания необходим человеку, принимающему результат;
кто отвечает за выбор требований, выпуск и последствия ошибки;
при какой цене ошибки делегирование перестаёт быть разумным.
Рассмотрим основные возражения против вайбкодинга и агентной разработки именно с этих позиций: как проверку того, при каких условиях созданной с её участием программе можно доверять.
3. Возражение о почти правильном ответе
Говорят, что сгенерированный машиной код часто бывает почти правильным. Он выглядит убедительно, компилируется и даже проходит несколько испытаний, но ошибается в редком случае или неверно понимает правило предметной области. Очевидная ошибка легко обнаруживается; правдоподобная ошибка опаснее.
Рисунок 4. Видимая корректность программы может скрывать неоднозначные требования, редкие случаи и технический долг.
Это возражение справедливо: сгенерированный код может выглядеть убедительно и проходить первые проверки, оставаясь при этом ошибочным. Именно поэтому многие разработчики относятся к нему с недоверием. Однако необходимость проверки не делает такой код бесполезным — она лишь не позволяет принимать его без критической оценки. Необходимо использовать соответствующие методы проверки.
4. Возражение о потерянном времени
Следующее возражение состоит в том, что система создаёт код быстро, но человек затем долго читает, исправляет и переделывает результат. Первоначальное ускорение генерации поэтому не обязательно означает рост производительности.
Сгенерированный исходный код нельзя полностью уподоблять байт-коду или результату работы обычного компилятора. Компилятор выполняет преобразование, определённое формальными правилами языка. Генеративная модель интерпретирует неполное требование вероятностно, а созданный ею исходный текст становится сопровождаемой частью проекта. Поэтому проверка необходима, хотя её глубина должна зависеть от риска. Одноразовый скрипт, внутренний прототип и механизм авторизации требуют разного уровня доказательности.
Эмпирические исследования не дают единого ответа о влиянии ИИ на производительность. В эксперименте METR с инструментами начала 2025 года 16 опытных разработчиков выполняли 246 реальных задач в хорошо знакомых им открытых проектах. С ИИ они в среднем затратили на 19% больше времени, хотя до работы ожидали ускорения и после неё продолжали считать, что работали быстрее.
Этот результат описывает важный, но узкий случай. В феврале 2026 года METR сообщила, что новые данные указывают на возможное ускорение, однако признала их недостаточно надёжными: разработчики, сильнее всего заинтересованные в ИИ, чаще отказывались участвовать в условии без ИИ, а задачи с предполагаемой большой выгодой от автоматизации реже попадали в эксперимент.
Другие исследования получили противоположные результаты. Три полевых эксперимента в Microsoft, Accenture и компании из списка Fortune 100, охватившие 4 867 разработчиков, показали рост числа выполненных задач при доступе к средству ИИ-дополнения кода. Однако и этот результат нельзя автоматически переносить на автономных агентов, незнакомые проекты или критические системы: различались инструменты, задачи, участники и сами показатели производительности.
Следовательно, вопрос «ускоряет ли ИИ программирование?» слишком широк. Для конкретного проекта необходимо учитывать:
время на постановку задачи и передачу контекста;
время ожидания и управления агентом;
затраты на проверку и исправление результата;
качество и объём созданного изменения;
влияние на ревьюеров и дальнейшее сопровождение;
частоту повторной работы после обнаружения скрытых ошибок;
возможность параллельно выполнять другие задачи.
Производительность следует измерять не скоростью появления кода и не числом закрытых задач, а полными затратами на получение работающего, проверенного и сопровождаемого результата. ИИ может как сократить, так и увеличить эти затраты; направление эффекта определяется задачей, инструментом, опытом разработчика и качеством процесса.
5. Возражение об отсутствии понимания
Говорят, что вайбкодер не понимает собственной программы. Когда система ломается, он не способен объяснить её поведение.
Это, вероятно, самое сильное возражение. Однако оно направлено не против машинного программирования, а против отсутствия инженерной модели.
Ни один современный разработчик не понимает свою систему во всей полноте. Он не знает каждого участка операционной системы, компилятора, процессора, сетевого оборудования и библиотек, от которых зависит программа. Работа становится возможной благодаря слоям абстракции и ограниченным договорам между ними.
Поэтому требование «понимать каждую строку» заведомо невыполнимо. Более полезно другое требование: человек должен понимать те свойства системы, за которые он отвечает. Он должен знать её границы, данные, инварианты, режимы отказа, требования безопасности и способы наблюдения за поведением.
Машина может даже содействовать такому пониманию. Ей можно поручить построить карту зависимостей, объяснить поток данных, перечислить предположения, предложить контрпримеры и указать участки, затрагиваемые изменением. Но это происходит лишь тогда, когда человек спрашивает не только «сделай», но также «объясни», «докажи» и «что может нарушить это решение?».
Следовательно, разумный критерий состоит не в том, писал ли человек код вручную, а в том, способен ли он предсказывать существенное поведение системы и организовать её проверку.
6. Возражение о техническом долге
Машина оптимизирует ближайший запрос. Она охотно добавляет ещё одну функцию, зависимость или специальный случай, не заботясь о единстве системы. В результате возникают дублирование, несовместимые шаблоны и разрастание кода.
Это наблюдение также верно. Машины подчиняются той цели, которая фактически поставлена перед ними. Если единственным признаком успеха служит появление требуемой кнопки, машина будет стремиться создать кнопку, а не сохранить архитектурную целостность через три года.
Но подобным образом ведёт себя и организация, оценивающая людей только по числу выпущенных функций. Технический долг часто является не свойством инструмента, а следствием короткого горизонта управления.
Чтобы изменить результат, требуется изменить задачу. До генерации следует зафиксировать архитектурные ограничения. После неё — измерить сложность, дублирование, размер изменений и соответствие установленным шаблонам. Машине можно поручить сначала найти существующее решение, а не создавать новое; предложить минимальное изменение; объяснить, почему добавленная абстракция необходима; удалить лишний код после завершения функции.
Парадоксально, но машина способна не только производить технический долг, но и погашать его. Она может выполнять механические миграции, унифицировать повторяющиеся конструкции, добавлять типы и тесты к старому коду. Подобная работа часто откладывалась именно потому, что была слишком однообразной и дорогой для человека.
Машина увеличивает скорость как накопления, так и погашения долга. Направление определяет не её «характер», а система стимулов и проверок.
7. Возражение о безопасности
Говорят, что сгенерированная программа может работать и всё же оставаться небезопасной. Она забудет проверить полномочия, допустит инъекцию, оставит секрет в журнале или сделает служебный интерфейс публичным.
Нельзя ответить, что машина непременно будет писать безопасный код. Это было бы неправдой. Но столь же ошибочно предполагать, что код, написанный человеком, безопасен по своему происхождению.
Безопасность не возникает из авторства. Она возникает из процесса: модели угроз, ограничений доступа, анализа зависимостей, сканирования, независимого ревью и испытаний.
Машинный агент следует считать потенциально опасным исполнителем с ограниченными полномочиями. Ему не следует без необходимости предоставлять производственные ключи, неограниченную сеть или возможность самовольно развёртывать изменения. Его надлежит помещать в изолированную среду и выдавать минимальные права — так же, как мы поступаем с любым компонентом, которому не можем полностью доверять.
Рисунок 5. Агент с минимальными полномочиями: внешние данные и действия доступны только через проверяемые шлюзы.
Особенно важно, чтобы машина не являлась единственным судьёй собственной работы. Если один и тот же агент написал механизм авторизации и тесты, подтверждающие его правильность, мы получили не независимое свидетельство, а самосогласованный рассказ. Критические свойства должны проверяться иным средством или человеком.
Следовательно, AI-код не отменяет инженерную безопасность. Он делает более заметным тот факт, что безопасным должен быть процесс, а не репутация автора.
8. Возражение о выдуманных зависимостях
Машина может назвать библиотеку, которой не существует, использовать устаревший интерфейс или предложить пакет сомнительного происхождения. Такая ошибка способна превратиться в уязвимость цепочки поставок.
Ответ здесь сравнительно прост: предложение зависимости не должно означать разрешение на её установку.
Каждая новая зависимость должна пройти проверку происхождения, лицензии, версии, сопровождаемости и известных уязвимостей. Желательно ограничивать агента утверждённым набором пакетов и требовать обоснования всякого расширения этого набора.
Заметим, что машина способна выдумать имя пакета, но только система автоматического исполнения превращает эту фантазию в установленный код. Между высказыванием и действием должен существовать проверяемый шлюз.
Было бы странно отказаться от электронной почты, потому что письмо может содержать вредную ссылку. Мы предпочитаем фильтры, изоляцию и осторожность. Тот же принцип применим здесь.
9. Возражение о ложных тестах
Говорят, что машина может ошибиться в реализации, а затем написать тест, закрепляющий ту же ошибку. Все индикаторы станут зелёными, хотя требование останется невыполненным.
Это возражение показывает различие между проверкой программы относительно самой себя и проверкой относительно мира.
Тест, построенный из тех же предположений, что и реализация, не является полностью независимым. Поэтому спецификацию полезно создавать отдельно от кода. Приёмочные примеры должны исходить из требований, поведения прежней системы, реальных инцидентов или независимой модели.
Можно предложить нескольким средствам искать контрпримеры, использовать генеративное тестирование и проверять инварианты, а не только заранее ожидаемые ответы. Человеку же следует сосредоточиться на выборе свойств, которые действительно имеют значение.
Таким образом, машина не уменьшает значение тестирования. Она заставляет нас яснее ответить на вопрос, что именно доказывает каждый тест.
10. Возражение об архитектуре
Машина видит локальную задачу, но не постигает целой системы. Она не учитывает долгосрочное развитие, организационные ограничения, стоимость эксплуатации и неявные договорённости между командами.
Верно, что большая архитектура не содержится в одном запросе. Но она не содержится и в голове одного программиста. Архитектура существует в решениях, документах, интерфейсах, правилах и коллективной практике.
Если эти знания нигде не выражены, машина будет действовать плохо. Однако новый разработчик в той же организации столкнётся с похожей трудностью. Разница лишь в скорости, с которой машина способна породить неверные предположения.
Отсюда следует практический вывод: значимые ограничения должны быть сделаны явными и доступными для автоматической проверки. Границы модулей, правила работы с данными, ограничения зависимостей и требования наблюдаемости не должны оставаться исключительно устным преданием старших инженеров.
В этом смысле применение машин может улучшить организацию программирования. Оно обнаруживает те места, где проект держался не на документации и проверяемых правилах, а на памяти нескольких людей.
Архитектор не исчезает. Его деятельность смещается от ручного производства каждого фрагмента к формулированию пространства, внутри которого допустимо производство фрагментов.
11. Возражение о перегруженном ревью
Один разработчик с машиной способен произвести больше изменений, чем его коллеги успевают проверить. Генерация ускоряется, а человеческое внимание остаётся ограниченным. В результате ревью становится узким местом.
Это не случайный недостаток, а важное указание на неверно выбранную единицу производительности.
Если организация вознаграждает объём созданного кода, машины неизбежно завалят её кодом. Следует ограничивать размер изменений, требовать объяснения намерения, выделять рискованные участки и автоматически отклонять правки, не соответствующие проверяемым правилам.
Лучший машинный вклад может состоять не в создании большего числа строк, а в создании меньшего и более ясного изменения. Машине можно поручить подготовить краткое описание, карту рисков, доказательство прохождения проверок и варианты отката.
Программный код не является продуктом сам по себе. Непроверенный код подобен деталям, сложенным перед заводскими воротами. Производительность определяется не числом деталей, а количеством работающих изделий.
12. Возражение об утрате навыков
Наконец, говорят, что начинающий разработчик, передающий машине написание и исправление программ, не учится программировать. Эксперимент Anthropic действительно показал снижение освоения новой библиотеки у участников, использовавших AI-помощь; особенно пострадали навыки отладки.
Это серьёзное предупреждение. Однако из него не следует, что помощь всегда препятствует обучению. Значение имеет способ взаимодействия.
Ученик, который просит готовый ответ и немедленно вставляет его, переносит мышление наружу. Ученик, который сначала строит предположение, затем просит критику, объяснение и альтернативы, может получить чрезвычайно терпеливого наставника.
Образование должно намеренно разделять режим выполнения и режим обучения. Иногда студент обязан решить задачу без машины, чтобы сформировать внутреннюю модель. Иногда машина может задавать вопросы, давать подсказки, генерировать упражнения или разбирать ошибку, не сообщая полного решения.
Человеческий навык остаётся необходимым по той самой причине, по которой машины полезны: их ответы требуют постановки задачи и надзора. Общество, утратившее способность проверять машины, будет зависеть от систем, которым оно не способно возразить.
Но общество, запрещающее новые средства ради сохранения старых упражнений, рискует обучать людей работе, которая уже перестала быть центральной. Правильная цель состоит не в сохранении количества ручного набора кода, а в сохранении способности понимать, проверять и создавать вычислительные системы.
13. Возражение о собственности и конфиденциальности
Остаются вопросы конфиденциальности, лицензий и происхождения кода. Машине может быть передан закрытый исходный текст, секрет или персональная информация. Её ответ может совпадать с публичным произведением, имеющим лицензионные условия.
Эти вопросы относятся не к разуму машины, а к правам и границам системы, в которой она действует.
Организация обязана знать, какие данные покидают её среду, как они хранятся и используются ли для дальнейшего обучения. Секретные каталоги должны исключаться из контекста, ключи — храниться отдельно, а совпадения с публичным кодом — проверяться средствами атрибуции и лицензионного анализа.
Нельзя считать, что удобство интерфейса отменяет правовые обязанности. Но наличие таких обязанностей не делает использование машины невозможным. Банки применяют внешние вычислительные системы, не публикуя счета клиентов; больницы используют программное обеспечение, не отказываясь от медицинской тайны. Они делают это посредством договоров, технических ограничений и аудита.
14. Обучающиеся машины
Вместо вопроса «заменит ли машина программиста?» полезнее задать другой: «Какой вид программиста возникает рядом с машиной?»
Можно представить разработчика, который производит меньше исходного текста, но формулирует больше проверяемых требований. Он тратит меньше времени на синтаксис и больше — на модели данных, границы системы и последствия ошибок. Он не обязан помнить каждое имя функции, но обязан отличать доказательство от правдоподобия.
Как было показано в начале статьи, подобное изменение уже происходило при каждом повышении уровня абстракции. Программисты перестали вручную назначать адреса машинных команд и передали компиляторам многие задачи, включая оптимизацию. Каждый такой переход вызывал опасение, что новая абстракция уничтожит понимание. Иногда она действительно скрывала важные детали, но одновременно позволяла создавать системы, недоступные прежнему масштабу человеческого труда.
Не всякий подъём уровня абстракции является прогрессом. Абстракция полезна только тогда, когда её границы определены, а нарушения обнаружимы.
Поэтому будущее машинного программирования зависит не только от качества моделей. Оно зависит от качества окружающих их процедур: спецификаций, тестов, изоляции, наблюдаемости, ревью и образования.
15. Заключение
Мы поставили вопрос: «Может ли машина программировать?»
Теперь можно увидеть, что этот вопрос был выбран неудачно. Машина уже способна производить программы, исправлять их и участвовать в разработке. Более существенный вопрос состоит в том, при каких условиях результат заслуживает доверия.
Возражения против вайбкодинга показывают, что без проверки машина способна быстрее создавать ошибки, технический долг и ложную уверенность. Но они не доказывают, что машинное программирование бесполезно. Они определяют требования к его зрелой форме.
Назовём систему разумно созданной не тогда, когда каждая строка прошла через человеческие пальцы, а тогда, когда:
её свойства сформулированы;
существенные риски проверены;
происхождение компонентов известно;
изменения ограничены и обратимы;
ответственный человек понимает границы решения;
существует возможность обнаружить и исправить ошибку.
Если программа удовлетворяет этим условиям, спор о том, кто именно набрал её текст, становится церемониальным.
Если же условия не выполнены, человеческое авторство само по себе её не спасёт.
Машина не освобождает человека от мышления. Она освобождает его лишь от некоторых движений, которые прежде сопровождали мышление. Воспользуется ли человек этой свободой, чтобы мыслить лучше, или чтобы не мыслить вовсе, — это уже не вопрос вычислительных машин.
Оригинал: тут
