“The product of mathematics is clarity and understanding. Not theorems, by themselves.” — Bill Thurston

Bessis makes the argument that mathematics has publicly been valuing proving theorems as the high status work, while systematically undervaluing and disguising the critical roles that creativity, community, clarity, and teaching play in advancing the field. Critical work got done without anyone explicitly setting out to do it, as an unacknowledged byproduct of the system of human production. Now with the advent of LLM powered theorem provers the theorem proving can happen in the absence of those critical side effects.

“definitions are worth zero points, expository work counts negative, and the best jobs should always go to the people who proved the hardest theorems.” — David Bessis

The parallels to writing code write themselves. How should we think about the value of code that passed the tests versus code that has been socially constructed in a way that leaves the team prepared to operate on it, iterate it, and improve it? How should we think about the value of 200k lines of unintelligible Lean autoformalization?

Two interesting terms to come out of the exploration:

Canonization - general, reusable, coherent, efficient, and compatible.

By canonization, I mean the process of taking a local, one-off formalization and turning it into library mathematics: general, reusable, coherent, efficient, and compatible with the rest… Canonization often changes the picture itself: the definitions, the abstractions, the API, and sometimes even the statement… This is extremely difficult and time-consuming. - Alex Kontorovich

This is the difference between code written for yourself, as part of a greenfield, or as a one off. Canonization is the separate work of turning the “I got it working” version into something the future can build on.

Fork in the road here. Bessis asserts that the only true value of proving a theorem is for the practitioners that follow. In software we explicitly have the inverse situation, disposable code we put in production is a key learning tool, arguably you can’t know the correctness and value of the work until you’ve deployed, this is the entire idea behind MVP.

Still we all benefit everyday from code that has been canonized, the stable abstractions, the boringly reliable systems we don’t have to think about, the encoded best practices. That weird of the moment phenomenon where everyone has a vibe coded solution for you to try to a problem, and it feels more reliable to vibe your own, that’s the lack of canonization we’re feeling. When we say “coding has always been the easy part” we’re explicitly drawing a distinction between the act of getting lines of code into a text file and the canonization. It’s the photo negative of “technical debt”. Features of a codebase that resist change, the code that sucks the will to live are measures of an absence of effective canonization. (though often, especially in the traditional human powered software systems they were also evidence of bad canonization)

We’re in a golden age of disposable and single use software. This software reads as “bad” to any pre-existing aesthetic judgement. Those definitions of “good” and “bad” software was a doing a lot of implicit, unstated work. Canonization feels like a useful term to make that work explicit for software that needs to live on, and be legible to systems of humans and non-humans operating on it. Canonization is the difference between work that does today’s task and work that is accretive. (and value exists in both)

The Overhang

I’m always a sucker for a good “The Thing” coinage (see “The Jackpot”), and The Overhang is no exception.

The Overhang consists of the unrealized capital gains of past (mathematical) creativity, the latent value from connecting the dots in the existing corpus. It is a dividend of canonization. Mathematician X states problem A, mathematician Y crafts concept B, then mathematician Z notices that B trivially solves A and “captures” the social reward. But in the process of capturing the reward, Z usually introduces new concepts and new open problems, reinjecting latent value into the Overhang.

LLMs, being tools that naturally can memorize the entire corpus and pattern match on it, are extremely well suited for searching the Overhang, and do it in a way completely distinct from how humans do it. If an LLM searches by reading everything, humans are engaged in a fundamentally different project with intuitive leaps based on reading a small number of papers and interacting with other brains.

Software has an Overhang as well. Open source. Decades of canonized, intelligible, build-on-able work, sitting in public repos. (and Stack Overflow, and blogs, etc).

The Overhang is genuinely exciting, allowing us to discover (develop) things that would never have been realized with just human brains on the problem. The dream of searching the Overhang has existed for decades, or at least since Highlander II: The Quickening.

Don’t love Bessis’s coining of “intuition-maxxers”, but I’m absolutely familiar with and excited about the people “seeing further than anyone before, standing on the shoulders of giant machines.”

But if we’re not careful, the Cognitive Surplus becomes the Cognitive Seed Corn (as in the eating of, credit Migurski). If we continue to value only the work of theorem proving (coding) and not the work of canonizing (and also training the next generation of practitioners) then the Overhang will grow increasingly poor as a search space. We see this already in how reviewing is more fatiguing and also unrewarded. No one gets status for doing cleanup. (see Tanya’s glue work)

Generation easy. Canonization hard. Running code valuable; presumably autoformalization too. But the intuition and the social production of knowledge are the seed corn. Our task is to reimagine how teams work and what we give status to, so that our practices don’t leave our people or the Overhang depleted.

Claude Code felt like magic when I used it for the first time (14 months ago?). And then it felt like magic again when the models got good at code at the end of the year.

