I enjoy the Outlanders 2 game, an easy going village sim. But somehow it’s never quite acquired one of those fandom wikis with the various details, and sometimes I’m curious about how many days it takes carrots to mature and what their yield is. (usually when playing in Tournament mode).

I used it as an excuse to try two LLM backed work modes I haven’t tried much, computer use and decompilation (really data mining of assets, no actual decompilation happened). Computer use was slow and finicky, and I hadn’t consciously realized that you can’t use your computer for anything else while the LLM is driving it. (I’d get bored and start doing something on my computer and come back to “Connection lost”)

Mining the game’s assets by contrast worked better and was easier than I could have possibly imagined. I didn’t have to tell it how, or anything about the data formats, or even where the files lived. I didn’t even have to sit at my computer. I setup a model running on my laptop with access to the binaries, and then a shared repo and set of issues that I could have a model on my phone task the local model with questions, and way we went.

3 carrots per field plot every 9 days btw, but also first pass on the wiki claims it’s a “building”. That’s data mining in a nutshell. (I might fix that)

So using the information Sol extracted from the game files, I quickly put together an Outlanders 2 “wiki”. (wiki in the sense that there is a repo that will accept pull requests vs “wiki” in the sense that you can click to edit). (data repo)

update Oct 28: A cold that won’t let go is apparently great for side projects. Switched from working locally, to working primarily on my phone, and using Github issues plus some in repo docs as a RPC to an agent running locally when additional information was needed. 51 pull requests, 580 data records have grown to 871, including all 260 challenge levels with the dates each one runs, a Mechanics section, search, and a look inspired by the game.

Computer use still slow, but works better when I’m not trying to use the laptop at the same time.

Here is the opening the snippet.

You live in the Weald. It’s an ancient forest. It’s dark, it’s dank, the soil is terrible, and there are probably monsters in the dark, or at least very large boars. There are other goblin villages out there. Somewhere far away is the sea, and even further away, humans, or worse, elves, so we’re not going there.

“This village is the most miserable excuse for a trash heap you’ve ever seen. There’s not enough to eat, and the food is terrible. It’s cold at night. It’s impossible to get a decent mushroom kebab or a cup of tea. And no one does a thing I tell them to.” - Robin (the hero of our story)

I’m having a lot of fun with it.

Recently there has been a loud declaration that management is dead. Organizations should flatten. Managers retrain as ICs or be let go. Etc. Facebook has been one of the loudest advocates of this approach. Six months in, they’re asking ICs to move back into management.

A different thread running through the industry is the large number of managers opting out. There’s a sense that the work has gotten harder and less rewarding at the same time, with a mix of layoffs, tighter budgets, and typical founder psychosis turned to 11 by AI. (And fomo over those generating generational wealth)

These are two sides of the same coin. When organizations don’t understand why we have management, the role is undervalued and underinvested in.

And to be honest it’s easy to see how we got here. Much has been written (including by me) on how the 2010s was the industry on easy mode, money and customers were plentiful, technical challenges were minimal and largely outsourced to cloud providers, and the primary technique for improving a team’s capacity was to hire more people. (And then we speed ran this whole dynamic again during the pandemic, extending the 2010s even as the underlying conditions changed). It just wasn’t that important to be that good at engineering leadership (or really any form of leadership) for many teams for a long time.

But now it is.

The point of a technology company is to create change. The point of engineering leadership is to increase your team’s capacity to create change. And managers? Managers are catalysts.

“Catalyst” has a colloquial definition, but it also has a technical one: a catalyst lowers the activation energy necessary for a reaction to occur. That’s what good management does.

Without a catalyst you can still create change. You add heat and pressure. Mandates. They work some of the time, and damage the system 100% of the time. Sometimes that’s the right call. A little damage now, do the expensive repair work later. If you invest in management you have a choice. If you don’t, you don’t.

In Facebook’s case the move to dramatically reduce managers (some teams moving to a 50:1 ratio) at a time they were rolling out a radical revision to their software development process resulted in a 40% YoY increase in incidents, and a drop in team sentiment from 74% to 55% over a 6 month period. Code changes were up 220%, but new value delivered to customers didn’t follow in line. That is not the type of change any of us are hoping to create.

How managers go about lowering activation energy is not a secret. It’s your standard laundry list of manager virtues. Build trust, lower cynicism. Connect the team’s local goals to larger strategic priorities, and adapt larger directional guidance to local context. Invest in both team cohesion, and development. Apple pie stuff.

We’ve known this for decades btw. There’s a classic paper, In Praise of Middle Managers, built on a 3 year field study looking at what it takes to produce radical change. There are two failure modes: low commitment to the change produced inertia, and high commitment without attention to the people living through it produced chaos. Heat and pressure is the second one. Managers who don’t understand that lowering the cost of change is their job can be part of the first problem.

Many extremely well intentioned managers can end up impeding vs accelerating change. Managers who have internalized the “shit umbrella” archetype for example are likely to understand their role primarily as protecting the team from change versus increasing the team’s capacity to drive that change. That leads to a team that is underdelivering, and a burned-out manager. High performing “local optimizers” often resist change because they’ve got the system working the way they want it. Pass-through leaders who are doing none of the local adaptation of changes breed cynicism.

Your job, as a manager, is lowering that activation energy. Growth, learning and evolution are the work that you’re here to facilitate. Especially in times of change.

Your job as a leader is to invest in managers who can do this work. Train, celebrate, empower. There is a near-infinite list of new programs and processes that need to be managed, new training, new rituals, new anxieties. The idea that at this moment you need fewer managers because AI can summarize Jira is a fundamental leadership error.

If you’re seeing resistance to change. If you’re seeing burnout increasing. If you see individuals generating more code, but the impact isn’t accelerating at the same rate. If you want to transform your system of software development, the first thing you need is managers who understand the job.

“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.