#60: Claude Code и инженерная ответственность с Senior Software Vlogger

[00:00] Дмитрий: Anthropic нельзя привлечь к дисциплинарной ответственности за то, что они сгенерировали плохой pull-request, а Диму Рожкова — можно. Вот поэтому мы Диме Рожкову продолжаем платить зарплату, но если любой агент, которого он использует, обосрётся, то мы спросим с Димы Рожкова — потому что его работа не допускать обсеров моделей. То есть если раньше я отвечал за свой код, то теперь я отвечаю за код, который генерирует модель.

[00:39] Александр: Я собирался включить бэкапную запись, потому что мы записываемся в Riverside — это такой онлайн-сервис для записи подкастов. Попросил Диму включить локальную запись, а он говорит: «Я уже всё пишу». И мне вот интересно: чем это ты таким записываешь наш голос локально у себя?

[00:54] Дмитрий: Да, это моё приложение, оно называется Summit AI Notes.

[01:00] Дмитрий: Название глуповатое: оно пошло от Summit, но, понятное дело, само название занято, поэтому пришлось добавлять к нему разные суффиксы. По большому счёту это приложение для записи звонков на Mac — оно записывает и звук, который мы слышим, и микрофон, причём в два раздельных потока. Сохраняет это как запись, потом всё транскрибирует, то есть расшифровывает в текст, и суммаризирует — всё локально. Отсюда и название Summit, то есть как бы «summarize». По большому счёту это приложение для менеджеров, консультантов, всяких адвокатов, психологов, коучей — для всех, кто очень много говорит на разных звонках, но кому по разным причинам нельзя использовать облачные сервисы. Хотя есть опция подключить и облачный AI, но основной прицел именно на локальную историю.

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

[02:17] Александр: Да, pitch уже чувствуется не первый раз — всё проговаривается чётко, по делу, прямо интересную вещь называешь. Для меня лично цепляющее. Ну а самое интересное в рамках той серии подкастов, которую я делаю… Как ты это написал? Ты вроде не Swift-программист, насколько я знаю.

[02:34] Дмитрий: Я не Swift-программист. На самом деле лет 6–8 назад я пробовал писать что-то маленькое на Swift. Это было такое тулбар-приложение, которое просто дёргало Web API и отображало какой-то статус. Я тогда работал в компании xing.de — это такой LinkedIn для немецкого рынка. У нас там были sandbox environment, которые можно было запустить в виртуальной машине: выгрузить туда свою тестовую версию, потестировать, чего ты там напрограммировал. И вот для этой sandbox environment я сделал тулу, которая позволяла запускать новые окружения, следить, сколько ты их уже запустил, грохать их. И это дело было написано на Swift. Я тогда, помню, взял приложение Никиты Прокопова — Тонского. У него есть такое приложение: точка, которая светилась разным цветом. Я взял его как контейнер и дописал туда какую-то свою небольшую логику. И на этом моё Swift-программирование, собственно, и закончилось. А потом закончилось программирование в принципе, потому что я стал менеджером. Подводя к тому, на чём я всё это пишу: пишу это не я. 100% этого приложения написали Claude Code, Gemini CLI, где-то поначалу начинал Codex. Но сейчас в основном всё пишет Claude.

[03:50] Александр: Круто. Мы про это весь выпуск и будем говорить. Но хочу напомнить: если вам имя и фамилия Никиты Прокопова о чём-то говорят — вы наш слоняра, а если нет, то слушайте подкаст «Тысяча фичей». С Никитой было целых два выпуска, залетайте слушать. А мы дальше продолжаем про Claude Code. У тебя был, подведу итог, некоторый опыт лёгкого программирования на Swift под десктоп — в прошлом, когда-то давно. Сейчас, если тебя посадить программировать, будет сложно. И у меня, в принципе, абсолютно так же. Мне кажется, у большинства разработчиков с большинством фреймворков примерно так же и происходит: ты вроде что-то знаешь, может, даже в универе что-то программировал — представление есть, но джуниор-разработчиком в этой технологии год назад ты бы себя не назвал. Однако ты успешно написал приложение, которое, насколько я понимаю, не только работает у тебя на компьютере, но и довольно успешно продаётся. То есть его можно купить и заиспользовать. Реальный продукт.

[04:57] Дмитрий: Да.

[04:58] Александр: Приносит value.

[04:59] Дмитрий: Всё так. Плюс у Apple же есть статистика crash-репортов. И у меня за всё время всего два crash-репорта, причём в самом-самом начале. Сейчас crash-репортов больше нет. То есть оно не падает у людей, когда они его используют, — по крайней мере, Apple мне об этом не сообщает.

[05:17] Александр: Мне кажется, можно сказать какие-то небольшие метрики, потому что «успешно» — растяжимое понятие. Кто-то скажет, сколько там у него пользователей, ещё что-то.

[05:26] Дмитрий: Ну, напродавал я его на 500 долларов. Получается, оно стоило 30 долларов, сейчас стоит 50. А установок… что-то даже не вспомню, сколько. Наверное, чуть побольше тысячи. Какие-то метрики сейчас загружаются — когда загрузятся, скажу точнее. Но запустилось оно в ноябре. Для дистрибьюшена и маркетинга я пока использовал буквально только свои каналы. Это то, ради чего я, собственно, туда и полез: я оставил всю энергию на то, чтобы заниматься как раз дистрибьюшеном. Но в итоге всё равно занимаюсь программированием на Claude по ночам — это, на самом деле, очень смешной факт. То есть успешность как бы валидирована: людям нравится, люди пишут мне на почту. Даже написал какой-то адвокат из Калифорнии — говорит, попробовал массу приложений, твоё самое лучшее, вот фичи, которые я хочу, чтобы ты добавил. Окей, добавлю. То есть оно провалидировано даже совершенно посторонними людьми, которые не знали, что я существую, до того момента, как скачали приложение.

[06:36] Александр: Круто, круто. Думаю, это только начало — тем более что времени прошло довольно немного. И мне очень нравится, что ты подсвечиваешь то, на что действительно тратится большое количество твоей энергии помимо программирования с Claude, — то, что, оказывается, важно, чтобы продукт стал успешным. Ты уже сказал про дистрибьюшен — а что ещё, помимо самого приложения (про которое мы, конечно, тоже поговорим), надо, чтобы запуститься?

[07:10] Дмитрий: На самом деле не так много надо. И есть даже некоторый тренд с точки зрения этого вайб-кодинга: люди идут именно в Apple-экосистему, пишут приложения для iPhone, для Mac. Мне кажется, это связано с тем, что как раз есть App Store, и он реально работает: люди ищут новые приложения, устанавливают, и некоторые приложения набирают там просто сумасшедшую выручку в месяц — хотя, конечно, вливают они по 200 тысяч долларов в рекламу. Но штука в том, что App Store позволяет получить какую-то валидацию средствами самого App Store. Не говорю, что можно полностью игнорировать дистрибьюшен и маркетинг, но так или иначе: если ты сделаешь приложение под Android, скорее всего, ты умрёшь голодным, а если сделаешь под iOS — с теми же усилиями на маркетинг у тебя, скорее всего, будет больше денег. Получается, чтобы сделать своё приложение конкретно в Apple-экосистеме, тебе нужен Mac. Возможно, тебе даже уже не нужен Mac, но желательно, чтобы был Mac с Xcode, и аккаунт Apple за 100 долларов в год. За эти 100 долларов ты получаешь ещё и время на их Continuous Integration — то есть тесты можешь гонять у них на серверах бесплатно, — получаешь место в iCloud, там даже нет тарификации. По большому счёту ты можешь сделать, допустим, какую-то игру, использовать iCloud как базу данных и не платить за неё. Причём эта база данных может быть как приватная для каждого конкретного пользователя — Apple создаёт отдельный инстанс, — так и общая для всех. То есть можно использовать и то, и то одновременно: какие-то приватные данные хранить в отдельном приватном контейнере, а общие — в общей схеме. Условно, если это игра: инвентарь пользователя лежит в приватной базе, а таблица рекордов — в общей, чтобы все её могли читать. То есть Apple даёт замечательную экосистему для старта. Плюс есть Swift — типизированный язык для всех этих новорождённых поделий. Его чуть легче использовать в том плане, что он сам себя как бы верифицирует: если он скомпилировался, типы сошлись, то, по крайней мере, наверное, что-то будет работать.

