The Third Path: Why the Super IC vs. Product Engineer Debate Misses the Point

The AI landscape has shifted dramatically over the past decade—from hosting tree-based models, to training deep learning systems, to now orchestrating agents via commercial LLM APIs. But the more interesting transformation isn’t technical—it’s organizational. The team structures that used to build AI products are collapsing.

Two years ago at a legal tech startup, I was Lead AI Engineer with a team of one junior developer. A traditional company would have staffed that function with 3-5 people and made me a pure manager—roadmap ownership, sprint planning, 1:1s, stakeholder alignment, maybe a Jira board to groom. Instead, I shipped.

Now I lead AI product development at a fintech. Same pattern: shipping features and systems that would traditionally require a team. In practice, it’s me and Claude Code.

The industry is calling this the “Super IC” phenomenon. But that framing misses something. I’m not a Super IC—I’m still a lead. I still own strategy, stakeholder management, and technical direction. I just also ship more now than ever, because AI removed the tradeoff that used to force a choice.

I’ve written about adjacent ideas before. If this post intrigues you, note that my thinking has evolved over time. I recommend checking out these earlier posts for more context:

The Conventional Wisdom: Pick Your Lane

Should you be a specialist, or should you be a generalist or a little bit of both? Different people have different opinions here. However, the discourse right now says AI coding tools are bifurcating engineering careers—while at the same time claiming anyone can now be a 10x engineer with AI assistance.

Regardless, you have two paths to stay relevant:

Path 1: The Super IC. Leverage AI for massive individual output. Become the engineer who single-handedly ships what used to require a team. The poster children are indie hackers like Pieter Levels ($3.5M ARR as a solo developer)¹ or the tiny teams at companies like Midjourney ($200M ARR with 40 employees)². Trade breadth for depth. Optimize for velocity.

Path 2: The Product Engineer. Own the full product lifecycle. Use AI to handle implementation details while you focus on what to build and why. Companies like PostHog and Vercel hire explicitly for this profile—engineers who “care more about outcomes and impact than the exact implementation.” I wrote about this archetype in my taste post—the hybrid professional who’s technical enough to validate AI output, design-minded enough to prioritize UX, and business-aware enough to connect features to outcomes. Trade technical depth for product breadth.

The evidence for this bifurcation is hard to ignore. A Stanford study found that employment for developers aged 20-34 has declined nearly 14% between 2022-2024, while prospects for senior engineers remain stable³. Amazon mandated a 15% increase in IC-to-manager ratios⁴. Meta’s “Year of Efficiency” eliminated 21,000 positions, explicitly asking managers to become ICs or leave⁵.

The message seems clear: pick a lane or get run over. But there’s a third option emerging—one (in my honest opinion) that refuses to accept this binary. Before I explain why it works, let’s understand why the choice ever existed in the first place.

The Flaw in the Binary

Here’s what bothers me about this framing: it assumes the IC/manager split was ever natural. It wasn’t. It was a bandwidth hack. For instance, many managers at today’s AI-driven companies still code quite a bit, but not as much as they did before becoming managers.

We, as humans, have limited hours and cognitive capacity. At some point, an engineer gets senior enough that their judgment becomes more valuable than their keystrokes. This holds true for other professions as well. So we invented the management track—a way to scale that judgment across more people. The tradeoff was that you stopped shipping. You traded direct output for leverage through others.

What AI tools change isn’t just individual productivity—they change the leverage equation that forced this tradeoff in the first place, both for technically skilled people and for other crafts like design, marketing, and writing.

Below is an attempt to visualize this evolution or shift that we are currently seeing and experiencing firsthand:

The traditional model forced a binary fork—you chose scaling through others (management) or scaling through yourself (IC). Either path had a ceiling. The AI-enabled model collapses this fork. You can now scale through both paths simultaneously because the execution bottleneck that forced the choice no longer applies.

The Third Path: The Player-Coach at Scale

Here’s what I’ve learned across two companies and five years of integrating AI into my workflow: the most interesting archetype isn’t the Super IC or the Product Engineer. It’s the technical lead who refuses to choose.

I call this the Player-Coach at Scale.

You keep the strategic context, the stakeholder relationships, and the architectural judgment that comes from experience. But you also ship—not by working 80-hour weeks, but because AI compresses what used to be a two-week sprint into a day when you have the right context.

The Player-Coach combines:

• The Super IC’s output capacity: Using AI tools to ship features and systems directly, not just review others’ work
• The Product Engineer’s strategic judgment: Understanding what to build, for whom, and why it matters to the business
• The traditional lead’s organizational context: Knowing the political landscape, the historical decisions, the technical debt that matters versus the debt that doesn’t

However, in my mind, a Player-Coach—although it may sound similar—is not a “Unicorn,” a term I’ve never liked:

And it is also not the “Renaissance Engineer,” although I’ve seen some startups use that term for people they want to hire:

And finally, it’s not about the “T-shaped” or “V-shaped” profiles, even if I’m a big fan of those metaphors:

Why the Player-Coach Failed Before

