So, I posted the previous message and just tested my app in real working mode – it works perfectly! Almost no tweaks needed. The agent did everything on its own.

I'm really impressed!!

GPT chat convinced me that since agents are writing code, development specifications should be changed to make coding easier for agents rather than humans. It’s a simple idea, but unusual.

So I decided to put this unconventional solution up for discussion. Yesterday, I made three posts:

- Reddit: 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/

The most positive response was on dev.to. People gave 3 hearts, 1 unicorn, applauded twice, and drew flames once. What all this means is unclear. There was one comment politely pointing out that “there is import maps.” There were about 280 views within a day.

The most typical reaction was on Habr. I got 2 downvotes, 2 people bookmarked the article, and it had around 410 readers. Karlickiy (author of $mol) commented, saying my approach was wrong. But he tells everyone that—that’s his role.

The most interesting was on Reddit. Around 10K people viewed it, there were 39 comments (half were my replies), and the post’s score was 0 (posts start with +1, so overall negative). The Reddit community met the idea of replacing static imports with dependency declarations to shift from early to late binding with rather cool neutrality. But not openly negative like on Habr. So overall, still somewhat positive :)

Probably, this idea of late binding in JS needs to be pushed further.

I’ve split my core package @teqfw/di, which I use to build all my web applications, into two branches.

- Version 1.x: handcrafted code, following the founders’ principles;
- Version 2.x: AI-generated code created by a Codex agent;

The first is made by humans for humans, the second by agents for agents.

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

By the way, automatic translation of messages from this channel into English and Spanish for the en & es channels is done by the app switched by agents to the second version of @teqfw/di. They do it very skillfully.

After splitting my core package `@teqfw/di` into two branches (human and agent), I tested v2 (the agent branch) on my app for translating posts in Telegram channels into other languages. The Codex agent handled this console app just as skillfully as it did the DI package itself.

Then I gave Codex a more challenging task—to build a web platform similar to `express` or `fastify`. I already had the `@flancer32/teq-web` package, which I created manually. It’s a web platform built according to Tequila Framework rules (isomorphic code without static imports and with late binding).

For about three days, GPT chat and Codex helped me revise the documentation within a cognitive context, following my excellent ADSM methodology. Yesterday, based on that documentation, Codex converted the package code into generation mode. Now I have two packages created by the Codex agent that need to somehow communicate with each other.

The problem I faced was: how do I explain to the agent working with `@flancer32/teq-web` the proper way to use the `@teqfw/di` package? The cognitive context documentation for the package is too extensive and detailed—it doesn’t make sense to include it in the package source as-is.

This leads to a logical conclusion—I need to create special documentation for agents and include it in the npm package along with the source code. That’s the direction I’m currently exploring…

There was a little over 45 minutes between the publication of the previous message in the ru-channel and the posting of its translations in the en & es channels, although usually it takes just a minute or two. This happened because Telegram stopped responding to the bot’s requests about which messages were published in the channel. I had to ask the Codex agent to update the documentation and project code for Telegram post translation so that it would be possible to manually provide the source message for reposting. The agent did an excellent job.

Here is the commit, if anyone is interested — https://github.com/flancer64/tg-wa-blog-post/commit/6cc7d8c56094c031a58134b2c7127cc5f7304667

I have restarted the bot on Telegram. Now I will check to see if the normal operation is restored.

Recovered! (y)

Asked on Reddit if there are any established practices for explaining to agents how to use a particular package (Maven, Composer, npm, etc.) – https://www.reddit.com/r/codex/comments/1rmdaxp/agentfriendly_documentation_for_npm_packages_how/

No one responded. It seems there aren’t any practices in this area yet. We had to come up with something ourselves together with GPT chat. The result is here – https://github.com/teqfw/di/blob/2.0.3/ai/AGENTS.md

As a result, the documentation for the di package ended up with 6 files and a total of 4,164K tokens. This includes the main AGENTS.md file. It could have been done as a single document, but the chat recommended breaking it down by topic so it’s easier for agents to use. We’ll see how that goes.

