ИИ

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

Мир в текущем его виде: появился «босс» — гидра

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

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

Не бог весть какая стратегия, но я до сих пор с ней бьюсь. Пришлось выделить поведенческий код в отдельный модуль и проводить симуляции на тысячах прогонов, чтобы отладить логику. Так удалось отладить поведение лекаря (я в разговоре с ИИ называю её «девочка»), а вот ведьма пока далека от идеала.

Процесс общения с «Курсором» по поводу изолированной симуляции поведения персонажей

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

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

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

Я как-то не думал, что это займёт столько времени, но планирую экспериментировать до успеха.

В конце 90-х был относительно популярен класс программ, который сейчас, кажется не встретишь. Не уверен, что у него есть какое-то официальное название, но чтобы как-то его называть, назову его «виртуальные компаньоны».

При запуске такие программы чаще всего отображали какое-то интерактивное животное — котёнка, который прыгал по вашим окнам или тараканов, которые прятались за ними.

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

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

В процессе написания идея модифицировалась — персонажи поселились на полоске внизу страницы, у них появились враги и некоторая специализация. Всё это полностью сделано «Опусом», я только направлял, тестировал и давал идеи.

Технически всё упаковано в одну картинку (так оказалось эффективнее) из которой читается и код, и спрайты, и вероятности перехода между состояниями для цепей Маркова.

Один из бывших коллег, который следит за моими перипетиями в отношении нейросетей, прочитав прошлую заметку с заголовком «Собрано на коленке», совершенно закономерно спросил меня: а что, собственно, у меня там на коленке собрано-то?

Я перечитал — и оказалось, что из-за усталости я совершенно упустил из виду, что не посвятил «коленке» ни полабзаца.

Что дашборд я стихийно собрал нейросеткой просто под эту задачу — наверное, можно догадаться, — это действительно не какой-то готовый продукт, а скрипт на «Пайтоне», написанный нейросеткой, входящей в мою подписку. Как я сказал, учусь чаще использовать более дешёвые сети, и это — одна из задач, с которой справляется собственная сеть «Курсора» — «Композер 2», а она очень простенькая.

То есть он вполне «собран на коленке».

Но ещё более наколеночно устроен деплой, то есть развёртывание новых гипотез на подключённых мощностях. По сути, это россыпь документации плюс шелл-скрипты, срабатывающие на хуки при коммите. Всё, опять же, написано вайбкодингом, в основном, тремя сетями: всё простое я поручал «Композеру 2», сложнее — «Кодексу 5.3», ещё сложнее — «ГПТ 5.4».

Почему я не стал использовать что-то готовое? А зачем? Надо было быстро, у меня не было времени сравнивать решения, выбирать лучшее под задачу (машины доступны только по ssh, друг друга не видят, перекачивать информацию можно только через мой ноубук), но главное — разбираться, если возникнут проблемы.

В этом мире вайбкоженой шелл-рассыпухи при возникновении проблем я просто даю приказ с ними разобраться.

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

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

Реальный случай, кстати. И таких примеров у меня было несколько.

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

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

Я последние несколько дней занимаюсь похожей штукой. Ну или мне кажется, что это примерно одно и то же.

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

В проверке гипотез мне помогает курсор и куча оборудования — я оккупировал под свои цели три ускорителя H100 и три RTX 6000 Pro. Благо вечерами нагрузки никакой, а часть из этого оборудования вообще пока простаивает. Чтобы видеть куда и какие эксперименты пускать, я написал себе дашборд. При помощи тех же нейросетей, разумеется.

На скриншоте видно плохо, потому что дашборд с панелью «Курсора» выведены на 6К-монитор, поэтому немного расскажу. На дашборде я вижу текущее оборудование, включая ЦПУ, где кое-какие эксперименты тоже можно ставить — на одной из машин 190 ядер, а под оборудованием — текущие эксперименты и цифры по ним.

Всё обновляется в реальном времени.