If you’re skeptical about this model, you should be. The player-coach has a terrible track record historically.

Ask anyone who’s tried it pre-AI: you end up doing both jobs poorly.

Companies loved the idea because they got “two people for the price of one.” Engineers hated it because they were perpetually context-switching between shipping and leading, excelling at neither.

The criticism was valid. Here’s why it doesn’t apply anymore:

The old failure mode: Your coding time competed directly with your leadership time. Every hour reviewing PRs was an hour not architecting. Every 1:1 was an hour not debugging. The bandwidth constraint was real and zero-sum.

What AI changes: The implementation portion of coding—the part that consumed 60-80% of development time—is now compressible. What used to take me a week of focused coding now takes a day of AI-directed development. That freed bandwidth doesn’t disappear; it gets reallocated to the strategic work that can’t be compressed.

Now that we’ve defined the Player-Coach, distinguished it from similar-sounding myths, and explained why it works now when it didn’t before, let’s see how all three paths compare below in “The Three Engineering Archetypes”:

Beyond this high-level comparison, let’s dive deeper into the skill profiles. I’ll compare them across five key dimensions:

• Output — Direct shipping capacity. PRs merged, features delivered, bugs fixed. The raw productive throughput of hands-on engineering work.
• Strategy — Product thinking and technical vision. The ability to see the bigger picture, make architectural tradeoffs, and align work with business outcomes.
• Context — Organizational knowledge depth. Understanding why systems exist, who the stakeholders are, and how decisions ripple across teams.
• AI Leverage — Proficiency with AI coding assistants. How effectively you multiply your output through prompt engineering, context management, and AI-augmented workflows.
• Leadership — People and team influence. Mentoring, code review quality, driving alignment, and elevating those around you—often without formal authority.

The radar tells the story: the Super IC spikes on output and AI leverage but craters on strategy and leadership. The Product Engineer inverts this—strong strategy, weaker direct output. The Player-Coach doesn’t win any single dimension outright, but maintains competitive scores across all five. That balance is what AI makes possible.

Toggle on the Unicorn to see the mythical ideal—near-perfect scores everywhere. It’s included as a reminder of what we’re not claiming. The Renaissance Engineer is actually quite close to the Player-Coach—both are AI-enabled, both pursue breadth across domains. The key differences: Renaissance Engineers score lower on context (60 vs 90) and leadership (60 vs 75) because they emphasize curiosity-driven exploration over organizational knowledge and coaching. The Player-Coach prioritizes strategic judgment and team elevation; the Renaissance Engineer prioritizes polymathic reach.

Note: These scores are based on my experience and observations of these archetypes across multiple organizations. They’re meant to be illustrative of relative strengths and tradeoffs, not empirically measured metrics. Your mileage may vary.

The Context Multiplier

Here’s the key insight that makes this work: context is the real multiplier.

There’s a fascinating paradox in the research. A METR randomized controlled trial from July 2024 found that experienced developers were actually 13% slower with AI tools on codebases they’d worked on for 2+ years—yet they still believed they were 20% faster⁶.

This seems like bad news for the “AI makes everyone 10x” narrative. But read it differently: AI helps most on greenfield development, boilerplate, and unfamiliar territory. It helps least when deep contextual knowledge matters most.

As a lead, I have context the AI doesn’t. I know what the team tried last year and why it failed. I know which customers are strategic and which integrations are political minefields. I know the technical debt that’s safe to ignore and the debt that will bite us in six months. I’m not just prompting Claude—I’m directing it with judgment that took years to build.

This is why context becomes the ultimate competitive advantage. Let me break down the formula:

The inputs matter more than the tool (i.e. context engineering). Give two engineers the same AI assistant—one with deep organizational context, one without—and you’ll see dramatically different outputs. Same goes for those not using the latest advancements such as sub-agents, skills, or spec-driven development (Kiro, etc.). The context-rich engineer gets production-ready code that fits the system. The context-poor engineer gets generic solutions that require extensive rework.

The Real Filter: Artifacts vs. Meetings

This reframes what’s actually dying in engineering organizations. It’s not “middle management” in some generic sense. It’s a specific failure mode: people whose output is coordination without artifacts.

What I like to think of as “The New Career Filter”—a pattern you might have experienced or seen emerge in different forms:

The filter isn’t IC versus manager. It’s: can you produce artifacts, or do you only produce meetings?

AI tools don’t eliminate the need for coordination, strategy, or leadership. They eliminate the excuse that those activities preclude direct contribution. If you have good judgment, you can now apply it directly rather than trying to transfer it to someone else through a spec document.

What This Means for Your Career

Having been around for some time now, I’ve had the opportunity to see how this plays out for different career stages. For instance, the worst thing you could do is blindly trust AI tools’ output and do “Vibe Coding” instead of “Vibe Engineering”. Then one of your peers would have to spend hours cleaning up—and you’d lose their confidence going forward.

Here’s my take:

If you’re a senior IC: Your expertise is now directly monetizable as individual output at a scale that wasn’t possible before. The question is whether you want pure IC leverage or to expand into product and strategy. The wrong move is staying a “senior IC” who’s really just a mid-level engineer with more tenure.

