I went in expecting to learn about oil prices and trade baskets. I came away thinking about energy and geography. For thirty-odd years the assumption has been that where you sit on the map is subordinate to economics and US naval hegemony. Open seas, free trade, plug into the global system and your coordinates don’t matter much. I think Hormuz is showing us that assumption was wrong – and the investment baskets, the proxy wars, the ceasefire negotiations all make more sense when you look at them through that lens. This isn’t a new argument – Kaplan’s Revenge of Geography made the case in 2012, Zeihan’s been running the demographic/geographic thesis for a decade. What feels novel is watching the mechanism work in real time – Iran didn’t just leverage geography abstractly; they built a literal toll booth. The ships are transiting now, under a dozen flags, negotiating with geography directly. That’s what this post is about.

But first, the baskets

Citrini published three trade baskets around the Middle East disruption. A “trade basket” is basically a curated list of stocks that express a thesis – if you believe X is going to happen, buy these companies. The percentages next to each name tell you how much of your money goes into each one.

If you’re a finance person and already grokked all the necessary info on this stuff from the original post, feel free to skip this section, but as someone not super long on this stuff, I found that these baskets were a useful framework for the non Bloomberg terminal-pilled. Each one captures a different theory about how geopolitical chaos flows through markets.

Tanker basket. These are companies that own and operate the massive ships that move crude oil around the world. Frontline, DHT, Scorpio, a bunch of others. The biggest position is BWET, an ETF that tracks tanker freight futures – essentially a direct bet on shipping rates going up. When shipping lanes get dangerous, ships reroute around Africa instead of through Suez. Same oil, way more ships needed, way more days at sea. Rates spike. BWET has quadrupled since Citrini first recommended it.

Energy/commodities basket. Broader oil supply chain: companies that drill, refine, run pipelines, make fertilizer (natural gas is the main input for fertilizer, so energy disruption hits them hard). Oil went from $67 on February 27 to around $118 at peak. This basket is a straightforward “disruption means higher energy prices” bet. Citrini’s highest conviction play here is actually US petrochemicals – Dow and Westlake – because Gulf infrastructure damage will take 250-275 days to repair even after Hormuz reopens. US producers sitting on cheap domestic feedstock benefit regardless of how the conflict resolves.

Energy sovereignty basket. This one’s different. It’s almost entirely European and Japanese renewables companies – Vestas, Orsted, Iberdrola, RWE, plus grid infrastructure and solar hardware manufacturers. The bet is that every government watching Hormuz close now has political mandate to fast-track domestic energy buildout. Permits, subsidies, grid investment. The utilities in this basket (Fortum, Verbund, Acciona) have a particularly elegant setup: they own renewable assets with near-zero marginal cost but sell into wholesale electricity markets where the price is set by gas. When gas prices spike, their margins explode even though their costs didn’t change. Slower burn than the other two baskets, less volatile, probably only up modestly so far. But arguably the most durable thesis.

The ceasefire announced yesterday hammered all three baskets, at least short term.

The toll booth

The detail from Citrini’s field report that stuck with me most is that Iran hasn’t actually closed the strait. They’ve set up a checkpoint system through the Qeshm-Larak channel. Ship owners submit vessel details – ownership, flag, cargo, crew – to brokers. Payments go through cash, crypto, or diplomatic arrangements. Approved vessels get escorted through Iranian waters. The analyst observed at least 15 ships crossing on April 2, up from 2-5 daily in prior weeks. Ships flying Indian, Malaysian, Japanese, Greek, French, Chinese, Turkish, and Omani flags. All transiting independently. Without Washington’s approval.

Iran has turned a chokepoint into a toll booth. The Strait of Hormuz is 21 miles wide at its narrowest point, 20% of global oil transits through it¹, and Iran sits on the northern shore. That’s leverage you can’t sanction away and can’t replicate somewhere else. And the place you can see the old order breaking down most clearly is in who’s transiting right now and how they’re doing it – independently, on their own terms, without asking Washington.

Cameron framed the broader picture well: Iran and Ukraine are the pre-WWI/II proxy fights, the ones where the major powers try to settle the new order without going at it directly. You can already see it in the mediation patterns. Pakistan popping up as a “surprise” mediator in the US-Iran talks makes a lot more sense when you realize China sent them.

Geography starts to matter

Cameron and I’s conversation covered a lot of ground, but three regions kept coming up – each one illustrating a different way that physical location is reasserting itself over financial abstraction.

Iran. If sanctions get dropped as part of the ceasefire framework, 1.5-2 million barrels per day of suppressed supply re-enter the market. That’s an oil price story, sure. But Iran has been selling heavily discounted crude to China and India through shadow fleets for years because they have no other buyers. Sanctions gone means normal banking, normal pricing, normal trade relationships. Give Iran access to SWIFT and suddenly Beijing isn’t the only trading partner worth having. The toll booth at Hormuz gave Iran leverage; sanctions relief would give them options.

Cuba. Alfred Thayer Mahan called Cuba “the key to the Gulf of Mexico” the same way Gibraltar is the key to the Mediterranean², and looking at a map you can see why. Cuba flanks both the Yucatan Channel (connecting the Gulf to the Caribbean) and the Straits of Florida (connecting the Gulf to the Atlantic). Any vessel entering or leaving the Gulf passes within range of Cuban shores. That includes the shipping lanes carrying roughly 13% of total US crude oil production from Gulf platforms to refineries and markets.³

This matters right now because Russia and China are actively building presence there. In June 2024, Russian warships carrying hypersonic missiles docked in Havana – the largest Russian show of force with Cuba in years.⁴ Russia ratified a formal military cooperation agreement with Cuba in October 2025.⁵ Meanwhile, CSIS has identified four Chinese signals intelligence facilities on the island through satellite imagery, including one at Bejucal less than 100 miles from Florida that can monitor Kennedy Space Center launches.⁶ In March 2026, a Russian oil tanker broke the US fuel blockade with 100,000 tonnes of crude.⁷

In short: Cuba caps the Gulf for the US and gets Russia out of our hemisphere. That’s a Monroe Doctrine argument. The economics of Cuba – nearshoring, tourism, whatever – are hypothetical and frankly unrealistic under current conditions. Trump is running maximum pressure, the island’s population has dropped over 10% in four years from emigration⁸, the power grid collapsed in March.⁹ None of that changes where Cuba is on a map. It controls chokepoints the same way Iran does, and other powers are already treating it accordingly.

The EU. The EU-as-superpower scenario is probably the most underpriced thing in markets right now. Common defense spending, real industrial policy, joint debt issuance – if it happens you get a completely different European investment surface. But the reason it’s underpriced is because it’s genuinely hard. The Franco-German engine that’s supposed to drive consolidation is stalled: their EUR 100B+ joint fighter jet program (FCAS) is collapsing over workshare disputes¹⁰, Macron is pushing for common EU debt and Germany is explicitly rejecting it¹¹, and their competing visions for industrial policy are pulling other member states into opposing camps.

The energy picture is a useful reality check. Europe has spent EUR 300 billion on REPowerEU¹², cut Russian gas imports from 45% to 13%¹³, tripled US LNG imports¹³, and hit a milestone in 2025 where wind and solar generated more EU electricity than fossil fuels for the first time.¹⁴ And despite all that, the Hormuz closure – which directly affects only about 10% of EU LNG¹⁵ – still sent Dutch gas benchmarks nearly doubling, triggered fuel rationing in Slovenia¹⁶, and forced the ECB to postpone rate cuts. Geography doesn’t care about your spending programs.

