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.

I have a feeling this isn’t just a “me” thing. Companies and tech influencers are loudly pushing AI-first workflows, YouTube talks and blog posts explain “how I use LLMs” as if that’s now a core part of your stack, and experienced devs keep reporting the same weird combo: they feel faster while also suspecting they’re learning less.¹

Even as I write this, I have Claude Code spun up in another terminal pane, churning out unit tests for a chunk of code that I mostly didn’t write but that’s probably 95% of the way to production-ready.

It’s incredible.

I genuinely don’t know how I feel about it.

TL;DR

• LLMs have transformed my work into lots of shallow touches on many tasks instead of long focus sessions on a few things.
• I’m shipping more than ever, but I retain less and feel less ownership.
• I now spend as much time optimizing my workflow as I do thinking about the code itself, and the ROI is objectively good and subjectively cursed.
• My deep-focus muscle is weaker; hard problems feel harder.
• I’m increasingly inspired by Andrej Karpathy’s “tab complete first, type it out to learn” approach and Dan Abramov’s worries about people not wanting to learn at all, and I’m trying to decide how far I want to lean into each side.

My new model of programming

My old “good day” looked like this:

1. load one tricky problem into my head,
2. struggle with it,
3. get stuck,
4. have a small breakthrough,
5. ship a PR.

The feedback loop was long but satisfying: effort in, understanding out. Most of the joy lived in steps 2–4; that’s where I actually learned things. The throughput wasn’t insane, but at least I felt like I owned what I shipped.

Now, a typical “good” day looks more like:

• write a short-to-medium-length prompt about a bug or feature;
• let Claude Code write a first pass over 3–4 files;
• skim the output, fix the obviously wrong bits, add logging, run tests;
• repeat that loop across a few tasks, plus reviews, plus a doc or two.

By the end of the day, my GitHub looks absolutely cracked. Lots of green. On a good day I can crank out multiple features that are well tested and work as soon as they hit production.

Under the hood, though, the feedback loop has been re-sized:

1. define the shape of what I want,
2. write a prompt and hand it context,
3. triage whatever comes back,
4. iterate until it compiles / passes / looks fine.

There’s still skill there—prompt design, taste, knowing what “smells wrong” — but the locus of difficulty moves. It’s less “can I solve this?” and more “can I supervise this?” The reward structure changes too: less “wow, I learned something deep” and more “nice, another plate spun and didn’t fall.” Still satisfying, just in a more managerial way.

And when the model drops a solution fully formed, part of the joy evaporates. The problem gets solved; I don’t get the same little “oh sick, I figured that out” hit. When I scroll through my own diffs, I’ll sometimes realize I can’t actually explain why I did X instead of Y in a given PR without re-reading the whole thing.

The work has my name on it; it just doesn’t always feel like it has my fingerprints. Intellectually, I know that programming has always been “assembly on top of other people’s abstractions.” Emotionally, the gap between “I shipped this” and “I understand this” has never felt quite this wide.

Meta-work all the way down

The really cursed bit has been where I’ve redirected my effort in the name of plate-spinning optimization.

Over the last few months I’ve spent a lot of time:

• writing and re-writing my CLAUDE.md rules to hydrate Claude Code with exactly the right context,
• changing my editor and my Raycast snippets so “send this chunk + spec + failures” is one keystroke,
• structuring projects in ways that are maximally legible to an LLM (Hacker News was not too happy with my first pass at adding .cursorrules to my main work repo),

and less time doing the traditional “learn new thing from first principles” grind.

2020-me would’ve side-eyed the shit out of this behavior (I read a book called Haskell Programming from First Principles in 2020, ffs). But the annoying truth is that the ROI is stupidly good. Small tweaks in how I feed context into models translate into noticeably more throughput. It’s very “busting the myths of programmer productivity”-coded: tooling and environment beat raw keystrokes. This is just an extreme version of the same idea.

It does mean my “craft” feels different. Less “I write elegant code” and more “I design systems so other things can write pretty good code.”

That’s defensible if you frame it as leverage. It’s just weird to wake up and realize your job has quietly shifted from “builder” to “foreman” without anyone explicitly deciding that.

The deep work tax

The part that actually scares me is what these changes have been doing to my ability to go deep.

Some problems are still very much not “vibe-codeable”: bizarre perf issues, gnarly data modeling, pathological failure modes where I really do have to build a mental model and play it forward in my head. Those are the problems that historically made me feel like a real engineer.

I am noticeably slower at them now.

If I treat the LLM as a teammate—ask it questions, use it as a rubber duck, let it sketch branches I then reason about—that helps. I’m still doing the thinking; it’s just assisting. But the second I let it slide into “do the thinking for me,” my learning curve flattens. I get answers without much intuition attached.

