#72: Зачем IDEA в 2026

[00:00] Антон: Я тоже в этом году темку закинул: а нужен ли вам IDE?

[00:03] Александр: Опа! Человек, который работает в компании JetBrains, которая создала самую популярную IDE в мире, задаёт вопрос на конференции по Java: нужен ли вам IDE? И с подвохом вопрос, как будто бы у тебя есть что сказать.

[00:17] Антон: С двойным дном. Почему я вообще хочу его задать? У меня много в круге общения людей, которые были пользователями IntelliJ IDEA много-много лет. Те люди, которые и программировали на Java, и, скажем так, всегда были за качество кода и так далее. И многие из этих людей сегодня IDEA либо не открывают, либо открывают очень иногда, либо что-то у них вообще другое, третье — как-то поменялся workflow. То есть я от тебя точно такую же фразу, например, слышал, помню, ты сказал: «Я бы рад использовать, но в моём workflow этому инструменту нет места».

[01:13] Александр: И вопрос, Антон: как дела?

[01:17] Антон: У меня вообще шикарно, у нас сегодня выходной. Я отдохнувший, радостный. Ну, помнишь, что было в девяносто первом году?

[01:26] Александр: Ну, как сказать, помню — я ещё тогда не был даже в планах.

[01:29] Антон: Ну, хорошо. Давай поставим так вопрос. Знаешь ли ты, что случилось в девяносто первом году, 20 августа?

[01:34] Александр: Я могу догадываться, но я не знаю.

[01:36] Антон: Ну, Советский Союз развалился.

[01:38] Александр: А, в этот день. Прикольно.

[01:40] Антон: Да, и у нас 20 августа в Эстонии — это день восстановления независимости. Поэтому у нас выходной.

[01:49] Александр: Прикольно, прикольно. Ну, могу только позавидовать, что сказать. И как там вообще дела по поводу конференций в ваших краях? Потому что ты там ходишь по конференциям, я знаю. Всякое интересное узнаёшь. Расскажи.

[02:04] Антон: Слушай, у нас в наших краях, в Эстонии, если честно, с конференциями так себе. А вот в Европе с конференциями очень живо. И мы на них даже ездим. И мне по долгу службы надо ездить на них много. А вот летом у нас перерыв обычно в Европе. И в этом перерыве есть всё равно забавные некоторые ивенты. Unconference — знаешь, что такое? Когда не конференция, а unconference. Не-конференция, получается. Как по-другому это назвать по-русски? Я не знаю.

[02:42] Александр: Сабантуй.

[02:43] Антон: Можно тебя попросить? Закрою чуть-чуть свет, а то ты в YouTube будешь просто как с призраком разговаривать. У нас вылезло солнце, и оно светит прямо мне в окно. Вот это вообще забавно. Такое редко бывает.

[03:00] Александр: Но если это видеоподкаст, то зрители сейчас были свидетелями чего-то очень необычного.

[03:07] Антон: Ну, чудо, да. Это чудо.

[03:10] Александр: Так, и что значит unconference?

[03:12] Антон: Там нет докладов.

[03:15] Александр: А, то есть просто сходка.

[03:16] Антон: Там дискуссии. Да, там сходка, там дискуссии. И на самом деле это очень здорово организовано. В данном случае я не говорю за все такие неконференции. Я говорю за одну, наверное, самую популярную. JCrete называется. Там, где Java-разработчики собираются. На Крите. Есть такой дядька, для многих известный, — Хайнц Кабуц, который там же и живёт. И этот сабантуй где-то с 2011 года, кажется, собирает. И туда человек сто каждый год приезжает. Вот так, по приглашениям. То есть там надо вписаться. Там такой процесс: ты вписываешься, что ты хочешь приехать. Он разыгрывает какую-то свою рулетку и говорит: ну давай, приезжай. И ты тогда подтверждаешь, что приедешь. И тогда за тобой резервируется уже место. Ну вот, где-то примерно сотня таких людей приезжает. А половина из этих людей всегда примерно одни и те же. Поэтому я думаю, что у Хайнца там своя рулетка. Она такая…

[04:18] Александр: Biased.

[04:19] Антон: Да, biased, и с интересными вероятностями. То есть сколько раз я вписывался, столько раз он меня и принимал. Поэтому, наверное, я в его шорт-листе состою. И всегда мне удаётся туда приехать. А за эти годы, надо сказать, что тусовка не молодеет. Как-то, знаешь, все люди старше и старше становятся. Java-программисты всё старше и старше. Ну, такое. Этот тренд, на самом деле, виден везде, на всех конференциях. Не сказать, что прям молодняк в Java идёт. Ну, или, может быть, просто…

[04:59] Александр: Могу его понять. Ну, или подтвердить, например.

[05:03] Антон: Как бы, да.

[05:03] Александр: А как это на месте выглядит?

[05:05] Антон: Это выглядит так, что в начале дня предлагаются разные темы. Просто народ становится в очередь: у меня такая тема. Машет этой самой бумажкой. Объясняет, что за тема. Вешает на доску. Потом вся эта толпа идёт, ставит галочки, что «мне эта тема интересна». Например, три галочки у меня есть. Я иду такой, ставлю — хоп: там одна тема, вторая, третья. И дальше уже темы, которые набрали больше голосов, распихивают по плану. И сразу же поехали. И обычно это где-то 3–4 слота. То есть там в 10, в 11, в 12, в час. И параллельно там около 3–4. Ну, то есть где-то 20 в сумме на доску влазит. И там темы такие, которые обычно… или, скажем так, они подаются не как доклады, а как дискуссии. То есть если я подаю темку какую-то, то я скорее как модератор. А те люди, которые приходят, вот они выражают своё мнение, дискутируют, спорят и так далее. Там есть некоторые исключения. Там, например, Клифф Клик всегда приезжает тоже. И у него всегда обязательно хотя бы один раз за все эти несколько дней, что эта штука идёт, он обязательно читает лекцию про компиляторы. Ну, я пару раз сходил — очень много умных слов, и я ничего не понимаю.

[06:48] Александр: Слушай, а про компиляторы на Java-конференции — то есть про какие?

[06:52] Антон: Ну, смотри, это не совсем… Хорошо, Клифф Клик — ты знаешь, кто такой Клифф Клик?

[06:57] Александр: Да. Создатель C2-компилятора, да?

[07:02] Антон: Ну, как это — это Java, но это не совсем Java. И на самом деле JCrete — там в основном Java-тусовка, но там темы не обязательно про Java. Там темы бывают очень общего характера. Развлекательные, неразвлекательные, очень глубокие. В этом году, естественно, на повестке, наверное, большинства тем, так или иначе, — это AI. Там уже было предложение: давайте переименуем JCrete в AICrete. Так, смеха ради. Вот. Я тоже в этом году темку закинул. Ну, почему: приехал в первый день, думаю — ну, а чего бы нет? Давайте что-нибудь злободневное. И подал темку: а нужен ли вам IDE?

[07:50] Александр: Опа! Подожди. Человек, который работает в компании JetBrains, которая создала самую популярную IDE в мире, задаёт вопрос на конференции по Java: нужен ли вам IDE?

[08:06] Антон: Да.

[08:07] Александр: И с подвохом вопрос, да, как будто бы у тебя есть что сказать.

[08:12] Антон: С двойным дном, да. Вопрос с двойным дном. Ну как, почему я вообще хочу его задать? У меня много в круге общения людей, которые были пользователями IntelliJ IDEA много-много лет. Те люди, которые и программировали на Java, и, скажем так, всегда были за качество кода и так далее. Ну, включая тебя, Саш. И многие из этих людей сегодня IDE либо не открывают, либо открывают очень иногда, либо что-то у них вообще другое, третье — как-то поменялся workflow. То есть я от тебя точно такую же фразу, например, слышал, помню, ты сказал: «Я бы рад использовать, но в моём workflow этому инструменту нет места». Да?

[09:06] Александр: Было дело.

[09:07] Антон: И на самом деле, если порефлексировать, мы всегда существуем в таких информационных пузырях: вот ты можешь сказать «да никто это не использует» или «да все это используют». Когда ты слышишь эту фразу — это когнитивное искажение картинки, когда ты вот…

[09:30] Александр: Это манипуляция такая ещё.

[09:32] Антон: Ну да, тоже. Это либо манипуляция, либо это реально человек в пузыре и просто не заметил этого. Вот, и я такой думаю: ну, вот интересная толпа будет, чтобы спросить этот вопрос вот у них. Что за толпа? Это в основном Java-разработчики, там 20+ лет опыта. И у меня какое ожидание было: что они скажут «да, конечно» и скажут почему.

[10:01] Александр: То есть на вопрос, нужна ли IDE, ты ожидал у той аудитории, которая пришла, — 20+ сеньоры с опытом на Java, — ответ будет: да, нужна, и вот почему.

[10:10] Антон: Да, да, это моё ожидание.

[10:13] Александр: Сейчас мы дальше поговорим детально, что произошло и как дальше пошла беседа.

[10:19] Антон: Почему я такой вопрос задаю? Во-первых, потому что вокруг меня есть люди, которые не открывают IDE.

[10:28] Александр: Ну, под словом IDE мы сейчас даже не имеем в виду IntelliJ IDEA. VS Code — туда же. Любой, любой даже редактор, который делает чуть больше, чем редактор.

[10:45] Антон: Да. Почему такое предположение? Потому что у нас более-менее поменялась работа за последние два года: мы не пишем код руками. Но мы же делаем что-то другое, и вот это что-то другое становится интересным предметом для изучения. То есть я сейчас на эту всю штуку смотрю не как тролль какой-нибудь — я как патологоанатом смотрю: интересно изучать, как workflow поменялись, и что же людям всё-таки нужно, и как они будут составлять эти workflow. Потому что…

[11:18] Александр: Интересное слово — «патологоанатом». Подсознание всё-таки выдало его, а не, например, «учёный-исследователь».

[11:25] Антон: Ну, или можно было бы сказать, как Дроздов: «Вот здесь мы наблюдаем программиста в его естественной среде. Давайте посмотрим, что же он делает для того, чтобы собрать проект. Знакомьтесь, это Java-программист. Он открывает IDE и запускает дебаггер».

[11:45] Александр: Да, вот-вот. Это вообще тема.

[11:49] Антон: Короче, как я и предполагал, люди ответили — не то что в основном, а все повально ответили: да, конечно, нам нужны IDE. Но почти никто из них мне нормально не сказал, чем они пользуются для того, чтобы… ну, когда они его открывают.

[12:09] Александр: То есть на вопрос «зачем» ответа не было?

[12:11] Антон: У меня есть отдельные примеры. Вот давай, может быть, про них поговорим.

[12:18] Александр: Да.

[12:20] Антон: Начнём вот с самого такого интересного товарища — Клиффа Клика, который, в принципе, C++-программист. Ну, потому что он писал JVM, и я сейчас точно не знаю, чем он точно занимается — какие-то алгоритмы, какие-то вычисления там придумывает и так далее.

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

[12:48] Антон: Ну, в общем, очень специфичный дядька. И надо сказать, что люди с похожими задачами, когда я их встречал, ну, скажем, даже меньше чем полгода назад, они бы сказали, что AI нам не помогает. Никак. Они сразу же говорят: нет, это всё фигня. Клифф первый поднял руку, сказал: он пишет где-то там процентов 60–70 своего кода с помощью Claude Code. Вообще он пользователь Emacs’а. Но открывает IntelliJ IDEA, когда ему нужно дебажить Java.

[13:26] Александр: Экзотично.

[13:27] Антон: Да, вот. Это, наверное, такой самый straightforward, самый прямой ответ, для чего нужна ему IDE. Дебажить. Второй товарищ — Питер Лори. Если вы не слышали этого имени, это товарищ, который делал OpenHFT и Chronicle, и вот эта вся очень перформанс-ориентированная тусовка на Java для HFT-шников.

[13:56] Александр: По-моему, были там интересные всякие подпроекты — Koloboke Collections от одного из наших…

[14:04] Антон: Что-то я слышал.

[14:04] Александр: Да-да-да, они на Хабре появлялись, там тоже было такое.

[14:07] Антон: Вот. Этот товарищ тоже очень специфичный. Он говорит, что он всё генерирует Claude Code. Вообще всё-всё. Всё-всё-всё. А потом открывает код и переписывает его руками. Вот. И у него есть очень чёткие аргументы, зачем он это делает. Если он переписывает его руками, мы, наверное, не будем даже задаваться вопросом, где он это делает. Да? Понятно, что в IntelliJ. Вот. Окей, но я таких людей много не встречаю, которые вот сгенерировали код и потом такие не поленятся и всё это перепишут. Пойдут, перечитают, перепишут, да? А Питер говорит, что у него есть достаточно хорошая история мониторинга: как он работал раньше и сейчас и какой его аутпут был. То есть он говорит, что где-то до ковида у него была производительность примерно 500–700 строк кода в день. Сейчас это около тысячи в день. Ну, то есть произведённого кода, который он отправляет всё-таки в version control. Вот. Это интересно. И второй аргумент, который он там приводит… ну, то есть, во-первых, первый аргумент — у него выросла продуктивность. Второй аргумент — это то, что при таком подходе он всё равно полностью владеет кодом. Он полностью знает, что там внутри. Вот. То есть когда он работает с AI, генерирует код, он всё равно, пройдя весь этот путь, не отпускает рук полностью от кода, да? Вот. Что приводит…

[16:01] Александр: Ну, потому что он же его переписывает.

[16:02] Антон: Ну да. И он говорит: пока я его даже сгенерирую, я его миллион раз продумаю. У него там всякие вот эти режимы планирования, plan mode в Claude Code. Сгенерирует — не ваншотит эту задачу, он её тоже там какими-то шагами делает. И вот эти шаги, пока он их все сделает, пока получит результат с агентом, у него уже в голове картинка системы создалась. А дальше уже чисто механическая работа переписывания и оптимизации. То есть, ну, понятно, что он не один в один перепечатывает — это было бы глупо. Он, наверное, как-то переписывает так, чтобы ему было это удобно, хорошо и как-то по своим критериям. Что подвело дискуссию, на самом деле, к интересному моменту, что — ну, это и так понятно, интуитивно, — пока мы работаем с кодом в той или иной форме, нам всё равно нужны будут тулы для работы с кодом в той или иной форме.

[17:06] Александр: Тезис неплохой.

[17:07] Антон: Да? Ну, то есть, это можно немножко более экстремально сделать: а зачем агенты генерируют код на каком-то языке программирования, почему бы уже не генерировать машинный код?

[17:17] Александр: Пару-тройку дней назад я с коллегой, со своим другом Мишей, мы прям час на эту тему разгоняли. Тоже горячая тема. Вот какой смысл, да. Ну, у меня тезис такой был бы — наверное, он тоже шаткий, — что код нужен для того, чтобы потом как-то его диагностировать. Его легче диагностировать всё-таки на высоком уровне, чем на низком. И если у тебя код без спек — допустим, мы как-то делали подкаст про спеки, да, с тобой и с Димой вместе тоже. Но если у тебя код просто навален или работающий бинарник навален, то из кода, который, в принципе, на высокоуровневом языке написан, легче — я не знаю, как русское слово, — экстрактнуть, как-то понять, что программа всё-таки делает. Потому что и LLM-ки научены всё-таки на тексте, а не на бинарном коде. Да?

