Coding Agent Degradation: Cross-Vendor Field Notes and an Initial Analysis

Disclaimer: These are my personal observations and judgments, not the position of my company. My assessments of the tools reflect personal experience rather than a controlled experiment. External research and reports are attributed separately.

This week, working with the latest Grok Build has been painful. Tasks are slower, the allowance drains quickly, and things that once happened without prompting need repeated reminders. I use these tools to develop our own products, but I was again spending too much attention supervising the tools themselves.

I tried Google's available Argon model and Antigravity, and felt something familiar. It worked quickly, produced good results, understood my requests, and kept moving. The available allowance also felt generous. I was no longer constantly wondering how much work I had left before running out.

I have used agents that felt this good before. Claude Code worked very well for me in January and February. Later, I valued Codex's care, and then Grok Build became my main tool. After a while, though, work would start to feel slower or harder: worse reasoning or instruction following in some cases, excessive thinking in others. The good feeling has returned, along with the question: <strong>why does this sequence seem to recur across different vendors' tools?</strong>

There is another change I find puzzling. Some output has become harder to read, less like something written for a person. Writing ability was among the things that originally impressed me about language models. Why do better coding scores not necessarily bring clearer communication or a better development experience?

The following brings together my usage records through October 29, 2026, peer observations, public postmortems, and independent tests. Grok happens to have my August and September praise followed by an October correction, supplying a contemporaneous sequence. Claude and Codex produced their own distinct experiences. This is not yet a controlled longitudinal experiment, but it gives me reason to investigate the changes and how developers can respond.

Some background matters here. Around December 2025, our team began moving to Claude Code. From January onward, I personally used different coding agents intensively to work on product code. These observations come from sustained development work.

Our approach is mix-and-match: typically one agent leads implementation and another reviews the code, alongside ongoing experiments with agent loops and automated software engineering. I have written about IDD (Intent Driven Development), loop engineering from manual cycles to paired skills, and unattended issue/PR loops. Those articles describe how we work. This one records how the tools have changed within that work.

My GitHub activity: 16,471 contributions in 2026 at the time of this screenshot, including commits, pull requests, issues, and code reviews.

Degradation across vendors: how common is it, and is it inevitable?

An incorrect answer can be fixed within a task. A more disruptive problem is a tool that changes after becoming useful: familiar work starts taking longer, consuming more allowance, and requiring repeated reminders and checks. That instability affects how much work I can hand over.

I have experienced declining engineering usefulness in products from Anthropic, OpenAI, and Grok, with corresponding symptoms in other users' public reports. That makes the questions worth asking directly: <strong>how widespread is this experience? Is a new model becoming harder to use inevitable? If causes differ, what shared pressures could produce similar outcomes across products?</strong>

Degradation needs separating into elapsed time, work completed within an allowance, reasoning and instruction following, readability, overengineering, and interrupted workflows. My main Codex complaints are slowness and overengineering, rather than an equally clear loss of intelligence. Studying these symptoms together does not establish a shared backend cause.

My everyday use is real project development, generally at medium or high rather than the highest available reasoning setting; those labels are not standardized compute units across vendors. The assessments come mainly from sustained experience, supported by contemporaneous posts, specific failures, and inspectable reports. I did not preserve every task and configuration, so they cannot establish a precise incidence rate. With that scope in mind, here is how the changes unfolded.

My usage timeline

These tools handled different tasks in the same project. I use dates where I can place them with confidence, without guessing the timing of version updates. Grok's three posts preserve contemporaneous assessments rather than relying entirely on today's recollection.

::::steps :::step{title="Around December 2025 · The team starts moving to Claude Code"} We began using Claude Code in team product development. From January 2026, my personal usage became intensive, while I continued mixing coding agents from different vendors. :::

:::step{title="January–February 2026 · Claude Code as my primary tool"} I was happy enough with Claude Code to maintain two paid accounts. This is the personal starting point for comparison, without uniform per-task measurements. :::

:::step{title="Around February 2026 · Starting with Codex for code review"} I began using Codex mainly for code review and appreciated its care. Claude Code was still my primary coding tool. :::

:::step{title="March 2026 · A change in Claude Code experience"} Around the expansion of available context, the experience began to feel worse. Available capacity, actual context, model version, and client changes need separate records. I cannot identify a specific change at the onset.

