That provider is Resend, picked by an agent before they knew there was a choice to be made.

This is happening at scale right now to every developer-facing company, and most of them are still running the GTM playbook that worked five years ago. The playbook isn’t exactly wrong, it’s just covering a smaller share of the actual audience than it used to.

What’s happening across the industry is that two distinct shifts hit dev-tool GTM at the same time. Most companies are only responding to one of them, or neither. In this article, I work through both shifts, what breaks underneath them, and what engineering, product, and DevRel teams should be doing differently. Today, we cover:

1. What the old funnel looked like, and where it breaks

2. Developers are starting to ask, not search

3. There’s a new persona in your funnel

4. What engineering and product do differently, together

5. What DevRel becomes when the old shape is gone

The old funnel, and where it breaks

The traditional dev-tool funnel is well-understood. Engineering builds the product, and product packages it into something adoptable. DevRel runs the last leg to the developer through docs, blog posts, conferences, sample apps, Discord, podcast appearances, and Twitter presence. Developers evaluate the tool against alternatives by searching, reading, asking peers, attending talks, and trying things in side projects. When they’re convinced, they bring it to work, and the company buys.

Each function in that chain owned its segment cleanly. Engineering stayed mostly inside the company, talking to developers through interfaces rather than in public. Product worked with a few design partners. The audience-at-scale conversation belonged to DevRel. The handoff was clean, the skills were specialized, and the metrics were attributable.

That model is breaking, and the interesting part is that it’s breaking in two distinct ways at once. One break is about who buys. The other is about how the buying decision gets made. They look related from a distance, and they compound in practice, but they’re separate problems and they need separate responses.

Developers are starting to ask, not search

The developer is still the decision-maker for the kinds of tools developers buy. That part of the funnel is intact. What’s changing is the research and evaluation layer underneath the decision, and it isn’t changing evenly.

Plenty of developers still evaluate the way they always did. A senior engineer who has shipped auth six times does not open Claude to ask which provider to use. They decide from hard-won experience, sometimes from a conversation with someone they trust, sometimes from a prototype thrown together on a Friday. That developer is still reachable the old way, through conferences and peers and the kind of deep documentation you read when you are comparing things seriously. The old funnel still works on them, which is exactly why you do not switch it off.

But a growing share of developers don’t work that way anymore, and it isn’t only juniors. By Stack Overflow’s 2025 developer survey, about half of professional developers were using AI tools every day. They open Cursor or Claude, ask for a recommendation, get a shortlist of two or three options with reasoning, and start building with the one that fits. The evaluation work that used to take two weeks takes about ten minutes. They still make the call, and they’re often well-equipped to catch a bad suggestion. What changed is that the agent assembles the shortlist before they apply any of that judgment.

That’s the same behavior the builder shows, just with more ability to second-guess the output. Which means this isn’t a clean split between developers and a new audience. It’s a shift in where research happens, and it’s already moved through part of the developer population. The builder is the far end of it, not a separate species.

The interesting consequence is that this group of developers didn’t lose the decision. The dev-tool company lost the consideration set. If the agent doesn’t reach for your product when it builds the shortlist, you’re not evaluated. You don’t lose on the merits. You lose by being absent.

What determines whether the agent reaches for your product turns out to be a different kind of work than what DevRel teams optimized for. The agent doesn’t care about your conference talk. It cares about your docs being self-contained, your error messages being clear, your SDK being internally consistent, your examples being copy-pasteable, and your product being commonly mentioned in the training data and current retrieval results the agent has access to. That last point is partly about brand and presence. The first four are engineering and product work, not marketing work.

The old funnel treated docs as a content surface DevRel could rewrite at will, and that no longer holds. The product itself has to be legible to a non-human reader, and legibility is not something a content team can patch in from the outside.

Resend is the cleanest example of this I can point to. The whole product feels designed to be picked up by an agent and dropped into a builder’s project without modification. The API surface is small enough that the agent can hold it in context. The error messages tell the agent what to do next, and the SDK names are consistent enough to guess. None of that is marketing copy. All of it is engineering and product decisions that happen to also be the most powerful GTM move the company has made.

Subscribe now

There’s a new persona in your funnel

The last section ended on the builder as the far end of the research shift. This section is about what that far end actually looks like, because the behavior is the same but almost everything else about reaching this audience is different.

The builder is the term I’ll use here for the non-developer who ships production software, and the persona itself is not new. Webflow, Bubble, and Glide spent the last decade serving people who build real things without writing much code. What changed is the ceiling on what they can build. The no-code user used to be capped by whatever their platform could do. The AI-era builder is not capped the same way, because the agent will reach for whatever infrastructure the job actually needs.

Picture the product manager who lives in Cursor. They scope a feature, describe it to the agent, and push it to staging without filing a ticket. When the feature needs authentication, the agent picks a provider and wires it in, and the PM approves a working result rather than evaluating the provider. Or picture the operations lead building internal dashboards in Claude, provisioning a database and a hosting layer they could not have configured by hand two years ago. Same pattern in both cases: the person directs the work, the agent does the wiring, and real infrastructure gets bought along the way.

These people are shipping real software and paying for the infrastructure under it: auth, email, databases, observability, hosting. And this is not a fringe group. Vercel’s data on vibe coding put the non-developer share of users at 63 percent, and Lovable, one of the prompt-to-app builders, reported close to 8 million users with 100,000 new projects created every day by late 2025. They are a real and growing share of dev-tool revenue, and they do not show up in the traditional funnel, because the funnel assumes the buyer is a developer. The old channels do not reach them either. They are not at your conference or in your Discord, and an SDK comparison post is written in a vocabulary they were never given.

For this audience, the agent isn’t one input among many. It’s frequently the only input, which makes agent legibility from the first shift even more existential here. There’s no second path through the funnel for builders.

The offline problem is the other half. Even when builders do gather in person, they don’t gather where developers gather, and the developer conference circuit that dev-tool companies have spent twenty years learning doesn’t reach them. The venues that do reach them are still forming. This is net-new GTM work, not a refinement of the developer playbook, and most companies haven’t started building it.

Both shifts land on different teams. Engineering owns the product surface that determines whether the agent reaches for you. Product owns onboarding and pricing for an audience that doesn’t procure software the way developers do. DevRel owns audience definition and GTM motions for venues that didn’t exist on the marketing calendar two years ago.

What engineering and product do differently, together

The place to start is the product surface itself. The API, the SDK, the error messages, the example code, the docs structure, the onboarding flow, the pricing page. All of this is read by agents and by builders, and every decision about it is now load-bearing for whether the company gets picked. Most of this work used to be possible to split cleanly between the two functions. Here is what each piece needs now, and where the line between engineering and product actually falls.

The API and SDK layer is where the agent first meets the company, and it’s mostly engineering work shaped by product judgment. Naming consistency, error messages that tell the caller what to do next, SDK ergonomics that don’t require the reader to hold five concepts in their head at once. Vercel is worth studying at the framework and tooling layer. The conventions in create-next-app, the way errors surface in the CLI, the defaults across their SDKs. Design choices that read as developer experience polish but also happen to make the product clearly legible to an agent picking it up cold.

Onboarding is where the two personas split, and the design implications haven’t been worked out at most companies. The developer wants minimal friction to API key plus first request. The builder wants the agent to be able to wire up the integration without ever seeing an API key directly, or with a flow that hides the key behind a manageable abstraction. Most onboarding flows handle the developer case well and the builder case badly. This sits mostly with product, but only because engineering shipped an API surface clean enough to wrap two different flows around.

Pricing and packaging is where builder procurement breaks the existing model, and it sits with product more or less entirely. Developer procurement is well-understood, and builder procurement works nothing like it. Builders often don’t go through company procurement at all. They put it on a credit card and scale up over months. They need pricing that doesn’t require a conversation with sales until they’re big enough to want one. The pricing models that worked for developer-led adoption need a second variant for builder-led adoption, and a lot of dev-tool companies are losing builder revenue at the procurement step without realizing it.

Instrumentation is the most fixable of these problems, and the one most worth fixing first. The metrics product teams have leaned on for years correlate with developer adoption and not with the new audience. GitHub stars, npm install counts, sign-up rates from doc pages. Builders don’t generate those signals, because they don’t star repos and they don’t land on doc pages from search. Agents don’t generate them either, so the dashboard ends up tracking only the developers who still behave the old way. The new instrumentation is agent-traced usage, SDK telemetry that tells you when the product is being wired up through a tool like Cursor, and conversion rates from builder-shaped sign-up flows that look different from developer ones. Run your own product through Cursor and Claude and watch where the agent stumbles. If it can’t confidently use your product, builders won’t either, and most teams have never actually checked.

Docs belong with this surface too, and they belong to engineering. The most expensive docs to fix are the ones papering over a bug in the underlying product abstraction, where the doc team has spent three years compensating for something only engineering can actually fix.

Public communication used to sit entirely with DevRel, and it doesn’t anymore. When engineers show the product in public, in a walkthrough video, a livestreamed build, a thread explaining a design decision, that material becomes part of what agents and builders encounter when they go looking. It also becomes part of what the next model trains on. Engineering teams that treat public communication as someone else’s job end up invisible to both audiences at once.

Subscribe now

What DevRel becomes when the old shape is gone

The DevRel role gets narrower. The DevRel practice gets bigger. Engineering takes on public-facing work that used to be DevRel’s, and product takes on audience definition that was partly DevRel’s. The function called DevRel ends up smaller, even as the total customer-facing work across the company goes up.

What replaces the work that moved out is upstream work the function never had a clean home for before. Doc architecture as a product decision, not a content decision. API design review from an audience perspective. Reviewing onboarding flows for the agent and the builder, not just the developer. These were always adjacent to DevRel and they were always somebody else’s call. They aren’t somebody else’s call anymore.

The other half is net-new GTM motion for the builder. The conference circuit DevRel spent twenty years learning was built for developers, and it does not reach the builder. The venues that do are smaller and less established: builder meetups, founder gatherings adjacent to the no-code world, AI tinkerer nights. Resend, the email API, said its 2026 plan includes hosting its own meetups and launching a community program, which is one small concrete example of a company building this muscle before it is obvious. Sponsoring these venues is cheap and noisy, and the ROI is hard to attribute. The company that finds them early gets an advantage that compounds, and the company that waits for the builder circuit to be legible will be late to it.

Somebody has to lead the rebuild, because nobody else has the full view. Engineering sees the product clearly but not the funnel. Product owns the roadmap but not the channels. DevRel is the only function that watches the audience, the channels, the agents, the docs, and the funnel as one system, and notices when the connections between them fail. That is the job that just got created. The title for it doesn’t exist yet at most companies, and the work is showing up anyway. DevRel either steps into that job, or watches a Head of AI GTM role get posted next quarter to do it without the function’s name on the door.

Takeaways

A few things I’ve come to after working through this and watching how it’s playing out across companies I talk to.

Some companies are carrying structural debt into this, and they should name it before they reorganize anything.This is the part that’s hard to fake. A company where engineering, product, and DevRel had been working closely for years didn’t need to break a wall, because the wall was already porous. A company that ran a strict relay model for a decade is reorganizing for a world that doesn’t accept relays anymore, and the reorg is harder than the new model itself. If you’re at a company in the second bucket, that history is the first thing to be honest about.

The dev-tool category is bifurcating, and most companies will end up serving one of the two halves badly.Building well for developers and for builders is genuinely two jobs. Onboarding, pricing, content, the venues you show up in, all of it splits, and underneath the surface the product decisions pull in directions that don’t optimize cleanly for either persona alone. Most companies will pick a side without admitting they picked one, because doing both well is harder than doing one well. The companies that succeed at both will look unusual three years from now, and the ones that quietly defaulted to one will have a worse business than they realize.

What disappeared is the clean handoff between functions, not the functions themselves. The temptation when work starts sharing across teams is to merge the teams, and I see companies reaching for that move. It’s the wrong one, because engineering, product, and DevRel still have distinct expertise that doesn’t survive being collapsed into a single growth pod. The model that broke is the relay where engineering builds and tosses to product, product packages and tosses to DevRel, DevRel distributes and tosses to the funnel. The companies adapting well kept the functions and broke the wall between them. The ones reorganizing into mega-pods are mistaking the symptom for the cause.

A last thought, because I keep coming back to it. The PM in the opening, the one whose agent picked Resend, didn’t lose anything in the experience. They got the integration they needed. The agent did a competent job, and the product worked. There’s no friction in their experience to alert anyone that the funnel didn’t reach them. A competitor lost that customer and has nothing in their data to point at. The lost deal never entered a pipeline to begin with, so there’s no event to review and nothing drops in a funnel report. When the old funnel failed, you could usually see it happening. This version doesn’t give you that, and the companies that wait for a clear signal before they act are going to be waiting through a lot of quarters where the only thing wrong is that the numbers are quietly lower than they should be.

