User writes an issue, agent updates the site. Yes, I did that

Three months ago, in February, I left a comment that LLM agents can update the codebase based on end user tickets and immediately roll out to production. Some colleagues supported this idea, others criticized it on the contrary. This is normal, we all have our own experience that shapes our thinking

My experience tells me that agents can be arranged in a chain: you feed a task (issue) as input, and get a ready-made result (code) as output. Or a processing rejection along with the reason for the rejection — that's also a valid result. After all, that's exactly the chain I built. A chain that automatically, without any involvement from me, turns any GitHub user's request into a page on my website. Or doesn't turn it into a page if it deems it unnecessary. Now any GitHub user can not just criticize my February comment, but do so substantively — demonstrate in practice that agents really can't handle the tasks assigned to them. Or confirm in practice that they can.

This is a simple web application that registers events from GitHub repositories via webhooks and spins up a Docker container with an agent inside in response to specific events. The agent analyzes incoming data, makes decisions, modifies code, and deploys the result to production via GitHub Actions. In fact, there are 8 different profiles for the Codex agent: 8 different initial prompts, 8 different roles. Their sequential application allows a user's issue to be turned into a page on my website.

This is absolutely not a production-ready solution. I built this pipeline primarily for my own use. The pipeline can be configured to only run agents for specific GitHub users. I already have several such pipelines set up on different repositories. But this pipeline here I configured without any restrictions on the issue author. Anyone can post an issue and check the work result: what the agent did, whether it made it to publishing the page, and at what stage it "cut off". The particularly curious can even try to break the environment the agent runs in, or force it to do some mischief on external resources. The only thing keeping the agent within bounds are the initial prompts. I am sure there are ways to make agents perform illegitimate actions, but I am also sure there are ways to restrict agents' ability to perform illegitimate actions. In any case, responsibility for using the tool lies not with the tool's developer, but with its user. Just keep that in mind.

I invite all enthusiasts and skeptics to try this pipeline in action themselves. Test your expectations and concerns. And in return, I get hands-on experience operating the product in its "natural habitat" :)

File a ticket - https://github.com/flancer32/site-teqfw/issues

View the result - https://teqfw.com/demo/pages/

Yes, the agent that performs the processing is Codex with the gpt-5.4-mini model at the lowest reasoning level, running on the cheapest tariff. That means there will be no "intelligent behavior" miracles. But personally, the most important part of this experiment for me is predictability. Will the pipeline work the way I expect, or will the curious minds of experimenters, if any exist, be able to stump me?

Comments

    Also read