If you’re a lead or manager: This is the existential question—are you still technical enough to ship? Be honest. If you’ve spent five years in meetings and lost your implementation edge, you have a choice: rebuild those skills with AI as an accelerant, or double down on pure people leadership knowing it’s a shrinking niche. The coordination-only manager is dying. The player-coach is thriving.

Skills for the Player-Coach Era

Knowing the destination isn’t enough—you need the skills to get there. Here’s what I’ve found actually matters.

These aren’t the same skills that made you a good IC or a good manager. They’re a new synthesis—the competencies that let you operate in both modes while AI handles the translation between them. Click any skill in the radar to see how to develop it:

The radar captures the balance, but one quote from Addy Osmani captures the mindset:

That skepticism—calibrated, not paranoid—is what separates Player-Coaches from engineers who let AI drive.

The Uncomfortable Truth

Here’s what I’ve come to believe: the IC/manager career fork was never natural. It was a patch for human bandwidth limitations.

AI is unpatching it.

The engineers who thrive in the next decade won’t be the ones who pick between leading and shipping. They’ll be the ones who refuse to choose. They’ll have the strategic context of a lead, the implementation capacity of a team, and the judgment to know which problems deserve their direct attention versus delegation to AI.

I’ve been living this for two years across two companies. It’s not theoretical. It’s not coming. It’s here.

From V-Shapes to Player-Coaches: What Changed

Looking back at my own writing, I can trace how this thinking evolved—and why the Player-Coach feels like a synthesis rather than just another framework.

When I wrote about the V-shaped data scientist in 2024, I was grappling with a different problem: practitioners who were technically excellent but couldn’t ship end-to-end. The solution was developing breadth—understanding the full ML workflow, not just your slice. But the V-shape still assumed you had to personally build all those competencies. That takes years.

When I wrote about taste in 2025, the landscape had shifted. Vibe coding platforms were minting unicorns. Anyone could ship an app. The new bottleneck was judgment—knowing what to build, sensing what users want, making the micro-decisions that separate beloved products from forgotten ones. I argued that taste was the new differentiator.

What changed between then and now? Two things:

1. AI tools got good enough to trust with implementation. Not perfect—you still need to validate—but good enough that the “playing” part of being a player-coach is no longer a full-time job.

2. The market started rewarding people who refused to specialize. Solo founders building profitable companies alone. Tiny teams shipping products at scales that used to require dozens of engineers. Technical leaders who still ship production code. Between 2015 and 2024, solo founders rose from 23.7% to 36.3% of all startups, and 52.3% of successful exits now come from solo-led companies⁸. This trend accelerated dramatically in 2023-2024 as AI coding tools matured—the data simply wasn’t there two years ago.

The V-shape was pre-AI thinking: build the skills yourself. Taste was mid-transition thinking: judgment matters more than execution. The Player-Coach is the synthesis: your shape doesn’t change, but your reach does. You stay deep in your domain, maintain the judgment and taste that can’t be automated, and use AI to extend into execution that would have required a team.

That’s not a prediction about the future. It’s a description of how I’ve been working for two years. The frameworks finally caught up.

Further Reading

If this resonated, here are the voices shaping this conversation:

• The 70% Problem by Addy Osmani — Why AI completes 70% of the work but the remaining 30% requires human expertise
• Vibe Engineering by Simon Willison — The responsible counterpart to “vibe coding” for experienced engineers
• AI & Software Development by Kent Beck — “Augmented coding” as a framework for AI-assisted development
• Being a Player Coach by Andy Budd — The historical critique this post responds to
• How AI Will Change Software Engineering by Gergely Orosz — Industry-wide data on the shift

Footnotes

1. Pieter Levels, indie hacker and solo founder of Nomad List, Photo AI, and Remote OK. Multiple sources confirm $3M+ annual revenue with zero employees as of 2024-2025 (Starter Story, Software Growth). ↩

2. Midjourney achieved $200M annual recurring revenue in 2023 with a team of approximately 40 employees, generating over $5M per employee (CB Insights, Sacra). ↩

3. Stanford HAI analysis of US labor market data, 2024. Shows significant decline in junior developer employment concurrent with AI tool adoption. ↩

4. Amazon internal memo on organizational efficiency, requiring 15% increase in individual contributor to manager ratios across engineering. ↩

5. Meta’s “Year of Efficiency” restructuring eliminated approximately 21,000 positions, with explicit guidance for managers to return to IC roles. ↩

6. METR (Model Evaluation and Threat Research) randomized controlled trial, July 2024. Found experienced developers 13% slower with AI tools on familiar codebases. ↩

7. Tobi Lütke, Shopify CEO, internal memo 2024. Established policy requiring teams to demonstrate AI inadequacy before requesting additional headcount. ↩

8. FourWeekMBA analysis of startup data 2015-2024. Solo founders increased from 23.7% to 36.3% of startups, with 52.3% of successful exits coming from solo-led companies. ↩