Power of Eloquence

Mastering the Art of Technical Craftsmanship

Receipts, Not Vibes: How to Ask an Agent to Audit (and Finally Finish) Your GitHub Backlog

| Comments

Generated AI image by Gemini Nano Banana

TL;DR — Experienced engineers don’t lack ideas. We have backlogs of half-finished repos that life got in the way of. AI agents now make it realistic to finish them, but only if you can tell what’s actually done. I asked an agent to audit all 70 of my own GitHub repos against hard evidence of agent work, not my memory and not README vibes. It came back with 40 repos carrying receipts, 30 without, and an honest list of leftovers that didn’t fit the story I wanted to tell. Below is the protocol, the prompt, the real numbers, and why a classified inventory beats a highlight reel — whether you have a career break or just one evening a week.

Over twenty-plus years of software engineering, I’ve amassed, to date, over 70 (not 60 - as per my original post claim earlier in the year) personal repos on GitHub. (Yes, that many — and that’s with forks excluded, plus my private repos mentioned in this article)

Scroll through them and you can read my career like tree rings. Plenty started life as learning side projects: a new language, a framework I wanted to get my hands on, a kata to keep my skills from going rusty. Others were genuine pet-project ideas of my own, the kind I was properly excited about the night I typed git init.

The trouble is how many of them stopped halfway.

Not because the ideas were bad. Because life happened. A demanding day job, family, and all the commitments that come with both. Every evening on the laptop was an evening not spent on something (or someone) else. For most of my career, the advice for staying sharp was some version of just build things — good advice for a 23-year-old’s calendar. Somewhere past the twenty-year mark, it quietly turns into a trade: self-learning versus lifestyle. Lifestyle usually won, and rightly so. The half-finished repos just kept piling up.

And suddenly.

Two things changed at once. I was on a career break mid-year of 2026, and AI agents have finally become good enough to do serious work. For the first time, I can go back through that ‘backlog’ and actually either finish or enhance those projects, in a span of time that would have been unthinkable a several years ago prior to AI-era. jukebox-aurora, an Angular jukebox I’d left on Angular 5 for years, was on Angular 19 with a working build again after a cloud-agent Phase 1 — work that used to mean a month of evenings I never had.

Here’s my claim, and the rest of this post is the evidence for it. Agents don’t replace taste. They don’t decide what’s worth building, and they don’t own the judgement on whether it’s any good. What they do is compress execution — enough that you no longer have to choose between learning and living.

But.

“I’ve been building heaps with AI lately” is a vibe. Vibes don’t survive an interview, and they certainly don’t survive your own honest scrutiny six months later. So before I said anything about my own work, I wanted receipts.

Why I didn’t trust my own memory

When I sat down to take stock of what I’d actually built with agents over the past year or so, my first instinct was to just list it from memory. The expense tracker rebuild. The Java toy robot. That language app. A handful of others.

Then I tried to count, and realised I had no idea.

Memory is a terrible source of truth for this. It over-weights the projects you’re proud of and the ones you’ve recently blogged about. It forgets the half-finished branch from four months ago. And it happily blurs “I used an agent for a bit of boilerplate” with “an agent did most of this”. If I’m going to point at a portfolio and call it evidence, the evidence has to come from somewhere that doesn’t flatter me.

This is the same theme I keep circling back to in this blog. In Context Engineering, it was the quality of what you hand the model. In Dont Let AI Dull Your Edge', it was not outsourcing your judgement. In From Roadmap to Repo, it was that plans are cheap and receipts are not. This post is the Saturday-night, applied version of all three: an audit you can re-run, and a portfolio you can actually point at.

The method: six steps to receipts

Here’s the protocol. None of it is clever prompt poetry. The skill is in the grounding — telling the agent exactly what counts as evidence and refusing to let it fill gaps with enthusiasm.

1. Point the agent at a source of truth

Give it your GitHub account, not your recollection. Default-branch commit history and pull requests are the record. Explicitly tell it not to use anything you’ve said about your projects in previous chats, or anything it “remembers” about you. If your agent has memory features, this matters more than you’d think — it will happily repeat your own highlight reel back to you as if it were a finding.

2. Define evidence before you ask anything

This is the step most people skip, and it’s the whole game. For my scan I used Cursor as the tool under audit, so evidence meant one of three concrete things:

  • The commit author is Cursor Agent (cursoragent@cursor.com) — a cloud/background agent made the commit.
  • The commit message carries a Co-authored-by: Cursor trailer — IDE agent work I accepted and committed.
  • There’s a pull request from a cursor/ head branch.

