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

Решаем задания на Codewars вообще любой сложности за полчаса и меньше без ИИ и иных подглядываний (типа)

Обычная системная куча обязана предполагать худшее: что в неё в любой момент постучатся из десятка параллельных потоков. Отсюда неизбежные блокировки, атомарные операции и накладные расходы. Но в GUI-приложениях на WinUI 3 этого сценария просто не бывает — все контролы и элементы разметки создаются и умирают строго в одном-единственном STA-потоке. Зачем же платить за потокобезопасность, которую мы не используем?

В этой статье мы разберем устройство sta_memory_pool — кастомного аллокатора для библиотеки wxl, работающего в 15–16 раз быстрее общей кучи. Вы узнаете, как с помощью инструкции lzcnt вычислить класс размера за один такт, как избавиться от лишних if-проверок на горячем пути с помощью самоперестраивающихся таблиц функций и как заставить линейную аллокацию работать на максимальную отзывчивость приложения при старте.

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

У меня это выглядит так. Появилась идея новой фичи для разработки. Я запускаю /opsx:explore скил OpenSpec и обсуждаю с ИИ как будем делать эту фичу, какие нюансы и детали надо предусмотреть. Когда открытых вопросов не остаётся, перехожу к /opsx:propose, чтобы подготовить спецификации перед разработкой. Потом ревью спек с помощью команды /review-artifacts и правка найденных нестыковок. Дальше запускаю /opsx:apply-sequential для реализации в автономном режиме и чистым контекстом агента для каждой подзадачи. Потом ревью через /audit-implementation и правки после него. Архивирование изменения через /opsx:archive. И наконец-то создание PR, финальное ревью и merge.

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

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

Но насколько далеко это можно довести в обычном браузере? Что произойдёт, если вычисления — это полноценная симуляция с десятками миллионов объектов? Разберемся в этой статье.

На одном из проектов (4Х историческая стратегия) появилась задача убрать часть логики в потоки, отдав им снапшот игрового состояния, чтобы пока основной поток считает свой тик, остальные (AI, поиск пути, UI и др) могли крутить свою логику, вроде "кто стоит в этой локации" и делать это без блокировок или риска увидеть половину чужой записи. Чтобы реализовать такую систему, надо придумать как получить обратный индекс полка по локации, причем сделать поиск дешевым для потоков, т.е. у потока должен быть свой снапшот состояния некоторой части игрового мира на момент старта апдейта (кадра, тика логики, дня, месяца и т.д)

Общепринятая практика - это сделать данные иммутабельными на время кадра, и построить нужный индекс один раз на старте, а дальше дать читателям возможность работать с ним. И вообщем от ребят, которые делали эту задачу на ревью прилетел вот такой код (выделю тут только основную часть):

std::vector<std::vector<unsigned int>> regiments(location_count);

Такая структура называется jagged array, массив массивов (зачем она и как с ней работать я показывал в книге Game++), или, если вам ближе академическая терминология, CSR (compressed sparse row) немного другая форма записи таких массивов, либо разреженные матрицы. И такие структуры довольно частое явление в играх, если у вас много локаций и вам надо узнать какой лут разложен в каждой локации, какие армии принадлежат каждой области, или какие монстры живут в локации, какие локации входят в область, какие области в регион, или почекать соседей локации на карте, adjacency region, на чем строится весь поиск путей и вся заливка областей в глобальных стратегих;

Этот пост для разработчиков, которые еще скептически относятся к кодингу с ИИ агентами и не используют его. Мир стремительно меняется и пора «проснуться» и поменять методику работы.

Ниже я расскажу личный опыт, чтобы было нагляднее.

Кейс по мотивам исследования SKILL.state: немного инженерии контекста, бенчмарков и графиков. Эксперименты с памятью coding-агентов в OpenCode и Codex и размышления о перспективах идеи.

Мы с женой хотели играть в Split Fiction, но английские диалоги было трудно понимать на слух. Я собрал PS5 Voice: MacBook распознаёт субтитры с приставки и озвучивает их по-русски. Мы уже играли с этой озвучкой — работает, и это кайф. Рассказываю, как устроено приложение, и делюсь промптом для самостоятельной сборки.

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

В прошлой статье я рассказывал о скрытом баге: ИИ‑агент в проде заказчика тратит токены, генерация закрывается со статусом «успех», а клиенту уезжает пустая строка. Тогда я обещал разобраться и починить. Обещание выполнено: причина найдена, правки встали в воркфлоу, счётчик пустых ответов уже 7 дней — чисто. Баг получил имя Reasoning Lock. Теперь подробно о нём: симптомы, «расследование по этажам», механика и «лечение» — в общём в стиле детектива :-)