But I think the most interesting take on this whole geography thing has to do with trade routes and climate. Historically, European power flows East-West through the Mediterranean. Spain, Italy, Greece – they control the sea lanes, which makes them more strategically important within the EU than their GDP might suggest. But global warming means the Arctic is opening up. China already runs an “Arctic Express” container service from Shanghai to Rotterdam, Hamburg, Gdansk, and Felixstowe – 18 days versus 35-50 via Suez.¹⁷ Nature Communications projects the first ice-free Arctic day before 2030.¹⁸ As the northern passages become viable, the UK, the Netherlands, and Norway gain strategic weight as trade destinations – potentially at Mediterranean expense. (The Arctic angle probably deserves its own post, but it’s worth flagging here because it illustrates the same point from a different direction.)

Italy sees it coming – they’re counter-investing in Trieste as a rail gateway to Central Europe, trying to stay relevant in a world where ships might skip the Mediterranean entirely. The geography of Europe is pulling in two directions at once, and climate change is accelerating the split. That tension makes a unified EU bloc harder to achieve in ways that don’t show up in the usual federalist pitch.

Bits still need atoms

Here’s where I’ll bring it back to what I actually know something about: cloud software and AI.

The popular version of the AI story is that software is weightless, models run in the cloud, bits move at the speed of light. Geography fades into irrelevance. But the infrastructure underneath all of that is profoundly physical, and it’s getting more physical every year. Dylan Patel at SemiAnalysis estimates that the big four hyperscalers will deploy roughly 50 gigawatts of compute capacity this year, backed by around $600 billion in CapEx. Every one of those gigawatts needs power from a physical place. Google is buying energy companies. Hyperscalers are putting deposits down on turbines and locking in power purchasing agreements years in advance. The constraint on AI scaling is increasingly “where can you plug this in” – and that’s a geography question.

The supply chain is even more concentrated. ASML in the Netherlands makes roughly 70 EUV lithography machines per year – the tools you need to fabricate leading-edge AI chips. Patel calculates that you need about three and a half EUV tools per gigawatt of AI compute. That puts a hard ceiling on total global capacity: maybe 200 gigawatts by 2030, and that’s if everything goes right. TSMC in Taiwan fabricates the chips. Samsung and SK Hynix in South Korea make the high-bandwidth memory. The entire AI buildout runs through a handful of specific facilities in a handful of specific countries, several of which sit in the same part of the Pacific that’s become the other major theater of great power competition.

Every gigawatt of new compute deepens the dependency on specific places – where the power is, where the fabs are, where the lithography machines come from. AI only makes geography more important.

The ships transiting Hormuz under a dozen different flags aren’t waiting for a diplomatic resolution. They’re negotiating directly with geography. I suspect the next decade will be defined by who else figures that out.

Failure mode 1: the last-mile problem

Anyone who’s worked with coding agents knows this one — the agent gets me 90% of the way there, especially for UI work and well-specified features. The output compiles, the tests pass, the shape is right. But something’s off — a button three pixels too close to the edge, a sluggish loading state, an error message that reads like it was written by a robot (because it was).

The problem is that fit and finish is emergent. Once I see it, it’s obvious what to tweak. But I couldn’t have written that into the prompt ahead of time, because I didn’t know what “wrong” looked like until I was staring at it.

I used to try to capture everything in the initial prompt. Diminishing returns kicked in fast — the prompt got longer, the agent got more confused, and I spent more time specifying the work than it would have taken to just do the finishing touches myself.

So what I’ve started to do is treat the agent’s output as rough framing. Get it directionally correct and plan to finish by hand. The framing doesn’t need to be beautiful; it needs to be square. You can sand later.

In short: let the agent run, accept the 90%, and budget time for human finishing. Don’t over-specify. Don’t try to prompt your way to perfection.

Failure mode 2: the convincing-but-wrong plan

This one is scarier because the failure mode doesn’t rear its head until much later; sometimes it can be too late.

It happens when I’m not deeply familiar with a domain, or when the relevant context is hard to capture in a prompt. The agent produces something that looks right — coherent design, clean code, passing tests. A reasonable reviewer would approve it.

But the whole direction is wrong.

I ran into this recently. I was building a new form of feature flag targeting for PostHog — one that could target both user and group properties in the same flag. That meant creating a relationship that combined two distinct entities, persons and groups, so we could process properties from both sides when evaluating a flag. The agent helped me design the schema, build the queries, write the tests. Everything worked. The PR looked solid.

The problem: the agent’s design added new fields directly to the persons table, which would have increased load on the ingestion in a way that wasn’t tenable. The correct approach was a join table, but you couldn’t really see that from the code or the tests. You needed to understand the ingestion pipeline’s load profile, and I didn’t know it well enough to flag the issue before I’d already pushed the first PR (fortunately, we caught it in code review, and nothing bad happened).

But that’s the pattern of this type of failure mode: this time, the agent didn’t get me 90% of the way there. It got me 100% of the way to the wrong destination.

In these types of scenarios, you need slow down before you start. Identify the assumptions that would be catastrophic if wrong. Check those assumptions against someone (or something) that knows the domain. The cost of starting in the wrong direction dwarfs the cost of an extra hour on design.

What’s working for me

Before I spin up an agent, I ask myself: is this a “directional and finish” job, or a “deep-domain correctness” job? The answer informs how I spend my time.

For directional work, I sort tasks into a batch, kick off agents in parallel, and then — this is the part I had to learn the hard way — I finish them one at a time. Parallelism works for starting, not for finishing. A recent HBR study calls the alternative “brain fry” — juggling too many agent threads drives cognitive fatigue rather than reducing it. So I’ve turned off notifications from my LLM tools. Kick something off, come back when I’m ready. While an agent runs, I write down the follow-up questions I’ll need when it’s done. By the time it finishes, I’ve already thought through the next steps.

For deep-domain work, I front-load the thinking. I’m not prompting yet; I’m designing. I use Steelman, a tool I built for exactly this, to pressure-test my assumptions before I write a line of code. What are the load-bearing assumptions? What would make this approach catastrophically wrong? Where does my understanding have gaps? Only after that work do I involve the agent, and I watch it more carefully.

Either way, I accept that I won’t one-shot the result. I reserve undivided attention for the last 10% of each task. Coming back to something almost-done with fresh eyes is real momentum — easier to push over the finish line than to start from zero, and the fresh perspective catches things I’d have missed after hours of staring.

Not all LLM-assisted work fails the same way. Some fails at the edges and needs human polish. Some fails at the foundation and needs human judgment before it starts. Know which one you’re in, and plan accordingly.

This is the latest in an unplanned series about AI-assisted development. Previously: Spinning Plates, Racing towards Bethlehem, Spinning the Wheel, Contra Yang, et al, Announcing Steelman. Finally, I wanted to shout out Justin Duke’s LLM as advance team – it resonated deeply with me, and got me thinking about this post in the first place.

