Eight months of running a product solo with AI agents as co-engineers

TL;DR: For more than eight months I have been running a production job board side project completely solo, next to a full time engineering job, with AI coding agents working as co-engineers rather than autocomplete. Claude Code is the primary tool at home, Kiro CLI in my enterprise day job context, Cursor as the IDE since 2023. This is not a one week experiment writeup; it is the operating mode that finally got a side project past what I call the 60% wall, the point where my solo products used to die under backend grind, devops, and edge cases. Agents removed that wall. They did not remove the need for product judgment, UX taste, or verification. This post covers where agents genuinely accelerate, where they do not, how I structure context, permissions, and verification so they can work autonomously without wrecking anything, and what it honestly costs: tens of dollars a month.

The 60% wall

I have nine years of commercial full-stack and frontend work inside teams. Underneath that runs a long trail of side projects that all died in the same place. Never at the idea stage, and never at the prototype stage. They stalled at roughly 60% complete: the UI existed, the happy path worked, the core data model was in place. What killed them was everything after that. Background jobs and retries. Admin tooling. Migrations. Monitoring. The eleventh edge case in a form. The unglamorous 40% that separates a demo from a product.

The pattern was brutally consistent: after an eight hour work day, the energy budget ran out exactly where the grind began. Not a skill problem, a throughput problem. One person with two evening hours cannot crank through infrastructure, edge cases, and ops for a real product, and the math does not care how motivated you are.

Today that project, the one that used to be exactly the kind of thing that stalls, is live in production with real users and growing, and I run all of it alone: backend, frontend, a scraping and data pipeline, AI matching, content, and operations. The difference is not that I became more disciplined. The difference is the tooling generation, and more specifically how I decided to use it. More on that history on the about page.

The options I actually weighed

When I decided to attempt a serious product again, I laid out the realistic options instead of just grabbing whatever was trending.

Option one: no AI at all. Full control, zero cost, and every line goes through my head, so I understand the system completely. The con is fatal: this is precisely the mode that produced the 60% wall three times in a row. Running the same experiment a fourth time and expecting a different result was not a plan.

Option two: IDE autocomplete. I had been using Cursor since 2023, early enough that AI in the IDE was mostly completion plus a chat sidebar. The pros are real: faster typing, low risk, no workflow change. But autocomplete is keystroke-level leverage, and the wall is task-level. Completion never ran a migration for me, never scaffolded a test suite, never traced a bug across the codebase at 10 pm. It made the pleasant 60% about 20% faster and did nothing for the 40% that mattered.

Option three: chat assistants. Paste code into a chat window, get reasoning back. Genuinely useful for architecture rubber-ducking and unfamiliar territory. The con: I was the clipboard. All context lived in my head, every answer had to be manually applied and manually re-verified, and anything spanning more than a couple of files fell apart. Great consultant, terrible co-worker.

Option four: autonomous agents with guardrails. An agent that lives in the repository, reads the code, edits files, runs commands and tests, and iterates until a task is done end to end. The pros are exactly the shape of my problem: it works at the task level, it does not get tired, and it can grind through the unglamorous 40% while I sleep or sit in meetings. The cons are equally real: an agent with shell access can delete the wrong thing, run a destructive migration, or push garbage, and it will confidently report success either way. Autonomy without structure is a liability, not leverage.

I chose option four, with one caveat that turned out to be the whole game: autonomy is earned through structure, not granted by default. The interesting part of this post is the structure.

Where agents genuinely accelerate

The honest pattern after eight plus months: agents are strongest exactly where solo projects die.

Tedious end-to-end work. The scraping and data pipeline behind my job board was built through agent collaboration: fetch, parse, dedupe, classify, store, retry, alert. None of it is intellectually hard; all of it is volume. The same goes for admin panels, i18n plumbing, dependency audits, and the long tail of form states. This is the 40% behind the wall, and an agent chews through it at a rate one tired human never could.

Migrations and refactors. Rename a concept across sixty files, move a module, convert a pattern everywhere it appears, then run the build and tests to prove nothing broke. Mechanical, verifiable, exhausting by hand, near-free with an agent.

Test scaffolding. Agents are excellent at the part of testing engineers procrastinate on: harness setup, fixtures, the first twenty cases around a bug. I still decide what deserves testing; the agent removes the activation energy.

Investigation legwork. Reproduce this bug, read these logs, find every place this value is set, tell me which of these five hypotheses survives the evidence. An agent does the sweep in minutes and comes back with a conclusion I can check, instead of me burning an evening on grep archaeology.

For larger features the mode scales up: I plan in one focused session, split the feature into a few parallel, low-conflict subtasks with contracts between them agreed up front, run each subtask in an isolated working copy, and then integrate deliberately in a final session with end-to-end verification. Three or four agents building in parallel while I review is a throughput level a solo evening builder simply did not have before.