[09:47] Александр: И тут я тебя остановлю. Я вообще редко прерываю, но прямо чувствую, что у ребят, которые слушают, вопрос на лице: в смысле Swift? В смысле Swift?! Да на нём не так много open-source-кода, LLM-модельки наверняка программируют хуже, чем на том же Python, Go или Java. Какой Swift? Причём тут компиляция? Вот тут можно прямо подискутировать. У меня своё мнение, конечно, есть, но хочу услышать, что ты ответишь людям, которые могут сказать подобное возражение. Ну, помимо того что «ребята, у меня работает в App Store» — это мы оставляем за скобками.

[10:21] Дмитрий: Оно не только у меня работает. Есть такой польский инди-девелопер, Кицес, кажется, его зовут, который просто навайбкодил… Ну окей, допустим, раньше он писал всё руками, а теперь перешёл, кажется, на Cursor, и навайбкодил каких-то 10 различных приложений для Mac — и они все работают. И он напродавал на 5000 в месяц. Понятное дело, что у него 80 тысяч подписчиков в Twitter, у меня поменьше, поэтому у него дистрибьюшен чуть лучше налажен. И он делает приложения, которые решают одну проблему. Например, если у меня приложение для записи и разбора звонков, такой комбайн, то у него приложение чисто на очень-очень модную сейчас тему — голос в текст. То есть, условно, голосовая клавиатура: приложение, которое позволяет сделать хороший голосовой ввод в любом другом приложении. Потому что у Apple голосовой ввод, конечно, есть, но он очень плохой. Так что это не только у меня работает. Я, можно сказать, уже, наверное, не позднее большинство, конечно, но уже early majority получается — раннее большинство. А насчёт Swift: я думаю, ты прав в том, что кода в open source на Swift, на котором можно было бы поучиться, гораздо меньше. Но всё равно достаточно. Плюс, мне кажется, играет роль ещё и то, что у Swift порог входа чуть выше, чем у Python. Соответственно — это чисто индустриальная интуиция, которая может быть и неправдой, — код, который лежит на GitHub, возможно, будет выше качеством. Нафигачить что-то на Python или JavaScript и выложить — проще, в том числе с той точки зрения, зачем это делать. А на Swift непонятно, зачем это делать, и сложнее. Получается, если код выложен, то он уже, наверное, делает что-то хорошо и у него есть какая-то цель. То есть обучающая выборка, может, и меньше, но качественнее. Как говорится, закругляя всё это, — он пишет на Swift. Штука в том, что я про это тоже делал видос — как сеньору вкатиться в вайб-кодинг. И там суть в том, что я на самом деле не могу оценить качество этого кода: я не Swift-программист. Я оцениваю качество кода только как чёрный ящик. Первое: он работает? Работает. Память не жрёт? Не жрёт. CPU под контролем? Под контролем. Потом смотрю метрики качества кода — у меня есть линтер: проверяю, соответствует этот код каким-то стандартам линтера или нет, есть ли варнинги. Надо ещё, наверное, заметить, что приложение у меня написано на Swift 5. Там есть места, на которые Xcode ругается, что в Swift 6 это будет запрещённое поведение — его желательно уточнить или переписать. Но так или иначе: когда я последний раз замерял, в приложении было что-то типа 50 тысяч строк кода на Swift. Оно работает, я его использую в разных вещах — на работе тоже использовал. Единственный, наверное, вариант доказать, что всё клёво, — нанять какого-то сеньор-Swift-разработчика, чтобы он сделал ревью. Но мне не очень интересно это людям доказывать. Моё доказательство в том, что оно работает и не падает.

[13:47] Александр: Очень тонкая дорожка, конечно, — просить сеньоров ревьюить код LLM, потому что здесь включается человек. А человек — это существо, которое базово обладает многими эмоциями, и эти эмоции могут возникать и управлять людьми. Так вот вопрос: какие эмоции у этого сеньора возникнут? Будет ли он знать, например, что это LLM-код или нет? Можно ведь сделать такой чёрный эксперимент: не говорить, кто написал код, и просто попросить поревьюить. Вот тогда, возможно, будут очень интересные вещи. Но это уже, знаешь, просто не хочется на это время тратить, потому что по программированию действительно всё становится понятно. Мне, как сеньор-разработчику, всё стало ясно уже несколько месяцев назад. С другой стороны, ты говоришь очень правильные вещи: ты смотришь на то, что реально важно для продукта. Ты назвал эти метрики, повторять не буду, — и это то, что всегда было важно. Просто мы, разработчики, которые уткнулись в свои терминалы и редакторы кода, частенько про это думаем, если пишем на Swift, потому что мы всё-таки пишем приложение и сразу видим: во-первых, есть инструменты, легко это посмотреть; во-вторых, это в целом заметно — когда запускаешь приложение на iPhone, а у тебя UI-поток фризится, ты такой: «блин, надо это профайлить», по-другому никак. А вот бэкендеры чаще всего просто добавляют ещё один endpoint — хорошо, если добавляют тест, хорошо, если проверяют ручками и пушат на CI. А сколько памяти добавилось, а что там этот поход в базу данных, — ну, потом, может быть. Короче, я к тому, что мы и сами про эти важные метрики редко думали — про них думал кто-то другой, если мы говорим про большие компании и приложения. Но про это всегда кто-то думал, это всегда было важно. Важные вещи для приложения всегда мониторились. Сейчас их ещё не автоматизировали, с ними ещё не научились так хорошо работать модели — хотя некоторые попытки уже есть, чтобы и эту часть им делегировать. Но в целом мне нравится, что ты назвал эти штуки. Можем идти дальше — к самому Claude Code, к приложению, к моделям. У меня первый вопрос: ты какую модель использовал? Начал программировать приложение в июле — и тогда был что, Sonnet 4?

[16:09] Дмитрий: На самом деле всё приложение написано за 20 долларов в месяц, по вечерам — причём не каждый вечер, покуда хватало лимитов, и не каждый раз я даже упирался в лимит. И всё оно написано по большому счёту четвёртым Sonnet, плюс иногда я подключал бесплатный Gemini, плюс иногда подключал Codex по ключику. Так что я переключался между моделями. Особенно это было важно, наверное, когда формировалось ядро приложения, потому что некоторые моменты тяжело было стартануть, чтобы они сложились. И вот это, наверное, к обучающей выборке очень хороший подход: несмотря на то что есть какие-то примеры приложений, есть документация про то, как использовать ScreenCaptureKit на Mac — это официальная библиотека для записи с экрана, собственно, видео и аудио, — Claude почему-то не мог написать рабочую штуку, чтобы она писала оба потока. Возможно, он мог написать какую-то демку, но мне-то надо было в эти потоки подсасываться, куда-то их перенаправлять, что-то с ними делать. Вот это заняло довольно существенное количество времени — настроить именно базовую функциональность, чтобы я мог записывать раздельно микрофон и звук. На самом деле там ошибка, мне кажется, была в том, что я пытался заставить его записывать только звук и не записывать видео с экрана, а сама пиха этого не позволяет: у тебя всегда будет видеопоток. И я очень много времени потратил на эту борьбу. Отвечая на вопрос: это был Sonnet 4, плюс иногда Gemini — как он там, третий Gemini, или 2.5 даже, — и Codex, какой-то пятый Codex.

[18:03] Александр: Я, когда слушал твой первый видос на YouTube, где ты только начинал про это рассказывать, ты как раз описывал этот кейс — про запись звука и видео. И я прямо почувствовал: знаешь, в работе с моделями ты не можешь головой объяснить, но чувствуешь, будто понимаешь — я тогда прямо внутри себе сказал: «походу, это был Sonnet». Потому что Opus так себя уже не ведёт: реально Opus такой фигнёй страдать не будет, он тебе сразу предложит посмотреть. Мне кажется, сейчас, если бы ты работал с Opus, ты бы эту задачу просто чуть быстрее решил. Или, возможно, даже этого кейса бы не возникло. Как вариант?

[18:45] Дмитрий: Скорее всего, да. 4.5, конечно, на голову выше, чем Sonnet. Opus 4.5 прямо. Для некоторых — я в X видел такое мнение — он стал водоразделом в том плане, что теперь оно действительно полезно. Если раньше, допустим, с Sonnet ты как-то вымучивал из него решение, то сейчас гораздо реже приходится этим заниматься: он гораздо чаще делает правильно и может найти какие-то старые ошибки, которые у тебя были в приложении, какой-то старый код переписать.