That experience of having your position challenged well and coming out the other side with something sharper is genuinely valuable. But it doesn’t scale. You can’t always find the right person to push back on your thinking at the right time. And most of us don’t seek out that kind of friction voluntarily. What we do instead, increasingly, is reach for an AI — and the AI mostly tells us we’re right. It validates, polishes, and helps us build on assumptions we never examined. We walk away feeling sharper when really we just feel more comfortable. I wanted something that would make me less comfortable with my position before I committed to it.

So I built Steelman.

What it does

Steelman is an adversarial reasoning tool. You state a position — “we should rewrite this service in Rust,” “single-payer healthcare is the only workable option,” “this essay’s thesis is airtight,”¹ whatever — and it puts your argument through a structured gauntlet.

Here’s how it works:

1. Claim decomposition. You write your position, and the AI breaks it down into empirical claims (things that are verifiably true or false) and value judgments (trade-offs and priorities). This is my favorite part tbh; seeing your argument decomposed into its load-bearing components is clarifying in a way that’s hard to describe until you’ve experienced it.

2. Three rounds of adversarial challenge. Three escalating personas target the weakest parts of your argument. Each round, you defend your position. The AI assesses whether your responses actually address the challenges and updates the status of each claim accordingly.

3. A Decision Record. At the end, you get a structured document: your refined position, the challenges you faced, which claims survived and which didn’t, and (crucially) falsification criteria. Conditions under which you’d change your mind.

The important design constraint: the AI never writes for you. It decomposes, mirrors, challenges, and structures, but every word in the final Decision Record is yours. I didn’t want a tool that generates opinions. I wanted one that pressure-tests them.

Why I built it

Honestly, I’m worried about what’s happened to decision-making in the age of AI. I’m as guilty of this as anyone — we’re all going full-bore into using these thinking machines, and mostly that’s great. But the default mode of every major AI chat app is sycophancy: you state a position, and the model validates it, maybe adds some caveats for plausibility, and helps you build on a premise it never questioned. It’s not that AI can’t help with decisions — it’s that the way we’re using it trains us to outsource the thinking rather than sharpen it. Vaughn Tan has a great piece on this — he argues that mainstream AI interfaces create a “seductive mirage” of talking to a meaningmaking entity, when really they’re just tools, and that we need to design AI experiences that clearly separate the subjective judgment work only humans can do from the non-meaningmaking work that machines are good at. That framing resonated with me. The right role for AI in decisions isn’t to make them for you — it’s to force you to make them better yourself. Steelman is my attempt at that: an AI tool that stays on its side of the line, structuring and challenging your reasoning while every decision about what matters and what to believe remains yours. The default mode shouldn’t be “yes, and.” It should be “okay, but have you considered.”

The stack

For the folks who care about this kind of thing: it’s a Next.js app using Claude (via the Vercel AI SDK) for the structured generation, Supabase for persistence, and Tailwind for the UI. I used Zod schemas to constrain the AI outputs into predictable structures — claim objects, challenge objects, assessment objects — which was essential for making the multi-round flow feel deterministic rather than vibes-based.

Try it out

Steelman is currently in closed beta. If you’re interested, you can sign up for the waitlist.

I’m especially curious to hear from people who make a lot of high-stakes decisions — engineering managers, staff+ engineers, architects, but also founders, policy folks, anyone who writes arguments for a living — about whether this maps to how they actually think through problems. The adversarial personas currently skew toward infrastructure and systems decisions, but Steelman works on any kind of argument, and I’d like to expand the persona set to cover more domains.

If you try it out and have thoughts, feel free to reach out to me via email. I’m iterating on this actively and feedback from real users is worth more than any amount of me arguing with myself about what to build next (though Steelman is useful for that too).

We’re all going to keep using AI to help us think. The question is whether it makes our thinking better or just makes us more confident. Steelman is a bet that the right AI tool for decisions is one that challenges you, not one that agrees with you.

I try to read these viral AI-displacement pieces with an open but critical eye; looking for what’s genuinely new versus what’s just repackaged anxiety, and trying to separate the claims that hold up under scrutiny from the ones that fall apart one you bring the temperature down a few degrees. I read Yang’s piece with that spirit in mind.

I think the basic point of Yang’s piece is right: white collar work is information processing, AI is good at information processing, and the stock market will reward companies that figure out how to do more with fewer people. I don’t think that’s a particularly original take, and people in my industry have been frothing about this (on Twitter, on LinkedIn) for literally years. Maybe it’s hitting mainstream politics finally.

But his speculations on timelines are pretty insane. “20-50% of 70 million white-collar jobs” gone in “the next several years,” millions displaced in 12-18 months – based on what? A conversation with one CEO? Talk about anecdotes laundered into predictions. And while influencers in more tech-native sphere aren’t innocent of making these types of claims too (e.g. AI 2027¹), the general vibe of this discourse feels like shock and awe over substance. Straight-line extrapolation dressed up as forecasting.

That was my biggest complaint the whole thing, really: the emotional engineering. The timbre. Yang frames someone in his family building a website in minutes as evidence that designers are obsolete, but anyone who ships software knows the demo is maybe 20% of the actual work. He cites mortgage delinquency charts as though AI is already cratering the housing market, but the actual NY Fed data tells a very different story². He names it “the Fuckening” because it “feels more visceral.” He’s made a career out of being the UBI politician; he links his book tour dates at the bottom. I don’t want to be uncharitable, but it’s worth noting that Yang’s financial incentives are perfectly aligned with maximizing alarm: the scarier the story, the more urgent the book feels, the more relevant the policy proposal becomes. That doesn’t make him wrong, but it does mean we should be especially careful about separating the signal from the sales pitch before engaging with the substance.

He also makes the classic non-tech mistake (intentional misdirection?) of framing AI demos like they’re real, load-bearing parts of software infrastructure. Yes, someone built a website in minutes. But the demo is maybe 20% (or less) of the actual work; the other 80% is edge cases, integration, compliance, error handling, all the stuff that makes things actually work in production. AI is still bad at that part, and I think there’s a meaningful reason it’s going to stay bad at it for a while that’s worth explaining.

The way these models improve is through evaluation: you need to be able to measure whether the model is getting better at a task in order to train it to be better at that task. For the demo stuff, evals are relatively straightforward. “Did the model produce working code that compiles and passes these test cases?” You can answer that programmatically. But most knowledge work isn’t like that. Most knowledge work is a bundle of tasks held together by judgment, context, and institutional memory, and the eval that would capture whether AI is doing the whole job well basically doesn’t exist.

This is Goodhart’s Law applied to AI capabilities: when a measure becomes a target, it ceases to be a good measure. AI benchmarks are saturating – SWE-bench scores went from 33% to over 70% in a single year³ – and labs are increasingly optimizing for the benchmarks rather than for the messy, situated work the benchmarks are supposed to proxy for. Oxford researchers reviewed 445 AI benchmarks and found that most don’t actually measure what they claim to measure, suffering from vague definitions and absent statistical validation.⁴ The model gets better at the test without necessarily getting better at the job.

And the hardest parts of knowledge work are precisely the parts that resist measurement. You can’t easily write an eval for “did this integration handle the edge case that only surfaces when the legacy billing system sends malformed dates on leap years” or “did this PR account for the implicit constraint that the payments team agreed to in a Slack thread six months ago.” These failures are vast yet specific, context-dependent, and often only recognizable as failures when a real user hits them in a real environment.

