AI SDLC Kit
Scenarios

Solo Developer

How a solo developer uses ai-sdlc-kit effectively, adapting HITL practices and agent roles for a team of one.

When to use this scenario

Use this walkthrough if you are the only person working on the project. All agent roles are executed by the same individual, which changes the HITL dynamics but not the fundamental process.


The solo developer's advantage

Solo developers benefit from ai-sdlc-kit more than large teams in some ways:

  • No coordination overhead — you do not need to share artefacts across people; the kit's structure replaces the need for meetings about scope
  • Faster spec cycles — you can approve artefacts as soon as you finish them (with appropriate review delay)
  • Full context — you already know the constraints; CONTEXT.md captures them for the agents

The disadvantage is that the same person who frames the problem is also the person who validates the framing. This creates confirmation bias risks at HITL checkpoints.


Adapting HITL checkpoints

The 24-hour rule

Review generated artefacts 24 hours after they were created, not immediately. The fluency of AI-generated prose makes it easy to approve content you do not actually agree with. A day of distance breaks the fluency illusion.

This applies especially to:

  • idea.md after Discovery
  • spec-epic-N.md before Construction starts
  • Review reports before merge

Simplified HITL process for solo developers

CheckpointStandard processSolo adaptation
HITL-A1 to HITL-A5Team review meetingAsync self-review; use the 24-hour rule
HITL-B1 (spec)Spec review with stakeholdersRead aloud test: if you need to explain a criterion, it is not specific enough
HITL-B3 (implementation)Peer code reviewDiff review against spec acceptance criteria only; not style
HITL-B4 (reviewer report)Review discussionFix blockers; explicitly accept or document tech debt
HITL-B5 (ops)Deploy approval by team leadWrite the rollback steps before approving — if you can't write them, the plan is incomplete

When to compress checkpoints

For small epics (under 5 tasks), it is acceptable to combine:

  • HITL-B1 and HITL-B2 into a single review (spec + task list together)
  • HITL-B3 and HITL-B4 into a single review (implementation + reviewer report together)

Do not combine HITL-A4 (technical spec) and HITL-A5 (epics). These are separate reviews of different abstraction levels.


Adapting agent roles

In a team context, different humans invoke different agents. As a solo developer, you invoke all agents. The role distinction is still useful:

AgentWhat its perspective forces you to consider
🧭 Discovery"Am I solving the real problem, or just the first formulation of the problem?"
🗂️ PM"Am I describing what the product does for users, or how it works technically?"
🧑‍💼 Tech Lead"Are these requirements testable? Are the priorities correct?"
🏗️ Architect"Is this architecture appropriate, or is it the architecture I happen to know best?"
📐 Planner"Are these tasks independent enough to be implemented and tested separately?"
🛠️ Implementer"Am I implementing the spec, or what I wish the spec said?"
🧪 QA"Does this test prove the behavior, or just that the code runs?"
🔎 Reviewer"Does this implementation satisfy the acceptance criteria, or does it just look correct?"
🚀 Ops"Can this be safely deployed? Can it be safely rolled back?"

Running an agent means adopting its critical perspective, not just generating its output.


For a new project

Follow the full New Project walkthrough, with these time-boxing guidelines:

PhaseTime budget per epoch
Flow A (Discovery → Epics)1–2 hours for small projects; 1–2 days for large ones
HITL review per checkpointMinimum 15 minutes; apply 24-hour rule for spec and epics
Flow B per epicVaries by scope; spec review is always same-day minimum

For an existing project

Follow the Existing Project walkthrough. The CONTEXT.md population step is the highest-value investment for solo developers — it takes 1–2 hours and pays back across every subsequent agent interaction.


Common solo developer mistakes

Mistake 1 — Skipping the Discovery phase
Solo developers often skip Flow A because they "already know what they want to build." The Discovery phase is not for when you don't know what to build. It is for making your idea explicit enough to function as input to a spec. The spec cannot be more precise than the idea document.

Mistake 2 — Over-compressing epics to go faster
The temptation to put everything in Epic 1 is real when you are the only developer and the deadline is yours. Epics that are too large cannot be reviewed coherently, and HITL checkpoints become rubber stamps by necessity. Right-size epics at 3–7 tasks.

Mistake 3 — Using agent outputs without reading them
This is the fastest route to a codebase that is internally consistent but externally wrong. Every agent output requires genuine review. An AI-generated spec that you approved without reading is not a validated spec — it is a liability.