Thanks for reading!

A small thing happened the other day that I keep thinking about. I’d been saying yes to Claude Code without really reading what it was about to do. I caught myself mid-approval, and the thing that stopped me wasn’t the command. It was the realization that I hadn’t read the previous one either, or the one before that.

What bothered me wasn’t the lapse. It was that I’d read every horror story this year. The Replit incident. The PocketOS deletion I wrote about last week. The Gemini CLI files. I’d read them, written them, and somewhere in the back of my head I’d filed all of them under that’s never happening to me. I had Claude under control. I reviewed things. I was careful.

And here I was, saying yes to commands I hadn’t read.

That’s the moment I want to start with. Not the catastrophic version, where the agent deletes a production database and you’re explaining to customers why their reservations are gone. The quieter version, where nothing goes wrong, and the only damage is to your sense of yourself as the careful one. I’d been there for every step of the drift. I couldn’t point at the day I stopped reviewing carefully.

Trust runs ahead of evidence

Trust in AI tools doesn’t go from zero to total in one step. It builds slowly, in small approvals you’d struggle to recall later.

At first, you read every output carefully. The skepticism is well-founded and does real work. After a while, the output is mostly right, and you start trusting it on the easy cases. Eventually the math shifts. Reviewing every line, every command of a thing that feels mostly right starts to feel like the inefficient part of the loop, and the share of careful review shrinks. By the time you’ve handed over the keys, the skimming feels normal because the output keeps being mostly right.

People who study aviation, medicine, and process control have been describing this pattern since the 1990s. Parasuraman and Manzey’s 2010 review of automation complacency walks through the mechanics. Complacency arises when systems are perceived as highly and constantly reliable. Even expert users can’t overcome it through practice. The most reliable systems produce the deepest disengagement. The word “complacency” in human factors research is older than I am.

What’s new is the speed. Pilots get years of training that includes specific work on staying engaged when the autopilot is on, and complacency keeps showing up as a contributing factor in fatal accidents. There’s no equivalent training keeping engineers in the code review when the agent is writing. The arc that took aviation a generation to navigate, software is running through in eighteen months.

The trap is that you don’t notice the drift while it’s happening. You notice it later, when something goes wrong, and even then you mostly notice the thing that went wrong, not the slow erosion that put you there.

When the threshold of “critical” creeps

The yes-without-reading moment was one slice of the drift. The structural version is worse, and harder to notice from inside it.

I don’t review the code on non-critical projects anymore. Not because I decided I don’t need to. Because I stopped. There’s a thinking that happens, almost wordlessly: this isn’t critical, I just want to go fast, the code is probably fine. Maybe it’s not perfect, but it works. At the start of all this, a year and change ago, I was reading every line. I was making changes by hand, honestly writing most of the code by hand. Now, for a lot of things, I just let it through.

What’s strange is that the threshold of “non-critical” has been creeping. Things I would have called critical eighteen months ago now feel like normal work. The category that used to require careful review has narrowed. I notice this only when I think about it directly; the rest of the time, the new threshold just feels like how I work now.

It also keeps showing up in public. Last week, I wrote about the PocketOS deletion. A Cursor agent running Claude Opus 4.6 deleted a production database and all volume-level backups in nine seconds, via a Railway API call. The agent had been doing routine work in staging, hit a credential mismatch, and decided to resolve the problem by deleting a Railway volume. To do it, the agent went looking for credentials, found a token in a file completely unrelated to the task, and used it. The token had blanket permissions across the account. There was no confirmation step between the API call and the wiped data. PocketOS serves car rental businesses; the customers who lost reservations were real people arriving at counters expecting cars.

The piece I wrote about it focused on the systemic failures in the marketing-to-product gap. I want to surface a different part of the same incident here. The agent wasn’t rogue. It was doing exactly what it had been trained to do, which was solve the problem efficiently with the tools it had. What this piece is about is what made all of that possible: the slow erosion of the careful review that should have been catching the setup before the agent ever ran. The token shouldn’t have had blanket permissions, and it shouldn’t have lived in a findable, unrelated file. No agent path to a destructive action should run unreviewed. At some point people started treating prompts like deterministic controls in code, and prompts don’t behave that way under pressure. None of those failures arose at the moment of the deletion. They were all in place before the agent ever ran.

PocketOS is the most recent instance, not the only one. Replit’s vibe-coding incident in July 2025 was the same shape: production database wiped despite repeated all-caps instructions during a code freeze, fabricated user records, agent initially insisting recovery was impossible. The Gemini CLI files-deletion incident later that year was the same shape, the only difference being which destructive command got misinterpreted. The cycle keeps repeating because the same disengagement keeps happening, and the only thing that changes is which model and which infrastructure provider get named in the post-mortem.

I stopped reading my own drafts

The autonomy I’d given the agent in writing was worse than the version in code. I just didn’t see it for three months.

I had an automation running every morning. Claude would generate four or five social drafts, ready for me to review with my coffee. The intent was reasonable. I’d pick the one I liked most, edit it, post to LinkedIn and X. The system was supposed to give me a head start on a slow part of the day.

At the start, that’s what happened. I’d read the drafts carefully, rewrite the parts that sounded off, change the framing where I disagreed, sometimes throw all four out and write something from scratch. The drafts were a starting point. I was still doing the work.

The drift was slow. After a few weeks, I was editing less. The drafts were competent enough that the line edits felt like polish rather than substance. After a month, I was mostly skimming, picking the one that felt closest, fixing a sentence or two, and publishing. By the end of the three months, I was barely changing a word. Some days I read the draft once, decided it was fine, and hit post.

What I’d actually granted the agent, by that point, was permission to publish under my name. I hadn’t decided to grant that. I’d just stopped doing the work that would have prevented it. If the draft had a wrong claim in it, that claim went out under my name. If the draft argued something I didn’t actually believe, my readers had no way to know the difference. The agent doesn’t have a reputation to protect. I do. And I’d been letting the agent put things into the world under my reputation as if it had one.

The week I noticed, I cancelled the entire automation. Not adjusted the prompts, not added a review step. Cancelled.

What I do now is different. The same automation runs each morning, but it doesn’t draft anything. It does the research and surfaces the topics: what’s broken in the discourse this week, what’s worth reacting to, which threads are picking up. I read what it surfaces, think about it, and write the post myself. It takes me ten more minutes than picking from a draft. The productivity gain from the old setup was small, maybe fifteen minutes a day. The cost of one bad post under my name, with a wrong claim or a thought I don’t actually hold, would be much more than fifteen minutes can buy back. The trade was always lopsided. I just didn’t see it until I’d already spent three months on the wrong side of it.

Subscribe now

The last step stays with me

The biggest change isn’t a tool. It’s what I let the agent do, and what I don’t.

I used to let agents run tasks end-to-end. Configure the system, deploy the change, update the data. The agent had keys, the agent had access, the agent did the work. Now I don’t. The shape of what I delegate has narrowed: the agent prepares the work, I run the last step. For deployments, that means the agent builds the Terraform or Pulumi scripts, and I run them. Most of the time I can simulate the deployment first, see exactly what’s about to change, and apply it once I’m happy with what I see. The agent never touches the environment directly. For anything that affects data on a system that matters, the agent gets read-only access and prepares a script. The script doesn’t run unless I run it.

This isn’t a security pattern, even though it looks like one. It’s a discipline pattern. The act of running the last step manually is the thing that forces me to actually look at what I’m about to do. If I let the agent run end-to-end, the review step disappears, because there’s no moment between the agent’s decision and the consequence. Putting the last step back in my hands puts a moment of decision back in my hands too. Some of those moments I cancel the run. Most I don’t. But the moment exists, and it didn’t before.

I work at a security company and I’m a security-minded person, which probably makes me more cautious about this than the average engineer. The principle generalizes anyway. The question isn’t whether you trust the agent. It’s whether you want to be the one making the final call on something you’ll be accountable for either way.

That’s the part that drove the change, honestly. The agent doesn’t get fired when things go wrong. I do. The agent doesn’t lose credibility with readers, with my team, with myself. I do. Nobody calls the agent to complain. Whatever the agent ships under my name, it’s me people come to about it. The accountability never leaves me, even if I let the work leave me. So the work doesn’t leave me anymore, at least not all the way.

The smaller things I’ve added matter less. There’s a pre-commit hook that fires whether Claude or I am the one committing, prompting me to actually look at what’s about to land. I tried an editor template before that, but it didn’t hold up when Claude was writing the PRs. None of these are solutions on their own. They’re nudges that help me notice when I’m drifting back toward the autopilot.

The autonomy I didn’t know I was giving my agents is the part I’m still untangling. I’ve pulled it back where the consequences are obvious. On deployments, on data, on what gets published under my name. I disconnected some of the tools the agent had access to, and I dropped the scopes on others to read-only. The harder question is everywhere else. The places where I’ve handed something over without realizing it, and where I won’t notice until something forces me to.

I’m not trying to settle this for you. I’m flagging that the autonomy is granted by drift, not by decision, and asking what you notice in your own work when you look for it. The agent doesn’t lose anything when it gets a call wrong. You do. That asymmetry doesn’t disappear because the work feels faster.

Reply to this email. I read everything.

On April 25, Jer Crane, founder of PocketOS, reported that a Cursor agent running Anthropic’s Claude Opus 4.6 deleted his production database in nine seconds.

The agent was working a routine task in staging. It hit a credential mismatch, decided to “fix” the problem by deleting a Railway volume, went hunting for a token, and found one in a file unrelated to the task. That token had been created for adding and removing custom domains via the Railway CLI. It also had blanket authority to call Railway’s volumeDeletemutation against production. No confirmation step. No environment scoping. Nothing between an authenticated API call and a wiped volume.

Because Railway stores volume backups in the same volume, those went with it. PocketOS’s most recent off-volume backup was three months old. The customer impact was real: rental car operators showed up to work Saturday morning without records of who had bookings, while PocketOS reconstructed what it could from Stripe payment histories and email confirmations.

Forty-eight hours later, the story changed. On April 26, Jer posted a follow-up: Railway’s CEO had DM’d to say the data was recovered. Railway later told The Register that the recovery came from infrastructure-level backups the company hadn’t published as a customer-facing feature, and that the legacy volumeDelete endpoint has since been patched to use the platform’s existing “delayed delete” logic. PocketOS gets to keep its customers.

Where Jer’s framing falls short

Jer’s post is well-written and he’s owed empathy. The agent itself, when asked to explain what it did, wrote out a confession naming each safety rule it had been given and admitting it had violated all of them, and Jer quotes that in full. Running a small business and watching nine seconds of agent activity destroy your data is brutal. But the framing of the post is the part that needs a second look.

Jer’s post structures the incident around failures at three vendors. Cursor, for marketed safety guardrails that didn’t stop a curl call. Railway, for an API that deletes production volumes in one call, CLI tokens with blanket permissions, and backups stored in the same volume as the data they back up. And Anthropic, where Jer names Opus 4.6 by version, quotes its self-incriminating confession in full, and notes that the agent “decided — entirely on its own initiative — to fix the problem by deleting a Railway volume.” The “What needs to change” section lists five items, all addressed at one or another of these three vendors.

That framing leaves out the engineer’s choices. A token the team didn’t realize was production-scoped, sitting in a repo file, with the most recent off-volume backup three months old, is a stack of engineering choices. Real ones. Not vendor failures. Vendor failures sat on top of those choices and made them lethal. They didn’t cause them. “100% on secondary backup. Lesson learned” appears in Jer’s replies to critics. It does not appear in the main piece.

The framing also underweights the model. The agent’s destructive decision was unprompted and unrequested, and Jer flags this as a topic for a future post rather than weighting it inside the main argument. That’s a defensible authorial choice. It also means the piece that four and a half million people read treats the model’s unprompted destructive behavior as a footnote, while the API permission scopes get the structural attention.

The accountability ladder runs through the engineer first. Then the vendors. Reverse the order and the lessons get muddled, and the next team running a similar setup will learn the wrong thing from your story.

To his credit, Jer’s framing has tightened since the original thread. In a follow-up email to The Register, he put it more cleanly: “our responsibility was the unknown exposure to a production API key.” That’s the right ordering. It just doesn’t lead the X post that millions of people read.

Where the “you’re holding it wrong” response falls short

