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

I’ve got Claude Code running in the background while I tab between writing this, sipping a Powers, and fielding phone calls from a team slightly panicked about the end of quarter QBR. This blog post is being written on May 27th, 2025, things may have changed by the time you read it. It was a toss up whether to post this on Notes on engineering leadership, or here, but eventually decided this was too loose for even Notes low standards. You’ve been warned (or at least given a context window with which to understand the remaining blog post).

LLMs are without a doubt the most disruptive change to how code gets written I’ve seen in my career since the introduction of the World Wide Web. As someone who largely started on the web at a time when most people weren’t, I remember reading Dr. Dobb’s 30 years ago and seeing all these ads for weird C++ binaries I could pay to include in binaries I shipped on CDs. (Jokes on me as I now work at a company that has C++ in production that dates to that era). That said, as of today, LLMs don’t change some key fundamental physics of writing code as a team. Importantly, as of today, they haven’t changed the fundamental calculation that writing code is always easier than understanding code.

The insight that reading code is harder than writing leads naturally to the insight that every line of code is tech debt. Every line of code encodes your best current understanding of the problem you’re trying to solve (for increasingly weird definitions of “you”). Nothing has changed the fact that your current understanding is probably limited, and wrong in several ways.

Updating your mental model even harder for LLMs than for engineers

If you’ve ever had the questionable joy of participating in a “technological transformation” (whether or not it was called that) than you’ve had the specific experience of how challenging it is to convince an engineering team to give up on its current test suite (for extremely variable values of “test suite”). It doesn’t matter how much you argue that the test suite is a product of the practices and understanding of the problem you’re trying to over turn. And you’ll have this same conversation iterated for each historical technical decision (but especially tests). I’ve gone through the process of convincing a toddler to give up their pacifier, and convincing engineers to give up their tests, and I’d choose reasoning with the 2 year old any day of the week.

LLMs are more challenging. As soon as you instruct them to start building context from an existing codebase, you’re in a battle to change their mind about what’s important. From tests, to schemas, to dependencies. Given the lack of explicit tools for operating on their internal model, it’s a shockingly similar process to convincing an engineer (I should note the approaches that work with a toddler do not work with LLMs, in particular bribery is largely a failure).

The saving grace for engineers is the handful of folks who through inclination or trauma either believe in a better world or just want to see the current world burn and are therefore inclined to radical departures. My experimental data suggests telling LLMs they “just want to watch the world burn” does not make them more comfortable deleting obsolete test cases.

NIH wasn’t invented here, but we did perfect it.

Current generations of LLM are very happy to write you a new function for functionality you already have in your codebase. Your tips on incantations to add to CLAUDE.md to change this behavior welcome. Just telling it “DRY” ain’t getting the job done. (and honestly, DRY was always problematic advice that lead to premature abstraction, and that was before the nightmare that was dependency injection). Code bases with significant AI contribution are … bushy. Arguably as long as no humans are required to reason about the codebase we’re fine. It does preclude, practically from first principles, those exceptional individuals many of us have encountered in our career who seemed to be able to hold the entire code base in their brains. Arguably that’s a net positive. Those individuals were always problematic similar to those folks who are willing to work 80 hours a week and jump on every incident. At a minimum they make the rest of us look bad. But it’s still an arms race between the LLM and itself. I may be skeptical of TDD as a human practice, but as a LLM practices it’s the gold standard. But if every member of your team has their own bespoke approach to common functionality is your test suite doing its job? At a minimum you’re burning a lot of Github Actions CPU. And that’s before you ponder what does the response to Log4Shell look like in a world where everyone on your team has their own NIH bespoke logging code?

A Small Number of Well Known Tools … if it was opposite day.

Highly productive engineering teams (historically) reach that productivity by building a deep expertise in their tool chain. This is why it is so critical to closely examine introducing new technologies to your stack. An under examined cost of complicated technologies is that the cost of defining the preferred subset of capabilities falls on each development team instead of the industry as a whole. For example think about how every team that uses a “big language” (like Typescript or Scala) defines their own local subset, or paucity of Postgres best practices vs MySQL. TIMTOWTDI isn’t actually a good thing. (“batteries included” definitely won that argument) LLMs radically lower the cost of writing code (already the cheapest part of software development). With LLMs it is often easier to code an approach than research one. The exploding ecological diversity in our software environments is breathtaking.

Where we’re at today

Local, bespoke, unique, noisy, bushy, big codebases seem like the inevitable byproduct of our current tools and models. It’s possible that LLMs can be shaped into tools that making code reading and code reasoning more powerful; that help us refactor, refine, and reduce the complexity of our codebases. I’m certainly encouraging my team to experiment with what is possible. Lowering the cost of writing code was the thing that no engineering leader asked for, but it’s the thing we got.

How are you changing your leadership practices in the face of LLMs?

You’ve spent $0 on LLM APIs reading this blog post.

I’m quite confident I’m not the first person to want to do something like this. But we’ve reached an awkward and unfortunate moment in the Web’s journey where search just doesn’t work very well anymore. Except searching the latent information space of a LLM trained on the entire Web actually works unreasonably well for this sort of thing. Meaning, it is easier to write your own than find an existing solution. That’s going to have all sorts of weird consequences I’m sure.

So here’s my script, gdrive-to-s3.py. It use the MediaIoBaseDownload API to fetch files in byte ranges from Gdrive and multi-part S3 uploads which in combination remove the need to read any of these 10Gb files directly into memory or store then locally (either of which would rather rules out running the script on a t2.micro) and instead allows you to stream the data from one storage provider to another in manageable chunk sizes.

I used to leave long running jobs hanging around in load bearing screen sessions all the time. Kind of nice to return to my roots.