#54: Вайбим с Иваном Ямщиковым

[00:00] Александр: Здарова! Вы слушаете 54-й выпуск подкаста «Тысяча фичей». Сегодня вместе с Иваном Ямщиковым мы разгоняем тему вайб-кодинга: пытаемся понять, как в середине 2025 года выглядит программирование и какие навыки приобретают инженеры — чем программисты отличаются от программистов. В конце Иван заряжает мощнейший мотивационный спич. Поехали!

[00:42] Иван: Что сейчас вокруг нас? Дивный новый мир вайб-кодинга. Карпати (Andrej Karpathy) в какой-то момент удачно применил термин «vibe coding», и он разлетелся очень широко; ребята из Кремниевой долины заговорили про «age of the vibe». Феномен интересен по двум причинам. Во-первых, это не совсем кодинг: человек пишет промпты, и на их основе создаётся софт — иногда параллельно в нескольких окнах, с набором лайфхаков, чтобы удерживать контекст и понимание проекта. Иногда со специальным софтом вроде Cursor или Lovable, иногда напрямую — чаще с Claude, потому что для генерации кода он сейчас, кажется, самое популярное решение из коммерчески доступных моделей. Эта идея полетела в массы. И вайб-кодинг хорош для двух вещей. Прежде всего — прототипировать. А вот дебажить вайб-код намного сложнее, чем код, работу которого понимаешь.

[01:52] Александр: Факты, факты.

[01:53] Иван: А поскольку большинство вайб-кодеров — не кодеры, дебажить вайб-код ещё сложнее. Но это лирическое отступление. Факт в том, что быстро прототипировать стало гораздо проще: общий вкус, насмотренность и понимание нужного функционала зачастую важнее глубокого знания фреймворков, на которых ты это строишь. При этом путь от прототипа до продукта по-прежнему долгий — в частности потому, что такое решение стало сложнее тестировать. Инструменты для тестирования вайб-кода есть, но они пока сырые. И это же бутылочное горлышко ограничивает агентов — когда вместо того, чтобы вайб-кодить самому, ты ставишь задачу агенту (или группе агентов), который кодит сам и лишь периодически возвращается с вопросами или просит доступы: «давай интегрируем базу данных, дай ключик». Это продолжение той же парадигмы: уровень абстракции на стороне человека-создателя всё выше, а конкретика — на стороне генеративной модели. Модель сама разбирается, где хранить ключи авторизации, и обычно разбирается плохо: были публичные истории про утечки секретов у вайб-кодинг-платформ. Мы сейчас в моей лаборатории вместе с ребятами, сделавшими агента UpBuild, как раз пытаемся понять, как вообще надёжно тестировать агентов, проектирующих софт. Проблема в том, что тестов можно придумать бесконечно, но чем их больше, тем медленнее работает вся эта махина. И возникает неочевидный трейд-офф: либо быстро собрать прототип, подсветив проблемы отдельно, чтобы человек поправил руками; либо гнать батарею тестов до победного и отдавать результат только когда всё прошло. Второй путь крайне недружелюбен к пользователю, а первый приемлем, только если пользователь достаточно глубоко погружён в стэк.

[05:14] Александр: То есть мы говорим про две развилки в тестировании и валидации того, что делают агенты: либо честная интеграция с человеком, либо что-то более автономное?

[05:27] Иван: Автономная штука всё равно требует понимания, какие тесты осмысленно гнать, а какие нет, потому что конечный результат всё равно валидирует человек как заказчик. Это очень похоже на извечную дилемму фрилансера: как часто встречаться с заказчиком, чтобы тебе заплатили? Слишком часто — сделаешь кучу лишней работы (он будет всё время играться со шрифтами), а заплатит как договаривались. Слишком редко — есть ненулевой шанс, что он скажет «что за ерунда, не буду платить, пойду к другим». Так же и с агентом: тестов не хочется слишком много, потому что если клиент запустил агента и 40 минут нет ответа — человек уходит и не возвращается. А если ответ есть, но он тупо не работает и падает — это тоже не то, чего ждут. Где оптимальный баланс — открытый вопрос, который прямо сейчас исследуют.