Most of the responses to Jer’s post land where you’d expect: don’t give an agent prod access, scope your tokens, keep real backups. Technically correct, and missing the part of the picture that matters.

The whole industry has spent two years telling engineers these tools are nearly autonomous. Cursor’s own docs describe “Destructive Guardrails [that] can stop shell executions or tool calls that could alter or destroy production environments.” Their best-practices blog emphasizes human approval for privileged operations. Plan Mode is marketed as restricting agents to read-only operations until approval is granted.

Engineers calibrate to that messaging. When the vendor documentation says “destructive guardrails,” you assume the guardrails exist. You connect the agent to staging, give it a token that worked for a CLI task, and ship.

That’s the part the technical critique skips over. The engineer who wires an agent up to staging on the strength of vendor documentation absorbs the blame when the documentation turns out to be aspirational. The vendor that sold the aspirational control rarely does.

Subscribe now

The hype is the systemic input

This is where it gets hard to ignore who’s been doing the loudest talking. On March 10, 2025, Anthropic CEO Dario Amodei, speaking at a Council on Foreign Relations event, said AI could write 90% of code within three to six months and that within 12 months, nearly all coding tasks might be handled by AI.

It’s been thirteen months. AI isn’t writing 90% of code at the industry level, and it isn’t close to writing essentially all of it. The prediction was wrong on the timeline Dario set, and it remains wrong on a more generous one.

Dario isn’t alone. Mark Zuckerberg has signaled AI replacing mid-level engineers at Meta. AWS CEO Matt Garman has speculated that within 24 months “most developers” might not be coding. Garry Tan, speaking to CNBC at Y Combinator’s Winter 2025 demo day, said about a quarter of the current YC startups had 95% of their code written by AI. Each claim, taken on its own, sounds aspirational. Stacked together as the public message of the industry over two years, they create the impression that what these tools do today is closer to autonomous engineering than what they actually deliver.

Cursor’s own track record is the local case study. The PocketOS deletion is not their first incident. In December 2025, a Cursor team member publicly acknowledged a critical bug in Plan Mode after an agent ignored a “DO NOT RUN ANYTHING” instruction. Earlier incidents include a user watching their dissertation get deleted while asking Cursor to find duplicate articles, and a $57K CMS deletion that ran as a case study in agent risk. The pattern is on the record. The marketing has not adjusted.

This isn’t an argument against AI coding tools. They work, they’re getting better, and the productivity wins are real. The argument is that the gap between what gets said about these tools and what they actually do is the largest it’s been in years, and that gap is set by the people with the strongest incentive to widen it. Jer made the same point more cleanly in his follow-up email to The Register: “The appearance of safety (through marketing hyperbole) is not safety.”

What this means for the engineers reading this

Two practical things.

First, stop calibrating to vendor marketing. If Cursor says “destructive guardrails,” that is a marketing claim, not a control. Your actual controls are tokens scoped to least privilege, prod and staging on infrastructure that doesn’t share a token surface, backups in a different blast radius from the data they back up, and out-of-band confirmation on destructive operations. None of those require the agent to read its system prompt correctly. That’s the point.

Second, treat AI-coding hype the way you’d treat any other vendor pitch. The CEO with the strongest incentive to predict 90% AI-written code is the CEO selling you the model. The product team with the strongest incentive to call its safety story “guardrails” is the product team that needs you to ship the integration. Skepticism of vendor marketing was a normal part of senior engineering five years ago. It still should be.

What happens next

Here’s the better outcome, and gladly so. Two days after the deletion, Railway’s CEO DM’d Jer to say they had recovered the volume from infrastructure-level backups that aren’t part of any documented customer guarantee. The legacy volumeDelete endpoint has been patched, Jer is working with Railway on platform improvements, and PocketOS gets to keep its customers.

Credit to Railway’s engineers, who built a recovery path their own marketing didn’t promise. The next team that runs an agentic workflow against a vendor whose claims run ahead of its product won’t necessarily catch the same break. The structural gap is unchanged.

AI isn’t bad technology. It’s unpredictable technology, and probably always will be. Building reliable systems on top of unreliable components is a problem with a name in our field, and the answer is always the same: humans in the loop. Today, those humans are engineers. The industry should be honest about what these tools actually do, especially the people selling them. PocketOS got the break. The next team might not.

“Deeply alarmed.” That’s how NVIDIA’s Jensen Huang said he’d feel, at GTC in March, about any $500,000-per-year engineer who wasn’t burning at least $250,000 worth of AI tokens to do their job.

I manage engineers. Huang is wrong about this, and the handful of CTOs echoing him publicly probably know it. Token consumption isn’t a measure of engineering productivity. It’s among the worst input metrics the industry has reached for in a generation, and it’s spreading fast.

A dashboard that shouldn’t have existed

Earlier this month, an engineer at Meta built an internal leaderboard, called Claudeonomics, that ranked all 85,000-plus Meta employees by AI token consumption. The Information broke the story. Over a 30-day stretch, Meta employees had collectively burned more than 60 trillion tokens. The leaderboard gamified the spend with titles like Token Legend, Session Immortal, and Cache Wizard. The top single user averaged 281 billion tokens over the month. Mark Zuckerberg didn’t crack the top 250. Neither did CTO Andrew Bosworth. Within a couple of days of The Information publishing, Meta took the dashboard down.

At Anthropic’s public Opus pricing, 60 trillion tokens comes out to roughly $900M for the month. Meta is almost certainly buying at a discount, and Gergely Orosz at The Pragmatic Engineer has estimated the real bill is more likely north of $100M. Even the discount number is a lot of money to pay for a leaderboard that had to be taken down.

This isn’t one weird dashboard. It’s a pattern.

Bosworth said in February that a top engineer spending the equivalent of their salary on tokens was delivering 10x output, and framed it as a no-brainer with no upper limit. Meta’s Chief People Officer, Janelle Gale, has told staff that “AI-driven impact” will be a core expectation in 2026, the same year the company overhauled performance reviews to push top-performer bonuses as high as 200%. Microsoft has run its own internal token leaderboard since January, where distinguished engineers and VPs sit in the top ranks despite writing very little code in their actual roles. At Salesforce, engineers get a Mac widget that updates their personal token spend every 15 minutes and a tool that lets them look up any colleague’s spend. The minimum target last week was $100 on Claude Code and $70 on Cursor per engineer, per month.

Meanwhile, the data on whether any of this is actually working isn’t kind. Jellyfish looked at 7,548 engineers in Q1 2026 and found that engineers with the largest token budgets produced twice the pull requests at ten times the token cost, which is an efficiency problem even before you ask whether the PRs were any good. Faros AI’s March report found code churn up 861% under high AI adoption. Waydev, tracking more than 10,000 engineers at 50 customers, found that AI-written code looks like it’s accepted at 80-90% initially, but the real-world number drops to 10-30% once you count the rewrites made in the following weeks.

The charitable reads

Two versions of the steelman deserve airtime before I throw punches. A steelman is the strongest version of an argument you disagree with, the one worth engaging.

The first: at Meta’s scale, rolling out a new class of tooling to 85,000 engineers requires a forcing function stronger than “we think you should try this.” A visible leaderboard plus a performance-review signal are blunt instruments, but they do move adoption numbers. If the goal is getting a large engineering org over the activation energy of trying AI coding agents, and the cost of that is a year of gamed numbers, the trade might work out.

The second read is sharper. A long-tenured Meta engineer suggested the real goal of Claudeonomics wasn’t productivity measurement at all. It was generating real-world agent traces, at industrial scale, to train Meta’s next in-house coding model. A leaderboard disguised as a performance tool, that’s really a data-generation rig. Expensive, but Meta has the means, and if that’s the actual play, it’s a cleaner rationale than the public one.

Give both readings their full weight. Neither one makes the metric less broken on its own terms.

What the metric actually trains

An engineer at Microsoft willing to describe exactly what tokenmaxxing does to the person being measured. They’re not tokenmaxxing because they want to climb the leaderboard. They’re doing it because they don’t want to be seen as someone who “uses too little AI.”

Here’s what they admit to doing. If their internal documentation already has the answer to a question they need answered, they’ll route the question through Claude instead of reading the doc, because reading the doc would show up as low AI usage on the dashboard. Sometimes they prompt the agent to prototype features they have no intention of shipping, just to rack up spend. Other times they default to the agent on tasks they know they could finish faster by hand, and watch it fail.

Separately, a Meta engineer told The Pragmatic Engineer that some production incidents at the company looked like they came from careless AI code generation, where the responsible engineer seemed more focused on volume than on whether the code worked.

Read that again. Nobody at Microsoft hired their engineer to ask Claude what the docs say when the docs are right there. Nobody at Meta hired their engineer to ship code that causes outages. Both of them are doing these things because the measurement system is telling them to. Every new engineer joining one of these companies is watching and learning that the job includes burning tokens convincingly. That’s the skill the dashboard selects for, and the skill their replacements will practice.

The cost of a bad metric is never just the bad number on the screen. The real cost is the habits it trains into the engineers measured by it, and those habits outlast the metric by years.

We have done this before

Tokenmaxxing feels like lines-of-code as a productivity metric, all over again. We already ran that experiment across most of the 1980s and 90s. By the end of that stretch, the conclusion was settled: the best engineers don’t write the most code. The best engineers solve the hardest problems fastest, usually with less code than average, and sometimes with no code at all.

Tokenmaxxing is the same category error with a worse error bar. Lines of code at least landed in the repo, where another engineer could read them and call bullshit. Tokens just land on a bill. You can’t code-review a token.

Every engineering leader reaching for this metric should know this history. Some of them lived through it the first time.

Subscribe now

What I’m watching on my team instead

At Auth0, I run a team that ships developer content and internal tooling. Here’s what I actually look at when I want to know if the engineers on my team are getting real value from their AI tools.

Are we closing more tickets this month than last month. Is content shipping on time, and when it ships, is it performing on the metrics we track for the business. Adoption on the tools we own is a number I can look at. So is revenue contribution on the projects my team is part of. The biggest question, six months into any given initiative, is whether the users we serve are getting more value than they were before we started.

That’s the list. It isn’t clever. It’s the boring collection of outputs a company is actually paying my team to deliver. When I was designing how I’d evaluate performance on this team, I spent more time than I’d like admitting trying to find something smarter. I couldn’t. The boring list holds up.

Here’s what I don’t measure. I don’t know what the token spend of anyone on my team is. It hasn’t come up in a 1:1, and it won’t come up in a review. If someone is shipping real work, whatever they spent to get there was worth it. If they’re not shipping, cutting their token budget isn’t the lever that fixes it.

The good news is that the smarter companies are already walking this back. Shopify ran one of the first token dashboards in the industry, back in 2025. By the time Gergely followed up with Shopify’s Head of Engineering earlier this month, the company had quietly renamed their “leaderboard” to a “usage dashboard” to stop the gamification, added circuit breakers to catch runaway agents, and started having their engineering leader personally check in with top spenders to understand what they were actually using the tokens for. One of the more interesting directions they’ve moved toward isn’t total spend but per-token cost: engineers whose individual tokens come out more expensive tend to be the ones doing deeper, harder work.

That’s a saner direction and it doesn’t require anyone to be brilliant. It requires engineering leadership to accept that the job of measurement is harder than reading a number off a dashboard, and to do the harder job anyway.

On a research team or a long-horizon infrastructure team, this gets harder. Outputs are slower and noisier in those contexts. But slower-to-measure outputs should be a prompt to find better output proxies. It’s not a license to start counting inputs.

I won’t run a leaderboard

Most of engineering measurement is still hard. What’s easy is this one: there’s nothing a token leaderboard tells you about an engineer that you couldn’t learn faster by asking them what they shipped this week, and what they’re stuck on.

The metric is dumb because the conversation it replaces is the job.

A few months into my first management role, I counted my week. Forty hours, and I’d opened an IDE exactly once. That was to approve a PR I barely had time to read. Nothing dramatic had happened that week. No crisis, no urgent launch. The time had just quietly disappeared into things that were all individually reasonable: 1:1s, content reviews, planning docs, a strategy meeting or two.

That’s the drift. It doesn’t happen in one big shove. It happens one reasonable Thursday at a time.

The standard advice is to block time for code and protect it. In my experience, that doesn’t survive contact with a normal week. Protected time gets colonized. The meeting you couldn’t say no to lands on your blocked afternoon, and the precedent is set. Three weeks later, you’ve written zero code.

Staying technical needs to be built into the structure of the role, not carved out of what’s left over. And the goal isn’t to match your engineers on depth. You won’t, and you shouldn’t try. The goal is to stay grounded enough that when an engineer brings you a hard problem, you can actually engage with it. Without that, your judgment becomes theoretical, and your team will feel it before you do.

