Raising Expectations When Working With Coding Agents

In my software factory series, I want to make higher expectations concrete. If coding agents can multiply what we achieve, then at least doubling our output is a bar worth discussing seriously.

I screened 523 repositories for OpenSaaS and consumer open-source applications and identified 200 contributor identities with sustained activity: at least three mainline commits in at least 19 of the 25 complete weeks in each of two periods, July–December 2025 and January–June 2026. Each engineer is compared with themselves. I took their best six consecutive weeks from the first period and compared that commit count with their own best six consecutive weeks from the second, always within the same repository.

Yes, I know counting GitHub commits is a shitty metric… But I don’t know a better practical starting point for comparing my own output over time. If you do, I want to hear it.

Dex Horthy discusses 2–3× gains in his talk at 10:13. I used that as a reference point for a deliberately modest threshold of at least 2× in this commit-count comparison. Personally, I think 10× is a perfectly reasonable ambition for this metric.

Coding agents were already available in 2025, so this is a comparison with an earlier version of ourselves, without assuming when anyone adopted them. Only 8%—16 out of 200—at least doubled their commit count.

If at least 2× is the expectation, widespread doubling does not show up even in this imperfect measure. I want us to start discussing that bar as a community; I do not take it as an established industry norm. We have work to do in defining higher expectations and learning how to meet them. That gives us something more useful to pursue than repeating that “engineers are cooked”: showing what we can achieve when we change how we work.

Define what should improve

For my own work, raising expectations means doing more useful work in the same human time, with at least the quality I delivered before coding agents. I would look for improvement in three dimensions:

• Throughput: more accepted work completed with the same human effort.
• Quality: more reliable, maintainable software, with fewer defects and less rework.
• Impact: better outcomes for the people using the product and the business behind it.

My starting expectation is higher throughput without lowering the other two. If I choose to spend the saved time on reliability or a more valuable problem, I want to be able to show that improvement too.

Find and scope meaningful problems

Faster implementation also raises expectations about how I find and define the work. The existing stream of tasks may no longer supply enough meaningful problems to use that capacity well. I cannot control every product decision or organizational constraint. I can help colleagues, take on a broader range of tasks, and discover problems within the areas I already work on. Defining those problems and narrowing their scope are skills I need to keep developing.

That means practicing continuous problem discovery. I need more input from application users, other developers, and the product and business side, with less time between noticing a problem, discussing it, and checking a possible solution. User feedback can reveal friction I never see in a ticket. Colleagues can point to recurring engineering problems, while product conversations can explain which obstacles matter most to the business. A broader, shorter feedback loop gives me more problems worth considering. My job is to turn that input into work with a clear scope: who is affected, what needs to improve, and which manageable change would let us check whether we helped.

I would never advise treating the job as doing exactly what I am told and closing the laptop. I expect myself to help find and define more meaningful work to take on. If I keep the same task pipeline and only make implementation faster, I need less work to produce the same result. As expectations rise, that contribution can look smaller. Taking responsibility for discovering and scoping the next useful problem needs to become part of the work itself.

Measure progress against your own baseline

I would rather start with an imperfect measure I understand than rely on feeling productive. The baseline should let me check whether the improvement I intended actually happened: more useful software, less human effort, stronger reliability, or better user outcomes. I want to compare my work with my own earlier work under conditions I understand.

Apply this to an iOS consumer app

Throughput

I would look for more accepted improvements reaching users in the same human time: fixing a broken flow, making an existing feature work offline, or completing maintenance that keeps getting postponed. I would compare similar kinds of work with my earlier output and include the time spent reviewing and verifying the result.

Quality

I would expect fewer crashes and hangs, fewer memory problems, and reliable behavior through backgrounding, interrupted requests, and poor connectivity. Important flows should work with VoiceOver and larger text. Automated regression checks can help protect those behaviors. If I spend the saved implementation time on these improvements, I should be able to point to the problems I removed and check whether they return.

Impact

I would look for more users finishing onboarding, successful sign-ins without retries, or fewer support requests about a recurring problem. I would define the outcome before building, instrument the relevant flow, and compare results after rollout, using comparable groups or a controlled rollout where practical. A larger diff does not tell me whether anyone benefited.

For example, repeated reports of failed sign-ins could become a focused investigation into what happens when a request is interrupted. I can agree on the problem with product colleagues, scope a fix, verify it under poor connectivity, and check whether users encounter fewer failures after release. That connects problem discovery, implementation, quality, and impact in one piece of work. The next round of feedback tells me whether it helped and what still needs attention.

Keep raising your own expectations

For me, this is primarily about setting higher expectations for myself. I want reference points for how much useful work I deliver, its quality and impact, and the human effort it takes. Looking at those dimensions together helps me see where I have improved and where I need to change my approach.

I want to keep comparing my work with my own earlier work, raising the bar, and acting on the gaps I find. Making Human Attention the Priority looks at the effort behind those results.