[18:22] Антон: Вот. То есть, окей, если у нас есть код, и всё равно он является центром вот этого производимого продукта, что же мы всё-таки такого с ним делаем? Что нам нужно в IDE? В основном люди говорят такое: нам нужно код проверять. Вот все остальные — возьмём вот эти две яркие личности, которые один переписывает код, второй дебажит код, уберём их как такие экстремальные примеры, — вся остальная толпа скажет, что нам нужно делать ревью кода. Я очень не люблю слово «ревьюить». Вот за него я бы отдельный котёл в аду сделал бы, но «ревью кода» — норм. Так, а зачем смотреть код? Вот, Саш, ты мне расскажи. Ты же говорил уже, я помню, ты не смотришь на код. У меня, когда люди говорят, что они не смотрят на код, есть такая заготовленная шутка. У каждого должен быть свой момент — moment of shame. У тебя был уже свой moment of shame?

[19:30] Александр: Ты смотришь в корень. И корень лежит в том, что я не боюсь этого moment of shame, и когда он наступит, я его пофикшу. То есть ответственность-то я принимаю. Что, ну не посмотрел? Ну посмотрел бы — увидел? Не факт. Короче, овню я, решаю проблемы я. Решу так же с кодом, так же не глядя. Ответ такой.

[19:52] Антон: Наверное, у каждого вот этот спектр moment of shame может быть очень большой. Один — это когда тебе на ревью сказали, что у тебя тесты закомментированы. Это одно. Второе — это то, что у тебя приложенька крашнулась на мобилочке, и ты её сделал для себя только. А третье — что это баг в продакшене, и там не работает какая-то функциональность, ты пошёл починил. А четвёртое — это когда у тебя outage на миллионы долларов. Это другое. Понятно, что к любому этому аргументу найдётся контраргумент, особенно где-то посередине, в не самых критичных случаях: что мы же можем обмазаться всякими guardrails, проверками, всем чем угодно. Тут немножко дискуссия может свернуть в другое русло: что если мы так делаем, то наш аутпут, во-первых, быстрее не станет, во-вторых, он дешевле тоже не станет. То есть мы как будто бы во всём pipeline ускорили только 5% производства, а всё остальное осталось медленным. Это то, что сейчас во многих компаниях есть: бухаются деньги на ускорение производства, кодогенерации, а бизнес-вэлью не выходит быстрее. Получается, есть расходы, нет прибыли. Но это другая дискуссия. Меня интересует больше вот этот тезис, момент, что люди говорят: мы хотим. То есть они всё равно считают, что они должны владеть кодом и что-то с ним делать. Что-то — вот эти вот задачи я бы хотел найти. В это «что-то» не входит ручное написание, ручной рефакторинг кода, а вот всё остальное. Вот всё остальное мне интересно.

[21:57] Александр: Ну, давай ещё немножко здесь покрутимся — вот про то, каким бы мог быть инструмент будущего, который всё-таки про код всё ещё, да? Но у нас есть тут, раз уж мы так немного здесь, прямо разные точки зрения — вот ты меня спрашиваешь. Я бы сказал, что есть у меня в голове процент того, куда наша индустрия пойдёт. С вероятностью там, не знаю, 30 процентов вот это, 70 вот это, ещё по пятёрке что-то я скидал. Короче, там даже в 100… больше чем 100.

[22:31] Антон: Обложку для выпуска — на хрустальный шарик и нас двоих таких.

[22:36] Александр: Да-да-да. И там вот есть какие-то сущности. Вот одна сущность, которая экстремальная и которая у меня внутренняя, — давай так, процентов 80 внутренней уверенности, субъективной моей, — что этот инструмент и вот то, куда мы пойдём, оно уже не нужно. То есть оно уже не нужно, но мы ещё этого не поняли. Мы как общество и как комьюнити ещё не осознали, не приняли, потому что у нас психика такая, типа сопротивляется. Это вот я наблюдал, этот эффект, с другими, немножко более низкоуровневыми отдельными примерами. Это когда человек наработал какой-то скилл и в него вложился, стал профессионалом. И тут ему говорят, что вот этот скилл может быть заменён чем-то легко. Примеры могу привести — например, Jenkins. Когда DevOps-инженер — вот эта новая специальность — вложил все знания в Jenkins, умеет пайплайны строить, автоматизировать. И тут приходит TeamCity и говорит: у нас просто вот лицензия, вот все функции готовы. Это удар. То есть это получается самокормящаяся система. Сама себя по инерции поддерживает. Они отвергают тогда вот это что-то новое и предпочитают закрыться и вариться в этом предыдущем. И сейчас эффект глобальный.

[24:13] Александр: В случае с AI.

[24:17] Александр: Именно. То есть мы сопротивляемся — большинство, — и в этом сопротивлении, которое идёт изнутри, из подсознания, такое эмоциональное больше сопротивление, мы начинаем аргументы придумывать. То есть наш мозг, лоб, он должен объяснить нашему другому мозгу: а что происходит? Ну вот смотри: «овнить код», «я хочу понимать, что происходит» — вот эти все аргументы, они идут, потому что мы пытаемся объяснить сами себе, что происходит. Не потому что эти аргументы лежат в корне проблемы — в корне лежит другое. То есть мы переворачиваем это и говорим: а что происходит реально? Вот давай реально уберём все аргументы. Происходит то, что, ну, страшно. Реально страшно. Вот и всё. И у этого страха есть вполне определённые нормальные причины, про которые мы сегодня немножко говорили. Во-первых, это страх оказаться за бортом, потому что ты можешь оказаться не нужен. То есть код — это всё, вокруг чего профессиональная идентификация программистов строилась десятилетиями. Код-ревью, код на интервью, несколько этапов кода, код-стайлы. Мы все про код. Все конференции всегда про код, 95%. А сейчас просто вот этот столб под сомнение поставлен. С моей точки зрения — с вероятностью 80%, уже даже и сомнений нет, но, допустим, в головах большинства он всё ещё под сомнением: а нужно ли вообще нам быть про код? И если нет, то про что? Я же как бы про код был. То есть это глубинная переработка своей идентификации. И мне кажется, с большинством именно это и происходит. Просто этому нужно время, и потихоньку, постепенно люди придут к тому, что мы можем строить софт качественный, без багов или с минимумом багов, и всё точно так же на рельсах будет ехать, просто без кода. С чем-то другим мы будем это делать. И вопрос для меня здесь в том, что нужно просто подождать. То есть, может быть, не делать никакой инструмент, и не выгорать, и не тратить ресурсы компании — это отличная стратегия в существующих реалиях, потому что через год, возможно, когда всё устаканится, вот тогда уже будет понятно, какой инструмент нам нужен.

[26:37] Антон: Ну, тут есть вот эти тоже очень философские, наверное, темы. Когда мы дискутируем про то, нужен ли код, или какой агент лучше, или какая LLM-ка лучше и так далее, очень часто упускают из дискуссии одну большую переменную — настоящую стоимость инференса. Это мы сейчас платим, допустим, сколько-то, 90, за подписку за Claude Code — да, Max. А ты посчитай стоимость инференса программиста, который будет руками писать код. Она тоже есть. Мы уже сказали, что мы ускорили что-то, а аутпут быстрее не стал. Точно так же мы вложили в инструмент сколько-то — сколько-то много. Ну, допустим, появилась настоящая цена этого всего дела. Сколько ты сейчас сжигаешь токенов?

[27:44] Александр: Ну, пару тысяч, наверное, в месяц, если так нормально считать.

[27:51] Антон: И это стоимость тебя как инструмента стала. То есть твоя зарплата плюс ещё 2000, чтобы ты быстрее что-то продюсил, так сказать. А для бизнеса лучше не стало. Что делать? Оставить тебе 2000 на инструмент и убрать у тебя из зарплаты 2000, чтобы те же самые косты были?

[28:16] Александр: Ну, неприкольный вариант.

[28:19] Антон: Но это такая тема, на которую трудно дискутировать, потому что мы не знаем: хоп — понастроят дата-центров, и инференс станет быстрее и дешевле, или, не знаю, новая технология появится, или матрицы не надо будет перемножать для инференса, и вообще всё станет очень дёшево. На контроллерах будем LLM-ки запускать. Не знаешь, как технология повернётся. И как технология повернётся — тут тоже: мы почему не верим, например, что моделька станет хороший код производить? Она уже хороший код производит. Год назад все говорили: да фигню она пишет. Сейчас смотришь на этот код, который выдаёт моделька, если более-менее нормальную задачу поставил, — да ёлки, 90% программистов не напишут такой хороший код. Не знаю, ты, наверное, может быть, и не заметил, если ты на код не смотришь. Но я заметил, что он пишет очень хороший код. Очень хороший. Может быть, это обо мне говорит что-то плохое как о программисте, но я могу отмазаться, что я не программист. У меня есть такой козырь. Про стоимость и пайплайн — то, что мы мощно нарастили, а результат не повысился.

[29:42] Александр: Ну да, но это просто такой фактор, наверное. Это не то, что меня конкретно интересует. А ты смотрел, кстати, на этот вопрос — на этот процесс, точнее, — с точки зрения теории Голдратта? Вот я постоянно так всё вижу в мире, и это же вот прямо оно: бутылочное горлышко переместилось из процесса, где-то что-то было в разработке — ну, действительно, долго код писали раньше, его ждали, его планировали, вокруг этого выстроили целые ритуалы. А теперь, оказывается, следующее горлышко у нас как раз код-ревью. Вот.

[30:15] Антон: На эту тему можно поразгонять, например, что люди делают и какие забавные штуки там происходят. Но если модельки начнут производить код, который не надо будет проверять человеку, — это шаг в сторону dark factory. Давай, может быть, условимся, что dark factory — это где-то там за горами ещё, потому что иначе эта дискуссия просто не имеет смысла. А вот прямо сейчас…

[30:46] Александр: Ну, все умрём, можно просто сказать.

[30:47] Антон: Да-да-да, можно сказать, что все умрём. А вот прямо сейчас у людей болит то, что им код всё равно надо проверять. Сейчас во многих проектах вообще говорят: нельзя с AI ничего генерировать. Ну и ладно, про них тоже забудем, может, у них что-нибудь поменяется. А вот прямо сейчас у людей работа с кодом просто другая: они не пишут его руками, они его генерируют агентом, настраивают харнесы, и у них есть куча других задач, включая проверку кода, включая отладку кода, включая, не знаю, какую-то навигацию по коду — просто если совсем базовые функции брать: вот я открыл проект, я по нему навигируюсь, например. Но эта задача была и раньше. Но сегодня у тебя изначальная задача другая: ты открываешь код, потому что тебе насыпали этих пул-реквестов миллион. И раньше у тебя в команде был один такой товарищ, который три тысячи наваливал, а теперь у тебя таких с десяток, и они очень быстро наваливают. Вот как с этим быть?

[32:01] Александр: Я удивляюсь, я диву даюсь отсутствию критического мышления у большинства коллег вокруг. Реально, ну вопрос-то очевидный. То есть эта проблема была и раньше: если у тебя был в команде человек, который умел делать пул-реквесты на 10 тысяч, это уже тогда была проблема. Ну да, ты должен был его проревьюить, но это была не такая большая проблема, чтобы стать вопросом номер один. Как-то справлялись. Я в своей картине мира мыслю так: а зачем мне код-ревью? То есть я — чтобы что? Чтобы код посмотреть? Ну, то есть реально, включаем рацио и пытаемся ответить. Я хочу — как человек, который ревьюит, и его не попросили, «это процесс, это надо», а вот действительно моё искреннее желание, по-настоящему, — я хочу, чтобы он был, чтобы он делал то, что от него требуется, не делал ничего лишнего и потом ничего не выстрелило. Ну, как бы я обеспечиваю некоторое разумное качество этого кода. Когда я делал ревью раньше, руками, своими глазами, я никогда не писал какие-то стилистические поправки: тут надо порефакторить, тут метод слишком большой. Ну извините, а кто я такой вообще, чтобы другого человека с десятилетним опытом работы просить метод на два разбить? Это же бред. Я всегда смотрел на код-ревью как на некоторое разделение ответственности, такое лёгкое, но больше в сторону всё-таки «посмотри свежим взглядом: не сделал ли я здесь что-то лишнего или какую-то фигню, что-то, может быть, забыл, и можно ли это вообще в прод лить? Или надо что-то всё-таки поделать?» Вот как я свою задачу в код-ревью для себя ставил и формулировал. Соответственно, если мы эту задачу вот так вычленяем и говорим: а как я её могу решить с помощью существующих инструментов сейчас? И давайте решать эту задачу: давайте обеспечим качество, целесообразность появления этого кода в мейне, чтобы в проде он не упал, вот это всё — просто забыв про код-ревью, а попытавшись сказать: а могу ли я вообще с кодом вот это решить? Могу ли я написать такую систему, которая будет решать эту задачу автоматически? И вот это интересно, вот над чем, мне кажется, инженерам надо думать, а не над тем, как мне переварить через себя теперь не тысячу строчек, а десять тысяч строчек кода. Да не переваришь, лопнешь ты. И мы как будто искусственно поставили перед собой вот это электричество, новую энергию, новое что-то — и замедлили его своими мозгами. То есть мы, думаю, специально тормозим прогресс вот в этом плане. Искусственно как будто.

[34:39] Антон: Ну, тут можно ещё с разных сторон, наверное, посмотреть. Если проблема в десяти тысячах строчек в PR была проблемой всегда — как мы её решали?

[34:49] Александр: Ну, «разбей», я просил, наверное.

[34:51] Антон: Вот-вот-вот. Разбей на PR-ы. Почему ты сразу же делаешь огромную пачку, огромный PR? Вторая тема, что если он, не знаю, больше ста строчек… Вот тут такой момент. Мне повезло работать всегда одному. Или в паре, но без бранчей. То есть я никогда не делал таких мерджей, каких-то больших ревью. У меня ревью в JRebel были построчные. То есть мы делали правки, там, десять строчек, например, и их ты проверяешь. То есть это немножко другая ситуация, когда тебе прилетает целая пачка функциональности и ты пытаешься понять, что же изменилось. Вот если ко мне такое прилетало, у меня первое ощущение, или первая мысль: а что это делает? То есть я читаю, я умею читать код, я прочту эти, не знаю, тысячу строк, но я от этого умнее не стану.

[35:55] Антон: Меня всегда поражало, что вот наши инструменты для проверки кода последние 15 лет, наверное, никак не улучшались. Максимум, что появилось, — это в GitHub комментарии к строчкам. Но это, блин… Это на самом деле удивительно. Это инструменты из 90-х, привет им, там ничего… Меня просто, когда я на это смотрю и на бахвальство тем, что хороший код-ревью-инструмент где-то вышел, меня просто подгорает, потому что это ужасно всё. Это самая ужасная задача для программиста — делать проверку чьего-то чужого кода и потом ещё и вливать куда-то. Это, по-моему, самая ужасная вообще задача для всех, кто занимается кодом. Так вот, я хочу посмотреть на этот кусок — чего мне там прилетело — и чтобы мне семантически объяснили: вот эта функция теперь работает по-другому.

