NuclearBand

Стратегический лонгрид о превращении агентов из личных инструментов в инфраструктуру компании: https://nuclearband.rocks/articles/AINativeCompany/

PREPARE TO FIGHT После нескольких десятилетий развития веб-технологий мы наконец можем делать сайты как меню Quake III Arena. IMPRESSIVE Q U A D D A M A G E https://nuclearband.rocks/

I’ve got balls of steel!

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

Не в первый раз в контексте обсуждении внедрения ИИ слышу вопрос - "кто отвечает за код?". На мой взгляд ничего принципиально не изменилось: программист не исчезает из процесса, а просто меняет свою роль, поэтому отвечать можно ровно так же, как и раньше. Для собственного спокойствия мне удобно считать, что за результат отвечает QA: он последним посмотрел на фичу и дал добро, значит, можно спокойно спать. Но в реальности не отвечает даже QA — он не может проверить все краевые случаи, особенно если GD их не описал, программист не подсветил, а сам процесс не заставил это сделать. Поэтому за результат одновременно не отвечает никто и отвечают все: ответственность лежит не на конкретном человеке и не на конкретной строчке кода, а на процессе разработки. Если баг дошёл до продакшена, это не значит, что какой-то программист оказался плохим; это значит, что процесс где-то не обеспечил нужное описание, реализацию, проверку или передачу информации. А персональная ответственность, если уж её непременно хочется найти, всегда в итоге находится только у того, кто этот процесс выстроил.

Возвращаясь к Multica: сделал multica-declarative — cli-тулза, которая позволяет декларативно описывать конфигурацию платформы: агентов, их скиллы, MCP-серверы и остальные нюансы упряжек. Экспортировать конфиг из мультики и импортировать его обратно. Так можно, например, удобно версионировать скиллы через git и синхронизировать их между машинами через мультику. Причина простая: я настолько привязался к Multica, что уже даже рабочие задачи запускаю через неё. Когнитивно это значительно комфортнее - закидываешь задачу на свой VDS в таск-трекер и тут же выгружаешь из контекста своего мозга, подлинное делегирование, потому что не остаётся никаких открытых сессий с агентом для микроменеджмента. А в это время агент с VDS делегирует реализацию агенту на основном компьютере, который всё делает в фоне (а благодаря unity cli даже не использует compute use для qa - снимает скриншоты из юнити через eval ScreenCapture.CaptureScreenshot и кликает на кнопки прямо вызывая button.click кодом). Возникает приятное ощущение, что все задачи ваншотаются. Ну и больше не нужно никаких remote тулов для телефона - multica эффективно закрывает и этот вопрос полностью.

Юнити не были бы юнити, если бы в статье о появлении unity cli (это реально круто - не анонс, не обрезок, а сразу нормальный инструмент вместо тупого unity mcp) не забыли приложить главную ссылку на свой готовый скилл для его использования - https://github.com/Unity-Technologies/skills/tree/main/skills/unity-cli.

Вот ради чего стоит заводить свой сайт: https://wattenberger.com/thoughts/code-is-a-medium-for-thought/. Никакой rich-text в Telegram или wysiwyg-редактор на Хабре не позволит сделать такое. Информации стало слишком много, вместо передачи фактов куда важнее развить вкус, мышление, обогатить картину мира. Сделать это одним только текстом невероятно сложная задача. Хорошая форма не просто объясняет идею, она позволяет человеку превратить её в собственный опыт. Я сам сейчас много эксперементирую с формой ответов ИИ - html формат это очевидно, но я добавляю мета-уровень с геймофикацией и обучением (меня, а не ИИ), плюс готовлю большую презентацию на работе. Получилось 50 HTML-слайдов и это только скелет. Мяса для речи гораздо больше. Но меня не покидает мысль, что весь этот контент можно уплотнить и одновременно добавить значительно больше деталей и выпуклости.

Как-то жаловался, что в юнити не вдупляет что люди тестируют, а оказывается при этом существует Graphics Test Framework (который в Unity Registry невидимый). Главная его фишка в методе ImageAssert.AreEqual, который позволяет сравнивать макет с экраном в игре.

