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: why does this sequence seem to recur across different vendors' tools?

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: 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?

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.

1. 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.

2. 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.

3. 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.

4. 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.

5. 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.

6. 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.

   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.

7. 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.

   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.

8. 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 execution, and the identity of the artifact being verified need separate records. This single case cannot identify whether the cause was the model, context management, or the tool's stopping policy.

Three explanations from a peer discussion

I brought these experiences to an AI coding discussion group with more than 500 members, asking whether others had felt something similar. Three participants responded in the exchange. I retain their group IDs here while paraphrasing their positions.

野生皮卡丘 reported experiencing genuine regressions, while also pointing to novelty wearing off and expectations rising with familiarity. They attributed more of the change to the product and speculated that vendors might adjust compute allocation after attracting users. The experience and the motive hypothesis are different claims; their subjective numerical split is not a measurement.

Cal Art Academy said they had experienced several similar cycles and would switch tools. They suggested that large amounts of uneven user feedback might make a model worse. Investigating that explanation requires tracing how feedback reaches later training and deployment; it cannot be interpreted as every conversation immediately changing shared model weights.

谷雨 pointed to routing and adjustable parameters behind the service. This suggests a product-layer investigation, but the conversation supplied no logs identifying a particular routing or parameter change.

These responses give me reasons to collect more records and expose a disagreement worth investigating: habits and expectations, training feedback, or operating choices and service settings. They are three self-selected responses, not the views of the whole group or proof of any explanation.

A timeline of public reports

These primary sources sit alongside the personal records. Each node identifies whether it is an official review, an independent test, or a user report, preserving their different evidential weight.

1. April 2025 · OpenAI confirms a behavioral regression

   OpenAI's May 2 Expanding on what we missed with sycophancy reviews a GPT-4o update and rollback. It establishes that behavior changes can worsen a product. I discuss this separately from the conversation experience users missed below.

2. August–September 2025 · Anthropic confirms infrastructure faults

   Anthropic's September 17 A postmortem of three recent issues identifies infrastructure faults affecting response quality. Serving implementations matter; these 2025 events cannot be moved onto my March 2026 timeline.

3. March–April 2026 · Three Claude Code changes

   Anthropic's April 23 An update on recent Claude Code quality reports identifies a high-to-medium default change on March 4, reversed April 7; an idle-session reasoning-history bug introduced March 26 and fixed April 10; and a shorter-output prompt introduced April 16 and reverted April 20.^[2]

   On lowering default effort, the review states:

   “This was the wrong tradeoff.”

   These are documented decisions and faults. They occurred on different dates; the March 26 bug cannot explain an earlier onset.

4. April 2, 2026 · A complex-engineering user report

   stellaraccident's Claude Code #42796 reports instruction-following and completion problems, with retrospective log analysis. It supplies leads; file-read counts and visible thinking cannot directly establish reasoning budgets.

5. May 2026 · A drop in daily repository-repair tests

   JB's May 29 MarginLab report records a drop on a SWE-Bench-Pro subset and offers this interpretation:

   “This appears to be a harness issue, not a model regression.”

   That is the author's attribution. The CLI was changing too, preventing isolation of the model. Its table shows recovery to 66% on May 27, before the May 28 model launch connected to recovery in the prose. I use the product fluctuation, not a causal claim that the model launch produced it.^[3]

6. June 13, 2026 · A Codex user reports slower tasks

   mazukabz's Codex #28077 reports tasks moving from under roughly five minutes to 30–50 minutes. I recognize the symptom. The numbers are the reporter's, not my measurements or an official failure rate.

7. Through October 29, 2026 · A pinned-client test detects no change

   ninjahawk's LiveNerf pins the client and test conditions. Neither completed ten-day window detected a change.

   This contrary result matters. It mainly measures knowledge and mathematics rather than full development workflows and has detection limits. It measures something different from MarginLab; the two cannot be merged into a single model-degradation curve.

Official reviews confirm specific regression mechanisms, and user reports supply leads. They have not explained the Grok changes in this report. The evidence supports recurring reports across products, without establishing a universal cycle or shared cause.

Why launch benchmarks do not directly predict daily experience

Launch charts usually establish performance under a specified evaluation and configuration. Daily development also asks whether medium or high saves time, whether an agent continues through asynchronous review, and how many unnecessary changes it leaves.

Figure: Anthropic's Opus 4.6 launch material. Original chart and evaluation details: official announcement. This is a launch evaluation, not a measurement from this report or a longitudinal stability series.

