От вайб-кодинга к инженерии с агентами

По мотивам беседы Андрея Карпати о том, почему ИИ в программировании уже нельзя считать просто подсказкой.

Скачок, который многие пропустили

Карпати говорит, что в какой-то момент почувствовал себя отставшим как программист. Не потому, что забыл, как писать код. Просто инструменты за короткое время перешли границу: раньше они выдавали куски, которые приходилось чинить, а затем начали собирать всё более цельные решения.

Для него перелом пришёл примерно в декабре: он всё чаще просил модель сделать больше, всё реже правил результат и постепенно начал доверять агенту длинные цепочки работы. Это и стало тем, что он назвал вайб-кодингом: не строгий ручной набор строк, а управление направлением, пока модель тащит основную механическую часть.

Языковая модель как новый компьютер

Карпати описывает это как переход к «программам 3.0». В «программах 1.0» человек пишет явные правила. В «программах 2.0» он готовит данные, на которых учится нейросеть. В новой схеме главным рычагом становится контекст: документы, изображения, требования, ограничения и запрос к модели.

То есть модель начинает работать как исполнитель, который читает контекст и действует в цифровой среде. Хороший пример: вместо огромного установочного сценария можно дать агенту понятную инструкцию, а он сам посмотрит на окружение, выполнит шаги и исправит ошибки по пути. Это уже не просто ускорение старого способа работы. Это другой способ отдавать работу компьютеру.

Новые задачи, а не только быстрый старый код

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

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

То же касается личных и рабочих баз знаний. Раньше код хорошо работал с таблицами и строго заданными структурами. Теперь можно взять набор документов и попросить модель пересобрать их в вики, связать темы, вытащить вопросы и показать материал под другим углом. Это уже не «код быстрее». Это обработка смысла.

Почему ИИ силён рывками

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

Отсюда практический вывод: чем лучше вы можете проверить результат, тем безопаснее отдавать задачу агенту. Если есть тесты, критерии, проверяющие скрипты, симуляции или понятные правила качества, агент становится намного полезнее. Если область плохо проверяется, человек должен держать руку на руле.

Это также совет основателям: ищите области, где результат ценен и проверяем. Там можно строить свои среды проверки, дообучать модели и получать преимущество даже без прямого участия крупных лабораторий.

Вайб-кодинг и инженерия с агентами

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

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

Роль инженера сдвигается. Меньше нужно помнить, где в библиотеке axis, а где dim. Больше нужно понимать данные, архитектуру, безопасность, ограничения и то, что вообще стоит строить. Агент заполняет пробелы, но вкус, замысел и проверка остаются у человека.

Что менять в командах

Нанимать нужно иначе. Маленькие задачки у доски хуже показывают реальный уровень. Лучше дать большой проект, разрешить пользоваться агентами, а затем проверить качество, безопасность и способность довести продукт до рабочего состояния.
Документацию нужно писать не только для людей. Хорошая инструкция теперь отвечает на вопрос: «Что дать агенту, чтобы он сделал работу?»
Инфраструктура должна стать удобной для агентов. Настройка доменов, платежей, развёртывания и прав доступа всё ещё слишком часто рассчитана на человека, который кликает по меню.
Процесс разработки должен включать подробное задание, тесты, автоматические проверки, попытки взлома и человеческую проверку ключевых решений.

Понимание нельзя передать агенту

Можно передать агенту часть мышления, но нельзя передать ему понимание.

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

Будущее не за теми, кто просто «пишет руками», и не за теми, кто бездумно принимает всё, что выдал ИИ. Сильнее окажутся инженеры, которые умеют ставить задачу, давать агентам правильный контекст, проверять результат и не снижать планку качества.

Сообщество энтузиастов - https://t.me/openclaw_lab