[06:47] Александр: Мне интересно, что мы углубляемся как раз в эту тему — а она, как я понимаю, в зоне твоего интереса, в том числе научного: как валидировать и тестировать то, что делают агенты. Редко кто действительно поднимает такое в паблике — все показывают, какие новые модельки и какое будущее, а вот про прикладные интеллектуальные задачи, типа «как сделать так, чтобы это просто нормально работало», говорят редко.

[07:29] Иван: Это связано просто с тем, что компании, которые разрабатывают такие модели, в первую очередь заинтересованы в продаже некоторого будущего.

[07:37] Александр: Конечно, да, безусловно.

[07:39] Иван: Но надо признать, что они его и делают, так что вопросов к ним должно быть по минимуму. Одно дело, когда обещают и не делают, другое — когда каждые полгода нет-нет да случается релиз, от которого все «ого-го».

[07:53] Александр: Это очень важно. И знаешь, почему я в подкасте всё чаще про это говорю? Потому что, попробовав Claude и решив с ним задачи, которые я прокрастинировал, я просто открыл…

[08:08] Иван: А что не Cursor?

[08:09] Александр: Ну, я в Neovim программирую, извини. Cursor я, конечно, пробовал, но это программа, ориентированная на людей, которые хорошо пользуются мышкой, — а у меня руки на клавиатуре, разделённой на две части. Я люблю клацать по кнопкам и программирую в терминале либо в IDE со специальным плагином. С Cursor мой разработческий опыт сильно страдал: он очень opinionated в том, какие клавиши нажимать и как с ним взаимодействовать. Мне стало некомфортно, я попросил агента поменять кей-биндинги, он ошибочно показал не тот пункт меню, я десять минут искал, где это всё меняется, расстроился — и просто взял себе терминальную тулзу. А с Claude опыт потрясающий, это очень круто. И к чему это? К тому, что когда ты этим пользуешься и получаешь value как разработчик, все вопросы к тем, кто рассуждает про будущее, отпадают: оно уже есть, его можно пощупать, и оно работает. А про тестирование и валидацию — мне нравится, как это сделано в Claude Code. Насколько я понимаю, там используются две модели: reasoning-модель и кодинг-модель. Reasoning разбивает задачу на пункты, строит план и реализует его шаг за шагом, очень структурированно — ровно так, как я сам организую работу: завожу тудушку в md-файле, накидываю план, он дополняется по ходу, отражается в git-коммитах. И когда я наблюдаю эту структуру как пользователь Claude Code, я вижу, что он делает буквально то же, что и я. Причём он спрашивает у меня валидацию — вот к слову про тестирование: «хочу сделать это, ок?», «тут нужен доступ, ок?», «запустить cargo check в Rust или прогнать тесты?». Я постоянно получаю эту обратную связь и работаю с ним в паре. Это как раз один из тех способов, про который ты говорил, — когда очень часто взаимодействуешь с «заказчиком». Мне интересно: а как может выглядеть обратное, когда взаимодействие, наоборот, уменьшают? Это про какие-то асинхронные агенты?

[11:01] Иван: Да, всякие агенты типа Manus или того, что делает MiniMax: у них есть агент, который позволяет собирать какие-то странички, сайты и так далее. Обычно это фреймворк поверх моделей: агент стучится в разные модели, а периодически, если не может с чем-то совладать, пишет тебе. Например, ты говоришь «сделай мне приложение», он отвечает «давай интегрируем Supabase» — тебе нужно залогиниться, дать ключи; ты интегрируешь, он говорит «супер» и идёт дальше. Идея в том, что он сначала декомпозирует задачу на подзадачи, те, что может, делает сам, а когда нужен внешний инпут — приходит к тебе. Таких агентов много. Примерно такие же штуки анонсировала Perplexity: браузер, в котором можно давать задания не только для софта, а вообще для чего угодно — например, «купи мне два билета на самолёт…

[12:37] Александр: …на шестое число».

[12:38] Иван: …и всё». Оно ушло, перелопатило нужные сайты, предложило тебе несколько вариантов, ты выбрал, оно открыло форму оплаты, ты заплатил — билеты куплены. Промежуточные шаги, которые предполагают гугление и декомпозицию на подзадачи, агент делает сам с помощью того, что называется reasoning, — то есть последовательности инструкций, которые разбивают изначально большую задачу.