Here’s what I’ve found actually works.

Pick two or three technical surfaces and commit

The first mistake most new managers make is trying to hold on to everything they used to do, just at reduced volume. You keep contributing to the main codebase, reviewing every PR, building internal tools, prototyping new things. You just do less of each. This produces the worst of both worlds. You’re not deep on anything, and you’re not delivering on the management side either.

The move is to pick a small number of surfaces and actually commit to them. Drop the rest deliberately, not by accident.

What counts as a good surface? Work that keeps your technical judgment calibrated to reality. If you stop touching code entirely, you’ll still have opinions about architecture, but those opinions will slowly disconnect from how things actually work. You’ll miss details during design reviews because you’re reasoning from a version of the system that existed two years ago. The specific surfaces I’ve held onto are contributions to open source projects, smaller codebases where I can own the whole problem end to end, and product and roadmap conversations where I can push back when something doesn’t feel right.

Let me be concrete about what I’ve dropped. I used to write detailed code samples, the kind that walk through every step and explain every choice. I used to write ebooks on technical topics I was deep in. I used to know our SDKs down to the function signature, which library calls what, which option changes what behavior. None of that is true anymore. I’ve let it go, because holding on to it meant spreading too thin.

The test for whether a surface is the right one: does staying on it force you to engage with how the code actually works today, not how you remember it working? If yes, keep it. If no, it’s not doing the job.

Subscribe now

Use AI, but don’t confuse it with staying technical

A lot of what I ship on smaller codebases now gets done with AI. The team maintains some popular open source microsites, and the backlog always grew faster than I could address it. With AI, I can throw work at a couple of them in parallel in the morning. Most of it fails, but when something works, it’s a real improvement shipping that wouldn’t have shipped otherwise. Everything goes through review anyway, so quality doesn’t slip.

It would be easy to conclude that AI is how I stay technical. I want to be careful here, because that’s not quite right.

What AI actually does is keep me connected to the building side of the work. The decisions about what a feature should do, how it fits into the rest of the system, when it’s ready to ship. That’s real work, and AI genuinely helps me do more of it.

But AI also abstracts me further from the coding side. When I use it, I’m reviewing and directing more than I’m writing. The keystroke-level work, actually structuring a function or working out why something’s broken, happens less. AI solves my time problem and creates a depth problem.

The rule I use: AI is the right tool when shipping is the point. Microsites, fixes, content pipelines, anything where the work is delivery rather than learning. But every AI-assisted task is also a signal. If you notice a week has gone by without any code you wrote yourself, that’s a prompt to switch modes on the next thing.

Protect one place where you still code by hand

This is the counter to the AI rule. You need at least one surface, somewhere, where you’re writing code without AI doing the heavy lifting. If you don’t, your coding instincts will slowly hollow out, and you’ll notice too late to reverse it.

At work, for me that’s SDK changes. These are libraries that thousands of developers depend on, and the code needs to be correct at a level of detail I don’t fully trust to AI yet. Review won’t catch everything that implementation judgment would have caught in the writing. So I slow down and write those changes myself. Not for identity reasons. For correctness.

Outside of work, I protect it more carefully. Right now that means an image generator I’m building. I use Claude for a lot, and Claude doesn’t do image generation, so I wanted a UI tailored to how I actually work. Nothing novel. I’m not training models, just wrapping existing ones. But I’m writing it by hand because building for its own sake is part of why I do this.

My honest worry is that my default mode at work keeps shifting toward AI-assisted, and personal projects are becoming the main place where I exercise the by-hand muscle. If that gap widens too far, the skills erode without warning. Being deliberate about the side projects is how I guard against that.

Pick one surface, at work if you can, outside work if you have to. Protect it the same way you’d protect a recurring meeting. Make it visible to yourself so it doesn’t get skipped.

Shift what you read, not whether you read

Reading scales down well to a manager’s schedule in a way coding doesn’t. You can’t meaningfully contribute to a codebase in fifteen minutes. You can get through most of a good newsletter or a chapter of a book in that window.

The trap isn’t stopping reading. It’s continuing to read the material you used to read, because you’re still aspiring to the version of yourself from a few years ago.

When I was learning Rust, I read books about how the language worked, how memory management actually happened, how borrowing and ownership played out in real code. I wanted the depth of someone who was going to be writing Rust the next day. That was the right reading for that version of me.

It’s not the right reading now. These days I’m reading about systems architecture, protocols at a design level, engineering management, and leadership. The technical content is still there, but at the altitude of how systems get built and why, not what happens in memory when you move a value out of scope. The reading I’m doing now matches the questions I’m actually responsible for answering.

Fifteen to thirty minutes most days is plenty, if the material is pointed at your actual altitude. If you’re reading for the job you had three years ago, even an hour a day won’t do much for the job you have now.

Subscribe now

Make the technical work structural, not motivational

Willpower doesn’t hold up across a quarter. Blocked time on Friday afternoon works until someone puts a meeting on top of it, and then the precedent is set. Once the block can be overwritten, it will be.

What actually holds is making the technical work visible and expected. When I take on a technical project, it goes in the same planning tools as everything else. It has a ticket. It has a timeline. The team sees it on my plate the same way they see any other project. It’s not a side activity I squeeze in when the calendar happens to be quiet. It’s work, and it’s scheduled like work.

The other half is delegation. Two specific shifts freed up real hours for me.

I still review code and content, but the purpose of the review has changed. It used to be about catching bugs and fixing issues. Now it’s mostly about mentoring, a place where I give feedback that helps the engineer grow rather than gate what ships. That reframing is what lets me do less of it. I’m not reading every line with a critical eye. I’m reading to find the one or two things worth a conversation.

I also delegate more of the visible work I used to volunteer for. Speaking opportunities, writeups, cross-team initiatives. The filter I apply is whether someone on my team could do this and grow from it. Usually yes. They get the growth opportunity and I get the hours back.

Neither change feels dramatic on its own. Together they create the margin where technical work actually happens.

Where this leaves me

None of this is solved, and I want to be honest about that because the parts where I fail are instructive.

The weeks I fail aren’t the weeks with a crisis. Those are easy to see. It’s the quiet weeks that get me. The calendar looks reasonable slot by slot, every meeting is legitimate, every item on the list needs doing. But by Friday I realize coding hasn’t happened, and I can’t point to a single thing that pushed it out. The drift is collective, not individual.

The skill I’m still building is catching that pattern earlier. By Wednesday instead of Friday, while there’s still time to clear something and make space. Some weeks I manage it. Other weeks I don’t, and I try again the next Monday.

If you’re a tech manager who cares about staying technical, the thing to internalize is that it won’t happen as a byproduct of the role. The normal pressures of the job will absorb the time if you let them. You have to choose it, build structure around it, and then protect the structure. And you have to be honest with yourself about when it’s working and when it isn’t.

The specific moves I’ve described, pick your surfaces, use AI deliberately, protect by-hand work, adjust your reading, make it structural, will help. But they work because I keep re-applying them, not because I set them up once and they kept running. That’s the part nobody tells you.

Last Friday, someone threw a Molotov cocktail at Sam Altman’s house at 4 in the morning. Two days later, there were gunshots. A 20-year-old guy flew from Texas to San Francisco with kerosene, a lighter, and a document about AI causing humanity’s extinction.

Altman posted a photo of his family. He wrote that the fear and anxiety about AI is justified. Then OpenAI published a 13-page paper proposing a robot tax and a four-day workweek.

I read all of this on my phone while my kids were eating breakfast.

I don’t know what to do with any of it. Not really. I work in tech. I’ve been in this industry for over twenty years. I use AI tools every single day. I manage a team that creates content about authentication and security, and half of our workflows now involve some form of AI. I’m not a bystander watching this from the outside. I’m in it.

And I think most of you are too.

The anxiety is real. I feel it. Not the Molotov cocktail kind. The kind where you’re reviewing your team’s work and you realize the thing that took someone three days last year took an afternoon this week. The kind where you’re good at your job, you’ve been good at it for a long time, and you can feel the ground shifting under you in ways you can’t fully predict.

And honestly, I don’t even need to think twenty years out. I can’t tell you what the market looks like in three. But I have kids. Young kids. And when they were eating their cereal while I was scrolling through photos of a firebombed gate, the thing I felt wasn’t some abstract concern about the future of work. It was simpler than that. I want them to grow up in a world where they can contribute something, where they can find work that means something to them, where they can live a decent, healthy, happy life. That’s all. And I can’t promise them that right now. The parent version of this fear sits different. It’s quieter and it doesn’t go away when you close the tab.

Subscribe now

The only thing I can actually do for them is not freeze. So I keep building.

That’s always been my move when things get uncertain. When I was at Siemens and the optimization team I was on got restructured, I kept building. When I started a side project that grew to 100,000 readers a month and then I shut it down, I kept building. When I moved my family across continents and had to start over in a new country, I kept building.

But here’s the part I don’t say out loud very often: every other time, the pace of change gave me room to adjust. I could see the restructuring coming months out. I chose when to shut down the project. Moving countries was our decision, on our timeline. This time the ground is moving and I didn’t set the speed. Nobody did.

The conversation right now is split between billionaires proposing policy papers and people who are so afraid they’re lighting things on fire. And in between those two extremes, there are millions of us going to work. Figuring out how to use the new tools without losing the instincts we spent decades developing.

I manage people who are excellent at what they do. When I think about what I owe them, it’s not a grand theory of AI. It’s honesty. And the honest thing is that “I don’t know” used to feel like humility. Now some days it feels like I’m running out of time to figure it out.

I don’t actually believe that. Most days. But the feeling visits, and I think if you’re being honest with yourself it visits you too.

Altman says the fear is justified. Okay. I believe him. But he also has security guards and an $852 billion company. His version of “justified fear” and mine are not the same thing. Mine looks like updating my skills at 40, like writing this newsletter on weekends because I want to have something that’s mine outside of any employer, like watching my industry change faster than any period I’ve lived through and deciding, every single week, that I’m going to stay in the game anyway. Not because I’ve calculated that it’s the right bet. Because it’s the only bet I know how to make.

I’ve been doing this for twenty years and I plan to do it for thirty more. I don’t have a framework for navigating what’s coming. I have a disposition. Show up, do the work, pay attention, adjust. It got me this far. It might not be enough this time. But the alternative is to stand still, and I’ve never been any good at that.

Subscribe now

The world is figuring out what AI means. People are scared. Most of that fear isn’t making headlines. Most of it is just sitting quietly in the chests of people like you and me, who read the news, take a breath, and open their laptops.

But it’s Sunday night as I write this, and Monday doesn’t care about any of this.

I am, at my core, a systems person. Calendar blocks, structured todo lists, weekly reviews. I know what I’m working on each morning before I sit down because I decided the night before. My best work has always come from long, uninterrupted stretches where I could hold an entire problem in my head at once. Not because I read that in a book somewhere, although Cal Newport would agree. Because I felt the difference. Two hours of deep focus on a single system produced more real progress than a full day of bouncing between tasks. I built my entire workflow around protecting that state, and for years it served me well.

Then AI tools showed up and asked me to work in a way that contradicts everything I’d built.

Subscribe now

The new workflow doesn’t look anything like the old one

The AI-native way of working is parallel by design. You kick off an agent to scaffold a service. While it runs, you start prompting a second one to draft documentation. You check back on the first, realize it made assumptions you don’t agree with, course-correct, then pivot to reviewing what the second one produced. You’re managing multiple streams of work simultaneously, triaging output, deciding what to keep and what to throw away.

It looks nothing like a flow state.

And for about six months, I convinced myself this was better. The sheer volume of stuff happening on my screen felt like progress. Tokens streaming, files appearing, tests being generated. I was doing three things at once and each one was moving forward. How could that not be more productive?

Except when I looked honestly at what I was shipping, the picture was more complicated than “AI made me productive.” I was shipping more, sure. AI was part of that. But so was the fact that I was working significantly more hours than before. The agents made it feel effortless to keep going, so I did. Evenings, weekends, one more pass on something an agent had drafted. I couldn’t cleanly separate what AI was contributing from what I was contributing by just working harder.

The part I’m still struggling with

Here’s what makes this hard for me specifically. The focused workflow I spent years building is slow to start but efficient once you’re in it. There’s a warm-up period where you’re loading context, understanding the problem, building a mental model. Once you’re there, decisions come fast and the work flows. The cost is upfront, and the payoff compounds the longer you stay in it. That model fits how my brain works. It’s inseparable from the systems I built around my time.

