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

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

В отличие от «серебряных пуль» прошлого вроде микросервисов или NoSQL, внедрение искусственного интеллекта во многих компаниях, похоже, спускают сверху, с уровня высшего руководства, независимо от того, сколько людей там вообще когда‑либо работали инженерами или хотя бы учились на них.

Признаю: такой подход сразу разбудил во мне дух противоречия, и я начал активно сопротивляться любым ИИ‑инструментам. Я не считаю, что человек, который в жизни не написал ни строчки кода, должен указывать мне, чем пользоваться в инженерной работе. По‑моему, это уже крайняя форма микроменеджмента, а ничего хорошего из него никогда не выходит.

К тому же лично меня такой подход попросту задевает.

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

Но я забегаю вперёд.

Искусственный «интеллект»

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

А поскольку значительная часть того, что мы, люди, делаем за компьютером, сводится к обмену текстом в обе стороны, такую модель можно использовать для разбора запросов, генерации текстовых ^{(примеч.1)} ответов на основе вероятностной эвристики или команд командной строки. Затем эти команды можно выполнить старым добрым способом, вернуть результаты обратно в модель и повторять цикл, пока не будет выполнено условие выхода.

И это само по себе вовсе не плохо. Но никакой магии здесь тоже нет. «Агентный воркфлоу» — или как там его будут называть к тому моменту, когда вы читаете эту статью, — это просто очередное подтверждение старой истины: любую программную проблему можно решить, добавив ещё один уровень косвенности.

LLM не исключение. Если результат работы нейросети можно улучшить, дав ей больше входных данных, значит, нужно дать ей больше данных. А если лучший способ понять, какие именно данные нужны, — попросить модель сгенерировать команду, а затем выполнить её через system(), пусть будет так.

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

У нас дома есть Google…

В интернете полно полезной информации. И если предположить, что мы более‑менее умеем сохранять уже накопленные знания, то общий объём публично доступной информации со временем может только расти. Но, спойлер: здесь есть один нюанс.

Проблема в том, как всё это найти. И она далеко не нова. Я ещё застал времена, когда первым советом было: «Попробуй новую штуку под названием Google».

Увы, с золотых времён интернета нулевых ситуация заметно ухудшилась. Поисковики уже давно ведут тяжёлую борьбу с SEO, и пока не похоже, что побеждают. ^{(примеч.2)}

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

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

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

Конечно, при двух условиях:

• у нас достаточно вычислительных ресурсов,

• а модель не галлюцинирует при составлении сводок.

К обоим пунктам мы ещё вернёмся, потому что они очень важны.

Обратная сторона в том, что LLM резко снизили стоимость производства словесной каши, которой теперь можно заливать интернет и ещё сильнее размывать и без того ненадёжное информационное пространство. Фрейя Холмер выпустила очень хорошее видео о том, к чему приводит засорение сети ИИ‑контентом в бесконечной гонке SEO‑вооружений.

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

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

…а теперь Google есть ещё и на работе

Есть одна область, где цикл с LLM оказался особенно полезен для поиска и о которой, как мне кажется, пока говорят не так много: внутренние базы знаний компаний. Где бы вы ни работали, почти наверняка у вас есть какой‑то набор из wiki, переписок в Slack, Google Drive, страниц в Confluence и всего остального, где хранится масса полезной информации, которую почему‑то никто не может нормально найти.

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

За последние несколько месяцев, хотя я сам в компании совсем недавно, мне удалось найти немало ответов, написанных ещё до моего прихода. По тому же принципу, по которому «ИИ‑поиск Google» может параллельно запускать несколько запросов и потом собирать ответ, Claude и другие подобные инструменты умеют превратить мой вопрос на естественном языке в набор поисковых запросов с возможными синонимами и гонять их, пока что‑нибудь не найдётся.

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

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

Поиск по вашей корпоративной wiki или чату, скорее всего, этого не делает.^{(примеч.3)} Подозреваю, что в логах Slack годичной давности лежит масса полезной информации, до которой без LLM‑поиска добраться абсурдно сложно — если только рядом не окажется более опытный коллега, который помнит тот разговор и сможет вас к нему направить.