[19:21] Александр: Всем сейчас, кто слушает и почему-то ещё этого не сделал, но хочет поиспользовать Claude Code и как-то расти в карьере — не знаю, себе премию, может, получить, — и у вас есть разрешение от компании (или это ваши проекты) на то, что можно Claude Code туда запустить: просто берёте Claude Code, Opus 4.5 и говорите: «пройдись по моей кодовой базе и скажи, где тут баги, что улучшить, что можно подрефачить». Ребят, вы офигеете. И ваш работодатель офигеет.

[19:56] Дмитрий: Ну, его можно даже направлять. Есть различные инструменты статического анализа, в частности те, которые строят диаграммы зависимости классов и прочее. Можно подготовить эти файлы и сказать: «вот у тебя есть структура приложения, посмотри, есть ли места, которые вызывают у тебя подозрения, — залезь в них». Опять-таки, мы же говорим про сеньор-разработчиков, да? Мы же не говорим про вайб-кодеров, которые говорят: «ну, сделай красиво». У меня, кстати, был такой твит — типа «малыш, ну сделай красиво». Потому что это тоже смешно: программисты сами же говорят «нет хорошего ТЗ — результат будет ХЗ», а потом заходят в Xcode и говорят: «напиши Тетрис» — и всё, вот это и есть их ТЗ, которое они способны отдать модели. А потом говорят: «ну вот, он не написал 3D-Тетрис с шейдерами, как я хотел, — модель говно». Если ты умеешь направлять модели, тем более если у тебя есть знания сеньор-разработчика, тем более если ты знаешь свою кодовую базу — или думаешь, что знаешь, — то можно конкретно понаправлять его в определённые места. Использовать не жёлтую уточку для дебаггинга, а Opus 4.5. И он действительно может уйти минут на 20 в запой, скажем так, и вернуться с нормальным разбором того, что нашёл. Я всё ещё говорю о том, что хороший — как это по-английски называется — harness, то есть хорошее окружение вокруг всего этого, помогает неимоверно. У вас должен работать форматировщик кода, должен быть линтер, причём линтер желательно настроить самый строгий. Модели не любят писать тесты: по умолчанию тест она, скорее всего, писать не будет, если ей об этом не сказать или не настроить правила. И в этом тоже есть смысл: если модель на каждый чих будет уходить, допустим, на день — типа как задача в один story point, то есть полдня работы программиста, — то вы её не будете использовать. Она должна отрабатывать за секунды или за минуты. Соответственно, она где-то должна срезать углы — и срезает их там же, где срезают углы люди: не пишет тесты по умолчанию, валит всё без архитектуры в один файл. И вот это всё на человеке — причём и как промпт за промптом использования, и как настройка окружения. То есть ты об этом должен подумать. Но, опять-таки, об этом тоже можно не то чтобы думать — это думание тоже можно делегировать: сказать «подготовь окружение для проекта максимально строгое» — и оно сделает. Но вы тогда должны быть готовы, что оно будет тратить на каждый запрос больше времени. Об этом тоже можно в CLAUDE.md добавить строчку — «не используй быстрых решений, подумай каждый раз». Окей, я буду меньше делать с этой моделью, потому что в лимит буду выходить чаще, но каждое её решение будет действительно смотреть, какие есть взаимосвязи в коде. Люди вообще плохо понимают, как конкретно мы работаем. Мне кажется, это самая большая проблема — что мы не понимаем, какое количество информации и контекста у нас перед глазами, когда мы программируем. Когда я смотрю, например, на открытую IDE, у меня, скорее всего, ещё открыта как минимум панель с деревом файлов. И когда я думаю над задачей, глаза волей-неволей воспринимают всю эту информацию. У меня есть тикет в Jira, у меня есть документация — и я как-то хожу между всем этим и что-то думаю. Я вижу, какие у меня есть файлы, я помню, что делал перед этим. А у моделей всего этого нет. Понятное дело, что модель может посмотреть по файлам, но она должна помнить это сделать. Тогда как у тебя, у человека, это просто перед глазами — тебе не нужно делать усилие. Даже если у меня фокус-мод, я вижу только один экран с текстом, — я открою, посмотрю, какие у меня файлы. Буквально подумайте: вы же не говорите себе «окей, посмотрю по дереву файлов, чего у меня есть», а модели приходится говорить это себе, чтобы поглобить, погрепать эти файлы, посмотреть, где может быть что-то полезное. Поэтому если ваше окружение позволяет модели какими-то тулами туда дотягиваться, то и результат будет гораздо лучше. Вот, собственно, и весь секрет. Опять-таки, если мы сеньоры, если мы говорим про архитектурный дизайн, про дизайн-систем, про все эти вещи — ну, вы думайте как сеньор. У вас есть инструмент, и этот инструмент не будет делать за вас всю работу. Он может — но результат вам, скорее всего, не понравится. Сеньорское мышление тоже надо оставлять.

[25:03] Александр: Да, абсолютно всё ты верно говоришь. Знаешь только, что у меня в голове всё это время было? Эти штуки, по сути, когда ты это понимаешь, лежат на поверхности. Это первое, что ты делаешь при работе с моделью. Сейчас я, по крайней мере, всегда её снабжаю всем необходимым: даю доступ сюда, а сюда не даю — понимаю, что здесь секреты, ими точно делиться не хочу, а тут на полную свободу. То есть я в целом так и работаю, но я это не услышал от кого-то и такой «о, теперь буду делать так» — я к этому пришёл. И это, мне кажется, ключевое во всём этом процессе: к этим решениям, к этому флоу — к тому, что ты, например, дорабатываешь CLAUDE.md по ходу работы с проектом, донастраиваешь, задаёшь правила, которым надо следовать («не делай force-push никогда», «делай всегда вот так»; «если хочешь поменять — сделай amend-коммит, если ещё не запушил, а если запушил, то лучше новый коммит») — ты к этому флоу приходишь в ходе работы и обучения работе с моделью. Как будто бы ты работаешь так же, просто говоришь модельке, как это делать. И это, опять же, всё очевидно, но к этому ты приходишь сам. И это ключевое: каждый человек достаточно способен, чтобы к этому прийти и привнести что-то своё. Основная проблема, мне кажется, в том, что люди просто не хотят идти. Вот базово — не хотят идти и учиться. И у меня вопрос: почему? Почему?