The common response here is that bigger context windows will solve this: just give the model the entire codebase, the Slack history, the docs, and let it figure it out. And it’s true that context windows are growing fast. But the bottleneck isn’t having the context; it’s knowing which context matters. An experienced engineer reading a PR doesn’t scan every Slack thread from the last six months; they know, from years of working in this system, that this thread about the payments team’s implicit constraint is relevant while ten thousand others aren’t. That’s not a retrieval problem. It’s a salience problem, one that depends on a mental model of how the system actually works, who made what tradeoffs and why, and what’s likely to break downstream. Throwing more context at a model can actually make this worse, not better, because you’re increasing the noise without improving the model’s ability to identify the signal.

In other words, this is a measurement problem, and measurement problems are slow to solve. You can’t easily evaluate whether a model correctly identified the relevant context, which means you can’t easily train it to get better at that task (Goodhart’s Law again, just at a different layer). I think the next generation of companies building vertical AI tooling will start to crack specific domains, but the generic “AI replaces knowledge worker” story requires solving eval problems that the entire field is still struggling with.

But beside all of that, even if the tech were ready tomorrow, have you ever watched a big company try to adopt any new software? Procurement cycles, compliance reviews, legacy system integration, middle managers fighting to keep headcount. Most Fortune 500s are still finishing cloud migrations they started a decade ago. These predictions always come in too hot. ATMs were supposed to kill bank tellers, spreadsheets were going to eliminate accountants, the internet was going to make offices obsolete by 2005. Every time, the tech changed jobs more than it killed them and new roles showed up that nobody predicted. Our economy might reward signals of efficiency, but in practice the underlying processes take forever.

This time COULD be different because AI is software not hardware, scales way faster, deploys way cheaper. I take that seriously. There’s already data suggesting the economics of software are shifting: SaaS gross margins among public companies have been declining, dropping from around 78% in 2020 to 72% by 2023 as product commoditization and competition compress pricing.⁵ The traditional seat-based SaaS model is under real pressure; if an AI agent can access a database and execute a workflow directly, why are you paying $70/seat/month for a dashboard that sits between a human and that same database? That’s a real structural shift worth watching. But “the economics are shifting” and “definitely catastrophic in 18 months” are very different claims.

Software engineering is probably the industry where this conversation is loudest and most specific, which makes sense: it’s the one closest to the technology itself. It’s also the one I know best, so let me talk about what I’m seeing in software engineering (I’ve been writing about this for a minute).

Specifically, I want to address this question: is software engineering in general just going up one abstraction layer? There’s a version of this argument that sounds clean and reassuring. We went from assembly to C to Python to “just tell the AI what to build,” and every time the previous layer’s practitioners were fine because they moved up. And there’s something to that. Gergely Orosz at The Pragmatic Engineer wrote about how even the creator of Claude Code didn’t open an IDE for an entire month; all his committed code was AI-written.⁶ Senior engineers are already spending less time typing and more time shaping systems (defining specs, reviewing output, making architectural decisions). AI just pushes that trend to its logical conclusion.

But I think the abstraction-layer framing obscures something important about what’s actually valuable in software engineering right now. It’s not “knowing how to code” in the syntactic sense. AI can write a for loop. It can scaffold a React app. It can even do a pretty good first pass at a complex feature if you give it enough context. What it can’t do well is hold the full mental model of a production system in its head: the implicit constraints, the historical decisions, the understanding of why this particular service communicates with that particular database in this particular way, and what breaks if you change it. The Stanford study I’ll get to in a minute found something relevant here: employment for developers aged 22-25 dropped nearly 20% from its late 2022 peak, but employment for workers over 30 in the same AI-exposed roles actually grew 6-12%.⁷ The market is telling us something. The value isn’t in writing code; it’s in the tacit knowledge that comes from years of shipping code in messy real-world environments. AI is great at the codified stuff. The un-codified stuff is where humans still dominate, and it’s where the value is concentrating.

There’s a related point here that I think gets lost in the discourse: not all software engineering is created equal, and AI is going to hit different parts of the industry very differently. I work at a product-led company where engineers are expected to talk to customers, make product decisions, think about activation funnels, and ship features that move business metrics. That kind of work is ambiguous, cross-functional, and deeply contextual. It’s hard to automate because the “right answer” isn’t well-defined and changes constantly based on user behavior and market conditions.

Compare that to programming at e.g. a large insurance company, where software is already more of a commodity – maintaining internal CRUD apps, building reports against legacy databases, implementing well-specified business logic. That work has been getting squeezed for years, first by offshoring, then by low-code tools, now by AI. Or think about the kind of programming that happens at a consulting firm, where you’re building roughly similar applications for different clients over and over. AI eats that for breakfast because the patterns are repetitive and the specifications are relatively concrete.

This isn’t a new divide. The frontier of software engineering has always been different from the commodity middle. What’s changing is that AI is dramatically widening that gap. If your work is primarily translating well-understood requirements into code, you’re in trouble regardless of Yang’s timeline, because that’s exactly what AI does best⁸. If your work involves navigating ambiguity, making judgment calls with incomplete information, and understanding complex sociotechnical systems, you’re probably fine for a long time. Arguably more valuable than ever, because AI is making the easy parts of your job faster while the hard parts remain stubbornly human.

Since we’re talking about data, let’s actually look at some, because the picture is more nuanced than Yang lets on (though it’s not exactly rosy either).

Morgan Stanley surveyed 935 executives across five sectors and found an average 4% net decline in headcount over 12 months, alongside an 11.5% productivity increase.⁹ Notably, U.S. companies actually reported a 2% net gain in jobs; the biggest pain was in the UK at 8% net loss, and concentrated among larger firms. Early-career positions were disproportionately affected, which tracks.

The Stanford Digital Economy Lab study is probably the most rigorous thing out there right now.⁷ Using ADP payroll data covering millions of workers, they found a 13% relative decline in employment for 22-25 year olds in the most AI-exposed occupations since late 2022. For software developers in that age range specifically, the drop was nearly 20% from peak. But (and this is the part Yang would leave out) they also found that employment for older workers in the same roles grew 6-12%, and that jobs where AI augments work rather than automates it haven’t seen similar declines. The adjustment is real, but it’s not uniform, and the “automation vs. augmentation” distinction matters enormously for predicting where this goes.

Challenger, Gray & Christmas tracked 696,000 job cuts in the first five months of 2025, an 80% year-over-year jump.¹⁰ But they attribute this to a cocktail of tariffs, funding cuts, consumer spending shifts, and AI, not AI alone. The World Economic Forum’s 2025 report estimated 92 million jobs displaced by 2030 but 170 million new roles created, for a net gain.¹¹ And a Harvard Business School professor studying this put it well: AI exposure overlaps with about 35% of tasks visible in labor market data, but the history of predicting employment effects from technology is “extraordinarily hard,” and the radiologists we were told to stop training in 2017 are busier than ever.¹²

What does all this tell us? The displacement is real, it’s measurable, and it’s hitting early-career workers first and hardest. But it’s also a 4% net headcount decline and a 13% relative employment drop in specific demographics, not the 20-50% apocalypse Yang is selling. The data supports “meaningful structural change that’s already underway and will accelerate” much more than it supports “the Fuckening.”