Not a README that says “built with AI”. Not a vague recollection that “I think Cursor helped with the tests”. If it isn’t one of those identities in the git record, it doesn’t count. Swap in your own tool’s fingerprints (Claude Code, Copilot and friends all leave different marks), but write them down before the audit runs.

3. Force a full inventory — including the empty rows

Ask for every owned, non-fork repo. Every single one, including the ones with no evidence. This sounds like busywork, and that’s exactly why it matters. A highlight reel is what you get when you let the model (or yourself) choose what to show. The “No evidence” rows are what keep the rest honest. They also tell you something useful: which projects predate your agent workflow, and which ones you built some other way.

4. Classify with explicit rules

Don’t let the agent invent its own categories. I used four:

Class Rule
Completed A substantial slice shipped — a new app, a modernisation, or a finished phase
Enhanced Agent work on an existing product, not a rewrite
In progress There’s an open cursor/ PR
No evidence None of the identities from step 2

The rules are deliberately boring. Boring rules are re-runnable rules. If I scan again in six months, I want the same definitions so the numbers mean something.

5. Demand the limitations

Every audit has blind spots, and you want them stated up front rather than discovered when someone asks a pointed question. For mine, the obvious ones were:

  • It searched default branches only, so work on abandoned feature branches is invisible.
  • If co-author trailers were disabled for a stretch, that work looks human.
  • Work done with other tools (Claude, Copilot, plain ChatGPT copy-paste) doesn’t register as Cursor evidence at all.

Asking the agent to list these is a small thing, but it changes the tone of the whole report. It stops reading like a sales pitch and starts reading like an audit.

6. Ask the career question last

Only after the inventory is complete and classified do you ask the question you actually care about:

Given the hours I really have, which three are portfolio-grade now, which three are one Saturday from done, and which should stay frozen?

Order matters here. If you ask “what’s portfolio-worthy?” first, the model will go looking for things to praise. Ask it last, against a complete and honest table, and it has to reason from the evidence instead of towards a flattering answer.

The prompt skeleton

Here’s roughly what I pasted. It’s short on purpose — the structure does the work, not the word count.

Audit my personal GitHub account {user}.

Sources of truth: default-branch commits and pull requests. Do not use my memory.

Count as Cursor/agent evidence only if:
- author is Cursor Agent (cursoragent@cursor.com), or
- message contains Co-authored-by: Cursor, or
- there is a cursor/ head branch PR.

Classify every owned, non-fork repo as:
Completed | In progress | Enhanced | No evidence.

Completed = a substantial slice shipped (new app, modernization, or finished phase).
Enhanced = agent work on an existing product, not a rewrite.
In progress = open cursor/ PR.
No evidence = none of the identities above.

List all repos, including No evidence. Quote sample commits/PRs.
State search limitations.
Then recommend, given ~one evening a week: 3 portfolio-grade, 3 next Saturdays, 3 to freeze.

A quick walk through why each block is there. The sources of truth line stops the agent leaning on anything I’ve told it before. The evidence block is the definition from step 2 — without it, “agent-built” becomes whatever the model feels like. The classification rules make the output comparable across runs. “Including No evidence” and “Quote sample commits/PRs” are the two lines that force receipts: if it can’t quote a commit, it can’t claim the class. “State search limitations” gets you step 5 for free. And the recommendation line comes dead last, with my real time budget baked in, so “portfolio-grade” is judged against one evening a week rather than a fantasy calendar.

Strip any one of those lines and you’ll see the output get vaguer and more complimentary. Touch wood, that’s the most useful thing I learned from the whole exercise.

The worked example: 70 repos, one honest table

I ran this against my own account, awongCM, on 10 September 2026 (at the time of doing the code audit). Forks excluded, that’s 70 repos I own — some going back to as far back as 2013! I have accumulated my learning/pet project repos over the years since then but, as life goes on and gets in the way, they never got finished.

The headline:

  • 40 repos with Cursor evidence
  • 30 repos with none

And of those 40:

  • 28 completed
  • 5 in progress
  • 7 enhanced

My gut said maybe a dozen. Forty was higher than I’d guessed — and the thirty empty rows were a sharper correction than the forty filled ones. See the snapshot of my Cursor-generated canvas report below.

The Cursor canvas from the audit: 40 / 70 with agent evidence, 30 empty rows, and where the commits actually landed.

