Opus 4.5, which was somehow released less than a year ago, felt like a paradigm shift in how people used LLMs to code. Coding agents, once relegated to encapsulated, carefully scoped changes, could now implement full features, usually with a little steering and supervision along the way. The model (and harness) were now smart enough to determine what mattered, find it in the codebase, reason a bit, come up with a plan, and make code changes. As vague as that process sounds, it does roughly correspond with the process for adding a well-defined feature to an existing codebase: observe general architecture, see where specific things are, see how they fit together, think about where to put changes, put them in.
Fast-forward nearly a year and pretty much any LLM + harness combo can do this. Some certainly do it better than others, some faster, some with fewer tokens, but the ability to make a tightly-specced code change in Q4 2026 is table stakes. What people are craving now, and what I think Opus 5.5 delivered on, is:
- The ability to distinguish what is reasonable from what is technically possible
- Using that judgment to know when it is appropriate to address something autonomously versus asking the human or choosing a simpler path
Autonomy is not judgment
The second point is particularly important, because I think that there is often tension between (1) and (2). Autonomy over a long period of time is being conflated with competence in what the model is supposed to accomplish over that same period. As labs increasingly pride themselves on their models' ability to handle long-running tasks, a model deciding to stop 'early' is seen as an objectively bad thing. What's more, harness-level tools like ‘/goal’ are effectively stopgaps to force end user behavior that emulates what people think models should be doing on their own. However, just because a model can be trained or otherwise forced to run for hours on end without human interruption doesn’t mean it possesses the reasoning ability to produce a good result over that time or even a finite amount of time.
The missing capability was the judgment required to know when endless autonomy was appropriate in the first place. A model must understand the user’s goal well enough at every stage of the process to decide which technically valid actions are proportionate to that goal. I think most developers’ frustration with even the latest crop of frontier-level models was that you would look away for 5 minutes and the model would act like a junior dev trying to farm karma on r/maliciouscompliance. If you said “reuse existing methods when possible” and the reusable method happened to live in a private class in another package, the model would make the class public. That would inevitably create a cross-package dependency conflict, so now the agent had to resolve that too. Then it would (far too late) discover package A, in 300 different files, calls a method deprecated in the version package B uses, so, naturally, that would need to be fixed as well and oops it just burned through your weekly usage quota.
What did you supposedly do wrong?
Putting this into human terms, suppose you were the engineer who wrote that request. What would you have needed to do to prevent this through instructions alone? The answer is at once straightforward, long-winded, and boring: when making the judgment call to "reuse existing methods when possible", you failed to consider that one method that could be considered reusable lived in another package in a private class. And why didn't you know that? Because you had to look through a shit ton of code in the current package and, at some point during that process, you were so focused on cataloging every reusable method in the current package that looking through other packages slipped your mind. Or maybe you just hadn't considered it in the first place, just as we collectively fail to consider the millions of edge cases in code shipped every day. Had you seen it or thought to look, of course you would have known it wasn't worth it to refactor the entire class plus a dependency just to re-use one method.
Perhaps if you were feeling particularly diligent that day, you would have gone back and updated your earlier statement (assuming it was in writing) to "reuse existing methods in the current package and public classes in other packages when possible". But even that is, arguably, a waste of your time, since you work with reasonably competent people. Failing to perform that entire sequence doesn't make you a bad engineer; any engineer encountering the situation later on would, at best, automatically (read: autonomously) make the correct judgment call based on the context of the task at hand and, at worst, know to clarify with you before performing that idiotic refactor.
With LLMs, it feels like we gave up the 'at worst' case over the past few months without gaining the 'at best' equivalent. Ironically, they would actually be good at the mechanical labor, poring through file after file, that led to your 'downfall', but, once the orders are given, they lacked the discernment that would've told you to at least ask. Doing all that refactoring is certainly possible in the literal sense, and you said “when possible”, so what did the model do wrong? It can run as long as it needs to, after all, especially if you enable automatic usage credit top-ups. In reality, any sane developer would have just rewritten (read: copy/pasted) the method and called it a day because they actually wanted the underlying task to get done. No one interprets ‘possible’ as ‘perform an unlimited amount of collateral refactoring to make it possible’, especially when the request was scoped as a quick change. When something unplanned comes up, possible typically means one of: convenient, absolutely necessary, or with a host of tangential benefits.
The limits of scaffolding
I think the industry push toward longer and more autonomous runs, before models had the judgment to manage that autonomy well, explains why many, including myself, felt that these models were regressing from ~March to now. Unlike many employers, we weren't trying to fully replace ourselves, so it was actually more impressive to have a model stop and defer to us frequently and properly implement the grunt work in between our competent, human judgment calls than to have one that relied on its own bad judgment. To be clear, there are many long-running tasks that agents are good at. These tend to be tasks composed of discrete, unambiguous steps, with clear beginnings and ends and well-defined handoffs between them; many of the featured or prominent use cases for agents like Manus, Dots, and Muse look like this. Unfortunately, that describes only the easiest parts of software development.
I love a Bijan Bowen one-shot 0-1 WebOS demo more than anyone, but when it comes to actual software development work, I preferred when the model would come back to me with a question before proceeding. Instead, models began to take the longest, most complicated, and most expensive path to being ‘technically correct’, which is often a sisyphean task that I would end up interrupting. But how do you account for that sort of ‘common-sense’ that is common among humans but not-so-common among LLMs?
Just as ‘/goal’ was harness-level scaffolding for models that stopped too early, ‘/plan’ increasingly feels like scaffolding for models that are unable to contextualize and scope the task at hand and instead go too far. Planning mode attempted to solve this by forcing the model to surface every foreseeable ambiguity, emphasis on foreseeable. Because guess what: in engineering, things are often not foreseeable. Plus, it mapped well onto how we humans develop software. However, much like a design review, you can spawn as many explore agents as you want during the planning phase, but it’s impossible to anticipate every single thing that a model would end up being ‘stupid’ about. This is for no reason other than the fact that it’s hard to enumerate each instance you'd need snap-second common sense: Tide Pods did not have a ‘do not eat’ warning pre-2018 because, when writing the safety label for their laundry detergent, they hadn’t accounted for the edge case of teenagers consuming cleaning products for clout.
Intent at every step
- Prompt
- Understand intent
- Observe
- Reason
- Implement
- Prompt
- Observe
- Reason
- Implement
I think Opus 5.5 has done a lot to close this gap. If Opus 4.5-era models had finally learned the linear process of prompt, understand intent, observe, reason, implement, Opus 5.5 turned this into a graph where 'understand intent' feels less like a discrete step and more like it is implicitly baked into each node. We could speculate endlessly about how Anthropic did this: their models tend to be bigger in size, they’re known for their emphasis on post-training and alignment, or maybe they just got lucky this time. Regardless of how they did it, I think Opus 5.5’s ability to sniff out the latent intent behind the user’s ultimate goal and synthesize it with the current step of the task at hand is what is blowing people away. It is the first model whose competence feels commensurate with its level of autonomy in writing software. In the name of developers’ wallets everywhere, I hope that other labs are able to quickly figure it out and follow suit.