Next steps for CLI coding agents

Context is still king

After having used tools ranging from Opencode to Claude Code, Amp, block, Github Copilot, agentic IDEs like Windsurf and Cursor, I think the next frontier for coding agents is a simple extension on the current SOTA: more agency.

Currently, state-of-the-art coding agents can flesh out features end-to-end, but not without A LOT of toil.

You need to know how to manage context, know exactly what you want to build, codify it in a way the agent knows where to look and what to look for, document the quirks that inevitably will be part of your company’s codebase, add all your edge cases, and finally, be ready for a lot of reverting, deleting weird tests and plain out throw it all away because it STILL build the wrong thing. Meanwhile, you wasted 10 USD and 2M tokens on an under-specified feature.

This is not the promised land, the bright future where all engineering efforts are magically replaced by agents, and engineers will lose their jobs. Be very sure: the hype around AI automating or replacing software engineers IS ILL-PLACED FOR NOW.

The current tools, besides having a limited context window size, have the problem of needing context to be built and rebuilt over and over, knowledge re-distilled into tokens again and again. This is both frustrating and expensive, especially when a mistake in the middle of the process derails the entire feature.

Now, many systems have been built and are effective against this: the famous AGENTS.md style file, where knoweldge and patterns are distilled into a set of reusable directives that the models can read and re-read as needed, works super well, but, the issue is still there at runtime if the model makes a mistake.
Then you can abort the failed inference attempt, fix your file, and try again.

The problem? It’s a reactive approach. The fix can only happen AFTER time has been wasted and the agent has gone off the rails.

So, what is the next step?

My hypothesis is that 200K-1M tokens, while still very limited, it’s still plenty, and you can leverage that bandwidth to improve the behavior during the inference process. How? By simply turning the agent into a true pair programmer.

The idea is that while you work with the agent in your codebase, you will generate a lot of implicit context: You will create a manually tailored AGENTS.md, you will document some of the quirks of your in-house frameworks and you will tell Claude that you are actually using Java 23 for this project, even if your system uses 21, etc, etc.

Now, what if you could use all that knowledge and combine it with structured outputs to make the agent propose several ideas for a complex task? That’s the idea I have been toying with:

A true agentic agent - pun intended

Imagine this: Your most important architecture details are in place, your objectives are well-defined, and you have a complex task to tackle.

Instead of letting the agent work blindly, what if you could turn it into a true architect that can propose different technical approaches anchored in timeless, deterministic, and battle-tested software engineering principles?

This is, in my humble opinion, the next frontier for coding agents: tailoring their own behavior to specific codebases, special quirks of your company frameworks, and business requirements, in a way that makes them highly effective.

If you combine this with a good harness around these models, I can promise you that the future is not here yet, it’s just being imagined and shaped as we go!

Keep coding!