For the past 18 months or more, AI-assisted programming essentially has been more or less dominated by one company. If you were doing serious code generation — not autocomplete, but handing an assistant a real design problem and expecting working software back — the odds were overwhelming that the assistant was Claude. Anthropic didn’t just have the best model for this. For practical purposes it had the only one, in the sense that mattered: the one you’d bet a project on.
I’m as embedded in that fact as anyone. My longest-running project with Claude is Ivory, a Common Lisp vertically integrated into .NET that is by now nearly fully ANSI compliant. My efforts have been years of work off and on. Work intensified especially in the last 2 years, with thousands of interactions during the last 9 months in keeping with Claude improvements and a growing structured code surface foundational to increasing development pace. The use of Claude, in particular, represents a kind of collaboration you can only have with a tool on which you can rely consistently enough that the value of use is clear. So when I say the dominance is ending, I’m not rooting against the incumbent. I’m reporting what I see from inside a loyal customer base.
Because dominance like that never lasts. Not in software. IBM owned computing so completely that “nobody got fired for buying IBM” became a proverb, and then Microsoft owned it, and then Microsoft was the company that faltered and did not fail solely because of its size in customers, software portfolio, and talent. The pattern isn’t that the leader fails. Usually the leader stays excellent. The pattern is that the field fills in around them, and one day the question “who else is there?” has answers.
It has answers now. In the US, xAI’s Grok. Abroad, Mistral in France, and DeepSeek, Qwen, and Kimi out of China — models people do real work with, not benchmark curiosities. You don’t have to believe any of them has caught Claude to see what the list means. Two years ago the list was empty. And while newcomers alone make a big statement, that statement is re-enforced by the fact that increasingly powerful hardware, with unified memory and GPU chips inside, are becoming more accessible to run models distilled from their bigger cousins.
I’d used Grok lightly before — enough to notice it was fast and pleasant, not enough to form an opinion worth having. What changed my level of interest wasn’t the model. It was a business deal. In June, SpaceX — which had folded xAI into itself this spring — agreed to buy Anysphere, the company behind Cursor, for sixty billion dollars. Cursor is the AI coding editor built from a fork of VS Code; some large fraction of working programmers touch it daily. When the company behind a model buys the editor on everyone’s desk, that model is going to be in front of an enormous number of programmers soon, whether they chose it or not. A model I’d been mildly curious about had become one I was obliged to understand. So yesterday I spent a few hours getting properly acquainted with Grok 4.5, through its CLI, the way you’d interview a promising candidate whose résumé suddenly got interesting.
I designed a graduated series of exercises. First a well-bounded design problem: a discrete event simulation framework in Common Lisp. Then a prose problem: rephrase a Science article in the voice of Paul Graham. Then a genuinely open-ended one: build a SNOBOL interpreter — a pattern engine plus a language host that parses and runs real SNOBOL programs.
And one rule governed all the Lisp work: everything had to load and pass its tests on two hosts, Ivory and SBCL. SBCL is a venerable open-source Common Lisp with no opinions about anything, and it cannot be flattered. I told Grok the reason out loud: SBCL is the referee, there to keep everyone honest. That rule turned out to earn its keep, and I’ll come back to it, because having a truth oracle in the loop is the part of this exercise I’d recommend most broadly.
The simulation framework went well. If you’ve never met discrete event simulation, the central trick is that simulated time isn’t the OS clock. It’s just a number. You keep a queue of pending events sorted by timestamp, pop the earliest one, jump the clock straight to it, and run the event, which usually schedules more events. Nothing happens between events, so nothing is computed between events, and hours of simulated factory activity finish in milliseconds. Grok produced a small, clean framework — activities with durations, an agenda, branching on outcomes — and it ran identically on both hosts essentially on the first attempt.
One detail told me more than the rest of the code combined. When two events land on the same timestamp, which fires first? A naive implementation leaves it to chance, and simulations that work by luck are worse than ones that don’t work at all. Grok’s agenda entries carried a monotonic sequence number to break ties, so simultaneous events fire in the order they were scheduled. That’s the kind of detail you only get right if you’ve either built one of these before or actually understand the problem. Either answer is encouraging.
The essay exercise is where the incumbent kept its crown. The source article — “Advancing science by designing for surprise” — argues that scientists write papers as cautious confirmations for their home crowd, when information theory says only surprise carries information. A natural candidate for the Graham treatment, since Graham’s essays live on exactly that move.
Grok’s rendering was competent. More than competent in places — a couple of its closing lines would pass for the real thing. But held next to actual Graham essays, the seams showed. Grok’s version tracked the source article nearly paragraph for paragraph: same ideas, same order, new clothes. Graham doesn’t work that way. He starts from some personal observation, wanders toward the idea, doubles back, admits he might be wrong, and arrives at the thesis as if discovering it in front of you. A voice has a costume and an anatomy. Grok tailored the costume well. It didn’t have the skeleton.
But before I score that point for Claude, I have to report what happened next, because it complicates the scoring. I complained about Grok’s essay to Claude, and Claude said something amazingly honest (not the right word since tech can’t be honest or dishonest, but I hope you take the point and forgive my use of it): it probably wouldn’t have done better with the same prompt. “Rephrase this in Graham’s voice” pulls hard toward tracking the source. The paragraph-for-paragraph fidelity was substantially the assignment’s fingerprint, not the model’s. So I asked Claude to write the version the better prompt would produce — “write the essay Graham would have written after reading this article” — and it did, and the result fixed everything I’d complained about. Then I asked whether the comparison had been fair, and Claude enumerated, unprompted, exactly how it was rigged: it had answered a different assignment than Grok did, it had written the grading rubric before writing its entry, it wrote with Grok’s essay open on the table, and it already knew which assistant I preferred. There’s a pleasing irony here, because spot the pattern first, then produce the result that confirms it, is more or less the sin the source article was written to expose. The conclusion is that my prose comparison is a strong impression, not a controlled result — and that when you compare models, a surprising amount of what you’re measuring is your prompt.
The third exercise was the real one. SNOBOL’s signature idea is that a pattern is a first-class value — built from combinators, passed around, composed, made recursive — matched by a backtracking scanner rather than compiled to a regex automaton. This is why SNOBOL could match balanced brackets with a single primitive in 1967, a challenge for regexes. Grok built the pattern engine as a continuation-passing scanner, which is the right architecture, because SNOBOL’s odd control primitives — the one that cuts off backtracking, the one that kills the whole match — fall out naturally when every pattern node holds its own success and failure continuations. Then, with the SNOBOL/Lisp engine frozen as a library, it built a language host on top: lexer, parser, and a runtime that executes real .sno programs, with user-defined functions, gotos, tables, arrays, tracing, and file I/O.
It clearly is not a bit-perfect historical SNOBOL — the unimplemented corners are stubs that honestly fail rather than pretend, which I count as a virtue in software and in people. But it runs sixty-eight golden test programs with expected output, all green on both hosts, and there’s a harness that checks a portable subset against a real CSNOBOL4 installation. This is a multi-thousand-line, multi-layer system with real architecture, built fast, and it works.
And here the SBCL referee earned its keep. Somewhere in the file I/O tests, the two hosts stopped agreeing — not on the pattern matching, but on two mundane corners of ANSI Common Lisp I/O. Ivory’s PROBE-FILE, asked about “/tmp”, could lose the absolute directory in parsing and report the path missing. And seeking on a text stream would report the new position while subsequent reads went on consuming the old buffered data. SBCL did neither. Grok noticed, isolated both behaviors into precise, reproducible diagnostics, and worked around them so the tests stayed green. Then those diagnostics went to Claude via git issues that were used to fix the underlying bugs in Ivory itself. One assistant found the bugs. Another fixed them. Neither knew the other existed.
Sit with that hand-off for a moment, because it’s a picture of the world we’re entering. The interesting thing wasn’t that either model was smart. It was that the work product of one was good enough to be picked up by the other, and that the bugs were found at all only because two independent implementations were required to agree. Monocultures don’t produce that kind of correction. Fields do.
So where did the audition land? Grok 4.5 was fast — noticeably fast — and its code was decent to good: idiomatic Lisp, correct on both hosts, scaling up to a real system with real engineering process around it. Its diagnostic work was genuinely strong. Its prose had the costume of a voice but not the anatomy, and on that axis Claude remains clearly better to my ear. And I haven’t pushed Grok anywhere near the complexity of my Ivory work, so this is a first acquaintance, not a verdict.
But notice what kind of report that is. It’s the report you write about a credible alternative, and for most of the past twelve to eighteen months there was nothing to write it about. That’s the news. Not that Claude has been surpassed — on my evidence it hasn’t. But the incumbent has been handing its challengers openings. It has felt slow lately. And the recent jailbreak episode exposed a safety enforcement regime designed, it seems, for well-meaning users — one that didn’t survive first contact with a bad actor even barely into the pathological. Safety that doesn’t price in the mildly malicious isn’t safety. It’s etiquette. Still, the real story isn’t the stumble. It’s that the field is filling in, here and abroad, the way fields always eventually do around a dominant player. This is good for everyone, including Anthropic. Incumbents with company ship better work than incumbents without it, and customers with second sources can finally tell which of their habits are preferences and which are just defaults.
Claude is still my baseline on the work I am finishing. But a baseline you never compare against anything isn’t a baseline. It’s a habit. The era when there was nothing to compare it to was the strange part, and it’s over.