[36:57] Александр: Не функция имеется в виду, а функциональность.

[37:00] Антон: Функциональность, да. Не то, что там функция кода работает по-другому — я это и так прочту. Почему оно так работает? Вот это важно. И в этом случае мне хорошо бы иметь связку, например, с задачей или с каким-то документом: что вот из-за этого мы сейчас поменяли вот этот код, он теперь работает по-другому, программа работает по-другому. И там такие-то, такие-то функции поменялись. Опять, когда я сейчас говорю слово «функция», это не функция в коде, а функции продукта поменялись, работают по-другому, и поэтому у нас теперь там тест-сьют тоже другой. Вот это я хочу увидеть.

[37:43] Александр: Ты хочешь слышать и видеть и пройтись по истории.

[37:47] Антон: Ну, то есть люди любят истории. Они друг другу рассказывают истории: вот я был там-то, там-то, мне посоветовали, я пришёл, узнал это, это, выводы такие, теперь делаем так. И тебе интересно, ты следишь за этой историей. И вот мы же хотим тоже историю про какой-то инкремент продукта. По факту я вижу продукт, он работает, он стабильный, случился инкремент, новая версия. Расскажи мне историю про него. Я с ней ознакомлюсь; если у меня есть какой-то авторитет или право, я могу с ней не согласиться, чуть-чуть её подправить в терминах этой истории — сказать: а давай-ка ты поедешь не в этот город, а в другой, и остановочку тут сделаешь. И дальше эту историю отпустить, и она пойдёт в продакшн. Мне как человеку, как кожаному мешку, вот что хочется. Я думаю, это всем хочется. Если ты видел, если ты слышал: куча продуктов в последнее время появилось типа про код-ревью — Greptile, CodeRabbit, ещё что-то там. Они все используют AI для проверки кода. Этот AI для проверки кода тебе вываливает тот же самый дифф с комментариями, что вот здесь какая-то функция неоптимально написана. По-моему, те же яйца, вид сбоку: раньше мы использовали SonarQube какой-нибудь или линтеры какие-нибудь запихивали в CI, чтобы они там нам отчёты показывали. Это никак не улучшает качественную ситуацию — понимание того, что за PR прилетел.

[39:16] Александр: Просто он ещё и на вероятностях работает. То есть в следующий раз ты запустишь эту штуку — он тебе другой результат выдаст.

[39:28] Антон: Вообще по-другому всё.

[39:28] Александр: По-другому всё, наверное, не скажет, но где-нибудь там в деталях. Знаешь, что сложно? Вот я сейчас замечаю… Я всё-таки работаю; хоть мы тут и говорим, что я код не читаю, но, естественно, это про какие-то свои проекты, а то меня уволят завтра. Я на работе читаю код, пацаны, всё нормально.

[39:47] Антон: Постелил соломку.

[39:47] Александр: Да, конечно, а то… Но как происходит сейчас у нас ревью на проекте, например? Это вообще… когда это происходит, я думаю: не, ну я, конечно, не думал, что в такой ситуации… Значит, у нас есть процесс: вот надо влить код. Я прошу коллегу, говорю: я тут код написал — я с ним согласен, ну, сгенерировал, естественно, — вроде оно; поревьюй, мне нужен аппрув, не могу влить. Вот не нужен был бы аппрув — я бы давно влил. Мне говорят: окей. Через два дня приходят, говорят: поревьюил, читай. Открываю GitHub — там его сгенерированные полотна, его Клодом, естественно. Я беру своего Клода, говорю: что он мне поревьюил, что там найдено? Потому что я не могу это читать, ну, это почти… Мне мой Клод говорит: короче, на самом деле вот два важных места, остальное я уже поправил. Я такой: так, что за два важных места? Он мне сделал. Я отправляю коллеге, говорю: поправил. И вот этот круг — он теперь на моей правке нашёл какие-то другие правки, то есть это может длиться дня три. Ну, потому что есть другие задачи, есть CI, который кряхтит на каждый инкремент вот этого события. Я когда представляю вообще, чем мы занимаемся в этот момент, у меня мурашки и холодный пот по телу, потому что мы просто клей между двумя Клодами. По факту решений минимум. Есть некоторые тонкие вещи, где, блин, да, реально: давай это не будем делать, давай это тикет заведём, а тут пошли. Но это настолько такая, знаешь, сверху какая-то надстройка, а ресурсов тратится неимоверно, и времени тратится много. Вопрос: что происходит и что с этим делать? Вот это то, как выглядит, например, у меня там на одном из проектов такая работа. И по идее я должен был прийти, и всё должно было заколоситься, и мы должны фигачить в продакшен за два часа новые фичи, а мы вот этим занимаемся. Мы Клодов между собой дружим.

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

[42:04] Александр: Да-да-да.

[42:06] Антон: Вот. Может быть, возвращаясь немножко опять к работе с кодом. Вот у нас были — они ещё и есть, но для многих уже были — IDE, где главной, центральной работой всегда была работа в редакторе. Вот код, мы что-то там руками делали. Если редактор перестаёт быть центром вселенной, или центром этой IDE, и центром становятся какие-то другие функции — мы как индустрия сейчас пришли к такому интерфейсу, чат-интерфейсу, который мы сейчас наблюдаем в Codex, в Copilot, в Cursor третьем, JetBrains Air примерно про это же, ну и так далее. То есть там примерно всё. У тебя как это выглядит? Чатик. У тебя есть доступ к сессиям разных агентов или своего только одного агента, в зависимости от того, что продукт предоставляет. И каким-то образом можно снавигироваться в код куда-то. Ладно, иногда надо посмотреть его в редакторе: посмотрел быстренько и схлопнул. Или диффки какие-то посмотреть тоже. То есть я вот, например, когда генерирую код агентами, у меня агент бежит, видно, что какие-то правки летят, и он говорит: я там поменял тебе код вот в этом классе, каким-то образом написал что-то. И вот мой стиль работы такой, что, когда я вижу такую правку, я её открываю и смотрю диффку. Диффку — потому что она только локальная. Я не хочу смотреть весь результат потом, после работы агентов, когда он закончил весь этот свой молотильный… вот это вот, когда он там пять минут молотил что-то, писал код, генерировал кучу файлов, и ты в конце видишь: вот у тебя там десяток файлов. По сути дела, это как ревью пул-реквеста, правильно? Вот только что отработал, вот у тебя новый код, ты на него смотришь, и это, по сути дела, пул-реквест. Потому что это дельта — дельта между предыдущим состоянием и вот начальным. И мне неохота вот это смотреть. Я когда смотрю на чат и там вижу какие-то интересные моменты для себя — потому что они никогда не происходят просто так, они всегда с каким-то комментарием прилетают из агента, — я вот хочу увидеть этот дифф и открыть его. Мой такой стиль. Может быть, кто-то ещё так делает, я не знаю. Ты, наверное, так не делаешь. Напишите в комментариях — вот в YouTube мы выпустим, — как вы смотрите вообще за процессом, как вы медитируете над кодом. Может, человек смотрит ютубчик в это время и отправляет вообще в бэкграунд агента работать, и всё.

[45:00] Александр: Вполне. Я тебе, наверное, расскажу, как я это делаю. Я всё-таки человек, который, по крайней мере, на продуктивности помешан пока ещё и верю, что в какой-то гонке можно куда-то прибежать. Поэтому у меня довольно специфический кейс. Я каждое своё действие рассматриваю под рефлексирующим вопросом: нужен ли я здесь сейчас? Или я могу чем-то более полезным заняться? С точки зрения продуктивности и моей производительности как юнита. И я пришёл сейчас к тому, что я программирую графы вместе с агентами. То есть я программирую себе фабрику, мультиагентскую, которая будет мне производить то, что я хочу, и на выходе будет максимально качественный результат для меня как для программиста, чтобы я минимум усилий тратил на просмотр, на валидацию перформанса, на поиск багов — на всё. На всё, на что я трачу время, я каждый раз такой: а что бы мне такого добавить в мою фабрику, чтобы я перестал в следующий раз это делать? То есть один раз я пошёл, такой: блин, а здесь вот контракт не соблюли на самом деле; надо было посмотреть всю OpenAPI-спеку, прогнать тесты со всеми возможными корнер-кейсами и на выходе найти дыры, и потом эти дыры залатать. Ну так давай я теперь создам юнит в своей фабрике, в своём графе, в пайплайне мультиагентского производства, чтобы там такой юнит был. И я вот сижу эти графы программирую. Просто очень увлекательная вещь, когда ты понимаешь, что это то же самое, просто на уровне агентов, что я делаю в базах данных, где всякие пайплайны строишь. То есть по сути тоже: у тебя SQL-запрос, он парсится, AST анализируется, трансформируется, оптимизируется и в итоге оседает во что-то. И вот я этот процесс трансформации делаю с задачей — чтобы она осела в пул-реквест в максимально оптимальном, качественном виде. Это то, как я делаю. Соответственно, я смотрю на конечный результат. Всегда на самый конечный. Ну, пока что это пул-реквест. Повышение качества каждого своего пул-реквеста сейчас моя первоначальная задача номер один. Вот мой юзкейс такой.

[47:03] Антон: Ну вот если мы как раз идём по задачам программиста — мы уже упомянули, что там… Можем сказать, что задача номер ноль, и она даже сильно не обсуждается, — это дебаггинг, который всё равно программист в большинстве случаев делает руками. Можно это делегировать агенту. Он к тебе — Андрей — приходил в гости, рассказывал, как теперь дебаггер можно использовать: либо самому, лучше, либо агенту вкинуть. То есть тут есть такой шажок дальше, что вот инструменты из IDE были бы полезны агенту. Это немножко положим на стек. А вторая из задач — это ревью кода: либо это диффы какие-то, либо это PR, либо это мёрж веток, может быть, тоже — примерно смежная задача. И нужны инструменты, получается, для работы с version control. Командлайн, не командлайн — какие-то нужны. Это задача. Да. А какие у нас ещё могут быть задачи? При работе с кодом именно.

[48:14] Александр: Да, при работе с кодом, вот как бы в этом инструменте. Давай я тогда со своей колокольни буду. Всё-таки у меня вот такой, наверное, один из самых максимальных уровней абстракции — ну, то есть полёт такой. Вот с высоты моего полёта следующее — это только автономные агенты, к которым я вообще не прикасаюсь. Они у меня есть, но пока мне не получилось построить такого агента, который вот прям будет хорошо делать, чтобы мне было так, как надо. Только утилитарные какие-то проблемы решает. Код пока нормально автономно писать не получилось. То есть всё-таки надо немножко смотреть. И вот на что я смотрю, что я вижу. Ну, во-первых, артефакт, с которым я работаю, пока что это Jira, или задача, или тикет, issue в GitHub. Да, то есть давай вот по артефактам вообще таким. То есть на вход пришло: issue в GitHub, Jira-тикет или созвон, на котором мы что-то решили. Вот об этом мало кто думает, но мы, вообще-то говоря, языком решаем, какие задачи надо делать, какие не надо. Можно записать созвон, сделать транскрипт, из этого транскрипта вытянуть решение.

[49:25] Антон: Абсолютно, да.

[49:27] Александр: Но мало кто этим занимается, потому что это вот костыли. То есть ты этот скрипт где, у тебя что-то локально должен запустить? Можно это скачать? Или ты своего какого-то агента со второго аккаунта затянуть на Google Meet? Это вот кошмар. Должен быть инструмент для того, чтобы речь переходила в постановку задачи агенту без участия человека. Вот. Наверное, это всё из тех артефактов, которые идут на вход. Ну, ещё есть мой какой-то внутренний процесс, когда я думаю. Я вот, например, когда ночью сплю, могу проснуться и начать думать: а как бы я хотел вообще свой продукт докрутить? Вот я там свою эту молотилку пулреквестов встрою, думаю: ой, как бы хорошо было сделать трейсинг для каждого агента, каждого его шага. Вот ещё бюджет, да, бюджет докрутить. Это всё у меня в голове. И вот мне нужен способ, как из головы дампнуть куда-то, чтобы это потом пришло на вход агенту. Вот это тоже интересная задача.

[50:24] Антон: Сегодня у тебя два пути есть. Либо это через рот выпустить, либо через руки. То есть либо сказать, либо напечатать.

[50:34] Александр: Да, но, вообще-то говоря, я могу ещё рисовать. Вот.

[50:40] Антон: Ну, это тоже через руки.

[50:42] Александр: Я к тому, что вот инструмент, да — куда я это буду писать? В Телеграм себе, в Saved Messages? Тебе в личные сообщения?

[50:48] Антон: На бумагу.

[50:50] Александр: Да, на бумагу. Ну, а потом я с этой бумагой что буду делать? Буду брать, фотографировать, делать AirDrop на комп, потом искать в Finder эту фотку и драг-н-дропом кидать в Claude Code? Я не буду этим заниматься. Если мы говорим про инструмент, то должен быть способ легко это куда-то дампнуть, и оно потом само попадёт к агенту, если это нужно. Ну, тачскрин — пальцем нарисовать на экране. Вот я думаю, что какой-то вот процесс… То есть я пока не уверен, что это что-то около Jira, только что-то такое, знаешь, адаптированное. Потому что если мы говорим про то, что я ещё могу быть такой не один вот в этом своём творческом процессе создания и генерации задач, а есть и другие люди, то хочется какое-то такое вот пространство, в котором мы живём и в котором есть артефакты, которые идут на вход агенту, и эти артефакты собираются из внешнего мира отовсюду. Вот. То есть теперь, после того как у меня Claude Code фигачит по десять тысяч строчек кода и делает на Rust какие-то невероятные вещи, я себя дебилом чувствую, когда сижу и в Jira текстом набиваю какую-то задачу. Ну, чем-то я не тем занимаюсь. То есть что-то должно быть более умное. Ну ладно, допустим. Или есть что сказать здесь?

[52:00] Антон: Это, наверное, в сторону… Есть такая область, называется «графы знаний», которые собираются из разных совершенно артефактов и как-то связываются и так далее. Ну, там можно… Хранилище там любое может быть, тот же Obsidian, да? Ну, как бы тебе вот важно именно то, что у тебя есть граф, у которого есть какая-то семантика. Артефакты как-то связаны между собой и так далее.

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