Если прокрутить ниже, будет ещё один блок экспериментов, план запусков и блок, написанный «Квеном 3.5-35» в виде отчёта научного руководителя эксперимента. Кстати, краткие описания к запускам в таблице оборудования тоже генерируются им на лету.

А теперь пара выводов.

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

Во-вторых, данные надо просить перепроверять, а если есть какие-то интуитивные сомнения, что нейросетка правильно поняла задачу, просить её пересказать. Эта нехитрая мудрость мне тоже обошлась в несколько часов экспериментов, которые пошли не туда.

Я как-то, сильно увлёкшись программирующими нейросетками, не слишком приглядывался к другим направлениям, или, как сейчас принято говорить, «модальностям». Одно время было интересно, как и всем, наблюдать, как сети генерируют картинки, но сейчас я к этому отношусь очень утилитарно и использую их в основном для обработки фотографий. А сгенерированные картинки просто удручают своей стилистической однообразностью.

Музыка и песни, генерируемые нейросетями, привлекали своей необычностью лет десять назад, но сейчас уже как-то не интересны. Видео меня тоже как-то не поражают, видимо, потому что 95-й процентиль всего, что попадается на глаза, — трижды переваренный кал.

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

Поэтому я как-то пропустил, что небольшая по нынешним временам сетка — «Квен 3.5» с 35 миллиардами параметров, квантованных до FP8, — оказывается, прекрасно распознаёт русский рукописный текст. Я просто не изучал, на что способны современные мультимодальные нейросети!

Я-то думал, что весь нейросеточный мир, помешанный на английском и говорящий в основном на китайском, с рукописным русским научится справляться ещё не скоро.

В общем, я глазам не поверил, когда мы попробовали вышеупомянутым «Квеном» распознать текст на фотографии: распозналось всё идеально, причём сеть ещё и ошибки поправила (правда, не уверен, что это хорошо). Понимаю, это не самый непонятный почерк, но этот листок — наш первый эксперимент.

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

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

Данные не реальные, этот текст написала от балды одна из наших сотрудниц, но я всё равно на всякий случая закрасил некоторые данные

Добавлено позднее: уже позже, ближе к ночи я решил попробовать развернуть эту модель, квантованную до четырёх бит на своём ноутбуке, по памяти она как раз должна была влезть, — чтобы попробовать как она справится. Справилась отлично, но мне не удалось выключить режим размышлений, не нашёл такого параметра в LM Studio, где я её запускал, а с ним она работает гораздо медленнее.

Один из читателей в моём телеграмном канале написал, что у него с текстом справилась сеть «Гемма4» на смартфоне.

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

Это кадр со мной из свежего комикса «Кибердянска»

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

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

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

С нетерпением жду появления ещё более способных нейросетей. Компания «Антропик» уже что-то там анонсировала очень крутое, но пока это не в публичном доступе.

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

Всё это время я программировал с нейросетями, в основном с использованием самых мощных моделей, которые только доступны, но некоторое время назад решил изменить вектор. Теперь я, напротив, хочу посмотреть, на что способны более простые модели, в частности «Композер» (это дообученная открытая модель «Кими»), который входит в подписку «Курсора».

Для этого я использую свой любимый полигон — браузер «Виола». Я подыскал несколько несложных задач из разряда «найти бы место, а поправить можно за полчаса», то есть такие, где важно понять, где поправить; сама правка сложной не выглядит.

Одна из задач — дописать нестандартный тег TB, который автор так и не завершил. Судя по иллюстрациям в его недописанной книге о браузере, этот тег предназначался для разрыва таблицы: на рисунке он стоит между строкой «HTML Source / Output» и последующими. Вероятнее всего, TB расшифровывается как Table Bar.

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

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

Ребята из компании «Селектел» (большое спасибо!) дали нам на несколько дней потестировать блок графических ускорителей NVIDIA DGX B300 Supermicro HGX B300. На данный момент это одно из самых производительных решений в одном корпусе.

Для меня, как техногика, это примерно как если бы какому-нибудь любителю автомобилей предложили бесплатно покататься на топовом «Роллс-Ройсе».

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