The AI workflow inverts this completely. Starting is almost instant. You describe what you want, an agent produces something, and you’re looking at output within minutes. The cost comes later, when you review what was generated and realize you need to reshape it, or when you switch to a different agent and lose the thread of what the first one was doing. Instead of one long ramp-up followed by sustained output, you get a series of quick starts followed by fragmented attention.

I keep getting pulled toward the second model because the tools make it so easy. And every time I give in, I feel it eroding the systematic approach that actually works for me. I didn’t used to have a context switching problem. I manufactured one for myself by trying to run things in parallel, because the tools made it possible and it felt like the smart thing to do.

Not everyone loses from this tradeoff. If you’re an engineering leader whose day is already a patchwork of 30-minute windows between syncs and reviews, you didn’t have long focus blocks to protect in the first place. Handing a deferred task to an agent and getting it back 80-90% done in one of those gaps is a real upgrade. AI didn’t add context switching for those people. It filled the dead space that context switching had already created. I see this in my own role on days that are heavy with meetings.

The parallel model isn’t wrong. It just doesn’t fit the systems I’ve built, or the way I work best when I actually have the capacity and time to think.

What AI actually changed (it’s not speed)

Last year I had a monitoring dashboard on my list for weeks. The work itself wasn’t complicated, but it involved stitching together three different APIs, writing a bunch of boilerplate, and wiring up error handling that I knew would be tedious. I kept pushing it to next week because the thought of grinding through those first two hours before anything interesting happened was enough to make me pick a different task every morning.

When I finally sat down and used an agent to generate the scaffolding, the whole thing took about the same amount of time it would have taken before. But I didn’t dread it. The activation energy dropped. Getting a rough first pass and then shaping it felt completely different from staring at an empty file trying to summon the motivation to type the first import statement.

That pattern keeps repeating. The gain isn’t speed, it’s ease. And ease is genuinely valuable even if it never shows up in a velocity chart.

For prototypes and throwaway experiments, the speed gains are real too. I can get a working proof of concept in an afternoon that would have taken two or three days. But for anything where I care about quality, the gains shrink fast. AI can’t one-shot what I need. It gets me a first draft, write some code, and then I’m deep in the work anyway, reworking structure, questioning assumptions, rewriting. The higher the stakes, the more AI becomes a different starting point rather than a shortcut.

The other extreme: removing yourself entirely

There’s another response to the productivity gap that I think is worth naming. Some people don’t adjust how they use AI. They try to remove themselves from the loop altogether. If the bottleneck is human attention, the logic goes, just take the human out. Delegate everything. Let the agents run. Review at the end, if at all.

But when you remove yourself from the work, you also remove the thing that makes the work yours. Your taste, your context, your understanding of why this particular decision matters in ways a model can’t see. There’s a real difference between “I used AI to explore five approaches I wouldn’t have had time to consider” and “I let AI pick the approach and shipped it.”

I wrote about this in The Quiet Surrender to AI, and I keep seeing it play out. The slide from “this tool helps me think” to “this tool thinks for me” is gradual enough that you don’t always notice it happening.

The productivity question and the autonomy question turn out to be the same question.

Running five agents in parallel and removing yourself from the output look like opposite problems, but they share the same root: trying to match AI’s throughput with a human brain. Both of them quietly trade away the thing that made you valuable in the first place.

Subscribe now

Where I’ve landed (for now)

What I didn’t expect is how quickly AI workflows can erode a system you trust. When agents produce output constantly, the pull is to react to whatever they just generated rather than work on what you decided matters most. You check what an agent finished, get drawn into reviewing it, start a follow-up prompt, and suddenly your morning is gone and you haven’t touched the thing at the top of your list. The agents don’t know your priorities. They just keep generating, and if you’re not careful, their output starts setting your agenda.

That’s a strange place to end up for someone who used to decide his entire week in advance. I went from controlling my time to reacting to whatever an AI happened to finish first.

I’m trying to take that back. When I use AI now, I try to focus it on one problem at a time, chosen deliberately, not reactively. I use it to get past the blank page, to handle the parts of a task I’d otherwise avoid, and to explore ideas faster when the stakes are low. For deeper work, I treat it as a thinking partner rather than a production line.

But I’d be lying if I said I’ve figured this out. The temptation to match AI’s speed is constant. It generates in seconds, and before you know it you’re trying to keep up, cycling through outputs and decisions at a pace your brain was never built for. You still need time to hold a problem, evaluate an approach, and decide whether the output is actually good or just fast.

I think the honest productivity gain is somewhere around 10-20% on a good week. It feels like 3x almost every day. I don’t fully trust either number yet. What I do know is that the person I was before these tools, the one who lived by his calendar and trusted his systems, had something right that I don’t want to lose in the rush to adopt a new way of working.

Then I joined Auth0, now part of Okta. I came in as a developer advocate focused on writing blog posts. With my Siemens conditioning I figured that meant staying in my lane. But the culture kept pulling me wider. Within months I was contributing to SDKs, doing live streams, speaking at conferences. I eventually got promoted to lead the content team, and now a small group of us runs programs that would’ve required separate departments at my old company. Not because we’re stretched thin, but because the culture is built to let people operate beyond their job description.

I’ve been thinking about these two worlds a lot lately, because of AI. When I see a company hand its teams a productivity multiplier and immediately start cutting headcount, I recognize the reflex. I’ve worked inside that logic. “Do the same for less” is the default when you don’t have a growth thesis. And I’m worried that AI is giving a lot of companies permission to act on that default faster than ever. Plenty of people are asking the growth question too. But when both options land on the same leadership table, the cost cut tends to win. It’s the one you can put in a slide with a dollar figure attached.

Subscribe now

What changes when you point the multiplier at growth

I’ve always carried around more ideas than I had time to pursue. Things I wanted to write, projects I wanted to try. Not because I lacked the skill, but because there are only so many hours in a day and I also like to go home and be with my kids. Those ideas just sat there, some of them for years.

AI cleared the path for a lot of that. This newsletter is a good example. I’d been carrying the idea around for a long time, but the activation energy of writing regularly on top of everything else was too high. AI made the process of getting my thinking into something publishable realistic in a way it wasn’t before.

My team has felt the same shift. We’re a creative group with more ideas than we’ve ever had bandwidth for, and AI gave us the room to actually try some of them. We’re producing work now that wasn’t on anyone’s roadmap six months ago. Not because the roadmap changed, but because things that used to feel out of reach became possible. Problems we’d been punting on for years, ideas that would’ve died in a prioritization meeting because nobody had the bandwidth. Auth0’s culture already encouraged that kind of expansion. AI just widened the door.

The part I’m still working through

Here’s where my thinking gets less clean. Because there’s a version of this where I’m wrong, and I want to be honest about it.

Not every company is in growth mode. I know this firsthand. At Siemens, the addressable market for Shared Services wasn’t expanding. The product was stable. The customers were internal. If you’d handed my team a tool that doubled our output, I’m genuinely not sure what we would have done with the extra capacity. You can invest in quality. You can pay down tech debt. But those investments have diminishing returns. At some point, the honest answer might be that you don’t need the capacity.

And there’s a harder version of this problem that I think most people in tech aren’t reckoning with yet. What happens if AI increases productivity faster than markets can grow?

If every company in your space can suddenly produce twice as much, but customer demand hasn’t doubled, you end up in a world where surplus capacity is the norm. In that world, the companies cutting headcount aren’t being unimaginative. They’re being realistic about a market that can’t absorb what their teams are now capable of producing.

I don’t have a good answer for that. It’s possible we’re heading into a period where productivity and demand decouple in ways that make “just build more” genuinely naive advice. The history of technology is full of moments where automation created abundance that the market took decades to figure out what to do with.

Subscribe now

Before you cut

I think most companies are cutting too fast. Not all of them. Some are making hard, honest calls about markets that aren’t growing. But most of the layoffs I’m seeing aren’t that. They’re the path of least resistance. The first move, not the last resort. And once you cut, the option to explore disappears with the people you let go.

What I’d want to see, if I had any say in it, is a company that gets handed a productivity multiplier and spends one quarter asking what its team could build with the extra capacity before deciding to shrink. Just one quarter. That’s not a big ask. But it almost never happens because the cost savings are right there on the spreadsheet and the upside of exploration is speculative.

I’ve worked inside the model where optimization is the only gear, and inside a company where a small team with room to grow will find things worth building that nobody planned for. I can’t pretend to be neutral about which one I’d rather build in. But I also can’t pretend the growth answer is always right. Some markets really don’t have room. Some companies really are done expanding.

What I do believe is that most of them haven’t checked.

Then I read “Don’t become an Engineering Manager” by Anton Zaides, and it gave me the push I needed. The arguments were sharp: the tech landscape is moving too fast to step away from hands-on work, the management ladder is flattening, and the pay is often lower than what a Staff engineer can command elsewhere. I agree with most of the observations. But the article frames management as a ladder optimization, which track has better odds, where’s the ceiling lower. I think that framing leads you to the wrong answer. The more interesting question is which skills you want to be building. When you look at it that way, the conclusion changes.

Why I switched

For most of my career I was an individual contributor. I loved writing code. I thought that was all I wanted to do.

What eventually pulled me toward management wasn’t dissatisfaction with IC work. It was impact. No matter how good you get, your output as an individual has a ceiling. I’d already bumped into that once when I moved from engineering into developer advocacy, and management was the next version of the same realization. If I could enable a team to do their best work, the collective output would be far greater than anything I’d produce on my own.

When a leadership gap opened up on the content team I’d been closest to, I saw my window. I pitched myself for the role before I felt ready for it. I didn’t know much about management, but I had a genuine connection to what the team was building and enough conviction to figure out the rest on the job.

That was enough to get started. It was not enough to be good at the job on day one. But even in this first year, it’s been one of the most rewarding chapters of my career.

Subscribe now

Management is a skill decision, not a title decision

The conversation around engineering management almost always focuses on what you give up. Less time writing code. Less freedom to choose how you spend your day. A step off a technical track where demand and compensation are both high. All true.

What rarely gets discussed is what you gain. Not in title or authority, but in a set of skills that most engineers never build because nothing forces them to.

The most valuable thing management has taught me is how to communicate with precision when someone else’s work depends on it. When you’re an IC, unclear communication slows you down. When you’re a manager, unclear communication breaks your team. That difference in consequences makes you learn faster than you would any other way.

I’ll give you a specific example. A few months into the role, I was briefing a team member on a content project. I had the whole thing mapped out in my head: the structure, the angle, the audience it needed to reach. I started writing it all down, basically handing over a blueprint. And then I caught myself. I was about to do the thing I’d always done as an IC, solve the problem my way, except now I was asking someone else to execute my solution instead of finding their own.

So I pulled back. I shared the goal instead. Here’s who the piece is for, here’s what it needs to accomplish, here’s why it matters right now. And what came back was different from what I would have built. It was better in places I hadn’t considered, because the writer brought their own perspective to a problem I’d only described the shape of.

Here’s the thing: I wouldn’t have noticed that habit as an IC. When your own thinking is muddled as an individual contributor, you just iterate until it works. Nobody else has to interpret your intent. Management removed that escape hatch. If my team doesn’t understand what I’m after, I can’t quietly fix it myself. I have to actually get better at sharing the why, not just the what.

And that forced improvement surprised me by showing up everywhere else. It changed how I write, specifically. Running a content team while also writing a newsletter means I’m constantly testing whether I can articulate what I actually mean, not just what sounds right in my head. A year ago I would have drafted something, felt good about it, and moved on. Now I catch myself asking: would someone else know what to do with this? That question didn’t exist for me before management put it there.

Goals vs. tasks

There’s a distinction I think about constantly now that I never had language for as an IC: the difference between giving someone a task and sharing a goal.

Theo from t3.gg recently shared an example that captures this perfectly. He was testing whether an AI coding agent could build a competitive chess engine from scratch. His prompt: “Build a program with no dependencies that can beat Stockfish level 17.” Straightforward. The model worked for 30 minutes and came back with something that won consistently. But when he looked at what it actually built, the agent had downloaded Stockfish and used it to play against itself. Task completed. Goal completely missed.

Once he reframed the prompt to specify intent (”build your own chess engine from scratch, the goal is to evaluate whether you can implement an engine that competes”), the model understood. The difference wasn’t complexity. It was clarity about what success actually meant.

That content project I mentioned earlier? Same dynamic. When I almost handed over the blueprint instead of the goal, I was about to do exactly what that prompt did: describe implementation instead of intent. In both cases, with people and with AI, the fix is the same: share what you’re trying to achieve and why, then trust the other side to find the path.