Where the receipts were heaviest

Three repos stood out, and interestingly they each represent a different way of working with agents.

mindyourlanguage — 67 cloud-agent commits. This is the one where the agent did the most autonomous work: commits authored by Cursor Agent itself, not co-authored in my editor. It’s a Chinese–English phrase learner I started because I wanted something I would actually use — Web Speech TTS, a phrasebook, practice history, CEDICT refresh, and a Render deploy — not another tutorial dictionary. I kept product taste and the practice UX for myself; I handed the background agent the long autonomous stretches: Phase 3–5.5 implementation, Render/npm CI fight fixes, and the CEDICT import plumbing.

expense-savings-tracker — 141 IDE co-authored commits. The opposite pattern. Almost all of this was me in the IDE, steering an agent turn by turn and committing with the Co-authored-by: Cursor trailer. It’s also a modernisation rather than a greenfield toy: an Expo React Native + TypeScript app on Supabase, reworked behind a repository pattern with swappable data adapters, and later grown a Next.js web front end in the same monorepo. One hundred and forty-one commits is a lot of evenings — but it’s a lot fewer evenings than it would have been without the agent. I’d would say it took about 12 weeks of weekend evenings roughly to finish, alongside dveloping my with other AI pet projects running in the background during my career break - which was really enjoyable and fun process overall. It’s not just working on the mobile app alone only, but also I have tentatively completed my personal finance dashboard app (first iteration) on top of this repo as well. NB: this repo is marked as private. Apologies in advance it is not for public viewing.

java-toy-robot — 23 agent commits and 16 cursor/ PRs. The PR-driven pattern. Here the agent worked on branches and I reviewed pull requests, which is the closest of the three to how I’d run agents in a real team. It sits on my Java comeback track — the same accountability habit as From Roadmap to Repo, just on a smaller kata. The sixteen PRs walked Phases 2–4 in slices: file input, package restructure, injectable table, CI, edge-case tests, CLI errors, README polish.

Three repos, three different collaboration styles: autonomous background agent, pair-programming in the IDE, and branch-and-PR review. If I’d listed my work from memory, I’d have lumped them all together as “built with AI”. The receipts show they’re genuinely different skills.

Modernisations and salvages, not just demos

One thing the classification made obvious: a decent chunk of the “Completed” and “Enhanced” rows weren’t new projects at all. They were old repos I’d reopened and dragged into this decade — upgraded tooling, typed codebases, working builds where there used to be a broken npm install.

tv-show-angularjs went from a dated AngularJS TV-premieres browser to Angular 19 against the TVMaze API, with Render and CI on top. go-slackbot got salvaged onto modern Socket Mode instead of rotting as an abandoned intent. weather-widget-editor left its old stack for Vite, React, and TypeScript.

That’s the bit that surprised me most, emotionally speaking. Some of those repos had been sitting untouched for years, the kind of project you feel faintly guilty about every time GitHub shows it in your list. An agent didn’t just help me build new things; it gave old ideas a second life in a couple of evenings each.

The honest leftovers

And then there are the rows that didn’t fit the story I wanted. I’m including them on purpose.

  • hello-claude-world — clearly AI-assisted, but it’s Claude, not Cursor. Under my evidence rules, it’s “No evidence”. Correctly so.
  • copilot-models-testing — same story, but Copilot.
  • cashflow-forecasting — this one stung a little. It’s my TypeScript/LangGraph cash-flow forecasting engine, and it looks agent-built to anyone reading the code. But there’s no Cursor trailer, no Cursor Agent author, no cursor/ branch. So it lands in “No evidence” too. Looking back at the history, most of that work was me plus Claude Code (and a later “added cursor mcp” commit), not Cursor’s co-author trailers — so under these evidence rules, the empty row is correct. NB: this repo is marked as private. Apologies in advance it is not for public viewing

It would have been very easy to quietly move cashflow-forecasting into the “agent-built” pile. It’s one of my more serious learning projects, and it’s part of how I talk about what I’ve been working on. But the whole point of defining evidence up front is that you don’t get to overrule it when the answer is inconvenient. If I want that repo to count, the fix is to record the work properly going forward — not to edit the audit.

The other 27 “No evidence” repos are mostly what you’d expect: older projects from before I worked this way, learning repos, a few experiments built entirely by hand. None of that is a failure. It’s just a different era of the same journey.

Against “~one evening a week,” the audit’s closing recommendation came out like this:

Portfolio-grade now

  1. mindyourlanguage — public, deployed, and the densest cloud-agent receipt trail
  2. expense-savings-tracker — the heaviest IDE co-author trail, plus a web dashboard on top of the mobile app
  3. java-toy-robot — small enough to explain in an interview, with sixteen reviewable cursor/ PRs

One Saturday from done

  1. jukebox-aurora — Phase 1 (Angular 5→19) merged; Phase 2 Spotify still open
  2. depot — Phase 0 stabilize merged; Phase 1 Rails 7.2 / Hotwire / Render still open
  3. py-grawler-tool — crawl + search API merged; Phase 2 browser frontend still open

Freeze for now

  1. go-ping-imgur — open cursor/ PR, but a thin CLI not worth the next evening
  2. 3d-image-gallery-css3 — modernization PR open; low career signal relative to the others
  3. The long tail of pre-agent learning repos (ls-ruby-wrapper, ruby-game-of-life, and friends) — keep them public, stop feeling guilty

I agreed with the spine. I overruled one emphasis: for a public hiring conversation I’d swap expense-savings-tracker (private) for ecommerce-api or ml-gladiator on the portfolio-grade list, and keep the expense tracker as the private proof of sustained IDE pairing. That’s the judgement the audit is supposed to leave with me, not with the model.

The full inventory lived as a Cursor canvas beside the chat — seventy rows, filters for Completed / In progress / Enhanced / No evidence — rather than a public URL. The numbers above are what matters; the canvas was the working surface.

The career case (earned, not claimed)

Here’s where I’ll put my hiring hat on for a moment.

Nobody hiring a senior engineer in 2026 is going to sit and watch you type. What they’re increasingly trying to work out is something harder: can this person ship working systems with agents, and still own the judgement? Can they tell the difference between a diff that’s correct and a diff that merely compiles? Do they know when to hand work off and when to keep it?

A graveyard of tutorial clones doesn’t answer that. Neither does “I use AI every day” on a CV. Both are noise.

What does answer it is something like this:

  1. A classified inventory — here’s everything I own, here’s the evidence of how it was built, including the bits that don’t flatter me.
  2. Five to eight running apps you can actually open, click through, and talk about in depth.
  3. A clear story of the different ways you worked with agents — autonomous, pair-programmed, PR-reviewed — and why each repo got the mode it did.

That combination says more than any line on a resume. It says you can deliver, and it says you’re honest about how. In banking and financial services especially, where I’ve spent most of my career, that second part matters a lot. “Trust me, it works” doesn’t pass a change review, and it shouldn’t pass a portfolio review either.

And here’s the part I keep coming back to: this is career capital you can grow without taking a sabbatical. One evening a week, aimed properly, compounds. The audit tells you where to aim.

Concluding thoughts: life, not hustle

I want to be careful about how this lands, because there’s a version of this post that’s just another productivity sermon. Use agents and you can ship three apps a week! That’s not the point, and honestly it’s not how I want to live.

And to be clear about one thing: please don’t take a career break just to do this. Mine happened for its own reasons, and the backlog work is something I’m doing during it, not the reason for it. Stepping away from paid work so you can spin up a fleet of agents and push your repo completion rate towards 100% is optimising the wrong number. A portfolio with forty “Completed” rows nobody can explain in an interview is just a bigger graveyard. The audit is meant to make you more selective — three portfolio-grade apps you genuinely own beat thirty you merely supervised.

The point is smaller and, I think, more useful. The gap between “I have an idea” and “there’s a working repo” used to be measured in weekends I didn’t have. Now, for most of us, it can be measured in evenings we do. The next idea doesn’t have to cost a cancelled weekend or another night of only-half-present on the couch. It can just become a repo, at the pace a full life allows.

Keep the learning loop. Keep building. But stop treating your lifestyle as the tax you pay for curiosity — and when you do build, keep the receipts.

Thus, my challenge to you: paste the prompt above, point it at your own account, and see what comes back. I’d genuinely love to hear how your numbers compare (and which inconvenient leftovers you found).

Till next time, Happy Coding! Keep Learning and Growing! 👨‍💻

PS: The audit only works because the tools leave fingerprints. Cursor’s Co-authored-by: Cursor trailer and Cursor Agent commit identity are what made “agent work” searchable instead of vibes; GitHub’s commit and PR search did the rest. If your tool of choice leaves a different mark, write that mark down before you run the scan — otherwise you’re back to memory.

Comments