[52:47] Александр: Дальше нужно вот это, как я вижу с точки зрения своего завода. Мне нужно, чтобы этот завод вот эти артефакты, которые к нему на вход приходят, — сырьё это — начинал перерабатывать. И чтобы процесс переработки для меня был полностью автоматизирован, но состоял, как вот на заводе, из частей, каждая из которых может быть донастроена, заменена, проинспектирована: добавить больше токенов, более дорогие модели, больше мощностей сюда. Здесь у нас сейчас мы заготавливаем, не знаю, больше багфиксов, у нас security week, условно. То есть возможность вот этот процесс наблюдать и с ним работать. И диагностировать, в случае если мне это интересно. Прозрачность. Безопасность. Там внутри, вот в этом всём процессе, где-то есть код. То есть он там по пайплайну идёт. Была задача на входе, дальше она трансформировалась в первый код, его там поревьюили, его там трансформировали, там побенчмаркали, здесь его end-to-end тестами покрыли, а тут вообще на формальном языке описали и проверили, что он… Всё что угодно с ним может происходить, но это как сырьё, знаешь, как зерно, которое протекает по пайплайну. Хочу ли я иметь возможность взять и зачерпнуть это зерно? Вот так на руку себе взять и просматривать его: красивое зерно? Или тут что-то не то? В целом, как будто бы классная штука. И хотелось бы, наверное, иметь возможность. А потому что, понимаешь, для психического спокойствия. Мне кажется, что это важно: когда у тебя по заводу что-то идёт, ты бы мог посмотреть внутрь и реально взять в руки и посмотреть, что вот да, это оно. Это примерно как ты сегодня заглянешь в Jenkins или в TeamCity, и там у тебя на интерфейсе красивый зипничек, и ты такой: блин, ну а можно взять его и развернуть? И посмотреть, что там внутри. Чтобы прямо вот в интерфейсе как бы нажал, и он тебе такой — и дерево нарисовал. И вот ты там, не знаю, help message в CLI обновил, ты взял его, развернул, прямо в классе посмотрел: вот мой новый текст в help message написан. Нафиг не нужно с точки зрения завода — он перемелет и доставит, — но человеку просто будет комфортнее, приятнее рядом с этой машиной находиться, если такая возможность есть.

[55:07] Антон: То есть инструменты или возможности для диагностики вот внутренностей нужны.

[55:12] Александр: Да, да, да.

[55:16] Антон: Что на выходе?

[55:18] Александр: Да, мне на выходе нужны артефакты. Уже в виде каком — кстати, тоже интересно, потому что как будто бы сейчас меня уже не интересует, будет это джарник, будет это бинарник или это будет Docker image. Мне главное увидеть: вот, как бы, если я делаю мобильное приложение — о, в мобилке тыкнул, обновился интерфейс. End-to-end, прям на самом высоком его уровне. Хочу ли я спуститься ниже, до уровня «а что за артефакт»? Ну, в целом я хочу иметь часть пайплайна, в котором этот артефакт как-то тоже докручивается, описывается и, ну, например, оптимизация размера Docker image. Вот есть у меня шаг в пайплайне специальный, который думает на тему, а как бы нам сделать поменьше Docker image. И туда возможность заглянуть тоже, типа, если имеется: вот посмотреть там слои в Docker, что за base image, какой у него размер, а почему у нас там от Node так много модулей скачанных лежит. Ну, просто поизучать археологию. Классно. Сам артефакт — ну да, хочу видеть его на выходе.

[56:25] Антон: Что ещё? Ну, ты, наверное, будешь искать доказательства того, что этот артефакт делает то, что надо.

[56:32] Александр: Да, то есть то, что получилось, оно делает то, что надо. А как я это… Вот что такое вообще доказательство в этом мире? То есть зелёные тесты — ну, come on. Все мы знаем, что тесты можно на моках написать, уж самый экстремальный. Все знают мемчик про два юнит-теста и ноль интеграционных. Ну, они банально могут даже не запускаться. Ну, короче, все мы знаем, что тесты — это такое. Но их отсутствие тоже странно. То есть они точно должны быть, но где-то там, в середине пайплайна. То есть не на выходе. На выходе какая-то другая верификация. Должна быть валидация. Меня лично, как инженера, который занимается разработкой баз данных, всегда интересует: а этот артефакт по перформансу как сейчас? То есть вот мы там… До этого у нас продукт, не знаю, на вот этой машине держал, не знаю, десять тысяч RPS вот таких запросов и потреблял столько памяти. А вот этот артефакт теперь как себя в тех же условиях ведёт? О, стали меньше памяти потреблять. А, так и задача-то была на самом деле сократить — за счёт, не знаю, обновления Java и использования compact headers, не знаю, там. Value types завезли. Ну вот, вот он результат. То есть я хочу понять end-to-end, что та задача, которая пришла, и тот артефакт, его описание — оно коррелирует. То есть вот это оно. То есть какие-то метрики. Метрики про артефакт. Это хочется иметь.

[57:55] Антон: Окей.

[57:58] Александр: Функциональная валидация? Вот я не знаю, а возможно ли такое? То есть вот, условно сказать, мы хотим, чтобы кнопка называлась по-другому и делала заказ такси из точки А в точку Б. Потому что раньше у нас была бага, что из точки Б в точку Б заказывается. Вот у меня по всему этому пайплайну пройдёт задача. Я на выходе увижу deployed on production. Вот я же всё равно, по идее, должен пойти сам дальше и сделать заказ этого такси, чтобы истинно, глубинно понять, что это оно. Или попросить кого-то, человека, чтобы он пошёл и сказал: да, работает. Могу ли я доверить агенту, что он скажет: слушай, я тут интерфейс протыкал, реально оно? End-to-end вот этот верификатор в каких-то случаях, наверное, могу. Потому что, опять же, ну не всё я могу.

[58:45] Антон: Ты же production этого доверил агенту. Почему ты не можешь верификацию пользовательского сценария доверить другому агенту, например?

[58:59] Александр: Хороший ты вопрос задал: если я как бы доверяю агентам в написании кода, в написании тестов и во всём-во всём-во всём, почему бы мне не доверить проверку end-to-end? То есть что кнопка делает именно то, что от неё требуется там на входе. В целом, если так ещё чуть-чуть абстрагироваться повыше, я бы доверил большинство валидаций агенту. То есть это то же самое, что нанять человека себе на завод. Вот ты построил себе завод, построил производство, но ты не можешь как предприниматель контролировать качество каждого твоего продукта и даже каждой новой версии этого продукта. Ну, просто у тебя есть более важные задачи. Соответственно, как решает предприниматель эту задачу? Он её делегирует. Находишь себе человека, и он отвечает за качество твоих продуктов. Найди себе агента, и он будет отвечать за качество твоих пулреквестов. В целом рабочая идея, да; сейчас она, наверное, малореализуемая, но я опять там на полёте каком-то фантазирую. То есть мне бы хотелось иметь вот возможность автоматической проверки. И с точки зрения инструмента, возвращаясь, да, — как бы это могло выглядеть вообще, чем бы это могло быть? Ну, понятно, что это какая-то визуальная штука, то есть я как человек не хочу читать много текста. Я хочу что-то всё-таки видеть. То есть какой-то вот, ну, условно, прям вот пайплайн, как вот, знаешь, в CI/CD раньше. А, ну и сейчас — я просто тоже редко смотрю. То есть вот шаги, да, вот по пайплайну прошло, там что-то несколько раз тут покрутилось, я хочу видеть стоимость этого, я хочу знать, сколько токенов сожрёт мой пайплайн. Вот. И возможность увидеть на конце и в каждый шаг углубиться внутрь. То есть расширить, детализировать, вплоть до логов, трейсов, дебагов, перформанс-профайлов. Вот насколько могу, настолько и хочу опуститься. Но постепенно.

[1:01:01] Антон: Окей. Ну, смотри, мы весь этот граф можем как бы по-разному крутить и раскладывать, как он визуально видится, да. Например, каждый шаг в этом графе — это агентская сессия. И если у тебя эти сессии представлены в интерфейсе и видна зависимость одной сессии от другой, то, в принципе, сегодня мы уже имеем эти интерфейсы.

[1:01:27] Александр: Ну, смотри, сессия всё-таки — когда мы говорим сейчас, в августе 26-го, мы подразумеваем сессию с одним агентом. Либо с Клодом, либо с Codex. Могут быть субагенты. Сегодня агенты… Недавно было анонсировано, что агенты могут посылать сообщения, какой-то новый протокол. Клод, по-моему, выкатил, да. Я очень мельком это заметил, но положил на стек, что агенты могут теперь между сессиями общаться. Наконец-таки. Ну, то есть вот прям я этого ждал, когда уже сделают хорошую вещь. Понятное дело, что я сам могу навайбить, но то, чего я хочу, и та проблема, которой я с тобой вначале поделился, — когда мы являемся прослойками между Клодами друг друга, у нас нет интерфейса для общения наших Клодов. Вот если бы я мог отправить какой-то реквест моему коллеге, типа: Сашин Клод сделал пулреквест, просит твой Клод его провалидировать. Да?

[1:02:31] Антон: Подожди, подожди, почему у вас нет? У вас есть GitHub.

[1:02:35] Александр: Нет, нет, нет. GitHub — это интерфейс, созданный для общения людей с людьми вокруг кода. Когда ты видишь вот эти портянки слопа от одного Клода другому, ты его через интерфейс GitHub не вывозишь, идёшь в свой Клод и пытаешься там понять суть. Значит, GitHub-интерфейс не работает.

[1:02:55] Антон: Ну, я про то, что оба агента, зная, например, как другого затегать, дать ему команду или отдать фидбэк, могут же использовать этот интерфейс. Точно так же, как ты туда пишешь в текстовое окошко: @claude или @copilot, почини вот эту фигню.

[1:03:15] Александр: Да, но это то же самое. Да, абсолютно ты прав. Но это как будто бы просто какая-то такая…

[1:03:20] Антон: Ну, костыли, хорошо, я согласен.

[1:03:22] Александр: Костыли прям, да, жёсткие. Хочется это вот всё вместе как-то соединить, вот так вот, какой-то трубой. Оно там быстро, оптимизированно решает, и на выходе уже говорят: мы тут договорились, потратили каждый по три ляма токенов, столько багов нашли, что-то его Клод как-то плохо. Вот он результат. Вот чего я хочу. И вопрос: зачем мне тогда Клод моего коллеги, если я могу со своим Клодом поднять вторую сессию? И ответ прост. Я прошу своего коллегу поделиться ресурсами. И это вот новая вещь, которую раньше мы, ну так, не рассматривали. Мне мало моего Клода: я бы запустил у себя этот граф на ночь, и он бы у меня весь мой Fable выжрал. Я не хочу.

[1:04:06] Антон: Ну, то есть это про бабки получается, да?

[1:04:09] Александр: Да, да. Как нам оптимизировать теперь? Я, типа, вместо того чтобы самому мержить и ответственность на себя брать, прошу человека своим умом немного инвестировать в мою задачу. По факту-то.

[1:04:23] Антон: Ну, сколько он там ума именно инвестирует? Скорее больше бабок инвестирует.

[1:04:26] Александр: Ну, времени.

[1:04:27] Антон: Ну, времени. Это ресурс. Всё равно, какая разница? Любой ресурс.

[1:04:31] Александр: Сейчас у нас новый ресурс есть: токены у каждого, бюджет токенов у каждого.

[1:04:34] Антон: Ну да. Окей, можем-то перевернуть немножко всю эту штуку на бюджеты, да? Вот как экономить? Есть глубокая вера…

[1:04:44] Александр: Что я тебе хочу сказать про бюджеты ещё от инструмента? Я хочу от инструмента, чтобы он мне показывал бюджеты.

[1:04:51] Антон: Бюджет. Ты не поверишь — а я не помню, я, кстати, может быть, тебе показывал. Я как-то прототипировал в начале года штуку, потому что был какой-то момент, когда все вдарились в эти канбан-доски, где агенты двигали бы тикеты, да, — визуализация как бы прогресса задачи. Мне показалось, это какая-то странная штука. Это как бы первая часть функциональности. Вторая часть функциональности — это вообще весь тренд на spec-driven development. То есть у тебя есть задача какая-то — откуда эти таски появляются? Не ты же их руками туда занёс, а они появляются как задачи какой-то общей задачи, чтобы сделать какую-то фичу в проекте, допустим. То есть я просто прототипировал такой веб-интерфейс, где была бы якобы входная часть, где мы ставим задачу, дальше эта задача каким-нибудь spec-driven-тулкитом разбивается на подзадачи, подзадачи кладутся на доску, и дальше есть команда агентов. Мне в тот момент казалось, что именно команда агентов, которые будут работать, — но мы сейчас с тобой дискутировали, что агенты могли бы общаться между собой, и, может быть, это всё равно была не самая абсурдная идея, как бы то, что я там нарисовал. И у меня была возможность составить как бы агентов по командам: какие-то аналитики, девелоперы, QA-щики и так далее, поставить между ними workflow какой-то, и вот получалась такая как бы фабрика. И я хотел тоже видеть на каждом шагу, сколько денег на каждый шаг тратится. Я такой интерфейс нарисовал, начал было интегрироваться, но потом я увидел, что куча проектов примерно то же самое делают, и у меня это осталось в GitHub валяться просто как такой даже не POC, а как концепт. Но я вижу, что во многих проектах в том или ином виде это появляется. Там Linear, например, начал делать свою штуку. Сегодня Slack что-то там анонсировал, ну и так далее. Есть в JetBrains некоторые проекты, которые пошли как спин-оффы. Я вёл к тому, сколько это всё стоит и что мы хотим именно от стоимости увидеть, потому что, наверное, самая главная вещь — это вот сколько мы тратим на то, чтобы получить результат. Неважно, каким образом. И вот есть поверье…

[1:07:29] Александр: Хорошо.

[1:07:31] Антон: Есть вера в то, что если мы что-то дадим агенту, что будет помогать ему решать задачу — ну, на разных этапах, может быть, в разных каких-то микроэтапах, — то это будет экономить токены. Есть куча всяких скиллов. Это вот эти вот всякие скиллы, которые там lazy programmer какой-нибудь, да?

[1:07:51] Александр: Да.

[1:07:53] Антон: Магическим образом начинает меньше токенов тратить.

[1:07:56] Александр: Ну, там сегодня был анонс того, что Claude Code сделал команду concise output, и он теперь меньше, типа, на output кидает текста и этим экономит.

[1:08:10] Антон: Ну, то есть вот эти все комьюнити — такие порывы или какие-то поделия — постепенно бывают замечены настоящим продуктом и как-то вот вводятся в продукт в том или ином виде.

[1:08:26] Александр: Это хорошая, кстати, тема, и она на самом деле важная, потому что, смотри, я почему для себя это постоянно отмечаю. Вот я хочу что-то построить с Клодом, поверх Клода — или с Codex, — чтобы оно было более эффективным. Допустим, какой-нибудь… вот первое: год назад я self-review делал плагин, чтобы просто банальная идея — в отдельном сабагенте, в отдельной сессии проревьюить то, что есть, с каким-то новым свежим инпутом, а не засранным контекстом от имплементации, собственно. Отлично. Но, не знаю, через два месяца это появилось в Клоде. Он начал ревьюить и делать сабагента. То есть всё, что ты делаешь, что действительно имеет смысл, надстройки — они естественным образом перетекают потом в Клод, потому что, во-первых, им это выгодно, они поглощают: зачем им плодить конкурентов, условно, какой-нибудь плагин, надстройку для чего угодно над Клодом, если это может быть частью Клода. Это суперлогично. А во-вторых, они ищут юзкейсы. То есть они на таком рынке, технологии и мире, где они вообще не знают тоже сами, что вот прям конкретно надо сейчас. Они это изучают через нас, видят, что большинство людей начали делать свои DAG’и — теперь мы должны DAG’и внутрь и лупы сделать, чтобы по факту меньше спрашивать и больше результата. Через год, через полгода будет это всё в Клоде, естественно. Вопрос: а что нам-то тогда остаётся делать? Мы можем просто посидеть и подождать Клода и получить всё самое лучшее, оттестированное, от ведущей компании. Или пытаться делать что-то своё, какие-то свои инструменты. К вопросу о вот этой нашей с тобой дискуссии об инструменте: а может быть, это станет просто частью Клода?

