Ненормальное программирование *

В процессе подготовки к соревнованиям по системному программированию на C++ я начал заново изучать CMake, потому что Cargo сильно меня избаловал. При этом я заметил в туториале интересное утверждение:

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

CMake Language Fundamentals

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

Для последней версии я писал код, почти не связанный с базовыми алгоритмами и в основном зависевший от довольно сложного набора API. Поэтому я выбрал самый простой из известных мне языков — Brainfuck, ведь простота языка очевидным образом приводит к созданию простой кодовой базы. На самом деле, кодовые базы на BF обычно состоят всего из нескольких строк. Кроме того, комментарий Урбана Мюллера в README заставил меня написать контрпример.

Код выложен на Github.

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

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

Шесть одновременно видимых регистров на ЭЛТ, 24-разрядная десятичная арифметика, магнитный диск в роли оперативной памяти, необычная логика вычислений, программирование с перфокарт, которые для длинных программ необходимо склеивать.

Пройти мимо малоизвестного, но крайне необычного Wyle Scientific не получилось.

Сама компания Wyle Laboratories называла эту машину «больше чем калькулятор — почти компьютер». Посмотрим – так ли это.

История о том, как обычный электрик без профильного IT образования попытался автоматизировать рутинную задачу и в итоге собрал рабочий MVP для работы с PDF файлами.

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

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

TL;DR: Мы портировали игровую логику и рендерер первого Doom на SQL и запустили его внутри базы данных. На моём ноутбуке игровой цикл исполняется на исходных 35 FPS, а рендерер генерирует полный буфер кадров 320x200 с частотой от 60 Гц и выше. Python только обрабатывает тайминги, считывает клавиатуру и отображает получаемую им битовую карту. Многопользовательский режим тоже работает.

Можете сыграть прямо сейчас: Deathmatch, четыре слота, обслуживание в порядке очереди.

SQLDoom на EU-серверах

SQLDoom на US-серверах

Это shareware-версия первого эпизода. Если все места заняты, вы попадаете в очередь. Если очередь заполнена, то в процессе ожидания вы всё равно можете запрашивать состояние игры через SQL.

Я люблю игры, которых нет в Steam: DRM-free игры с GOG и itch.io, визуальные новеллы, фанатские переводы и патчи к ним. На Steam Deck всё это прекрасно запускается, но каждый раз через одну и ту же рутину: скачать, переключиться в режим рабочего стола, распаковать, добавить в Steam как стороннюю игру, выбрать Proton, поискать обложки, вернуться в игровой режим. Переключаться туда ради каждой игры было лень, да и просто геморройно.

Отсюда и выросла идея DeckDrop: один раз зайти в режим рабочего стола, поставить его и больше туда не возвращаться. Дальше всё делается с телефона или компьютера: вставил ссылку, и через пару минут игра уже в библиотеке Steam с нормальным названием и обложками. А скриншоты и длинные записи с дека можно просто скачать на телефон.

Телефон лежит на столе или в другой руке. Сбоку от него в воздухе ладонь. Двигаешь ладонью — корабль на экране поднимается и опускается. Экрана не касаешься. Камера не нужна: телефон пищит ультразвуком и слушает эхо своим микрофоном.

Играть: sonaroids.app (веб-приложение на iPhone; для Android есть .apk — ссылка на главном экране игры). Код: github.com/neokrasav4ik/sonaroids, MIT.

UPD. Заголовок устарел, и это хорошая новость: на Mi 9 Lite, середнячке 2019 года, играется так же, как на iPhone 16. Помогли широкий зонд (управление примерно вдвое чище) и приложение для Android со своим звуком, правильной громкостью и выбором микрофона. Новые разделы статьи — «Широкий зонд» и «Android: приложение вместо браузера».

Я не боюсь, что ИИ заберёт мою работу. Боюсь, что именно это и станет моей работой: читать чужой diff, строить вокруг агента harness и отчитываться токенами.

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

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

TL;DR: docker‑compose файл, поднимающий 3X‑UI с настройкой пары входящих протоколов (VLESS, Hysteria2), маскировочным web‑сервером с обновляемыми сертификатами, а также dnsproxy для предоставления DoH/DoT. Обкатывался аж на целой одной vps, так что, сами понимаете... это скорее концепт, чем инструмент.

При использовании не забудьте создать рядом .env файл с переменными окружения (они описаны в начале compose‑файла), а также каталог www, и положить туда маскировочный сайт (ну хотя бы непустой index.html). После запуска:

— панель будет доступна по адресу https://ваш.домен/admin/ (если вы не задали иной путь);
— не забудьте изменить логин/пароль для панели с дефолтного admin/admin после первого входа (Настройки панели — Аутентификация — Учётная запись администратора);
— стоит также на всякий пожарный отозвать API‑ключ, использованный при настройке (Настройки панели — Аутентификация — API токен).