Напомню, что строю ИИ‑агентов на self‑hosted n8n. Герой статьи — агент в проде заказчика: по ночам принимает заявки в Instagram Direct, ведёт диалог, собирает анкету и создаёт/обновляет сделку в amoCRM. Стек агента: n8n + Redis + LangChain, LLM основная — DeepSeek V4 Pro через OpenRouter, резервная — недавно поменял на Qwen3.8 Flash.

Предыстория: два периода, две природы отказов

История началась задолго до самого бага. С конца июня (установил в прод агента в первых числах июня если точнее быть) отказы случались двух периодов, и разница между ними = ключ к пониманию.

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

Период второй — последние два месяца: промпт. Система стабилизировалась, и правки от заказчика посыпались в системный промпт... (( Под живую бизнес‑логику: инструкция по пересылке оплаты пользователем, отдельные сценарии ответов для VIP‑клиентов (абзаца два, которые под каждое «фи» постоянного клиента меняли по несколько раз), уточнения формулировок после каждого спорного диалога. Каждая правка по отдельности естетсвенно правильная и рабочая. Суммарно же промпт разросся до где то 6.4k токенов, и плотность запретов («КАТЕГОРИЧЕСКИ ЗАПРЕЩЕНО», «Отправь СТРОГО этот текст») стала максимальной за всю жизнь системы.

Мода на квантизацию скоро закончится...когда появятся они: модели, обученные на тернарной/тритовой/троичной логике.

Или нет?

Пройдемся по форматам обучения от FP32 до FP4, а потом сделаем аналог модели Microsoft Bitnet 1.58 на C#, размером 29Кб (в экстремальном варианте — 17,1 КБ).

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

Lenovo Tab M11 на моём столе загружается с внутренней памяти в Kubuntu.

KWin работает через DRM/KMS, Mesa рисует через Panfrost, звук идёт через PipeWire, сетью занимается NetworkManager. Bluetooth виден как обычный hci0, сенсоры — как IIO, камеры — как V4L2. Стилус работает с давлением и наклоном.

Камеры тоже завезли: задняя умеет полноценно фотографировать не только в jpg, но и в RAW, и писать видео 1080p/30fps, а еще обе камеры при этом доступны обычным Linux‑приложениям как /dev/video-rear и /dev/video-front.

Android? Отправлен за 101-й километр.

Такого плана в начале у меня не было.

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

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

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

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

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

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

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

Про диаризацию на рабочем созвоне: как размечался эталон, почему в системном канале нет твоего собственного голоса, чем закончился A/B четырёх эмбеддеров (место в бенчмарке VoxCeleb никак не предсказало результат на живой записи), что показали VibeVoice и MOSS и почему адаптивный фильтр не вычитает эхо из микрофона.

В 2013 году я купил книгу про то, как делать приложения, и загорелся. И вот спустя 13 лет, я все же выпустил свое первое приложение — дневник тренировок, от первого запроса в Claude Code до публикации в RuStore и Google Play. Рассказываю, как без навыков программирования я сделал свое первое рабочее приложение.

Я программист с приличным стажем, ещё в школе писал игрушки для БК‑шек, а сейчас у меня коммерческий стаж на Python, и я считаю себя, в общем‑то, уверенным сеньором.

До недавнего времени из ИИ я пользовался только браузерным Gemini. Он быстрый, живой, отзывчивый — с ним можно приятно поболтать, однако кодит он неважно. Добиться нужного результата частенько получалось только через крепкое словцо, на которое, впрочем, Gemini охотно откликается. Но понятно, что это всё жутко неудобно и надо было переходить на кодинг‑агентов.

Так бы я и канителился, однако получилось так, что вайб‑кодинг, вместе с вайб‑планированием и вайб‑постановками задач в Jira, в нашей команде внедрили волевым решением. Никого не спрашивая, не выясняя, кто что умеет, кто как к этому относится и как это вообще повлияет на разработку.

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

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

Трудно представить начало сессии с ИИ, в которой модель легко и быстро понимает весь проект и необходимый контекст, чтобы принять от разработчика требования и качественно спроектировать внедрение, не сломав текущее стабильное состояние. Экспертиза инженера‑разработчика или системного аналитика несравненно качественнее — хотя бы потому, что он живёт с ней 24/7.

Claude Code не привязан к api.anthropic.com: это обычный клиент, и куда он ходит, задаётся двумя переменными. Разбираю, что именно нужно ему от эндпоинта, три способа подключения (shell, settings.json, apiKeyHelper), как проверить curl-ом до запуска и что означают типовые ошибки — 401, 403 с HTML, «auth may not work as expected» и внезапный 404 на haiku. Без названий сервисов, только механика.