Four Months, One Redis Array Type, and What It Tells You About AI on Production Code

Salvatore Sanfilippo, the engineer better known as antirez and the original author of Redis, spent four months building a new Array data type for the database. He wrote up the experience this month under a title that reads almost as an apology for its own length: Redis Array Type: Short Story of a Long Development. The post is short. The development was long. And the value of the post is that it documents, with the precision of a working systems engineer, exactly what AI collaboration looked like on a piece of production-critical infrastructure that millions of services depend on.

We have written previously about the harness as the long-running discipline that surrounds an AI collaborator, and about skills as modular governance that make the collaboration auditable. Antirez’s account is the practitioner version of those arguments. It is what the harness looks like when the engineer at the keyboard is one of the most respected systems programmers alive, and the code in question goes into a database that production traffic pounds in millions of operations per second.

The discipline he describes is not new to him. What is new is that we now have a public, named, granular account of how a serious engineer used AI on serious code without the result reading as either a marketing testimonial or a cautionary tale.

The Four Months

The shape of the project is worth reading slowly. Month one was specification. Antirez spent it deciding what the Array type should be, how it should expose its operations, what semantics it had to preserve, and how it would interact with the rest of Redis. Month two was implementation. Month three was code review and optimization. Month four was stress testing and feature expansion, including a regex search operator called ARGREP. The cadence is the inverse of the demo-driven cadence that AI tools encourage. There is no day-one MVP. There is no “ship the happy path and iterate.” There is a month of thinking, then three months of executing the thought.

This is not nostalgic engineering. It is the cadence that production-critical code has always demanded. Antirez did not abandon it because AI was at the keyboard. He used AI to keep it.

Where AI Was Essential

Antirez is direct about which parts of the work AI carried. The 32-bit support implementation. The verification work that he describes as “a virtual workforce ensuring no obvious bugs” before he committed code. The debug session on the TRE regex library, where the alternation pattern foo|bar|zap was misbehaving and the model traced the issue through TRE’s internal state machine faster than a human reading the C source could. He used Opus first. He moved to GPT 5.3 and 5.x for parts of the system programming work where that family of models was producing better C. The choice of model is treated as a tool selection, not a loyalty test.

The pattern across these uses is consistent. AI took the tedium and the verification. The 32-bit support is mechanical translation work that a careful human can do but does not enjoy. The verification pass is the kind of work where a tireless reviewer who reads every line is more valuable than a brilliant one who reads the interesting parts. The TRE debug is search through unfamiliar code, which is exactly what models trained on the open-source corpus excel at.

Where AI Was Not in Charge

The list of human-driven decisions is the more interesting half. Antirez owned the specification phase. He owned the architecture, including the central design choice of a multi-level directory structure that evolved, over the four months, into what he calls a “super directory of sliced dense directories.” That is not a phrase a model produces. It is a phrase an engineer produces after weeks of prodding the data structure until the trade-offs settle. He owned the feature expansion, including the decision that an Array type should ship with ARGREP rather than wait for a follow-up release.

The line he draws in the post is the line that matters. “For high quality system programming tasks you have to still be fully involved.” Not partially involved. Not directionally involved. Fully. He reviewed the code line by line. He kept the architectural decisions in his own head. He treated AI output as draft material that earned its way into Redis only after he had read it as if a junior engineer had submitted it.

Why This Is the Harness Thesis in Practice

We have argued for the harness as the place where AI collaboration becomes safe at scale. The argument has been theoretical: a long-running engineering effort needs a containment structure that survives across sessions, holds the specification stable, gates what code lands, and makes the collaboration auditable. Without that structure, AI assistance becomes a series of unaccountable suggestions that compound into technical debt the team cannot explain.

Antirez built that harness for himself, by hand, around a single project. The four-month timeline is the harness. The month of specification is the harness. The line-by-line review is the harness. The decision to use different models for different parts of the work is the harness. The architectural authority remaining in the human’s head is the harness. He did not call it that, and he did not need to. The discipline produced the same artifact that organizational harnesses produce: a piece of code where the role of each contributor is legible, where the risk surfaces are bounded, and where the engineer of record can answer for every line.

This is the form the discipline takes when one engineer of antirez’s caliber does it alone. In a 200-engineer organization, the same discipline cannot be improvised. It has to be encoded into the harness: the skills that gate which models touch which surfaces, the containment that constrains what AI execution can reach, the spec-first cadence that survives team turnover. The principles are identical. The implementation has to scale.

What to Take From This Into Your Engineering Practice

Three things are worth carrying out of antirez’s account into how your team uses AI on production code.

First, the specification month. If your team’s AI collaboration starts with code generation, you have skipped the part where human judgment is irreplaceable. Decide what the system is supposed to do, in writing, before any model writes a line. Antirez spent 25 percent of his calendar time on this phase. Most teams spend 0.

Second, the line-by-line review. AI-assisted code that the engineer of record has not read is not code; it is unreviewed material that is now in your repository. The review is not a quality-assurance step that comes after merge. It is the act that converts a model’s output into the engineer’s commitment.

Third, the model-as-tool stance. Antirez switched models when the work demanded it. He did not declare loyalty to a vendor. He did not treat the choice as ideological. He picked the tool that produced better C for the system programming subproblem in front of him. This is the posture of a working engineer, and it is the posture your team should hold.

The Redis Array type ships when antirez decides it ships. The code is in his repository, under his name, and he can answer for it. Four months of disciplined collaboration produced a piece of infrastructure that production systems can rely on. That is what AI as collaborator looks like when the human at the keyboard has not delegated judgment along with the typing.

The slogan is easy. The discipline is the work.

This analysis synthesizes Redis Array Type: Short Story of a Long Development (Salvatore Sanfilippo / antirez, May 2026).

Victorino Group helps engineering organizations turn AI-as-collaborator from a slogan into a working discipline on production code. Let’s talk.