Блок занимает десять юнитов в стойке; его габариты — 44 × 48 × 90 сантиметров, а вес — почти полтора центнера. Внутри — восемь ускорителей B300, водяное охлаждение, а потребляет всё это хозяйство до 19 киловатт.

Добавлено позднее: оказалось, что «Селектел» нам выделили Supermicro HGX B300. Спасибо одному из читателей, указавшему на ошибку. Я не до конца исследовал вопрос.

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

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

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

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

Одна B300 примерно в 1,8 раза быстрее, чем H100 NVL. H100 NVL, в свою очередь, примерно в 1,4 раза быстрее, чем RTX 6000 Pro. Модели, которые не помещаются в память одного ускорителя, мы пока не используем, поэтому для нас прежде всего интересны результаты именно на одной карте.

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

Единственная модель из более-менее больших, которую нам удалось завести — это Qwen3.5-397B-A17B, для неё метрики ниже.

При росте параллельности с 200 до 500 общая пропускная способность увеличивается почти в полтора раза — с 14 900 до 22 200 токенов в секунду. При этом время до первого токена (P99 TTFT) ожидаемо растёт, но остаётся в пределах 24—25 секунд даже на максимальной нагрузке, а время генерации одного токена (P99 TPOT) — в районе 66 мс, что для модели на 397B параметров с разреженной архитектурой является очень достойным показателем.

К сожалению, из‑за нехватки времени мы не смогли разобраться с запуском ещё более тяжёлых моделей вроде Kimi-K2, возникли какие-то непонятные проблемы с типом FP8. Жаль не удалось это победить, очень хотелось бы посмотреть на по-настоящему тяжёлые модели.

Но и полученные цифры уже дают заказчикам ориентир: если ваша задача требует обслуживания нескольких сотен одновременных запросов к ультра‑большой LLM, DGX B300 справляется с ней без перегрева и троттлинга, сохраняя предсказуемую задержку.

А это сырые пока данные, сведённые из нескольких разных тестов по двум разным моделям — полной «Квен3-30» (A3B) и квантованная «Квен3.5-35» (A3B) на нескольких ускорителях. Самое интересное тут — B300, я про это ещё напишу подробнее отдельно.

Так, кто там у меня в комментариях в телеграмном канале спрашивал о сравнении наших графических ускорителей при работе с сетями, квантованными до FP8 (однобайтового типа с плавающей точкой)?

Табличка ниже, использовался «Квен 3.5» с 35 миллиардами параметров (A3B).

Что мы тут видим? А видим мы очень интересную штуку: оказывается, ускорители H100 бывают очень разными. Инференс нашей тестовой модели показывает, что NVIDIA H100 NVL по-прежнему превосходит RTX 6000 Pro WS примерно в полтора раза, при этом ускоритель H100 без приписки «NVL» работает примерно так же, как и RTX 6000 Pro WS, хотя обошёлся нам примерно втрое дороже.

Сравнение полноразмерного «Квена 3» я уже у себя публиковал.

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

Нейросеть «Опус 4.6», конечно, жрёт невероятное количество денег.

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

У меня уже много лет чешутся руки переделать мою старенькую библиотеку Text_Figlet. Это, наверное, самое популярное моё детище — она время от времени встречается мне в каких-то продуктах и даже входит в виде пакета в некоторые дистрибутивы «Линукса».

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

«Смашинг» был сделан только по горизонтали; вертикальный алгоритм я в своё время не дописал, и этот факт — одна из причин, почему мне захотелось вернуться к библиотеке.

 _  _     _ _                        _    _ _ 

| || |___| | |___    __ __ _____ _ _| |__| | |

| __ / -_) | / _ \_  \ V  V / _ \ '_| / _` |_|

|_||_\___|_|_\___( )  \_/\_/\___/_| |_\__,_(_)

                 |/                           

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

