Я переключил свой проект https://github.com/flancer64/tg-wa-blog-post по переводу постов в телеграме с русского на английский и испанский со своей старой, вручную написанной версии связывания кода, на новую версию, созданную LLM-агентами. Я был уверен, что придётся брать огромного размера напильник и подгонять код вручную. Это довольно большой сдвиг в оформлении кода и в понимании механизмом его связывания. Но в целом у нас с Codex-агентом сегодня ушло меньше часа на миграцию.

Я ещё не уверен, что приложение по переводу постов после миграции полностью работоспособно, но тесты проходят и к телеграму приложение подключается. Разумеется, код мне не нравится - это каша с кучей предупреждений от tsserver'а о проблемах в коде. Тем не менее, эта "каша" подключилась к телеграму, а это значит, что 1) DI, созданный вчера Codex-агентом, работает, 2) миграция на новый DI, проведённая сегодня Codex-агентом, тоже в какой-то мере работает.

Я впечатлён!

Ну вот, я запостил предыдущее сообщение и теперь проверил своё приложение в рабочем режиме - оно полностью работает! Практически без напильника. Агент всё сделал сам.

Я впечатлён сильно!!

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

Поэтому я решил иишное решение вынести на обсуждение. Вчера сделал три публикации:

- reddidt: https://www.reddit.com/r/javascript/comments/1re4blt/askjs_is_declaring_dependencies_via_deps_in_esm_a/
- dev.to: https://dev.to/flancer64/static-imports-are-undermining-javascripts-isomorphism-25nm
- habr: https://habr.com/ru/articles/1003708/

Самое благожелательное отношение - на dev.to. Народ поставил 3 середечка, 1 единорожика, 2 раза похлопал в ладоши и 1 раз нарисовали пламя. Что всё это значит - непонятно. Был один коммент - мне вежливо указали, что "есть же imports map". Всего было порядка 280 прочтений за сутки.

Самое привычное - на Хабре. Поставили 2 минуса, 2 человека добавили в закладки, всего было порядка 410 читателей. В комменты пришёл Карлицкий (автор $mol), сказал, что мой подход неправильный. Но он всем так говорит, такова его роль.

Самое интересное - на reddit'е. Посмотрело около 10К человек, 39 комментариев (половина - мои ответы), оценка самого поста - 0 (при публикации ставится +1, так что по итогу негатив получился). В целом народ на reddit'е довольно прохладно встретил идею заменить статистические импорты декларациями зависимостей для перехода с раннего связывания на позднее. Но не откровенно негативно, как это бывало на Хабре. Так что тоже по итогу всё же позитив :)

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

Разделил на две ветки свой базовый пакет @teqfw/di, на котором я строю все свои веб-приложения.

- версия 1.x: это "код ручной работы" по заветам отцов;
- версия 2.x: это нейрослоп, сгенерённый Codex-агентом;

Первое - сделанное людьми для людей, второе - агентами для агентов.

https://www.npmjs.com/package/@teqfw/di

Кстати, автоматический перевод сообщений из этого канала на английский и испанский для en & es-каналов делает приложение переключенное агентами на вторую версию @teqfw/di. У них это очень ловко получается.

После разделения своего базового пакета @teqfw/di на две ветки (человеческую и агентскую) я проверил v2 (агентскую) на своём приложении по переводу постов в телеграм-каналы на другие языки. Codex-агент так же ловко справился с этим консольным приложением, как и с самим DI-пакетом.

После этого я дал Codex'у задачку посложнее - построить веб-платформу уровня express или fastify. У меня уже был пакет @flancer32/teq-web - я его вручную создавал. Это веб-платформа, сделанная по правилам Tequila Framework (изоморфный код без статических импортов и с поздним связыванием).

Дня 3 мы с GPT-чатом и Codex'ом правили документацию в когнитивном контексте, согласно моей замечательной методологии ADSM. Вчера Codex на основании этой документации перевёл код пакета в режим генерации. Теперь у меня есть уже два пакета, созданные агентом Codex, которые должны как-то коммуницировать друг с другом.

Проблема, с которой я столкнулся - а как объяснить агенту, который работает с @flancer32/teq-web, как правильно применять пакет @teqfw/di? Ведь документация когнитивного контекста пакета слишком обширна и подробна, её нет смысла поставлять в пакете с исходным кодом в изначальном виде.

Отсюда проистекает логичный вывод - нужно делать специальную документацию для агентов и поставлять её в npm-пакете вместе с исходным кодом. Вот в эту сторону я сейчас и копаю...

Между публикацией предыдущего сообщения в ru-канале и публикацией её переводов в en & es каналах прошло чуть больше 45 минут, хотя обычно это минута-две. Объясняется это тем, что телеграм перестал отвечать боту, какие из сообщений опубликованы в канале. Пришлось попросить Codex-агента изменить документацию и код проекта по трансляции телеграм-постов таким образом, чтобы можно было давать исходник сообщения для репоста вручную. Агент всё сделал в лучшем виде.

