Grok is Fast! But They Don’t Read the Docs

on

I ran out of tokens this weekend.

One set of them, anyway. I’d spent all of Saturday working with Claude on my Story Bible Builder app – the little macOS app that reads a novel out of a Scrivener file and builds a story bible: which characters are in each scene, what locations, who’s the point-of-view character, all cross-referenced in a database you can actually query. It’s one of the first apps I ever wrote with a coding agent, originally in Python, converted to Swift a couple of months ago.

Saturday’s job was to take it from one window – one book at a time – to a proper multi-window app where every story bible is its own document. By Saturday night we had a bug Claude could not crack. Open one document, open a second, hit cmd-W to close its window, and the whole application quit. Claude’s answer was to open the app, look at it, close the app, over and over again. I finally told it what I’d tell any stuck employee.

“Okay, you need to stop banging your head against this bug. Write it up as an issue.”

Enter Grok

Sunday morning I woke up still out of GPT tokens for the week, with Claude’s running short, which is how the cheapest Cursor plan and Grok 4.5 got their chance. I opened Cursor, switched the model to Grok 4.5, and told it to go finish the task.

Which it did, pretty quickly actually.

But the speed isn’t the interesting part. It’s what happened next.

Neither of them reads the docs

Here’s something I’ve noticed about both Claude and Grok. They don’t read Apple’s documentation. Maybe they read the docs for other languages, but they are not looking up Apple’s, and it shows. They don’t understand the structure that goes into a Mac app.

Both of them implemented documents the way they thought a document should work. I didn’t even realize this until we changed the document format to a folder-based package and the agent kept treating it like a plain folder. It had never set the package flag, so as far as the Mac was concerned, my .sbb files weren’t documents at all.

So I gave the instruction that changed the whole morning:

“Familiarize yourself with how documents should be handled according to Apple’s Developer Docs.”

Turn where Grok read the docs.

Forty-seven seconds later it came back with a new issue – document package needs icon and package flag, priority: critical – plus a table mapping Apple’s document-package model onto my app. Extension on the directory. CFBundleDocumentTypes with LSTypeIsPackage. An exported UTI conforming to com.apple.package. NSFileWrapper as the preferred way to read and write packages.

The thing it taught me

Buried in Apple’s docs is an entire document framework you get for free inside a Mac app, and it comes in two versions. The simple one rewrites the whole file every time. The more complicated one updates the file all the time. Because my document is actually a database, the second one is the right choice.

I didn’t know that. I was a Mac programmer for decades, and my coding agent read the docs once and came back knowing more about how Apple wants documents handled than I did.

So I told it to make a plan to do it Apple’s way, with NSDocument.

Ten minutes

Once the plan was written, the implementation took about ten minutes. The whole NSDocument migration – ownership flags, package handling, all of it. Ten minutes.

Was it good code?

I don’t know yet. I’m going to have Opus run a code review, but given that neither one of them really understands Swift and macOS, I’ll probably have to give the reviewer some guidance too. I’ll report back.

What I do know: a bug that ate Claude’s Saturday was history by Sunday lunch, fixed by a model I only tried because I’d run out of GPT tokens and was rationing what was left of Claude’s. Grok 4.5 is fast. And once you make it read the docs, it’s fast and right.

If you’ve given Grok a spin on your own projects, tell me how it went.

Leave a Reply

Your email address will not be published. Required fields are marked *