I use AI heavily in my personal software project. At first, that meant opening a session, explaining the project state, asking for implementation help, reviewing the result, then manually carrying the outcome into another session for testing or follow-up work.
The bottleneck eventually stopped being “can AI help with this task?” and became “can I coordinate many AI-assisted tasks without turning myself into a human message bus?”
The problem was state, not intelligence
Separate sessions did not reliably share durable task state. A worker could finish implementation, but the next worker still needed to know what changed, which dependencies were satisfied, what files mattered, and what remained blocked.
I designed a GitHub-backed relay where each worker has a durable state file, an explicit task contract, dependency rules, a revision counter, and a structured handoff. A local controller reads those states and activates workers only when their dependencies are satisfied.
What the automation handles
- Durable task status
- Dependency gating
- Handoff persistence
- Worker activation
- Concurrency limits
- Navigation/context injection
What I intentionally kept manual
I did not want “more automation” to mean “less accountability.” I still define the product behavior, choose acceptance criteria, inspect source evidence, test the app, resolve ambiguous tradeoffs, and decide whether work is actually done.
Where it helped
The relay made longer build-test-fix loops practical. One worker can implement a bounded change, another can review or test it after the dependency is satisfied, and the durable GitHub state prevents the workflow from depending on my memory of what a previous session said.
What I learned
AI leverage is often a systems problem. The model can be capable and the workflow can still be bad. Reliability improved when I treated context, state, dependencies, and verification as product requirements rather than conversational conveniences.