I like the idea of using custom GPT chats. I once tried to write “clear documentation” for my early public library versions. The problem is that readers have different skill levels. Making documentation equally understandable for both beginners and experienced users is a tough challenge. You need to present the material differently.

With customizing a GPT chat, you just describe the product specification, and the chat adapts it to the user’s current level. It can provide more details or keep things abstract. Plus, the chat can communicate with the user in their native language, even if the specification is in English.

So, I updated the @teqfw/di package and added a link to its onboarding chat right in the README.md. I’m going to try including an onboarding chat with each of my public packages. Oh, and at the same time, I shifted the focus of the entire TeqFW platform. Now the focus is on making web app development easier with AI agents. It turns out that JS isomorphism, late binding, and namespaces fit really well with LLM architecture.

Here’s my package in the NPM registry with the updated README — https://www.npmjs.com/package/@teqfw/di

Today I set up a Codex agent in offline mode on one of my virtual servers (in the US). I connected it to OpenAI via an API key. On the third try, I managed to get it, in offline mode, to create a text file with a "Hello World!" greeting in the current directory. It kept trying to switch to interactive mode.

In total, it took the agent 10,000 tokens to create the file over three attempts, costing about 3 cents. I have a vague feeling that a Codex subscription is definitely more cost-effective. For 20 euros a month, it can run for a very long time. At least, I haven’t hit any limits in six months. But I haven’t coded anything big using Codex.

Overall, a Codex agent can easily run autonomously on a server. If you set up a web app to receive webhooks from GitHub (for example, when an issue is created in a repo), you could trigger the agent through that web app. The agent would analyze the issue’s content and either accept it for processing or reject it. With sufficient funding, you could create a small automated agency to develop some application. It would definitely handle tasks as well as Magento does. At the very least, it would be faster. But it would consume a fair number of tokens.

My VSCode asked me to update the Codex plugin today. Since I installed the Codex CLI on the server yesterday, I decided to compare the versions. The Codex developers release new versions very frequently, sometimes multiple times a day. So, I set up a daily auto-update on the server via cron.

Right now, the server runs codex-cli version 0.114.0, while after the update, VSCode has codex-cli 0.115.0-alpha.11. In other words, the more stable versions are used autonomously, while stability testing is done by users. The reasons are obvious — free testers with feedback.

This is where the industry is heading — robots write the code, people test it.

We already went through this with Magento. Only there, people both tested and wrote the code. How far ahead the Magento team was! But I can already imagine what the agents fixing code in branches with little human traffic will experience! :)

Today, my codex agent created a component for runtime configuration of my npm package @flancer32/teq-web (a web server for TeqFW-style applications). I gave it a code example in the specification to show how it should be done, but it did it its own way. I asked it to explain.

The agent told me that it couldn’t do it exactly “like in the example” because the tests fail due to my other package — @teqfw/di — which has extra validations. By the way, this code was also created by the codex agent.

I asked it to create a task for another agent to fix the issue. And so that I wouldn’t serve as an unnecessary middleman between the agents, I told it to create the task directly on GitHub.

And it did just that. Here’s the task: https://github.com/teqfw/di/issues/33

Now, I just need to figure out how to make the codex agent on the server pull tasks from GitHub, fix them, and return the results. Actually, all of that has been figured out already by others. It’s just a matter of implementing it for us as well.

Created a bridge between GitHub Issues and a Codex agent. It’s currently a proof of concept, but fully functional. The bridge connects to GitHub using the user account adsm-agent (screenshot attached). I linked three of my repositories to this bridge: the bridge itself, the teqfw.com website, and a Telegram post translator for English/Spanish.

I created several issues, which the agent processed. In some cases, it performed excellently; in others, it didn’t manage at all. Overall, the concept works, but it needs refinement before it’s ready for production.