There’s also the raw attention issue. Dev work has been “spinning plates while someone throws more plates at you” for a while: context switching, Slack, video calls, random interrupts. LLMs quietly make that worse:

• starting a new “little task” is cheap, so it’s trivial to keep stacking plates;
• I can make a marginal amount of progress in shallow mode, so my brain learns it doesn’t need to fully load anything.

When I finally try to go deep, all I seem to have left are short bursts of focus, and it’s been a long time since I’ve consistently been able to enter a real “flow state.”

Part of why I’m writing this is just to admit that out loud: my focus is worse, and I don’t like that trend.

Learning from Karpathy

I listened to the recent interview between Dwarkesh Patel and Andrej Karpathy while I was in the middle of all this, and I liked the whole thing, but two parts really lodged in my brain since they felt relevant to this “how do I work with LLMs without lobotomizing myself” sentiment I’ve been feeling.

The first was how he actually uses them. In the section where he talks about how he codes day-to-day, walking through how he built Nanochat, he describes his workflow as almost entirely in-editor tab completion—his “sweet spot” for using LLMs—rather than giant freeform prompts in a chat box.

The second was how he encourages people to learn from Nanochat itself. The repo is framed as an educational, hackable, end-to-end LLM stack. His recommended way to study it (and his other materials) is very deliberate:

• keep the reference repo or notebook on one side of your screen;
• on the other side, keep your own empty project;
• type everything in yourself when you’re learning a new concept;
• no copy-paste, ideally no fancy completions, at least for the first pass.

The goal is to build a real mental model instead of outsourcing it to autocomplete. It’s very “understand the thing, don’t just trust the abstraction.”

I find that mix really compelling: high-leverage tab completion for production work, almost monastic manual typing for learning. And I keep wondering whether I should push myself in that direction (less “prompt in a side pane”, more “use completions as a compressed spec”) plus explicit “no LLMs, just type” time when I’m adding new primitives to my brain.

Or just learn, period

Contrast that with Dan Abramov, who recently wrote about feeling pessimistic about educational content: there’s this sense that people don’t actually want to learn anymore, they want pasteable answers and “LLM will do it” workflows instead.

That hits a little too close.

It’s not that I don’t want to learn—I do—but the system I’ve built around myself makes it extremely easy to default to “Eh, I’ll just prompt it.” And in a world where content creators are noticing demand shift away from deep explanations toward “just give me the fix,” it’s very easy to let my own habits drift the same way.

Karpathy’s “type it all out” energy feels like a deliberate counter-move to that. A personal protest: yes, I could vibe code this, but instead I’m going to sit here and actually understand it, line by line.

I don’t really want to become the person Dan is worried about writing for.

When the plates slow down

There’s also this amplitude thing: the highs are higher, the lows are lower.

On a good plate-spinning day, I feel unstoppable. I’m:

• shipping easy features end-to-end,
• reviewing pull requests,
• giving interview feedback,
• triaging bugs,
• keeping up with team chatter.

The bottleneck becomes “How fast can I read, parse, and respond?” and that’s always been one of my strengths, so it feels fantastic — everything aligns with what I’m good at.

But when anything in that loop slows down unclear spec, weird bug, flaky infra, life stuff — everything suddenly feels heavier. The plate stack is tall, and now I’m noticing how many of them are wobbling.

It stops being “Today was kind of unproductive” and turns into “I failed to keep the system at max output,” which is a wild standard to hold myself to, and a fast path to burnout if I let it ossify.

Where do I go from here?

So what do I actually do with all of this, besides write a neurotic blog post about plate metaphors?

Here’s my current plan; future-me can come back and roast me if I bail on any of it:

1. Treat LLMs like power tools, not autopilot.
   For routine work—CRUD, migrations, boilerplate tests, glue code—I’m fine going full plate-spinner: let the machines churn as long as tests are green. For hard problems, default to “rubber duck that can autocomplete,” not “Boss, do my job.”

2. Steal Karpathy’s split-brain approach.
   During normal dev, lean more into in-editor tab completion and inline comments as the primary interface, instead of bouncing to a giant chat window for everything. During learning time, pick one repo / concept, put it on one side of the screen, and type it all out manually on the other. No copy-paste, minimal autocomplete, maximal attention.

3. Protect deep work like a real deliverable.
   Carve out a few hours a day where I don’t prompt at all. No “just one quick suggestion,” no “let me see what the model thinks.” Just me, the code, and my own brain. The goal isn’t purity; it’s to keep my intuition from atrophying.

