Как вайбкодинг доводит до депрессии, как потом лечиться

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

Причём самое обидное, что для этого AI-агенту даже не нужно писать плохой код. Наоборот, чем лучше он справляется, тем интереснее становится проблема.

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

Теперь вы открываете редактор, объясняете агенту, что нужно сделать, и получаете готовую реализацию.

Если всё прошло хорошо, остаётся посмотреть diff, запустить тесты, оценить результат и принять изменения.

Прекрасно. Производительность выросла, рутинной работы стало меньше. Только куда-то исчез довольно существенный кусок самого программирования.

И вот у меня вопрос: а если человеку нравился именно этот процесс?

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

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

А ведь программисту, вообще-то, должно нравиться программировать.

Самое неприятное, что вайб-кодинг мне очень нравится

Мне кажется, у выражения vibe coding совершенно незаслуженно сложилась несколько отрицательная репутация.

Обычно это представляется как история про человека, который купил подписку на Codex, написал «сделай мне новый Facebook» и теперь считает себя разработчиком.

Но вдумайтесь, насколько прекрасна сама идея.

У человека есть некоторое представление о желаемом результате. Некоторый вайб, настроение, ощущение того, как должна работать система.

И он передаёт это ощущение искусственному интеллекту, который превращает его в программный код.

Да это же фантастика какая-то!

Ещё недавно для реализации какой-нибудь идеи нужно было самостоятельно пройти довольно длинный путь от её концепции до работающей программы. Теперь значительная часть этого пути может быть автоматизирована.

И это, по-моему, невероятно круто.

Конечно, если мы говорим о настоящем программном продукте, одного настроения недостаточно. Нужно понимать архитектуру, ограничения, безопасность, тестирование, масштабирование. Да и проверять агента всё равно приходится.

Но именно поэтому меня интересует происходящее.

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

Можно, конечно, принципиально отказаться от агентов и продолжать писать всё самостоятельно.

Но это какое-то довольно странное решение. Примерно как отказаться от компилятора ради удовольствия вручную переводить программу в машинные инструкции.

Мне совершенно не хочется отказываться от технологического прогресса ради сохранения привычного рабочего процесса.

Поэтому, кажется, придётся искать удовольствие в другом месте.

Мы теряем привычный интерфейс взаимодействия с компьютером

Если посмотреть на историю языков программирования, можно заметить довольно интересную закономерность.

Мы постоянно совершенствовали способы, которыми человек описывает компьютеру желаемое поведение.

Машинные инструкции, ассемблер, языки высокого уровня, объектно-ориентированное программирование, функциональные абстракции, декларативные интерфейсы.

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

И, на мой взгляд, именно языки программирования стали одним из самых удивительных интерфейсов, которые человечество вообще придумало.

Ведь что такое программа?

Это некоторое описание поведения системы, которое компьютер способен исполнить.

А язык программирования позволяет человеку взаимодействовать с этим поведением на понятном ему уровне абстракции.

Можно изменить одну функцию, переопределить метод, перестроить взаимодействие объектов. Иногда достаточно нескольких строк, чтобы существенно изменить поведение всей системы.

Мне кажется, это невероятно красиво.

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

И здесь возникает интересная мысль.

Мы ведь разрабатывали привычные языки программирования для людей. Чтобы людям было удобно читать, писать, анализировать и изменять программы.

А обязательно ли подобное представление окажется оптимальным для AI-агентов?

Возможно, со временем они начнут работать с каким-нибудь специализированным промежуточным представлением. С графами вычислений, формальными контрактами, чем-то похожим на AST или совершенно другими структурами.

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

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

Я не знаю.

Но мне кажется, что синтаксис конкретного языка постепенно перестаёт быть настолько дорогим знанием, каким он был раньше.

При этом понимание computer science никуда не исчезает.

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

И вот что меня особенно заинтересовало.

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

Мне кажется, программисту нужно вернуть удовольствие

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

Счастье разработчика довольно тесно связано с тем, как именно он взаимодействует с системой.

Ведь удовольствие от программирования заключается далеко не исключительно в наборе символов на клавиатуре.

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

Когда несколько объектов взаимодействуют настолько естественно, что практически не приходится задумываться об их устройстве.

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

И даже если этот код изначально написал AI-агент, мне всё равно хочется его прочитать.

Понять, как он устроен. Возможно, что-нибудь изменить.

Взаимодействие с программой никуда не исчезает после того, как мы перестаём самостоятельно писать каждую строчку.

Оно просто становится другим.

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

Причём я сейчас говорю об удовольствии в самом буквальном смысле.

Насколько красиво выглядит программа? Насколько приятно её читать? Насколько выразительно можно описать взаимодействие компонентов? Хочется ли вообще открывать этот код?

И вот здесь я совершенно неожиданно для себя обнаружил Ruby.