Plus like a lot of what he’s describing is also just an acceleration of stuff that’s been happening for years. Knowledge work offshoring, junior roles getting squeezed, bad grad employment numbers. AI is pouring gasoline on existing fires not starting new ones. There is something to this, though: economic transitions hurt the people who built their lives around stability. People who followed the script (school, useful degree, knowledge work career) are going to be disrupted. But I also think that’s just capitalism? Things change! We drive towards efficiency! I don’t think the mindset should ever be “learn a thing once and then coast on it”; the whole point is to be constantly examining yourself, updating your priors, and understanding that what worked in the past might not work in the future.

I want to be honest about the limits of that framing, though. “Stay curious and keep adapting” is easy advice for me to give. I’m in my thirties, I work at the frontier of this stuff, and my entire career has been built around the assumption that the tools and the landscape will keep changing. That’s a very different position than someone who’s 50, spent twenty years building expertise in a domain that’s about to get compressed, has a mortgage and kids in college, and is now being told to “upskill.” Yang is right that the social contract of “study hard, get a degree, get a stable career” is under real pressure, and I don’t think “just adapt” is a sufficient answer for everyone. The question of what we actually do for the people who can’t easily pivot is a real one, and I don’t have a clean answer for it. Yang’s answer is UBI, which is at least a concrete proposal, even if the way he’s selling it feels more like a campaign pitch than a policy discussion.

Maybe I’m coming across as too emotional too. I’ve read a lot of these doomsday scenario-type pieces and they always feel like they’re trying to manipulate me rather than inform me. I don’t doubt that things are changing rapidly, maybe faster than ever, and I think that I’m lucky to be in a frontier industry where this idea of adapting and changing and modifying my workflow is endemic. Frankly, the one true thing about software engineering has always been that it evolves and it rewards those who are intellectually open-minded and good at upskilling.

I’ve stopped trying to find balance. I’m all in.

Over the holidays I refined my Claude Code setup, went full-bore into multi-worktree setups with Conductor, and spent a lot of time iterating on my work process. On top of that, the models got better. The tooling caught up. And somewhere in there, I personally crossed a threshold. Now most of my work happens through agents. I’m living in Claude Code & Conductor, spinning up sessions, watching them churn, merging the output. The 80/20 flip that Karpathy described happened to me too: 80% agent coding, 20% edits and touchups.¹

It feels incredible. It feels like cheating. It feels like gambling.

The casino

There’s a moment after you send a prompt where you’re just… waiting. The agent is running. You can see it thinking, reading files, making decisions. And there’s this little hit of anticipation: what’s it going to do? It’s the same dopamine loop as pulling a slot machine lever. Low effort, variable reward, endlessly repeatable.

Someone on Hacker News called it “doom tabbing”: the AI is already running, the bar to seeing what it does next is so low that you just… watch.² A coworker described the opposite problem: you can’t just sit there, so you open Slack or try to multitask during the dead time. Either way you lose — watching keeps you in the dopamine loop, switching fragments your focus. Fifty times a day, both add up to a strange kind of fatigue. Pull the lever, spin the wheel, see what happens. The reward gets front-loaded; the difficult part – understanding what you built, debugging it six months later – gets pushed further out in time.

Ryan Broderick went even darker, calling generative AI an “edging machine”: it charges you for the thrill of feeling like you’re building something while caring more about the monetizable loop of engagement than the finished product.³ I don’t cosign his full doom take, but the framing stuck with me. There is something seductive about the loop. It simulates progress. It feels like making.

And then there’s “comprehension debt” – the tendency for the code in your codebase to become less and less understood over time because the AI one-shotted it and you just moved on.⁴ People counter that AI actually helps you learn — you can ask it to explain things, build mental models. I do this too. But when I ask for an explanation and then let it do the implementation, the understanding doesn’t stick the way it would if I’d written the code myself. It feels like learning in the moment. Whether it compounds into something durable, I’m not sure.

The casino is fun. When you’re on a heater, it really feels like you’re doing something. But the casino doesn’t care whether you understand what you built.

The fun

And yet — work has never felt this fun.

I’ve always believed that energy management matters more than time management. If the work drains you, it doesn’t matter how many hours you have. And these tools have changed the energy equation. The drudgery is gone. The copying and pasting of compiler warnings, the boilerplate, the fill-in-the-blanks tedium – I just don’t do that anymore. What’s left is the creative part: deciding what to build, figuring out the shape of the solution, reviewing whether the output is good.

Karpathy, my coworkers, all the engineers I’ve talked to who use these tools – they’ve all noticed the same thing. Programming feels more fun now because the fill-in-the-blanks drudgery is removed and what remains is the creative part.

I also feel less stuck. When I hit a wall, I don’t have to grind through it alone. I can throw the problem at Claude, watch it try things, learn from what it attempts. There’s almost always a way to make some positive progress. That changes the emotional texture of the day. Less frustration, more momentum.

And the tenacity thing is real. Watching an agent relentlessly work at something – never tired, never demoralized, just trying approach after approach – is genuinely inspiring. I’ve seen Claude struggle with a problem for thirty minutes and then crack it. That stamina was always a bottleneck for me. Now it’s not.

How I’m adapting

I don’t have a clean answer to the “is this cheating?” question. But I have a working theory about how to stay a craftsman in the casino.

The shift I’ve made is this: I spend more time defining success criteria and less time doing the mechanical work of achieving them. Karpathy’s framing helped here. “Don’t tell it what to do, give it success criteria and watch it go.” The leverage comes from being declarative instead of imperative.

Boris Cherny, who created Claude Code, recently shared how his team uses the tool: start every complex task in plan mode, and pour your energy into the plan so Claude can one-shot the implementation.⁵ One person on his team has one Claude write the plan, then spins up a second Claude to review it as a staff engineer. Another says the moment something goes sideways, they switch back to plan mode and re-plan — don’t keep pushing. The pattern is the same — front-load the thinking, let the machine handle the doing.

My days have started to split into two modes. There’s contemplative time — defining goals, thinking through edge cases, building the reward function. That part is slow and focused. Then there’s execution time — spinning up agents, running them in parallel, triaging output. That part is fast and frenetic, caffeine-fueled, multi-stream.

What still matters

The contemplative work is what makes the execution productive instead of just fun. Without it, I’m just pulling levers and hoping.

For frontend work, this means developing strong taste. Can I look at the output and feel whether it’s right? Does the UI make sense? Are the interactions smooth? I’ve been spending more time on what Jim Nielsen calls “sanding the UI” – the patient, iterative work of smoothing rough edges until something feels right.⁶ The agent can generate a component, but I’m the one who has to sand it.

For backend work, it means building robust test harnesses. Types that encode invariants. Property-based testing has been great for this – instead of writing specific test cases, I describe properties the code should always satisfy, and the framework generates hundreds of edge cases to throw at it. If the tests pass and the invariants hold, the code is probably fine. The work shifts from writing the code to specifying what correct code looks like. I build the acceptance criteria first – the tests, the types, the “what does correct look like?” – and only then let the agent loose against it.