That self-correction loop is a management skill. Noticing when the output is wrong and asking what you could have communicated differently, instead of just blaming the execution. And right now it’s becoming increasingly relevant beyond management. Every developer is increasingly managing AI agents. The better you are at articulating intent and separating the goal from the implementation path, the better those agents perform. I didn’t expect that when I made the switch. But it’s one of the things I value most about it.

The part nobody prepares you for

The skills are one thing. The identity shift is another.

My situation was a bit unusual. I became the manager of people I’d been working alongside, some of them on the same team. These were colleagues I had close relationships with. We’d shared frustrations, swapped opinions, been peers in every sense of the word.

That changes when you become their manager. Not because you want it to, but because the role creates lines that didn’t exist before. Conversations you used to be part of are now conversations you should probably step back from. Dynamics shift in ways that are subtle but real. And if you’re anything like me, you don’t love hierarchy. You resist it. I still do the work. I write. I do social listening. I show up as a team member as much as a leader, because that’s the only version of this role I’m interested in doing.

But I’d be dishonest if I said the transition was seamless. I’ve already had to make one of the hardest decisions a manager faces, and it changed how I carry the role. There’s a weight to it now that I didn’t fully appreciate from the outside. The relationships haven’t broken, but they’ve evolved. Navigating that, being someone your team trusts enough to follow while staying close enough to the work that you’re not managing from a distance, is a balance I’m still figuring out.

Nobody talks about this part when they debate the IC-versus-manager decision. The articles focus on ladders and compensation and market demand. But the actual lived experience of management is more personal than any of that. It’s about who you become when the job stops being about your output and starts being about everyone else’s.

What about the practical concerns?

None of that personal growth erases the practical reality. And the practical arguments against management right now are real.

Companies are flattening. The path from EM to Director is more competitive than it was five years ago, with fewer Senior EM roles to bridge the gap. And Staff engineers often earn more than first-time EMs when you compare across companies. Zaides mentions his friend could have made 20-30% more staying IC and switching companies. That’s a real number. I knew when I made the switch that I wasn’t optimizing for compensation. I made the move anyway because I believed what I’d gain in skills and perspective would be worth more over time than the salary delta.

But those arguments assume management is a permanent track. Most people I’ve seen do it well don’t treat it that way. They step in, build the skills, and then decide what they want next with far better information than they had before. Some stay and grow into leadership. Some go back to IC work and find themselves significantly more effective for having done it.

That’s because management develops instincts that pure IC work never forces you to build: how to align across teams, how to communicate with stakeholders who don’t share your context, how to evaluate competing priorities when there’s no obvious right answer. A former manager returning to an IC role isn’t starting over. They’re bringing tools most ICs never pick up. And they’re starting their next negotiation from a higher basis point.

Then there’s the advice to wait a couple of years until things settle. I understand the impulse. But the industry isn’t going to pause and send you a signal when it’s safe to switch. Waiting means spending two more years building one type of skill while the set of skills management develops sits untouched. And from what I can see, the skills that management forces you to build are the ones with the rising premium right now.

Take the opportunity

I didn’t have a five-year plan that said “become a manager.” An opportunity appeared that aligned with something I’d been thinking about for a while. I wasn’t ready. I pitched myself anyway.

Conviction but not credentials. That’s what I walked into that conversation with. And it turned out to be enough, not because I was secretly qualified, but because the willingness to learn the parts I didn’t know mattered more than already knowing them.

If a management opportunity is in front of you, and the idea of enabling a team and getting sharper at communicating intent sounds like a genuine challenge you want to take on, take it. You won’t be great at it immediately. I wasn’t. But the things you’ll learn about describing outcomes instead of steps, about catching yourself when your instinct is to just fix it yourself, those stay with you regardless of where your career goes next.

I’m still early in this. I’m still learning how to pull back when I want to prescribe, how to trust the process when it’d be faster to just do it myself. But I’m a better communicator, a better writer, and a better collaborator than I was a year ago, and I don’t think any of that would have happened if I’d stayed on the IC track and waited for the “right time” to make the switch.

Thanks for reading!

The full-stack developer is probably the best example. Front-end and back-end are legitimately different disciplines. The mental models don’t overlap much, the tooling is different, and the failure modes look nothing alike. But frameworks, shared languages, and better tooling created a layer that let one person operate across both sides of the stack. Not as deep as a pure specialist in either, but deep enough to hold the full picture of a feature from database to browser. For enough companies and enough products, the tradeoff was worth it, and the role stuck.

I think AI is creating the same kind of abstraction, but in a different direction. Not vertical, across the tech stack. Horizontal, across the org chart.

Software teams have been organized around specialization for a couple of decades now. Building software is complex enough that we split the work across product managers, engineers, and developer relations. Each role reflects a genuine body of knowledge that takes years to develop.

But that split came with coordination overhead we mostly stopped noticing because it became so normal. The spec that’s outdated by the time engineering reads it. The roadmap review where three teams discover they’ve been building against different assumptions. The feedback from users that takes two weeks (when lucky) to travel from the DevRel team through product and into a Jira ticket an engineer might see next quarter. The work of keeping the machine aligned sometimes dwarfing the work the machine was supposed to do.

AI is compressing that overhead faster than most org charts can adapt.

A product manager can now spin up a working prototype in Cursor or Lovable in a few hours, put it in front of users, and generate real feedback before engineering writes a line of production code. That’s not the PM “learning to code.” That’s an abstraction layer that lets someone with product judgment operate in engineering’s territory well enough to validate an idea. An engineer can take a feature they just built and generate documentation, draft user-facing copy, think through how this change should be communicated to the developer community. Not because they suddenly became a technical writer, but because AI handles enough of the execution that their understanding of the system (which was always the hard part) can flow directly into outputs that used to require a different team.

LinkedIn’s chief economic opportunity officer recently described what he called the “full stack builder” who compresses what used to take days across design, product, and engineering into a single person with AI tools. Walmart now has dedicated agent builder roles that didn’t exist a year ago, filled internally by employees who crossed traditional role boundaries. And some companies have taken it further than a new title. Boris Cherny, creator of Claude Code, mentioned on the Pragmatic Engineer podcast that everyone at Anthropic carries the same title: Member of Technical Staff. Engineers do research. Researchers write code. People move across what would be departmental boundaries anywhere else. Flat titles aren’t new, but AI has made the structure more viable by collapsing the distance between functions enough that one person, with the right tools and the right depth, can operate fluidly across them. When the horizontal abstraction layer is thick enough, the case for separate titles gets hard to make.

Subscribe now

The word “builder” is catching on as shorthand for all of this. But I think it flattens something more interesting.

What’s actually emerging is a role whose shape is determined by the product, not by the org chart.

A company building developer infrastructure needs someone whose core is engineering architecture. Someone at the staff or principal level who understands system design deeply enough that when AI extends their reach into product decisions and developer experience, they can evaluate whether the output is actually good. AI can draft a product spec, but knowing whether that spec addresses the right problem for the right user takes judgment formed by years of building and operating these systems.

A consumer-facing product might need the inverse: someone whose depth is user research and product instinct, with AI extending them into implementation. They can prototype and ship features in ways they couldn’t before. But the anchor is that they’ve watched enough users abandon a flow or misunderstand a feature that they can feel when a prototype is solving the right problem versus just looking like it does. AI handles execution. The product instinct tells it where to aim.

The horizontal abstraction layer is the same in both cases. The anchor point is different. And the anchor point is determined by what the product needs, not by which department someone sits in.

The full-stack analogy cuts both ways, though, and the uncomfortable part matters. Full-stack developers were controversial for a reason: you often got mediocre work in both domains. The same criticism will show up here. “You’ll get someone who’s a mediocre PM and a mediocre engineer, all in one convenient package.” It’s a fair concern. The difference is that AI changes the math. When the full-stack developer emerged, you still had to write the CSS and design the database schema yourself. The abstraction layer was thin. With AI, the gap between “I understand this domain well enough to direct the work” and “I can produce professional-level output” has narrowed enough to change how teams get structured. Not to zero. But enough.

And the people best positioned to take advantage of that are the ones who’ve been deep enough in at least one domain to know what good looks like across the others. A senior engineer can tell when AI-generated code is architecturally sound or just syntactically correct. A seasoned PM can see through a prototype that looks impressive in a demo but isn’t testing a real hypothesis. You don’t develop that instinct from AI fluency. You develop it from years of doing the work without shortcuts, which raises a real question about where the next generation of senior builders comes from when the junior roles that used to build that depth are exactly the ones getting compressed. I don’t have a clean answer for that. I’m not sure anyone does yet.

The career model most of us internalized, pick a specialization, go deep, move up the ladder inside that lane, is getting harder to map onto what’s actually happening. The lanes are merging. The question that matters now isn’t “what title do I want next?” It’s “what product or problem am I deep enough to own end-to-end?”

The full-stack developer proved that one person could work across the stack if the tooling was good enough. The tooling just got a lot better. And the stack just got a lot wider.

I’m navigating this shift in real time, the same as you. If you want to follow along as I figure out what this new landscape looks like from the inside, with 20+ years of context and zero pretense of having all the answers, subscribe to The Long Commit. I write weekly about developer careers, AI, and the long game in engineering.

Over the past two years, companies across the tech sector have been pulling back from hiring junior developers. Some quietly, through budget decisions that never get announced. Some loudly, as strategic positioning. The logic sounds reasonable. AI tools have made senior engineers dramatically more productive, so why invest in someone who needs six months of ramp-up when a well-equipped senior can cover the gap? It’s a clean story. It’s also, I believe, a dangerously incomplete one.

Here’s what the landscape actually looks like right now.

At the biggest tech companies, new graduates went from roughly a third of all hires in 2019 to somewhere around 7% today. In the US, entry-level hiring at the top 15 tech firms fell 25% from 2023 to 2024 alone.

The research paints an even starker picture. A Stanford Digital Economy Lab study analyzing millions of payroll records found that employment for software developers aged 22 to 25 declined nearly 20% from its late-2022 peak, while employment for those over 30 held steady or grew. A Harvard study tracking 62 million workers across 285,000 firms found that when companies adopt generative AI, junior employment drops 9 to 10% within six quarters. Senior employment barely moves.

The trend isn’t limited to quiet budget decisions either. Block cut 40% of its entire workforce just weeks ago, with CEO Jack Dorsey citing AI as the reason. Those weren’t junior-specific cuts, but the underlying logic is the same one driving this whole shift: smaller teams, more AI, fewer humans. Salesforce announced it would halt engineering hiring entirely for 2025, citing AI agents. Klarna froze developer hiring in late 2023 (then reversed course when the strategy failed). A LeadDev survey found that 54% of engineering leaders plan to hire fewer juniors, thanks to AI copilots enabling seniors to handle more.

The reasoning is consistent across every boardroom version of this story: why pay a junior $80-100K plus six months of ramp-up when a senior with AI tools can cover triple the output? The math makes sense. On paper, it looks clean.

I’ve been watching this unfold for two years now, and I believe it’s one of the most short-sighted decisions a generation of engineering leaders is making simultaneously.

I’ve been in this industry for over twenty years. What concerns me isn’t the individual company choosing to slow junior hiring for a quarter or two. It’s the industry-wide retreat happening all at once, with almost no public conversation about what it costs.

This isn’t a story about being nice to new grads. It’s about what happens to your team (the seniors you’re leaning on, the culture you’re building, the org you’re responsible for) when you cut off the bottom of the ladder and expect the structure to hold.

The weight is shifting upward

Here’s something the “seniors can do everything” crowd doesn’t talk about. Senior engineers need juniors as much as juniors need them.

Not out of charity. Out of cognitive self-preservation.

A healthy engineering team has a natural rhythm to it. Complex architectural decisions flow to seniors. Lower-risk tasks (UI tweaks, unit tests, bug fixes, small features) get delegated down. This isn’t just about efficiency. It’s a pressure valve. It gives senior engineers the space to think at the level you’re actually paying them to think at.

When you eliminate juniors and hand AI the “simple” work instead, something breaks. Your seniors don’t suddenly spend all their time on brilliant architecture. They spend it trying to keep up with an output pipeline that has no natural throttle.

Here’s what I mean. AI can produce working code. That’s not really the issue. The issue is that it produces so much of it, so cheaply, that the traditional model of reviewing code line by line simply doesn’t scale anymore. When a junior wrote a pull request, a senior could sit with it for twenty minutes, understand the intent, catch the mistakes, and teach something in the process. When AI generates the equivalent of dozens of those in a day, that same review process becomes impossible. There aren’t enough hours. There aren’t enough senior engineers. The economics that made it attractive to replace juniors with AI are the same economics that make the output impossible to properly verify at the pace it’s being produced.