[13:12] Александр: Слушай, мне всегда было интересно разобраться во втором феномене, который случился после прихода примерно GPT-3.5. Сначала мы столкнулись с тем, что, блин, LLM-ки могут генерировать осознанный текст, с которым можно даже общаться. А потом в какой-то момент — опа, они уже reasoning, то есть как будто научились думать, понимать definition of done, понимать, что такое задача. Как произошёл этот переход — что нужно было сделать?

[13:48] Иван: Логика простая: у тебя есть модель, которая умеет восстанавливать пропуски в тексте. Если у тебя есть рассуждение, то восстанавливать пропуски в рассуждении — буквально то же самое: есть вход и выход («дано» и «вывод»), между ними последовательность текста, часть которой можно закрыть и попросить модель её восстановить. Такие штуки по-английски называются chain of thought — цепочка мысли. Как только появились более-менее крупные модели, появились и исследования о том, как структурировать эту chain of thought. Довольно быстро обнаружили, что простую задачу модель решает легко, а сложную — с трудом. Возникла мысль: давайте декомпозируем задачу на простые, проведём модель по серии простых шагов, а потом соберём вместе всё, что она наделала.

[14:46] Александр: Разделяй и властвуй.

[14:50] Иван: С точки зрения задачи — да: разбей на маленькие, и каждая как-нибудь решится. В принципе не rocket science, но технических деталей там много, всё не супертривиально — однако люди это довольно быстро исследовали. Следующий логический шаг такой: раз декомпозиция помогает, получается трейд-офф между качеством ответа и количеством «компьюта», который мы на задачу бросили — модель не доучивается, она просто дольше думает над ответом. Дальше возникают забавные идеи: вот у тебя есть задача и ответ; вместо того чтобы сразу выдать ответ пользователю, ты даёшь модели промпт «посмотри на этот ответ, оцени, какие части хорошо подходят к запросу, а какие плохо». Потом — «выдели плохие части и переформулируй». Добавляешь внутренний критерий остановки — и reasoning заканчивается каким-то ответом. Если ты умеешь останавливать куски рассуждения и генерировать выход по входу, можно собрать pipeline и показать, что качество ответа в среднем растёт по сравнению с pipeline без шага самооценки. Вокруг этой идеи и строится всё, что связано с reasoning. Ведь и люди учатся мыслить через пробы и ошибки: есть ментор, который слушает тебя и говорит «а вот тут как? а с этим что?», ты уходишь думать снова и через несколько итераций приходишь к удовлетворительному ответу.

[17:33] Александр: Хорошо, что ты заговорил про человека, — я об этом думаю почти с начала разговора. Работа с агентами и постановка задач для них очень похожа на то, как если бы у тебя была команда смышлёных, быстро учащихся, голодных студентов, и тебе надо просто скоординировать их работу: понять, кто куда, направить, как ментор, где-то дать свободу, дообучить… Ну, дообучить не можешь.

[18:11] Иван: Да, это иллюзия. Строго говоря, есть у модели reasoning или нет, в реальном времени она не учится — в отличие от человека. Она заранее предобучена и на твоих задачах выполняет то, чему предобучена. Дообучение модели — это отдельный вопрос.

[18:30] Александр: Да-да, дать какой-то фидбэк — вот что я имел в виду.

[18:35] Иван: Фидбэк ты дать можешь. Грубо говоря, модель — это не обучаемый сотрудник с бесконечным объёмом довольно случайных знаний и умений, который плохо понимает, где их применять; ему нужна именно помощь в этом, а не дообучение. В формате чата этот сотрудник на твоей обратной связи не дообучится — ты можешь только прибить гвоздями определённое поведение как правильное, а другое как неправильное.

[19:11] Александр: Но каждый месяц мы получаем апдейты этих «сотрудников», и в этом плане они чему-то учатся.