Вот этот коммит, если кому интересно - https://github.com/flancer64/tg-wa-blog-post/commit/6cc7d8c56094c031a58134b2c7127cc5f7304667

Я рестартанул бота в телеграме. Сейчас проверю, восстановился ли штатный режим.

Восcтановился! (y)

Спросил на reddit'е, есть ли какие-то устоявшиеся практики по объяснению агентам, каким образом нужно использовать тот или иной пакет (maven, composer, npm, ...) - https://www.reddit.com/r/codex/comments/1rmdaxp/agentfriendly_documentation_for_npm_packages_how/

Никто ничего не ответил. Похоже, нет пока что никаких практик в этом направлении. Пришлось вместе с GPT-чатиком самим что-то придумывать. Результат тут - https://github.com/teqfw/di/blob/2.0.3/ai/AGENTS.md

Итого в документации по di-пакету оказалось 6 файлов и 4,164K токенов в общей сложности. Это включая индексный файл AGENTS.md. Можно было бы и одним документом сделать, но чатик посоветовал разбить по темам, типа так агентам проще. Ну, будем наблюдать.

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

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

В общем, я обновил версию @teqfw/di пакета и вставил прямо в README.md ссылку на его онбординг-чат. Попробую каждый своей публичный пакет сопровождать таким онбординг-чатом. А, ну и заодно сменил фокус предназначения всей платформы TeqFW. Сейчас в фокусе - удобство разработки веб-приложений с помощью ИИ-агентов. Оказывается, изоморфизм JS, позднее связывание и namespaces очень хорошо ложатся на архитектуру LLM.

Это мой пакет в NPM-реестре с уже обновлённым README - https://www.npmjs.com/package/@teqfw/di

Сегодня установил Codex-агента в автономном режиме на одном из своих виртуальных серверов (в США). Подключил к Open AI через API-ключ. С третьей попытки удалось уговорить его в автономном режиме создать в текущем каталоге текстовый файл с "Hello World!" приветствием. Он всё в интерактив пытался уйти.

Итого, на создание файла с трёх попыток у агента ушло 10К токенов, что встало в 3 цента. Есть у меня какое-то смутное ощущение, что Codex по подписке явно выгоднее. За 20 евро в месяц он может работать очень долго. Я, по крайней мере, за полгода ни разу в лимиты не упёрся. Но я и не кодил ничего большого через Codex.

В общем, Codex-агент свободно может работать автономно на сервере. Если поставить веб-приложение для получения веб-хуков с GitHub'а (например, при создании issue в репозитории), то можно через это вбе-приложение запускать агента, который будет анализировать содержимое issue и отправлять его в работу или отклонять. При хорошем финансировании можно создать маленькое автоматическое агенство по разработке какого-нибудь приложения. Уж точно, не хуже, чем в Magento будут задачи обрабатываться. Как минимум, быстрее. Но токенов будет потреблять изрядно.

Мой VSCode попросил меня сегодня обновить Codex-плагин. Так как я вчера ставил Codex CLI на сервер, решил сравнить версии. Разработчики Codex'а очень часто релизят новые версии, иногда несколько раз в день. Поэтому я поставил на сервере ежедневное автообновление через cron.

Так вот, сейчас у меня на сервере стоит версия codex-cli 0.114.0, а в VSCode после обновления - codex-cli 0.115.0-alpha.11. То есть, в автономном использовании находятся более устойчивые версии, а проверка устойчивости производится на людях. Причины очевидны - бесплатные тестировщики с обратной связью.

Вот, куда движется индустрия - код пишут роботы, тестируют люди.

Мы это ещё в Magento проходили. Только там люди и тестировали, и код писали. Насколько ж всё-таки ребята в Magento Team обогнали время!! Зато я знаю, что будут ощущать агенты, которые будут править код в ветках, где люди ходят не слишком часто! :)

Сегодня мой codex-агент делал для меня компонент для runtime-конфигурации моего npm-пакета @flancer32/teq-web (веб-сервер для приложений в стиле TeqFW). Я ему в спецификации дал код с примером, как надо, но он сделал по-своему. Попросил его объясниться. Агент мне поясняет, что "как в примере" он сделать не может - падают тесты из-за моего другого пакета - @teqfw/di. Потому как в нём сделаны лишние проверки. Этот код, кстати, тоже codex-агент делал.

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

Ну он и сделал. Вот эта задача - https://github.com/teqfw/di/issues/33

Осталось придумать, как заставить codex-агента на сервере забирать задачи с GitHub'а, фиксить их и отдавать результат. Вернее, это уже всё придумано до нас. Осталось реализовать, чтобы было и у нас тоже.

