Self Inventory

Between dropping off the kids and my first meeting of the morning I built a scrollytelling analysis platform (hoping to have this open sourced very soon). Not a sketch or a prototype. A working application with interactive D3 visualizations, pre-packaged analysis vignettes with metadata context, and an agentic execution flow that could run the vignettes forward. I packaged the whole thing into a binary with a build and deployment system and got it into the hands of my peers before lunch. In a previous life this would have taken me two weeks, probably three. I’d have spent days just wrestling with D3’s method chaining patterns, adapting animations to the shape of the data, debugging transitions that fired in the wrong order.

I spent years learning those patterns. I studied Mike Bostock’s work, internalized the idioms, built hard-fought fluency with selections and joins and the enter-update-exit cycle. The model writes better D3 than I ever did at peak understanding. It reads the documentation and source faster than me, adapts to API changes I’d have spent hours tracking down, and chains together complex animations from a description of what I want the reader to experience. What the model couldn’t do was envision the thing. The choice of scrollytelling as a form, the architecture of how vignettes would be packaged with their metadata and executed agentically, the decision to distribute it as a single binary rather than a service. Being opinionated about architecture and distribution was critical. Without those opinions the model would have produced something, but not a system that did what I needed it to do in the hands of my peers. That was taste, not execution. Kahneman would call this System 2 labor I poured years into becoming System 1 intuition, then commoditized entirely.

The inventory

Nate Jones has been making arguments about where value is migrating in knowledge work and what that means for careers. His framing keeps hitting me on about a one-to-two week delay from my own realizations, which is both validating and unsettling:

We need relentless honesty about where value is moving. This requires looking at our own work and asking which parts are really valuable and which parts an agent could handle better, cheaper, and faster. Most people don’t want to do this inventory. It can require admitting that skills you spent years building are depreciating fast. But the people who do the inventory are the ones who can reallocate their time toward the things that still matter before the market forces them to.

I’d never thought about career. I thought about craft, about implementation, about the satisfaction of making a thing work at every layer of the stack. Jones is useful to me because he’s analyzing from outside that identity, looking at labor market dynamics and reallocation patterns. I was arriving at similar conclusions from the inside, through the lived experience of watching my hard-fought skills compress into prompts.

So here is the inventory. Three things I’ve historically taken pride in that I now need to examine honestly.

I’ve spent a great deal of time cultivating taste for specific technology stacks, implementations, and patterns. This was time consuming to initially curate, but also time consuming because I’d reticently avoid new technologies out of discomfort with unfamiliar patterns. Not liking Docker for runtime security reasons pushed me to LXC, then systemd-nspawn, eventually Podman. I genuinely enjoy Podman and have what I consider robust deployment patterns that were hard fought to grasp. But in discussion with nearly any modern model I can prod it into a more sustainable version of those pattern ideals because it can read documentation and source faster than me. The taste was valuable. The reticence about implementation was not.

I’ve been reluctant to utilize abstractions provided by others, preferring to roll my own from whatever layer I can get my hands on and move upward. This forced me into obsessing over implementation details that have been simplified, abstracted, and commoditized outside of highly regulated deployments. Increasingly I think that confirmation of compliance will be a continuous-check-continuous-analysis task set up by a systems thinker rather than hand-rolled by an implementer.

I’ve pridefully been fixated on delivery while carrying the burden of the previous two, feeling that the primary value is to deliver informed by the craft cultivated above. Implementation was the proof of understanding. Now implementation costs are driving significantly downward, and delivery is less about proving you can do the work and more about proving you knew what work to do.

Two epochs

For ten to twenty years “what I can make” and “my capacity for making things” was nearly my entire identity. The first epoch that cracked this open was having children and deciding to be emotionally present. Learning about things like IFS, choosing to be a present father, building a more rounded sense of what I am beyond what I produce. That transition moved me from “I am what I make” to “I am more than what I make.”

This is the second epoch. Implementation commoditizing moves me from “my value is how I make things” to “my value is knowing what to make and why.” Both transitions pull away from the computational, the memorized, the mechanical, and toward something more observational and systemic. And the second one is less threatening because the first one already happened. If my entire identity were still bound up in what I could build with my hands in code, this moment would be existential. Instead it is exhilarating.

Systems thinking as the antifragile skill

I’d been reading Stafford Beer, Melanie Mitchell, Nassim Taleb, and Dan Davies to think about building modeling and simulation systems. The realization landing now is that the same skills (describing system state, reasoning about convergence, understanding where opacity creeps in) are exactly what’s needed for specification and context management in an agentic world. The fragility Taleb describes in Antifragile is over-optimizing for implementation mastery in a world assumed to be stable. When the environment shifts, all that optimization becomes liability. The antifragile move is Beer’s insight from the viable system model: design systems that remain viable without managing every implementation detail. Describe desired system state clearly enough that if it were agentically constructed, repeated implementations would converge on the same behavior. That’s a harness, but pointed at the system level rather than the implementation level. Davies’ The Unaccountability Machine offers the necessary warning: if you can’t specify it well enough, you get opaque unaccountable systems. The inventory isn’t just about letting go of implementation pride. It’s about getting serious about the harder skill that replaces it.

I’ve built more in the last six weeks than likely the last three years. The inventory isn’t a funeral for old skills. It’s a reallocation toward the things I actually want to build, with the honest acknowledgment that the bottleneck was never my ability to implement. It was always my ability to describe what I wanted clearly enough to get there.