[19:17] Иван: Я почти уверен, что непрерывное дообучение будет ещё нескоро, и у этого есть технические обоснования. Чтобы что-то выучить, ума много не надо, а вот важно при этом не забыть. У тебя есть полезные данные, ты дообучаешь сетку, градиентом меняешь веса — и она, конечно, выучит новое, параметров у неё много. Вопрос в том, не сотрёт ли она при этом старое. Есть феномен под названием «катастрофическое забывание» (catastrophic forgetting), его активно исследуют. Как это устроено по факту: у тебя огромный набор данных, ты долго учишь модель и набором тестов проверяешь, насколько она «well done». Если недоучена — справляется плохо; если переучена — справляется божественно, но не потому, что выучила что-то полезное, а потому что вызубрила наизусть. Поэтому отдельно нужны тесты на зубрёжку: тебе нужна гибкая модель, а не зубрила. По набору оценок ты в какой-то момент понимаешь, что модель начала ухудшаться, останавливаешь обучение — и это твой чекпоинт. Дальше, если ты делаешь с ним post-training или mid-training (например, специализируешь модель под код), нужно убедиться, что она не забудет важные вещи, которые уже знала, — специальными данными её легко поломать. И пока хорошего неинвазивного рецепта «учиться по чуть-чуть и не скатываться» нет — на рынке нет решения, которое гарантированно позволяло бы инкорпорировать новые данные, не ломая старые навыки.

[22:15] Александр: А не является ли это фундаментальным ограничением? Или ты думаешь, что мы просто пока до этого не дошли?

[22:22] Иван: Мне кажется, не является — ведь люди-то знания инкорпорируют, значит, наверняка это можно сделать. Всё, что физически возможно, — возможно. Хорошая аналогия — химия. Технически мы можем синтезировать любое вещество, которое физически возможно. Но когда говоришь с человеком, который занимается вычислительной химией, оказывается, что это работает как ступеньки: чтобы синтезировать сложное вещество, нужно сначала синтезировать компоненты, а для них — их компоненты, и так далее. Чтобы добраться до нужного вещества, надо преодолеть пирамиду бутылочных горлышек. Мы точно знаем, что химически можем сгенерировать огромное количество веществ, но конкретных реакций, ведущих, скажем, к сверхпрочному материалу для колонизации космоса, у нас нет — комбинаторная сложность такова, что мы не знаем, как до него добраться, хотя знаем, что оно возможно. С LLM (и вообще с машинным обучением) примерно та же история. Мы видим, что мозг умеет учиться, не сильно забывая ранее изученное. Мы не знаем, связано это с тем, что информация в мозге хранится очень эффективно, или с тем, что у нас просто очень много параметров — может, если бы мы знали столько же относительно числа своих нейронов, сколько знает нейросеть относительно своих параметров, мы бы тоже ничего нового выучить не могли. Гипотезы есть, а как сделать то же в алгоритмах — пока не знаем. Более того, для огромного числа задач это и не нужно: все смирились с тем, что модель просто обучают, она стационарна, ею пользуются год, а за этот год делают модель побольше и получше. И тут есть нелинейные эффекты масштаба. Неверно, что модель в 10 раз больше работает в 10 раз лучше — всё сложнее. На выбранном наборе задач (особенно если обе модели чуть дообучали под них, делали fine-tune) большая будет лучше на несколько или десятки процентов. Но по широте применимости большая модель диспропорционально лучше: маленькую можно натаскать на узкую задачу, и она будет ненамного хуже, но чтобы натаскать её на следующую, придётся радикально переучивать. А большую можно натаскать на одну задачу, потом на другую, потом на третью — и ей всё ок. Один из интересных вопросов, который мы решаем в стартапе Pleias: можно ли сделать модель достаточно маленькую, но при этом достаточно гибкую, чтобы работать не под один юзкейс, и не очень требовательную к железу относительно больших коммерческих моделей.

[27:29] Александр: Кстати, про стартап — давай проговорим, чем вы занимаетесь с точки зрения бизнеса, а потом вернёмся к маленьким моделям. Чувствуется, что это прямо зона твоей огромной экспертизы.

[27:43] Иван: Есть стартап Pleias, который мы запустили в декабре 2023-го вместе с Настей Стасенко и Пьером-Карлом Лангле. Мы сделали датасет Common Corpus — его можно найти на Hugging Face, его скачали уже больше 700 тысяч раз. Это один из трёх самых популярных датасетов для предобучения больших языковых моделей — наряду с C4 и датасетами от Microsoft и Hugging Face. Он интересен тем, что назван в честь идеи Creative Commons, идеи Commons вообще. Прелесть в том, что у всех данных есть источники: ты знаешь происхождение (то, что называется provenance), знаешь, что они не нарушают права правообладателей — общественное достояние или допустимые лицензии, и для каждого документа можешь явно прочитать его лицензию. Для нас это было важно, потому что тогда базовая уверенность рынка была в том, что так делать не нужно и невозможно — что нельзя обучить LLM, не воруя чужой контент.

