Agentic coding has been a core part of my daily workflow for a while now. I wanted to give it an honest trial - no prejudices, just seeing what it can actually do through deep hands-on experience.

While assembling notes for a different blog post, I realized I had enough material for an intermediary one - a framework I’ve been using to think about agentic coding productivity.

Here’s the plan: build a simplified framework of software engineering and then throw agentic coding into the picture. Once that’s done, the fun part - poking holes in our own model to see what falls out.

Two claims I want to justify: the bottleneck is still you ¹, and agentic coding multiplies your output - it doesn’t add to it. Zero times anything is still zero.

Economics Of Software Engineering

To put it simply, software engineering is about transforming your cognitive capacity into value-generating software. That’s it. When we talk about productivity, we’re not counting lines of code or features delivered. What matters is whether the software, at the end of the day, is useful to customers.

Why state something so obvious? Because in the age of agentic coding, many outputs have become much cheaper to deliver. If we use a vague measure of productivity, we can’t have a productive discussion.

Let’s play with concrete numbers. Say your daily cognitive capacity is 20 units. You spend it on three tasks—a code review (5 units), a bug fix (5 units), a design meeting (5 units)—plus a couple of necessary-but-not-adding-value-right-away tasks like updating docs (1 unit each).

Now to name things properly. I’ll use T notation—T05 means a task of 5 cognitive units. Cognitive capacity varies over time: sleep, mood, engagement, meetings fragmenting your day. Value delivered is roughly proportional to cognitive load—with one twist: low cognitive load tasks are usually of low value on their own. Prerequisites for real work, not value-adding by themselves.

Fair warning: I won’t justify how well these concepts map to reality, and I’ll pick numbers that make my point. The goal is a useful framework, not a correct one.

To keep things simple, I’ll focus just on the execution: coding, reviewing, thinking. I’m deliberately omitting ideation, understanding user needs, team coordination—all essential, but out of scope here.

Lastly, some tasks exceed our daily capacity—even with full focus, they can’t be done in a single day. For these, we dissolve: instead of one T40, we break it into six T10 tasks. Note that the total cognitive load after dissolving is always higher than the original—you pay overhead for planning, context switching, and coordination.

How does this change with an agent?

What Agents Bring To The Table

With the framework in place, here’s the core claim:

Agentic coding decreases your cognitive load to deliver tasks.

If you put no cognitive energy in, there’s no value out.

I’m claiming the agent’s added value is a function of your invested cognitive load. Multiplicative, not additive. No matter how I’ve tried, I can’t get sensible output from an agent without being involved myself.

In framework terms: the agent reduces a task’s cognitive load by assist ratio—one that I suspect depends heavily on task complexity:

The agent only helps when a task’s cognitive load is below the agent ceiling—a rough measure of model capability. The more demanding the task, the less gain you get. But here’s the kicker: it can actually get worse. If a task exceeds the ceiling, you’ll spend more time fixing the agent’s bugs and explaining what should be done than if you’d just done it yourself.

And dissolving doesn’t necessarily save you—the overhead of breaking a task into smaller pieces can outweigh the agent’s speedup on each piece. Some tasks can’t be dissolved at all: when you need to solve the interplay between parts of a system, the solution is inherently holistic. Iterative improvements just send you in circles.

So why is it bad news? It doesn’t scale! Or to be more precise, it still scales only with your cognitive capacity—which is very much bounded. When you’ve been doing 10+ hour sessions for the past few days and have a bad day afterwards, the agent won’t save you. You’ll be just as unproductive as you would without it.

Running The Numbers

Now for the fun part: let’s put the framework to work and see what agentic coding actually does to your value added.

Take a T40 task. How does delivery change with an agent in the mix?

Without the agent, the task is too big for a single day—so you dissolve it into two T15s and four T05s, delivering in 2.5 days. For this example, let’s set the agent ceiling at 10 cognitive units.

Here’s the catch: the T15s exceed the ceiling, so the agent would hurt us there. We dissolve further—each T15 becomes five T05s. With fourteen T05 tasks and an assist ratio of 2, we finish in under two days².

Like that’s great! Two is definitely less than two and a half before. But notice: the marketed “doubled productivity” translates to only ~40% more value added. The dissolve overhead eats the rest.

Two factors at play.

First, we had to dissolve more—and dissolving always costs extra. This overhead is driven by the agent ceiling, which I expect will rise over time. As it does, we’ll speed up tasks already below the ceiling and avoid dissolving tasks that currently exceed it.

Second, task profile matters. If your work is mostly small tasks—say, ten T05s—you get the full assist ratio benefit with no dissolve overhead. A T40 that needs breaking apart? That’s where the gains shrink.

When I read posts from people claiming 10x productivity with agents and try to square it with my very different experience, I explain it this way: they’re reporting assist ratio on subset of tasks, not overall value added. Or I’m doing something really wrong and missing out on a lot of gains.

So what’s my own estimate? A nice round two. I feel roughly twice as productive with agentic coding. Of course, I sometimes burn myself out—low-productivity days are inevitable. So the 2x is averaged across everything. The real lever right now does not seem to be the agent; it’s avoiding the down days in the first place.

The Implications

Time to collect on our framework investment.

The first to come to mind: given the multiplicative, not additive, nature of assist ratio, you still need people to do the work. If you’re worried about the future of software engineering, either you’re safe—or you should be rooting for the agent ceiling to stay low.

Teams with no time to do the work are missing out the most. The gap between them and teams who can actually focus is now multiplied by whatever assist ratio you believe in.

The silver lining? This creates pressure to give engineers space to be productive. Maybe fewer meetings and less bureaucracy are in your future. Fair warning though: once you have that space, higher expectations will follow.

Who gains the most? Teams whose work is mostly tasks with small cognitive load. You get the full multiplier without the dissolve penalty.

Offload cheap cognitive tasks to the agent. They don’t add value on their own, but the agent handles them efficiently—freeing your cognitive buffer for the complex stuff. Think of pre-formatter days: manually aligning code, nitpicking alignment in reviews. Then ruff/cargo fmt/gofmt/… came along. Run a command, move on. Same principle here.

Finally, the value added gain will be small if value mostly comes from outside engineering. Imagine a business where it’s not about choosing the right database—it’s about the product correctly identifying customer needs and designing features to capture the market. Engineers will spend less time on mundane tasks, more time on architecture decisions, but the value is created elsewhere.

If nothing else, may this help you talk about productivity more… productively.

Footnotes

1. As was already established, the bottleneck is all that matters ↩

2. Just in case I lost you. There are in total 70 cognitive units to drain. Assist ratio of 2 makes it 35 units. With daily capacity of 20, it takes 35 / 20 days. ↩