Ruby. Почему я вообще не попробовал его раньше?

С Ruby я познакомился сравнительно недавно.

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

Я понимаю, что у Ruby есть свои недостатки. Производительность, динамическая типизация, особенности метапрограммирования, сложность статического анализа в отдельных случаях.

Но меня привлекает то, насколько выразительно на нём можно описывать систему.

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

Давайте представим небольшую задачу.

У нас есть приложение, которое обрабатывает пользовательские запросы при помощи нескольких AI-агентов.

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

Нам нужно описать маршрутизацию.

И мне хотелось бы, чтобы такая система выглядела примерно следующим образом:

router = AgentRouter.define do
  on :question, to: :researcher do |request|
    request[:source] == :documents
  end

  on :payment, to: :human do |request|
    !request[:verified]
  end

  on :payment, to: :billing

  otherwise :assistant
end

Просто посмотрите на этот код.

Я понимаю, что красота субъективна, но мне кажется, это фантастически приятный способ описания программы.

У нас есть правила маршрутизации. Мы последовательно проверяем условия, выбираем подходящего исполнителя, а если ничего не подошло, используем агента по умолчанию.

И всё.

Даже человек, который впервые видит Ruby, скорее всего, довольно быстро поймёт, что происходит.

При этом здесь совершенно не требуется специально придумывать новый язык конфигурации.

Это обычный Ruby.

AgentRouter в примере является небольшой учебной абстракцией. Я сейчас покажу её реализацию, потому что именно там, на мой взгляд, начинается настоящее удовольствие.

Немного прекрасного метапрограммирования

В Ruby есть замечательная возможность использовать блоки и менять контекст, в котором они исполняются.

Благодаря этому можно создавать небольшие предметно-ориентированные языки прямо внутри обычной программы.

Например, наш маршрутизатор можно реализовать следующим образом:

class AgentRouter
  Rule = Data.define(:intent, :destination, :condition)

  def self.define(&configuration)
    new.tap { |router| router.instance_eval(&configuration) }
  end

  def initialize
    @rules = []
  end

  def on(intent, to:, &condition)
    @rules << Rule.new(intent, to, condition)
  end

  def otherwise(destination)
    @fallback = destination
  end

  def resolve(request)
    rule = @rules.find do |candidate|
      candidate.intent == request.fetch(:intent) &&
        (candidate.condition.nil? || candidate.condition.call(request))
    end

    rule&.destination || @fallback
  end
end

Вот и вся основа.

Это рабочий пример для Ruby 3.2+, без дополнительных зависимостей.

Что мне здесь нравится?

Во-первых, Data.define. Мы буквально одной строчкой создаём класс для представления правила маршрутизации.

Во-вторых, блоки. Условие маршрутизации остаётся обычным фрагментом Ruby-кода. Мы можем передать его как объект, сохранить и выполнить позднее.

И, наконец, instance_eval.

Этот метод выполняет блок в контексте конкретного объекта. Поэтому внутри AgentRouter.define мы можем вызывать on и otherwise напрямую, как будто это какие-то специальные конструкции языка.

В результате получается собственный небольшой DSL.

При этом сохраняются все обычные возможности Ruby: методы, переменные, замыкания, объекты, композиция.

Нам не пришлось писать парсер для отдельного конфигурационного формата, реализовывать собственную грамматику условий или интерпретировать выражения из JSON.

А ведь это именно то, что мы зачастую пытаемся сделать при разработке различных декларативных конфигураций.

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

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

И это одна из тех особенностей Ruby, из-за которых мне хочется продолжать с ним экспериментировать.

А ведь всё это ещё и можно нормально проверять

Естественно, красивый DSL не делает приложение автоматически правильным.

Например, у нас есть правило:

on :payment, to: :human do |request|  
  !request[:verified]
end

Откуда вообще берётся verified?

Если значение этого поля определяет сама языковая модель на основании пользовательского сообщения, у нас могут появиться весьма неприятные проблемы.

Для реального приложения его должна предоставлять доверенная часть системы, которая занимается аутентификацией и авторизацией.

И здесь как раз появляется нормальная инженерная работа.

Мы можем описать политику маршрутизации в одном месте, покрыть её тестами и проверять независимо от работы LLM.

Например:

assert_equal :researcher, router.resolve({
  intent: :question,
  source: :documents
})

assert_equal :human, router.resolve({
  intent: :payment,
  verified: false
})

assert_equal :billing, router.resolve({
  intent: :payment,
  verified: true
})

Эти проверки можно выполнять без API-ключей и обращений к языковой модели.

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

Но мне нравится, насколько естественно можно представить устройство системы.

И вот представьте, что значительную часть реализации этого приложения написал AI-агент.

Мне всё равно интересно открыть такой файл.

Посмотреть, как описаны маршруты, какие инструменты доступны агентам, какие условия действуют для определённых операций.