[29:11] Александр: То есть идея была сделать датасет, который не нарушает авторские права, является достоянием общественности и при этом может конкурировать с существующими. Ну и он просто полезный.

[29:26] Иван: На текущий момент мы знаем минимум о восьми LLM, которые использовали наши данные, — например, недавняя NVIDIA Nemo. Но это первый шаг: когда у тебя есть такой датасет, логично обучить поверх него модель. И мы вынужденно оказались в пространстве совсем маленьких моделей: если всерьёз использовать только открытые данные, то можно обучить модель максимум миллиарда на три параметров — больше открытых данных просто нет. Мы обучили семейство на 350 миллионов, 1,2 миллиарда и 3 миллиарда, а сейчас сосредоточились на 350M и 1,2B. Они обучены только на Common Corpus и синтетике на его основе — то есть от начала до конца на данных с понятным происхождением, без нарушения копирайта. Дальше мы задались вопросом, какую ценность маленькие модели могут создать на рынке. Одно из логичных применений — RAG (Retrieval Augmented Generation): у тебя есть документация, поверх которой модель должна быстро давать качественный и полный ответ. Прелесть маленьких моделей для RAG в том, что они нетребовательны к железу (меньше VRAM), их можно развернуть у себя, и они быстрее больших. А документы выступают как аутсорс-память модели: ей не обязательно помнить отдельные факты — нужны здравый смысл и понимание естественного языка, а факты она подсмотрит в источниках. Мы выложили на Hugging Face маленькие, но мультиязычные модели — само по себе достижение, кажется, это единственные модели такого размера с настоящей мультиязычностью (пока в основном европейские языки, в следующей итерации добавим южноазиатские). Во-вторых, они хорошо отвечают на вопросы в RAG: на бенчмарке HotpotQA мы отвечаем примерно как модели в 10–15 раз больше нас по числу параметров. И в-третьих, мы умеем цитирование «из коробки»: модель сама ссылается на документ, на основании которого даёт ответ. Первой такое в большой модели сделала Anthropic (у них есть Citation Mode) — а у нас это работает даже в модели на 350 миллионов параметров. Погрузившись в тему, мы поняли, как устроен спрос. Есть крупные enterprise-клиенты: они попробовали OpenAI или Anthropic, им понравилось, но они думают, как это оптимизировать — в том числе с точки зрения безопасности своей интеллектуальной собственности. Отдавать свои данные OpenAI хочет не каждый бизнес: OpenAI говорит, что на твоих данных учиться не будет, но не каждый готов верить таким обещаниям.

[34:02] Александр: Да, согласен.

[34:04] Иван: Один из очевидных способов сэкономить — гибридный пайплайн: часть вопросов решается пингом в сложную модель (потому что задача сложная), а часть — работой с локальным пайплайном, который ты развернул у себя.

[34:31] Александр: То есть такой ансамбль.

[34:34] Иван: Да, ансамбль: на входе ты понимаешь, сложная задача или простая, и если простая — задаёшь её локальной модели на своём сервере. Особенно если модель маленькая, она может работать даже без GPU.

[34:53] Александр: Да, оптимизация костов — это понятно, об этом комфортно рассуждать. Но большие компании во многих странах ещё и заинтересованы не шерить данные с OpenAI, не отправлять по API половину своих документов просто чтобы получить ответ. Это становится хардстопом, блокером в использовании таких моделей: они бы хотели, им понравилось, но не могут. А вы как раз предоставляете небольшую локальную модель, которая знает про данные, обращается в RAG (где эти данные лежат — в каком-нибудь Qdrant или другой векторной базе), решает часть задач и цитирует, откуда взяла ответ. Кстати, мне это технически интересно: она же не ошибается в цитировании — или ошибается, просто реже?

[36:05] Иван: Цитирование позволяет снизить количество галлюцинаций.

[36:09] Александр: Я думал, там прямо настоящие ссылки, а это просто тот же механизм предсказания, только…

[36:16] Иван: Нет-нет, там есть настоящие ссылки. Но добиваются их тем, что структурируют ответ и показывают модели много синтетических примеров того, как надо приводить цитату на основании входных данных.

[36:29] Александр: Ещё вопрос в тему маленьких моделей — про программирование. Модели хорошо кодят, и та же интеллектуальная собственность в виде кода (куда хочется добавить фичу или покрыть тестами) — вроде бы та же тема: мы не хотим отправлять свой код, где могут быть захардкоженные ключи.