[1:10:10] Антон: Скорее всего.

[1:10:11] Александр: Может быть. Может быть.

[1:10:14] Антон: Ну, если мы эволюцию Codex тоже посмотрим, как у них эволюционировал интерфейс, — они тоже, по сути дела, строят IDE. Я думаю, что примерно через год мы увидим там совершенно новую реинкарнацию IDE. Вот в том, что сейчас, вот как чатик, там уже диффы есть, там уже бранчи поддерживают.

[1:10:38] Александр: Да.

[1:10:39] Антон: И кто-то из инженеров или продакт-менеджеров Codex — я их всех по имени не упомню, я просто на многих из них подписан, — кто-то из них сказал, что мы на самом деле строим IDE. Ну, по факту. Как бы всё куда идёт — мы строим IDE нового образца. Вот.

[1:10:57] Александр: Это ладно. Смотри, вот мы говорили про стоимость и что делается для стоимости. Вот первый там вариант — это скиллы, да, которые якобы оптимизируют как-то потребление токенов. Там каждый раз, когда новый вот этот какой-то скилл выходит, все тестируют: кто-то говорит, у меня сэкономилось 10% токенов, у кого-то там сэкономилось 60%, но кода не нагенерировал. То есть это всё нужно бенчмаркать, и каждое новое поколение моделей, каждая новая версия модели пользу от этой штуки нивелирует. Так или иначе. Вот. То есть — а может и хуже делать, да. То есть тот же Борис в каком-то интервью заявил, что вот вы обмазались всякими инструментами, скиллами, MCP-шками, а вышла новая модель — там, условно, не знаю, пятый Opus, — выкиньте всё, что у вас там для 4.8 поставлено, и вы увидите, что многое из этого вам уже и не нужно. И тогда снова достраивайте, что вам нужно. То есть это такая гонка, или борьба с ветряными мельницами, когда вы делаете ставку на то, что вы будете производить какие-то тулы, или скиллы, или, не знаю, MCP-серверы для агентов, которые якобы будут экономить им деньги. Они будут экономиться на каком-то отрезке — пару месяцев, пока новая модель не вышла. Дальше выходит новая модель, и ваши тулы становятся либо непригодными, либо не нужны, либо делают хуже самой модели. То есть вообще вся идея того, что давайте давать инструменты моделям или агентам, — вроде логично, а вроде, если так подумать, это гонка, которую очень трудно поддерживать. Это я, наверное, веду к тому, что, допустим, давать LSP агенту — что-то от этого агент всё равно будет получать, но этот LSP можно, наверное, уже на коленке сделать просто по каким-то примерам, по каким-то существующим наработкам. А как произошло, например, — смотри, есть же пример. Вот раньше, когда модельки совсем были слабые, во времена Sonnet, когда ещё Opus 4.5 не было, я такой: а вот как круто я придумал! Короче, я сейчас с агентом напишу скрипт, оттестирую его и потом буду просить других агентов этот скрипт запускать, чтобы делать какую-то утилитарную, каждый раз выполняющуюся задачу. А сегодня агент сам эту штуку пишет в момент работы. Он под ногами программирует себе целые системы с тестами, и просто one-shot задачу: он себе напрограммирует всё, что хочешь, запустит это, оттестирует, потом решит с помощью этой автоматизации основную задачу, выкинет это, и в следующий раз, если что, заново напишет. Вот что делает сейчас агент. И я тогда, год назад — ну ладно, полтора, — сидел и думал: как круто. А сейчас эта модель уже сама сожрала это всё и на десять поколений вперёд ушла в этом. Соответственно, действительно, ты говоришь…

[1:14:28] Антон: Смотри, было бы дешевле, если бы он этого не делал, а сразу же брал бы готовые инструменты, правильно? Это было бы дешевле с точки зрения потребления токенов, абсолютно. Поэтому давай следующий шаг: ну вот ты один раз себе написал — сохрани, переиспользуй.

[1:14:46] Александр: Ну, что уже делают модели? Они уже это делают. Если у вас долгоиграющие сессии, у вас инструментарий переиспользуется. Некоторые.

[1:14:57] Антон: То есть уже нет вот этого, потому что это логично. Но это всё, знаешь, следующая итерация вполне такого нормального растущего процесса. Вперёд. Что будет дальше? Наверное, эти тулы надо будет как-то шерить между собой, чтобы мной написанный тул и твой написанный тул для работы с гитом в нашем общем проекте были общими.

[1:15:17] Александр: Ну, логично.

[1:15:18] Антон: Ну вот, это логично. Давай сожмём ещё немножко эту штуку. Вот LSP. Тебе, например, Андрей показал LSP: найти символ, где используется, или снавигироваться куда-то агенту. Ну, скорее всего, это поиск — как бы поиск того, чего агент хочет найти. Здорово, LSP это предоставляет. Следующий логический и достаточный этап — это, типа, а давайте на этом LSP… чтобы LSP умел рефакторить. Давать функции. Рефакторинги какие-то делать, да?

[1:15:56] Александр: Да, ну, переместить там из одного класса в другой метод, например.

[1:16:00] Антон: Я бы даже сказал, что переместить класс в другой пакет, наверное, чаще бывает, чем переместить метод.

[1:16:06] Александр: Ну и чтобы это компилировалось, сразу работало.

[1:16:09] Антон: Ну, то есть он переместил и, соответственно, импорты везде поправил.

[1:16:13] Александр: Да, везде импорты.

[1:16:16] Антон: Метод двигать, честно говоря, не очень частый рефакторинг. Хорошо, он может случаться, но это не такая частая задача, мне кажется. Чаще может быть задача, например, какой-то результат инспекции, который говорит, что у тебя куча дубликатов в коде. Давай сделаем extract и везде заменим на использование этого нового метода, например. Вот это достаточно частая штука, потому что агенты любят дублировать код. Что ещё может быть? Ренейм, часто говорят. А зачем? Мне кажется, часто агент пишет код с достаточно нормальными именами, которые ты уже особо и не хочешь переименовывать.

[1:17:00] Александр: Ну смотри, есть же целый пласт продуктов, которые не написаны агентами и которым хотелось бы сделать ренейм.

[1:17:09] Антон: Ты просто вызовешь шорткат и сделаешь ренейм.

[1:17:15] Александр: А что такое шорткат? Ну, то есть агенту надо сделать.

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

[1:17:42] Александр: Да, абсолютно верно.

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

[1:18:18] Александр: Слушай, знаешь, какая аналогия? Вот я раньше… У меня, кстати, на канале где-то, по-моему, есть: matklad приходил в гости, Лёша, и показывал, как он работает с кодом. У него VS Code — это ещё было пару лет назад — VS Code с Emacs-биндингами, что-то такое. И он показывал, как он грепает и поиск по коду осуществляет более примитивными способами. То есть find, как бы generic find, да? Хочешь прыгнуть в метод, в его definition — берёшь, прыгаешь сначала вверх файла на импорт этого метода по символьному поиску, дальше копируешь то, что там есть, ищешь этот файл, в файле прыгаешь, и опять по этому поиску. То есть ты из комбинации трёх, четырёх, пяти просто find и jump по файлу решаешь задачу, которую тебе может решить LSP просто одним нажатием, да? Соответственно, если есть такой способ работы с сорцами, как комбинация грепов, седов, джампов, сиков, и с ними можно решить 99% задач, которые решает LSP, а агенты невероятно хороши в комбинировании грепов, седов и вот этого всего, — то действительно, не является ли LSP просто продуктом не того тира, то есть он для другого? И агенты работают со стандартными юниксовыми или с какими-то более примитивными другими штуками более эффективно.

[1:19:43] Антон: Ну, мне кажется, что всё идёт в ту сторону… Вот я до JetBrains работал в таком маленьком стартапе ZeroTurnaround, и мы делали JRebel, и мы делали XRebel, и это были наши основные продукты. Даже JRebel, да, — что он делал? Он делал hot swap на лету, чтобы программист не перезапускал приложение. Это, скажем так, продукт, который повышает продуктивность и вроде экономит деньги, но он не является абсолютно незаменимым. То есть он nice to have. И вот до сегодняшнего дня, до появления агентов, был какой-то список инструментов, которые программисту абсолютно необходимы для того, чтобы делать работу. И туда входили компилятор, соответственно, git — ну, то, что работает с version control. В какой-то момент можно было бы уже сказать, что CI обязателен, ну, там, issue tracker и IDE, соответственно, со всеми этими вещами. И вот, например, JetBrains как компания всегда производила essential-тулы для программиста. Куда ни кинь камень, любой из этих инструментов, любой из этих продуктов был essential для того, чтобы что-то делать. Да, там были альтернативы, речь не об этом. А сегодня вдруг внезапно, чего бы ты ни делал, редактор или что-то ещё, — это уже как бы не essential-тул. И даже для агента LSP не является — агент всё равно сделает свою работу. Потому что у него есть bash tool, у него есть file tool, что там ещё, ask user tool, — и там, по-моему, четыре тула каких-то было, которые типа были абсолютно необходимы для того, чтобы агент сделал все свои задачи. Вот.

[1:21:52] Александр: И тут вот дело с LSP примерно на таком же уровне, как со скиллами. То есть сегодня мы, вкидывая LSP, допустим, для Java, давая его агенту, экономим 20% токенов, а завтра уже 10% токенов, а послезавтра, может быть, и хуже делаем, я не знаю. Вот у меня какая-то мысль такая, что если мы агентам для работы даём что-то и туда делаем ставку, оно глобально, как я уже сказал, — это борьба с ветряными мельницами. А вот с другой стороны, когда уже агент отработал, — вот эта работа с результатом, она не подвергалась улучшениям 15 лет. Никак, ни в каком виде. Мне кажется, что вот там теперь будут essential-тулы находиться. Ну, как мы с тобой уже сказали, ботлнек сдвинулся, да? Вот там, где ботлнек, там essential-тулы, наверное. Я знаешь, как ещё это вижу? Вот с точки зрения просто больших компаний — ну, это OpenAI и Anthropic. Они настолько сейчас мощны, в моём представлении — я вообще не смотрю за этим, не слежу, — но у них столько сейчас мощности, что они могут сожрать кого угодно, кроме друг друга. Вот я так их вижу: как два динозавра в мире, и то, что у них на пути, — вот эти тулы, про которые мы говорим, — они их просто захавают. Вот сделаешь LSP — они сделают Клода, который будет LSP генерировать на ходу, и будет лучше. Сделаешь профайлер, не знаю, трейсер, оптимайзер — они его съедят через два месяца. Они всё на своём пути сожрут. Вопрос, где их путь, в каком он направлении, и как на нём не стоять, а быть где-то в том месте, куда они не пойдут. И вот здесь, мне кажется, интересная такая призма с точки зрения продукта и вообще приложения своих усилий. То есть как мне не конкурировать с OpenAI и Anthropic? Как мне сделать так, чтобы работать с моим инструментом в мире, где есть такие вот глыбы, было классно, удобно и essential, как ты, например, говоришь, или близко к тому?

[1:24:21] Антон: Ну, есть поговорка: знал бы прикуп — жил бы в Сочи. Или в любом другом удобном месте. К сожалению, я думаю, что ответа ни у кого нет.

[1:24:30] Александр: Да, но здесь вот в этом-то и интерес — как-то порассуждать. Потому что, ну смотри, какие у меня есть размышления. Я вот буквально недавно — у меня была бессонная ночь, и я подумал: а вот если я, компания имени меня, — что она хочет сделать такого, чтобы прославиться наконец-таки на весь мир и сказать: вот, он сделал это? Ну, что мне точно не стоит делать, а что, может быть, стоит. И я подумал: а какие ставки я делаю на то, какое развитие будет у всего этого дела, и где меня через год не сожрут эти два больших динозавра? Где я выживу? И я подумал, что какая-то история с некоторой… во-первых, мультивещью, ну ладно. Вопрос в том, что я пришёл к тому, что всё-таки как будто бы контекстное окно в ближайшее время маловероятно, что вырастет кратно. Оно всегда будет вот таким ограниченным. То есть да, оно может стать два миллиона в какой-то момент, но в целом как будто бы мы упёрлись в текущих технологиях, по ощущениям. Я вообще не эксперт, но люди вроде тоже сами говорят, что оно не будет в ближайшее время сильно расти. То есть я могу сказать: ага, вот здесь где-то, где контекстное окно бесконечно не будет расширяться, оно будет маленькое, — наверное, это комбинация контекстных окон. Это какая-то между ними оркестрация, соединение их, работа с другими контекстными окнами, в других местах расположенными. То есть какая-то вот такая история. Ну вот я начал строить, да, фабрику такую, независимую ни от чего, которая вот с контекстами как раз работает и как-то их настраивает. То есть узкоспециализированные контексты именно: ты — контекст, ты — сабагент, там, не знаю, на то, чтобы каждый pull request подвергать сомнению, что это максимально оптимальный код, с вот этим эффортом, например: чуть-чуть подумать, запустить, сделать доказательства, сделать оптимизацию, сделать оптимизацию с профилированием. Вот у тебя задача, контекст, — я знаю, ты с ней справишься, но у тебя она узкоспециализированная. А другой — вот, и комбинация вот этих вещей. То есть я для себя так подумал, что окей, вот контекст не будет расти, вокруг этого что-то можно подумать. Что ещё? Давай подумаем. Локальные модели и глобальная конкуренция — в том плане, что, ну, Клодами и Антропиками сыт не будешь, потому что всё-таки не везде их можно использовать. И это фундаментальное такое ограничение. Причём многие задачи, наверное, могут вполне и сейчас уже решаться локальными моделями, которые достаточно простые. Суммаризация какая-нибудь.

[1:26:50] Антон: Тоже верно. Ну, также можно сказать: если у меня есть Клод, я там простые задачи решаю Сонетом. И почти ничего за это не плачу.

[1:26:58] Александр: С Хайку, ты хотел сказать. Вот, положа руку на сердце, я ниже Опуса с high ничего не использую. Для любой тупой задачи у меня Опус с high. Но это я пока ещё не накрутил себе такой пайплайн, который будет сжирать подписку настолько быстро, что я задумаюсь о том, а может быть, всё-таки и Хайку начать использовать. Но, например, есть конфиденциальность банальная. Ну, то есть не можешь ты медицинские данные, если ты какая-нибудь поликлиника, передавать в Anthropic. Ну, не можешь. И куча таких примеров, и вот здесь что делать? То есть как сделать инструмент, который будет работать и с тем, и с другим, например. И как сделать так, чтобы он был essential. Вот тут тоже подумать. История такая: локальные модели — это круто. Вот. Визуальное что-то. Вот я, кстати, не уверен — как ты думаешь, вот эта история с тем, что мы сейчас в терминалах все живём с Клодами, и Кодексами, и OpenCode’ами, — она, ну, к чему может прийти?

