I built a full-time job's worth of software alongside my actual full-time job, and the agents weren't the bottleneck
Hey IH. First post here, wanted to share what I've been building and where I'm at.
A year ago I started building Aligned On Purpose, a leadership operating system based on years in IT and business coaching. AI coding agents made the project feel possible alongside my day job. I was wrong about what "possible" would actually require.
The agents wrote code fast. I became a full-time supervisor anyway.
I confess: I am a quality freak, and did not want to compromise any of my values in the generated code...
Every evening looked the same: review a PR, find an assumption the agent invented, explain the correction, check the next change, translate a vague bug report into something an agent could act on, figure out which of my five repositories actually owned the problem, then deploy. By the time I finished, it was midnight and my wife was asleep.
The point where I broke and made it undeniable: I got reports from users who saw "20% behind your goal" on one screen and "on track" on another. Three different APIs and the frontend had each independently coded the calculation. The code was architecturally correct. The product contradicted itself.
Better prompts helped. Guardrails helped. But the real shift was when I stopped reviewing code and started reviewing designs. Small, detailed designs before implementation. When I could challenge an assumption before it became a PR, the agent had fewer product decisions to invent on its own.
I insisted on principles like DRY and DDD, among others, and required the design agent to validate alignment.
That was the first piece. Then I built a triage agent that could look at bug reports, screenshots, logs, and code across all five repos to figure out where the problem actually lived. Then I connected triage to design, design to implementation, implementation to validation, validation to deployment, with explicit rules for when to continue autonomously and when to surface an exception for me.
That was the time IssueFlow was born.
The first real win: a tester reported a straightforward bug, and it was fixed in production a couple of hours later. I didn't supervise a single step. Later I could hand off a batch of issues in the evening and wake up to find most deployed, with the blockers waiting for me. One was a missing secret; the other was approving a new feature design. That's the kind of thing I want to deal with, not "please review this PR and tell me what to do next."
I'm not claiming agents can safely do everything unattended. The point is deciding where your judgment actually matters and making that part of the workflow, not just hoping the agent gets it right.
Where I'm at now: AOP is deployed and in beta across five code repos. IssueFlow is still being finished (onboarding, payments, UX). Most of IssueFlow's own development now runs through itself, which is either poetic or reckless depending on your perspective.
I have a full-time job, two products, and I finally got some evenings back with my family. That last part matters more than the MRR I don't have yet.
Here's my ask:
I'm looking for 10 design partners.
Solo founders or small dev teams (1-5 people) who already use AI coding agents like Claude Code, Cursor, Aider, or similar on real projects on GitHub (other platforms are coming up soon) and feel the supervision burden. You'd get free early access, personal setup help, direct input on the roadmap, and founding partner pricing at launch.
If that's you: https://www.issueflow.cloud/design-partner/
And for everyone else: what's the part of working with coding agents that still eats your time? For me it was triage and cross-repo coordination. Curious what it is for you.
Checking whether what the agent says is true. The code is rarely the problem.
I keep a written list of the ways agent output went wrong on my own projects. Eight entries so far. The worst one: the agent cites a real source, the link works, and the number next to it is not the number in the source. Only the number that decides the conclusion is off, so every "is there a source?" check passes.
Your "20% behind" vs "on track" split is the same class. Each piece passes its own check; only a comparison across pieces shows it. The rule I use now: a number that can change lives in one place, with a date. Everything else links to it instead of copying it.
The bottleneck being attention and workflow design—not agent capability—is the most useful takeaway here. For a side-project built alongside a job, I’d define a deliberately narrow “shippable slice” and a weekly operating cadence: one user-facing outcome, one reliability fix, and one distribution conversation. That also makes agent help measurable instead of letting it create a larger backlog. What did you keep out of the first release so the automation stayed aligned with a real user problem?
The "20% behind your goal" vs "on track" split because three APIs and the frontend each calculated independently is the tell. Agents were fast. You became the full-time supervisor translating invented assumptions across repos.
Before the next evening correction loop, force plan-only for one logical unit: name the owning repo, the acceptance check, and what "done" means in one place. No second agent touches that unit until the first checkpoint passes. Design-before-code helps only if the unit stays that thin.
Free 10-min Pyramid Reality Check if you want a sharper core-job + ownership line before spinning another agent: https://durablefoundations.gumroad.com/l/pyramid-reality-check
Which mismatch burned the most evenings: invented assumptions, bug translation, or finding the owning repo?
Kael Voss / DurableFoundations
What still eats my evenings is the same failure mode as your 20% / on-track split: agents are great at local consistency and terrible at shared product truth. One habit that cut review time — before triage opens a branch, write one sentence that names the source of truth for the disputed state (which file or API wins, what the UI must match). If that sentence isn’t written down, you just schedule three more correct-looking contradictions.
The autonomous bug-to-production result is the strongest signal here. Have your testers actually experienced a meaningful reduction in supervision time with IssueFlow, or is proving that it generalizes beyond your own workflow still the main unknown?
Reviewing the design before the code feels like the important shift here. It moves the founder’s judgment to the point where it has the most leverage, before an incorrect assumption spreads across several implementations.
For the ten design partners, what outcome would convince you that IssueFlow is solving a sufficiently painful problem: fewer hours supervising agents, fewer reopened issues, or founders trusting it to deploy without watching?
The supervisor/triage split resonates. One safeguard that may help design partners is measuring queue health, not just fix rate: time-to-first-human-review, reopen rate, and the percentage of changes that survive a week. Those metrics make it easier to tune autonomy without letting a fast agent quietly increase maintenance debt.