[36:56] Иван: Да, в этом проблема. И тут тоже есть гипотезы, что локальные решения частично будут работать. С другой стороны, одна из проблем в том, что алгоритмы нельзя патентовать — интеллектуальная собственность программистов в основном такая «несуществующая» штука, а цена человеческого труда в этой области очень высокая.

[37:24] Александр: А есть ли сейчас хорошие примеры — кажется, мы точно должны прийти в точку, где локальные модели просто будут хорошо работать. Но прямо сейчас, как программист, я использую удалённые LLM-ки: мне комфортнее получать качественный ответ, и я пишу open source, поэтому не парюсь. А если говорить про что-то локальное, что никуда не ходит, — есть сейчас хорошие примеры? У меня всё-таки аудитория программистов, может, есть на что посмотреть. Знаю, что для кодинга используют, по-моему, Llama, но я в эту сторону давно не смотрел — как вышел Sonnet 3.5, а тем более 4, так на нём и остановился.

[38:09] Иван: Мне кажется, сейчас уровень развития моделей такой, что критически важна разница между людьми, которые ничего не пробовали, и теми, кто попробовал хоть какую-то приличную современную модель. Если ты попробовал — твоя жизнь не будет прежней.

[38:26] Александр: В этом плане — точно, да.

[38:29] Иван: Неважно, через какое решение. Ты просто понимаешь: окей, производительность труда вырастет неимоверно — а с другой стороны начинаешь задумываться, что это значит для рынка, для того, как ты планируешь спринт. Знаешь, в крипто-сообществе была популярна мысль: главное — не быть на нуле. Принципиально отличаются люди, у которых есть хоть сколько-нибудь крипты, от тех, у кого её нет вообще: ты чуть лучше понимаешь, как устроена эта часть технологического ландшафта.

[39:17] Александр: И я бы добавил: как только ты совершил с криптой реальную транзакцию, экономически увидел ценность этих цифр — ты понимаешь, что это деньги.

[39:31] Иван: Ну, это спорно — есть люди, которые даже Нобелевскую премию получили, а до сих пор не поняли, что такое деньги. Я скорее про то, что в фундаментальных технологиях, которые качественно меняют структуру рынка, очень важно просто пожить на этом технологическом стэке неделю. Даже если ты на него не перейдёшь (например, компания не разрешает), ты хотя бы начнёшь думать, что это значит для твоей отрасли, — не на основании рассказов дядь из телевизора или с YouTube, а из личного опыта. Это качественно другая история. Поэтому я бы советовал: для кода лучше Claude Code пока, на мой взгляд, ничего не сделали, и его проще всего попробовать — можно даже онлайн через веб-интерфейс. Попробуйте пожить с ним неделю и посмотрите, как меняются ваши рабочие паттерны.

[40:41] Александр: И продуктивность. Знаешь, когда тебе питчат «надо попробовать, надо использовать, а ты ещё не используешь, а продуктивность, быстрее ускоряться» — это идея на поверхности, которую тебе подают, чтобы ты попробовал. Но мне нравится твоя мысль: пробовать не для того, чтобы сейчас стать продуктивным (это и так произойдёт), а чтобы сдвинуть точку зрения на происходящее, увидеть, как это работает и куда движется, перенастроить майндсет. Однажды попробовав, ты сильно начинаешь отличаться от тех, кто не пробовал, — и от себя прошлого в первую очередь.

[41:41] Иван: Ну да: если ты заглядываешь в бездну, бездна заглядывает в тебя, как говорил Ницше. Но если серьёзно — это верно для любой технологии: если ты работаешь с технологиями, есть смысл периодически трогать их руками. Я впервые попробовал Яндекс.Диктовку, наверное, в 2011-м — работала она плохо, но было понятно, что через какое-то время я смогу вводить текст голосом, и он будет точно распознан. Из этого следовали практические выводы: думать про голосовой интерфейс, если делаешь новую железку, или периодически осмысленно экспериментировать со старой, чтобы понять, насколько технология жива. Я с телефона взаимодействую с Perplexity и ChatGPT в основном голосом — для меня это абсолютно нативно: нажал на микрофончик, сказал, что надо, — модель сделала. А знаю людей, которые до больших языковых моделей голосовыми интерфейсами не пользовались, и им теперь прямо сложно — они печатают что-то в приложении ChatGPT с телефона. У них не сформировался паттерн. Думаю, для поколения моей дочери сама идея что-то печатать будет крайне сомнительной: «печатать? фу».