And domain expertise matters more, not less. There’s a popular narrative that AI helps you upskill quickly in unfamiliar domains — and that’s true when you’re learning. But for this modality, for being genuinely productive with these tools, your existing expertise is what makes it work. The better I understand the problem space, the earlier I can catch the agent going down a wrong path. When I’m working in code I know well, I can interrupt a bad approach in the first few seconds. When I’m in unfamiliar territory, I might not realize something’s off until it’s been spinning for ten minutes. The models still make mistakes – subtle conceptual errors that a hasty junior dev might make, wrong assumptions they run with instead of checking.⁷ You have to watch them like a hawk. It ends up looking like pattern-matching on failure modes before they compound.

These are the things I’m holding onto – taste, rigor, expertise. The parts that feel like they might still be craft. Whether they’re enough to keep it that way, I’m not sure.

The question I can’t answer

Derek Thompson wrote a piece called “The Monks in the Casino” about young men who’ve retreated from social risk into dopamine loops: gambling, speculation, variable rewards without vulnerability.⁸ The casino reshapes what feels normal. What starts as entertainment becomes the default texture of experience.

I keep thinking about how that logic spreads. Engineering used to feel like one of the more contemplative corners of work – long stretches of focused thought, deep understanding as the goal. Now the casino has arrived here too. The tools are incredible, and they’re also slot machines. The dopamine loop is built into the workflow. And I’m not sure how vigilant I need to be, or whether vigilance is even the right frame.

The question I keep asking myself is whether this is still craft.

Craft implies understanding. It implies that the maker could explain every decision, could reproduce the work, could teach someone else how to do it. When I ship something Claude mostly wrote, can I say that? Sometimes yes. Sometimes I’m not sure.

There’s a comforting story I could tell myself here — that craft is evolving, that the new skill is knowing what to ask for and how to evaluate the output, that judgment is the new execution. Maybe that’s true. But I notice how convenient it is. It’s exactly the kind of thing you’d say to avoid sitting with the harder question.

What if the answer is actually no? What if I’m slowly trading away the thing that made me good at this — the deep, hard-won understanding — for speed and fun? What if the speed is the bribe?

Recent research suggests this isn’t just paranoia. A randomized experiment from Anthropic found that AI assistance impaired developers’ conceptual understanding, code reading, and debugging abilities – without even delivering significant efficiency gains on average.⁹ Only the interaction patterns that involved genuine cognitive engagement preserved learning outcomes. Their conclusion: “AI-enhanced productivity is not a shortcut to competence.”

But knowing that doesn’t tell me what to do. I don’t want to stop using these tools – they’re too good, and the work is too fun. A friend texted me yesterday: “What a time to be alive and programming, eh?” It really is. I’m locked in at the casino, the games are as good as they’ve ever been, and I’m watching myself play more than ever. The best I can do is pay attention.

Thanks to Juraj Majerik for reading a draft of this and for feedback. This is the third post in an unplanned series about AI-assisted development. Previously: Spinning Plates, Racing Towards Bethlehem.

Part One: The Excellent

The thing I keep coming back to is the combination of autonomy, opportunity, and impact. These three words get thrown around a lot in job postings, but at PostHog they actually mean something. I’ve worked on genuinely interesting problems that matter to the business, and I’ve been given real freedom in how I solve them. Most days I wake up excited about the work. That’s rare, and I don’t take it for granted.

The feature flags team sits at an interesting intersection: we’re responsible for infrastructure that needs to be fast and reliable (we serve billions of flag evaluations), but we’re also building product that developers interact with directly. I’ve gotten to do both. I rewrote our evaluation service in Rust, shaving latency and improving reliability. I’ve also shipped product features, worked on SDK improvements, and thought deeply about developer experience. The breadth is energizing.

The learning has been extraordinary. I came to PostHog wanting to write Rust professionally. At my previous startup, I’d read Luca Palmieri’s Zero to Production in Rust and knew the language was a good fit for the performance-critical work I wanted to do, but the existing tech stack and hiring concerns made it impractical. At PostHog, I finally got the chance. I’ve now built and shipped production Rust services handling real scale. I’ve learned how to operate distributed systems, how to debug cascading failures, how to think about reliability as a discipline rather than an afterthought. All of this through the lens of actual work, not side projects or tutorials.

And then there are the people. PostHog has assembled an extraordinary group of engineers from around the world. The talent density is intimidating in the best way; I’m constantly learning from my teammates. The company also invests heavily in bringing people together in person. In my eighteen months, I’ve done team meetups and offsites in Toronto, New York, Amsterdam, and San Francisco, plus company-wide offsites in Mykonos and Mexico. I have another one coming up in London. These trips aren’t just perks; they’re how a distributed team builds the trust and rapport that makes async collaboration actually work¹.

Part Two: The Challenges

I want to be honest about this part, because I think the hard stuff is where the real learning happens.

The biggest challenge was rebuilding our feature flags evaluation engine while it was running in production. You can’t feature flag the feature flag service. Every change ships to everyone, immediately. This constraint forced me to think carefully about testing, validation, and rollout strategies. I built extensive test harnesses, shadow testing infrastructure, and tooling to validate behavior before shipping. It was some of the most disciplined engineering work I’ve done.

The rewrite itself went well. What came after was harder.

In late 2025, we had a series of incidents. Four outages in October alone, totaling over fourteen hours of customer impact. The technical details are in our post-mortems, but the short version is: we discovered failure modes in the new service that we hadn’t anticipated. CPU resource sizing issues caused cascading failures. Connection pools exhausted under load. Retry logic amplified problems instead of containing them. Each incident taught us something, but the lessons came at a cost.

Those weeks were some of the hardest of my career. I wasn’t sleeping well. The feeling of letting customers down was awful; these are developers who depend on our service to ship their own products, and we were failing them. I took some time off. I seriously considered whether I wanted to keep doing this kind of work.

What got me through was the team and the culture. Folks from the leadership team reached out to me directly to check in and offer support – I typically don’t hear much from them, but they all reached out when I needed it, and that affected me more than I expected it would. PostHog practices blameless post-mortems, and they really mean it. After each incident, the question was never “who screwed up?” but “what allowed this to happen?” My coworker Phil Haack wrote about this in his own reflection on his first year. That approach made it possible to actually learn from the failures instead of just feeling bad about them.

The incidents also forced us to rethink our team structure. Before, we had one feature flags team with a sprawling scope: SDKs, product UI, platform infrastructure. After, we split into two focused teams. Phil now leads the Flags Platform team, laser-focused on performance, reliability, and architecture. I lead the Feature Flags product team, focused on the configuration UI, cohorts, early access features, and SDKs. The split lets each team go deep on their domain without feeling pulled in competing directions.

Looking back, I think the hardest part wasn’t the technical debugging. It was sitting with the uncertainty while we were still figuring things out. There’s a specific kind of dread that comes from knowing something is broken, knowing people are affected, and not yet knowing why. Learning to function in that state, to keep investigating methodically instead of panicking, was its own kind of growth.

Part Three: What’s Next

For my first eighteen months, I was hired as a product engineer but spent most of my time on platform work. Rust, performance, reliability, infrastructure. I loved it, and I’m proud of what we built. But I’m ready for a change.

I’m shifting my focus toward product engineering. I want to get closer to our users and think more directly about business impact. Feature flags is already a sticky product, which is solid for something that isn’t a daily-use feature. But our activation rate is lower than I’d like. There’s a gap between people who express interest during onboarding and people who actually end up using the product. That gap feels like an opportunity.

I want to understand why people bounce. I want to make the product so good that trying it feels effortless. I want PostHog to be the obvious choice for teams who care about feature flags and want to understand what those flags actually do.