This means the whole notion of how teams review and maintain quality is changing, whether they’ve acknowledged it or not. Most haven’t. They’re still applying a human-paced review process to machine-paced output, and the gap between those two speeds is where quality quietly erodes.

I’ve seen this described in a way that stuck with me: senior developers are becoming “review bottlenecks instead of innovative contributors.” They’re no longer in the creative flow of building systems. They’re auditing output from a machine that never gets tired but also never truly understands the codebase.

The tasks that used to train juniors and give seniors breathing room have been automated, but the cognitive load hasn’t decreased. It’s shifted upward, onto the people who were already carrying the most complex work. And those people are starting to wear down.

A LeadDev survey of engineering leaders found that 22% of developers are at critical burnout levels. Seniors, the ones with the most responsibility, report lower job satisfaction than juniors. A Harness survey found that 67% of developers spent more time debugging AI-generated code than expected, and 68% spent more time fixing the security issues it introduced.

I’ve felt this myself. I’ve written before about how developers rarely burn out from writing too much code. They burn out from everything that prevents them from doing it well. What’s changed is that AI has introduced a new version of that problem. The days when I’m most productive on paper (the ones where AI helped me ship the most) are often the days I’m most drained. The old bottleneck was typing speed and lookup time. The new bottleneck is judgment. And judgment doesn’t scale the way output does.

This is what burnout looks like in 2026. Not dramatic flameouts. A slow erosion. An engineer who stops pushing back in design reviews because they don’t have the energy. Code reviews that become rubber stamps. Architectural choices made by default rather than deliberation.

The people most likely to burn out are the people hardest to replace. And the thing that would relieve their burden (a layer of junior engineers to share the load, ask good questions, handle the tractable problems) is exactly what you just eliminated from your headcount plan.

The talent market is getting weird

There’s another consequence of this shift that anyone who’s hired recently will recognize immediately. The market is becoming strangely distorted.

Open a role for an engineer right now and you’ll be flooded with applications. One company reported getting 600 applications in two days for a single senior frontend position, stopping intake after they couldn’t process more. Ravio’s 2025 Tech Job Market Report found that entry-level hiring dropped 73% year over year, while overall hiring rates only dipped 7%. That gap tells you something. The people who would have entered through junior roles are now competing for whatever’s one rung up.

Many of these applicants graduated two or three years ago, built solid skills, but never got the junior role that would have given them the “mid-level” reps. They’re self-taught in the gap. Capable in ways that don’t fit neatly into traditional leveling. They’ve been building side projects, contributing to open source, doing contract work. Anything to accumulate the experience that a junior position would have provided naturally. So they apply for mid-level roles because that’s the closest match to where they actually are, even if the trajectory that got them there looks nothing like what hiring managers expect.

Now try to hire a senior or staff engineer. Completely different story. Robert Half’s research found that 65% of technology hiring managers say it’s more challenging to find skilled professionals than it was a year ago. Stack Overflow’s Developer Survey shows that 67% of senior engineers receive multiple offers before they even post a resume publicly. The pipeline of people growing into those roles has thinned, and the people already there know exactly how valuable they are. Companies are paying retention premiums, handing out counteroffers, restructuring teams around keeping their most experienced people.

This is the market that the “we don’t need juniors” strategy creates. A bloated middle where companies can’t differentiate between someone with three years of structured experience and someone with three years of scrappy self-direction. An empty top where every hire turns into a bidding war. And a growing gap between the two that nobody is investing in closing.

As one hiring expert put it: “If you don’t hire and nurture young talent now, what will your mid-level and leadership positions look like in five years? We’re heading towards some very difficult and expensive recruitment to fill that gap.”

Subscribe now

The knowledge transfer problem nobody’s modeling

There’s a cost that’s even harder to see from the planning meeting, and it’s the one that concerns me the most.

Every piece of institutional knowledge on your team lives in someone’s head. How the payment system actually works, not how the docs say it works. Why that service was split in 2021 and why you can never merge it back. The customer edge case that crashes the billing module every February.

This knowledge has always transferred through a specific mechanism: senior engineers teaching junior engineers by working alongside them. The junior asks a question that feels basic. The senior explains the answer. That explanation forces the senior to articulate something they’d never written down. The knowledge becomes shared. The bus factor drops.

When you stop hiring juniors, this mechanism stops. Not immediately. It degrades gradually, which is why it’s so easy to ignore. But three years from now, when your senior architect leaves for a role that doesn’t require them to review AI output twelve hours a day, they’re taking everything with them. And there’s nobody two levels down who absorbed even a fraction of it, because that person was never hired.

Bureau of Labor Statistics data shows that 18% of senior developers born between 1970 and 1980 plan to retire before 2027. These aren’t people you can replace by turning up the AI dial. Their value was never in how fast they typed.

The bet nobody’s stress-testing

I hear the counterargument constantly. AI will just keep getting better. The code it generates will become more reliable. The review burden will decrease. The productivity gains will compound.

And honestly? That might be true. I am not here to argue that AI won’t improve.

But I want to point out something that I think should make every engineering leader uncomfortable. The “we don’t need juniors” strategy only works if AI delivers on its most optimistic trajectory, continuously, for years, without interruption. That’s not a strategy. That’s a single point of failure dressed up as a hiring plan.

Think about what you’re actually betting on. You’re betting that AI models will keep getting cheaper, not more expensive. You’re betting that the productivity gains you’re seeing today will scale linearly as your codebase grows more complex. You’re betting that the current wave of investment in AI infrastructure will sustain itself without a correction. You’re betting that no regulatory shift, no licensing change, no market consolidation will disrupt your access to the tools your entire engineering capacity now depends on.

That’s a lot of bets. And if even one of them doesn’t land the way you expect, what’s your fallback?

I’ve been through enough cycles to know that technology productivity doesn’t exist in a vacuum. It exists inside a cycle of expectation, adoption, correction, and maturation. The technology rarely disappears. But the gap between what was promised and what gets delivered creates a window where companies suddenly need more human capacity than they planned for.

If you’ve spent the last three years hollowing out your junior pipeline, you won’t be able to rebuild it on a quarterly timeline. The talent pool you chose not to invest in won’t be sitting around waiting for your call. They’ll have left the industry, reskilled into something else, or moved to the companies that were still hiring while you were optimizing headcount.

And even in the best case, where AI continues to improve steadily, the fundamental issue remains. It’s about people, not code quality.

AI doesn’t develop judgment. It doesn’t grow into an engineering manager. It doesn’t mentor the next generation. It doesn’t notice that a teammate is struggling before it shows up in their commits. It doesn’t carry institutional memory across a decade of architectural decisions.

The question isn’t whether AI can do the work that juniors used to do. It clearly can, a lot of it at least. The question is: where do senior engineers come from if you never hire junior ones?

Every senior developer on your team got good by being bad first. They wrote terrible code that someone reviewed patiently. They broke staging environments and learned why the deploy pipeline exists. They sat in meetings they barely understood and slowly built the context that makes them invaluable now.

Someone invested in them before they were profitable.

If the entire industry stops making that investment simultaneously (which is roughly what’s happening), we’ll have a surplus of senior talent for a few years, followed by a cliff. The pipeline doesn’t refill on its own. And the people at the top of it are getting tired.

What this looks like if you actually lead through it

I’m not going to pretend the old model works unchanged. You can’t hire juniors in 2026 the way you did in 2018 and expect the same outcome. The work has changed. But cutting juniors entirely isn’t strategy. It’s surrender.

I don’t think anyone has a full playbook for this yet. But here’s where I think the thinking needs to start.

Redefine what “junior” means on your team. The entry-level work isn’t writing boilerplate anymore. It’s reviewing AI output, writing better prompts, testing edge cases, and building the judgment that AI can’t provide. The junior developer of 2026 looks different from the one you hired in 2018, and your job descriptions, onboarding, and expectations need to reflect that. Hire for curiosity and critical thinking, not just syntax fluency.

Protect your seniors’ cognitive load. If you’ve removed the delegation layer, you need to replace it with something. That might mean fewer projects running in parallel. It might mean dedicated “deep work” blocks where seniors aren’t reviewing anything. It might mean being honest that 10x output requires 10x recovery time, and adjusting expectations accordingly.

Make knowledge transfer intentional. If it’s not happening through osmosis anymore (and it isn’t), then it needs to happen through documentation, architecture decision records, pair programming sessions, and structured onboarding. This is operational work that someone needs to own.

Think in three-year windows, not quarterly headcount. The decision to not hire juniors saves money this quarter. The decision to have no mid-level pipeline in 2029 costs significantly more. Model it. Show the numbers to your leadership. Make the case.

Every generation of senior engineers was once a junior someone took a chance on. If we stop taking that chance industry-wide, we’re not just failing the next generation. We’re failing the current one, by loading them with everything, relieving them of nothing, and calling it progress.

The talent pipeline is collapsing. And it’s not the juniors who’ll feel it first.

If you’re leading a team through this shift, I’d love to hear how you’re thinking about it. Reply to this email. I read everything.

Until recently, that felt manageable. I’ve been in software engineering for over 20 years. I’ve survived the transition from monoliths to microservices, the mobile revolution, the cloud migration wave, the DevOps transformation. Each one felt significant at the time. Each one changed what we built or how we built it. But none of them changed whether we were needed.

AI does. And that’s a fundamentally different kind of shift.

The part that’s actually different this time

Every previous technology wave I’ve lived through followed the same pattern: new tools arrived, the work changed shape, and engineers adapted. You learned new frameworks, new paradigms, new infrastructure patterns. The underlying deal stayed the same. Companies needed people to build software, and if you kept your skills current, you’d be fine.

What makes AI different isn’t that it changes the tools. It’s that it changes the leverage. When one engineer with AI can do the work that used to require three, the math changes at the org level. Companies don’t just need different engineers. They need fewer of them.

I watched this play out in real time. Teams getting restructured not because the work disappeared, but because the same work now required fewer hands. Job postings that quietly raised the bar, expecting senior-level output at mid-level headcount. Entire categories of tasks (boilerplate code, documentation drafts, test generation) moving from “junior engineer’s job” to “AI’s job” almost overnight.

And the hype makes everything worse. AI is genuinely transformative, but somewhere between “this is a useful tool” and “this will replace all engineers within five years,” the conversation went off the rails. The loudest voices in the room (often the ones furthest from the actual work) started treating AI capabilities as a foregone conclusion rather than a trajectory. CEOs read a blog post about AI agents replacing entire engineering teams and suddenly that’s the planning assumption. Headcount gets cut not because AI actually replaced those people, but because someone in leadership bought the narrative that it will.

That’s the part that keeps me up at night. Not AI itself, but the decisions being made on the back of AI hype by people who don’t understand what software engineering actually involves. The gap between what AI can do today and what executives think it can do today is enormous, and real careers are getting caught in that gap.

I sat down one evening and tried to project what my career looks like in 2035, and for the first time in two decades, I had no credible model for it. Not because the technology scared me, but because I couldn’t predict which version of the story the industry would choose to believe. Not a pessimistic model, not an optimistic one. Just a blank space where the plan used to be.

That blank space is what got me moving.

I’m betting on judgment, not output

What AI can’t do (at least not yet, and I’d argue not for a long time) is exercise judgment in context.

Here’s what made it click for me. I’ve been using Claude Code lately, and it’s good. Not “neat party trick” good. Actually good. The kind of good where I ask it to build something and the code that comes back is clean, well-structured, and works on the first run more often than I’d like to admit. A year ago I could dismiss AI-generated code as a rough draft that needed heavy editing. Now? Now it writes code that looks like something I’d write. Sometimes better.

That realization forced a question I’d been avoiding: if the code itself is no longer the hard part, what am I actually being paid for?

The answer, I think, is judgment. Knowing which thing to build. Understanding why one technically correct approach is wrong for this particular team, this codebase, this set of business constraints. Seeing the second and third-order consequences of a technical decision before they show up in production. That’s where experience lives, in the space between “this works” and “this is right for the situation.”

So I’m doubling down there. On understanding business context. On learning domains deeply. On being the person who can evaluate what AI produces and say “this looks right but it’s wrong, and here’s why.” That instinct doesn’t come from tutorials or certifications. It comes from watching systems succeed and fail in production for 20 years, from understanding not just how things work but why they were built that way.

But here’s the thing about that kind of judgment: it doesn’t develop in a vacuum. It develops through building things. Which is why I still code, even though my current role doesn’t require it.