[43:27] Александр: А с точки зрения программиста — какой поведенческий паттерн складывается у тех, кто этим сейчас пользуется?

[43:35] Иван: Мне кажется, главное, что подсвечивает генеративный ИИ, — это что хороший программист умеет придумывать тесты. Об этом говорили ещё до того, как это стало мейнстримом: качество программиста определяется, среди прочего, способностью придумывать и писать тесты.

[43:53] Александр: Подкаст, первый или второй выпуск которого был как раз про TDD… Приятно.

[43:59] Иван: А что? Можешь теперь ходить и говорить «я же вам говорил». И ведь правда говорил.

[44:09] Александр: И вообще это отвечает на вопрос, что такое программа: это программа, которая проходит набор тестов, которые ты определил.

[44:17] Иван: Да, понятный вывод. Умение писать тесты — паттерн, который отличал программиста от программиста и до генеративного ИИ (как любит шутить Гриша Бакунов, «бывает программист, и бывает программист»). А сейчас этот навык играет ещё более заметную роль.

[44:47] Александр: То есть, наверное, всё-таки не писать тесты в привычном смысле, не печатать их.

[44:53] Иван: Нет — понимать, что такое тесты, как ими обложить то, что ты делаешь, чтобы быть уверенным, что оно работает так, как ты хочешь.

[45:00] Александр: Выделить из системы функции или признаки, которые ты хочешь валидировать, — и успешная валидация этого набора говорит, делает программа то, что ты хочешь, или нет. Это в контексте поведенческих паттернов, да?

[45:22] Иван: Да. На мета-уровне хороший программист отличается от плохого способностью проверять и «хватать за руку» своего агента: агент показывает тебе список тестов, которые проводит, ты смотришь глазами — и понимание, какие туда добавить, а какие убрать, это и есть паттерн, который должен сейчас формироваться у человека.

[45:49] Александр: А знаешь, ещё одно — может, не паттерн, а скорее свойство или чувство. Ты с этого начал сегодня, я даже заметку оставил: вкус и видение важнее, чем что-либо другое. В том смысле, что код за тебя теперь могут написать, а вот что ты воплощаешь, какую задачу ставишь — это теперь начинает требоваться от программистов. Хотя, мне кажется, это и раньше требовалось, нет?

[46:24] Иван: Я не настоящий программист, но мне казалось, что требовалось.

[46:28] Александр: С другой стороны — раньше настоящие программисты всё-таки писали код руками, а теперь руки от этого освобождаются, и надо заниматься чем-то другим. Вопрос — чем. Я в эту сторону про вкус.

[46:44] Иван: Я согласен, просто это очень плохо формализуемая штука — наши слушатели нас виртуальными помидорами закидают: «что такое вкус?». В этом есть некоторый пафос, и совершенно непонятно, что делать. В том же дизайне, UX/UI есть хотя бы книжки, по которым можно растить насмотренность. И в структурах данных или высоконагруженных сервисах есть элемент эстетики — у людей, которые глубоко с этим работают, вырабатывается вкус. Но даже в UI/UX это плохо формализуется: я знаю много людей, которые прочитали кучу книжек и при этом делают плохие, непонятные интерфейсы. А на более высоком уровне абстракции — это как «нет взаимности, не по любви»: нельзя сформулировать почему. Можно долго проводить разбор полётов, но химии нет, вайб-чек ты не проходишь — и всё. И самое плохое, что тут можно сделать, — попытаться формализовать это «буковками через рот».

[48:11] Александр: «Почему ты не проходишь вайб-чек?»