This is different work than writing Rust services. It’s more ambiguous, more user-facing, more tied to metrics I can’t fully control. I’m excited to learn how to be good at it.

If any of this resonates, we’re hiring.

Phil’s Flags Platform team is looking for backend engineers who want to tackle hard problems at scale: Rust, distributed systems, reliability engineering. If you want to work on infrastructure that serves billions of requests and learn from some genuinely excellent engineers, this is the role.

My Feature Flags product team is hiring product engineers who care about developer experience and want to ship features that users actually love. If you’re energized by the intersection of product thinking and technical depth, come work with us.

The old design was fine. It worked, it loaded fast, it was readable. But it had the classic “developer blog” energy: purely functional, zero personality. I wanted something that felt more like a design studio homepage and less like a default Jekyll theme with the serial numbers filed off.

What I was going for

I spend a lot of time looking at personal sites. The ones I keep coming back to share a few traits:

• Monospace as a design choice. The best personal sites I’ve seen use monospace because it creates a specific mood: technical, deliberate, slightly editorial. I wanted that same energy; Berkeley Mono in particular has enough personality to carry body text while still feeling sharp at small sizes for nav labels and metadata.

• Strong typographic hierarchy. Big bold headings, tight letter-spacing, uppercase labels for navigation and section headers. The kind of thing where you can squint at the page and still understand its structure. Type size, weight, and spacing do the heavy lifting; color and decoration stay minimal.

• Structural borders. I like sites where the borders do real work: separating navigation from content, delineating sidebar sections, anchoring lists. Intentional 2px lines that say “this is a boundary.” The nav and footer get strong borders; everything else stays subtle.

• Light and dark, automatically. I’ve had dark mode on this site since 2020, but the old palette was an afterthought. This time both modes are first-class citizens via prefers-color-scheme, with warm off-whites and deep charcoals.

• Sidebars that earn their space. Each sidebar section is a discrete card with its own purpose: stats, links, subscribe options, fun facts. If a page has a sidebar, the sidebar has a job.

The font

I switched everything to Berkeley Mono. I’ve been using it in my editor for a while and I think it’s the best monospace font available right now. It has enough character to carry long-form prose and it looks great at the small sizes I use for navigation and section labels.

Self-hosting was straightforward: four @font-face declarations pointing at .otf files, with font-display: swap to avoid FOUT. The fallback stack goes TX-02, JetBrains Mono, SF Mono, Fira Code, Cascadia Code, so it degrades gracefully.

The layout

The grid is simple: a main content area and a 260px sidebar on desktop, collapsing to a single column on mobile. CSS Grid makes this trivially easy:

.page-content.with-sidebar {
  grid-template-columns: 1fr var(--sidebar-width);
}

Every page that benefits from a sidebar gets one. The writing index has stats and subscribe links. Individual posts have an info table with publish date, word count, and slug. The homepage has social links, feeds, and fun facts. Pages like speaking and projects use the full width.

The details

A few smaller decisions that I think matter:

Navigation is uppercase, bold, and letterspaced. More design studio masthead than list of links. The nav and footer both use 2px borders against the strong color, so the page has clear top and bottom anchors.

Section headers (“Currently”, “Previously”, “Interests” on the homepage) are display: inline-block with a 2px underline. This gives them visual weight while keeping them compact.

The post list has a bold top border and per-post word counts inline with the date. I added aggregate word count stats to the sidebar too; partly because I’m curious, partly because it’s the kind of thing I like seeing on other people’s sites.

Sidebar sections are bordered cards with uppercase headings and a subtle bottom border inside each card. Small thing, but it makes the sidebar feel intentional.

Content changes

While I was in there, I made some structural changes too:

• Renamed “Blog” to “Writing” since that’s more accurate and I like how it reads in the nav.
• Renamed “Talks” to “Speaking” for the same reason.
• Created a Digest page by pulling the reading list out of the Media page and giving it its own home. It felt buried before.
• Added a Uses page because I’ve always liked /uses pages on other developers’ sites (h/t to UsesThis.com).
• Added word counts to the writing index, the stats sidebar, and each post’s info box.

The tools

This is still a Jekyll site hosted on GitHub Pages. One CSS file, a few Liquid templates, some HTML. The whole design system lives in CSS custom properties:

:root {
  --bg: #fafaf8;
  --text: #1a1a2e;
  --accent: #3d5af1;
  --border: #d0d0d0;
  --border-strong: #1a1a2e;
}

Dark mode is a prefers-color-scheme: dark media query that swaps those values. Your OS decides.

The spirit here, as it’s been since I made the first commit to this site, is basically motherfuckingwebsite.com: no JS, no build step, no dependencies beyond what a browser already gives you. HTML, CSS, and content. The whole site loads fast, works everywhere, and I can understand every line of it.

What I’m trying to keep is the state it put me in: leaving the house at any opportunity, walking places by default, keeping a running backlog of things to try, and treating any day like it might be worth doing something.

I’ve lived in Seattle for more than 8 years and I still love it here — the nature access is world class, and I find the city beautiful. But after living here for so long (the longest I’ve ever lived somewhere since before I went to college), I’ve noticed that it’s easy to settle into a routine and stop exploring. So, I’m writing this down partly so I don’t spend the winter wishing I was still in New York, and partly to see if I can make these behaviors stick.

Walking as continuity

In New York, walking is how the day moves. And because you’re on foot, you experience the space between things.

That matters more than I expected. Walking makes time feel contiguous. You get little hits of texture: a new storefront, a poster for a show, a line outside a place you didn’t know existed, weather that forces you to actually notice the season.

In Seattle it’s too easy to turn life into teleportation. Efficient, private, slightly dead.

So I’m trying to walk more as a way to keep the city “on.” If it’s plausibly walkable, I want my default to be: fine, I’ll walk.

Passive transit is goated

In New York, the whole city felt 30 minutes away. I know it’s the most tired take of all time, but the ubiquity and consistency of the subway was perpetually delightful — I’d show up basically anywhere, ride, arrive. I could read, write, play Balatro, or just stare into the middle distance and let my brain idle. That’s time you don’t get back when you’re driving.

And it wasn’t just commuting. Going out at night, meeting someone across town, running errands — it was all the same. You just… go. No parking, no route decisions, no low-level vigilance. I didn’t realize how much I liked that until I had it constantly.

Seattle isn’t that. Link is expanding and buses run, but coverage is spotty, frequency varies, and for most trips driving is still faster. I’m lucky — I live on a bus line that goes straight to my office and my gym, so I’ve started taking it for both. Some days the app lies and I just drive. But when it works, I show up less scattered, and I’ve already had 20 minutes to read or do nothing. That’s worth protecting.

Keep a running list of spots to hit

This was the big one, and it’s something I know my friends have done for years and I’ve balked for a while out of (mostly) laziness. We all have to learn our lessons in our own time.

But yeah, in New York, I kept a list of places I wanted to go (and I made a list of places I did go): coffee shops, bars, restaurants, museums, neighborhoods, specific dishes. It was a backlog, and it had the obvious effect of making me more excited to go out.

It turned “what should we do tonight?” from an empty question into a menu. I wasn’t inventing a plan from scratch when I was tired; I was selecting something I’d already pre-approved when I had energy.

