I'm pretty sure isRecord is our fault

A few weeks ago, many programmers (or perhaps former programmers) began to notice that OpenAI’s Codex model had developed an obsession with defensive coding. Nothing captured this better than isRecord, a ridiculous guard on whether an object-like object is actually an object, that began appearing everywhere.

The quirk quickly became a meme. It’s even available as npm package.

Hey I know that code

Now I’ve always used isWhatever for helpers that return booleans. I’ve had to occasionally bully my poor colleagues to use it too, both for style consistency and because of a little thing called founder mode.

So when all of this isRecord discourse reached my timeline I had to pause. I was certain that I’d seen isRecord before.

And sure enough, a search of tldraw’s code-base revealed it:

This guard is part of our data store package, where all information in the tldraw canvas is stored as a flat reactive map of objects, or “records”. It’s a simple guard and more about assigning a type than really protecting the store.

As far as I can tell, these lines are the source of the isRecord so beloved by coding models. If you search for the code on GitHub, you’ll find tldraw and many copies of tldraw, followed by newer code written by Codex.

The only other repo I’ve found to use isRecord from the before-times is RocketChat’s version, added in July 2025:

Not to brag, but our isRecord predates that by at least two years. In fact, I think we wrote the store in the summer of 2022, though the git blame only takes us back as far as 2023, when we moved the code over from the private repo to the public one.

10,000 years of isRecord

In the end, I have to admit some pride in having had a tiny influence over the weights of such incredible models. The next time you see an isRecord in your code base, please think of tldraw.