Where agents do not help

Equally important, because this is where the hype version of this post would lie to you.

Product decisions. Which feature to build, which segment to serve, what to cut. An agent will happily argue any position with equal confidence. The decision quality comes from talking to users and watching real behavior, and no model does that for me.

UX taste. Agents produce plausible interfaces, and plausible is not the same as good. Every screen that users actually praise went through rounds of my own judgment: spacing, hierarchy, what to remove. The agent iterates fast once I can say what is wrong, but it does not know what is wrong on its own.

Judgment calls under ambiguity. Pricing, tone of copy, whether a risky migration is worth it this week, whether a feature is done enough to ship. These need someone who owns the consequences.

And one meta-limitation that shapes everything else: an agent reporting "done" is a claim, not a fact. Treating agent output as finished work without verification is how you ship confident garbage. Which brings me to the structure.

The structure that makes autonomy safe

Three pillars: context, permissions, verification. I will describe the patterns rather than my exact configuration, because the patterns transfer and the configs do not.

Context. Agents are only as good as what they know about your project, and context windows degrade when stuffed. My rules: a small set of global instructions that apply to every project (code standards, git conventions, security defaults), per-project instruction files that act as a router to deeper docs, and specialized instructions loaded only in the projects that need them. One chat is one focused task; when the task changes, I start fresh. Anything worth remembering gets written into project docs in the same session it was learned, so a fresh session can pick up from files instead of from a bloated conversation history. Durable knowledge lives in the repo, not in the chat.

Permissions. The goal is an agent that works to completion without asking about every reversible step, while being physically unable to do the irreversible ones. I layer this: a permission mode that allows normal work but runs a safety check on risky actions; hard deny rules for the categories that must never happen regardless of mode, things like force-pushing, deleting branches or repositories, and touching secrets; and a pre-execution check that catches destructive commands even when they arrive wrapped or disguised. For parallel work, isolation does the heavy lifting: each agent gets its own working copy with pushing disabled and no production credentials present, so the worst case is a bad branch I never merge. On top of all of it sit human gates that automation never crosses: schema migrations, merges to the main line, and production deploys are mine. I also test the guardrails themselves, because a safety layer you have never tried to break is a hope, not a control.

Verification. Every agent claim gets checked at the level the claim was made. Code claims: build it, run the tests. Visual claims: open the page and look, because markup that reads correctly can render broken. Bug fixes: a failing test first, then the fix, or you do not know whether you fixed anything. Absence claims ("this feature does not exist yet") get double-checked, because a single failed search has burned me into planning work that was already done. None of this is agent-specific advice, really; it is what a good reviewer does with any collaborator's work. The agent just makes the reviewer role the main thing I do.

What it costs, honestly

Money: somewhere between 30 and 100 US dollars a month for subscriptions and agent usage, depending on how heavy the month is. For a product that would otherwise need contractor hours or simply not exist, that is noise. The subscription model also changed my behavior in a useful way: once marginal cost per task is effectively zero, you stop rationing the good model and start optimizing for speed and quality instead.

Time: the honest overhead is maintenance of the system itself. Instruction files drift, guardrails need occasional auditing, and every workflow improvement is an hour spent not building features. Call it a few hours a month. It pays for itself, but pretending the overhead is zero would be the kind of hype I promised to avoid.

Attention: the failure mode of this whole setup is complacency. The weeks where agents burned my time were the weeks I skipped verification because the last ten tasks went fine. The tax is constant vigilance at the review layer, and it is non-negotiable.

Lessons after eight months

• The wall was throughput, not talent. Solo projects died at 60% because one tired person cannot grind infrastructure and edge cases in the evenings. Agents attack exactly that segment, which is why they changed the outcome rather than just the speed.
• Autonomy is earned, not granted. Context files, layered permissions, isolation for parallel work, and human gates on irreversible actions are what make it safe to let agents run to completion. Without the structure, option four degrades into option three with extra risk.
• Agents move the bottleneck from typing to deciding. My scarce resource is now judgment: what to build, what is good enough, what is actually true. That is a better bottleneck to have, but it is still a bottleneck.
• Durable knowledge belongs in files, not chats. Writing decisions and learnings into project docs the moment they happen is what makes fresh, focused sessions cheap, and focused sessions are where agents do their best work.
• "Done" is a claim until verified. Build it, test it, look at it with your own eyes. The review layer is the job now; skipping it is how confident garbage ships.
• Tens of dollars a month is the cheapest co-engineer you will ever hire. The real price is the discipline to structure the work so that a very fast, very tireless, occasionally wrong collaborator makes you faster instead of sloppier.