totesen

A lot of people say AI will make us all "managers" or "editors"...but I think this is a dangerously incomplete view! Personally, I'm trying to code like a surgeon. A surgeon isn't a manager, they do the actual work! But their skills and time are highly leveraged with a support team that handles prep, secondary tasks, admin. The surgeon focuses on the important stuff they are uniquely good at. My current goal with AI coding tools is to spend ~100% of my time doing stuff that matters. (As a UI prototyper, that mostly means tinkering with design concepts.) It turns out there are a LOT of secondary tasks which AI agents are now good enough to help out with. Some things I'm finding useful to hand off these days: - Before attempting a big task, write a guide to relevant areas of the codebase - Spike out an attempt at a big change. Often I won't use the result but I'll review it as a sketch of where to go - Fix typescript errors or bugs which have a clear specification - Write documentation about what I'm building I often find it useful to run these secondary tasks async in the background -- while I'm eating lunch, or even literally overnight! When I sit down for a work session, I want to feel like a surgeon walking into a prepped operating room. Everything is ready for me to do what I'm good at. --- Notably, there is a HUGE difference between how I use AI for secondary vs primary tasks. For the core design prototyping work, I still do a lot of coding by hand, and when I do use AI, I'm more careful and in the details. I need fast feedback loops and good visibility. (eg, I like Cursor tab-complete here) Whereas for secondary tasks, I'm much much looser with it, happy to let an agent churn for hours in the background. The ability to get the job done eventually is the most important thing; speed and visibility matter less. Claude Code has been my go-to for long unsupervised sessions but Codex CLI is becoming a strong contender there too, possibly my new favorite. These are *very* different work patterns! Reminds me of @karpathy's "autonomy slider" concept. It's dangerous to conflate different parts of the autonomy spectrum -- the tools and mindset that are needed vary quite a lot. --- The "software surgeon" concept is a very old idea -- Fred Brooks attributes it to Harlan Mills in his 1975 classic "The Mythical Man-Month". He talks about a "chief programmer" who is supported by various staff including a "copilot" and various administrators. OK, so there is a super obvious angle here, that "AI has now made this approach economically viable where it wasn't before", yes yes... But I am also noticing a more subtle thing at play, something to do with status hierarchies. A lot of the "secondary" tasks are "grunt work", not the most intellectually fulfilling or creative part of the work. I have a strong preference for teams where everyone shares the grunt work; I hate the idea of giving all the grunt work to some lower-status members of the team. Yes, junior members will often have more grunt work, but they should also be given many interesting tasks to help them grow. With AI this concern completely disappears! Now I can happily delegate pure grunt work. And the 24/7 availability is a big deal. I would never call a human intern at 11pm and tell them to have a research report on some code ready by 7am... but here I am, commanding my agent to do just that! --- Finally I'll mention a couple thoughts on how this approach to work intersects with my employer, @NotionHQ First, as an employee, I find it incredibly valuable right now to work at a place that is bullish on AI coding tools. Having support for heavy use of AI coding tools, and a codebase that's well setup for it, is enabling serious productivity gains for me -- *especially* as a newcomer to a big codebase. Secondly, as a product -- in a sense I would say we are trying to bring this way of working to a broader group of knowledge workers beyond programmers. When I think about how that will play out, I like the mental model of enabling everyone to "work like a surgeon". The goal isn't to delegate your core work, it's to identify and delegate the secondary grunt work tasks, so you can focus on the main thing that matters.