[48:13] Иван: Вот именно. Если бы всё сводилось к словам, многих прекрасных вещей в жизни было бы больше, а каких-то меньше — но мир не так устроен. Есть вещи, которые плохо формализуются, и вкус, на мой взгляд, удивительно плохо формализуется. Поэтому мне некомфортно давать совет «развивай вкус, чувак». Скорее есть смысл в практических вещах. Попробуйте завайб-кодить пет-проект, который давно хотели, но на который не было времени. Прежде чем сядете, сформулируйте, сколько времени, по вашим ощущениям, это займёт, — скажем, что-то на 20 часов, что в лучшие годы вы бы затащили за выходные (с чуть бóльшим количеством кофеина и доставки на дом). А потом сравните, сколько реально ушло: 20, 10, 8, 5 или 18 часов. Это крайне интересный опыт, потому что он не про вкус, а про конкретную формализованную штуку: вы поймёте, что меняется в вашей продуктивности — в терминах формальной отчётности (сколько story points вы бы заложили без модели и с ней). А качественно вы поймёте, что проект, сделанный с генеративным ИИ за 10 часов, — не тот же самый, что вы сами сделали бы за 20. Он будет другим, и появится ощущение, где там дырки, что оказалось проще, а что сложнее, чем ты думал. Это само по себе полезно: даёт ощущение, как меняются требования и ожидания в индустрии. Простой совет: посвятите одни выходные, чтобы что-нибудь завайб-кодить. Хотите больше фана — соберитесь с парой друзей, устройте хакатон или демодей в конце выходных, покушайте пиццы, чуть-чуть испортите себе здоровье, но погрузитесь в этот новый мир. И второй прикладной момент: возьмите Claude для генерации, сделайте этот эксперимент сами, а потом возьмите какого-нибудь популярного агента (MiniMax или другого) и попробуйте то же с ним — сравните, что меняется. Интересно делать это с друзьями: проекты будут разные, и где-то агент будет просто крэшиться, где-то затащит и сильно ускорит.

[52:31] Александр: Да, и это качественно изменит мышление и, возможно, какую-то позицию. Пусть вы потратите одни выходные…

[52:38] Иван: …и, ладно, окей, ничего не изменится, скажете «мя-я-я, такое». Ну зато затащите за выходные пять проектов, которые давно не могли затащить. Это нормальная инвестиция выходных. И относиться к этому надо именно так: не «боже мой, на меня снизойдёт мана небесная, явится Архангел Гавриил и объяснит, как работает генеративный ИИ». Может, не снизойдёт. Зато затащишь пять проектов и пообщаешься с друзьями — почему нет? А постфактум посмотрите, что поменялось. Просто избыточные ожидания неуместны: речь-то не о rocket science, а о каком-то росте продуктивности. По разным оценкам, современные генеративные модели повышают продуктивность белых воротничков процентов на 20–30: условно, закрывали 10 задач в день — будете закрывать 12–13. И это не обязательно код: ответы на письма, привести в порядок страничку с документацией на вики. Продуктивность в коде устроена по-другому — у кого-то растёт сильно, у кого-то меньше. Мир с ног на голову не перевернётся, но 20-процентный рост — это, грубо говоря, за пятидневную неделю сделать столько, сколько сделал бы за шестидневную.

[54:26] Александр: Или за четырёхдневную — столько, сколько за пятидневную.

[54:30] Иван: Да. Это заметный прирост продуктивности, но не фундаментальный переворот, после которого «всё поменялось». Поэтому суперзавышенные ожидания ни к чему. Хотя, конечно, зависит от человека: кто-то может и в полтора, и в два раза повысить продуктивность — по-разному бывает. Но я бы не ждал космоса. Я бы скорее дал себе повод систематически погрузиться в этот технологический стэк, чтобы понять, как он будет менять индустрию.

[55:12] Александр: Да. От себя в заключение дополню твои два замечательных совета: это может стать просто интересной и увлекательной заменой досугу. Прикольно смотреть, как моделька что-то делает, а ты такой: «оп, получается». Это реально весело — особенно если это пет-проект и на тебя не давят сроки. Так что, надеюсь, мотивацию мы заложили. Искренне хочется верить, что большинство слушателей «Тысячи фичей» уже написали по паре своих проектов с Claude, Cursor или MiniMax — чем вы там пользуетесь. А тем, кто ещё не торопится и хочет посидеть на берегу, — давайте, прыгайте, поплыли вместе с нами.

[55:56] Иван: Повайб-кодите буквально сутки — и этот мир станет вам абсолютно…

[56:00] Александр: …понятен. Факты. Ну а на этом, наверное, всё. Спасибо тебе, Вань, что пришёл!

[56:03] Иван: Спасибо большое, ребят. Пока-пока.

[56:06] Александр: Пока.