I can't code. My 3,600-star open-source app is written entirely by AI agents — here are the quality gates that keep it honest
I am a product manager. I cannot write code — not "I'm not very good at it", I mean I could not ship a working feature if my life depended on it. Git is something I learned along the way, from an AI, while building this.
And yet: I maintain an open-source desktop app with 3,600+ GitHub stars, 59 releases, 34 contributors, and a UI translated into 10 languages. Every line of it was written by AI agents. My job is requirements, decisions, and acceptance. The agents do architecture, code, tests, and releases.
This post is not "AI is magic, anyone can do it." AI-written code fails in predictable ways. What makes this work is not the agents — it's the gates. Here is the actual system, with the receipts.
How it started
I had a personal problem: over the years I had starred hundreds of GitHub repos and could never find any of them again. GitHub's star list is a reverse-chronological wall; search matches names, not "that tool that turns webpages into Markdown."
During a hackathon weekend, a tool called bolt.new was free to use. I described what I wanted — sync my stars, let AI tag and categorize them, semantic search — and it started writing code. The prototype was ugly, but it worked: my star list organized itself, and I could search it in plain language.
So I kept going, entirely on free AI tiers, rotating providers as quotas ran out. (That constraint later became a product decision: the app is BYOK and provider-agnostic. It binds to no vendor because its author never could.)
The part nobody believes: the quality gates
"Vibe-coded" projects have a reputation: fine demo, collapsing codebase. The reason mine hasn't collapsed is that nothing merges without passing an automated pipeline that is stricter than what many human teams run. The main CI job is literally named Quality gates:
- Architecture boundary check — a custom script enforces the frontend's layering rules, so an agent can't quietly tangle the codebase.
- Release-file tamper block — contributors (human or bot) cannot edit version numbers or the update feed in a PR. Only the release bot may. An agent tried; the gate said no.
- Plugin registry validation — the community plugin registry is semantically checked on every PR.
- An i18n completeness gate — every PR is diff-checked for missing translations and hardcoded UI strings across all 10 languages. Agents love hardcoding strings; the gate loves catching them.
- Lint, typecheck, full test suite, production build — for the frontend, the optional self-hosted server, and the worker.
- CodeQL and gitleaks run as separate workflows — static analysis and secret scanning.
- Even the CI runner image is pinned, with a comment explaining why: the floating ubuntu-latest label was scheduled to migrate and would have swapped the toolchain under every gate.
One honest detail: dependency audit currently runs report-only. The CI file says why, in plain language — two known high advisories sit in transitive chains that need major toolchain upgrades, and the audit becomes blocking once that backlog is cleared. I'd rather show you a gate with a documented exception than pretend everything is green.
The numbers: 317 pull requests opened, 272 merged, every one through that pipeline. I'm not the only author anymore — one community contributor has shipped multiple major features (external feeds in Discovery, a token-permission onboarding guide, card quick actions) through exactly the same gates as the agents. The gates don't care who wrote the code. That's the point.
What the human actually does
My workflow is a PM's workflow, not an engineer's:
1. Write the requirement like a spec, not a wish. "Users can't find starred repos" becomes: sync flow, AI summary + tags, categories that can be locked so re-analysis never overrides a human decision, pause/resume for batch jobs over thousands of repos. The clearer the spec, the less the agents improvise.
2. Decide at the forks. Users asked for a CLI. Our stack made that painful; but collecting the actual scenarios showed the need was "let my AI tools query my star library" — so we shipped an MCP server instead (10 read-only tools). A constraint became a useful side door — the core stayed what it always was: the AI organizing the library itself.
3. Accept or reject. If the gates pass and the behavior matches the spec, it ships. If not, the feedback goes back as a better spec, not as me poking at code I can't read.
What I'd tell other non-coders
Your moat was never typing speed. In the agent era, the scarce skill is knowing exactly what to build, for whom, and how you'll know it's right — then building the fences that keep automated work honest. PMs, support leads, domain experts: you've been training for this.
The app is GithubStarsManager (MIT, local-first, free): AmintaCCCP/GithubStarsManager — if you have a graveyard of starred repos, it might resurrect them. And if you're a developer reading this with (justified) skepticism about AI-written software: the repo is open. Go read the CI file. I did — well, an agent explained it to me. Then I checked its work, like always.
Disclosure: this article was drafted with AI assistance and reviewed by me — which is, honestly, on brand for this project.
1 reaction
Mentions
GithubStarsManager ended the three-weeks-late release news from a changelog post. A dozen repos, one timeline filtered to my platform, one click to download or push to aria2. Least flashy feature, and the one I'd miss most. AmintaCCCP/GithubStarsManager
Starred this week: oh-my-agent (shared skills dir for every coding agent), new-term-radar (catches new AI names before they trend), futu_algo (revived HK quant system). The pile keeps growing — that's why I built GithubStarsManager: AmintaCCCP/GithubStarsManager
GithubStarsManager v0.8.7 is out. semantic search over your stars no longer needs hand-rolled cloudflare setup — there's now a one-click wizard to deploy the worker + vector index. your embedding model stays BYOK, local or cloud. AmintaCCCP/GithubStarsManager
I star repos faster than I revisit them. GithubStarsManager turns the pile into a searchable library: summaries, categories and release tracking. No more remembering repo names. Free/open source, 3.7K stars. Bring your own model or use Ollama locally. AmintaCCCP/GithubStarsManager t.co
我点 GitHub Star 的速度，早就超过回去看的速度。 收藏多了，真要找某个工具时，只剩一句：我好像见过。 GithubStarsManager 把它们全拉回来，自动写摘要、分类，还能按用途找，不用死记仓库名。 3.7K Star，免费开源。AI 可接 Ollama 本地跑。 AmintaCCCP/GithubStarsManager t.co
Starred this week: LakeDB (local DB client — AI writes SQL, can't run it without my OK), motion-prompt (120 named motion styles + examples), AudioScript (live local Mac subtitles). I find them again via GithubStarsManager's AI summaries + tags. AmintaCCCP/GithubStarsManager
维护一个自己一行代码都没写的项目，第400多天了。 我是产品经理，不会写代码，GithubStarsManager 每一行都是AI Agent写的，我只管提需求和验收。能撑到3600+星，靠的不是Agent多聪明，是门禁够烦：测试、边界检查，10种语言少翻一句就拦PR。人类贡献者也一样被拦。 AmintaCCCP/GithubStarsManager
day 400-and-something of maintaining an app i didn't write. i'm a PM who can't code — agents wrote GithubStarsManager, i argue about requirements and click accept. the i18n gate yells at everyone when a string misses one of 10 languages lol AmintaCCCP/GithubStarsManager
Find Any Saved GitHub Project by Describing It: Stars Manager GitHub Stars Manager is an AI-powered organizer that lets you find a saved GitHub project by describing it in plain English. It sorts your saved projects into categories, tells you when one releases an update, and keeps everything on your own computer, which suits anyone with hundreds of saved projects. Find more tools like this on GitTiger: gittiger.com Repo: AmintaCCCP/GithubStarsManager
I can't code. My 3,600-star open-source app is written entirely by AI agents — here are the quality gates that keep it honest I am a product manager. I cannot write code — not "I'm not very good at it", I mean I could not ship a working feature if my life depended on it. Git is something I learned along the way, from an AI, while building this. And yet: I maintain an open-source desktop app with 3,600+ GitHub stars, 59 releases, 34 contributors, and a UI translated into 10 languages. Every line of it was written by AI agents. My job is requirements, decisions, and acceptance. The agents do architecture, code, tests, and releases. This post is not "AI is magic, anyone can do it." AI-written code fails in predictable ways. What makes this work is not the agents — it's the gates. Here is the actual system, with the receipts. How it started I had a personal problem: over the years I had starred hundreds of GitHub repos and could never find any of them again. GitHub's star list is a reverse-chronological wall; search matches names, not "that tool that turns webpages into Markdown." During a hackathon weekend, a tool called bolt.new was free to use. I described what I wanted — sync my stars, let AI tag and categorize them, semantic search — and it started writing code. The prototype was ugly, but it worked: my star list organized itself, and I could search it in plain language. So I kept going, entirely on free AI tiers, rotating providers as quotas ran out. (That constraint later became a product decision: the app is BYOK and provider-agnostic. It binds to no vendor because its author never could.) The part nobody believes: the quality gates "Vibe-coded" projects have a reputation: fine demo, collapsing codebase. The reason mine hasn't collapsed is that nothing merges without passing an automated pipeline that is stricter than what many human teams run. The main CI job is literally named Quality gates: - Architecture boundary check — a custom script enforces the frontend's layering rules, so an agent can't quietly tangle the codebase. - Release-file tamper block — contributors (human or bot) cannot edit version numbers or the update feed in a PR. Only the release bot may. An agent tried; the gate said no. - Plugin registry validation — the community plugin registry is semantically checked on every PR. - An i18n completeness gate — every PR is diff-checked for missing translations and hardcoded UI strings across all 10 languages. Agents love hardcoding strings; the gate loves catching them. - Lint, typecheck, full test suite, production build — for the frontend, the optional self-hosted server, and the worker. - CodeQL and gitleaks run as separate workflows — static analysis and secret scanning. - Even the CI runner image is pinned, with a comment explaining why: the floating ubuntu-latest label was scheduled to migrate and would have swapped the toolchain under every gate. One honest detail: dependency audit currently runs report-only. The CI file says why, in plain language — two known high advisories sit in transitive chains that need major toolchain upgrades, and the audit becomes blocking once that backlog is cleared. I'd rather show you a gate with a documented exception than pretend everything is green. The numbers: 317 pull requests opened, 272 merged, every one through that pipeline. I'm not the only author anymore — one community contributor has shipped multiple major features (external feeds in Discovery, a token-permission onboarding guide, card quick actions) through exactly the same gates as the agents. The gates don't care who wrote the code. That's the point. What the human actually does My workflow is a PM's workflow, not an engineer's: 1. Write the requirement like a spec, not a wish. "Users can't find starred repos" becomes: sync flow, AI summary + tags, categories that can be locked so re-analysis never overrides a human decision, pause/resume for batch jobs over thousands of repos. The clearer the spec, the less the agents improvise. 2. Decide at the forks. Users asked for a CLI. Our stack made that painful; but collecting the actual scenarios showed the need was "let my AI tools query my star library" — so we shipped an MCP server instead (10 read-only tools). A constraint became a useful side door — the core stayed what it always was: the AI organizing the library itself. 3. Accept or reject. If the gates pass and the behavior matches the spec, it ships. If not, the feedback goes back as a better spec, not as me poking at code I can't read. What I'd tell other non-coders Your moat was never typing speed. In the agent era, the scarce skill is knowing exactly what to build, for whom, and how you'll know it's right — then building the fences that keep automated work honest. PMs, support leads, domain experts: you've been training for this. The app is GithubStarsManager (MIT, local-first, free): AmintaCCCP/GithubStarsManager — if you have a graveyard of starred repos, it might resurrect them. And if you're a developer reading this with (justified) skepticism about AI-written software: the repo is open. Go read the CI file. I did — well, an agent explained it to me. Then I checked its work, like always. Disclosure: this article was drafted with AI assistance and reviewed by me — which is, honestly, on brand for this project.