I have not rerun these evaluations or assembled incompatible scores into a vendor ranking. They overlap with sustained use without measuring the same thing. A new version can improve on an evaluation while the product becomes harder to use in another configuration or longer workflow.

Initial analysis: shared pressures, potentially different causes

Operating tradeoffs are real; deliberate weakening needs evidence

Vendors make tradeoffs among inference computation, response time, and allowances. Anthropic's April postmortem documents one: lowering default effort to reduce high-effort latency, then reversing it after feedback. This is a recorded product decision with consequences. Cache and context-management bugs form a separate category, capable of worsening both results and usage without an intention to reduce capability.

My initial interpretation is that similar optimization pressures may reach users through different settings, prompts, and serving implementations. Official cases support that as a plausible explanation, without establishing it as the cause of Grok, Codex, or every change I experienced.

The group's “good at first, deliberately weakened later” account adds a claim about intent beyond the claim that operating tradeoffs can hurt the experience. Establishing it requires sustained matched measurements and evidence connecting them to a real policy change. The records justify asking vendors to explain changes, but do not establish that business script. Users still pay for rework whether its cause was a bug or an optimization; an investigation must distinguish them.

From GPT-3.5 writing to the 4o conversation experience

This contrast predates coding agents. I already found GPT-3.5's writing impressive. Later, 4o felt especially warm and natural to talk to. Those experiences concern both writing quality and the feel of a conversation, which need to be understood alongside their tasks.

There is specific research to compare against that early impression. Brian Porter and Edouard Machery's 2024 poetry study used ChatGPT 3.5 and found that non-expert readers struggled to distinguish its poems from human work, rating AI poems more favorably on several dimensions. Its particular poems and readers cannot establish a general literary rank.^[4]

GPT-4o launched on May 13, 2024. The dispute over later conversation changes also has a product record. OpenAI's August 2025 release notes say 4o returned to paid users' model picker on August 12. On August 15, OpenAI adjusted GPT-5's personality in response to feedback that it felt too reserved and professional.^[5] This confirms feedback and a response, not a survey of all users or writing tasks.

OpenAI's explanation of the April 2025 4o sycophancy regression concerns an update that over-weighted short-term feedback and was rolled back. My question is why correcting sycophancy can feel to some users like a broader downgrade in conversation. Warmth, clear expression, and uncritical agreement need separate assessment. OpenAI's August notes make that distinction too and report no increase in sycophancy on its internal evaluations after the personality adjustment. “It used to be too agreeable” does not fully explain the experience users say they lost.

This history cannot establish that new models are universally worse writers. It provides a relevant comparison: capability, safety behavior, and communication can move in different directions and require separate acceptance criteria.

Why has communication become harder to read?

This is an experience I have had across tools. Without fixed writing tasks and blind ratings, I cannot claim a measured, general decline in writing ability. Primary sources do, however, identify several mechanisms worth testing.

A coding product's output objectives can differ from clear explanation to a person. OpenAI's GPT-5 prompting guide describes Cursor finding excessive updates and recaps disruptive, while overly terse code was hard to read. It also separates verbosity from reasoning effort.^[6] Coding ability, time spent reasoning, and the eventual explanation can change independently.

Compression can remove information useful to completing work. Anthropic's April review describes a system prompt limiting text between tool calls and final answers that hurt coding quality and was reverted. This establishes the effect of that change, not that all short answers are bad or that every vendor used the same prompt.^[2]

Preference optimization need not reward readability itself. Ryan Park et al.'s Disentangling Length from Quality in Direct Preference Optimization studies exploitation of preferences for longer responses.^[7] Length, formatting, or apparent completeness can become proxies for quality; forcing shorter answers is not an automatic repair. The study does not establish the training methods or cause of a current vendor's regression.

Long tool histories also deserve investigation. Anthropic's Effective context engineering for AI agents discusses the management burden of accumulating tool output, history, and instructions.^[8] This helps distinguish an agent session from an early single-turn writing interaction, without explaining a particular unreadable response by itself.

These sources lead me first to test whether optimizing coding scores, apparent completeness, output length, or latency sometimes reduces the priority given to explaining work clearly. That is a testable hypothesis, not a confirmed common cause. Future records should include fixed writing tasks and blind comparisons: can a reader recover what changed, why, and what was verified? Output length alone cannot answer that.

Other factors that can become conflated

Weights, effort, system prompts, compaction, tools, and routing cannot be distinguished by a model name alone. Grok Bot and Grok Build also operate in different environments. The 4.7 announcement mentions Bot-harness training; positive Bot reports do not settle Build complaints.