Эффективно ли с технической точки зрения запускать дорогую LLM ради поиска по корпоративной wiki, если вместо этого можно было бы внедрить базовые поисковые технологии, которым уже несколько десятилетий? Нет, почти уверен, что нет. С точки зрения вычислительных затрат гораздо разумнее было бы нормально индексировать контент примерно так, как Google делал ещё 20 лет назад.

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

Галлюцинации и ложноположительные результаты

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

Галлюцинации — неотъемлемое свойство того, как работают LLM. Генерация токенов основана не на логике и не на истинности, а на статистике, и, насколько я понимаю, полностью избавиться от галлюцинаций невозможно. Я встречал их во всех моделях: от дешёвой и довольно посредственной бесплатной версии Copilot в Bing до самых навороченных платных моделей Claude.

Чаще всего я сталкивался с ними, когда задавал очень конкретный вопрос, на который раньше никто толком не отвечал: например, спрашивал о какой‑нибудь нишевой возможности CMake, Vulkan или Xcode. Вместо ответа «нет, так нельзя» я получал наиболее вероятностно правдоподобный вариант: модель советовала нажать кнопку, которой не существует, или включить несуществующий фиче флаг.

Это примерно как спросить человека, который хорошо разбирается в предметной области в целом, но не знает конкретную программу или библиотеку, которой вы пользуетесь. Он вполне может ответить: «Да, похоже на то, что так должно быть можно», потому что ожидание само по себе кажется разумным и, возможно, такая функция действительно есть в похожих продуктах.

Подозреваю, по той же причине LLM при написании кода пытается вызывать несуществующие API: если судить по другим языкам, кажется вполне логичным, что у контейнеров C++ должен быть метод.sort(). В Python и C# что‑то подобное действительно есть. Но C++ жёстко разделяет контейнеры, итераторы и алгоритмы, а LLM не рассуждают от базовых принципов — как бы маркетинг ни называл это «reasoning».

Частично эту проблему можно обойти, если всегда просить первоисточник или ссылку на него. Но мне не нравится сама идея, что ради правильного ответа приходится добавлять в запрос какие‑то магические заклинания. Смеяться над мемами про «make no mistake» забавно ровно до тех пор, пока самому не приходится всерьёз учитывать подобные вещи.

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

Я заметил еще одну проблему: с коннекторами довольно легко заставить LLM начать кормить саму себя собственными данными. Например, когда я попросил Claude найти предыдущие упоминания рекомендации, которую готовил для клиента, он уверенно заявил, что она подтверждается прошлыми отчётами… пока не выяснилось, что одним из этих «прошлых отчётов» был тот самый документ, который я сейчас и писал. Поймать ошибку было несложно, потому что Claude показал мне разбивку по источникам.

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

И ещё один риск, который я заметил у коннекторов, подключённых к другой LLM, — эффект испорченного телефона. Однажды Claude сообщил мне, что есть конкретные доказательства того, что определённое техническое решение команда приняла осознанно. В итоге оказалось, что он просто принял за факт сводку, составленную другой ИИ‑системой, а реальным первоисточником были сообщения двух пользователей на публичном форуме, которые лишь предполагали, почему модуль работает именно так.

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

А код?

До сих пор все мои примеры были связаны с поиском и исследованием. Но что насчёт написания кода? В конце концов, это же та самая следующая большая вещь, которая вот‑вот наступит, правда?

Если коротко: получается не очень.

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

В одном случае после долгого обсуждения я попросил Claude сделать рефакторинг ради оптимизации:

• убрать метод Update() у объекта, унаследованного от MonoBehaviour,

• сложить такие объекты в List<Foo>, принадлежащий классу‑менеджеру,

• а затем выполнять эквивалентное обновление в самом менеджере обычным циклом for.

Это довольно распространённая оптимизация в Unity: если у вас много объектов одного типа, она позволяет не платить за каждый (виртуальный) вызов MonoBehaviour.Update() из C++‑части движка в управляемый C#‑код.

Но вместо этого Claude создал базовый класс GameUpdateable с методом OnUpdate(), унаследовал от него Foo, сохранил массив как List<GameUpdateable> в менеджере, а затем сделал цикл с вызовом GameUpdateable.OnUpdate(). Некоторые C#‑бэкенды всё ещё могли бы девиртуализировать такой вызов, да и чистый вызов из C# всё равно лучше перехода из C++ в C#, но решение получилось сложнее и переусложненнее, чем я просил.

