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

tamina — Wed, 14 Oct 2026 17:40:26 +0000

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:

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.
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.
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): https://github.com/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.

DEV Community: tamina

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

How it started

The part nobody believes: the quality gates

What the human actually does

What I'd tell other non-coders