[26:38] Дмитрий: Это интересный вопрос, на самом деле. Мне кажется, с одной стороны, здесь есть некоторый элемент отрицания. Были же мемчики — какой там год, 18-й: «ну вот смотрите, оно даже строчку не может дополнить»; 19-й, 20-й год: «смотрите, оно даже функцию не может написать»; 20-й год: «смотрите, оно даже то не может». В какой-то момент мерилом искусственного интеллекта было то, что компьютер может обыграть гроссмейстера в шахматы. Считалось: вот когда машина обыграет человека в шахматы — это будет величие. Потом поняли, что нет, что метрика плохая: шахматы — игра вообще с полной информацией, тем более для машины, которая считает гораздо лучше человека. Компьютер играет в шахматы гораздо лучше человека, а люди играть в шахматы не перестали. И даже в какой-то степени это стало ещё интереснее: теперь люди тренируются играть и с людьми, и с компьютером, и это обогатило игру. Более того, сейчас Магнус Карлсен придумал новые правила шахмат, где, кажется, рандомизируются стартовые позиции, и это даёт ещё более интересный результат. Но там тоже есть момент. Штука же в чём в шахматах: у тебя есть поле, оно всегда начинается одинаково, и у тебя есть, условно, 20 тысяч стартовых комбинаций. Эти гроссмейстеры, понятное дело, помнят все эти комбинации плюс могут импровизировать. А когда придумали рандомизировать стартовые комбинации, весь их предыдущий опыт как бы стал нерелевантным. Гроссмейстеры посидели, подумали: «ну запомним ещё 40 тысяч комбинаций, подумаешь». То есть мы всё равно пришли к оптимизации. Какое-то время это было интересно, но всё равно станет просто чистой механикой запоминания. Шахматисты меня, конечно, сейчас распнут в комментариях, но тем не менее. Некоторым людям, мне кажется, с одной стороны, это ментальная самозащита: «я лучше, компьютер не может быть лучше меня». Чистая психология, это стопроцентно. У других людей возникает, наоборот, какой-то интерес: «о, нифига себе, оно может делать так» — и они относятся к этому с любопытством. Более того, это возникает — мы говорим про машины, но точно так же возникало и к другим людям. Приходит какой-нибудь новый разработчик, не обязательно даже джуниор, а старенький разработчик на команде будет к новичку относиться предвзято, потому что чувствует от него угрозу: «сейчас новенький меня подсидит, а вдруг он умнее — надо его дискредитировать». А с машиной так вообще — это же даже не человек. Никто не заплачет, ничьи чувства не будут задеты, если я буду сливать машину. Даже этические тормоза здесь не работают. Не говоря о том, что программисты в принципе немножко все мизантропы, так что этические тормоза могут отсутствовать — хотя в последнее время это немножко стало выравниваться. Получается, что, с одной стороны, как бы социально одобряемо сливать машину. То есть некоторые люди даже не хотят сесть попробовать: во-первых, они чувствуют угрозу от этой штуки, во-вторых — почему бы не слить новичка, в-третьих — потому что, как ты правильно сказал, это новая штука, с которой надо разбираться. Был тоже интересный твит, не помню, кто написал: почему непрограммистам легче программировать с LLM? Потому что программисты ожидают детерминированный результат, а у LLM он, в принципе, недетерминированный. Понятно, можно настраивать температуру, настраивать выборку токенов и всё вот это — в принципе, от LLM можно получить практически детерминированный результат: один и тот же запрос будет давать один и тот же выход. Но это не то, как работают облачные модели в общем случае. В общем случае один и тот же промпт будет выдавать разные результаты. И это иногда рвёт голову программистам, потому что это не то, к чему мы привыкли: мы привыкли писать программы, чтобы получать детерминированный результат — за это нам платят деньги, за то, что один и тот же ввод гарантированно даёт один и тот же вывод. А когда у тебя такая тула, которая «а вот я сейчас сделаю не switch, а match-if» — типа зачем, нафига, что за вариабельность? Это тоже может очень сильно отталкивать. Видишь, мне сложно об этом рассуждать, потому что я рассуждаю чисто из общения с людьми: своего такого опыта у меня нет, потому что я писал какие-то скрипты, что-то ещё до того, как зарубился на приложение, и у меня не было такого отторжения в принципе. А ещё один момент — это именно нетерпеливость. Если ты действительно крутой сеньор — есть люди, которые не то что не продумывают архитектуру, они её видят: садятся писать с нуля и сразу начинают писать всё правильно, ну, условно правильно. Когда им нужно формулировать это в английские слова, потом получать неточный результат и его постоянно уточнять — для них это выглядит как непонятный промежуточный шаг, который непонятно зачем делать, когда можно сесть и написать самому. Именно поэтому я рекомендую взять какой-то язык или стек, с которым нет опыта взаимодействия. Допустим, если ты пишешь на Rust — не знаю, что там для тебя, какой-нибудь фронтенд, наверное, совсем глупо брать, — ну, начать писать какую-нибудь игру на Unity. Хотя, опять-таки, я не знаю твой полный бэкграунд. Но что-то совсем другое, где ты не можешь оценить даже качество кода — можешь оценить его только по вторичным признакам: построить диаграмму классов или просто пробежаться.

[32:46] Александр: Ну да, как будто это имеет смысл.

[32:49] Дмитрий: Ты всё равно можешь архитектурно оценить. Даже иногда, глядя просто на структуру папок, которую оно создаёт, ты можешь понять, что там не очень всё хорошо внутри. Но это мы опять-таки приходим к тому, какой изначальный промпт ты ему задал. Ты его вообще просил нормальную архитектуру делать или нет? Ты же ему пишешь «напиши Тетрис», а не «напиши Тетрис с модульной расширяемой архитектурой, которую будут поддерживать люди». Ну, модель срежет углы и напишет тебе Тетрис — но напишет так, как она понимает, как надо писать Тетрис. И в этом ещё есть такой прикол: у китайских моделей с этим вроде как попроще, а вот все эти американские, европейские модели, мне говорили знающие люди, специально тренируют не выдавать решения один в один из обучающей выборки, чтобы не попасться на копирайт. Бывает, что всё равно получается это вытащить — из картиночных моделей особенно: типа с Getty Images получается вытащить конкретные фотографии. Но с точки зрения кода говорят: ну столько же примеров того же Тетриса, почему ты не можешь написать нормальный Тетрис? Потому что её тренировали не выдавать готовое решение, а писать типа с нуля. Это тоже нужно учитывать: несмотря на то что выборка может быть большой и хорошей, один в один решение оно выдавать не будет — оно будет выдавать решение наподобие. И все эти моменты надо учитывать. То есть перед тобой очень-очень умный человек — ну, не человек, а entity, сущность, которая знает очень много всего, может разбираться, но делает ошибки. И это к тому, что мы уже затрагивали — есть желание слить новичка. Есть люди, которые не умеют работать с джунами, — вот они точно так же не умеют работать с LLM. По тем же самым причинам. У тебя есть что-то, что бросается писать код тут же, не подумав, делает массу ошибок, тащит какие-то непонятные зависимости — либо сильно новые, либо, наоборот, сильно старые, которые где-то когда-то прочитало и запомнило. И тебе надо этой штукой управлять. Понятное дело, что если ты предприниматель, который не умеет программировать, и у тебя есть такой джун, ты можешь сказать: «о, да мы сейчас с Димкой весь интернет перепишем». Может, ты не можешь качество кода оценить, даже не знаешь, что будет, если у тебя там тысячи пользователей появятся — может, там всё в файл сохраняется. Но вы даже что-то сможете написать. Точно так же и с вайб-кодингом. А если ты грамотный, не знаю, сеньор-архитектор, и у тебя есть такой Димка, условно, — Opus 4.5, — так ты направляй его, ограничивай, давай ему время подумать, специально говори, что здесь надо подумать. Это очень сильно было важно именно с Sonnet. Opus в этом плане чуть более такой… сеньорности он набрал, сам как будто знает, когда надо подумать. Но всё равно, если ты ему явно скажешь тратить время на задачи, результат будет получше. Хотя, кстати, не всегда результат лучше, но это отдельная тема — иногда им лучше не думать сильно много.

[35:59] Александр: Я как-то замечал, что на некоторых простых задачах проще сказать в режиме чата, а не в режиме агента или планирования. Ну, действительно бывают какие-то приколы, но с Opus я встречаю этих приколов настолько реже — просто на порядок реже, чем с предыдущими моделями. Наверное, вот такой прикол расскажу, потому что ты про это немножко говорил — что хорошо бы, чтобы иногда модель не слишком много думала. Она иногда в своих собственных итерациях, когда делает дело-дело, попадает в такой цикл, и выйти из него ей становится тяжело. Последнее время выходит легче. И самое интересное — я просто удивляюсь тому, на каких вещах мы вместе с Opus в циклы входим. Я вот сейчас делаю сайт для подкаста — думаю, ребята, кто сейчас уже слушает, в ссылках будет просто ссылочка. Заходите и посмотрите, что я там наделал. Короче, я плеер делаю в вебе, чтобы можно было слушать подкаст «Тысяча фичей». Мы всё сделали, просто за два часа зафигачили 95% всего, что сейчас есть на сайте. А потом часа два с половиной я потратил на то… Ну, у меня в терминальном стиле, там мигает курсор терминала. И один курсор мигает вверху, в хедере, а другой — в самом «терминале», где надпись типа «подкаст Тысяча фичей». Так вот, я два с половиной часа потратил на то, чтобы синхронизировать эти два курсора, чтобы они мигали одинаково, а не по очереди. Я не знал — я же не фронтендер, — говорю: они мигают вразнобой, как ёлка, мне не нравится, давай синхронизируем. И мы просто… чего мы только не делали. В итоге кое-как я говорю: так, давай просто подсвети мне, где логика мигания этого курсора, где логика мигания того курсора, и давай подумаем, почему они не вместе мигают. И вот там оказалось, что у них — кстати, нетривиальная задача была. Я бы сам так же решал: пошёл бы, нашёл в коде этот кусок и тот кусок, вычленил бы эти два момента — где мигает здесь, где мигает там, — нашёл бы общее и понял, что его нет. И создал бы это общее, какую-то общую логику. По сути, я сам себе поставил задачу, не зная наперёд, и он её сам решил. Если бы я не был программистом, я бы эту задачу решал по-другому: скорее всего, просто убрал бы этот курсор, решил бы другими методами — будет один курсор.