But then I wanted to be able to vibe code entirely from my phone, one handed on vacation, while sipping a fruity drink and playing beach soccer with the kiddos, which brought me to exe.dev and Shelley. Shelley is great because its batteries included, all the tools you need out of the box to do web development.

Of course after that it started to feel clunky. The UI is a power tool of options, compaction is disruptive at a time when most agents are smoothing that experience out, exe.dev is still primarily focusing on it’s magic SSH setup experience, but I’m on my phone, and the phone based ssh/terminal clients feel like the increasingly baroque products of an evolutionary dead end.

So now I’m using “Claude Code for Web for iOS” (I think that really is the product name), and it’s simple and elegant, that nice soothing color palette of Anthropics, fewer things shoved in than the web experience, and it’s just “chat with your repo”, no vestigial or distracting UI elements.

Kiddo and I took some photos of sketches she made and started building a game together on the subway ride to school. She’s the artist and art director, I’m holding the phone with Claude on it in one hand, and the pole in the other.

But the tools are surprisingly weak.

• There’s no built in hosting option, surprising given Claude for Web has had artifacts forever, I’m reduced to using githack to get live previews of the work (and with some fiddly caching issues).

• It can’t see your work, no VLM, no screenshot tools, no Playwright/Chrome Dev Tools skills. Certainly nothing as sophisticated as the Shelley tools around mobile web emulation, profiling, accessibility, etc. (also when is Claude get video support a la Gemini?)

Off the train, with two hands and a spare minute exe.dev/Shelley looks a lot more compelling (and the price differential between Anthropic’s subsidized accounts is getting smaller as the subsidies get smaller). But rising expectations mean none of it is feeling magical anymore, just all tools and compromises, and TODO: FIXME. Which is, in and of itself, wild.

First attempt was VPS + Tailscale + tmux + Moshi + Claude Code Remote Control.

Clunky. SSH on the phone is never going to be fun. Claude Code /rc is very much a 1.0 product (sorry Andy!), I didn’t have a good pipeline to serving the things I was building, and when I put CC on yolo’ing some network configurations I lost access to the VPS, and breaking back in is a post vacation activity.

Second was using exe.dev, and in particular their agent Shelley. (Frankenstein reference?)

It’s been a ton of fun, works great on mobile web. Comes with a sophisticated set of tools around coding, researching, brainstorming, testing in browsers (including mobile emulation, accessibility and performance), visual QA, etc. As someone who has been playing with souping up harnesses recently this feels like a nice one. It uses sub-agents by default, and async web UI so it’s all background work by default. Has a built in code to publish pipeline. I’m having a lot of fun with it. My only caveat is I’m not sure how much it’s going to cost, I can’t really reason about that bit yet.

Started building a fun toy while we waited on the tarmac at JFK: a garden of generative coding techniques (in an older sense of the word).

And then I had it check out my blog repo, new my new post script, and I transcribed this blog post while getting a break from the sun. Fun.

Calling one of the various LLM APIs is easy. But requires key management. For me on a personal project that’s no big deal. In a work context it’s less trivial. But I’m working in claude, which means I have a tool talking to a LLM API running already all the time, that already has not only an API key, but also an allocated budget that is being managed around making me more productive. Much easier if all my LLM based productivity is spend hits a single line item.

E.g. a quick script to classify Github PRs has a section like:

  return f"""You are classifying GitHub pull requests for an engineering team.

  PRODUCT AREAS (choose exactly one per PR):
  {area_lines}

  WORK TYPES (choose exactly one per PR):
  {work_type_lines}

  For each PR, return a JSON array with these fields:
  - pr_id, product_area, work_type, confidence, keywords

  Return ONLY the JSON array. No prose, no markdown fences.

  PULL REQUESTS:
  {prs_text}"""

And the call itself:

  def _call_claude(prompt: str) -> str | None:
      try:
          result = subprocess.run(
              ['claude', '-p', '--output-format', 'text'],
              input=prompt,
              capture_output=True,
              text=True,
              timeout=300,
          )
          return result.stdout.strip() if result.returncode == 0 else None
      except (subprocess.TimeoutExpired, FileNotFoundError):
          return None

Probably this is what the agent sdk is for? This worked.

I played it a ton during Early Access, and it’s great to see it finally reach 1.0. I highly recommend it.

One of the things they added in 1.0 is a full automation system. Finally. (Though I’ll be honest I was mostly okay with Sluice Gate there by the end at least for basic reservoir management). But now you can get serious! Automations can work on water depth, flow, contamination, the weather, resource counts, population counts, etc. There is memory, and a full complement of logic gates for wiring up your very own beaver powered Turing machine.

But one of the things they also added to 1.0 is the ability to have the game call arbitrary HTTP endpoints, and vice versa.

