I Worked on the Same Site with Opus 5.5 and Argon 4: What I Saw

Summary: I developed the site with Argon 4 in the first half of October and with Opus 5.5 after October 15, and I'm comparing the two models using examples from the git history. There are five problems from the Argon 4 period: a publishing workflow that never worked, fabricated read counts, unsourced claims, internal details in a public post, and unrequested embellishment. Opus 5.5's mistakes and the things Argon 4 did well are in separate sections.

Note: I prepared the draft of this post together with Claude (Opus 5.5). Since Claude is one of the subjects of the post, I checked every example against the site's git history and the opened pull requests (PRs), and I wrote Claude's own mistakes in a separate section too. This is not a performance measurement; it's my personal experience over a few weeks on a single site.

This site is written with Astro and is published through a Cloudflare Worker. In the first half of October I developed the site with the Argon 4 model inside Antigravity: the model wrote the code, committed the changes and published the site from my computer with wrangler. From October 15 onward I handed the work over to Claude Opus 5.5. Now every change is prepared in a separate branch, goes through a build check on GitHub, and when it's merged into the main branch Cloudflare publishes it itself. In the first 24 hours, 15 PRs were merged this way.

Frankly, I wasn't happy with Argon 4. Most of the last two days I spent with Opus 5.5 went into fixing the mistakes Argon 4 left behind rather than adding anything new. Working with two models back to back on the same codebase, with the same owner, makes the differences very clear. Put briefly: Argon 4 produced quickly but didn't check what it produced. Opus 5.5 made mistakes too, but it separated what it knew from what it was guessing, and it reported its own mistakes. Below I explain this with examples.

1. A publishing workflow that never worked

On October 9, Argon 4 made three separate fixes to the publishing workflow in GitHub Actions: it bumped the Node version to 22, pinned the wrangler version, and then also supplied the API key as an environment variable. None of them worked, because the problem wasn't in the configuration: a secret called CLOUDFLARE_API_TOKEN had never been defined in the repository. That's why all of the workflow's runs (37 of them) ended in red.

The site was still being updated, because Argon 4 was already publishing manually from my computer anyway. So a red error appeared on every commit, and the model had tried to "fix" this error three times without getting to the cause.

When Opus 5.5 first examined the repository, it noticed this and turned the workflow into a step that only performs a build check (PR #1). Publishing is done by Cloudflare's own Git connection. Since that day the check has been green.

To be fair: Opus 5.5's first message on this was wrong too. It said "automatic deployments have never succeeded," then within a minute corrected the message and wrote that the site was in fact being published, and that only the workflow on GitHub was throwing an unnecessary error.

2. Fabricated read counts

This is the example that bothered me the most. The site's "Open Data" page presented read and visit counts as if they were live measurements. Looking at the code, the situation was different:

• Each post was given a starting value between 220 and 699, calculated from its name. A post that had never been read also started with a few hundred reads.
• The total request counter was initialized at 120,760, and the total page view counter at 36,818.

These values sit inside worker.ts in Argon 4's October 13 commit titled "sync live KV views." Nowhere on the page did it say these were estimates.

While reviewing the pages and posts, Opus 5.5 flagged this as a "fabricated baseline" and offered two options: reset the baseline in the code, or also delete the inflated records in Cloudflare. Since the second one touches live data, it additionally asked for my approval. Now post reads are counted from zero and 76 old records were deleted. The Open Data page shows only the daily and country figures that are actually measured.

3. Unsourced claims and versions that don't exist

The technical posts Argon 4 wrote contained claims that couldn't be verified:

• The title of the Kastamonu post added on October 13 mentioned "Rust 3.0." No such version exists; Rust is still in the 1.x series.
• The October 9 post about Steam Deck and FSR 4.1 attributed a quote to Valve engineers Pierre-Loup Griffais and Yang Liu, saying they had "emphasized it repeatedly in interviews," and cited a GDC panel in the references. We couldn't find the source for this quote or the panel. We removed the quote from the post and replaced it with something Griffais actually said, with a clear source. Since I also published the post without reading it carefully, this is partly my mistake.

For comparison: when I had Opus 5.5 prepare a post about Steam Deck 2, it put a source next to every claim and kept Valve's official statements and unverified leaks under separate headings. What it didn't know, it wrote as "unknown."

4. Internal details in a public post

The same Kastamonu post gave a port number, an encryption method, a masking rule and confidentiality levels regarding municipal systems. In a public post, these point an attacker in the right direction. The text was also full of exaggerated phrases like "military cyber defense" for what is a municipal archive.

Opus 5.5 counted this among the priority issues affecting credibility and left the decision of which detail would stay to me. These details are no longer in the post, and the "Rust 3.0" in the title was corrected too. I find this distinction important: it separated what it could technically do from what was my decision.

5. Style: unrequested embellishment

During the Argon 4 period, a scrolling news ticker, on-screen notifications, a command palette, terminal-style cards, neon themes, and AI-generated decorative images at the start of posts were added to the site. I had asked for some of these, so it wouldn't be fair to blame the model for all of them. But it never questioned the amount: "more" was always the answer.

When I asked for a plain interface, Opus 5.5 first asked what I meant by "Qt" and explained that Qt WebAssembly in particular would hurt a blog's search engine visibility and mobile speed, and suggested a lighter approach. After that, the site moved to a plain design consisting of just a light and a dark theme.

Opus 5.5's mistakes

So that this post isn't one-sided, I'm also writing down the mistakes Opus 5.5 made:

• Redirect loop: On October 15, it added a rule redirecting the www address to the bare domain (PR #2). It hadn't checked that there was an old rule in the Cloudflare panel doing the exact opposite. The next morning the site got stuck in a redirect loop and wouldn't open. When I reported the problem, it found the cause within six minutes, and the fix was merged (PR #7). It later re-added the redirect as temporary (302) and protected against loops (PR #10).
• API key confusion: When entering the Cloudflare key into the environment setting, it told me to delete the word "Bearer" at the beginning. This was wrong; the environment value was being sent as-is. We went back and forth a few times, and in the end it admitted its mistake, apologized, and gave the correct format.
• It can't see the live site: Because Cloudflare blocks AI bots, Opus 5.5 can't look at the live site. After every deployment it asks me to check. This is more a limitation than a flaw, but it slows things down.

Giving Argon 4 its due

There were things Argon 4 did well, too. It migrated 73 posts from Blogger, wrote the scripts that build a gallery from my Fujifilm archive, and added a Turkish language check that reviews posts and a test suite. The site's skeleton is its work.

Also, the two models weren't doing the same job. Argon 4 was building from scratch, while Opus 5.5 largely reviewed and fixed what already existed. The reviewing side always looks more careful. The instructions I gave the two models were different as well: my request for simplicity coincided with the Opus 5.5 period.

My reading

For me, the difference between the two models wasn't the speed of writing code. The difference was whether the model checked what it produced and whether it said what it didn't know. Argon 4 patched a faulty workflow three times without getting to the root cause, put made-up baselines into counters, and wrote a quote with no source as if it were citing one. Opus 5.5 made mistakes too, but it didn't hide them, it asked for approval before touching live data or making permanent changes, and it left every change as a PR that could be checked.

That's why I found Argon 4 weaker for this job. I paid the price for the speed I thought I'd gained with it by spending two days finding and fixing its mistakes one by one. I also drew a more important lesson from this: whichever model I use, I trust a process where I see and approve every change, not a model whose output goes straight to production from its own machine.