Quarterly Performance Review for me (and my agents)

Intro

We finished Performance Reviews at Standard Metrics. It's been a great couple of quarters.

When I think of performance, I always think of data analysis. Whereas not everything can be explained with numbers, I do try to put a lot of effort on substantiating career conversations with real metrics (for me and my team).

I thought I'd share some of the key insights that seemed interesting.

Some things in this post are expected, some are happening all around, and it seems like we are all discovering them from first principles. Our industry is evolving.

I can't share everything in detail, but I'm happy to share the trends that I saw while looking at our engineering metrics this cycle.

Self-review

Working with agents is clearly working for me. I'm able to sustain performance during planning season and shipping more foundational or complex software "solo".

No more planning dip

Q2 2026 was the first full quarter where I went all in on agents, and I've been feeling a lot more productive (every body says that).

After going thru my metrics, my career narrative, our project's releases, and narrative for Q1 and Q2 fr the team, and looking at the agent's metrics, I confirmed that I am definitely being more effective.

However, what I liked the most is that my productivity drops less during "planning season" (the planning period at the end of a quarter and beginning of the next).

My Productivity Quarter over Quarter.

I've been using Claude Code for a looooong while. According to Claude Code itself, my first token was a week and a half after the first public research preview opened.

But it didn't become my "daily driver" until December 2025 after Opus 4.5 was released. Before that, I usually would code one part myself and give a smaller, self-contained part of the work to the agent (that and tests 😉).

By the middle of Q1 2026, I started experimenting with different workflows and harnesses. I wanted to move away from "baby sitting" the agent.

I tried all the usual suspects: Amp, Gemini CLI (Now dead), Codex, Open Code, Kiro, and Jules. I really liked the spec-first workflow of Kiro and the "hands-off" / PR-first approach of Jules. But for the most part, I always went back to Claude Code. It just gets me.

At the beginning of Q2 2026 we had a goal to embrace agentic coding, so I went down the rabbit hole to figure out what that meant for me and our team as we build software.

I wrote about that here and here.

It's clearly working. I'm able to sustain performance during "planning season". I'm also shipping more foundational work and more complex software "solo".

Code Reviews

I'm doing more code reviews. We all are. Reviews help everyone on the team to stay aligned. But as I was looking at the metrics, my average number of reviews had stayed relatively stable. Even during planning season. I went all the way back to Q3 2024, and the trend stayed almost the same.

My theory is that reviewing PRs is a counterweight, as seniority goes up and the number of projects and engineers go up, your own productivity goes down, but the number of reviews you do for the team goes up.

Reviewed vs Merged QoQ.

Except my ratio went from 5:1 to 3:1 at the end of Q2 2026. That is to say, for every PR that I create, I used to review five PRs for the team. Now it's only three, and it's trending towards 2.5.

Time to merge and PR size

Not everything is golden. Time to merge went up for everyone in the org. The main culprits were PR size, volume and review time (back and forth between engineers and agents).

Here's mine:

Cycle-time was up, and stayed up until we consciously managed it.

I used to merge PRs within the hour of publishing them. That little bump in December is due the holidays. But other than that, it wasn't even noticeable. The story changes mid Q1 and gets pretty bad in Q2.

Here's Claude's visualization based on my PRs:

Diff size, QoQ. Sorted by size, largest first. Square root scale.

The size of PRs was much smaller back when I was "handcrafting" the code. As I started using agents more and more, the size of the PRs ballooned.

Agents are great at writing, but they tend to be very verbose and need guidance (style-guides, skills, and steering) to produce high-quality, easy-to-review code.

It's not a surprise for anyone that's been working with agents. It seems we are all trying to figure out how to make the recent models less verbose (see here and here).

I had to consciously manage it, forcing the agents to work on smaller "specs". It has had positive effects on PR sizes. Back in Q1 I would have bigger specs that I would have the agents implement directly. Ballador tries to parallelize as much as possible when orchestrating the work, and each agent gets its own smaller part of the spec, which forces them into smaller, more atomic pieces of work.

Internal skills like "dual review" (adversarial agentic review), "fix pr comments" and specialized "local review" skills, helped make sure that the reviews go smoother too. By the time a PR is ready for review, most of the stylistic and best practices are already baked into the code.

All in all, 100% net positive. I highly recommend it.

My Agents' review

I've been working with my orchestra of agents for the past three months in four different real projects:

1. Project A: Is a small, greenfield project (Python 3.14). A small calculation library that uses Polars. Fully developed by agents.

2. Project B: Is a TypeScript project. It's still relatively small and includes infrastructure code, documentation, scripts, and the service itself. It was started by humans, but now it's mostly my agents.

3. Project C: Is a mix of Python and TypeScript. It's much bigger than Project A and B. It has different modules, but everything is around a single domain. It's 100% serverless backend code. It integrates with Project D. This is mostly my team and our agents.

4. Project D: Is a large project. It's a modular monolith, most of which is Python / Django. Its frontend is a NextJS / TypeScript application. It also includes a dev CLI, a little bit of infrastructure code, and a lot of documentation. This is our main codebase. All the engineering organization contributes to it.

I instrumented Ballador to be able to track success rates, time of the task, number of "steering messages" that it sends to agents, etc.

These are the key insights.

Comparing model performance

Small Tasks

For small "one-shot" tasks, the performance of all the agents is very similar. There's no much difference regardless of the project size, model family, or effort settings.

On average, all these tasks take from 1 to 5 minutes.

Time to finish a small task successfully. All "one shot", virtually no steering.

Data from codexbar shows that the cost of Claude-family models is 10x compares with the others, thus not worth it.

I've been telling Ballador to give more work to Amp and Antigravity because of that.