[1:27:56] Антон: Ну вот ты сейчас сказал слово «все» — и как бы сразу же воткнулся в тот самый тезис, который мы с тобой в начале… Нет, не все.

[1:28:06] Александр: Ну, ладно. В чём там люди сидят? Ну, то есть, хорошо, — в приложениях?

[1:28:10] Антон: Ну, смотри, это, наверное, такая же самая история, как… ну, вечная, как мир. Кто-то предпочитал гитом пользоваться в UI, кто-то — из командной строки. Кто-то предпочитал настраивать NeoVim, а кто-то говорил: я — Notepad++, и всё тут. Например, по себе тоже могу сказать: я себя чувствую лучше в Codex Desktop, хотя у меня ничего на самом деле… ну, нет, даёт чего-то — лучше диффы мне даёт. Историю про диффы в терминале тоже можно посмотреть, там много чего интересного делается. Но я себя ощущаю лучше в UI, чем в интерфейсе для красноглазиков. Вот так вот — как Linux против Mac. То есть сказать, что все пользуются одним или другим, ну, нельзя.

[1:29:11] Александр: Все части меня, все мои десять субличностей.

[1:29:15] Антон: Но, но, но — я точно так же иногда беру, открываю терминал и сижу именно в терминале. Я даже не могу понять, от чего это зависит, — вот просто от положения звёзд. Лучше ли этот интерфейс?

[1:29:33] Александр: Наверное, потому что Claude Code просто впереди планеты всей — с его фичами, его инновацией. И он существует в терминале, и он там хорош — и ужасен в Claude Desktop. То есть Claude Desktop — ужасное вообще поделие, которое, ну, глючное просто. Хотя работает, но глючное. Я заметил, что я его почти не открываю больше уже. Хотя было время, я только в нём и сидел. Вот.

[1:30:01] Антон: Не знаю. У меня вообще такое ощущение, что, может быть, 2D-интерфейс — это вообще не самая лучшая вещь для работы с какими-то сложными системами. Но это совсем, знаешь, такая… типа, всё время кадр из «Джонни Мнемоника», из фильма, где Киану Ривз надевает шлем, берёт перчатку и начинает там кубики всякие крутить, вертеть, растягивать, располагать, чтобы какую-то информацию найти. Я слышал, что есть какие-то ресёрч-проекты по тем темам — VR как-то, работа с кодом и так далее. Но я сам никогда этого не видел, поэтому трудно сказать, что вот это на самом деле то, что когда-то должно произойти. Может быть, и нет. Я бы не хотел сидеть за компом в VR-очках.

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

[1:31:22] Антон: Вот ещё тоже интересная такая вещь. Вот IDEA — она же выполняла роль интерфейса к коду по большей части. Ну, то, что там редактор по центру был. Но сегодня ты возьми редактор замени. Вот у меня, например, уже есть вьюшка, где редактор как бы не является редактором. Ну, то есть там вместо редактора находится Codex, например.

[1:31:48] Александр: Вот, смотри, развиваем мысль. Там находится Codex. Codex — это что? То есть это чат-окно?

[1:31:53] Антон: С каким-то аутпутом сверху. Это может быть и терминал, на самом деле.

[1:31:59] Александр: А какой был бы essential-инструмент для работы с Codex, и кодом, и локальными моделями? Вот как бы он мог выглядеть? Возможно, что это вот то, что мы уже видели в некоторых местах.

[1:32:14] Антон: Для меня сегодня, наверное… у меня фантазия не работает. Мне нужен список сессий.

[1:32:21] Александр: Как чаты такие.

[1:32:22] Антон: Как бы, что я могу… Между этими сессиями как-то навигироваться. Я могу информацию…

[1:32:28] Александр: Ну, вкладочки такие, да?

[1:32:29] Антон: Да. Сейчас это дерево у нас, например. У нас новенький плагин на подходе, с заменой нашему поделью, которое существовало три года. И там у тебя сессии. Ты видишь, какие сессии из какого агента были. Ты можешь их пометить как законченные. Я не знаю, будет ли там какая-то передача информации между сессиями. Возможно, в будущем, если есть такая потребность, можно будет тоже такое увидеть. Группировка какая-то. Ну, то есть вот как ты с чатиками работаешь или с какими-то конверсейшенами, да? В том же Slack, например: у тебя слева куча каналов в Slack, и ты их как-то можешь группировать. Но это настолько базовые вещи, что сказать, что они прям сильно что-то революционно меняют, — как бы нет. Тут, наверное, надо исходить из задач.

[1:33:23] Александр: Вот, задач, да. То есть, а что такое задача? Давай ещё чуть-чуть даже с такого угла посмотрим. Я вот, когда на работе работаю, — мне психологически что надо, чтобы получить удовольствие, безопасность, спокойствие и уверенность? Мне надо, чтобы, во-первых, моя работа была видима, чтобы начальник понимал, за что он деньги платит. И чтобы то, что ты выпустил, работало. Ну, что это не слоп, то есть есть какой-то…

[1:33:59] Антон: Слоп тоже работать может?

[1:33:59] Александр: Не-не, я в плане вот прям чистый слоп, такой вот настоящий. То есть так-то всё можно назвать — любой output модели можно назвать слопом. Я слопом имею в виду просто мусорный выброс в output, который не нужен. В этом плане, кстати, к инструменту тоже: соотношение того, сколько токенов я потратил, и количества задач решённых, каких-то абстрактных задач. Это тоже довольно важная штука, которую, например, мой начальник хотел бы, наверное, видеть: вот Саша тратит 10 тысяч баксов, решает 10 задач в месяц.

[1:34:36] Антон: Это на уровне организации. Это на уровне организации, наверное, будет такой governance layer. Это то, куда сейчас многие вендоры на самом деле идут. Тот же Cursor, тот же… Ну, JetBrains тоже такую штуку делает. Кто там ещё? У нас вот было — Central. Central — это оно как раз про это и есть: чтобы понять, куда сколько денег идёт, и вот ты как индивид — сколько ты потребляешь. Дальше уже, наверное, вот эта важная мечта менеджеров — всегда замерить, сколько output каждый программист делает и сколько у него знаний в голове, как это понять и оценить.

[1:35:15] Александр: Bus-фактор его оценить.

[1:35:17] Антон: Либо bus-фактор, либо — вот раньше были такие проекты, которые пытались по коммитам определить, у кого сколько знаний о кодобазе.

[1:35:28] Александр: Экспертизу так померить.

[1:35:29] Антон: Да-да, экспертизу померить и важность этого человека для тебя. Это, правда, в модели очень хорошо ломается, когда у тебя два программиста работают одновременно над задачей и делают коммит из-под одного аккаунта.

[1:35:41] Александр: Не, ну смотри, это хорошая мысль в том плане, что здесь на самом деле оба заинтересованы: и организация заинтересована, чтобы видеть и понимать, куда она тратит деньги, и, условно, вот этому программисту готова платить X, а вот этому — 10X, потому что я понимаю, что он реально эффективней. Вот это понимание… И мне нужно тоже уметь организации объяснить, что я 10X.

[1:36:05] Антон: Ну, визуализация и доказательства тебе нужны.

[1:36:08] Александр: Да-да-да, то есть нужны какие-то метрики — вот эти потраченные токены, да. Но потратить токены… Давай я сейчас тебе граф запрограммирую: там у тебя анализ кодовой базы по циклу будет ходить, один стирает, другой генерирует.

[1:36:21] Антон: Счёт на AWS — миллион.

[1:36:23] Александр: За неделю.

[1:36:24] Антон: Легко.

[1:36:25] Александр: Вопрос целесообразности потраченных ресурсов: потрачены ли они по делу, настолько ли это дело важно, ведёт ли оно к целям бизнеса — или это что-то вообще ненужное для бизнеса происходит. Вот это всё понимать с точки зрения какого-то governance, или как ты это называешь. В этом много участников, и это может стать таким, ну, а-ля essential, близким к тому. Потому что у организации теперь по нормативам должен быть какой-то слой контроля качества. Типа у каждой организации есть слой контроля качества работы LLM и людей с LLM.

[1:37:01] Антон: Ну, я думаю… На самом деле не думаю, а знаю: вон Atlassian купил компанию DX. То есть в эту сторону большие организации на самом деле идут — они понимают, что предоставляют такой продукт или систему, которая будет позволять организациям вот эту отчётность как-то видеть: сколько они тратят, сколько у них продуктивности и так далее. Это важная мечта любого большого энтерпрайза. Сейчас, наверное, единственный, кто таким может похвастаться, — какой-то Microsoft, по большому счёту. Все остальные догоняют.

[1:37:40] Александр: Окей. Если в B2C развернуться — то, с чего мы начинали, для человека, — то я тоже заинтересован в том, чтобы результат моей работы был виден, был честным, и я мог потребовать, в том числе, чтобы мне за это платили справедливую оплату труда. Какой инструмент может такое делать? В современных, опять же, реалиях — или в будущих, через пару лет, куда мы стремимся.

[1:38:06] Антон: Мне кажется, сегодня это, в принципе, ты можешь сделать любым инструментом — взять Jira. Ну, тут будет очень сильная завязка на то, чтобы у тебя процесс был так построен, чтобы ты мог этот инструмент взять и увидеть сразу же. То есть мы говорим, наверное, что это на самом деле про отчётность.

[1:38:25] Александр: Отчётность. Слушай, ну хорошая отчётность, вот прям качественно сделанная, — понимаешь, в мире LLM это не просто отчётность как отписка, как бумажка, а это может быть один из инпутов модели. То есть теперь я своему агенту отчётность подключаю как один из харнесов, и он оптимизируется на этот счёт тоже.

[1:38:53] Антон: И учитывает его тоже. Но это опять, наверное, шаг в сторону — или по пути — в тёмную фабрику, dark factory. Где-то мы нащупаем какую-то грань.

[1:39:08] Александр: Ну вот, например, — вот чёткая грань точно. Я вот думаю, что контекстное окно не увеличится, и от этого можно что-то придумывать. Глобально не увеличится, то есть драматически. Визуальность. То есть end-to-end — мы идём к тому, что узкий инструмент, который, например, идёт вглубь: где есть дебаггинг, git, в базу данных сходить, вглубь покопаться, — мне теперь не надо. Мне теперь нужно чуть-чуть повыше. Вглубь у меня агент идёт. Я больше становлюсь таким менеджером и погонщиком этих агентов, построителем мультиагентских систем.

[1:39:49] Антон: Но вот, кстати, соединять агентов между собой и как-то их в графы объединять — это точно не essential. Это что-то такое… Ну, я сегодня возьму любой агентский фреймворк, в котором есть интеграция с LLM-ками и с тулами, и нарисую тебе этот граф, в принципе, не знаю, за вечер. Как бы вот и всё. И у меня будет такой harness, или а-ля агент, причём инструментом там может быть другой агент. Всю эту штуку возьму и на Koog напишу, или на Spring AI, или на чём-то ещё — какие там ещё есть другие фреймворки для этого же самого. Это точно не essential.

[1:40:38] Александр: Точно. Это что-то, что, кстати, в какой-то момент Клод уже начал делать — ну и Кодекс вроде тоже: HTML-репорты тебе генерировать. Раньше ты как-то сам просил его: слушай, я уже не могу читать этот markdown-файл, сгенерируй мне HTML-страничку с презентацией того, что ты сделал или что там происходит. И он тебе фигачит. А теперь это встроенная фича в Клоде: я ему пишу «сделай мне репорт», и он мне автоматически браузер открывает с репортом. Я его так проскроллил — и всё. То есть это встроилось. Соответственно, эти графы — это буквально следующий шаг после этих репортов. Ну что, хочешь меня с кем-то соединить? На, тыкни там, я тебе UI сгенерировал.

[1:41:21] Антон: Ну, или просто расскажи, что ты сделал.

[1:41:23] Александр: Да, у него будет типа визуализация его работы: вот в этом месте он где-то решил дописать код в твой проект.

[1:41:34] Антон: Окей.

[1:41:34] Александр: И вот эти динамические UI — это тема, которая будет на пути этих больших динозавров, как я себе это вижу. То есть они будут делать динамические UI. Что я имею в виду? Ну, очевидная у меня мысль: когда я работаю с Клодом, он мне сгенерировал HTML, какой-нибудь аудит, и говорит: вот я нашёл там 500 тысяч, не знаю, уязвимостей, вот их отранжировал — а что делать будем? Я такой: ну и что мне с этими 500 тысячами уязвимостей делать? Я хочу UI, сгенерированный на лету под мою задачу, который мне позволяет сортировать, выкидывать, говорить: это в бэклог, это сюда, это прямо сейчас делаем, это важно, а это вообще бред, никогда этого не делай. Я хочу тыкать в том результате, который он мне дал. Я не хочу ему текстом. Мы, кажется, докопались до сути: какая же роль у человека в этом всём процессе — это принятие решений или подтверждение вариантов. И я хочу инструмент для удобного принятия решений. То есть я не хочу ему текстом говорить: ты мне двадцать пунктов расписал, первый пункт — это, второй пункт — это. Да я это даже голосом не хочу говорить. Дело в том, что я хочу увидеть эти двадцать пунктов и вот так — тык-тык-тык, типа как plan mode сегодня. Интерактивный plan mode, сгенерированный HTML и CSS. Это будет через пару месяцев, я думаю, потому что это прямо очевидно — это то, что я бы сделал следующим.

[1:43:03] Антон: Но оно уже есть, как бы, на самом деле.

[1:43:05] Александр: Ну, это не… Он мне сам не предлагает этого. То есть я его должен попросить, настроить, сказать: я хочу, чтобы ты мне генерировал UI, в котором я кнопку нажать могу, и чтобы он это понял и дальше пошёл делать.

[1:43:17] Антон: Я думаю, если ты сегодня вкинешь скилл какой-нибудь, в котором это будет описано, он уже будет это делать.

[1:43:25] Александр: Через два месяца будет в Клоде.

[1:43:27] Антон: Да, через два месяца будет в Клоде.

[1:43:27] Александр: Да. То, что я говорю, — это то, что на пути этих динозавров. Что? Вот это. То есть нет смысла, наверное, делать что-то подобное сбоку, потому что оно станет частью агентов. Вот это — интерактивный UI.

[1:43:41] Антон: Соответственно, давай разовьём эту мысль. Если агенты пойдут по этому пути и начнут генерировать сколь угодно сложный UI под то, чтобы общаться с человеком, то нет смысла делать сколь угодно сложный UI-инструмент для агентов, потому что они сожрут тебя.

[1:43:59] Александр: Ну, они это сделают сами, да.