Сделал шлюз между GitHub Issues и Codex-агентом. Пока что это proof of concept, но вполне себе рабочий. Шлюз подключается к GitHub от имени пользователя adsm-agent (скрин приложил). Замкнул на этот шлюз три своих репо: сам шлюз, сайт teqfw.com и транслятор постов в Telegram на английский/испанский.

Сделал несколько issues, которые обработал агент. Где-то сработал на отлично, где-то вообще не справился. В общем, концепт работает, но нужно доработать до "продажного состояния".

Продублировал последнее сообщение на en & es каналах. Попросил Агента добавить в "tg-wa-blog-post" возможность обрабатывать изображения, приложенные к посту через этот issue - https://github.com/flancer64/tg-wa-blog-post/issues/6 Агент что-то там даже сделал и поставил вот этот PR - https://github.com/flancer64/tg-wa-blog-post/pull/7 Я его слил в основной код и пошёл проверять на практике. В результате Телеграм боту никакого уведомления о новом сообщении не прислал и я подумал, что это новый код виноват. Отправил сообщение вручную, через текстовый файл. Настроил проверку бота на другом канале и проверка пробила основной канал. Итого в en & es каналах теперь по два одинаковых сообщения - первой с ручной вставкой изображения (copy - paste), второе - обработано приложением.

Это сообщение также тестирует работу автоматического ретранслятора, поэтому я приложил скриншот (не особо информативный).

Ну вот, в этот раз картинка ретранслировалась без проблем. Хочу обратить внимание, что код по ретрансляции картинок полностью написан агентом через issue на github'е. То есть, схема вполне рабочая.

Эх! А так всё хорошо начиналось! Похоже, я испортил GItHub :( Не весь, конечно. Только свой репозиторий. Но тем не менее...

Сегодня сделал при помощи Codex-агента свой первый agent-skill - проверка формата ESM-кода на совместимость с моей платформой Tequila. Там всего-то три проверки, больше интересовал сам принцип создания и подключения скилла. От момента создания первого issue и до публикации скилла в npm-реестре прошло 40 минут.

"И вот эти часы этот скилл!" (с) Pulp Fiction

https://www.npmjs.com/package/@flancer32/skill-teqfw-esm-validator

P.S.

Ктати, я вчера GitHub починил - просто сделал logout и login. Надеюсь, никто даже не заметил, что я его сломал.

Сегодня сделал 4-ю версию скила "@flancer32/skill-teqfw-esm-validator". Практически всю работу делал агент через VSCode плагин. Итого получилось 12 проверок:

- RequireDefaultExport — у модуля должен быть export default.
- NoCommonjs — запрещены require(), module.exports и exports.*.
- NoStaticImports — запрещены статические import и статические re-export'ы.
- DependencyPosition — __deps__ должен быть последним top-level export.
- ValidateDepsExport — __deps__ должен быть frozen descriptor object и совпадать с параметрами конструктора.
- ConstructorClosureBehavior — у экспортируемого behavior-класса должен быть constructor.
- ExportedClassBehaviorScope — проверки class-behavior применяются только к экспортируемым классам.
- NoClassFieldBehavior — у экспортируемых классов не должно быть class fields.
- NoPrototypeMethodBehavior — у экспортируемых классов не должно быть prototype-методов.
- NoClassInheritanceBehavior — экспортируемые behavioral-классы не должны наследоваться от других классов.
- ModuleTopBlock — модуль должен начинаться ровно с одного leading JSDoc-блока.
- ConstructorDepsParameterName — для DI-конструктора structured parameter должен называться deps.

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

Вчера не сдержался и написал статью на Хабр по поводу стоимости кода, создаваемого ИИ-агентами - https://habr.com/ru/articles/1023900/

Нам для следующего семейного мероприятия понадобился плейлист в Spotify из 100 песен примерно. Возникла идея написать приложение через Codex-агента. Примерно через два часа моего чистого рабочего времени и где-то 10-20 минут времени работы агента я получил нужное приложение. Стало любопытно, насколько хорошо удерживается поведение контекста, который я создаю по своей методологии ADSM (разновидность Spec-Driven Development'а). Я попросил агента удалить код и тесты и с нуля, на основании одного лишь контекста, сгенерировать код приложения заново. Два раза - для модели GPT-5.4 и для уровня размышлений medium & low. Первоначальный код был написан на уровне GPT-5.4 high. В общем, агент справился достойно. Он подтвердил мой тезис о том, что когнитивный контекст (документация) удерживает управляемость в ходе развития приложения. Итого, одна генерации кода агентом стоила примерно 4% от недельной квоты подписки ChatGPT Plus (20 евро/мес.). То есть - примерно 20 евроцентов.