Back in Seattle, I realized how easy it is to fall into the same loop unless I stay current on what’s new. New stuff opens quietly. Scenes shift. Neighborhoods evolve. If I don’t capture that anywhere, I default to the same places because they’re good and easy and already in my head.

So now I keep a “Seattle backlog” on purpose:

• Restaurants and bars I’ve heard about
• Coffee shops and bakeries
• Bookstores, galleries, small venues
• Parks, viewpoints, hiking spots
• Single specific items worth leaving the house for

And I treat it like an object I maintain casually. Friend recommends a place? List. I walk past something interesting? List. I see a poster? List.

Bring the energy

I’ve never been one to shy away from going out, and I’ve been accused of being “high-energy” by friends and foes alike. But even I’ve succumbed to the Seattle-specific trap (which is especially bad in winter): waiting to feel like going out.

Seattle is quieter, and the city’s energy doesn’t exactly do you favors here. In New York, it’s easy to get swept along — there’s always something happening, and it feels like the default setting is “sure, why not.” In Seattle, you can blink and it’s 9pm and you’re still on the couch, perfectly comfortable (and the bars close in 2 hours anyway so what’s the point).

Rain also makes that feel rational. “Cozy” becomes ideology. And sometimes staying in is correct. But sometimes it’s just inertia that’s learned how to speak softly.

The thing is, the biggest hurdle isn’t the weather or the city — it’s me. If I actually decide to go out, there are always places in Seattle that are a good time. Despite my flippancy, there’s always a bar with a vibe, a restaurant that hits, a show somewhere, a friend who’s down.

One thing I liked about myself in New York is that I didn’t feel that complacency as much. I’d just decide the night was happening. Pick a place. Go. I’m trying to keep that: put on real clothes, make the plan, leave the house.

You ain’t gonna need it

Our place in New York was small and tasteful, but lacking in many of the creature comforts of home. By the end it felt more like a feature than a bug though, turns out living with fewer things exposed yet another obvious truth: extra stuff is mostly maintenance.

More clothes, more objects, more “just in case” adds up. Physical clutter; attention debt.

I was surprised to notice this because my Seattle setup felt perfect to me before I left. My wife and I love our place. It’s beautiful, it’s great for entertaining, the view is good. My eight sleep mattress has ruined all other beds for me. But like anything else, stuff accumulates, and it’s weirdly hard to let things go once they’ve been added to the fold. Living with less helped me notice the accumulation.

I want my place to feel light enough that it doesn’t pre-tire me, and nice enough that I’m not collecting stuff just to compensate for anything.

The point of all this

I’m making a bet that Seattle already has a lot of the raw material for me to build a daily lifestyle similar to what I had in New York. The only real question is whether I keep choosing it, and if it sticks. I haven’t abandoned the thought of moving to New York altogether.

“If your individual velocity has increased, how are you handling the other bottlenecks in the system — code review being an obvious one?”

Around the same time, I’d been revisiting Ordep’s Writing Code was Never the Bottleneck essay, which opens with a line that feels like a koan:

“Writing lines of code was never the bottleneck in software engineering.
The actual bottlenecks were, and still are, code reviews, knowledge transfer, testing, debugging, and the human overhead of coordination.”

Right. Exactly. That’s been the shape of the job for decades. When writing becomes nearly free, all the work you can’t automate steps out of the shadows.

And yet something has shifted for me. Not the bottlenecks themselves, but the work wrapped around them. That’s what this post is trying to unpack.

The bottlenecks are still the bottlenecks

Ordep’s core point is, in my experience, correct: reviewing is hard, debugging is hard, understanding intent is hard, maintaining shared mental models is hard, and making judgment calls is hard. His second point lands even harder:

“The marginal cost of adding new software is approaching zero.
But the price of understanding, testing, and trusting that code? Higher than ever.”

I feel this. I can ship more working code in an afternoon than I used to ship in a week, but verifying it, reasoning about its behavior, and protecting the shape of the system hasn’t gotten cheaper. If anything, it has expanded the amount of code I’m implicitly responsible for.

LLMs as connective tissue, not output machines

That said, the work around these bottlenecks has changed. The tools are not solving the hard parts, but they make it easier to reach them. Over the last six months, I have been surprised by how helpful LLM-based tools are as navigational aids rather than generators. They each fill a different gap. Greptile gives me a second look at my own PRs and catches high-level issues that are easy to miss once you have been staring at a diff for too long. 0github is now my starting point when I review someone else’s changes; its heat-map diff and “risk” slider point me to the sections that deserve real attention. And I have been leveraging Claude Code as a way to understand new parts of the codebase. When I explore a new subsystem, I will ask it to outline the key files and invariants so I can go straight to the important pieces instead of wandering through the directory tree.

The common thread in all of these tools is simple: they cut down the time it takes to gather context. I spend less energy on the overhead and more on the actual reasoning. They do not replace the difficult parts, but they make it easier to get to them. That was the part I did not expect — the bottlenecks stayed where they were, but the road leading to them became much smoother.

Naming the tension

The smoother road comes with its own tradeoffs, though. After I posted last time, my dad wrote me a long note that helped me put words to the thing I had been circling. He is a professor of evolutionary biology, and his message was very him: part philosophy, part evolutionary metaphor. He sent a series of questions and observations:

“Where is the balance?
Is there a shifting baseline?
Drift is easy; drift erodes capacity.
You’re describing a moving human–machine interface.
Being intentional about what you want to learn is a daily practice.
This is an adaptationist mindset.”

That last line made the whole thing click. If the environment is shifting under my feet, then my habits have to adapt with it. The tools make it easier to reach the real work, but they also make it easier to skip the parts that build intuition. The moment I let them shortcut the reasoning, the learning curve flattens. Drift is quiet at first, then it accelerates, and once it starts, it is hard to undo.

What responsible use looks like for me

All of this raised a practical question for me: if the road to the bottlenecks is smoother, how do I make sure I am still doing the part of the work that actually builds skill? That is where I started drawing a line for myself. I use LLMs to accelerate navigation, mapping, summarization, risk-surfacing, tracing, onboarding, interpreting test failures, and spotting suspicious patterns. In other words, anything that helps me figure out where to look and what deserves attention. I avoid using them to speed up correctness, design, invariants, architecture, root-cause debugging, or tradeoff decisions. Those parts only improve through repetition and deliberate attention. I am not chasing purity here; I just do not want to weaken the muscles that matter. If a tool helps shrink the search space, I am happy to use it. If it tempts me to ignore the search space entirely, that is where I step back.

The way has never felt faster

I agree with Ordep: writing code was never the bottleneck, and it still isn’t. Understanding, reviewing, coordinating, and verifying remain the real constraints, and they still require a human brain fully switched on. What feels new is that LLMs finally help with the work around those constraints, the parsing and mapping and sense-making that used to take most of my energy. They make the bottleneck easier to see and easier to reach, even though they don’t change what happens once I’m there. They don’t lower the cost of judgment, but they lower the cost of arriving at the moment where judgment is required. If I can keep adaptation ahead of drift, it improves more than my output; it improves the way I approach problems. The constraints have not moved, but I get to them sooner and with less wandering. The pace has changed. We are not slouching toward the next bottleneck; we are moving straight into it, and I have to decide whether I am meeting that speed on purpose or just being carried along.