Sitemap

Two Claudes

4 min readJan 8, 2026
Press enter or click to view image in full size
Left: Portrait of Claude Monet by Nadar, 1899 (public domain). Right: Photo of Claude Shannon from Mathematisches Forschungsinstitut Oberwolfach (CC BY-SA 2.0 DE).

Claude Monet painted the same haystack over and over — at dawn, at dusk, in snow, in summer. He started late in the year of 1890 and kept going for seven months, producing around 25 canvases of the same grain stacks sitting in a field near his house in Giverny.

Press enter or click to view image in full size
A mosaic of six paintings from Claude Monet’s celebrated Haystacks series (1884–1891). All images are in the public domain, courtesy of Wikimedia Commons.

He didn’t work from first principles. He just painted. When he noticed how quickly the light was changing, he had his stepdaughter wheel out more canvases via wheelbarrow. The theoretical framework for what he’d accomplished came mostly from critics who looked at the work after.

Claude Shannon is an analytical thinker. In 1948, he published “A Mathematical Theory of Communication,” which created the field of information theory. Where Monet captured light empirically, Shannon captured information mathematically. His entropy formula describes the principles of data compression. Every digital system we use today rests on foundations he laid.

Both Claudes changed their fields. But they represent two different ways of advancing knowledge.

Anthropic named their AI assistant Claude after Shannon — the theorist, the one who built frameworks. I wonder if Monet would have been just as fitting. We’re in an era where the tinkerer’s instinct matters more than the theorist’s rigor.

The era of tinkering

Large language models work, impressively well, before anyone fully understands why. The scaling laws that govern them were discovered by running experiments, not deriving theorems. Building effective AI systems today is less about understanding the model’s internals and more about constructing the right scaffolding around it — agent architectures that manage context, tool integrations, coding environments that let the model act on the world. Practitioners develop intuition through building, figuring out what works through trial and error. The theoretical explanation came after, and it’s still incomplete.

This pattern isn’t new. Steam engines powered the Industrial Revolution for decades before thermodynamics explained why they worked. Edison electrified cities through trial and error, not by applying Maxwell’s equations. Theory often follows practice, sometimes by a generation.

What’s different now is the infrastructure. GPUs have gotten dramatically better for AI workloads, and many ideas can now be tested locally on devices like the Nvidia DGX Spark or through API services like Modal and Tinker. GitHub lets you fork someone’s idea and extend it. AI coding assistants compress the time from concept to prototype. The feedback loop between “what if?” and “let’s see” has never been shorter.

The permission problem

A lot of people feel they need permission to build. They want to understand the theory behind systems before trying it themselves. They want to read the papers and understand the math before getting their hands dirty. They feel like impostors using techniques they can’t completely explain.

I think this is backwards. Understanding is a side effect of building, not a prerequisite for it.

Monet didn’t paint 25 haystacks after understanding the physics of light. He was curious and wanted to experiment. The understanding accumulated through repetition, through noticing what worked and what didn’t — empirical knowledge that no amount of studying could have provided.

What makes good tinkering

Tinkering without any feedback is just flailing. The difference between productive experimentation and wasted motion comes down to a few things.

Iteration matters. Monet painted many times. When a canvas wasn’t working, he moved on. He was willing to keep trying.

Taste matters too, but taste isn’t something you arrive with. It comes from extensive, repeated tinkering with real feedback — user signals, system performance metrics, the gap between what you expected and what actually happened. You develop an internal compass for what “good” looks like by building things and watching how they perform. There’s no shortcut.

And there’s a willingness to tackle hard problems without waiting for permission from domain experts. Tinkerers don’t ask whether something is in their wheelhouse. They just try it. Sometimes they fail, but often they discover the problem wasn’t as hard as the gatekeepers thought.

My own path

I learned this through experience. In university, I built websites, games, social media apps — not for credit, just to see what different frameworks felt like. My program taught C and C++. I taught myself Python, Go, JavaScript, Erlang.

In graduate school I worked on database research. The expected output was publications, theoretical contributions. But I still tinkered. I implemented system designs from scratch to understand them. My datasketch library started as an experiment with the most efficient way to compute MinHash using Numpy. Tinkering inside an institution that valued theory, but tinkering nonetheless.

This has served me well in the LLM era. The field rewards people who build. Understanding follows.

Theory will return

I’m not dismissing theory. Shannon’s framework was transformative — it gave us the foundation. The theorists will come back. They’ll use tools built by tinkerers to formalize what we already understand practically. They’ll identify the limits we’ve been bumping against and unlock the next level.

But that’s not the job of today. Today is for building.

If you’ve been waiting for permission, waiting to understand before you build, just pick up the brush. The light is changing.

--

--

Eric Zhù
Eric Zhù

Written by Eric Zhù

Building AI Agent Systems. Senior Staff Engineer at Alibaba, ex-Microsoft Research, Architect of AutoGen.