Queuing primarily adds waiting, while repeated work, extra tool calls, and cache misses can add consumption. Xingyu Chen et al.'s overthinking study investigates excessive reasoning on simple problems. Nelson F. Liu et al.'s Lost in the Middle studies the effect of information position in context. They supply investigation paths, not a calculation of my losses.

Ordinary fixed-weight inference does not immediately update shared weights when another user sends a message. Feedback can affect later training and deployment, as OpenAI's sycophancy postmortem illustrates. Connecting feedback to another regression still requires a specific update chain.

Growing project complexity, rising expectations, a new tool inheriting the old tool's investigation, and regression toward average performance after switching during a particularly bad experience can affect comparisons too. These confounders can coexist with confirmed incidents. There is no need to pick one explanation for everything.

Developer responses and the implications of easy switching

For me, the first response is to move comparisons out of memory. Keep a small set of repeatable real tasks, record model, client, effort, and context conditions, and compare elapsed time, consumption, interventions, unrelated changes, and final outcomes. Changing effort on matched tasks can show whether extra waiting buys less rework. Setting everything to the maximum bypasses the question and does not reflect how I normally work.

Delivery evidence should live in the work itself: the target commit, resolved review, and the version actually built and verified. A failed task remains blocked. Communication belongs in acceptance too: a concrete account of changes and tests must match what actually happened. A polished completion statement is insufficient. Fixed tasks, blind writing assessments, and continuous metrics remain proposed next steps, not a system I have deployed.

The other practical response is to preserve the ability to switch. I moved from Claude to Grok, then tried Google as allowances and experience changed. With code, workflows, and acceptance conditions kept in the project, having liked one tool did not stop me from handing the next task to another.

This is why I suspect model and coding-agent loyalty can be weak. In my workflow, recent task outcomes affect the next choice more directly than past brand preference. That does not establish near-zero user stickiness across the market: other users' histories, integrations, and team processes may make migration harder. For me, switching has been cheap enough that familiarity cannot compensate for a persistently worse experience.

If more developers are in that position, a launch ranking alone will be an insufficient advantage. Transparent configuration changes, timely regression detection, reproducible reports, and consistent task completion may matter to continued use. That is a product judgment drawn from my migrations, not a measured market result.

A different tool, with the question still open

Similar experiences with Anthropic, OpenAI, and Grok justify an investigation across vendors. Official postmortems confirm some regressions, peers and public reports supply observations, and LiveNerf limits the claim that every model inevitably deteriorates. Treating all changes as either illusion or a common commercial conspiracy would settle the question too quickly.

I want to keep recording how speed, outcomes, and readability change at everyday medium/high settings; whether computing saved inside a product becomes user rework; and what earns continued use when switching is easy.

As I write, Google has recently announced Argon and Carbon in succession.^[9] Over the past few days, I have moved my primary development work to Google, using Argon and Antigravity. It is fast, capable, and feels generous in its allowance. After this week's frustration, being able to hand over a task without saying “continue” at each handoff is a relief.

I have felt that relief with Claude and Grok too. The tool in front of me works well, and I have no reason to decide in advance that it will regress. I also cannot pretend the earlier experiences did not happen.

Will I find myself back here after a while, looking for the next agent that feels fast and useful? I hope this one keeps working well. I want to keep a better record of what happens next.

References

1. Anthropic. Introducing Claude Opus 4.6, February 5, 2026; 1M context is now generally available, March 13, 2026. ↩
2. Anthropic Engineering. An update on recent Claude Code quality reports, April 23, 2026. ↩
3. JB, MarginLab. Claude Code degraded for the week before Opus 4.8's release, May 29, 2026. Daily table: May 27, 66%; May 28, 72%. ↩
4. Brian Porter, Edouard Machery. AI-generated poetry is indistinguishable from human-written poetry and is rated more favorably. Scientific Reports, 2024. ↩
5. OpenAI. Hello GPT-4o, May 13, 2024; ChatGPT release notes, August 12/15, 2025; Sycophancy in GPT-4o, April 29, 2025. ↩
6. OpenAI. GPT-5 prompting guide, Cursor integration and the verbosity/reasoning-effort sections. ↩
7. Ryan Park, Rafael Rafailov, Stefano Ermon, Chelsea Finn. Disentangling Length from Quality in Direct Preference Optimization, 2024. ↩
8. Anthropic Engineering. Effective context engineering for AI agents, September 29, 2025. ↩
9. Google. Gemini 4 Argon, October 13, 2026; Gemini 4 Carbon, October 28, 2026. Carbon was announced with phased, limited access and is outside the personal usage record in this article. ↩