4. Optimize systems, not days.
   Try to evaluate weeks and months instead of chasing “max output” every single day. Did I learn anything deep? Did I move important things, or just many things? If a week has some sludgy, low-output days but a big conceptual gain, that should count as a win.

5. Be okay with forgettable work.
   Not every PR needs to be a personal growth moment. Some code can just… exist. The key is being intentional about which problems I’m using to level up, and which ones I’m fine letting the machines mostly handle (my old coworker Glenn has been writing about this on his Substack for a while now, ahead of the curve as always).

Beyond these steps, I don’t really have a clean conclusion. I’m very much in the middle of this, same as everyone else.

But I’m increasingly convinced that if my whole career turns into “telling a black box what to do,” I’ll burn out — even if the metrics say I’m 3x more productive.

For the hard stuff, I want to keep taking some plates down, sitting with them, and remembering what it feels like to hold one thing still for a while.

A particular segment of the podcast struck me. Harry and the host were discussing aspiring musicians who move to Nashville to break into the music industry:

“I remember asking everyone [what they were doing in Nashville], the Barista or the Uber driver or whatever… they’re all just like ‘I moved here to play drums, I’ve been here a couple years, and I’m just waiting on the gig’. And I would ask all of them ‘where can I check out your playing; where can I see you or listen to you?’ and they all went ‘well there’s a demo, it’s on cassette though and the thing is the bass player was like sick that day so this time is not that good and you know…’ I mean there’s all this qualifying! Nobody said like ‘oh right here – look at this video’. And I hate qualifying things… if I have to send something to someone and I have to qualify it, I’m not going to send it; I’ll just redo it until it doesn’t need an explanation… I realized right away that everybody I met here that didn’t have a gig was doing this qualifying thing, and I thought ‘cool, I’m not even going to say I’m a drummer to anybody until I have a video that I like of what it looks like and sounds like and feels like for me to play the drums’. So with all the little money I had, I paid this lovely videographer $25 an hour to come to my house and just point a Canon Rebel at me and I recorded myself playing a song, and I did it once a week…” (source)

The key takeaway? The best way to break into an industry is to demonstrate what your work looks like, allowing potential employers to see your capabilities firsthand.

This concept resonates deeply with me, both personally and professionally. While I don’t make music for a living, I do make software², and my experience has shown that creating and publishing quality work has been invaluable when seeking new opportunities. I’ve secured numerous interviews (two of which led to new jobs!) where the hiring team mentioned noticing me because of my GitHub or this blog. On the flip side, as someone involved in recruiting and hiring engineers, I always look forward to exploring candidates’ websites, blogs, and other online artifacts. In my experience, a strong open-source project can absolutely tip the scales in a candidate’s favor during hiring decisions.

Outside of work, I volunteer as a career mentor for my alma mater³. One piece of advice I frequently offer is to “publish the things you build.” For students just starting their careers with limited work experience, the best way to stand out among the growing crowd of CS graduates is to publish projects that showcase their skills. It’s never been easier to build something cool with software and put it online. I don’t want the students I work with to make the same mistake as the musicians Harry mentions – having plenty of talent but failing to compile a demonstration of that talent in a digestible way. As with many things, the easiest way to start standing out from the crowd is to just do things.

However, sometimes just doing things isn’t enough on its own. After hearing Harry’s interview, I read this post⁴ by my boss, James Hawkins, which succinctly summarized another concept that Harry’s interview had me pondering – when it comes to personal branding, it’s often better to go the extra mile and do something truly good. Harry discusses this at length in the podcast, lamenting the trade-off musicians face between creating “great art” and producing something that’s good enough to release. He observes that many musicians fail to showcase their abilities effectively because the process of doing something good is challenging, and the creative burden of not knowing when something is good enough to publish often prevents people from creating anything at all.

I believe this rings true – personal branding is a valuable asset for anyone in their career, and I agree with both James and Harry that it’s worth making something good if you’re going to put in the effort at all. However, as I encourage the students I mentor, every journey starts somewhere. Getting into the habit of publishing things that are “good enough” and consistently improving is an excellent way to enhance your skills overall. It’s not always easy to put yourself out there, but I don’t think it should be! Challenging tasks are worth doing, and I believe that investing extra time in enhancing your personal brand with examples of your work tends to have outsized positive impacts on your life and career – the return on investment can be substantial.

While nothing I’ve said here is groundbreaking or particularly novel, I felt compelled to write about it because these ideas have been noodling around in my mind since watching the podcast. I figured the best way to process my thoughts would be to take my own advice and just do the thing. After all, that’s what personal branding and growth are all about – consistently putting your work out there and trying to improve with each iteration.