[38:38] Дмитрий: Это примерно как автор термина «вайб-кодинг» Андрей Карпати. Он разработчик с большим опытом в искусственном интеллекте, работал в Тесле — или «Тесла», надо мной некоторые смеются из-за произношения. В общем, он вывел этот термин и рассказал, как конкретно он это делал. И это тот самый подход, который ты описал: натыкаешься на баг, пробуешь его починить, не можешь — но пробуешь как-то переделать, чтобы он не возникал. Вот это он и назвал вайб-кодингом. Сколько уже этому термину, год?

[39:12] Александр: Ну да, получается… Но я всё-таки решил. То есть я не завайбкодил, я как бы заинженерил, потому что у меня есть бэкграунд, есть опыт. Я бы и сам эту задачу решил, но, правда, полдня бы потратил, потому что я не фронтендер: пока разобрался бы, пока загуглил бы, как эти селекторы работают, какая логика браузера и так далее. А тут сделал чуть подольше. Вообще, тоже забавный момент, раз уж мы про Андрея заговорили: ни один мой выпуск, ни одна статья, которая так или иначе упоминает слово «вайб-кодинг», не оставила эту фамилию неупомянутой. То есть всегда Андрей Карпати упоминается. И мне от этого забавно внутри, потому что это уже какой-то мем стал — упоминать Карпати в разговорах про вайб-кодинг.

[39:57] Дмитрий: Ну, если он придумал термин. Он придумал термин «вайб-кодинг».

[40:01] Александр: Ну да, он как бы автор этого феномена — в смысле придумал слово, термин, всё правильно. Но, с другой стороны, ссылаться именно на какие-то мысли… Вот я к чему хочу подвести — что он говорит просто разумную вещь.

[40:20] Дмитрий: Нет, само собой.

[40:21] Александр: Я просто к тому, что вот то, как ты сказал: я бы скорее всего оставил один курсор. И это ведь тоже решение задачи, понимаешь? Это ещё один момент, почему программисты могут не любить LLM-кодирование, вайб-кодинг: для программиста это не решение. Нет — раз нам сказали сделать два курсора, надо убиться, но сделать два курсора. А для какого-нибудь человека, который не программист, — «ну, один будет тогда».

[40:54] Дмитрий: Да-да-да.

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

[41:24] Дмитрий: Видишь, с одной стороны — да. С другой стороны, во всех умных видео, когда говорят, что программист должен быть близок к бизнесу, учат ведь тоже: пойти к бизнесу и сказать «слушай, я могу потратить месяц, а может, эта фича всё-таки не нужна». То есть определять фичи, которые не важны. Если ты как программист не научился их определять — фичи, которые не важны, — или убеждать, не знаю, продукт, что эти фичи не важны, то есть куда расти ещё и в этом плане.

[41:53] Александр: Мне вот интересно, знаешь, про что поговорить? Про то, что ты-то всё-таки фулл-тайм работаешь, насколько я понимаю, в последнее время больше менеджером. И ты рассуждаешь как менеджер — мне интересно поисследовать этот вопрос, потому что у меня большинство гостей в подкасте это хардкорные разработчики: авторы баз данных, библиотек, опенсорса. Менеджеров у меня, по-моему, ещё не было. Как ты считаешь, как менеджер, какие изменения с этой, я бы сказал, революцией в инжиниринге за последний год ты наблюдаешь? Может быть, стало как-то именно на работе быстрее фичи делаться, быстрее баги фикситься — или ты пока не замечаешь сдвига со своей позиции?

[42:39] Дмитрий: Не замечаю в том плане, что я недавно сменил работу — с условно Java-стека на JavaScript-стек. Вообще, в принципе, я замечаю, что на Java-стеке оно и так медленно всё — даже без искусственного интеллекта. И вроде бы там, опять-таки, в то время был только Sonnet 4, то есть сильного ускорения ждать не стоило, особенно на Java. А сейчас есть Opus, и сейчас TypeScript-стек. Можно выбрать из нескольких агентов, что тебе хочется. Я не спрашивал, используют ли ребята что-нибудь, поэтому у меня нет чистоты эксперимента. Но мне было бы интересно… С другой стороны, всё ещё есть разные задачи. Возникает вот этот момент — в том числе инженерной гордости, но и инженерной ответственности. Даже если код нагенерировала LLM, ты же за него отвечаешь, драть за него будут тебя. Соответственно, лучше потратить время, за которое тебе и так пока ещё платят (как некоторые говорят) — или за которое тебе реально платят, — и сделать самому, отвечать за свой код, чем нагенерировать тысячу строк изменений, а потом потратить то же самое время на их ревью и, условно, допиливание, переписывание. Штука в том, что где-то нужно этому научиться, чтобы потом уверенно использовать. А пока ты уверенно не научишься использовать, объём, который эта штука может создать, просто сбивает с толку. Как я тоже где-то об этом писал: одна из проблем ещё и в том, что за условно два дня плотного кодирования с LLM ты можешь создать контекста больше, чем создавал бы два месяца. Но оно создалось за два дня. И получается, что тебе за два дня надо переварить двухмесячную дозу контекста. Это просто тяжело.

[44:47] Александр: Ну, именно — мы говорим «контекст» для тебя как для человека.

[44:49] Дмитрий: Да, я имею в виду знание. То, что тебе нужно в голове держать. Количество знаний. Ты приходишь на новую работу, у тебя есть кодовая база, ты её изучаешь недельку так, ходишь. А теперь представь, что вся эта кодовая база свалилась на тебя за один день, условно. Вся. И ожидается, что ты должен в ней уверенно себя чувствовать. Это тяжело. Это правда.

[45:13] Александр: И тут, как раз если мы говорим уже про промышленное программирование, скажем так, — не про инди-разработку для себя, — здесь мне очень понравилось, как ты сказал про инженерную ответственность. Мне кажется, это такой термин, который можно вот тебе… Дмитрий Рожков в подкасте «Тысяча фичей» в своё время ввёл термин — называется «инженерная ответственность». И вот это то, что нам нужно ценить в себе, в сеньорах, в ребятах, которые понимают, что такое качественное решение, и они его делали — они смогут его сделать и сейчас, просто если время будет. Такое же качественное решение, а может, даже ещё лучше. Знаешь, я вот сейчас даже лучше требую от модели, чем я бы сам сделал, — потому что я ей не доверяю. А себе я немножко всё-таки доверяю, потому что я из своей головы писал код.

[46:02] Дмитрий: Один из подходов, как ты сам можешь стать лучше: если ты увидишь код, который тебе кажется лучше, чем ты бы написал, — ну, ты чему-то научился, мне кажется, в этот момент.

[46:13] Александр: Да-да-да. Факт. И не только код. Вот про код-то я думаю: наверное, за 10 лет разработки код-то я неплохой пишу. А вот решение — само решение, именно целостное, — то, как ты его описал, какой ресёрч ты провёл… Вот ты оптимизируешь какой-то код: до этого я бы просто написал один бенчмарк, потому что, блин, бенчмарк писать, запускать — это долго. Написал, заоптимизировал, в GitHub пару строчек написал, результаты, может, прикрепил — короче, маленькие — и говоришь: «ребят, всё, быстро». А тут я говорю: так, давай сделаем исследование. Каждое изменение, которое ты считаешь улучшит этот код, должно сравниваться с бейзлайном. И качество самого решения, комплексного, оно круче в разы получается. Я бы сам задолбался так делать, а с моделью получается.

[47:05] Дмитрий: Да? Ну то есть ты очень много рутины переложил на этого джуна, который не устаёт, и заставил его проверить все цифры.

