Notes on working with coding agents as of October 2026

I’ve been making a few changes to how I work with LLMs, and I want to record them before I forget. Some are small improvements to prompting. Others involve rethinking how I want to build software altogether.

I’d like to implement these properly, rather than keep rediscovering them in individual conversations with coding agents.

1. Standardise as much as possible

One idea I’ve been thinking about is reducing the amount of choice involved in building software.

There are an enormous number of ways to accomplish almost anything in software development. Frameworks, databases, hosting providers, queues, authentication systems, deployment processes. Even a relatively simple application can involve a surprising amount of architectural decision-making before it does anything useful.

This creates additional work for coding agents. They need to choose an approach, understand the relevant APIs, configure the tools, and make sure everything fits together. Every additional technology introduces more opportunities to make mistakes.

I’m increasingly attracted to choosing a single platform and leaning into its conventions.

Cloudflare is a good example. Workers provide a way to run code, with services such as D1 available for storage. There are established patterns for many common tasks, and agents can search the documentation through Cloudflare’s MCP servers.

The command-line tooling is particularly useful. An agent can create projects, provision databases, deploy Workers, and inspect the platform without needing me to click around in a web interface. Much of the work involved in starting and maintaining a project can use the same tools and conventions.

The usage-based pricing is another attraction. For small projects with little traffic, the additional running cost can be tiny, depending on the services and plan. That makes another experiment easier to justify.

Of course, going all in on one vendor creates dependencies. I think that’s a reasonable trade-off for many of the projects I want to build. The consistency has real value, particularly when an agent is responsible for most of the implementation.

I suspect standardisation becomes increasingly useful as we delegate more work to agents. A predictable environment means fewer decisions, fewer unusual configurations, and less bespoke knowledge needed for every project.

2. Go cold turkey on writing code

This is the more speculative idea, and probably the biggest change to how I work. I think we’re in an awkward intermediate stage of software development.

Previously, developers wrote the code themselves. Now, many spend their time orchestrating LLMs that write it. They describe what they want, watch the agent work, review the output, correct mistakes, and repeat.

I originally thought experienced developers would continue working this way for some time. The developer would remain in control, using an LLM locally to execute their ideas. I’m becoming less convinced that this is a sustainable way to work.

There is something exhausting about constantly managing an agent. You’re responsible for everything it produces, but increasingly detached from the implementation. Much of the enjoyable, hands-on work has been delegated, leaving you with the job of supervising it.

I suspect this contributes to some of the frustration and burnout developers are experiencing with AI coding tools. And if agents keep getting better at writing code, I don’t see us returning to developers doing most of the implementation themselves.

The natural progression seems to be towards agents orchestrating other agents, with developers working at a higher level. That means we should probably start taking agent orchestration much more seriously.

I’m beginning to think the best way to make this transition is to deliberately stop working with coding agents locally. Instead, build an orchestration system in the cloud and force myself to interact with it through tasks and outcomes.

This is a bit like going cold turkey. If I have a local coding agent sitting in my terminal, the temptation will always be to jump in, make a few changes, and rescue it whenever it gets confused. That might get the immediate job done, but it doesn’t help build a system that can operate independently.

Removing that option would force me to solve the orchestration problems properly. The work becomes designing a system that can reliably use agents to develop applications, rather than supervising every coding session myself.

The direction I have in mind is an agent that stays with a task. It keeps the context, helps work through the requirements, and carries changes through to a pull request. Questions and review feedback become part of the same ongoing conversation, with the system deciding when to continue coding, check the result, or wait for a human answer.

I’d want to work through the issue tracker and code review, with enough history to understand what happened when something goes wrong. Each failure should help improve the orchestration, rather than become another reason to open a terminal and finish the job myself.

That will probably be quite frustrating at first, particularly when I know I could fix something myself in five minutes. But if I keep doing that, I’ll never find out what it takes to make the system work without me.

3. Make the code understandable to humans

Even if I go cold turkey on writing code, there will occasionally be problems I need to dive into myself, and terse, jargon-heavy code written for machines will make that much harder.

An LLM recently described part of a plan to me like this:

Obligations, authority fencing, and recoverable command intents.

I had absolutely no idea what it meant, which seemed a poor start for code I would eventually have to maintain. If this was how the LLM described the architecture, I suspected the resulting code would be full of similarly obscure names. So I responded:

Can you make this more human language? I have no idea what this is and am worried about reading the code afterwards. I feel like it’s going to be this very technical obscure wording that is hard to decipher. Make sure the files, classes, functions, etc. are named as a human would do.

The response was surprisingly good. The LLM explained that it meant:

• Keep track of every request that still needs an answer.
• Stop work from making changes after its permission has been withdrawn.
• Save the chosen action before starting it, so a restart can check what happened and continue safely.

It then proposed names like PendingRequest, SavedAction, saveChosenAction, and checkWorkIsStillAllowed.

Much better. I can read those names and understand roughly what the code is doing. No architectural phrasebook required.

I’ve noticed that LLMs tend to compress concepts into their most concise technical descriptions. They seem quite happy to invent terminology or reach for complicated abstractions even when ordinary English would do. The code might be technically correct, but unnecessarily difficult for a human to understand.

This is particularly irritating when the whole point of using an LLM is to spend less time on implementation. I don’t want to save an hour writing the code and then spend two hours deciphering it.

I followed up with another instruction:

I would like you to evaluate ALL the source code, and create a plan to make the whole thing more human readable and human understandable. Not just the latest work.

This produced a plan to improve readability across the entire codebase, rather than just the parts we happened to be discussing.

I think this is worth turning into a permanent rule for coding agents. It should apply when creating plans, writing code, and reviewing changes. A dedicated review could also periodically examine an entire repository for unnecessary complexity and confusing names.

It fits alongside architectural guidance such as preferring deep modules and keeping implementation details hidden behind simple interfaces. Those principles help make software easier to reason about. Readable naming belongs alongside them.