I Built an Autonomous Coding Agent That Clears My Backlog

I run a small portfolio of products alone. Not a big empire — a few paid apps, a marketing site, a couple of side bets that pay for themselves. The problem with running several things solo isn't the work you're doing right now. It's the work you're *not* doing: the backlog. The pile of "I'll get to it" tickets that quietly rots while you pour everything into the one thing that's on fire this week.

At one point I counted 143 open tasks across four repos. I know because I went through and counted. Most of them were not hard. Dependency bumps, a copy fix, a missing empty state, a flaky test, a webhook that needed a retry handler. Small, boring, un-blocked work that any competent developer could clear in twenty minutes. I just never had twenty free minutes forty times in a row, and every time I looked at the list it felt worse than the last time.

So I built a thing to do it for me. It's called NoteMee-AI, and this is the honest version of what it is, what it does well, and where it still very much needs me in the loop.

What I actually built

At the core is an **autonomous coding agent** that drains a task queue. You put tasks in — from a notes inbox, a GitHub issue, a Telegram message, whatever — and it works through them one at a time using a headless Claude model. It reads the relevant code, makes a plan, writes the change, runs the tests, and opens a diff for review. Nothing merges without a human clicking merge. That constraint is deliberate and I'll come back to it.

Three things make it usable rather than a demo:

**A Telegram clarification loop.** The single biggest failure mode of an AI dev agent is charging ahead on a bad assumption and producing confident, plausible nonsense. So when the agent hits genuine ambiguity — "which of these two config files is the source of truth?" — it doesn't guess. It pings me on Telegram, asks the question in one line, and waits. I answer from my phone while I'm in the queue at a coffee shop. It continues. This one design decision moved it from "toy that produces plausible garbage" to "thing I trust with real production repos."

**A co-pilot bridge.** The same Telegram channel is two-way. I can message the agent directly — "what's the status of the Stripe webhook task?", "add a task to fix the mobile nav", "show me the diff for #82", "run the test suite on the API repo." It's a chat interface to my own backlog and codebase, from anywhere. Most of my task triage now happens on a walk or between meetings, not in front of a screen.

**MCP connectors.** The agent connects to my stack through the Model Context Protocol. Each **MCP connector** is a typed doorway into a real system — the repo host, the issue tracker, the notes database, the deploy logs. MCP is what stops this from being a chatbot that only knows about text I paste into it. It can read the actual current state of the things it's changing, which is most of what "context" means in practice.

Tech stack: Claude for reasoning, MCP for plumbing, Telegram for the human loop. Nothing exotic. The value is in the orchestration and the guardrails, not any single component.

A day in the life of one task

Here's a real one, lightly anonymised. I'll show you the whole thing because the detail is what's convincing.

**Ticket:** *"Signup confirmation email links to the old domain."* Priority: low. Age: three weeks sitting there untouched.

The agent picked it up from the queue. It searched the repo, found the email template and the environment variable that set the base URL, and noticed the variable was defined in two places with different values. That's the exact ambiguity that used to produce confident wrong answers from agents. Instead, it messaged me on Telegram:

> *"Two BASE_URL definitions — `.env.production` (new domain) and `mailer.config.js` (old domain, hardcoded). Make mailer read from env?"*

I replied *"yes"* from my phone. Ninety seconds of my time.

It made the change, removed the hardcoded string, added a test asserting the confirmation link matches the configured domain, ran the full test suite, and opened a diff. I read the diff that evening — four files, all sensible, all exactly what I would have done myself — and merged it. Total human time: under three minutes, spread across a day, none of it pulling me out of deep work.

Multiply that by a few dozen small tickets a week and the backlog stops being a source of ambient dread. That's the whole pitch.

What I learned about where autonomy works (and where it doesn't)

I went in optimistic and got recalibrated fast. Here's my honest read after running this on real repos:

**Autonomy works well for** well-scoped, verifiable tasks. If a change has a clear definition of done and something the agent can check itself against — a passing test, a matching string, a type that compiles — it is genuinely reliable. Dependency updates, small bug fixes, copy changes, adding test coverage for existing behaviour, mechanical refactors. The boring backbone of every backlog.

**Keep a human in the loop for** anything that touches judgment. Architecture decisions. Anything security-sensitive. Changes where "correct" depends on business context the code doesn't contain. And critically, **reviewing every diff before merging** — I read every single one. The agent is a fast, tireless junior developer who never gets bored and never calls in sick; it is not a senior engineer, and treating it like one is precisely how you ship subtle nonsense to production.

And the bigger honesty: **it does not do distribution.** It won't find your customers, write the post that resonates, or decide what's actually worth building. It clears the backlog so I have the hours to do those things. That's the trade — and it's a genuinely good trade — but it's not magic and I won't sell it as magic.

The last lesson, maybe the most important: **the clarification loop matters more than the model.** A slightly less capable model that asks good questions before acting beats a more capable one that guesses confidently and acts. Humility, engineered in as a constraint, is the actual feature.

How you can try it

I'm opening a founding beta, and I want design partners more than I want signups. Not people who like the idea — people running real repos with real messy backlogs who'll tell me where it breaks.

Tiers:

• **Solo — £29/mo.** One person, a handful of repos. For founders exactly like me.
• **Pro — £79/mo.** More repos, more concurrent tasks, priority on the queue.
• **Agency — £199/mo.** Multiple clients/workspaces and seat management.

There are **5 founding-member spots** at a permanently locked-in founder rate. Founders get a direct line to me, input on the roadmap, and honest feedback from me when their repo teaches the agent something new.

If your own backlog is quietly rotting while you ship the urgent thing for the fifth week running — I'd genuinely like to point this at it and see what happens. **Comment below or DM me** and I'll get you set up. Tell me your messiest repo. That's the one I want to see it clear first.

I'll keep building in public and posting the honest version — what works, what doesn't, and what embarrassingly fails in ways I didn't anticipate. This is early. That's the point.