The Best AI Productivity Win I Got This Month Wasn't From Coding

I realized recently that a big chunk of my "engineering judgment" every Monday morning was really just me doing expensive manual reconstruction.

Not bad judgment. Just judgment buried under too much clerical work.

I've spent years getting good at reading the room in engineering delivery.

The Problem

You probably know the feeling if you've managed teams for a while. A sprint starts to wobble and you can sense it before the retro. A team looks "fine" on paper but you can tell they're overloaded. A repo becomes a drag on multiple teams and nobody says it directly, but you can feel the friction.

The problem is that this kind of intuition doesn't scale forever.

It works when you're close to one team. It gets messy when you're looking across several teams, several repos, several weeks of history, and a pile of GitHub events you don't have time to reconstruct every Monday morning.

That was me.

Every Monday, I was rebuilding sprint health by hand.

GitHub Issues. PR history. Workflow logs. Incident notes. Who is overloaded? What slipped? Which PRs are stale? Are we actually improving or just telling ourselves a nicer story this week?

It looked like management work.

It was mostly manual compilation.

That was the moment I started thinking differently about AI.

Not "can AI write more code for me?"

More like: why am I still doing the most repetitive part of engineering management manually?

So I built SprintSense.

What Changed

Not as an agent that runs the team. Not as a management replacement fantasy. Just as a system that does the boring part first.

It pulls GitHub Issues, PRs, Actions, and incident data. It computes the metrics deterministically. It surfaces risk alerts. Then a local model drafts the summary.

Then I do the part that still matters:

• decide what actually matters
• add context the tool doesn't know
• choose what to act on

That's the part that changed my mind about AI productivity.

The biggest gain wasn't coding faster.

It was turning about 4 hours of Monday reporting into 30 minutes of review and judgment.

That feels a lot closer to real leverage than most "look how fast the model wrote this file" demos.

What made the project more interesting is that I didn't test it on toy data.

Why I Trusted The Result

I pulled real public GitHub history. Real issues. Real PRs. Real workflow/check-in patterns. Then I transformed that into sprint and team views, ran the metrics pipeline, and layered summaries on top. I also seeded synthetic repos because public repo history doesn't naturally line up with every multi-team management scenario you want to test.

That combination was important. Real data gives you messiness. Synthetic data gives you coverage.

And real data was humbling.

Dates clustered weirdly. Repo conventions differed. Labels were inconsistent. Some assumptions that felt fine in the clean-room version broke immediately once public repo history entered the system.

Honestly, I liked that.

It forced the project to become software instead of staying a demo.

One of the biggest lessons was that the useful architecture split wasn't "model vs no model."

It was this:

1. fetch the raw data
2. compute the truth
3. let the model narrate the truth
4. keep the human responsible for decisions

That sounds almost boring. That's exactly why I trust it.

I've become more suspicious of internal AI tools that ask the model what is happening before the system has done the hard work of measuring what happened.

For SprintSense, the model doesn't get to invent DORA. It doesn't get to guess whether cycle time is up. It doesn't get to hallucinate who is overloaded.

The code computes the facts.

The model turns those facts into something easier to consume.

That distinction matters more than people think.

It also changed how I think about human-in-the-loop.

Where Human-In-The-Loop Actually Sat

I used to hear that phrase mostly in AI product talks. It often felt decorative. Here it became the whole operating model.

Human-in-the-loop showed up in three places:

• I define the rules: what counts as stale, overloaded, scope creep, and how metrics are scoped
• I review the summary: the model draft is a draft, not a decision
• I make the call: escalate, rebalance, discuss, or ignore

That's not a safety tax. That's the job.

And if you're doing management work, I think that's the right division of labor.

The other thing this project made very obvious: trust architecture matters as much as software architecture.

Why This Scaled Better Than Intuition Alone

I didn't want this turning into surveillance.

So the director view stayed aggregate-only. No per-engineer drill-down. The Senior SDM view had team tabs and patterns, not leaderboards. The junior engineer view stayed focused on personal growth signals, not comparison.

Same backend. Different abstraction levels. That's not just UI polish. That's adoption strategy.

Because once engineers think the system is there to rank them, the data gets gamed and the tool becomes political.

What I learned from all this is pretty simple:

AI helped because it made my existing judgment easier to apply across more surface area.

It didn't teach me what a risky sprint looks like. It didn't magically make me a better manager. It just stopped wasting my time on the clerical part between "the signals exist" and "I can act on them."

That feels like a more mature use of AI than a lot of what we celebrate right now.

I think we are still over-crediting AI for code output and under-crediting it for decision support. The glamorous demo is "the model wrote the feature." The useful reality is often "the system saved me three hours of reconstruction and helped me focus on the only part I actually needed to do myself."

Not AI replacing experience.

AI helping experience scale.

Discussion

I'm curious how other people are seeing this.

If you're using AI in engineering workflows, where are you actually getting the best leverage right now?

Is it still mostly coding?

Or are you starting to find the bigger wins in planning, reporting, review, measurement, and the rest of the SDLC around the code?