Вчера SpaceXAI выложила Grok 4.7. За три недели до этого OpenAI выпустила GPT-6 Astra, Anthropic — Claude Fable 5.1. Ещё в июле рядом встал Claude Opus 5: сама Anthropic пишет, что для большинства задач включать надо его, а Fable доставать, когда Opus уже не тянет ваши замеры.

Китайские лаборатории в этой компании больше не «дешёвый запасной аэродром». Qwen3.8 Max стоит те же $2 и $6 за миллион токенов, что и Grok, и на общем индексе отстаёт на один балл. Kimi K3 на суточных инженерных задачах сидит в том же коридоре, что и свежий Grok.

Ниже один набор работ: длинный код, терминал, схемы, юридические дела и счёт. Цифры лабораторий и независимый прогон Artificial Analysis лежат отдельно. На Terminal‑Bench они расходятся почти в полтора раза. Спорить «кто первый» по одной картинке из анонса после этого бесполезно.

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

После перезагрузки экран может остаться чёрным. Модем обнаруживает SIM, но не регистрируется в сети. DSP сообщает, что запущен, а ALSA по-прежнему не видит звуковых карт. Трёхмерная модель ассистента отображается, но стоит в T-позе.

На Samsung M52 я прохожу именно этот этап разработки Platinum OS One: превращаю загружающуюся Linux-систему в устройство, которым можно пользоваться как смартфоном. На момент этой статьи на телефоне работают оболочка с Vulkan, сенсорный ввод, Wi-Fi и SSH. SMS, звонки и USSD я проверил на самом устройстве. Misa получила трёхмерный аватар и подключение к своему диалоговому серверу.

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

Ubuntu userspace и аппаратная платформа Samsung

Platinum OS One строится вокруг Ubuntu Base 26.04 LTS и собственных компонентов. Samsung M52 — одна из целевых платформ. Сборочная система должна оставаться общей для разных устройств, а аппаратные особенности приходят из конфигурации платы, ядра, Device Tree и firmware.

На M52 используется vendor-ядро Samsung на базе Linux 5.4. Здесь это практический выбор: значительная часть поддержки дисплея, модема, аудио и камер связана с downstream-драйверами Qualcomm и Samsung.

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

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

В литературе по оптимизации, работа с памятью стоит не на первом месте, и даже если вы добрались до этих глав там, с большой вероятностью будут рассказывать про пропускную способность, чтобы система могла перемалывать условные пять ГБ/с вместо трех. И в целом это правильная метрика, когда у вас потоковая обработка, или батчи данных вродя запекания освещения, сборки навмеша, или компиляция шейдеров. Там имеет значение сколько данных прошло через процессор за отведённое время, и все стандартные приёмы (SoA, плотные массивы, линейный обход, векторизация) работают на эту метрику.

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

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

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

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

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

Когда комитет стандартизации проектировал корутины, за кадром остался один неловкий момент: фрейм корутины (coroutine frame) — это динамический объект. Локальные переменные, буферы под чтение, аргументы и состояние автомата с точкой останова co_await должны где-то физически лежать, и по умолчанию компилятор выделяет это пространство из общей кучи через глобальный operator new. В асинхронном GUI, где корутина заводится на каждое нажатие клавиши и на каждое чтение из файла, это означает межпоточные блокировки кучи на каждом шаге с потенциальным переключением контекста — ровно то, от чего корутины обещали избавить.

И это не единственный сюрприз: сам по себе co_await асинхронности не даёт. Учебный awaitable запускает работу только в момент ожидания, и две асинхронные операции подряд на деле не запускаются асинхронно - идут с холостым кругом между ними; чтобы корутины стали по-настоящему асинхронными, механизм запуска операции пришлось отделить от того, что даёт язык. Эти вещи неочевидны, о них почти не пишут, и тем, кто присматривается к корутинам, стоит смотреть на них в первую очередь.

Первые несколько дней с AI агентом легко создают ощущение, что разработку наконец-то «сломали». Даёшь задачу, через несколько минут получаешь diff на несколько файлов, тесты и уверенный отчёт о том, что всё готово. Если мерить производительность от момента, когда ты сформулировал prompt, до появления кода, результат действительно впечатляет.

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

Поэтому в течение месяца я смотрел не на количество сгенерированного кода, а на полный цикл изменения: задача → понимание контекста → реализация → review → тесты → интеграция → release. И именно здесь эффект оказался гораздо интереснее простого «AI ускоряет разработчика».

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

Недавно читал тут статью про «Cost per Task» и про то, что самая дешёвая модель в линейке внезапно обгоняет самую умную по цене решённой задачи. С выводом согласен полностью, но хочу добавить то, чего в той статье не было: дело не только в модели. Дело в том, что происходит после того, как модель написала код.

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

Ниже цифры, архитектура и грабли.

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

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