If you build an “HTTP Lever”, Timberborn will expose HTTP endpoints for turning it off and on on localhost. Connect it to a fireworks launcher and now you can have fireworks launch across the sky every time that endpoint is called.

Have Claude Code add a Notification hook that calls that endpoint like so, and now every time Claude needs your attention: fireworks launch in Timberborn.

(Or you can add it to the Stop hook if you want to know every time Claude stops)

{
  "hooks": {
    "Notification": [
      {
        "matcher": "",
        "hooks": [
          {
            "type": "command",
            "command": "curl -s 'http://localhost:8080/api/switch-on/HTTP%20Lever%201'"
          }
        ]
      }
    ],
    "Stop": [
      {
        "matcher": "",
        "hooks": [
          {
            "type": "command",
            "command": "curl -s 'http://localhost:8080/api/switch-on/HTTP%20Lever%201'"
          }
        ]
      }
    ]
  }
}

Anyone who tells you they have this current moment in coding figured out is lying to someone (you or themselves). I’m going to keep sharing half-formed thoughts, and bits of things I’ve learned.

As the cost of writing code goes to zero new strains and bottlenecks appear. This is what we expect when we think about building software as a system. For most teams the first place that strain appears is in code review.

No one wants their job to become spending all day carefully reviewing code that someone else had a machine generate in minutes.

Simon wrote yesterday about the anti-patterns of Inflicting unreviewed code on collaborators. Also nice to read the recent How to Kill the Code Review, and see an old friend like the Swiss cheese model.

Code review is a funny topic.

Most senior engineers and engineering leaders I know have always been quietly skeptical of its value. It’s expensive, and the data on defect detection doesn’t justify the cost. Meanwhile teams tend to put too much trust in code review while underinvesting in other tools to gain confidence: monitoring, automation, better coding tools and practices, training, etc. (Swiss cheese!)

Code review ubiquity is tied to GitHub’s (really quite recent I promise you!) rise to ubiquity, a tool designed for open source development, that quickly sublimated into being “conventional wisdom and best practice”. So much to say about how in software, we keep believing we’ve found “normal” and “best practice,” forgetting we’re 50 years into an experiment where we tear up and reinvent best practices every 5–10 years.

As a senior leader you sort of shrug and sigh, and be glad that code review has some nice side benefits like ensuring that information is dispersing through the organization, that people are talking to each other, learning and teaching is happening, all of which are valuable.

But that is all about code review for human written code and so I digress.

On my team we’re not ready (yet?) to ditch code review, but I got this insightful feedback on the first large AI generated PR I tried to land that has shaped my thinking. 

In a manually coded PR, if a reviewer comes in and pushes back on the design, then that’s often a smell that the design wasn’t sufficiently socialized prior to spending time on the implementation. So we have meetings to review designs, we write RFCs, etc, to get consensus about how to do a thing before we commit effort to it. In this case, you went through the planning phase with the agent to determine the approach to take, and then had it churn out the diff.

getting design push-back in a manually written PR is annoying because the effort expended to write it was wasted if the design has to shift. But if the agent is able to quickly produce a new diff once a plan is updated to reflect design feedback, then push-back on the plan isn’t a big deal because we can just update the plan and re-run the agent.

Anyone working with coding agents regularly knows the planning phase is where the bulk of the time is spent not to mention where the human cognition and creativity is happening (that and designing the verification steps). Plan → save the plan → implement → describe diff → review → verify → fix → possibly update the plan.

Implementation, the generating of code, is really a rather minor and cheap part of the process. Why obsess on getting feedback on that part?

That’s our latest learning as a team: Socialize and get feedback on the plan. (Also on the verification steps. And maybe on how you configure your reviewers.)

This is the most human to human high bandwidth work.

I liked a lot of the framing of the problem in Simon’s and Ankit’s posts (and seeing an old friend like Swiss cheese model). But I think their solutions missed out on a plan for ensuring the continuation of the real value that code review provides: socialization, information dispersal, learning and teaching.

Ankit is right, the human work moves upstream (as it always has).

You can look at the code. But honestly, it’s the human driving the agent’s job to worry about the code, ensure it works, and that they meet the standards of the org. We can do something more valuable with our teammates time when we ask them to review our work.

Software, in a Time of Fear

Up front, here are the lessons:

1. Stop listening to people who are afraid
2. Seek first-hand testimony, not opinions
3. Go with someone much more enthusiastic than you
4. Do not look down
5. You must get different equipment
6. Put the summit out of your mind

Yet I hope you stay for the hike up.

Personally I’m working on 1, 2, 3, and 5. I’m struggling with 4 and 6.

Had a call with Jesse the other week and we discussed how we’re speed running the last few decades of engineering management. The swarm craze of the last few weeks bringing us solidly up to Fred Brooks.