Какое-то офигительное чувство — когда задуманное так быстро превращается в код. Да, его до сих пор приходится просматривать, чтобы подсказывать нейросети, что переделать, но, в общем-то, меня это не коробит. Зато скорость программирования вырастает многократно. Я даже не могу предположить, сколько ещё откладывал бы переделку этой библиотеки, если бы не было настолько продвинутых нейросетей.

Провели тестирование графического ускорителя NVIDIA RTX 6000 Pro WE в сравнении с NVIDIA H100. Тестировали в разных режимах, с нейросетью «Квен3» с 30 миллиардами параметров, без квантования. Тесты включали и синтетику, и реальные наши задачи; мы даже подключили ускоритель к «боевой» инсталляции и наблюдали за разницей. Обучение не тестировали, так как у нас таких задач почти нет: нас больше интересовало, как будут вести себя большие языковые модели.

Все цифры публиковать не буду, но небольшую статистику по синтетическому тесту всё же приведу. Вывод такой: на реальных наших данных разницы мы не заметили, а в синтетике H100 производительнее в 1,55—1,6 раза.

Учитывая разницу в стоимости примерно в три раза, RTX 6000 Pro выглядит более выгодным вариантом для покупки, но с оговоркой: для моделей, которые не помещаются в память одной карты, H100 (или ещё более старшие модели) предпочтительнее, так как у таких карт есть собственная высокоскоростная шина для обмена данными, и общая производительность такого решения должна превосходить производительность карт RTX 6000 Pro, соединённых по обычной шине.

«Режим» — это количество одновременных запросов

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

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

Вернёмся к уязвимостям. На «Хабре» есть очень показательная статья — «Техдиректор Microsoft Azure с помощью Claude AI обнаружил ошибки в 40-летнем коде Apple II». Упомянутый код сеть «Опус» проанализировала на уровне ассемблера процессора 6502, который использовался в тех машинах, и нашла ошибку.

Анализаторы кода не использовались, да и вряд ли они есть для настолько старого ассемблера. Так что в этом смысле это должен быть довольно чистый эксперимент. Моя прежняя попытка читать ассемблерный код нейросетями показала, что существующие на тот момент нейросети справлялись не очень, но видимо «Опус 4.6» продвинулся и в этом.

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

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

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

Поэтому решил посмотреть как будет действовать нейросеть «Опус 4.6» на хорошо знакомом мне проекте — калькуляторе bc, работающем в командной строке. Я выбрал версию для «Линукса», так как там меньше кода.

Я написал небольшой промпт, в котором попросил найти мне переполнения стека, ошибки выделения и памяти и прочие проблемы, характерные для программ на Си. Что интересно, такие проблемы нашлись! Но как же «Опус» это сделал?

Ларчик открывался просто — нейросетка подключила к проекту ASan и UBSan — стандартные инструмент для поиска ошибок работы с памятью, знаковых переполнений, деления и ноль и так далее, а после проанализировала их вывод. Никаких чудес.

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

И дело не в наивном оптимизме. Дело в механике развития технологий.

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

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

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

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

Потом пришли ассемблеры. Потом компиляторы. Потом высокоуровневые языки. Потом фреймворки. Потом облака. И всё заверте…

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

Мы больше не программируем в машинных кодах. Очень мало кто пишет даже на ассемблере и даже Си многие считают чем-то очень далёким, почти устаревшим. Теперь «компьютерная смерть с косой» пришла за Пайтоном, Гоу, Растом и всем остальным, что многим так дорого. Будем описывать, что надо сделать компьютеру, на естественном языке.

И что именно из этого следует?

Если нейросеть способна переводить текст в код, это значит, что исчезает этап механической трансляции. Но разработка программного обеспечения никогда не сводилась к набору текста.

Я специально нашёл слайд презентации, которая с моим участием готовилась для президента нашей республики в 2021 году. Схема упрощённая; сегодня я добавил бы туда ещё пару-тройку прямоугольников и несколько циклов. Но даже здесь видно, что собственно разработка — перевод требований в программный код — это только один из многих этапов разработки программного обеспечения.

