92% of developers now use AI coding tools, per GitHub's developer survey. Your engineers can generate a working feature branch in a fraction of the time it took two years ago. Code output is up across the board.

Here's what's becoming clear: the engineers who will struggle most in the next two years aren't the ones who can't code. They're the ones who can only code.

AI automated the execution layer. The thing most engineers spent a decade getting really good at. And the skills that now separate your strongest contributors from everyone else? No one was hiring for them three years ago.

If you're an engineering leader figuring out what to invest in — for yourself, your team, your hiring rubrics — these are the three that matter most right now.

AI compressed the bottom of the stack. Writing boilerplate, translating specs into code, scaffolding CRUD endpoints — handled by tools. Even architecture and systems thinking are being done surprisingly well by AI that can ingest entire codebases.

What's left at the top isn't technical. It's judgment. Communication. Business instinct. The ability to look at what AI could build and decide what it should build.

These three skills are where your team's leverage lives now.

AI handles more of the "how." That means your engineers own more of the "what" and the "why." More conversations with PMs, designers, and stakeholders. More nuance. More frequency.

The key word: proactive. The bar isn't "communicates when asked." It's "surfaces the right information before anyone has to ask."

The engineer who spots a dependency risk mid-sprint and flags it in standup before it blocks the team. The one who drops a Slack message to the PM: "Found something during implementation that changes the scope — here are two options." That's who every team needs more of right now.

Why this matters more than ever: speed of output is outpacing speed of alignment. Your team ships faster than ever. If they're not communicating tradeoffs as they go, you get features that shipped on time but possibly solved the wrong problem.

This includes decomposing ambiguous problems. The engineer who takes "we need better onboarding," breaks it into discrete technical problems, and communicates that breakdown with clear tradeoffs in Linear or Jira? 3x more valuable than the one waiting for a perfectly scoped ticket. Decomposition without communication is just thinking out loud. The skill is doing both.

Harvard research backs this up: when companies adopt AI tools, junior developer employment drops roughly 9–10% within six quarters. Senior employment barely moves. The difference isn't just technical — seniors translate ambiguity into clarity for themselves, their teams, and their stakeholders.

This is the biggest mindset shift. For years, engineers were shielded from business context. PM wrote the ticket. Engineer built the thing. Someone else measured whether it mattered.

That model is breaking down fast.

When your team can build three versions of a feature in the time it used to take to build one, the bottleneck isn't capacity anymore. It's deciding which version to build. That requires engineers who understand the customer, the revenue model, and why this quarter's bet matters more than that one.

The best engineers right now aren't waiting for prioritization to be handed to them. They're shaping it. "I know we scoped this as two sprints, but if we cut X, we ship in one and still hit 80% of the business value — here's why." That's not a PM skill anymore. That's an engineering skill.

This changes how engineers review AI output too. The most important review question isn't "is this syntactically correct?" It's "does this solve the problem we care about?" Engineers who think in terms of impact catch what pure code review misses: the feature that works perfectly but targets the wrong user. The optimization that's elegant but doesn't move the metric in Amplitude.

The question isn't "did I ship it?" It's "did it move the needle?"

The tooling landscape shifts under your engineers' feet every quarter. The framework they mastered six months ago has a new competitor. The AI coding tool they built their workflow around just got leapfrogged by something better.

The engineers thriving right now aren't the ones who picked the right stack. They're the ones who can switch stacks without losing a step.

The curious engineer isn't waiting to be told "we're migrating to a new tool." They've already been exploring it. They spent 20 minutes poking at a new API because it looked interesting — and came back with an approach nobody else considered. They asked "what if I automated this?" and built a GitHub Actions workflow that saves the team 6 hours a week.

Curiosity also defends against complacency. When AI writes more of the code, it's easy to stop asking questions and start rubber-stamping PRs. Curious engineers don't do that. They poke at the output, wonder if there's a better approach, dig into why the AI made a particular choice. That questioning instinct keeps quality high when speed isn't the constraint.

The engineers clinging to "we've always done it this way" are falling behind fastest. Not because their approach was wrong but because the half-life of any specific technical approach just got a lot shorter.

Same shift across all three skills: value moved from execution to judgment. From reactive to proactive.

Your strongest engineers in 2024 shipped the fastest. Your strongest engineers in 2026 communicate before anyone asks, understand the business impact of what they're building, and stay curious enough to keep adapting as the ground shifts.

Still hiring primarily for coding speed and algorithmic problem-solving? You're optimizing for a world that's already gone.

The tools write the code now. Your engineers need to be the ones who decide what's worth building.

In your next round of 1:1s, give each engineer direct feedback on where they stand across these three skills — proactive communication, business acumen, and curiosity/adaptability. Be specific. "You flagged that dependency risk before anyone asked — that's exactly the kind of proactive communication I want to see more of." Or: "I'd love to see you push more on the 'why' behind what we're building, not just the 'how.'" Name the skill.

Tell them where they're strong. Tell them where to grow. Then ask: "What's one thing you explored this week that wasn't on your task list?" Make it clear these skills matter as much as shipping code.

Want something covered? Hit reply and tell me. I love hearing what you’re dealing with.

📬 Reply back to this email to book a 30 min session (free for subscribers!)

The best engineers aren't the fastest coders anymore — they're the ones who communicate, think in terms of impact, and never stop being curious. Invest in those three things, and the tools will handle the rest. 🚀

Until next time,

Sabeen 🐝

P.S. The Harvard study on AI's impact on junior vs. senior developer employment is one of the most important datasets out right now for anyone making hiring decisions. Worth reading the full paper. And if you're new here — welcome! Every issue is one framework you can use with your team this week. 👋