Over the last 30 days, I pushed 127 pull requests. And it feels soo good for my nerdy soul 🤓
So what? Not a big deal for many software engineers. Yeah, but it’s a massive shift for a mid-level leader.
Some time ago, as a mid-level leader responsible for dozens of people, I basically didn’t code. Having only a few fragmented hours a week, spinning up a new service or contributing in any meaningful way was impossible. Whatever task I picked up would become a blocker for my people.
Being hands-off was painful. After a decade of building good-quality software, everything I developed in my late career was random scripts in Google Colab, one-line changes to my teams’ codebases, or adjustments to their build scripts.
It was too intimidating to even push it anywhere.
Today, code is no longer the bottleneck. Over the past month, I’ve contributed to production apps, built some internal tools that unload my people, went over maintenance, and fixed some bugs in someone else’s service.
I feel like I’m back in the game.
Maker vs Manager
In 2009, Paul Graham published a famous essay “Maker’s Schedule, Manager’s Schedule”, the industry bible on why engineering leaders shouldn’t code.
The split is simple: managers live in 30-minute calendar blocks, jumping from one meeting to the next.
Makers need uninterrupted half-day blocks to load the mental model and write meaningful code. A single meeting in the middle of the day destroys a Maker’s focus. Once you became a manager or director, you had to stop coding. Your calendar doesn’t allow doing that anymore.
AI agents broke that law of physics.
In the AI-first mode, your working memory is externalized into Markdown specs. You no longer need to hold a syntax tree in your head and type boilerplate. Today, a 30-minute gap is enough time to refine a specification, dispatch an agent, and let the automated validation pipeline run while you step into your next meeting.
Of course, it requires an excellent SDLC process. Fast deployment, decent test coverage, quality gates, and underlying infra that is AI-agent friendly (here’s the example setup that my teams built - the one that let me bootstrap any AWS infra resources in minutes).
But before we get into the technicalities, let’s take a step back…
Why We Still Need Managers
Whenever the industry talks about AI autonomy and flatter orgs, there is always an ask: “Why do we need engineering managers at all?”
Google tried to answer that question back in 2002 by getting rid of engineering managers entirely. It failed. Later, Project Aristotle studied 180 Google teams, 115 of them engineering. Researchers found that who is on a team matters far less than how the team works together.
The five dynamics we all know already are: psychological safety, dependability, structure and clarity, meaning, and impact.
The data doesn’t say that only managers can create these conditions. But managers are the people most accountable for them.
No AI agent will build psychological safety for a burned-out senior engineer, resolve cross-departmental politics, coach someone through a career plateau, or translate messy business ambiguity into team purpose.
We still need this human glue.
But.
End of the Hands-Off Leader
The Amazon CEO, Andy Jassy’s push to strip out management layers hits this hard (I covered the RTO side of the story in another essay).
In September 2024, Amazon set a goal to raise its individual-contributor-to-manager ratio by at least 15% by the end of Q1 2025. Roughly 14k corporate cuts followed in October 2025, and about 16k more in January 2026 (not all of them were managers, but it's worth digging into the data anyway).
Jassy’s diagnosis was that when you have too many hands-off leaders, they justify their existence by trying to “put their fingerprint on everything”.
That is the trap I see for non-coding engineering leaders today. When you are completely disconnected from implementation, your only way to “add value” is to add process. You become an information router and this is tax on your organization’s speed.
The Great Flattening in Numbers
No matter what you think of Amazon’s move, here are some numbers that touch our jobs’ security directly:
Gallup reports the average US manager now has 12 direct reports, up from roughly 8 in 2013. The median is still much lower, but the direction is clear.
And there is more:
In Korn Ferry’s survey of 15k professionals, 41% said their company trimmed management layers last year.
According to Bloomberg, in 2023, middle managers made up about 31.5% of tracked layoffs, up from just under 20% in 2018
Gallup again - State of the Global Workplace 2026 shows manager engagement at 22% in 2025, down from 31% in 2022.
In 2024, Gartner predicted that through 2026, 20% of organizations would use AI to flatten their structures, eliminating more than half of current middle-management positions.
Was this forecast valid? I recommend verifying on your own. But if you are in a managerial role, you have definitely heard the term The Great Flattening.
So if you do JIRA, play the scheduling & coordination game, and work as a Transactional Leader, it will only get tougher over time...
Uff, quite depressing, no? I have to admit I also thought several times about my own future as an engineering leader.
At the same time, the familiar feeling comes back. All of these frustration when a non-technical manager brings another “sync meeting”, ask question that were answered, and never is around when you need them.
A game of appearances, halving story points, just to make it fit into Excel. It's no surprise many orgs started optimization at the management level these days.
What’s Next for Leaders
How to stay relevant as an engineering leader these days? When I shared a screenshot of my PRs on LinkedIn, a few good questions came up.
The first about the role split:
Coding again is great until the team starts waiting on the director’s PR, and nobody wants to be the one who says it’s blocking them.
The second is about depth:
A developer who works through an AI-driven SDLC loses a big part of the deep context... Do you feel you know the codebase as deeply as when you wrote code by hand, or when the leader ships through agents, who keeps the full picture of how the system works?
Both are real traps, and it's easy to get overhyped by AI agents and walk straight into them. Here are the three rules I use to navigate my "coder's comeback":
Rule 1: Pick the work nobody wants, yet makes everyone’s life easier.
“Don’t be a bottleneck” always was, and still is, a No. 1 thing.
If your team is waiting on your PR to finish a sprint goal, you have failed.
Instead, look at the massive shadow backlog: internal tooling, operational automations, maintenance work. Nobody wants to pick these up; they rarely survive product roadmap prioritization, and if you get pulled into an emergency for two days, nobody is blocked.
A few examples from my last months of work:
Rebuilding our service catalog. The infra is already there - metadata, automations that capture critical information about all steps of the SDLC process. But the catalog was hard to use. So I defined critical use cases and rebuilt one around these. Built an API with full OpenAPI coverage, captured data from multiple sources (CI/CD telemetry, service YAMLs, cloud infra IaC), and made it consumable by both humans and AI. Getting the answer about the number of tier-0 services with outdated Docker images is now 2 clicks or one prompt in Claude Code.
Building full governance over the no-code platform. Bringing all functionalities we couldn’t get for months from our vendor (covered it as a separate story)
Bug fixing and maintenance - as a platform leader, I want to be on top of our entire infrastructure. Each morning I start by reviewing investigations over alerts from the last 24 hours. AI agents run such triage for me and point out the best candidates to fix. If a service is well covered and the fix is relatively simple, I create a PR and send it to the owning team. So far, I fixed hundreds of random errors per month that no one wanted to touch (like missing record returning 503 instead of 404 because of some hacks in the code).
Critical work is still on my best people. My job is to make their lives easier.
Rule 2: Trade deep syntax context for deep customer and product context.
Do I know every helper function in our codebase as deeply as when I wrote everything by hand ten years ago?
No.
I don’t try to improve resource consumption on our tier-0 Java services that are red hot during peak hours. Or re-architect our stack from non-relational to relational DBs to cut hundreds of thousands of dollars in costs. I work with seniors and principals who know exactly how to face such challenges.
But as a director, I know our users, business strategy, and cross-team pain points much better. I know that some of our problems don’t need deep tech solutions. They need focused mitigations.
On the other hand, I spent the first half of my career building the cleanest code I could. I truly loved the craft—but (too) much of that code brought zero value to users because I built the wrong things.
The life-changing realization came after I started practicing my Problem Solving Framework. Sometimes the root cause of hundreds of your users’ problems is a misconfigured input field. Something you can easily debug and fix on your own with an AI agent.
Rule 3: Stand on the shoulders of your Seniors and Principals.
My +120 PRs a month - I want to state it clearly - is only possible because I work with best-in-class engineers.
Earlier in the article, I mentioned our AI-native cloud infra. Playbooks, super-fast CI/CD, top-notch quality - all of that helps me get a new S3 bucket with all needed IAM roles, a new microservice, or an RDS within minutes, only via agentic prompting. I don’t even need to open the AWS console.
When building my side project, colorharmony.dev, deploying it to Cloudflare required zero interventions on the web UI. The CLI is AI agents friendly, so I only say “I want to deploy this repository to CF, let’s go”, and after few prompt the app is up and running.
My contributions across dozens of employers’ repositories are possible only because of the quality gates in place. Linters, >80% test coverage, zero compilation warnings/errors. My organization also runs an additional layer of reviews with AI built on top of AWS Bedrock (read more).
I’m back in a coding game because engineers more skilled than I made it possible.
The Catch: Getting Back to Hands-on Is Not Easy
I have to be honest: being a hands-on engineering leader is both super exciting and mentally exhausting.
On one hand, you can make tangible progress every day. On the other hand, as I wrote in The Multi-Agent Hustle, jumping between leadership meetings and five terminal tabs of CLI agents is a perfect way to fry your brain.
I still build my process. Only a few months back, my default was to run a 3-tab terminal window, either with Claude Code or Google’s Antigravity, and run three separate agent sessions:
The planner (Opus, recently Argon, usually the most expensive one) reviewed my requirements, codebase, and architecture. Once the markdown spec was ready, I switched to the second tab:
An engineer (cheaper Gemini Flash, Claude Sonnet) that took a spec and wrote code. Then ran all quality checks and created a Pull Request.
Then the third tab, a completely fresh session: “review the PR, run Addy Osmani’s
/code-review-and-quality; cross-check with twelve-factor app patterns; review with impeccable skills”.
Then the number of tabs doubled, because //sigh// obviously //sigh//while waiting for agents, I wanted to run a parallel coding process. 🙈
Today my system is a bit more structured:
Moved to Orca ADE to bring some order into agent orchestration
Scout rule on validation layer. I build gates as quickly as I build product value. Combining deterministic gates (
tsc, custom linters, unit tests) with encoded standards (architecture.md,agents.md) and multi-tiered AI code reviews.Fighting the “AI Slop”. Either by constraining agents so they stop generating bloated code, duplicated components, and repetitive, generic UIs. Or just polishing this UI until it’s as minimalistic and aligned with the design system as possible.
The flow is still in making and nuanced. In the future, I’ll open up my exact way of building.
So, Is 127 PRs the Point?
No. It’s a number I can screenshot, but it’s the least interesting part. What actually changed for me is proximity.
When I fix a 503 that should have been a 404, I’m not saving the company. But I’m seeing, with my own eyes, what daily friction looks like for the people I lead.
When I rebuild the service catalog, I’m not “adding process”, I’m removing it. The hands-off version of me could only ask about these problems in a meeting. The hands-on version can fix them.
The Great Flattening is somehow depressing because people are losing their jobs. I’m still not sure Gartner’s forecast will turn out right. But here is what I do believe: the leaders hardest to kick out of a company are the ones who stay close to the work and bring the impact, make their people’s lives easier, and still carry the human touch no agent can replace.
AI agents didn’t change what leadership is for. They lowered the price of staying close to the work.
One of the most expensive leadership mistakes is confusing progress with solving the right problem. We can mobilise talented people, execute brilliantly and still achieve very little if our original diagnosis was wrong. Perhaps the most valuable question a leader can ask before pushing harder is "what evidence would tell us we're solving the wrong problem?"