Вместо того чтобы «просто сделать то, что требуется», Claude решил зачем‑то применить здесь ООП‑паттерн, который вообще не был нужен. И задача ведь была совсем не сложная: изменения затрагивали всего два‑три файла.

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

Хуже того, в случае с играми первоисточников почти нет. Последней AAA‑игрой, исходный код которой открыли, была Doom 3, вышедшая в 2004 году — 22 года назад. В ней даже многопоточности нет! ^{(примеч.4)} Другие классические игры, исходники которых за эти годы выкладывали на GitHub, обычно родом из девяностых — с программной растеризацией или, если повезёт, с фиксированным конвейером OpenGL 1.2.

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

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

И раз уж я упомянул дороговизну: помните, что на выход модель тратит в 5–10 раз больше токенов, чем получает на входе. Или, возможно, выходные токены просто стоят в 5–10 раз дороже входных — с практической точки зрения разницы немного. Поэтому составление сводок обходится сравнительно дёшево: модель поглощает гораздо больше текста, чем генерирует.

А с написанием кода всё наоборот.

Ассистент программиста

Недавно я читал о работах британского консультанта по управлению Стаффорда Бира.^{(примеч.5)} Всю его область управленческой кибернетики ^{(примеч.6)} можно очень грубо свести к одной идее: способность руководителя — а в большем масштабе и целой компании — принимать хорошие решения ограничена тем, сколько информации он способен обработать о работе собственной организации, клиентах, поставщиках и любых других факторах, влияющих на результат.

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

По похожей логике — пусть аналогия и не идеальна, признаю, — погружение в новую кодовую базу требует переработать огромный объём информации, чтобы принимать правильные решения. Это происходит каждый раз при смене работы или проекта, а в консалтинге такое случается довольно часто. Поэтому, когда нужно быстро принести проекту пользу, одним из главных ограничений становится объём информации, который вы успеваете усвоить.

В таких условиях LLM может быть очень полезна:

• помочь исследовать код,

• проследить связи

• и посмотреть, куда они ведут.

Возможно, стоило так и оставить первоначальное название «AI coding assistant» — ИИ‑ассистент программиста, — вместо того чтобы пытаться заставить эти инструменты делать вообще всё.

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

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

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

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

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

Второй случай касался проблемы с PBR‑освещением.

• Claude предложил переписать всю систему освещения,

• перенести основной источник света

• и добавить освещение окружения.

Спустя несколько часов выяснилось, что у одного из ассетов просто была некорректная текстура metallic/roughness, и никакие изменения в коде освещения не могли нормально исправить эту проблему. И снова: когда вы сами не эксперт в теме, уверенно рассуждающая LLM очень легко может отправить вас по ложному следу.

Забавно, как ИИ постоянно выдаёт ложную информацию и ошибочные утверждения о той области, в которой я разбираюсь. К счастью, по темам, о которых я почти ничего не знаю, он очень полезен и всегда прав. — pikuma.com, 19.06.2026

Устойчивость

Все ИИ‑компании сейчас теряют деньги. Разумеется, каждая обещает, что со временем начнёт получать прибыль и принесёт инвесторам безумную доходность, но пока этого не произошло. На самих токенах они получают предельную прибыль,^{(примеч.7)} но в целом остаются убыточными. Учитывая, что железо дешевле не становится, а модели приходится постоянно обучать заново, нынешние цены пока не выглядят устойчивыми.

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

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

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

Подписка на LLM универсальнее лицензии на профилировщик для среднего программиста? Наверное. Мне она действительно помогала быстрее разбираться в незнакомых областях.

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

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

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

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

Глубже разобраться в возможностях и ограничениях LLM можно на открытых уроках OTUS:

• 8 сентября, 20:00. «Что надо знать про работу LLM моделей». Записаться

• 22 сентября, 20:00. «Можно ли доверять ИИ‑коду: как находить галлюцинации, уязвимости и устаревшие решения». Записаться

Полный список бесплатных уроков августа смотрите в дайджесте.