Build a Wiki Search Engine with Zero Handwritten Code: Another Side of Claude Code

Former Google engineering lead Hugh Williams has done something else worthy of the Hacker News front page: using Claude Code to build a working search engine, Zettair, from scratch. It indexed over 1.5 million Wikipedia articles and included autocomplete, snippet summaries, related search recommendations, trending lists, AI-generated summaries—essentially all the features you’d expect from a modern search engine. Throughout the entire process, he “didn’t handwrite a single line of code.”

This was his second public experiment after previously using Claude Code to spin up an AWS system in 48 hours. But the conclusion is more interesting than the project itself: instead of loudly proclaiming, like many tech influencers, that “engineers are going extinct,” Williams offered a much calmer assessment — the ceiling of AI programming depends on how much the person using it understands.

An overlooked premise: Zettair didn’t start from zero

First, let’s drain some of the hype out of this story.

The name Zettair is familiar to older generations in information retrieval. It was an open-source search engine developed in the early 2000s at RMIT University (Royal Melbourne Institute of Technology), and Williams himself was one of its core developers. In other words, the underlying retrieval framework he had Claude Code implement this time was something he personally wrote, optimized, and published papers about more than twenty years ago.

That means:

• Claude Code didn’t need to independently discover how to build inverted indexes, calculate document frequency, tune BM25 parameters, or choose between variable-byte compression and Elias gamma encoding — Williams already knew the answers.
• When the model generated incorrect code in tokenization or drifted in scoring functions, he could identify the issue within seconds. That kind of “code reviewer” judgment isn’t something you gain by reading a few blog posts.
• The prompts themselves were effectively a high-density translation of domain expertise. Someone unfamiliar with IR (information retrieval) simply couldn’t write requirements precise enough for Claude Code to directly implement.

Williams himself didn’t avoid this point. His core conclusion was: “AI development is more about being a guide than writing code. And experienced engineers are always the best guides.”

Translated plainly: Claude Code is an amplifier, not a generator. It amplifies what’s already in your head; it can’t conjure up what isn’t there.

This isn’t an isolated case: Claude Code is rewriting how engineers work

Zoom out a bit, and Williams’ experiment is just the latest example in a growing pattern over the past year.

Earlier this year, Jaana Dogan, a senior Google engineer responsible for the Gemini API, dropped a bombshell on X: she described a distributed agent orchestration system her team had spent a year refining to Claude Code in three paragraphs, and within an hour it produced a highly similar prototype. The tweet exploded among engineers. One side reacted with “we wasted a year,” while the other calmly pointed out that the year reflected process overhead — meetings, alignment, Jira grooming, naming-style debates — because writing code was already the easiest part.

Then there’s Claude Code creator Boris Cherny. The numbers he published in late 2025 were even more extreme: over 30 days, he submitted 259 PRs, made 497 commits, added roughly 40,000 lines of code, and deleted around 38,000 lines — all completed by Claude Code + Opus 4.5. He reportedly never even opened an IDE that month.

By 2026, Cherny’s workflow had evolved even further:

• The main battlefield shifted to mobile. Every day he ran 5–10 simultaneous conversations in the iOS Claude app, backed by hundreds of agents, while thousands more handled background tasks overnight.
• “Loops” became the core abstraction. Essentially cron jobs plus repeatable agent tasks: automatically fixing CI conflicts, rebasing branches, clustering Twitter feedback — all fully automated.
• Inside Anthropic, no one writes code manually anymore. All SQL and all features are model-generated, while different Claude agents coordinate through Slack.

It sounds like science fiction, but this is how Cherny describes everyday life in 2026.

So what does it actually mean when people say “programming is solved”?

Cherny once said: “For me, programming has been solved.” But he immediately added that this isn’t universally true — there are still many complex codebases and niche languages models can’t handle well.

Putting Williams’ Zettair experiment together with Cherny’s daily workflow leads to several fairly reliable conclusions:

