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.