[47:12] Александр: Да, и вот проявление здесь как раз то самое, инженерной ответственности. Я хочу сделать качественное решение всей душой, я знаю, как это сделать, я это объяснил — и оно сделало. И здесь как раз рядом с инженерной ответственностью стоит слово, точнее, зеркалирует её — инженерная безответственность. И это, кажется, то, что я частенько наблюдаю в интернете: говорят, что нагенерили тут этого кода, закинули задачу, оно что-то выдало, вам pull-request скинули — а вам его теперь ревьюить. А там тесты, даже если запустишь, проходят и без изменений. Что это за фигня? То есть происходит обвинение в инженерной безответственности. И это, мне кажется, огромная проблема нас как индустрии — а как этот кризис преодолеть? Потому что, с одной стороны, есть огромное количество сгенерированного кода, который идёт в пайплайн разработки, а с другой — есть ревьюеры, которые просто люди: они устают ревьюить такое количество кода, и есть недоверие. Потому что два раза увидишь этот pull-request, который просто нагенерён — ну, не знаю, в полупьяном состоянии, лишь бы задачу закрыть в Jira, — и теперь все реквесты у тебя такие. И я сталкиваюсь с проблемой как человек с огромным чувством этой инженерной ответственности: мои реквесты просто не ревьюят, потому что у меня написано «generated with Claude Code» — всё, люди просто не хотят это смотреть. И я не знаю, как эту проблему решить. Мне кажется, что код-ревью в классическом понимании уже умерло — просто мы на остатках этого процесса ещё доживаем. Ты как менеджер и вообще со своей позиции — что думаешь про код-ревью, как его можно трансформировать? Потому что явно в текущем виде оно долго не протянет.

[48:52] Дмитрий: Я думаю, что да, не протянет. Но тут нужно, наверное, понять, для чего оно вообще вводилось. Код-ревью — это инструмент пошарить знания. Это одно из его назначений: ты посмотрел изменения и примерно представляешь, куда двигается проект там, где ты его не трогаешь. С другой стороны, это инструмент менторинга — когда ты говоришь новичку или просто какому-то члену команды, как можно написать по-другому, и вы друг друга обучаете. То есть, с одной стороны, ты понимаешь, куда двигается твой проект, с другой — подтягиваешь всех на более высокий уровень, а с третьей — это всё ещё инструмент поймать какие-то баги, которые человек с замыленным глазом не мог найти. Ну вот, можно оставить три. Если мы доверим код-ревью тоже LLM — сможет ли оно ловить баги? Да, сможет. И, в принципе, это то, как я разрабатываю с LLM: сперва пишу какие-то изменения, тестирую, работает, делаю commit, pull request, потом говорю «review». И иногда оно ловит прям серьёзные баги, опечатки; иногда просто ерунду находит — окей, я ерунду говорю не исправлять. Первое, о чём мы говорили, — знания по проекту. Надо ли тебе постоянно эти знания поддерживать в таком ключе, особенно если генерироваться будет гораздо, гораздо больше кода? Если у тебя есть тул, с помощью которого ты можешь эти знания наверстать: ты можешь сказать «окей, я сейчас буду делать такую задачу, накидай мне последних изменений из гита вокруг этой задачи». Теоретически тебе как будто бы и не надо туда идти. С другой стороны, эти знания пригождаются ещё и в процессе operations: когда твой сервис или продукт работает и тебе прилетает условный баг, ты уже как будто знаешь, где это может произойти. Но, опять-таки, если этот баг будет проходить какую-то предпроверку LLM — допустим, какая-то система будет этот баг ловить вперёд и пробовать обогащать его контекстом для тебя: «баг произошёл там-то, там были недавние изменения», — то теоретически оно в принципе может даже чинить эти баги быстрее, чем ты их увидишь. Третий момент, который мы называли, — обучение друг друга как программистов. Мы уже с тобой поговорили о том, что если ты видишь код, что эта система пишет код лучше, чем ты, то, наверное, и обучаешься. То есть как будто бы все три момента, из-за которых код-ревью у нас были, могут быть нивелированы с помощью системы искусственного интеллекта.

[51:58] Александр: И я бы, знаешь, ещё добавил сюда — ну, не моментик, потому что в разных компаниях по-разному, зависит от продукта: где-то ещё можно ревьюить вещи перформанса. Если разрабатываешь какую-нибудь базу данных, то перформанс-инженер придёт и увидит, что ты тут аллоцируешь память, а можно её и не аллоцировать. Но это тоже решается теми же самыми вещами: как будто бы тоже можно это добавить условно в промпт, либо сделать отдельного агента. Никто же тебе не говорит, что у тебя один агент должен делать ревью: один агент делает ревью на требования, другой — на security, третий — на перформанс. Они втроём оставили комменты, а потом четвёртый агент пошёл заново переписывать.

[52:47] Дмитрий: А ещё можно вспомнить, насколько люди вообще в принципе любят делать ревью. Где бы я ни работал, один из самых частых моментов: «о, я наоткрывал pull-request’ов, и их никто не ревьюит». Потому что некоторые люди быстрее пишут код, чем другие, в принципе — ещё когда LLM не существовало. А не-люди ещё быстрее.

[53:05] Александр: Я знаю, у меня есть картинка перед глазами — каждый раз, когда вспоминаю про код-ревью, одна и та же картинка. Короче, software engineering в целом, если мы говорим про промышленное, это как такой pipeline на заводе, конвейер: в одном месте на него накладывают сырьё, в другом его как-то формируют, третьим фильтруют, четвёртым формуют, запекают, упаковывают и продают. В целом мы с софтом делаем примерно то же самое: у нас конвейер выстраивается, просто он долгий и проходит через мозги многих людей. И на одном из этапов этого конвейера у нас код-ревью. Если кто-то читал Голдратта — «Цель», «Цель 2» — это вот прямо оно. У нас сейчас bottleneck в виде код-ревью в процессе. Он очевидный: с одной стороны наваливается огромное количество реквестов, а с другой — код-ревью ограничено, потому что его люди делают. По Голдратту опять же: bottleneck надо устранять, иначе производство просто не будет набирать те обороты, которые ты хочешь, ты не будешь расти. Вопрос в том, как это можно организовать. Ты неплохой пример привёл — с мультиагентами, с ревью. Скорее всего, это уже даже какая-то система будет, не привычный нам GitHub, а что-то другое. Это точно будет разработано и внедрено. Вопрос — что делать сейчас, потому что мы на таком пороге находимся, или уже его перешли, и мы в процессе трансформации, адаптации — такого кризиса, хаоса, бури и всё такое. С одной стороны, есть ранние адоптеры, которые уже вовсю используют и фигачат код, а с другой — скептики, и вот это противостояние происходит. Я сталкиваюсь реально с проблемой, что мои pull-request’ы висят. Мне хочется напихать больше, а оно не пролазит. У меня стоит вопрос, что делать. Хотя сами pull-request’ы качественные — я их сам всегда валидирую руками, сам себя сажаю на место код-ревьюера, делаю self-review в первую очередь, проверяю решения на следующий день, чаще всего даже не в тот же день, чтобы без замыленного глаза. И всё равно оно сложное, сложное решение. Потому что люди реально уже устают от этого. Я не знаю, что с этим делать. Единственное — только подождать. Я думаю, месяца три-четыре-пять пройдёт, и код-ревью просто отпадёт в большинстве компаний. Ну, потому что люди просто увидят. Может, в большинстве, может, не в большинстве, но я думаю, оно будет постепенно отмирать.

[55:35] Дмитрий: Но я вижу сейчас некоторое сопротивление. С одной стороны, есть люди, которые очень шарят в этой технологии, и другие люди, которые в ней не шарят. Предполагается, что они разберутся в этой технологии и будут делать осмысленные pull-request’ы. Сопротивление в том плане, что в одной команде сеньоры, которые в этом разбираются, опять-таки неохотно ревьюят pull-request’ы. Отговорка в том, что pull-request’ы большие — по 1000–2000 строк. Я говорю: ну окей, сделайте правило, чтобы максимальный pull-request был не 2000 строк, а 100 строк. «О, ну тогда это будет много pull-request’ов». Штука в том, что мы утыкаемся в ту проблему, про которую с тобой говорили, — человек может переварить только ограниченное количество контекста. Именно поэтому тебе нужна была команда программистов: ты этот контекст разделял условно на семь человек, и у тебя было семь мозгов, чтобы переварить эту сложность. А теперь, когда ты сам вайбкодишь — я, допустим, программирую, — он столько создаёт кода, что его физически невозможно переварить. Даже если бы я был крутым программистом, которым, наверное, никогда и не был.

[57:16] Александр: В принципе, нереально, нет.