First, the real productivity curve of AI programming is modulated by the user’s domain expertise.

Williams could build Zettair with Claude Code because he was the original author of Zettair. Dogan could reproduce a year of Google team work in an hour because she was already a staff engineer in that field and knew exactly what mattered and what didn’t. Give the same prompts to a developer who knows nothing about search engines, and they’d likely end up with a toy that technically searches but is unusable — broken tokenization, chaotic relevance ranking, terrible performance. Diagnosing every one of those issues requires expertise.

Second, the value of programming skills is shifting from implementation to judgment.

Cherny used an excellent analogy about the printing press during a Sequoia interview: before the printing press, only about 10% of Europeans were literate, and literacy itself was a scarce skill employed by nobles. After the printing press spread, literacy eventually rose to 70%, but writing itself stopped being a profession. Accountants, lawyers, doctors, journalists — they all became literate, but literacy became infrastructure.

Software engineering is following the same path, only much faster. In the future, what remains scarce won’t be people who can write code, but people who can:

• Break vague business problems into clear technical goals
• Instantly recognize when AI has gone off track
• Design workflows that let agents collaborate effectively
• Spot architectural risks in AI-generated solutions

Everything Williams did in the Zettair project falls into those categories.

Third, narratives like “I didn’t write a single line of code” should be treated cautiously.

They’re extremely attention-grabbing, but they can mislead readers into skipping the most important part: prior knowledge. A more accurate framing would be: “I didn’t write a single line of code, but I previously built this system, understand this system, and can judge whether every step is correct.”

Practical advice for developers who want to follow this path

If you want to genuinely make use of Claude Code (or similar agentic coding tools), several broadly useful methods can be extracted from the practices of Williams and Cherny:

1. Use Plan mode to refine the approach first, then let the model execute it in one shot. Cherny repeatedly emphasizes that spending a few extra minutes planning can save hours during implementation. This mirrors human code review logic: upfront alignment is always cheaper than later rework.
2. Turn repetitive high-frequency tasks into slash commands or sub-agents. Code simplification, E2E testing, CI fixes, automatic rebasing — Claude can run these loops on its own.
3. Run multiple agents in parallel. One writes features, another reviews, another runs tests. Don’t force AI into serial execution when the tasks are naturally parallelizable.
4. Start experimenting in domains you know deeply, not unfamiliar ones. Williams choosing Zettair wasn’t accidental — he could instantly judge whether outputs were correct. If you’re just getting started with Claude Code, begin with business modules you know best.
5. Integrate AI into the engineering workflow rather than stopping at the editor. Slack, BigQuery, Sentry, PR review — Claude Code can connect to far more tools than most people realize. The real leverage comes when it enters the team collaboration pipeline.

Final thoughts

The most valuable part of Williams’ experiment isn’t “how powerful AI is,” but the mirror it holds up to the industry:

When the execution cost of programming approaches zero, who can still continue creating value?

Clearly, it’s not the people insisting “I must handwrite every line of code,” nor those who think “knowing how to use AI is enough.” It’s the people who both understand the domain and understand how to make AI work for them.

The Zettair search engine itself isn’t what matters. What matters is that the knowledge Williams accumulated twenty years ago is still the leverage point that lets him effectively wield Claude Code in 2026. For everyone still writing code today, there’s a clear implication: the domain expertise you accumulate now may become the capital that allows you to direct AI five years from now.

Incidentally, if you’re in China and want to try Claude Code or compare Sonnet 4.5, Opus 4.5, GPT-5, and Gemini under the same prompt, you can check out OpenAI Hub — one API key for switching between mainstream models, without the hassle of constantly creating accounts. It’s convenient for comparative experiments.

Sources

• Former Google engineering lead uses AI to build a Wikipedia search engine - IT Home: Original report on Hugh Williams using Claude Code to build the Zettair search engine.