[1:44:01] Антон: Да. Они тебе сами сгенерят интерактивный JS, в котором попросят стрелочку провести между Клодом и Кодексом, нарисовать вторую стрелочку, из Jira соединить и сказать «run». Ну, типа, это будет. То есть не нужен для этого инструмент сейчас.

[1:44:19] Александр: Слушай, ну мы прям близко к этому миру, где ничего уже не нужно.

[1:44:26] Антон: Ну, один шаг остался, сказать уже…

[1:44:28] Александр: Ну, там всё уже — dark factory, и всё. Нет, я, конечно, хотел больше подискутировать про сегодняшние реалии — именно сегодня, ну или в перспективе одного года, например.

[1:44:42] Антон: Сегодня очень трудно говорить. Вообще вот этот классический вопрос на интервью — «где вы видите себя через пять лет?» — он стал совсем…

[1:44:53] Александр: Это уже оскорбительное какое-то.

[1:44:56] Антон: Да-да-да.

[1:44:58] Александр: Ну, допустим, всё-таки про сегодня. Если мы говорим, что сегодня нормальный — я нормальный, да — нормальный программист, который использует агентов, не просто посильно генерируя одну функцию, а работает с ними профессионально. Это значит, что использует скиллы, использует фичи этих агентов и так далее. Может быть, как-то работает по SDD, так называемому. Сильно не пишет код руками, но всё равно работает с кодом. Вот какие задачи он решает? И я ничего другого, кроме как ревью кода, проверка работы агентов, сегодня таким сильно выпирающим не вижу. Кроме — ну, там, переключение по бранчам, работа с version control, работа с интерфейсом для базы данных, например, — для некоторых может быть важно. Хотя и там ты можешь тулы для работы с базой данных дать агентам, и агент может тебе отвечать на вопросы.

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

[1:46:53] Александр: Хорошо, я сказал «нормальный», наверное, в моём пузыре.

[1:46:58] Антон: В твоём пузыре, да.

[1:47:00] Александр: В моём пузыре нормальный программист — который, ну, другим немного занимается.

[1:47:05] Антон: Но потому что мы с двух разных пузырей, например, можем даже и не найти общих точек соприкосновения, чтобы сказать: а, вот это надо делать. Потому что мне надо одно, тебе — другое.

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

[1:48:41] Антон: Ты хочешь узнать логику и последствия, наверное.

[1:48:45] Александр: Да, я хочу понять, что этот код делает, — именно это в голову загрузить, и ничего лишнего. Мне не нужны проверки на краевые случаи выхода из массива, мне не нужны ассерты, мне ничего этого не нужно в коде. Я хочу код очистить, но чтобы это всё ещё был код. И в этом коде иметь возможность углубиться до оригинального кода. В случае, если я такой: блин, а как у нас здесь этот файл лога берётся, ну-ка, дай-ка посмотрю, — я хочу посмотреть реальный код. То есть связь вот этого верхнеуровневого кода с глубинным и истинным. И если бы у меня был инструмент, который позволяет любой pull request, который ко мне пришёл, увидеть диффом высокоуровневого кода, и иметь возможность погрузиться внутрь, если я хочу узнать, и вернуться обратно, — и это всё было бы в одном клике друг от друга, — я тогда был бы готов нажать, принять решение: да, я готов это смержить, вперёд. И неважно, сколько времени я потратил, — я решил свою задачу. Боль-то какая? Боль — разобраться в том, что прислали. Вот какая-то такая штука.

[1:49:49] Антон: Я тебе могу такой немножко более детальный анекдот рассказать. Вот в IDEA у нас есть поддержка Maven, да. До прихода в JetBrains я засабмитил баг. Он до сих пор там есть, не починен. Про импорт Maven-проектов. И там ситуация такая, что непонятно на самом деле, как правильно её решать. В Maven можно написать версию Java — там Java version. Просто не было тулчейнов в то время; сегодня это с тулчейнами решается правильно. То есть в POM-нике пишется, с какой версией этот проект должен, в принципе, собираться. И при импорте, что бы там ни было написано, IDEA выбирала — и выбирает до сих пор — какую-то другую версию Java. Я не знаю, по каким правилам.

[1:50:50] Александр: Это боль. Это боль.

[1:50:52] Антон: Но сегодня это решается с тулчейнами. Ты тулчейн конфигурируешь, и оно правильно должно всё отработать. По идее. Я не проверял. То есть это было правильное решение проблемы. Но у тебя куча проектов, в которых тулчейн не сконфигурирован, но написана эта Java-версия, и нормальное ожидание пользователя — когда он импортирует этот проект, то он откроет его, он проимпортируется, и там будет правильная версия Java. Она, конечно, должна быть ещё на машине — в этом проблема. Ну и я такой: блин, вот классная штука, хочется сделать такой эксперимент. Могу ли я по своему процессу, вот так настроив агента, взять и починить эту штуку? Я же знаю, что я хочу. Я даже могу проверить результат, когда агент отработает: я запущу новую версию всей IDEA с этим патчем и проверю, правильная версия Java или нет. Я вот натравил агента, он там что-то нагенерировал, что-то поменял. Я запустил — всё работает правильно. А теперь я не знаю, я что-нибудь поломал или нет. Может, я поломал так, что другие проекты перестанут импортироваться. То есть вот эта проверка, что вроде как хорошо, — или общая summary над сгенерированным кодом, псевдокод, вот как ты рассказывал, — я могу принять решение, что это ок или не ок, имея какую-то экспертизу. А если я эту экспертизу не имею — даже вот, казалось бы, я вроде программист, я вроде работаю с IDEA, — я не могу проверить, поломал я что-то или нет своим патчем, чиня свою проблему. То есть всё упирается в то, достаточно ли хороша система, достаточно ли хорошо она была сделана — с тестами, которые не дают её сломать, как-то так. Вот это дилемма. Я прям не знаю, как с ней быть. Да, можно сказать: агенты все станут умными, они все эти кейсы тоже починят. А у нас куча legacy-софта, про который никакой агент не может знать, как его чинить или как изменять. И принять решение может только человек, который на самом деле знает систему. Как знание системы получить? То есть мы постепенно становимся таким контингентом, как COBOL-программисты, которые, выйдя на пенсию, всё равно зарабатывают себе на яхты.

[1:53:45] Александр: Очень хотелось бы к такому прийти, потому что молодое поколение не будет работать, а мы будем работать.

[1:53:50] Антон: Может быть, погружаться внутрь систем и знать архитектуру продуктов, проектов и так далее. Но даже сегодня ты не можешь вот так просто по рельсам кинуть агента работать над legacy-системой. И это, на самом деле, такая подводочка к тому, что мы с тобой в пузырях находимся. Ты в своём, я в своём, но мы более-менее на острие, я думаю, в каком-то смысле. А данные показывают, что adoption в энтерпрайзах где-то на уровне, не знаю, 5–6%. Ну, по разным причинам: где-то по security-причинам, где-то по legacy-причинам, где-то по, я не знаю, каким ещё — по костам или ещё чем-нибудь. И я, оказывается, не так сильно внедрён в общую разработку. Это удивительно, когда ты действительно смотришь вокруг. Я вот буквально недавно тоже был в большой компании, посмотрел, как там люди программируют. Да, то есть по-другому всё. И для них-то инструменты вообще другого рода нужны.

[1:55:02] Александр: Возможно. А может быть, не нужны. Может быть, догонят.

[1:55:06] Антон: Ну, как бы… Другого рода — они программируют, как программировали пять лет назад. Или как до ковида.

[1:55:12] Александр: Ну да, да. У них есть уже путь.

[1:55:15] Антон: Да, он уже есть. Его можно немножко улучшать — там более умные инструменты. Но если они в том же workflow находятся… А вот мы с тобой сейчас больше дискутируем про то, что workflow вообще поменялся.

[1:55:33] Александр: Когда код не становится центром в твоём IDE.

[1:55:37] Антон: Абсолютно.

[1:55:38] Александр: Ну вот контроль качества. Все мы про это говорим, говорим, говорим — и нет чёткого решения. Ну вот ты показал пример, где ты действительно взял кусок большого софта, переделал какую-то часть, посмотрел на эту часть, сказал: круто, работает. А дальше что? А дальше что? То есть я тебя прекрасно понимаю: в базах данных это же сплошь и рядом. Да, я здесь оптимизировал; да, я здесь поддержал новый индекс. А у клиентов после апдейта данные не сотрутся после этого случайно? Или там out of memory не случится, потому что мой индекс стал больше памяти потреблять из-за моей оптимизации? Может, оно тогда вообще и не надо — ничего не трогать: работает, и слава богу. То есть такие мысли тоже приходят. И тут, да, как развивать софт в реалиях, когда ты не можешь, откровенно говоря, полностью загрузить все детали себе в голову — у тебя нет ни времени, ни ресурсов, ни возможности. Просто никто не будет платить человеку большие деньги за то, чтобы он сидел и понимал, как она работает. Потому что таких вакансий — ну, 0,001%. В абсолютном большинстве — я думаю, слушателей в этом больше всего находится — да нет, ты не можешь, ты не можешь всё знать. Может ли агент всё знать?

[1:57:02] Антон: Он точно не знает.

[1:57:03] Александр: Ну подожди, агент ничего не знает. LLM-ка знает, да.

[1:57:06] Антон: Ну да, да, я имею в виду. Вот смотри, если мы берём контекстное окно, которое не будет разрастаться, то всё-таки весь проект в него не засунешь.

[1:57:14] Александр: Ну да, по-любому. Тут, соответственно, какой-то… Вот как бы я сейчас разработал агента: он берёт проект сверху — так его сажаешь, и он берёт и говорит: не знаю, дай мне 12 часов и 10 миллионов токенов, я сейчас буду изучать. У меня есть специальный процесс того, как я составляю базу данных о проекте. Он весь git посмотрит, все трекеры, все pull request’ы, он посмотрит, естественно, всю кодовую базу, все изменения, построит свой какой-то vision — и дальше будет что-то про код знать. То есть некоторую экспертизу он построит, положит в какую-нибудь локальную базу данных, сделает для неё быстрые запросы, и вот теперь, когда ты ему ставишь свою задачу, он будет из этой базы знаний говорить тебе: а вообще-то тут было три поломки продакшена, я это из коммитов узнал. Ну, то есть какую-то экспертизу он может извлечь из того, что ему можно дать.

[1:58:15] Антон: Достаточно ли этой экспертизы, чтобы такому агенту сказать: ну, раз ты сделал — значит, go, в продакшн? Наверное, всё-таки нет. Всё ещё ответственность — по рукам-то кому дадут?

[1:58:28] Александр: Ну да, чья ответственность? Да, естественно, мне. По крайней мере, мне ночью вставать и чинить. Агент не встанет ночью — он, строго говоря, и не спит. Но вот что мне нужно такого, чтобы это принятие ответственности было максимально комфортно? Для меня.

[1:58:52] Антон: Ну, только если любые эти самые издержки покрывал бы Anthropic.

[1:59:02] Александр: Ну, как вариант, да: ваш Клод написал тут код, который мне положил базу данных у клиентов, и теперь вот я…

[1:59:09] Антон: Кроме шуток, так же было с Copilot, когда на повестке дня был, наверное, самый горящий вопрос о том, что код, который генерируют модельки, — это чей-то код, авторское право там или что-то ещё. То в лицензии у Microsoft было написано ровно так: если к вам пришли юристы другой компании с претензиями, что вы украли у них IP, который на самом деле нагенерировал Copilot, то Microsoft берёт на себя ответственность.

[1:59:45] Александр: Слушай, я вот не знаю насчёт ответственности. Мне кажется, это путь в никуда — в плане того, что такого не будет. Вот история, которую ты рассказывал, — наверное, такое возможно. Ну да. Всё-таки мы, как люди нанятые, пришедшие со своими Клодами, Кодексами, локальными LLM, мы должны принимать ответственность. И нам нужен инструмент, чтобы эту ответственность принимать было проще. Я как человек, который что-то деливерит, хочу, делая свою работу… Вот я знаю, что через десять минут собираюсь домой, у меня уже голова настроена на то, что я перестал работать. Я нажимаю свою последнюю кнопочку, говорю: всё хорошо — и ухожу. И у меня не должна больше болеть голова о том, что ой, пройдёт там CI или не пройдёт. А вдруг завтра с утра приду, а мне коллеги напишут: из-за твоего упавшего CI мой агент никак не шипит. Не хочу я такого.

[2:00:42] Антон: Да. Мы все не хотим. Что за инструмент такой?

[2:00:48] Александр: Ну, то есть нажатие на кнопку должно под собой что-то такое иметь, что даёт мне эту уверенность. Естественно, там все CI прошли, не знаю, я могу это увидеть. Какой тут такой высокоуровневый инструмент, где я вижу по пайплайнам, что всё прошло, всё зелёненькое… А по сути тогда зачем я нужен, если всё это прошло? Мне что, вот кнопку нажать? Ну, пускай она сама нажимается.

[2:01:18] Антон: Ну, видишь, мы сейчас с этой дискуссией докрутились до того, что на самом деле это примерно такая же модель, как была, не знаю, десять лет назад, когда всё это DevOps-движение шло: менеджер, например, принимает решение, что пора новую версию продукта раскатать на прод. И видит в этом пайплайне, что все тесты пробежали, что всё хорошо, что там три аппрувала стоит — от QA, от кого-то ещё. Сейчас неважно, кто этот QA — человек, агент или какие-то автоматические тесты. Но вот эта уверенность должна быть. И я вижу, что сейчас…

[2:02:02] Александр: Хотя он не знает, как код работает.

[2:02:04] Антон: Да, он же не знает. Он в код не смотрел.

[2:02:08] Александр: В этом прикол, да.

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

[2:03:25] Александр: Ох, это интересно. А если мы говорим про инструмент — может ли быть такой инструмент, который подготовит проект?

[2:03:32] Антон: Тесты написать в IDEA вручную?

[2:03:34] Александр: Делать нормально, да?

[2:03:35] Антон: Делай хорошо — и будет.

[2:03:38] Александр: Делай нормально — нормально будет. Ну вот, кстати, это очень интересно. Мы инсайт такой откопали про девопсов, про SRE-инженеров, которые код никогда не читали, но вся ответственность на них.

[2:03:52] Антон: Да. Ну, или на менеджере, который кнопку нажимает, чтобы всё раскатать.

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

[2:04:22] Антон: Отсутствие знаний.

[2:04:25] Александр: Они вообще, да… То есть если что-то сломается, они даже не поймут что.

[2:04:28] Антон: Ну да. То есть ты, зная, как система работает, что в коде или в системах могут быть вот такого-то типа ошибки, какие-то ограничения, какие-то корнер-кейсы, — ты уже знаешь слишком много о низком уровне, и ты просто не можешь поверить, что кто-то всё это закрыл. Ты всегда знаешь, что там есть проблемы. А менеджер или SRE, который принимает вот это решение, думает немножко на другом уровне и не может предположить, что у тебя там выход за массив где-то может случиться.

[2:05:08] Александр: Где-то там тест не написан, да?

[2:05:10] Антон: Да-да-да.

[2:05:10] Александр: То есть меньше знаешь — лучше спишь.