Created a gateway between GitHub Issues and a Codex agent. For now, it’s a proof of concept, but it works quite well. The gateway connects to GitHub on behalf of the user adsm-agent (screenshot attached). I hooked up three of my repos to this gateway: the gateway itself, the teqfw.com website, and a post translator to Telegram in English/Spanish.

I created several issues that the agent processed. In some cases, it performed excellently; in others, it didn’t handle them at all. Overall, the concept works, but it needs further development before it’s ready to sell.

I duplicated the last message to the en & es channels. I asked the Agent to add the ability to process images attached to posts in "tg-wa-blog-post" through this issue - https://github.com/flancer64/tg-wa-blog-post/issues/6 The Agent even did something and submitted this PR - https://github.com/flancer64/tg-wa-blog-post/pull/7 I merged it into the main code and went to test it in practice. As a result, the Telegram bot didn’t send any notification about the new message, and I thought the new code was to blame. I sent the message manually via a text file. I set up the bot check on another channel, and the check triggered the main channel. So now there are two identical messages in the en & es channels — the first with the image manually inserted (copy-paste), and the second processed by the app.

This message also tests the automatic relay feature, so I attached a screenshot (not very informative).

So, this time the image was successfully reposted without any issues. I want to point out that the code for reposting images was entirely written by the agent through a GitHub issue. In other words, the system works perfectly.

Oh! And it all started so well! Looks like I messed up GitHub :( Not the whole thing, of course. Just my repository. But still...

Today, with the help of a Codex agent, I created my first agent skill — checking the ESM code format for compatibility with my Tequila platform. It’s just three checks in total; I was more interested in the principle of creating and connecting the skill. It took 40 minutes from opening the first issue to publishing the skill in the npm registry.

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

P.S.

By the way, I fixed GitHub yesterday — just logged out and logged back in. Hopefully, no one even noticed I broke it.

Today, I released version 4 of the skill "@flancer32/skill-teqfw-esm-validator". Almost all the work was done by an agent through the VSCode plugin. In total, there are 12 checks:

- RequireDefaultExport — the module must have a default export.
- NoCommonjs — require(), module.exports, and exports.* are forbidden.
- NoStaticImports — static import and static re-exports are forbidden.
- DependencyPosition — __deps__ must be the last top-level export.
- ValidateDepsExport — __deps__ must be a frozen descriptor object and match the constructor parameters.
- ConstructorClosureBehavior — the exported behavior class must have a constructor.
- ExportedClassBehaviorScope — class-behavior checks apply only to exported classes.
- NoClassFieldBehavior — exported classes must not have class fields.
- NoPrototypeMethodBehavior — exported classes must not have prototype methods.
- NoClassInheritanceBehavior — exported behavioral classes must not inherit from other classes.
- ModuleTopBlock — the module must start with exactly one leading JSDoc block.
- ConstructorDepsParameterName — for DI constructors, the structured parameter must be named "deps".

This is enough for agents to check the general structure of source code in TeqFW projects. Skills have proven to be a powerful addition to the context. Going forward, all context specifications (universal "cross-project" rules) can be moved into skills, creating a specification library accessible online, and agents could be linked to it through skills. This will definitely save tokens for the agents.

Yesterday, I couldn’t resist and wrote an article on Habr about the cost of code generated by AI agents - https://habr.com/en/articles/1023900/

For our next family event, we needed a Spotify playlist of about 100 songs. I had the idea to create an app using a Codex agent. After roughly two hours of focused work on my part and about 10-20 minutes of the agent’s runtime, I got the app I needed. I became curious about how well the context behavior holds up, based on my ADSM methodology (a variant of Spec-Driven Development). I asked the agent to delete the code and tests and regenerate the app’s code from scratch, using only the original context. I did this twice—once with the GPT-5.4 model and once with medium & low reasoning levels. The initial code was generated at the GPT-5.4 high level. Overall, the agent performed quite well. It confirmed my thesis that cognitive context (documentation) maintains control throughout the app’s development. In total, one code generation by the agent cost roughly 4% of the weekly ChatGPT Plus subscription quota (€20/month). So, about 20 euro cents.