Who Thrives in the Agentic Era

It's not the best coders. It's the people who know how to run things.

There's a question I keep hearing from CTOs and senior engineers: "What skills do I need to succeed with agentic development?" They expect me to say prompt engineering, or deep knowledge of LLM architectures, or some new framework they haven't learned yet.

My answer surprises them: the skill that matters most is management.

Not project management in the Jira-ticket-shuffling sense. I mean the actual craft of running things — running a project, running a team, running the process of finding a solution, quarterbacking a room full of tired engineers through a critical production incident at 2am. The people who thrive in the agentic era aren't the ones who write the best code. They're the ones who know how to lead, direct, and make decisions under ambiguity.

I know this because I've been doing it for 20+ years. And I know it because of what my last 39 days looked like.

The Numbers

Here's what the last two months of my life looked like — measured in commits across all active projects.

Read that again. In February 2026, working solo with agentic workflows, I out-committed the monthly average of a 32-person engineering organization running 40 active repositories.

And that's only a measure of my check-ins. Alongside the code, I've been operating as a fractional CTO for a SaaS platform — conducting a 35-item security audit, analyzing GCP spend, diagnosing a distributed computing failure, screening and interviewing engineering candidates, and building the first architecture documentation the platform had ever had. None of that shows up in a commit graph.

That's the real unlock with agentic development. When AI handles the implementation grunt work, you stop being measured by lines of code and start being measured by the problems you prevent and the decisions you make. I went from "write the code" to "find a strategy to onboard new clients fast" — and I had the bandwidth to do both.

773+ commits. 661+ GitHub issues. 207+ pull requests. 131,000+ lines of source code. 10 repositories. One person. 39 days.

And before the skeptic in you says "commits don't mean good code" — these aren't junk commits. They're passing CI/CD pipelines, surviving production security audits, and shipping to real users on real platforms. Volume without quality is noise. This is signal.

And notice the trajectory. January to February isn't a plateau — it's a 50% increase. That's what the ramp-up looks like when you shift from experimenting with agentic development to actually running your entire workflow through it.

The Skill That Makes This Work

Here's what I didn't do during those 39 days: sit at a keyboard writing code for 16 hours a day.

Here's what I actually did: the same thing I've done for two decades as a CTO and engineering leader.

I have a separate iTerm2 tab open for every project. Each one is its own context — its own codebase, its own Claude Code session, its own build pipeline. Throughout the day, I pop into each project, assess where things are, give direction, review output, and move on. Sometimes I'm in one for 20 minutes. Sometimes 3 hours. Sometimes I come back to it after dinner.

One day it hit me: this is exactly my old job. As a CTO, I'd drop into meetings — design reviews, architecture sessions, planning meetings, strategy discussions. I'd listen, give my perspective, make a call on direction, take some homework away, and leave. Then on to the next one. The skill wasn't writing code. It was knowing what to say in each room to keep things moving in the right direction.

That's exactly what I do now. The rooms are just iTerm2 tabs. And the team is AI agents.

What "Running Things" Actually Means With Agents

The management skills that transfer to agentic development aren't abstract leadership platitudes. They're specific, concrete behaviors that I developed over years of running engineering teams — and they map almost 1:1.

The column on the right isn't a metaphor. It's literally what I do every day. And the reason it works is because the column on the left is what I've been doing for twenty years.

Setting direction and scope. Every project starts with me defining what "done" looks like. Not in vague terms — in specific, zero-ambiguity terms. Affected files. API endpoints. Acceptance criteria. Test scenarios. The same skill I used to write design documents and define sprint goals now goes into issue specs that agents can execute without asking a single clarifying question.

Calling bullshit. This one transfers directly. When a junior developer brought me a solution that felt wrong, I'd push back — "that's too complex," "you're solving the wrong problem," "this won't scale." I do the same thing with agents. The output looks right on the surface but the approach is wrong? I call it. The implementation is drifting from the architecture? I redirect. This instinct — the ability to look at work and know it's heading the wrong direction before it gets there — isn't a coding skill. It's a judgment skill. And agents need it just as much as junior developers do.

Knowing when to pivot. Sometimes a direction just isn't working. With people, you feel it in the room — the energy drops, progress stalls, people start going in circles. With agents, you see it in the output — repeated failures, approaches that keep getting more complicated instead of simpler, solutions that technically work but feel wrong. The management skill is recognizing that moment and saying: stop. We're going a different direction. Start fresh from this angle instead.

Building institutional knowledge. One of my most-used phrases with agents is: "I never want to run into this again. Make it so we don't." With a human team, that turns into documentation, runbooks, or process improvements. With agents, it turns into skill development — custom tools, CLAUDE.md rules, pre-built patterns that prevent the same class of error from ever happening again. It's the same instinct: something burned us, now we make the system smarter so it doesn't happen twice.

Managing multiple contexts. A CTO doesn't work on one thing at a time. You're context-switching between a client escalation, a technical design review, a hiring decision, and a budget conversation — all before lunch. That skill translates directly to managing multiple agentic projects simultaneously. Right now I'm running ~4 personal projects and several client engagements. Each one gets attention, direction, and progress. The ability to hold multiple complex contexts in your head, give meaningful input to each, and keep them all moving — that's management.

Why "Prompt Engineer" Is the Wrong Frame

There's a narrative that the key skill for the AI era is "prompt engineering." With respect: that's like saying the key skill for running a restaurant is knowing how to place orders with suppliers. It's one small piece of a much bigger picture.

The developers who are struggling with agentic development right now aren't struggling because their prompts are bad. They're struggling because they've never had to run anything. They've been individual contributors their entire career — brilliant ones, often — but they've never been responsible for defining direction, managing parallel workstreams, making judgment calls under ambiguity, or knowing when to scrap an approach and start over.

The people who are thriving? Project managers who learned to code. CTOs who still get their hands dirty. Technical founders who've hired and managed teams. Military veterans who understand mission planning and delegation. People who've run anything — a team, a department, a company, a complex operation.

The skill is leadership. The tool is AI. And the people who already know how to lead are finding that they suddenly have a team that never sleeps, never gets defensive, and executes at a pace that makes traditional development look like it's standing still.

The Real Shift

I've been a CTO for over 20 years. I've built teams, hired dozens of engineers, run distributed organizations, managed multi-million-dollar projects. None of that experience is wasted in the agentic era. All of it applies — but amplified.

The gap isn't between people who can code and people who can't. It's between people who know how to run things and people who don't. If you've spent your career building the skill of getting complex work done through other people — defining what needs to happen, giving clear direction, reviewing output critically, making judgment calls, and course-correcting when things drift — then you already have the most important skill for the agentic era.

You just need to point it at a different kind of team.

Dave Shak is a Fractional CTO and Agentic Development consultant based in Kitchener-Waterloo. He has 20+ years of experience scaling engineering organizations and now helps teams adopt agentic development workflows.