Итоги года в вайб-кодинге
В общем, мне кажется конец года лучшим моментом, чтобы еще раз поговорить о вайб-кодинге. О нем пишут, ему учат и пытаются отучить, о нем говорят все подряд и даже выбрали словом года. Коллеги по подкасту Радио-Т весь год с угасающим энтузиазмом обещали, что вот-вот всё то, что не соответствующие высокому званию программиста навайбкодили, наконец-то перестанет работать и весь мир придет к ним на поклон за исправлениями — ну, и раз уж я закончил год выпуском уже третьей версии интересного проекта, где весь код написан и отлажен разными версиями AI, то вполне можно и подвести итоги.
Вероятно, когда-нибудь в будущем мы сможем оглянуться назад, ткнуть пальцем в 2025-й год и сказать — вот тот момент, когда искусственный интеллект перестал быть развлечением для гиков и начал вполне реально применяться в работе, заменяя человека. Повторение — мать учения, поэтому я, возможно, повторю сейчас то, что уже говорил в паре роликов в течение года. С другой стороны, прошло определенное время, так что у меня либо добавилось деталей, либо уверенности для таких утверждений.
Ключевая польза вайб-кодинга для меня — это не замена человека-разработчика, а появление всегда доступного разработчика (а то и многих разработчиков) и не только разработчика. Я начал такую разработку с того, что автоматизировал регулярно повторяющуюся задачу — подготовка черновиков и проверка текстов для телеграм-канала. Привлечение AI решило две проблемы — проблему чистого листа в написании комментария и проблему ошибок и неточностей, которые я мог допустить, бегло читая комментируемую новость. Но прежде всего использование LLM — это был Sonnet 3.5 на тот момент, — позволило мне разработать решение, которое иначе не было бы реализовано никогда.
Так и продолжалось — за этот год я оброс целым набором мелких и не очень программ и сервисов, которые решают какие-то рутинные задачи. Я, пожалуй, несколько лет мучился с добавлением новостей для обсуждения в Радио-Т — там надо указать ссылку, после чего робот пытается скачать новость и выделить текст, но в половине случаев он сталкивается с блокировкой роботов. На разработку расширения для Chrome, которое отправляет контент текущей страницы со ссылкой, картинкой и без лишних тегов через API сервиса, ушло в итоге менее часа и с тех пор этот процесс больше не раздражает. Посмотрев в очередной раз на свой блог, я понял, что держать огромный IDE только для написания текста в блоге мне противно, и за пару дней, точнее за 8 часов разработки, у меня появился специальный редактор под MacOS, который просто пишет тексты, вставляет картинки и постит в блог.
Но кроме этого, наверное, можно рассказать (не очень детально) о паре проектов, которыми я в этом году занимался и где AI не просто использовался для устранения мелких недостатков или автоматизации рутинных операций.
В первом (тут я постараюсь обойтись без деталей, поскольку проект непубличный) я выступал в роли продуктового менеджера в небольшой команде. Одной из задач в проекте было обнаружение новых сущностей в интернете. Сейчас эта задача решается достаточно нудно — живой человек идет в существующие сервисы и начинает собирать из них статистику, анализировать изменения, проверять их по другим источникам — в общем, аналитик с опытом много кликает мышкой и в итоге получает надежный сигнал примерно через полтора месяца после его фактического появления. Я сразу подумал о том, чтобы найти более ранние источники и максимально автоматизируемые — и в итоге у нас получился прототип, который сводит задержку с полутора месяцев до нескольких часов или дней, причем выявляет на порядок больше сигналов и делает это автоматически.
Нет, если вы подумали, что это мы так приспособили AI, то нет, в самом процессе обработки ни один AI не страдает. Но он изрядно потрудился в процессе разработки прототипа.
Прежде всего, процесс поиска решения начался с нескольких deep research в нескольких LLM и длинным чатам по результатам исследований — что может быть оптимальным источников сигналов? Несколько возникших гипотез были оперативно проверены тут же написанными AI скриптами и отброшены, а одна показалась интересной. Последовала перекрестная проверка (на этом, да и любом этапе такого общения с LLM очень важно указывать на необходимость критического анализа, а то они норовят воскликнуть “Прекрасная идея” и смысл проверки пропадает), и мы занялись непосредственно реализацией.
Но реализация практически представляла собой два уровня разработки. Получив первый набор очень сырых данных, мы разделились — я занимался поиском признаков для постепенной фильтрации этих данных и проверкой, что эти признаки действительно срабатывают, а основной разработчик по мере наработок воплощал их в реальность в итоговой системе. Каждый очередной фильтр, который мне казался уместным, проверялся через LLM, дальше писался прототип фильтра, через него прогонялся тестовый датасет и результат анализировался на адекватность.
В одном случае первоначальная идея “давайте искать в потоке определенные ключевые слова” в итоге реализовалась в компактную ML-модель, которая фильтровала записи не регулярными выражениями, а использовала Random Forest, показывая 97% точности. Все необходимое для составления датасетов, обучения модели и библиотеку для inference написал, конечно, AI — моя работа заключалась в генерации гипотез и написании промотав. Да, все метаморфозы идеи от гипотезы до архитектуры решения тоже обсуждались с AI.
В другом вроде бы перспективную идею “Давайте проверять, что определенные ссылки ведут на тот же домен” пришлось отбросить — оказалось, что треть ссылок невозможно распознать вообще из-за использования React, а среди оставшихся много ложных срабатываний такого фильтра.
Практически на такие итерации — гипотеза, разработка прототипа, проверка решения, — уходило несколько дней, после чего проверенное решение отправлялось в очередь на промышленную реализацию.
Я же в итоге так разошелся, что часть прототипов начали писаться на Go — компилируемом языке, на котором я сам не напишу ни строчки. Но, когда прототип на Python начал съедать по 300 мегабайт памяти и пришлось выбирать между незнанием языка (хотя я и на Python не писал, весь код писался AI) и перспективой растянуть тест фильтра на пару дней, пришлось довериться машине.
Разумеется, я не удержался и показал часть написанного кода коллеге по подкасту Радио-Т Умпутуну, который считается авторитетом в разработке на Go. Женя, разумеется, сказал, что так никто не пишет, он бы такой код не принял и вообще всё плохо, но к этим возражениям я еще вернусь.
Про второй проект я могу рассказать больше, тем более, что это совершенно публичная вещь, доступная с лета десяткам тысяч пользователей. Речь пойдет о чатботе, который работает уже несколько месяцев на украинском портале dtkt.ua. Чатбот отвечает на вопросы о налоговом и бухгалтерском учете, может дать рекомендации по вопросам отчетности, неплохо ориентируется в изменениях законодательства. Технически это RAG (Retrieval-Augmented Generation) бот, который использует в качестве источника данные самого портала, включающие законы, новости, ответы на вопросы, подготовленные консультантами, инструкции, инструктивные письма налоговой и так далее.
Первоначальный план выглядел совсем не так. Запрос от портала был скорее на помощника для тех самых консультантов и идея была в том, чтобы небольшое решение, напоминающее то, которое помогает мне писать комментарии в телеграм-канал, готовило бы черновик ответа на вопрос пользователя и затем проверяло финальный ответ, откорректированный профессионалом. Но вышло всё совсем не так.
Не уверен, что имеет смысл детально описывать все подробности, поэтому ограничусь конспектом. Сначала мы проверили и отбросили идею сделать fine-tune модели, чтобы она “знала” украинское законодательство. Вообще, данные, находящиеся в публичном доступе, почти гарантированно попадали в датасет больших моделей и все необходимые генерализации уже сделаны. Конечно, если вы делаете решение на основе большого количестве закрытых и специфических данных со своей логикой, то имеет смысл эту логику заложить в модель.
Вопрос выбора основной модели тоже не решился быстро. Хотя мне было легче, поскольку я не знал правильных ответов, но вот консультанты поспорили. В итоге я вспомнил былое, взял набор из нескольких десятков вопросов и ответов (уже имеющиеся консультации) и устроил нормальный evaluation — несколько кандидатов-LLM ответили на вопрос, а затем их ответы сравнили с эталоном — консультант и еще одна LLM-судья. Убедившись, что оценки судей коррелируют (совпадать они не будут, но то, что выше оценивалось машиной, выше оценивал и человек), я прогнал через тест уже 200 вопросов, ответы на которые оценивались только LLM. К моему удивлению, победила, обойдя таких солидных соперников, как OpenAI o1, GPT-4o и Sonnet 3.5, модель Google Gemini 2.5 Pro, только тогда вышедшая.
И тут у клиента появилось желание сделать не помощника консультанта, а полноценный чат-бот. А я, хоть и напоминал несколько раз, в том числе самому себе, что играю роль консультанта по AI, в итоге подумал, а почему бы нам и не замахнуться, понимаете ли? И сел писать ТЗ на вторую версию.
Результат выглядит как полноценный чатбот на портале, который доступен почти 100 тысячам подписчиков, правда, пользуются, понятно, несколько тысяч в неделю. Технически это кластер в Google Cloud, где используется целый комплекс LLM — вопрос пользователя попадает в быструю модель, которая решает, насколько он сложен (и надо ли вообще отвечать, например, попросить рецепт чизкейк не выйдет) и обрабатывает его для лучшего поиска. Мы её добавили, когда в закрытом тесте туда зашел один из тестеров, написал “Привет” и через 50 секунд получил ответ, что в предоставленных документах ответа на его вопрос не содержится.
После быстрой модели (практически горжусь, что придумали router до запуска GPT5) обработанный запрос попадает в поиск, который ищет в векторной базе, где сложен контент портала, и результаты отдает в еще одну LLM для переранжирования. Мы тестировали в разных конфигурациях и в итоге пришли к тому, что поиск собирает до 100 документов (похожих и соответствующих ключевым словам), после переранжирования остается 25 лучших, которые и отправляются вместе с длинным промптом в финальную LLM для генерации ответа.
Пользователь может продолжить чат — в этом случае его новый вопрос отправляется тем же путем вместе со всей историей чата. Это делается, чтобы быстрая модель могла быстро ответить на вопрос типа “Не понял, повтори”, и чтобы большая модель видела, что она уже отвечала.
Вот как раз тут я на этой неделе после тестирования выкатил новую версию — посвятив начало декабря тестированию нескольких параметров и построению автоматической системы оценки.
Перед выводами и обобщениями подчеркну — в этом проекте заняты ровно три человека. Я — как менеджер продукта и руководитель разработки, топ-менеджер портала — как маркетолог (кто-то же должен был настаивать на запуске до января с определенными фичами) и заказчик, и главный консультант как эксперт по качеству системы. Практически весь код написан, проверен, протестирован и внедрен (не хочу писать страшное “задеплоен”) несколькими LLM, главная из которых — Claude, в основном в Claude Code и чаще всего самой мощной и последней версии.
Назовите это вайб-кодингом, если хотите.
Надо, конечно, сказать, что я не гуманитарий с неясным представлением об интернет-сервисах, которым принято изображать “вайб-кодера”. Все же, первый свой сайт я сделал примерно 26 лет назад, ковыряться в скриптах на уровне “загрузил, не работает, написал команду, заработало, изменил в коде, сломалось, еще раз изменил, заработало как надо” я начал 25 лет назад и как-то всё это время разбирался с возникающими проблемами и теми задачами, что ставил себе сам. Много общаясь с разработчиками очень серьезных вещей (вроде поиска в интернете для миллионов человек), я, конечно, не старался давать советы из области тензорного анализа, но на уровне применения разработанных технологий старался не плавать. И многое из того, что я слышал или читал 10-15 лет назад, я с удовольствием вспоминал и применял в течение этого года — хотя и повторяю регулярно “Не ждите, что я вам тут сейчас Google напишу”.
Поэтому популярный аргумент “Он (то есть вайбкодер) понятия не имеет, что там в коде делается” со мной не проходит — я знаю, что там делается, по крайней мере, в общих чертах, причем гораздо детальнее, чем любой менеджер и руководитель знает, что делается в коде, написанном программистом-человеком. Более того, в отличие от такого руководителя, я могу этот код показать другой LLM, вернуться к первой, долго тыкать курсором и задавать вопросы “А что тут делается?” и получать максимально подробные ответы и ни разу не обидеть гениального интроверта-разработчика и не узнав, что я обесцениваю работу, при том, что все равно не разберусь в ней никогда.
Я хорошо себе представляю, что каждый элемент системы, созданной таким образом, получает на входе и что выдает на выходе. Собственно, это главный критерий — если результат не соответствует ожиданиям, надо искать ошибку.
Это мало чем отличается от работы с людьми — как я упомянул выше, в случае с живым разработчиком вы даже меньше знаете, что именно написано в коде, пока сами не начнете его читать и разбираться лучше, чем разработчик. Но, простите, зачем вам тогда собственно разработчик?
Я напомню аргумент моего коллеги по подкасту “Так не пишут, это невозможно будет поддерживать”. Но я и не собираюсь это поддерживать. И приглашать Женю (и кого угодно еще) поддерживать тоже не планирую. То, что код не соответствует чьим-то эстетическим требованиям, не делает его нерабочим. А то, что проект — по крайней мере, чатбота, — активно разрабатывается более полугода с регулярным добавлением новых возможностей и оптимизацией, совершенно определенно показывает, что поддерживать и развивать его можно. Просто поддерживают его не люди, а AI. За это время вышло несколько версий у каждой из ведущих LLM, каждую из них я использовал в разработке и ситуации, когда какая-то из них запуталась и я возвращался бы к предыдущему состоянию системы, практически исчезли (в начале, особенно до перехода к разработке чат-бота, такое случалось).
Более того — далеко не факт, что этот код вообще надо поддерживать даже силами AI. Не хочу сейчас глубоко вдаваться в концепцию disposable code, но в большом количестве случаев может оказаться проще не разбираться в имеющемся коде, а просто переписать его новой версией LLM с нуля.
Ирония с аргументом про поддержку еще и в том, что сейчас разработчики регулярно сталкиваются с проблемой разобраться в чужом коде, чужой системе и поддерживать проект, автор которого давно уволился или даже умер от старости — но это считается священной проблемой legacy и в ней ничего странного не усматривают.
Важный вывод — в описанных проектах использование AI в разработке ускорило процесс в разы. Я все же имел отношение к программным проектам и точно знаю, что разработать систему от ТЗ до начала развертывания за месяц — это очень серьезная задача для команды из людей-разработчиков. Переведите время в деньги и вы получите бюджет на несколько месяцев и несколько десятков тысяч долларов против 200-250 долларов на подписку в Claude/OpenAI/Gemini плюс зарплата “оператора” — мне кажется, “быстрее в разы и дешевле на порядок” будет адекватным результатом сравнения.
Примерно в середине года у меня был текст (и видео) примерно на эту тему — что разработка программного обеспечения, несмотря на свою прогрессивность, представляет собой последнюю область кустарного (хорошо, назовите это крафтовым) производства в истории человечества. Проблема, однако, в том, что человечеству уже нужны не гениальные мастеровые, пусть и за хорошими станками, а автоматизированные технологические линии. Правильный вайб-кодинг в данной аналогии — это оператор за станком с программным управлением. Он не выточит сложную деталь на ручном токарном станке — но составит инструкции, по которым машина изготовит деталь лучше и быстрее, чем любой токарь высшего разряда. Ваши способности по скоростному набору кода действительно утрачивают актуальность — а роль инженерного мышления и умения проектировать сложные системы только растет. Как раз самое время развеять мой скептицизм в обоснованности права программистов называть себя инженерами.