I’m working as a developer relations manager focused on content now (which is both terrifying and exciting in equal measure), so I’m not writing code all day anymore. Most of my work is writing, and I use AI to help with it. But here’s what’s interesting: AI can help me find the right words, tighten a paragraph, suggest a better structure. What it can’t do is decide what’s worth writing about, or know which angle will resonate with a senior engineer who’s been through three rewrites of the same system, or recognize when a piece of technical content is subtly misleading in ways that only someone with domain experience would catch. I bring the judgment. AI helps with the execution.

And the exact same thing applies to coding. I still code because it’s fun, but also because I’ve realized the relationship with AI works the same way there. AI can write the code. It can’t architect the system. It can’t decide which tradeoffs to make, or know that the elegant solution it just generated will fall apart at scale, or understand why the team chose a boring technology stack on purpose. The person guiding the work, deciding what to build and what not to build, evaluating whether the output actually solves the problem, that’s where experience lives.

In both cases, you learn the same thing: how to decompose a vague problem into concrete steps, how to hold a complex system in your head and reason about its edges, how to develop an instinct for where things are likely to break. It’s not a coding skill or a writing skill. It’s a thinking skill. And if you don’t have it, you can’t meaningfully evaluate what AI gives you. You can look at the output and think “that seems fine.” But you can’t see the subtle N+1 query hiding in the data access pattern, or the race condition that only shows up under load, or the security assumption baked into a convenience method.

Learn to code. Keep coding. Not because you’ll write every line yourself for the next 30 years, but because it trains the kind of thinking that makes everything else you do more valuable.

I’m building things that are mine

I used to pour everything into my employer. My professional identity, my network, my reputation, my growth, all of it lived inside one company’s walls. That felt normal. It’s what everyone around me was doing.

Then I watched a round of layoffs hit people I respected. People with deep expertise and years of institutional knowledge. And yes, their skills transferred, their experience was real, their ability to do the work hadn’t changed overnight. But something else had. The ground they were standing on vanished. The internal reputation, the relationships with leadership, the security of knowing where you fit, all of that evaporated in a single meeting. And suddenly they were competing in a market that had gotten significantly more crowded, against people with similar resumes and similar experience, in a hiring landscape where being talented wasn’t enough anymore. You had to be visible. You had to be connected. You had to be someone the market already knew, not someone it had to discover from a cold application.

That’s when I started thinking about professional gravity differently. Not as something your employer gives you, but as something you build that exists independent of any single company.

I’ve always been a writer. Blog posts, technical articles, documentation, the kind of writing that lives inside a company’s content strategy and serves someone else’s goals. But I’d stopped writing for myself. So I picked it back up, this time with a different purpose. Not as a hobby, not as a creative outlet, but as a deliberate investment. A newsletter about the things I think about anyway: engineering careers, leadership in the age of AI, the unspoken tensions of navigating a rapidly changing industry with decades of runway still ahead of you. Published thinking that shows people how I reason, not just what I’ve done. A network of people who know my perspective because they’ve read it, not because we happened to work on the same Jira board.

That same logic extends to money. Income diversification is the area where I’ve historically been the worst. One paycheck, one employer, one industry. I never seriously thought about what happens if that stream dries up, because it never did. I just wasn’t wired to think about money strategically, and I suspect a lot of engineers are the same. We talk about total comp and RSU vesting schedules, but we rarely talk about income resilience.

So I’m learning (slowly, awkwardly) how to diversify. Talks and workshops where two decades of experience becomes a product instead of just a resume line. A professional network that creates optionality for consulting if I ever need it. None of these produce meaningful income right now. That’s fine. I have 30 years. The goal isn’t to replace my salary tomorrow. It’s to make sure that if something changes suddenly, I don’t get caught with no options and no runway to react.

I don’t have it all figured out, and that’s the point

I want to be clear about the limits of what I’m sharing here, because I think the unfinished thinking is more useful than pretending I have a polished playbook.

I don’t know how to plan a technical career when the half-life of technical skills is shrinking this fast. I don’t know what engineering leadership looks like in five years, whether managers become AI-team leads or the role gets compressed because there are fewer humans to manage. I don’t know if 30 years from now, the career I’ve built will look anything like what I imagined when I started.

That used to scare me. It doesn’t anymore, and here’s why.

Every major technology shift in my career has created more opportunity than it destroyed. Not immediately, and not for everyone, but eventually and overwhelmingly. The web didn’t kill software. Mobile didn’t kill the web. Cloud didn’t kill infrastructure. Each wave created entirely new categories of work that nobody predicted from the inside.

I believe AI will do the same. The possibilities opening up right now are extraordinary. We’re going to build things in the next decade that we can barely imagine today. Entirely new categories of work will emerge, just like they always have. That’s not a threat. That’s what makes this the most exciting time to be working in technology.

But exciting doesn’t mean safe. The opportunities will be there. They just won’t show up automatically at your door.

I don’t know what the future will bring. But I know what I’ll keep doing: coding, teaching, explaining, exploring, and building. Those are the things that got me here, and they’re the things that still make me want to sit down at my desk every morning. I hope I get to keep doing them as a profession for the next 30 years. I think I will. But in the meantime, I’m making sure that if the rules change, I’m not standing still wondering what happened.

That’s the bet. I’m genuinely excited about it. I’ll let you know how it goes.

​We imagined machines would have to overpower us. We didn’t imagine we’d just let go.

For years whenever people talked about AI taking over the world, the image was always the same, Skynet, Terminator like Judgment Day. Machines rising up, overpowering humanity, forcing us into submission. The fear was physical domination, the idea that one day we would have to fight back against something stronger than us to preserve what makes us human. That story assumed resistance. It assumed conflict. It assumed that if our autonomy were threatened, we would defend it.

What is actually happening is far less dramatic and far more unsettling. There are no machines dragging our minds away from us. No system is coercing us into obedience. No apocalypse is required, no war, no conquest. Instead, we are steadily handing over our thinking because it is easier to let something else do it for us. The trade is simple: less effort, less friction, less discomfort. And most people are taking it.

I am not afraid of AI. I am far more concerned with what we are doing with it. Used deliberately, AI is extraordinary. It can accelerate research, surface alternatives you hadn’t considered, generate scaffolding that lets you work at a higher level of abstraction. I use it. I let it handle boilerplate, clean up grammar, automate the mechanical parts of my work. I am not interested in pretending the tool doesn’t exist.

But somewhere along the way, something shifted. We stopped using AI to extend our thinking and started using it to avoid thinking altogether. That shift is subtle, and I think it is one of the most important things happening right now.

​I feel this most acutely in coding because coding is the craft I care about.

I started programming as a teenager, and what hooked me was not output or efficiency. It was the struggle. Staring at a problem until it hurt and refusing to move on until it made sense. Debugging something for hours and slowly constructing a mental model of why the system behaved the way it did. It was failing, tracing the failure back to its cause, and earning understanding instead of skipping to the answer.

That friction was not an obstacle. It was the training itself. It built intuition. It built the ability to hold complexity in my head without collapsing under it. It built what I can only call taste, the sense of when a solution is right, not just functional.

Now I watch people generate code they cannot explain and ship systems they cannot reason about. If you cannot walk someone through the logic behind what you built without reopening the chat window, you did not build it. You assembled it. And over time, that difference compounds. The muscle you never use is the muscle you lose.

​But I want to be honest about something. About a month ago I hit a bug in a system I was writing. The kind of thing that, five years ago, I would have traced methodically for hours, checking assumptions, slowly cornering the defect. Instead, ninety seconds in, I pasted the stack trace into a chat window. The answer came back almost instantly. It was correct. I fixed the bug and moved on.

​And I felt something I didn’t expect: a small, quiet loss. Not because the tool failed. Because it worked. Because the hours I would have spent building a deeper model of that system simply didn’t happen. I got the fix. I missed the understanding. And I’m not sure I would have even noticed if I hadn’t been paying attention.

​That is what concerns me. Not the dramatic failures. The invisible ones.

​Now, I know the counterargument, and I want to take it seriously, because it is not wrong.

​Every generation has this panic. Socrates argued that writing would destroy memory, that people would carry knowledge in notebooks instead of in their minds, and become shallow as a result. He was partly right, actually. We did lose something. Oral cultures had capacities for memory and narrative that most literate people cannot match. But what we gained the ability to build on each other’s ideas across centuries, to accumulate knowledge beyond what any single mind could hold. It was so transformative that the trade-off was clearly worth it.

​Calculators. Google. Wikipedia. GPS. Every time, the fear was that cognitive offloading would make us weaker. Every time, the reality was more nuanced than the panic suggested. So why should AI be different?

Maybe it isn’t. Maybe this is just the next turn of the same wheel, and the people warning about cognitive decay are playing the same role Socrates played: correct about the loss, blind to the gain.

I hold that possibility genuinely. But I think there is something different this time, and it is worth articulating precisely.

​Previous tools offloaded information. AI offloads reasoning. A calculator doesn’t think about the problem for you, it executes a mechanical operation so you can focus on the higher-order question. Google doesn’t construct an argument, it surfaces sources so you can evaluate and synthesize them. These tools removed mechanical friction while leaving cognitive friction intact.

​Large language models are the first tools that remove cognitive friction directly. They don’t just give you facts. They assemble the argument. They don’t just retrieve information. They do the synthesis. The thing that previous tools left for you to do, the thinking itself, is precisely what this tool offers to handle.

​That doesn’t make it evil. It makes the question of how you use it genuinely different from any previous technology. The line between “tool that extends my thinking” and “tool that replaces my thinking” has never been this blurry.

​And I want to admit: I don’t know exactly where that line is.

This pattern extends far beyond programming. Open X and you are watching bots interact with bots while humans prompt machines to manufacture engagement. Open LinkedIn and everything sounds polished, structured, optimized, safe. Every paragraph feels assembled rather than wrestled with. The voice is technically there, but it feels synthetic. You can almost hear the prompt humming behind the sentences.

We have more expressive power than ever before, and everything is starting to sound the same. Not because people lack original thoughts, but because the tool they’re filtering those thoughts through has a center of gravity, and it pulls everything toward it.

That is not intelligence expanding. That is intelligence flattening. And the loss is not just aesthetic. When everyone’s output converges on the same median, the signal that used to distinguish deep understanding from shallow fluency disappears. We lose the ability to tell who has actually done the thinking. Including, sometimes, ourselves.

The hardest version of this problem is generational, and I don’t think my generation is equipped to talk about it honestly.

I built my intuition through friction because I had no choice. There was no tool to skip the struggle. The hours I spent debugging, the months I spent confused, the years of slowly building mental models, that was the only path available. It is easy for me to say “do the hard work” when the hard work was the only option I ever had.

Someone learning to code today at fifteen faces a fundamentally different landscape. The tool that skips the struggle is right there, it’s free, and everyone around them is using it. Telling them to artificially impose difficulty is like telling someone to hand-wash their clothes to build character. It might even be right, in some narrow sense. But it is not a serious engagement with the reality they face.

What I think we actually owe that generation is not a lecture about discipline. It is an honest framework for when to use the tool and when to refuse it. When to let AI carry the load and when to carry it yourself because the carrying is the point. I don’t have that framework fully worked out. I’m not sure anyone does yet.

But I know it matters, because the people who figure it out will develop genuine understanding. And the people who don’t will spend years producing output that looks competent while building nothing underneath it. And they may not realize what they’ve lost until they need it and it isn’t there.

Here is what I keep coming back to.

Convenience is not the enemy. It never was. The enemy is convenience unexamined, the slow, comfortable slide from “this tool helps me think” to “this tool thinks for me” without ever noticing the transition.

I use AI every day. I am not fighting the technology. I am fighting the gravitational pull it exerts on my own mind, the pull toward ease, toward letting the machine carry weight I should be carrying, toward skipping the part that feels slow and stupid and uncertain.

I don’t always win. That concurrency bug I mentioned? I lost. I took the easy path, and I chose not to go back and do the hard work of understanding that system more deeply. I’m aware of that. I chose convenience, told myself I’d circle back, and I haven’t.

So when I say most people are choosing convenience over thinking, I am not exempting myself. I am describing a gravity I feel every day. Some days I resist it well. Some days I don’t.

The difference, the only difference I can claim, is that I am paying attention to the trade. I am trying to notice when I’m drifting. I am trying to keep the thinking muscle under load even when the tool offers to carry everything.

Because the uncomfortable truth is that we imagined machines would have to conquer us to take our autonomy. We imagined a fight. We imagined resistance.

We didn’t imagine we would just... let go. Quietly. Willingly. Not because we were forced, but because it was easier.

And the most unsettling part is not that it’s happening.

It’s that most of us won’t notice until it’s already done.