Writing code was never the bottleneck

Most developers use AI to write code faster.

That framing makes sense on the surface. You describe what you want, the AI writes it, you review it, you move on. The productivity gain is real. The context switch is still there. But writing code was never the bottleneck.

But writing code was never the bottleneck.

Think about what actually interrupts your day when you’re building something.

A CI pipeline fails on a test you didn’t touch. You stop what you’re doing. You open the logs, read the error, diagnose it, fix it, push again. That’s 20 minutes gone, not because the fix was hard, but because you had to be the one to do it.

A pull request comes back with review comments. You address them one by one. Some are nitpicks, some are architectural, but you handle all of them the same way: by stopping and switching context.

A merge conflict appears. You resolve it manually, making sure the intent of both changes is preserved.

None of these problems require creativity. They require attention. And attention is what you can’t get back once it’s gone.

Attention is what you can’t get back once it’s gone.

For the past few weeks I’ve been building Readplace, a read-it-later app. The app itself is straightforward , a browser extension that saves articles, a web app that organises them. It will serve as the shell from my personal reading system I’ve been running for 10 years and got me almost half a million karma on Reddit.

What’s less straightforward is how I built it.

Every pull request in the repository triggers a set of GitHub Actions workflows. Claude runs as an agent inside each one — not as a coding assistant I talk to, but as part of the pipeline itself.

Here’s what the version 1 of the workflow fires on every PR:

claude-PR-code-reviewer.yml — reviews the diff, leaves inline comments, flags issues by severity.

claude-PR-CI-failure-fixer.yml — when CI fails, reads the logs, diagnoses the failure, pushes a fix commit. Includes an attempt counter to prevent infinite loops.

claude-PR-code-review-auto-apply.yml — takes the high and medium priority comments from the review and applies them automatically. No manual intervention needed.

claude-PR-conflict-fixer.yml — detects merge conflicts, resolves them, commits.

claude-listener.yml — listens for @claude mentions in PR comments from contributors, reads the context, takes action.

At the time of writing, the Actions tab shows over 1,800 workflow runs. Most of them are Claude. The architecture has one principle that took me a while to land on: prompts are files, not strings.

Prompts are files, not strings.

Every Claude instruction lives in a .md file next to its workflow — claude-PR-CI-failure-fixer.md, claude-PR-code-reviewer.md, and so on.

This matters for the same reason that configuration should be separate from code. When the behaviour needs to change, you edit the prompt file. You don’t touch the YAML. You don’t escape strings. You get a clean diff that shows exactly what changed in the instruction. Each trigger asks claude to read that file using its Read tool.

Version-controlled prompts behave like version-controlled documentation. You can see the history of how you’ve shaped the agent’s behaviour over time. That history turns out to be useful.

There’s something worth being honest about here.

The workflows don’t always get it right. The CI fixer occasionally misdiagnoses a failure. The auto-apply sometimes makes a change that needs to be reverted. The conflict resolver works cleanly on most merges and occasionally needs a human to step in.

None of this is a problem. The expectation isn’t correctness — it’s reduction of load. If the CI fixer handles 95% of failures without me touching them, I’ve recovered most of that attention. The one I need to handle manually are not worse than the twenty I used to handle manually.

This is the same reasoning behind the Priority Matrix in bug triage. You’re not trying to eliminate every interruption. You’re trying to move most of them out of the critical path.

Not every interruption needs your attention.

The effect on how you work is subtle but real.

When a CI failure fires, the default is no longer “I need to deal with this.” The default is “Claude is dealing with this.” You check the result when it’s done, the same way you check a build log. If the fix looks right, you move on. If it doesn’t, you step in. Sometimes close the PR and start over after adjusting the context.

The cognitive difference between handling an interruption and reviewing a result is real and large. One requires you to stop. The other doesn’t.

The whole workflow is open source at github.com/Readplace/readplace.com.

The workflow files are in .github/workflows/. Each .yml is paired with a .md prompt file. The setup requires one thing: an ANTHROPIC_API_KEY in your repository secrets and a PAT_TOKEN (due to some Github limitations on comment triggering subsequent workflows). Everything else is in the files.

The app (Readplace) is free for the first 100 users. It’s a read-it-later tool for people who actually read what they save. The full story behind it, including the 10-year reading system that became its foundation, is coming next.

Writing code faster is a reasonable goal.

Not being interrupted while you write it is a better one.

If you liked this, you might like readplace.com, built for exactly this kind of reading.

Thanks for reading. If you have some feedback, reach out to me on LinkedIn, Reddit or Github.