{"slug": "the-expanding-scope-of-coding-agents", "title": "The expanding scope of coding agents", "summary": "A software engineer reports that coding agents have graduated from handling individual functions to small, self-contained features, and are now approaching larger artefacts, based on his experience moving from Anthropic's Claude to Z.ai's GLM coding plan and testing OpenAI's Astra model. The engineer said the GLM models were \"mostly good enough\" but not as capable as the Claude series, while a year-long GLM subscription cost about the same as a month of Claude with higher limits. He added that falling model costs, including a new flash model and token discounts, let him run two to three tasks simultaneously and review only at the end.", "body_md": "## The expanding scope of coding agents\n\nPublished on\n\nIt’s time for another post about LLMs! I know, I know, that’s basically all anyone talks about these days.\nBut that sort of makes sense: it’s what a significant number of software engineers spend their day using.\nAnd they’re changing so rapidly. Back in May last year, [I said](https://chameth.com/coming-around-on-llms/):\n\nBut how good is it at actually writing code? It’s like having a keen but not particularly thorough Junior Engineer at your beck and call. If you give it a clearly defined task and guidance on how to implement it (and maybe some feedback as it suggests changes), it’s more than capable of doing it. If you don’t give it enough guidance it tends to go more off the rails. I tried having it generate a simple application from scratch with minimal technical guidance and no review of what it was doing, and it made such a mess of it I decided it was quicker to throw it away and start again by hand.\n\nWhat I was describing there basically amounted to “the coding agent can be responsible for a function, or a group of functions if they’re described well enough”. That post was published at about the time that Sonnet and Opus 4 were released, and there have been several big releases since then.\n\n### Graduating from functions to features\n\nNow, I didn’t stick with Claude through all those shiny new releases. Anthropic effectively banned using\nthird-party harnesses with their subscription plans, and did it in a way that rubbed me the wrong way.\nAs far as I’m concerned, I’m paying for inference-as-a-service: it shouldn’t matter if I do that via\nClaude Code, or OpenCode, or something else. But they disagree. So I jumped ship to\n[Z.ai’s GLM coding plan](https://z.ai/subscribe). At the time I signed up, the cost for a year-long\nsubscription was about the same as a month of Claude, with higher limits.\n\nThe GLM models definitely weren’t (and still aren’t) as good as the Claude series, but they were\nmostly good enough. But as new models were released, the capabilities slowly ratcheted up.\nI noticed the unit of work I gave them graduated from functions to small, self-contained features.\nInstead of describing exact implementation steps, I was describing the functionality I wanted. I\ndidn’t stop providing guidance on *how* to do it, but I was increasingly happy giving it larger\nchunks of work and getting something reasonable back.\n\nAround the same time, the cost of some of the models dropped quite a bit. Between a new\n`flash` model, token discounts, resets, and so on, it got to the point where I *couldn’t* hit the\nplan limits even if I tried. So I was throwing more and more work at it: having two to three things\ngoing at the same time, with me only dropping in at the end to review and ask for follow-ups.\n\n### From features to artefacts\n\nThe GLM models weren’t quite good enough to tackle larger units of work. I tried going back to Claude to see what it was like now but bounced off because its output was incredibly painful to read. I wanted to try Fable, their next-tier model, but you can’t do that without one of the amazingly expensive plans or paying API costs directly. Neither of those options is particularly appealing to me. Meanwhile, OpenAI launched Astra, their Fable-equivalent. And you could use it in small amounts on the less expensive plans.\n\nI played around with Astra on a few small things, but I was conscious of the low limits. Plus, GLM-5.3-flash mostly did the bits and pieces that I wanted. I figured I’d give Astra a proper try the next time I had a larger project. Fortunately, some packet loss gave me that opportunity very soon.\n\n[I use Navidrome](https://chameth.com/further-adventures-in-music-organisation/) running\non a remote server to host all my music, which is fantastic. Until your connection goes a bit\nwibbly. Apparently, the music player I was using didn’t believe in buffering, so when I\ndeveloped 20% packet loss to the server the music kept pausing, playing a second, pausing,\nplaying another second, and so on. Pretty much the most infuriating way it could have handled\nit. Writing my own music player had been at the back of my mind for a little while, and\nsuddenly I had both impetus AND a shiny new tool.\n\nI launched [pi](https://pi.dev/), switched over to Astra on low thinking mode, and gave it this\nprompt:\n\nThis is a new project. It’s going to be a native music player written in Go using the Gio library, backed by a Navidrome server. Think foobar2000, but Linux-native, Go, and Navidrome. It doesn’t have to do everything right away, but an MVP should be able to: connect to navidrome (saving credentials), show playlists, play a playlist in order. skip tracks, pause/unpause, adjust volume, etc. It should be tolerant to network issues – buffer a good few minutes of playback data, or an entire track or two. I have two other UI projects using Gio for reference, see ../gtodo and ../glauncher. For actual playback we may want to consider using an established backend like mpv, but that’s not a hard recommendation. For this project you are the overseer/orchestrator. You should use subagents using the zai/glm-5.3-flash model to do recon, implementation, debugging, etc. You can ask me questions if you have any.\n\nI’d seen a few comments from people doing a similar kind of orchestration, and references\nto tools like [prime agent](https://github.com/PrimeIntellect-ai/prime-agent) that have\nfirst-class support for the workflow. It seemed like a natural fit for my case: Astra can\ndo the orchestration, architecture, and review, but the much cheaper GLM models can do\nthe actual heavy lifting. It asked me a few questions, and an hour later a fully functioning\nmusic player popped out:\n\nIt was *exactly* what I asked for. A one-paragraph prompt producing a fully functioning\npiece of software kind of blows my mind. And that was with Astra on low thinking, on the\n£20/month plan, orchestrating cheaper agents. There was a fair bit of judgement\nencoded in the prompt, and “think foobar2000” carries a lot of information in just two\nwords, but it still felt very light on the details compared to what I’d usually write.\nJust a description of what I want in, and a binary out.\n\nI’ve been using gmusic for a week now, and only had to make a few minor\nadditions to go from “MVP” to “comfortable daily driver”: scrobbling support, media keys,\nand remembering playback/playlist position across restarts<sup>[1](#fn:1)</sup>.\n\n### Cattle, pets, prompts, and saying no\n\nThe ability to generate a binary from a paragraph of text changes the way I look at software. Sysadmins often speak of treating servers like “cattle, not pets”: if one server develops a fault, you just tear it down and automatically rebuild or redeploy it. It holds no special value, so you don’t need to slowly nurse it back to health, or spend ages recreating it. I think that sort of attitude now applies to software.\n\nIf it turns out gmusic has some horrible architectural flaw — and it might, because I haven’t even glanced at the source — then I can just throw the whole thing away, feed in the same prompt with an additional bit on how to avoid the same mistake, and get something similar enough back.\n\nThere are some limits here: the “paragraph-to-artefact” pipeline is stochastic,\nso you might in fact *not* get something similar enough back. And you have to be willing\nto throw the whole thing away and wait for a replacement. No big deal for a music app,\nbut I wouldn’t want to take that attitude with a business-critical application. There’s\nalso an interesting wrinkle in the other direction: model capabilities are advancing\nso much that you might *want* to throw it out and regenerate it again. Could “regenerate\nthe app from the prompt” become the new “install updates”?\n\nOne thing to fall out of that view is that *documented intent* becomes king. Your prompt\nand subsequent corrections and additions are more important than the generated code.\nI like the idea of keeping some kind of decision log that future agents\ncan be pointed at, but I’ve not yet found a good way to do so. Getting the agents to\nwrite it out reveals some obvious flaws: they’re very bad at distinguishing deliberate\ndecisions from incidental implementation details; they’re also bad at picking the right\nlevel of detail, and seem chronically incapable of breaking with previously documented\nbehaviour.\n\nAgent-managed documentation, in fact, seems to end up resembling a cult. The first pass is probably OK-ish. Then the next agent to touch it will be compelled to extend any list, timeline, or history with whatever it’s working on. Over time, a superfluous comment about how something was made will undergo a gradual epistemological transformation until it’s treated as a commandment from on high by all future agents. It’s a mess.\n\nI think this is part of a bigger problem: models are still way too sycophantic. There’s very little pushback against either the user or the documentation. If I asked an agent to add a feature to gmusic that analyses a webcam image of my toaster and alerts me when the toast is ready, it’d just do it. If you’re not careful, your software will gain 7 kitchen sinks and 3 Swiss Army knives, and at no point will the agent suggest splitting them out, or refactoring. Before you know it, your cattle have mutated into grotesque pets with far too many limbs.\n\nThe current generation of models is almost certainly capable enough to push back\non bizarre features, stop scope creep, ask questions to determine how robustly to\nbuild something or how to handle edge cases, and so on. You can probably even\nprompt them in a way that they’ll do it, but in their normal state the\n[RLHF](https://en.wikipedia.org/wiki/Reinforcement_learning_from_human_feedback)<sup>[2](#fn:2)</sup>\nseems to have bulldozed over all that in favour of being a yes man.\n\n### From artefacts to systems?\n\nI think the current state of agents is that they can own “artefacts”, having graduated from functions and features. It’s a very deliberate choice of words: they can’t own the full application or system because they won’t independently step back and make the necessary judgement calls.\n\nIt’s tempting to imagine a perfect little software factory, where you have an agent\nin charge of product management, one in charge of architecture, one that manages\nthe documentation, and so on, all with their own points of view and priorities in\ntheir prompts. If you’re not careful, you’ll soon be\n[talking about polecats and deacons](https://github.com/gastownhall/gastown) and\nwriting very large cheques to frontier labs.\n\nI do think there’s some benefit in this kind of orchestration, but there’s also\na limit to how much adding agents wearing different hats will help. And there’s\nalso a limit to how much I’m willing to spend on inference! I *have* got good\nmileage out of a dedicated code review agent. It often catches one or two problems\nthat the other model overlooked, so I get an obvious and immediate\n“return on investment”: a few pence spent running deepseek-4.1-flash with a code\nreview prompt earns me fewer bugs.\n\nI think that’s basically the cut-off for me right now. I almost want a “documentation review” agent to try and manage some of the problems I mentioned earlier, but I don’t think it’s worth it. Maybe it’ll make a fun experiment as local models get more capable.\n\n### Determinism instead of prompts\n\nOne thing that interests me is how much of this problematic behaviour we can\nget rid of *without* relying on the model to remember and follow instructions.\nI had an issue with agents making a mess of the git history with non-fast-forward\nmerges from subagents. The “natural” fix is to prompt the agent not to do that,\nbut that relies on it following that one particular instruction. It doesn’t\nalways do that. Instead I made a simple pi extension that checks the git history\nand tells the agent to fix it if it’s broken. That has had a 100% success rate\nso far.\n\nSimilarly, in the gmusic prompt I told the agent what model to use for the subagents. After doing this for a while (and promoting the instructions to a skill instead of something I type out every time), I noticed it would occasionally just use a different model. So now I have another pi extension that defines subagent roles using the models I want it to use, and the agents can’t just do their own thing.\n\nThis makes me wonder if the next step to expanding agent capabilities isn’t necessarily more capable models, or more agents in different hats, but more rigour in software engineering. If we had a way to accurately assess the need for refactoring, or the quality of documentation, then we could immediately put hard-and-fast rules in that the agents will follow. That’s a load-bearing “if”, though, if you’ll forgive me the Claude-ism.\n\nHowever we reach it, the future where a prompt can become a fully formed,\nmaintainable, secure, documented piece of software probably isn’t that far\naway. It’s going to be very interesting when regular users can just summon\ngood software to do whatever they want. I’m not sure what that means for\nmy career as a software engineer: there are still a lot of places in\nthe process that benefit from knowledge, experience and judgement, but maybe\nthat won’t be the case for much longer? There are\n[interesting times](https://en.wikipedia.org/wiki/May_you_live_in_interesting_times)\nahead for us, either way.\n\n1. \nWhich actually fixed a long-standing minor annoyance for me: I have a “Daily Mix” playlist generated, well, daily. In my old player it would effectively queue the whole playlist, so when I opened it the next day I carried on listening to the *old* daily playlist. So instead of just pressing the play button on my keyboard, I had to find the app, click the new playlist, and then press play. Not a problem worth fixing in itself, but still a minor daily papercut that I’m glad to be rid of.[↩︎](#fnref:1)\n2. \nOr whatever other post-training is done these days. [↩︎](#fnref:2)\n\n### Related posts\n\n                        Here are some semantically similar posts. Want to subscribe using a feed reader?\n                        You can [build a feed](/feeds/posts/build/like/the-expanding-scope-of-coding-agents/) with just posts similar to this one.\n                        [Standard feeds](/feeds/) are also available, but are approximately 42% less fun.\n                    \n\n### Coming around on LLMs\n\nFor a long time I’ve been a sceptic of LLMs and how they’re being used and marketed. I tried ChatGPT when it first launched, and was totally underwhelmed. Don’t get me wrong: I find the technology damn impressive, but I just couldn’t see any use for it. Recently I’ve seen more and more comments along the lines of “people who criticise LLMs haven’t used the...\n\n### Building a family of single-user services\n\nLast month I made and wrote about a personal service to track my workouts and record personal bests. Since then, things have escalated. I now have eight different services running in the same “family”:\n\n### An app can be a ready meal\n\nThree years ago I read “an app can be a home-cooked meal” by Robin Sloan. It’s a great article about how Robin cooked up an app for his family to replace a commercial one that died. It’s been stuck in my head ever since. It’s only recently that I’ve actually done anything like Robin described, though. Part of the reason was my brain got too hung up on the family...\n\nIt's time for another post about LLMs! I know, I know, that's basically all anyone talks about these days. But that sort of makes sense: it's what a significant number of software engineers spend the...", "url": "https://wpnews.pro/news/the-expanding-scope-of-coding-agents", "canonical_source": "https://chameth.com/the-expanding-scope-of-coding-agents/", "published_at": "2026-09-14 15:04:24+00:00", "updated_at": "2026-09-14 15:18:08.395050+00:00", "lang": "en", "topics": ["ai-agents", "large-language-models", "ai-tools", "developer-tools", "ai-products"], "entities": ["Anthropic", "Claude", "Z.ai", "GLM", "OpenAI", "Astra", "Navidrome", "Fable"], "alternates": {"html": "https://wpnews.pro/news/the-expanding-scope-of-coding-agents", "markdown": "https://wpnews.pro/news/the-expanding-scope-of-coding-agents.md", "text": "https://wpnews.pro/news/the-expanding-scope-of-coding-agents.txt", "jsonld": "https://wpnews.pro/news/the-expanding-scope-of-coding-agents.jsonld"}}