Нейросеть может помочь почти на каждом этапе. Но помощь и замещение — разные вещи.

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

Важно не то, что он был один. Важно то, что ему пришлось проявить себя во множестве ипостасей.

Представьте, что у этого разработчика в то время была бы под рукой мощная нейросеть. Было бы ему нечего делать? Вряд ли. Он бы быстрее перебирал варианты, быстрее тестировал идеи, быстрее исправлял ошибки. Но кто бы решал, какую игру делать? Кто бы определял, что она достаточно хороша? Кто бы нёс ответственность за результат?

Автоматизация всегда убирает уровень ниже. Программисты просто поднимаются выше.

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

ИИ не отменяет сложность. Он лишь сдвигает её на другой уровень абстракции.

Поэтому вопрос не в том, вымрут ли программисты. Вопрос в том, кто останется на уровне «переводчика текста в код», а кто поднимется на уровень «архитектора систем и решений».

Заметил сегодня, что в «Курсоре» появилась Gemini 3.1 Pro. А я только утром читал статью о том, что она стала доступна для раннего ознакомления и, якобы, уже «всех рвёт» по интеллекту. Заинтересовался, но, если честно, то, что я увидел, пока меня не впечатлило.

Собственно, всё на скриншоте — даже мой промпт видно.

Во-первых, модель зациклилась и не смогла остановиться — начала генерировать один и тот же токен. Такого я давно не видел, но, наверное, стоит это списать на то, что модель ещё находится в тестировании.

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

Логично, что для локальных адресов этого делать не нужно — именно эту задачу я и поставил «Джемини».

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

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

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

«Опус 4.6» я тестировал на задаче реализации типа нумерации для списков в «Виоле» — в найденных мной материалах упоминается, что такая возможность должна быть, но она так и осталась нереализованной.

До выхода «Опуса 4.6» нейросети с этой задачей не справлялись — либо ломали код, либо делали довольно кривую реализацию. «4.6» с задачей справилась. Рабочую реализацию она написала примерно с третьего раза, но я считаю, что это очень хороший результат, учитывая скорость её работы. Правда было два неприятных момента.

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

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

С этим багом мы боролись очень долго. Конечно, это ожидаемо — «Курсор», — среда разработки, которую я использую, почему-то до сих пор не умеет самостоятельно скриншотить разрабатываемые приложения. Там где нейросеть не может быстро получить обратную связь, всё сильно замедляется, потому что мне приходится вмешиваться — делать скриншот, добавлять его в окно чата и описывать что не так.

Настройка больших языковых моделей на оборудовании — какая-то совершенно отдельная дисциплина. Сколько ни набирайся опыта, а жизнь всё равно привносит что-то новое. Вот, например, мы недавно настраивали небольшую — 30 миллиардов параметров — модель на кластере 8×Nvidia H100. Так много, потому что она будет обслуживать запросы десятков тысяч пользователей.

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

В общем, пока всё приходится испытывать на практике — выходит новое оборудование и надо понимать можем ли мы его рекомендовать клиентам.

В прошлом году появилась очень интересная карта — RTX 6000 Pro. Мы её заказали, чтобы погонять на ней наши модели. Она втрое дешевле, чем H100, при этом производительность у неё далеко не втрое ниже. В аренду мы почему разным причинам не смогли её получить, поэтому купили.

На фотографии я держу её в руке — оцените, какая она огромная, и поверьте: очень увесистая. Тут она в исполнении Workstation Edition, поэтому у неё есть собственное охлаждение; обычно в серверных картах оно только пассивное.

Погоняем тесты, потом постараюсь что-нибудь про это написать.

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

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

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

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

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

Как пример, фотография ниже, сделанная изнутри здания казанского айти-парка. Сравните мою фотку (думаю легко понять где она) и результат обработки нейросетями.

Понятно, что информацию о тех участках, которые заслонены металлическими конструкциям, взять неоткуда, нейросеть там нарисовала отсебятину, пусть и достоверную. Если туда попали какие-то важные детали, то они только по случайности совпадут с реальностью.