Opus 4.6 launched February 5 with 1M context in beta; automatic access in certain Claude Code plans followed March 13. January's good experience belongs to an earlier product state.[^1]

As the Claude Code experience became substantially worse, I made Codex my primary tool. It felt as comfortable to use as Claude Code by then, although it had always been relatively slow. :::

:::step{title="August 19, 2026 · Public praise for Grok Build"} I posted that it was the best coding agent I had used and began considering changes to my other subscriptions.

August 19 post on X :::

:::step{title="September 2, 2026 · Grok becomes my primary tool"} The second post concerns real bug fixing: Grok Build 4.6 was outperforming my previous Claude Code setup for me. Tasks and configurations were uncontrolled, but the assessment was recorded at the time.

September 2 post on X

It followed instructions, took initiative, and carried work through. One SuperGrok Heavy account could handle much of the work I had been doing with two Claude accounts. I canceled one Claude subscription and later added a second Heavy account. The positive assessment persisted and changed what I paid for. :::

:::step{title="October 29, 2026 · A public correction"} Later, work slowed, the allowance drained faster, and initiative and workflow adherence declined. I returned to the earlier post to correct my assessment.

October 29 post on X

The records establish a change in assessment, not a backend cause or a claim that 4.7 is worse on every task. Novelty and rising expectations remain relevant, alongside the earlier sustained favorable record. :::

:::step{title="Recently, through October 29 · Google works well for me"} After quickly exhausting my Grok allowance, I tried Google Argon and Antigravity. It takes initiative and waits for and handles review, bringing back the feeling that I can hand work over. The observation period is short; sustained performance remains to be recorded. ::: ::::

Codex: from primary coding tool to a regular role in review and writing

For me, Codex's slowness was not a later regression; it had been relatively slow from the beginning. After one major version update, overengineering seemed to become more pronounced: small tasks could trigger prolonged investigation followed by unnecessary design and code. I do not remember which update or month, so I cannot tie that experience to a specific release. Even when the result works, waiting, reviewing the extra code, and maintaining it have costs.

This tendency also appears in code review, and it remains an issue today. Sometimes it repeatedly raises edge cases that I consider almost impossible, or issues with little consequence for the change at hand. Every round can produce more comments; after one set is addressed, the next round brings another. Review can feel endless. Some findings deserve a fix, while others are much harder to justify spending time on. Continuing to find issues and judging which issues should block delivery are different abilities.

This has changed our workflow design. We put a hard rule in our skills: code review gets at most three rounds. If disputed findings remain after the third, multiple agents form a jury to assess the remaining comments, rather than letting the same reviewer add requirements indefinitely. This is a constraint we introduced through actual use to keep review from becoming open-ended. For me, Codex's overengineering includes not only extra code, but prolonged review and disproportionate attention to unlikely risks and minor findings.

These days, my primary coding agent changes between Claude Code, Grok Build, and Antigravity, while Codex has two lasting roles: code review and helping me write copy of various kinds. This article itself is a collaboration between me and Codex. For writing, I still find OpenAI's models generally better overall.

That is also why I do not want to describe every change simply as becoming less intelligent. I have not felt an equally clear loss of intelligence in Codex. Its value for review and writing remains, while slowness and overengineering affect whether I choose it as my primary coding tool. Different assessments of the same tool on different tasks can coexist.

A specific workflow failure

I had written the full workflow into a skill: implement the change, open a PR, wait for the Codex review automatically triggered on GitHub, resolve feedback, check the latest commit, merge within the authorization given, clean the workspace, update main, and build the latest version.

For the details of how this workflow runs, see my earlier accounts of moving from manual loops to paired skills and the unattended issue/PR loop. Both link to our open-source Agent Loop skills. The instructions, workflow constraints, and change history are available to inspect, so readers can judge whether our usage makes sense and whether the workflow design itself contributes to the failures.

Early Grok Build would carry this through. Later it often stopped at “PR submitted, not merged yet.” Reminders were needed, and review, fixes, or the final build were sometimes missed.

In one case, testing went wrong and I discovered that the latest version had not been built. I requested a build, which failed. The agent then continued using the old version because the new one would not build.

The observable failure is that the new change had not completed build and acceptance. Keeping an old version running can be reasonable, while the new task remains blocked. Patch correctness, sustained workflow