Medium Tasks

This is where things start getting interesting. The code-base matters a lot more, especially for steering. Latest models need less steering and finish faster. I took a deeper look at the data because some results didn't feel quite right.

On average, these tasks take from 10 minutes to one hour.

Time to finish a medium. These take from 10 minutes to one hour.

These tasks will require steering very often after agent reviews and when Ballador is verifying the agents' work. Still, all agents finish their work successfully in a reasonable amount of time.

Here I like Gemini 5.6 Flash. It's fast, cheap, and requires a minimum amount of steering. I've had good success with all the "5 family" Claude models too. Fable and Opus both "one shot" these tasks and are relatively faster than others.

That Opus 5[1m] high looks off, right? More on that in a sec.

Larger tasks

I've been trying to avoid large tasks. If you see my PR size in Q1 and time to merge at the end of Q2, it started getting out of control. Bigger PRs mean a longer time to merge. It's just hard for engineers to review them.

These tasks take anywhere from five minutes to 45 minutes. They require steering, but fewer than medium tasks because I'm using bigger models. Steering happens more often when the codebase is complex or when the task spans more than one repository.

Time to finish a large task successfully. These go anywhere from five minutes to 45 minutes.

I've been consciously avoiding them with Ballador (see Q2 here). The models are quite capable of shipping them, but they're tough for human reviews (even with reviewer minions).

We've started the practice of building these big tasks and then having the agents slice them into smaller "stacked" PRs.

Gemini 3.6 Flash in High is really impressive at this. Unfortunately, it's not available for the enterprise tier, so Fable is the next best option (the very expensive best option). All the others required at least one steering interaction.

Anyway, my lesson learned here is just stay away as much as possible.

Task size distribution

Just for context, this is how the task distribution looks for all projects:

Task distribution per project.

Two call outs:

1. A lot of the work for Project (A) is unestimated. By the time I added instrumentation to track metrics in Ballador progress in that project was very advanced. Claude was still able to approximate values based on PRs.

2. I've effectively stayed away from huge PRs completely for Project (B)... so far.

Impact of codebase complexity

These two charts helped paint a full picture and helped me understand why the time for different agents seems to fluctuate so much.

Time by project

First, time by project and task size:

Time by project and task size. Agent reviews shown in yellow.

The time goes up as the codebase gets more complex. Agent Reviews (yellow) also take longer, which means steering and fixing issues add to the overall time it takes for the agent to be "done". Finally, our "code quality" skills also find more issues that the agent needs to address on its own before publishing a PR.

Just like humans, agents benefit from simplicity.

Size calibration

Second, "task size calibration".

I do "story point" calibration "team by team" to have a better understanding of how story points (from Linear) translate to actual development time (in Github). I track the "delta" between the "scales" our teams use.

My team uses 1, 2, 3, and 5 for estimating tasks. For us "a 2" takes 2x more than a one, 3 takes 2.9x more, and 5 takes 3.9x more. It's not perfect, but it's monotonic and close to proportional. Our team is very well calibrated.

Here's the agents' size calibration by project:

Time by project and task size. Agent reviews shown in yellow.

The complexity of the codebase acts as a multiplier of the time (and cost) it'll take agents to build a project.

For our most complex codebase, medium tasks take 5x more than small tasks and large tasks take 7.5x more. So, it's not linear.

Steering and reviews behave in the same way. In simpler projects, when the agent goes off, steering back into track takes fewer iterations.

My worst tasks took up to 5 iterations and from 32.8 to 68.1 minutes. The biggest offender was 7 iterations and took 1.4h (Project D).

Closing the loop

Again, all in all, a solid quarter. Q3 is already interesting and performance is looking better than Q2 one month in.

The lessons for me are:

1. Limit the scope of the tasks. That's always best. 💯 I'm going to continue advocating for this.
2. If you can't, then stick to the bigger models. Have agents split the work for human reviews after the fact. 🥞
3. Break down the projects in parallelizable streams of work that don't depend on each other. Ballador does this for me. 🤖
4. Experiment and find what works for you. Instrumentation is important 😉 measure what works and what doesn't.

Now, back to the Opus 5[1M] High-effort medium tasks that seemed to take an awful lot of time. It was a series of independent, but related tasks in our more complex code-base. And it "one shot" all of them.

BUT, it didn't trust Ballador's spec, and it went deep into the code to understand it. The series of tasks included a set of integration tasks between two projects, and so it verified the contracts were correct instead of just focusing on its own work. It drove the average for that model way up. That 5.5x weight had a big impact even though it wasn't that many tasks. It ended up being more expensive than the Fable medium tasks in the same repo.

Now, coffee time. After a solid quarter, we've earned it.

Coffee Time: Morgan's Flash Brew Iced Coffee

Method: Hario V60 (Flash Brew)
Brew time: ~3min

Grind: Medium-fine
Ratio: 1:15 - 20g coffee for 300g total (120g ice + 180g hot water)

Steps

1. Pre-wet the paper filter with hot water to pre-heat the Hario V60, then make sure to dump out the rinse water.
2. Add 120g of filtered ice (about 4 solid cubes) directly into your carafe.
3. Add 20g of medium-fine coffee to the dripper. Give it a gentle shake to create a flat bed.
4. Start your timer and pour 50g of hot water (205°F) in a spiral from the center outwards to bloom the coffee. Let it sit for 40 seconds.
5. At the 40-second mark, pour the remaining 130g of hot water in a heavy spiral to bring the hot water total to 180g.
6. Let the brew drain completely over the ice. Give it a swirl to melt any remaining ice and serve over fresh ice.

Perfect for summer. ☕️❄️

Here's the step by step on Morgan's website: Flash Brew with a Pour over