Blog

The phrase "open weights" does something to a developer's brain. It triggers a familiar sequence: model drops, you find the Hugging Face page, you scroll to the files tab, and somewhere in the back of your mind you are already thinking about disk space. That is the reflex. It is not irrational. It has worked often enough that it feels like a reasonable first move.

When Kimi K3 surfaced — in search suggestions, in developer feeds, on Hacker News, across GitHub — I followed the reflex. I went to the Hugging Face repository. I clicked through to the file list.

There were 96 weight shards. The metadata summed to 1,560,998,984,390 bytes. That is roughly 1.56 terabytes, decimal. Not a storage folder. Not a project directory. A model artifact the size of a modest home server's entire disk, split across nearly a hundred files.

I did not download it. I want to be clear about that. I looked at the file list the way you look at a shipping manifest for something you are not sure you ordered.

When I saw the Hacker News post titled Benchmarking Opus 5 on SlopCodeBench, the number that caught my eye was 4/17. My first instinct was the usual one: scan the score, file the model somewhere in my mental ranking, move on. Four passes out of seventeen checkpoints. Not great. Not catastrophic. Just another data point on the leaderboard treadmill.

Then I made the mistake of opening the paper.

The longer I use coding agents, the less I trust a model ranking on its own.

Rankings are useful, but they only tell me so much. I run Claude Code and Codex on real projects, and over time one thing has become hard to ignore: the same model can produce very different results under different harnesses. How context enters the run, which tools are available, and where verification happens all change the final output. Those choices can matter as much as the model itself, and sometimes more.

That is why my first reaction to a new model release is no longer to scan the leaderboard. I want to know what Agent, what harness, and what effort setting produced the new number.

Claude Opus 5 was released on July 24. This time, the public material gives us enough detail to ask that question more clearly.

The diagnosis was correct. The turn completed. Codex CLI returned the smallest-fix explanation for a ZeroDivisionError, and the final status read completed. If I had stopped there — closed the terminal, pasted the answer, moved on — I would have called the run a success and never questioned what happened in between.

Then I read the event stream.

On 2026-07-23 I watched a Codex CLI 0.145.0 turn complete correctly. Five tool calls, the right diagnosis, a final status of completed. I had preserved the bounded JSONL event stream from the observability work I'd been doing — the recorded tool calls, their results, and the two failed attempts along the way before the Agent reached the correct diagnosis. It was a satisfying run to look at.

And then I realized I had exactly zero evidence about tomorrow.

That trace explains one path through one turn on one day. It cannot tell me whether swapping the model version will regress that behavior, whether adding a new Skill to the loadout will cause a misfired tool, whether a prompt tweak to the harness will change how the agent approaches similar tasks. One successful run is not a regression test. It is evidence from one trial.

That gap is where Eval-Driven Development begins.

Something happened on Juejin on July 23 that is worth paying attention to, not because any single post broke new ground, but because of what the posts, taken together, reveal about where the conversation has moved.

A Juejin hot list checked on July 23 included a Top 10 Skills roundup, a guide to designing better Skills, and a piece asking, plainly, why installing more Skills can make an AI feel slower and less reliable. On Hacker News in the same window, projects surfaced for diagnosing loadout health, gating Skill changes with real usage evidence, and mapping which installed capabilities rarely fire. I am not citing these as verified market signals. Autocomplete suggestions and hot-list rankings show intent, not volume. But the intent itself is the signal: developers are no longer asking mainly "where can I get more Skills?" They are asking which Skills actually trigger, which ones collide, which ones sit unused, and whether any of them are worth their context cost.

That shift is worth understanding from first principles.

The observation did not start with a term. It started with work.

I was building something with multiple Agents—or what I was calling Agents at the time—and a problem kept surfacing: one overall goal did not map cleanly onto one loop of action and feedback. Different units of work needed different local objectives. They needed different signals to know whether they were converging. They needed different stopping conditions and different answers to the question: who is allowed to change the goal here?

The loops were not independent. Some depended on what another produced. Some could block another from proceeding. One unit's partial result could make a previous unit's objective obsolete. What I was actually working with was a graph—I just had not made it explicit. When I later came across the terms Loop Engineering and Graph Engineering in developer discussion and on X, they named a structure I had already been trying to manage.

That is the order I want to keep: observation first, terminology second.

When xAI released the Grok Build source repository, the immediate summary across developer circles was simple: Grok Build is open source. That phrase spread fast, and it is technically accurate in the most literal sense. What it glosses over is worth thinking through carefully, especially if you work with AI coding agents and you are deciding how much weight to put on a source release.

I read the repository, documentation, contribution policy, and several public analyses. I have not installed or run Grok Build. What I am doing here is sorting out what the release actually covers and what it does not, because those distinctions matter for any real evaluation.

Many developers look at Cursor, Claude Code, and Codex CLI and immediately ask: which one should I choose?

But the more common real question is: I already use Cursor, so do I still need Claude Code or Codex CLI?

Short version: these three tools have different jobs. They can be combined, but you do not need to buy all of them. The key is understanding each tool's home territory and choosing based on your actual workflow.

Short version: both tools are terminal agents. Both can read files, run commands, and complete multi-step coding tasks. But Claude Code is rooted in the Anthropic and Claude ecosystem, while Codex CLI is the local CLI entry point into OpenAI Codex. Choosing between them is mostly choosing an ecosystem, not just a feature list.