[57:18] Дмитрий: Как говорится, рыночек решает. Рыночек подравняется и найдёт тех архитекторов или тех программистов, которые смогут с этим работать. А люди, которые не могут с этим работать, — ну, придётся научиться, что я могу сказать. Ну, или можно, например, задуматься о чём-то, чем ещё можно заниматься в жизни помимо программирования, — тоже хорошая идея. Потому что сейчас каждый программист становится погонщиком LLM-агентов. Я тоже про это писал статью — что LLM-программирование очень сильно похоже на менеджмент, только итерации быстрее. Если в менеджменте ты условно ставишь задачу, ждёшь неделю, потом её верифицируешь, потом отправляешь на доработку, выстраиваешь процессы, чтобы команда перформила — чтобы pull-request’ы ревьюились, аппрувились, чтобы были какие-то метрики качества кода, — потом ходишь к разным стейкхолдерам, чтобы требования были правильные, всё на месте, потом смотришь, чтобы это влезало в дедлайны. Ну то же самое ведь.

[58:27] Александр: Знаешь, чего нет только? Нет, мне кажется, проблем коммуникации с людьми, потому что ты с ними больше не коммуницируешь. В этом процессе нет долгого ожидания, это быстрее, это меньше коммуникации — и что ещё?

[58:44] Дмитрий: Самое смешное, что агенты пока не обладают агентностью.

[58:47] Александр: Ага, в отличие от людей.

[58:49] Дмитрий: Ну вот смотри: допустим, если у меня в команде Саша Пахомов, он может сам сидеть на стуле и такой: «блин, мы это неправильно делаем» — пойдёт, заресёрчит, сделает, принесёт: «всё, смотрите, вот так теперь будем делать». Такого никогда не сделает агент. То есть принять самостоятельное решение просто потому что…

[59:05] Александр: Да, принять самостоятельное решение в текущей ситуации — и сделать правильное решение.

[59:11] Дмитрий: Ну либо неправильное — агентность тебе позволяет и неправильное решение принимать. Но штука в том, что я могу, допустим, тебе сказать: «слушай, Саша, короче, реши проблему, ты же сеньорный программист». Ты такой: «ну окей, я сеньорный программист, я пошёл решать проблему». Я теоретически могу так же сказать Opus 4.5, но думаю, что результат будет гораздо хуже: он всё равно мне принесёт эту проблему на верификацию. И здесь как будто мы начинаем приближаться к выявлению действительно тех качеств, которые необходимы в текущих реалиях от профессионала, эффективно работающего с LLM: это, «а», менеджмент, и «б», принятие решений слэш агентность. То есть это то, чего не хватает LLM, чего не хватает Opus, и ты их дополняешь — и в итоге образуете просто сильную единицу. Просто каждый программист теперь становится маленьким техлидом: у каждого программиста теперь есть своя маленькая команда программистов.

[1:00:11] Александр: Угу, факт.

[1:00:12] Дмитрий: И это не говорит о том, что ты не должен уметь программировать, что ты можешь теперь вайбкодить, не проверять или ещё что-то. Нет, это означает, что программировать ты должен уметь лучше, чем умел, проверять тебе надо будет ещё больше, чем ты мог проверить. Плюс ко всему ты теперь делаешь не то, что не пишешь код функции, — ты теперь постоянно… ну вот, самая нелюбимая работа осталась. Любили люди делать pull-request и review? Да ни за что — вот они поэтому и висят, их никто не проверяет. Читать чужой код — да вы офигели. А теперь вся работа — надо читать чужой код.

[1:00:49] Александр: Ну, не надо его читать просто.

[1:00:51] Дмитрий: Ну окей, можно не читать, конечно, но ты за него несёшь ответственность. То есть твоя работа теперь в том, что ты несёшь за это ответственность. А как уж ты удостоверишься, что там всё хорошо, — это на тебе.

[1:01:02] Александр: Факт, да. Хочешь — ревьюишь, хочешь — не ревьюишь.

[1:01:04] Дмитрий: Anthropic нельзя привлечь к дисциплинарной ответственности за то, что они сгенерировали плохой pull-request. А Диму Рожкова — можно. Вот поэтому мы Диме Рожкову продолжаем платить зарплату, но если любой агент, которого он использует, обосрётся, то мы спросим с Димы Рожкова. Потому что его работа — не допускать обсеров моделей. То есть если раньше я отвечал за свой код, то теперь я отвечаю за код, который генерирует модель.

[1:01:30] Александр: Да. Мне кажется, это очень крутая мысль, которая в целом достойна того, чтобы даже быть в начале подкаста. С этого можно начать, потому что это суть. Это суть, которая действительно очень важна. Я бы, знаешь, куда хотел двинуться. Мы с тобой совсем не поговорили про конкретные штуки, про конкретные тулы. Мы просто упоминали Claude Code, Opus, Sonnet в виде моделей, немножко ты пару слов сказал про Cursor — и как бы всё. Насколько я понимаю, ты для своего пет-проекта — ну, уже как бы не совсем пет, а просто для своего полноценного приложения — использовал модель Sonnet 4, а среду разработки какую-то использовал?

[1:01:42] Дмитрий: Начинал я именно в Claude Code.

[1:02:18] Александр: Ага. В терминальном приложении.

[1:02:20] Дмитрий: В терминальном всё как бы по старинке, прям вот там фигачил. И особо даже не запаривался с точки зрения стартовать контекст, чтобы под каждую задачу у меня было чистое окно контекста. Я просто всё фигачил в одной сессии. Иногда оно там что-нибудь крашнется, вылетит, сессия рестартовалась. То есть этот проект я, например, написал полностью так. И в определённые моменты, что я ещё делал, когда Sonnet начинал ходить кругами, я запускал, допустим, Gemini CLI и пробовал посмотреть, чего он предложит. Иногда, когда у меня кончались лимиты на Claude и кончались бесплатные лимиты на Gemini, я запускал по токен-ключу Codex CLI — Codex мне там тоже что-то делал. Но в основном всё было в Claude Code. Другой проект у меня ещё был, который я пробовал с такой штукой, как Qoder. Она через Q пишется, кажется, использует Qwen — по большому счёту это тоже такой китайский Cursor, можно так сказать. Но с помощью этого китайского Cursor я написал программу для микроконтроллера — для управления слайдером на Arduino. У меня есть 3D-принтер, он долго печатает, и я хотел таймлапс, но с разных сторон. Обычно как: камеру ставят статично и снимают таймлапс, как принт вырастает. А я хотел, чтобы он вырастал, но ещё и крутился — проезд сделать. Поэтому у меня есть слайдер, по которому эта камера ездит, и мне нужно было запрограммировать движение этого слайдера. Вот этот код для микроконтроллера на Arduino мне написал Qoder. От Cursor я отказался. Поначалу, конечно, пробовал Cursor, он мне что-то даже писал. Но после того как я перешёл на Claude, к Cursor для своего проекта я не возвращался — как-то не видел в этом смысла.

[1:04:19] Александр: Да, я тоже, как человек, который программирует в NeoVim почти всегда — ну и в IntelliJ IDEA, — и, как ты, использую сплит-клавиатуры. Для меня Cursor был просто чем-то, чем я не могу пользоваться. Я туда зашёл, такой: «господи, как тут вообще жить-то?» — и сразу закрыл. Потому что я не могу его кастомизировать быстро и просто так, как могу это сделать в привычном терминале. Конечно, непривычный мне тул. И да, Claude Code для меня сейчас не то чтобы генерилка кода — я вот недавно написал, что это способ взаимодействия с digital вообще, современный: и с локальным компьютером, и с интернетом. Через него я общаюсь с людьми и получаю информацию: могу тикеты в Jira создать, загрепать, посмотреть — и всё это через терминальное окно. Это какой-то технологический рай для меня, потому что я всегда стремился к терминалу, но приходилось его покидать, потому что не всё в нём можно было сделать. А сейчас в нём можно практически всё: хочешь Telegram — ну напиши своего клиента Telegram за два часа, и вот тебе Telegram в терминале, рядом в tmux просто открыл. Короче, я за Claude Code. Но, так понимаю, тебе он тоже зашёл. И в целом, если посмотреть повыше, не с гиковской позиции: Anthropic, по-моему, компания, которая сейчас на голову выше всех остальных — просто по видению того, куда движется разработка с LLM. У них есть какой-то вижен, которому я доверяю, и я бы делал так же, как они. Вот такое у меня ощущение внутри — у меня просто доверие к ним больше как у разработчика, и ещё поэтому использую. А что ещё у нас есть в целом, если людям хочется попробовать, посмотреть вокруг? Может быть, ты на рабочих проектах что-то ещё пробовал, кроме названного?