Возможно, изменить какое-нибудь правило прямо руками.

Именно такое взаимодействие с программой мне кажется невероятно приятным.

А почему тогда все любят Rust?

И вот тут у меня возникает ещё один вопрос.

Почему, когда разработчиков спрашивают о любимых языках программирования, мы постоянно видим Rust среди лидеров?

Например, в Stack Overflow Developer Survey 2026 показатель admired у Rust составляет 67,4%, а у Ruby 42,4%.

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

Но всё равно любопытно.

Rust прекрасен по совершенно другим причинам. Он позволяет контролировать память, добиваться высокой производительности, получать довольно серьёзные гарантии на этапе компиляции.

Но он и ужасен по совершенно другим причинам. Как мне кажется, он удовлетворяет абсолютно странную когорту разработчиков (приносит удовольствие), плюс у него достаточно узкий пул задач, где он реально слабо заменим.

Я прекрасно понимаю удовольствие человека, который разрабатывает сложную систему и получает от компилятора подтверждение, что целый класс ошибок в ней исключён. Но не понимаю человека, который просто разрабатывает и получает по рукам от компилятора за попытку подышать.

Там есть собственная эстетика и уродство.

Но если мы говорим об удовольствии от взаимодействия с кодом, почему Ruby настолько редко оказывается в центре подобных разговоров?

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

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

И Ruby-разработчики наверняка могут рассказать множество историй о том, как очередная красивая магия превращала отладку в настоящее приключение.

Я это понимаю.

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

Ведь это одна из известных идей Юкихиро Мацумото, создателя Ruby.

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

Особенно в веб-разработке.

Возможно, скорость разработки теперь важнее скорости исполнения ещё чаще

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

И для ряда сценариев это совершенно справедливо.

Но давайте представим обычное веб-приложение, которое взаимодействует с базой данных, внешними API и несколькими LLM-провайдерами.

Значительную часть времени такое приложение может проводить в ожидании внешних операций.

Конечно, производительность языка всё равно влияет на потребление ресурсов, пропускную способность и некоторые участки обработки запросов. Было бы странно полностью игнорировать эти факторы.

Но мне кажется, что для довольно большого класса прикладных задач производительность разработчика имеет гораздо большее значение, чем разница в скорости исполнения отдельно взятого метода.

Особенно если большую часть самого кода теперь пишет AI-агент.

Ведь программисту всё равно приходится понимать, как устроена система. Смотреть результаты работы агента, оценивать архитектуру, изменять поведение.

И если один язык позволяет делать это с большим удовольствием, почему мы должны считать подобное преимущество второстепенным?

По-моему, это вполне серьёзный инженерный аргумент.

В конце концов, время разработчика тоже стоит денег. А способность получать удовольствие от работы, мне кажется, вообще несколько недооценена.

И как всё-таки лечиться от вайб-кодинга?

Возможно, я пытаюсь решить проблему, которой вообще не существует.

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

И мне, в общем, понятна такая позиция.

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

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

Открыть редактор, придумать красивую абстракцию, поэкспериментировать с языком, заставить несколько компонентов взаимодействовать интересным образом.

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

С одной стороны, прекрасно.

С другой стороны, а что тогда делать с желанием программировать?

Мне кажется, ответ может быть довольно простым.

Искать те способы взаимодействия с системой, которые продолжают доставлять удовольствие.

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

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

Причём выбирать его теперь можно с довольно необычной позиции.

Насколько приятно на нём писать? Насколько красиво выглядят программы? Насколько выразительно можно описать систему? Насколько сильно вообще хочется взаимодействовать с таким кодом?

Мне кажется, что у языков вроде Ruby здесь появляется интересный шанс.

Ведь AI-агенту совершенно необязательно получать удовольствие от того, насколько красиво написан код.

А человеку, по-моему, всё ещё желательно.

И вот что мне действительно интересно.

Вы вообще замечаете, что с появлением AI-агентов удовольствие от программирования как-то изменилось? Стало интереснее, потому что теперь можно заниматься архитектурой и сложными задачами? Или, наоборот, начало не хватать самого процесса написания кода?

И отдельно мне очень хочется понять историю с языками.

Почему Rust вызывает столько любви у разработчиков, а Ruby с его идеей счастья программиста остаётся заметно менее популярным? Что именно приносит вам удовольствие в любимом языке? Может быть, его строгость, выразительность, предсказуемость, метапрограммирование или вообще что-нибудь совершенно другое?

Особенно интересно услышать людей, которые хорошо знают Ruby и сознательно отказались от него. Что в нём оказалось настолько неприятным, что красота языка перестала иметь значение?

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

Программировать вообще-то должно быть в кайф.

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

Только зарегистрированные пользователи могут участвовать в опросе. Войдите, пожалуйста.