[2:05:14] Антон: Абсолютно. Во-первых, потому что отсутствие знаний действительно позволяет принимать ответственность более легко.

[2:05:23] Александр: Да, действительно. Но вот если ты слишком много знаешь, то знаешь, что́ может здесь тоже помочь принять ответственность. Причём что мне, кстати, помогло в последнее время: когда вышел Fable, я запускаю Fable на существующей кодовой базе, которая работает, — ну вот это прям прод. Он там находит столько проблем, если его реально запустить, дать покрутиться и ставить задачу: он говорит — слушай, если у тебя вот здесь такое случится, будет out of memory. Ты когда понимаешь, что в той системе, за которую ты принял ответственность и в которой ты сейчас уверен, что она работает, есть такие баги, — ты такой: ну, работает же. Ответственность принял, баги есть, баги будут всегда. Вопрос в том, насколько они критические, насколько они вообще на функциональность влияют, какова цена этих багов, если они выстрелят, какова вероятность их исполнения — когда они вызовутся. Вот что новое, потому что раньше я, по религии протестировав и пройдя всё, думал, что в этом коде багов нет. Ну вот у меня такая иллюзия была.

[2:06:22] Антон: Они есть всегда. Давай, чтобы страшнее стало, подумаем, что модные программисты займутся софтом для самолётов.

[2:06:32] Александр: Ну, так и люди же… То есть ты говоришь: давай будем вайбить софт для самолётов — сколько тогда начнёт падать, да?

[2:06:39] Антон: Ну, просто иногда становится страшно. Даже без того, чтобы вайбить.

[2:06:48] Александр: Слушай, я на самом деле вот так тоже думаю. Ну, ты же летаешь на самолёте — ты не знаешь, какие люди там софт писали. Я одного видел воочию, но мне кажется, это какая-то вообще другая каста людей. Я, например, ходил на доклад человека, который руководил отделом написания софта для спутников. Там тоже есть баги — спутники падают, и с людьми там могут… Но они строят систему таким образом, чтобы наличие бага не приводило к полному отказу. Потому что баги будут. Это решается дублированием разных систем, разных классов систем: одна система может решать задачу другой. Их там три, как правило, а то и четыре. Может быть, в эту сторону подумать, кстати говоря: если нам строить софт, исходя из предположения, что этот софт — для самолёта. Вот что ты сделаешь, чтобы на твоём сервисе на вайбе можно было летать? Попробуй подумать про эти точки отказа. Ну, например, разные версии сервиса держать всегда, чтобы, если в новой выкаченной версии внезапно в чёрную пятницу этот баг случился, ты быстро мог откатиться на старую, деградировав по функционалу, но продолжая обслуживать критическое. Какие-то такие, знаешь, новые углы построения софта, под которыми мы раньше особо не думали.

[2:08:16] Антон: Тоже… ну, это интересно. У меня здесь аналог есть, не совсем про софт. Мы сейчас записываем видео в студии довольно часто. И у нас на канале эти видео уже начали выходить с начала лета. Видео в таком формате, что два человека в студии — гость и хост, и гость показывает демку. То есть он что-то на своём экране делает, это не интервью. И конечный результат — это видео двух людей: либо у них совмещён экран, либо они по отдельности, и, собственно, скринкаст с того экрана, который у гостя. Мы записали на данный момент около десяти эпизодов. Не было ни одного эпизода, чтобы где-то что-то не сломалось. И оно каждый раз ломалось по-разному. Просто каждый раз ломалось. И точки отказа были самые разные: от сервиса записи, от жёсткого диска, от камеры, электричества. В последний раз мы записывали про Spring AI. Всё хорошо шло — до какой-то минуты, где вдруг у него перестал шариться экран. Вот просто перестаёт шариться экран, и всё тут. Оказалось, что у него переполнился диск. Софтина, которая шарит экран через сетку, делает локальную запись — вот ты используешь Riverside, мы использовали StreamYard. И когда сторидж у тебя переполняется, локальная запись перестаёт туда писать, и он теряет скриншеринг. То есть я сидел со вторым лаптопом, и у меня вдруг всё тёмное стало — я перестал видеть его экран. А я напротив него сижу и хочу видеть, что он показывает, я для этого его использовал. То есть, казалось бы, не самая трудная задача: посадить двух людей в студии, направить на них камеру, раздать экран — и пускай говорят. Десять выпусков — десять плюс падений, отказов того или иного рода. А возьмёшь какую-то софтварную систему — базу данных возьмём. Там, наверное, способов отказа просто…

[2:10:45] Александр: В разы больше. На порядки.

[2:10:47] Антон: Да, абсолютно верно. И ты про них не знаешь. Самое страшное — что ты не знаешь, чего ты не знаешь.

[2:10:57] Александр: И выяснить до какого-то уровня… Уровень оптимизации тоже — в алгоритмах очень часто: ты оптимизируешь что-то, но не знаешь, где максимум этой оптимизации. И ты такой: ну, good enough. И потом всё равно — ты обложился, везде постелил соломки…

[2:11:15] Антон: Постелил, да, ифов понаписал и так далее. Вроде у тебя всё уже покрыто. И ты там через неделю эксплуатации узнаёшь ещё что-то новое о своей системе.

[2:11:27] Александр: Очередное какое-то падение.

[2:11:29] Антон: Да. Иногда, знаешь, забравшись на ту точку, с которой у тебя теперь прошлых проблем нет, ты наконец-таки видишь новые. Потому что за прошлыми проблемами ты других не видел.

[2:11:40] Александр: Да-да-да. И мне кажется, весь этот софтвер-инжиниринг — он очень чем-то похож… Похоже всё. Мы не знаем, какие новые проблемы сейчас появятся вот с этим всем. Мы узнали, что у нас ревью — большая проблема.

[2:11:54] Антон: Оказывается, да?

[2:11:55] Александр: Да. Ну, просто она была — та же проблема, — но не была такой кричащей.

[2:12:02] Антон: Наверное, мы скоро узнаем какие-то новые грани этого всего дела.

[2:12:09] Александр: Да, я думаю… Давай, может быть, к концу можно пофантазировать уж совсем. А какая следующая проблема? Решим мы проблему ревью и сделаем так, что ревью не будет вообще в процессе.

[2:12:21] Антон: У меня есть про это заход.

[2:12:23] Александр: Хорошо.

[2:12:23] Антон: Вот сегодня мы сделали волшебную кнопку, которая идеально делает фичу. Ты нажимаешь в агенте: сделай всё хорошо — на выходе идеальная фича без единой ошибки. В таком процессе много ли у нас знаний появляется, чтобы эту систему сделать? Качественно поддерживать? Что мы узнаём про эту систему, если мы только нажимаем кнопку?

[2:12:55] Александр: Ну, то есть он становится совсем чёрным ящиком.

[2:12:58] Антон: Ну, то есть условно…

[2:13:00] Александр: Да, я понимаю: любая фича может по взмаху волшебной палочки стать реальностью.

[2:13:07] Антон: Да, у тебя станет… Сегодня уже этот вопрос часто встаёт: наработка экспертизы.

[2:13:14] Александр: Да.

[2:13:16] Антон: В чём экспертиза? Экспертиза — в знании системы, как она работает.

[2:13:21] Александр: Можно сказать, что… А зачем?

[2:13:24] Антон: Да, это самый лёгкий аргумент.

[2:13:27] Александр: Я думаю, найдётся… Ну, смотри. Да, интересный мыслительный эксперимент. Если оставаться в рамках него, то всё-таки, понимая, как устроены компьютеры и их ограничения, — ну, например, ты в момент…

[2:13:43] Антон: То есть что тогда — какая задача твоего участия? Задача человека?

[2:13:46] Александр: Ну, соответственно, формулировать фичи. То есть ты такой: вот сделай вот это, сделай вот это, сделай вот это. Соответственно, понимание того, что сделать можно, что нельзя, сколько это займёт времени, токенов…

[2:13:59] Антон: Не знаю, да, окей, мы сейчас не говорим про время. По взмаху волшебной палочки.

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

[2:14:44] Антон: Точно.

[2:14:44] Александр: Иначе ты будешь составлять то, что нереализуемо. Или будешь составлять то, что слишком дорого и не имеет смысла.

[2:14:51] Антон: Тебе этот чёрный ящик может сказать: подвези серверную стойку, воткни её — и тогда будет работать. Стоить будет…

[2:15:00] Александр: Ну да, он такой: это будет стоить двести, давай закажем. Я уже набросал тебе корзину в Амазоне, хочешь — закажем.

[2:15:10] Антон: Ну вот опять мы пришли в этот мир, где…

[2:15:13] Александр: Да.

[2:15:14] Антон: Но вот просто даже сегодня, на сегодняшний момент, допустим, у нас AI был бы отличный, и нам бы сказали: ну всё, ребят, в IntelliJ теперь вы можете починить с AI все баги. И мы бы такие пошли в YouTrack: первый — бац, второй — бац, третий — бац, все баги начали бы чинить. У нас в какой-то момент были бы баги починены, и мы бы ничего не знали про… продукт. Внутри. Ну то есть наши знания очень сильно устарели бы.

[2:15:50] Александр: Так. Ну да, в какой-то момент просто перестаёшь понимать вообще, что там происходит. Ну что это?

[2:15:56] Антон: Угу. Ну то есть я такие эксперименты сделал, где генерировал проект по какому-то флоу, а потом понимал, что я даже его не могу протестировать. Ну, сам проверить.

[2:16:09] Александр: Я тебя прекрасно понимаю. Вот она будет… Я один раз, когда Opus 4.5 вышел, такой: всё, ну я демиург, пошёл. Короче, начал делать. Просто весь сервис от и до, end-to-end зафигачил, офигел тогда. Просто я через две недели вот так высовываю голову, смотрю на интерфейс, который я сделал, и такой: а что я сделал? А как этим пользоваться? Вообще, что это такое? Даже не то что как… Это что? Это какой-то просто франкенштейн, живущий в интернете, задеплоенный где-то на сервере. И я такой: ну, нафиг — и выкинул. Ну, как бы, было весело. Ну, я оставил, думаю, может, когда-нибудь дотянусь. У меня в гитхабе валяется проект.

[2:16:53] Антон: Проще с нуля, мне кажется. С текущими ресурсами проще просто описать задачу и за два часа, вникая на каждом шаге, — там, не знаю, за полдня — построить и понимать, как эта система работает. Чем, наверное, возвращаться к старым вот таким подпроектам, мне кажется. Ну, вот если говорить о том, что дальше происходит, что я вижу: я сейчас повально вижу вакансии для внедрения, которые не просто про то, что придите, научитесь, научите нас пользоваться Claude Code — там, не Claude Code, Codex, — а про внедрение на уровне организации с разных сторон. Про data governance, про стоимость, про какие-то флоу на уровне организации и так далее. На уровне организации, как я говорю, — я всё-таки про программирование больше. Не то, что нетехнические люди используют, но такое тоже есть. Там тоже будет интересное развитие ситуации. Наверное, опять какие-нибудь сервисы, которые могут тебе и отчётность, и рассказать, что происходит по потреблению и какой ROI у всего этого. Это тоже сейчас будет, наверное, такая большая тема. Но это всё равно не про работу программиста, это уже какие-то такие большие темы.

[2:18:33] Александр: Большие слои. Да, слушай, давай, наверное, финальный вопрос тебе задам. Обычно я даю свободный микрофон в подкасте — типа, что бы ты сказал слушателям, — но по факту у нас с тобой свободный микрофон был весь подкаст.

[2:18:50] Антон: Мы фантазировали.

[2:18:51] Александр: Мы фантазировали. А вопрос будет чёткий. Антон, ты как разработчик IDE, так или иначе…

[2:19:03] Антон: Ну, в каком-то смысле.

[2:19:04] Александр: В 2026 году, в августе. Ответь на вопрос, пожалуйста: нужна ли IDE?

[2:19:09] Антон: Нужна ли IDE? Хочется сказать, что нужна. Но я сам могу подтвердить, что в некоторых местах могу получить результат, не открывая IDE. Вообще никак. IDE, наверное, стала nice-to-have вещью для модных программистов, для какой-то части рынка. Она всё равно является essential. Мы в каком-то переходном положении сейчас, я думаю. И сейчас для тех, для кого это уже non-essential, — для тебя, для меня в каком-то смысле: если я какие-то свои личные проекты делаю, я, наверное, IDE не открою. Ну, или чуть-чуть. У нас у всех очень разные способы работы с агентами. Прям очень сильно они варьируются, спектр большой. Но через какое-то время, наверное, будет опять такая сходимость этих workflow, стандартизация. Это такой процесс, который проходят все технологические этапы — не знаю, архитектуры, языки программирования, компьютеры, всё что угодно. Когда у тебя есть много способов в одной точке делать что-то — и когда у тебя есть один-единственный правильный стандарт, как что-то делать. И этот маятник — я не помню, у этого эффекта или у этого явления есть, по-моему, даже официальное название, маятник Мацумото или как-то так. И вот мы сейчас приходим в ту точку, где прям очень много способов что-то делать. И будет стандартизация, будет мердж каких-то best practices, лучших практик. Потому что на самом деле в организациях это нужно стандартизировать. Существует такое понятие, как провижининг: не будет команда поддерживать для каждого программиста способ делать всё только его способом. То есть мы всё равно вернёмся к какому-то стандартному тулу, которым до сегодняшнего дня была IDE, которая специализировалась на коде. Потому что даже если ты возьмёшь все IDE, которые ты сегодня знаешь, — они выглядели плюс-минус одинаково: редактор был в центре, дополнительные вещи были по бокам. Мы придём к каким-то задачам, переосмыслим, какие задачи для нас будут самыми важными. И из-за этого IDE, которая есть сегодня, либо трансформируется, либо поменяется, либо появятся новые IDE, которые будут новым поколением. Но они всё равно будут IDE, так или иначе.

[2:22:12] Александр: Ну, а что? Время покажет. Хорошо, что мы записываемся на YouTube, это всё есть на записи. Не к тому, чтобы на чём-то подловить, ни в коем случае, наоборот. Иногда, знаешь, когда потом я пересматриваю свои видео двухлетней, полуторагодичной давности, я такой: господи, как я угадал? Счастливчик просто. Думаю: а могло бы быть по-другому? Получить какие-то новые эмоции в таком быстро меняющемся мире от себя прошлого — до того, что я не знаю. Довольно интересно, поэтому посмотрим. Я надеюсь, что да, к чему-то тоже такому придём. Я, в плане, поддерживаю, наверное, твоё видение. Как это? Сейчас у каждого свой монастырь, но в итоге вера плюс-минус какая-то консолидируется, так или иначе.

[2:22:59] Антон: Интересно, конечно, во всём этом пока что находиться, потому что возможность уникальная. Что называется, once in a lifetime opportunity — увидеть такую трансформацию в индустрии.

[2:23:10] Александр: Стопудово. Да, Антон, спасибо большое, что пришёл. Мне было очень интересно.

[2:23:15] Антон: Спасибо, что позвал.

[2:23:17] Александр: Давайте, всем пока.

[2:23:19] Антон: Пока. Спасибо.