Anchor your position. Let AI compound the depth.
· 11 min read
TL;DR
AI is transforming teams and organizations — but the conversation is missing something important. After a year of using Claude Code daily and watching the master-builder pattern play out around me, here’s the take I’ve converged on:
- AI gives you a choice: go wider (build across every domain, become the “10x engineer”) or go deeper (compound the depth you’ve already earned)
- Going wider works for MVPs, bounded businesses, and pre-PMF startups — but breaks at scale, where integration seams, quality drift, and plausible-but-wrong code start surfacing
- The win condition is anchoring: be the person your team trusts for the deepest answer in your domain, and codify what you know into shareable assets the team can use without having to be you
- AI compounds more for specialists than generalists — a 10× specialist becomes 30×; a 1× generalist becomes 3×. The gap widens
- Championship teams aren’t built by master-builders. They’re built by anchors who combine load-bearing depth with generous team play
Use AI to compound depth at your position — not to simulate expertise across every position.
How to spend the AI dividend
AI is genuinely transformative for organizations. The question isn’t whether to use it — it’s how.
There are two ways to spend the AI dividend: go wider or go deeper. You can go wider — build outside your specialty and become the “10x engineer” who does everything. Or go deeper — understand your systems better, write stronger code in your domain, and ship more depth per hour at the position you’ve earned.
Right now, the industry is obsessed with going wider. Single engineers shipping full-stack features in a day. Founders spinning up MVPs over a weekend. PRs spanning the entire stack. The master-builder is back, and AI is the great equalizer.
It’s seductive. It’s powerful. And it works — up to a point. But for teams that need to scale, it leaves something important on the table.
Championship teams aren’t built this way. A football team doesn’t win by having one player cover every position — it wins because each position is anchored by a specialist who’s spent thousands of reps mastering that one job, and because those specialists help each other where the play demands. Software teams that scale work the same way; AI doesn’t change that — it sharpens it. Better tools don’t turn a quarterback into every position; they make him a better quarterback.
After a year of using Claude Code daily — and watching the master-builder pattern play out around me — I’ve come around to a take that won’t be popular:
AI doesn’t make you a master of every position on your team. It makes you a stronger anchor at yours. Specialists win in the AI era — not in spite of AI, but because of it.
This is the article for the engineer who feels the pull of master-builder mode and senses something is off about it.
Why master-builder mode feels right
A quick note on the label first: “master-builder mode” isn’t standard vocabulary. I’m naming a pattern I see playing out — an operating model where engineers are expected to work across every domain because AI can fill the gaps in their specialty. If there’s a better name for it, I’m open to it.
The pull is real, and it has reasons.
Velocity is real. With Claude in the loop, a backend engineer ships a frontend feature the same day the design lands. A data engineer writes the Lambda, the API, and the dashboard around it. PRs get bigger. Tickets close faster. Standups feel productive.
And there are environments where master-builder mode isn’t just acceptable — it’s the right operating model.
1. Phase fit. Some phases reward breadth over specialization. Single-developer projects. Pre-PMF startups testing ten ideas a week. Hackathon prototypes. Internal tooling. The first six months of a new product. In these environments, breadth wins. Speed of iteration matters more than depth, and specialization costs more than it returns.
2. Scope fit. Some companies are simply bounded in a way that makes master-builder mode sustainable long term. Bootstrapped microSaaS products. Lifestyle businesses. Niche tools that may never need to scale past, say, $10M ARR. In these environments, AI-compounded generalists can operate extremely effectively — often better than teams over-engineered for a scale they’ll never reach.
For these companies, master-builder mode isn’t a temporary phase. It is the operating model.
I’m not arguing against either of those models. I’m arguing against the third case — the failure mode: companies whose ambitions outgrow master-builder mode, but continue operating in it anyway. Once a company starts aiming beyond the scale a small group of AI-assisted generalists can realistically hold — $50M, $100M, $500M ARR — the tradeoffs change. Systems deepen. Operational complexity compounds. Organizational coordination starts mattering as much as raw shipping speed. And that’s where master-builder mode starts becoming expensive. The longer a company stays in it after the business has outgrown it, the more that cost compounds.
Where master-builder mode starts to break
The failure rarely shows up as a dramatic collapse. It shows up as symptoms — the kind teams initially dismiss as normal product friction.
- Integration seams nobody truly owns. Two AI-assisted services talk to each other, but nobody can clearly explain the contract between them.
- Quality erosion in specialty domains. The accessibility audit fails. The query plan is inefficient. The S3 bucket permissions are wrong. Error handling becomes “throw and pray.”
- Velocity starts collapsing exactly when the stakes get higher. The team ships quickly for months, then suddenly takes two weeks to land a production hotfix because nobody deeply understands the system anymore. Everyone touched it. Nobody truly owns it.
- Plausible code that quietly fails at the edges. Claude writes the reconnect logic. Four engineers review the PR. It merges in an hour. Weeks later, someone discovers messages silently dropping during partial reconnect scenarios no one fully reasoned through.
The thread connecting all of these failures is the same: there’s no anchor.
AI generates code that looks convincing. But without someone who has deep reps in the domain — someone who can read the system skeptically instead of optimistically — plausible-but-wrong code makes it into production.
The reframe: become an anchor, design systems
If master-builder mode is the failure pattern, what replaces it?
Two ideas working together: anchors and systems designers.
An anchor is who you are to the team. When the problem is hard, the stakes are real, and the answer actually matters, the question lands with you. Not because of title — because you’ve built enough depth in the domain that the team trusts your judgment there.
A systems designer is how you earn that role. You’re not just shipping features in your area; you’re shaping the architecture, the contracts, the observability, the operational model, and the long-term maintainability around it. In the AI era, you also codify your depth into shareable, repeatable assets — Skills, slash commands, prompt libraries, runbooks — so the team can use what you know without having to be you. You think beyond the current sprint. The system starts bending around your influence over time, not just around your latest PR.
And this is where I think the industry is framing AI incorrectly.
AI is not what makes great engineers wider. It’s what makes strong anchors deeper. The point of giving a specialist better tools is to let them understand their systems faster, write stronger code in their domain, catch edge cases earlier, and ship more depth per hour. A quarterback with better film study becomes a better quarterback. He doesn’t become the wide receiver.
Use AI to compound depth at your position — not to simulate expertise across every position.
You can see this clearly across specialties:
- The data engineer who owns lineage guarantees, freshness contracts, warehouse modeling, and cost boundaries — not just this sprint’s SQL.
- The frontend engineer who owns the design system, accessibility patterns, performance budgets, and shared UI foundations — not just the screen attached to a ticket.
- The SRE who owns deployment topology, incident response patterns, SLOs, and operational resilience — not just the pager alert from last night.
And to be clear: anchoring is not gatekeeping. It’s not ego. It’s not “nothing ships without me.”
Anchoring is load-bearing depth combined with strong team play.
The football analogy matters here too. A quarterback who masters the position but refuses to trust the team — won’t audible, won’t trust the line, blames the receivers — doesn’t win championships. Neither does a quarterback who’s collaborative but can’t read defenses. The best teams require both: mastery of the role and generosity with everyone around them. Either failure breaks the championship dream.
Anchors work the same way. Teams move faster when someone is holding structural depth with humility — not when someone is hoarding control. Mastery without team play creates bottlenecks. Team play without mastery creates fragility.
Neither scales.
The best engineers in the AI era will be the ones who combine both in the same person.
Handling the two counters
“AI flattens the specialist advantage.”
This is the strongest version of the opposing view. It says: AI makes generalists 80% as good in any domain, so why pay specialist premiums?
Here’s why I don’t buy it. AI is excellent at the surface — generating code, scaffolding patterns, regurgitating common solutions. AI is weakest at boundary cases — the edge of your specialty, the load-bearing decision, the “why this and not that” judgment that takes a thousand hours of staring at the domain to make confidently.
Specialists hit those boundaries every day. Generalists rarely do. When AI is wrong at a boundary, the specialist sees it and the generalist ships it. The math runs the opposite way from the flattening claim: a 10x specialist becomes 30x because their context is deeper, their questions are sharper, and their ability to spot wrong answers is faster. A 1x generalist becomes 3x. The gap widens.
“But generalists become specialists.”
This is the more honest counter. It says: many great specialists started as generalists. Breadth-before-depth is a real path. AI master-builder mode is just the updated version of that path.
I’d partially concede this — and then push back on the AI version specifically. Traditional generalist-to-specialist works because the generalist accumulates pattern recognition by doing the deep work themselves, even at low velocity. They earn the pattern. AI master-builder doesn’t produce specialists, because AI does the depth for them. They ship the feature without earning the pattern. They get the artifact and skip the apprenticeship. The shortcut to depth doesn’t exist; depth is still the long way around.
Championship teams
Back to the football analogy I started with.
A wide receiver helps block. A tight end runs routes. A running back picks up blitzes in pass protection. Great teams work because every position is anchored by someone who’s spent thousands of reps mastering it — and because those specialists help each other when the play demands it.
But nobody plays every position.
The quarterback who tries to throw, run routes, block, and snap the ball on the same play isn’t a 10x player. They’re a confused player on a team that’s about to lose.
Software teams scale the same way.
Be the anchor at your position. Help adjacent domains generously — review PRs, pair on difficult problems, write the design doc, ask the uncomfortable question. But don’t confuse collaboration with pretending to have depth you haven’t earned.
Let AI compound the depth at the position you’ve already built.
The team gets stronger. You get stronger. The system scales.