Writing about software development over the years has always suffered from at least two key challenges:

• the vast majority of the writing suffers from survivor bias and serves as a record of something that worked for this particular set of humans in this particular set of circumstances.

• most of the writing has implicitly assumed a highly rational, implacable, rule following software engineer completely at odds with all the software engineers I’ve known (and wildly at odds with the best of them)

But if our software theories often assumed emotionally and morally stunted automatons with limitless patience, might they be useful in today’s context?

• TDD, always hit and miss for humans, clearly works well for agents.
• The folks I’ve spoken with who are experimenting with maximalist approaches to agentic coding talk a lot about components and isolation in ways that remind me of microservices (terrible for humans), and CORBA before it.
• Bake-offs (the agent might get attached to their implementation, but only for the space of that shell)
• Sub-agents have some of the insights of pair programming encoded in the practice, enough that it makes me wonder about the rest of the XP toolkit.
• UML and Rational Rose coming back?

I wonder what else from the scrap heap is worth poking at?

update: Big Up Front planning was pointed out to me as a classic technique that worked poorly with humans and is coming back as planning becomes more key

We’ve always had this tension. We’ve always fetishized the act of writing code, the quality of the code, the code as the primary artifact and IP. And on the other hand successful teams have always known that the value is the system, the value is human-technology hybrid that allows a product to be delivered, meet customer needs, evolve to provide more value over time, meet the spoken and unspoken needs of the problem domain, etc. This confusion in our thinking has laid at the heart of why, for example, technical hiring was such a disaster for so long. (Hiring continues to be terrible but it’s actually much better than it used to be. We now make fun of teams that ask you to reverse a linked list on a whiteboard while evaluating if they’d like to have a beer with you. That used to be the norm)

Said another way, we’ve known for a long time that code is the easy part. Has arguably always been the easy part, but certainly has been the easiest part of building software for the last several decades.

Yes: this is a genuinely new moment.

Yes: the last 3-4 months of frontier models, and Claude Code and its ilk are genuinely something new in the world.

Yes: the cost of producing code is plunging towards something near to zero faster than almost any of us can imagine, and that’s going to require a ton of change.

Yes: it’s already breaking social contracts and requiring rethinking about how teams work together. (Review is fatiguing in a way that creating is not, something else we’ve known for a while.)

Also yes: I’m feeling the dissociative awe at the temporal compression of change.

But code being the easy and cheap part is not new.

Technology changes requiring us to rethink our social contracts and how our teams work is not new.

The web, CI/CD, large scale sites, mobile, SPAs, machine learning and data, all of these broke how teams worked and required us to invent new ways of working.

I think it’s fascinating to read about running a dark software factory with a team of 3 people. I think as a leader with a much larger (though comparatively small) team of humans I’m going to need to be equally creative on the right way to incorporate humans rather than exclude them from the process. And honestly those conversations are fun. It’s been a while since we’ve gotten to throw all the pieces up in the air and see what works.

It’s reasonable to be skeptical of AI because so much of the hype around it, and so many of the people hyping it (and profiting from it) are also at the nexus of the most amoral and sometimes out right evil aspect of how capital has transformed tech. (Does anyone else miss when tech was funded by nice, morally uncomplicated actors, like the US Department of Defense, back when it was still called the Department of Defense)

It’s also reasonable for people who entered technology in the last couple of decades because it was good job, or because they enjoyed coding to look at this moment with a real feeling of loss. That feeling of loss though can be hard to understand emotionally for people my age who entered tech because we were addicted to feeling of agency it gave us. The web was objectively awful as a technology, and genuinely amazing, and nobody got into it because programming in Perl was somehow aesthetically delightful. (The language is referred to as write only line noise for a reason)

The cost of code is going to zero. That’s genuinely neat, and mind blowing, and going to require reinventing so many things. It was still never the hard part.

This project has been on my todo list for a long time (probably even before the 2016 date I have written down here). I was inspired by Trees Near You, an awesome hack from Brett Camper at a hackathon the city threw to promote its new open data initiatives (back when NYC did that kind of thing). At some point Apple changed some APIs and Brett’s awesome app stopped working and I conceived the notion to rebuild it for the web.

Now this project is largely pointless, because in the intervening decade NYC Parks has launched an excellent website to serve just this purpose. But it’s a fun, self contained little project, and I’ve picked up a couple of different times to try out new technology. (The React and React Native versions never really worked. A version I tried to build with Claude’s help in 2023 on Svelte mostly worked locally in Chrome, but never on Safari or in production). With Claude Code this time I got further.

So here is a simple Trees NYC web app. Relatively vanilla Javascript, SQLite backend. Please enjoy New Yorks 650k+ trees.

(and I was dismissed from jury duty, I don’t think the vibe coding was the reason.)