[1:06:06] Дмитрий: На работе я сейчас использую Cursor — просто потому, что там была возможность выбрать. С Claude я умею работать, а к Cursor мне было интересно вернуться, потому что он очень быстро эволюционирует и очень далеко ушёл от того, где был. Я использовал его для таких вещей, как, например… Я пришёл в новую команду, мне надо понять, что вообще происходит. Я спулил все репозитории, над которыми моя команда работала, и сказал: «расскажи мне, над чем работали за прошедший год». То есть прямо проинструктировал его сделать git-log, отфильтровать по авторам за 2025 год и составить мне список всех изменений: больших фичей, изменений средней руки — просто средняя работа — и тривиальных. Посмотреть, над чем работали программисты, куда стоит сходить, посмотреть, что там действительно было написано. Потому что, опять-таки, мы возвращаемся к тому, что, несмотря на то что ты используешь тул, ты всегда должен верифицировать, ведь ответственность в итоге всё равно на тебе. То есть мне в любом случае надо будет все эти строчки проверить. Но это очень удобно — то, чем я занимался раньше как менеджер: я сам фильтровал эту историю, сам смотрел, какие были pull-request’ы, сам по ним ходил. Просто сейчас я это всё сделал условно за три часа, а раньше мне неделька бы на это потребовалась, чтобы примерно составить представление. Теперь я просто могу делать другие вещи. Это на работе я этим пользуюсь — для таких, менеджерских, задач.

[1:08:00] Александр: Ну и как тебе вообще Cursor по истечении времени? Эволюционировал, говоришь, быстро.

[1:08:04] Дмитрий: Сложно сказать, потому что я с ним ещё маловато поработал. Но я попросил его написать что-то более такое… ну, про то же самое, но с UI: хотел, чтобы у меня был какой-то визуальный отчёт. И что-то как-то с полтычка не завелось. Он что-то начал делать, и в итоге у меня кончилось время, которое я мог этому уделить на работе, — я бросил это дело. Сказал: окей, сделай мне просто markdown-report, чисто по коммитам. Потому что я сперва пробовал делать это с Git API, а Git API мне дал отлуп — я превысил rate limit. Это означает, что Cursor не учёл, что rate limit вообще в принципе может быть. Но я же ему и не сказал об этом — опять-таки возвращаясь к тому, как нужно ставить задачу. В этом плане Cursor как-то… он вроде как туда идёт, они браузер добавили, это удобно, конечно: он может сам всё потыкать, верифицировать эти UI. Но самое смешное — был такой момент: технологии могут условно перестать развиваться, и мы останемся, допустим, с React.js. Потому что, во-первых, на нём очень много кода написано, во-вторых, все тулы как будто запиливают под React.js. И получается, что я программирую настольное приложение, а его в полном цикле очень тяжело тестировать: я его сам руками должен билдить, кликать, — а браузер тестировать легче. Там они подключают этот веб-драйвер, сами могут протыкать, сами могут всё проинспектировать. И может так остаться, что у нас останется один сплошной браузер — просто потому, что модели очень хорошо умеют его в полном цикле разрабатывать. То есть я к тому, что в Cursor теперь есть браузер, вроде как он может его тыкать, но что-то мне взаимодействие с Cursor не очень понравилось — хотя, по-моему, я выбрал тоже Opus 4.5.

[1:09:49] Александр: Это, кстати, к посту, который я тоже как-то писал: очень сильно зависит не базовая модель, а именно окружение — как ты эту модель используешь.

[1:10:05] Дмитрий: Да-да-да.

[1:10:05] Александр: Вот говорят: «какая модель, какая модель» — она, конечно, очень сильно зависит, но тулинг, который оборачивает эту модель, — то, как он с ней декомпозируется, как выстраивает логику, какие тулы ей предоставляет, — это всё огромное влияние имеет. Именно поэтому я ценю Claude Code: я вижу, что это тула, которая прямо с Opus 4.5 отлично работает. И поэтому у меня слабое доверие к Cursor, который тоже с Opus, но это другая оболочка. И вот то, что ты говоришь, у меня внутренне прямо откликается. У меня тоже был такой опыт с Cursor, я подумал: ну зачем? Просто зачем браузер? Господи, пишешь Cursor: давай, какие фреймворки для тестирования браузеров ты знаешь? Вот эти, Playwright? Отлично, давай теперь будем каждый наш коммит тестировать Playwright. Добавили экстеншн в Claude Code — он тоже теперь умеет работать с браузером.

[1:10:53] Дмитрий: Да, ну я вот написал свой экстеншн — скилл, как угодно можно называть. Это, кстати, тоже огромный момент работы с таким тулом: с одной стороны, есть экстеншны, плагины, всякие предготовые промпты, а с другой — ты сам это можешь сделать за час, если реально шаришь и реально хочешь. Сам напишешь этот скилл под себя, как тебе нужно, под свои задачи, и он будет работать. Мы возвращаемся к тому, что не надо переставать быть инженером.

[1:11:24] Александр: Однозначно, да. Сто процентов. То есть про Cursor мы поговорили. А вот такой вопрос. Я когда разговариваю с менеджерами, частенько слышу от них: «вот сейчас уже и твои эти сплит-клавиатуры, Саша, — ты там про Vim делаешь выпуски на YouTube — это уже совершенно никому не нужно, мы все голосом общаемся с моделями». Вот про голосовой input хочу у тебя спросить: у тебя какой опыт?

[1:11:49] Дмитрий: Я пробую его, и с голосовым вводом тоже, но тут нужно понимать, что я работаю над этими проектами в основном по вечерам, — так что голосом сильно управлять не получится. То есть я всё равно печатаю. Плюс, так как у меня подход чуть более инженерный, чуть менее вайб-кодерский, я прямо указываю, какие файлы нужно исправлять. Если я говорю, что что-то нужно добавить, допустим, в правую колонку в моём приложении, то укажу, что за файл я имею в виду. Соответственно, я потрачу меньше времени, меньше токенов, и он быстрее сделает то, что мне нужно. И вот так прицельно добавлять файлы удобнее с клавиатуры всё-таки. То есть я начинаю пробовать работать голосом, но пока в большинстве случаев это именно с клавиатуры.

[1:12:44] Александр: Мне было интересно задать тебе этот вопрос, потому что как автор приложения записи голоса и транскрибации на Mac, думаю, ты наверняка голос иногда в нём дорабатываешь. Но я полностью с тобой согласен в том, что голос — это вещь, которая в физическом мире иногда просто ограничена. И плюс — я на работе занимаюсь тем, что постоянно говорю. Если я буду ещё говорить после работы, у меня никакого голоса не хватит. Есть же профессиональные заболевания ораторов — связки просто изнашиваются.

[1:13:16] Дмитрий: Да, кстати, тоже аргумент. Поберегите свои связки.

[1:13:20] Александр: Мне кажется, мы очень хорошо прошлись. Конечно, глубоко прямо в каждую деталь не зарывались, но просто настолько много всего интересного и так бурно всё вокруг происходит, что как-то жалко тратить время на то, чтобы какую-то одну деталь обсуждать, потому что вокруг столько всего, что хочется обсудить. И, наверное, завершая: у меня есть такой традиционный открытый вопрос, на него можешь потратить сколько хочешь времени. Что бы ты хотел сказать слушателям, которые дослушали до конца, инженерам сегодня, 11 января 2026 года?

[1:13:55] Дмитрий: Спасибо, что дослушали до конца, во-первых. Во-вторых, я бы сказал, что надо попробовать. Попробовать подойти к этому так, как если бы к вам в команду пришёл какой-то трейни, менти, джуниор, который очень хочет помочь, знает очень много разных вещей, что-то умеет программировать, но которого нужно направлять. Отнестись к этому именно с этой точки зрения. Отнестись не как к волшебной кнопке — которой оно, в принципе, и является и кажется для многих людей, не знакомых с программированием, — а как к инструменту, с которым нужно учиться работать и который действительно может ускорить. Не пытаться выжать из него 100x-ускорение, но даже если вы станете в 4–5 раз быстрее, не теряя в качестве в вашем инженерном, — это будет очень большой плюс. То есть вы поймёте, как можно по-другому, по крайней мере. Вот и всё.

[1:14:52] Александр: Спасибо большое, Дим. Было приятно пообщаться. Пока.

[1:14:54] Дмитрий: Спасибо, Александр. Пока-пока.