Задумался над тем, как делать своим агентам почтовые ящики, чтобы они могли регистрироваться в сервисах и иметь собственные аккаунты и обнаружил суперфичу гугл почты: поддержка алиасов через + в имени. Т.е. если у вас почта mymail@gmail.com, то вы можете получать письма с любого адреса mymail+alias@gmail.com. Таким образом агенты могут регистрироваться через почту mymail+agent1@gmail.com и так далее.

Оплатил себе недельку в GFN.AM, чтобы поиграть на макс настройках в Expedition 33 с телефона. Но вместо этого купил Space Marine2 и теперь читаю в ChatGPT про кодекс Астартес и прочую друкхари. Вообще, ваха это пример мира, который я терпеть не могу. Все до единого идиоты, лишённые минимальной свободы воли, и тебе в итоге остаётся симпатизировать безмозглым тиранидам. Стриминг игр, кстати, полный улёт, не знаю почему я так долго его игнорировал. Клиент geforce now жрёт всего 600 мегабайт оперативки и вообще не загружает цпу, можно одновременно компилировать два проекта в юнити и играть в дум, не испытывая никаких тормозов. Кстати, покупайте ваху по моей реферальной ссылке, так вы поддержите отечественных разработчиков (мне капнет 15 копеек!).

Всю прошлую неделю делал игру для геймджема — как раз с помощью той самой пресловутой мультики. VDS у меня слабый, поэтому выбирал движок, который быстро собирается, не требует мощного ПК для компиляции и нормально деплоится в веб. Выбрал Phaser 3. И да, он реально лёгкий, билды невесомые. Но есть нюанс: работать с ним боль. Хочешь подвинуть кнопку на пару пикселей вниз? Или поменять скейл персонажа? Ну удачи. Инспектора нет, сцен/префабов как таковых нет, всё через код. В итоге пришлось городить свои читерные инспекторы. А какие ещё варианты? Defold лёгкий, но Lua... Да и агент сказал, что формат сцен выглядит не очень удобным для редактирования. Есть Cocos на TypeScript, такой мини-Unity, но очень китайский. Есть ещё KNI на C# - это форк monogame с поддержкой веб-билдов, но это тот же Phaser, только с ещё меньшим функционалом. Главная беда всех этих вариантов - ассеты. Нормального asset store нет, готовый UI kit найти почти нереально. В итоге берёшь ассеты из Unity и просишь ИИ как-нибудь прикрутить их к другому движку. Получается, Unity безальтернативен даже для веба. C#, простые форматы сцен и prefab’ов, куча готовых ассетов и библиотек — всё на месте. Да, собирается долго. Но это решается: HybridCLR + YooAssets (смотрю свысока на всех, кто с приходом ИИ не переписал Addressables или не перешёл на другой пакет). И в итоге ты получаешь hot reload в уже задеплоенной игре — фичу, которой, между прочим, нет ни в одном из тех лёгких движков.

Из всего, что я пробовал, ближе всего к нужной идее пока выглядит Multica. Там есть рантаймы - машины, на которых запускаются агенты, сами агенты - настраивается модель, харнесс, набор скиллов, системный промпт, можно даже squad из них сделать. И там же встроен таск-трекер - в нём можно назначать задачи агентам, которые их двигают, оставляя все свои рассуждения приложенными к задаче. Но по ощущениям это стрёмный костыль - привычный таск-трекер можно настроить значительно гибче. На самом деле достаточно только платформы агентов - добавить им ещё permissions, настройку хуков, и цифровую личность (собственные сэндбоксы, токены для таск-трекера, почта, аккаунты в мессенджере, базе знаний и т.д. каждому агенту) - и будет мякотка, Но такого пока нет.

