Months Without Writing a Line of Code: How I Measure My Output

I haven’t written a line of code by hand in months.

That’s not an exaggeration. All the code is generated by AI — several different coding agents take turns, all committing under the same git identity. What I do is break down tasks, write task briefs, look at results, judge right from wrong, and decide whether to merge.

That raises a very practical question: how do I know whether this day, or this week, went well?

1. The old yardsticks are all broken

First, the ones that no longer work:

• Commit count. About three-quarters of my commits are produced automatically by machines: auto-repair, generated files, translations, scheduled tasks. Reporting commit counts looks padded, internally and externally.
• Lines of code. AI can generate two thousand lines at once or delete two thousand lines at once. Line counts have no stable relationship with value.
• Git author. Every agent commits under my identity, so the author field can’t tell “who wrote it.”
• Busyness. I can spend a whole day talking to agents and end up merging nothing.

These yardsticks used to roughly work because “writing” itself was expensive, so how much you wrote broadly tracked how much you did. Now that writing costs almost nothing, that correlation is gone.

2. The new yardstick: deliverables only

I now look only at deliverables:

• which pages and features shipped;
• which production problems were fixed, and whether data proves they’re actually fixed;
• which PRs were merged, and what they solved;
• which rules, skills, and tools were written to make future work faster or steadier.

The reporting language changed with it: write “orchestrated AI to produce X,” not “I wrote X.” That isn’t modesty; it’s accuracy.

My daily log got shorter as a result: no more than 200 words, 3 to 5 items, in business language about “what got solved,” with no commit lists and no plan for tomorrow. If 200 words can’t hold it, I’m listing process instead of stating results.

3. Ask where it went, not how hard it was

I set myself a rule: judge a day only by where its output went, not by how tired I am.

A whole day of odd jobs, answering questions, and firefighting can be exhausting, yet if none of it moved the most important thing forward, the day scores nothing. Conversely, a day with only one thing done — if it was the most important and hardest thing — is a good day.

So every morning I pick the single “most important and hardest” item and do it first; everything else comes after. Tiredness isn’t evidence. Direction is.

4. The real bottleneck is “verify, collect, push, merge”

The most surprising finding after a few months: the bottleneck isn’t writing; it’s everything after.

For a while, my unpushed local commits climbed from a hundred-something to three hundred-something and then past four hundred. Not because I was lazy, but because AI pushed the cost of “writing” close to zero while “verifying, collecting, pushing, merging, shipping” got no cheaper — and it all piled up at me.

That changed how I think about output: written doesn’t count; merged, shipped, and proven effective does. So now I:

• set a convergence line on parallel work — after each batch, merge and delete first, then start the next;
• open a PR as soon as local CI passes, so finished work doesn’t sit on my machine;
• hand off whatever verification can be handed off to scheduled tasks and automation, keeping human attention for judgment.

5. So what is my skill, exactly?

If I don’t write code, where does my skill show? My current answer is three things:

Orchestration. Breaking a fuzzy requirement into tasks agents can complete independently, drawing clear boundaries between them, and knowing when to parallelize and when not to.

Review. Judging whether what the agent returns is actually right. That’s harder than writing: its report always says “all passing,” and I have to know when “all green” isn’t evidence.

Methodology. Turning every correction and every incident into a rule, skill, or automation so the same mistake isn’t made twice. This part compounds.

None of the three show up in commit counts.

6. What it forced me to admit

This yardstick has its uncomfortable parts:

• Not writing code doesn’t mean not needing to understand code. Review requires reading it; when something breaks, I need to know what to ask. My weak spots (git, for one) didn’t disappear; I just fill them in a different way.
• Low-output days are more visible. “Spent the day coding” used to feel like output in itself; that cover is gone now.
• Measurement has to be honest. What machines produce can’t be counted as my workload — but organizing the machines to produce it is my work.

Closing

When writing is no longer the bottleneck, the yardstick for output has to change from “how much was written” to “what was delivered.”

Look only at deliverables, ask only where the output went, treat verify-collect-push-merge as the real bottleneck, and locate your skill in orchestration, review, and methodology. This yardstick won’t make me look busier, but it makes it much clearer what I actually got done.