Сейчас работа с ИИ-агентами часто выглядит как личная магия разработчика. У каждого свои модели, harness, скиллы и локальные пайплайны. В трекере задача просто висит на программисте, а у себя на компьютере он уже делегирует её агентам, правит их планы и гоняет результат туда-сюда. В итоге вместо команды разработчиков появляется набор маленьких отделов: человек плюс его агенты. Но эти отделы невидимы. Никто не видит, сколько было итераций, где агент ошибся, сколько времени ушло на микроменеджмент и какой пайплайн реально сработал. Программисты фактически становятся менеджерами, но без менеджерской дисциплины. Они делегируют работу, но не фиксируют делегирование. Возвращают задачу на доработку, но не считают попытки. Улучшают промпты и скиллы, но не превращают их в общий актив команды. Из-за этого искажается вся картина разработки. Один может считать агента полезным, потому что привык вручную сглаживать его ошибки. Другой тратит на контроль больше времени, чем экономит. Третий нашёл сильный подход, но команда узнаёт о нём только как об устном совете: «попробуй вот так». Так не появляется инженерная практика. Так появляется фольклор. Делегирование агенту должно быть видно в таск-трекере. Агент сделал план — план должен остаться в задаче. Человек поправил его — это тоже должно быть видно. Агент написал код, провалил ревью, исправил ошибку, не понял контекст или хорошо справился с типовым сценарием — всё это часть производственного процесса, а не личная история разработчика. Плохо, когда история выглядит так: «Петя получил задачу, где-то у себя запустил какого-то агента, а потом просто перекинул результат в QA». Нормальный вариант другой: вся цепочка видна прямо в задаче. Агент Opus4.8_01 подготовил план, человек поправил и утвердил его. ImplementerCodexXHigh_1 написал код. Qwen_01 сделал ревью и нашёл проблемы. Человек посмотрел результат, принял финальное решение и передал задачу в QA. То есть ИИ не запускается где-то локально и незаметно. Он работает как часть общего процесса. Это важно и для обучения. Новичку не нужно объяснять на словах: «запусти агента, дай ему контекст и как-нибудь проверь». Он должен открыть реальные задачи и увидеть, как команда работает с агентами: где вмешался человек, что агент понял неправильно, какой план приняли, почему код вернули на доработку и как задача дошла до релиза. Нормальная культура работы с ИИ-агентами появится там, где работа агентов станет частью общего инженерного процесса: видимой, обсуждаемой и измеримой.

Это каналы про ИИ, на которые я подписан. Порядок случайный. DEKSDEN notes ИИ пашет, Саша одобряет Dealer.AI AI и грабли Валера Ковальский Константин Доронин Глеб Кудрявцев про AI Тимур Хахалев про AI Coding Tips AI | IT & AI Остриков пилит агентов Этихлид ElKornacio Refat Talks: Tech & AI AI-Driven Development. Родион Мостовой Max: AI, Engineering and Startups AI да парень! / Sergei Notevskii Метаверсище и ИИще Джимми Нейрон 🚀 Революция Чайных Пакетиков #subscription

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

Мой текущий remote setup это hapi + outray. В самой работе по сути используется всего пару скиллов: $jira для чтения задач и $yamu для компиляции (хотя под капотом nyamu) . Не понимаю тех, кто юзает какие-то сложные mcp для юнити - по-моему гораздо проще и эффективнее редактировать ямлы префабов и сцен напрямую, чем что-то там делать вызовами менюшек. Ещё есть добавка в системный промпт, чтобы результаты отдавались в html. Вся работа сводится к промпту "$jira номер задачи". Никаких планов, никаких ревью, никакой отсебятины. Скучно. Можно чуть запариться и полностью всё автоматизировать: подписаться на хуки джиры, добавить возможность писать и отвечать на вопросы коллег, но какая-то апатия наступила в отношении ИИ. Смысл усложнять, если и простой вариант хорошо работает. На днях чей-то стрим открыл по разработке, и там чувак портянку кода реально руками в ide читает и редактирует. Я даже не понял сначала что он делает) Ностальгия проснулась, всё-таки лучшей моделью был sonnet 4.5, когда приходилось изучать план, писать интерфейсы... Тогда агент брал на себя имплементацию, а какая-то архитектура и принципы оставались за программистом. А теперь архитектура не нужна, это просто попытка хоть чем-то себя занять. ИИ не то чтобы делает отличную архитектуру, но она никогда не становится проблемой. Вообщем, нет никаких сомнений, что нас всех уволят, даже самых ai-native, как впрочем и художников и гейм-дизайнеров и тестеров. Останутся только продюсеры :) И по-моему это и есть единственный критерий нормальной ИИ трансформации компаний. AI-first компании не те, где каждому оплачивают подписку, а те, в которых люди начинают совмещать несколько ролей.

Спонтанная покупка после того как узнал, что UI Toolkit до сих пор не умеет в лупы анимаций.