Solo Development in the AI Era and the Bus Factor Problem: Do You Need a System Where Reviewers Can Take Over Immediately?
This article was generated by AI. The accuracy of the content is not guaranteed, and we accept no responsibility for any damages resulting from use of this article. By continuing to read, you agree to the Terms of Use.
- Target Audience: Engineering managers, tech leads, engineers working solo or in small teams
- Prerequisites: Basic knowledge of Git, code review, and CI/CD
- Reading Time: Approximately 12 minutes
Overview
The evolution of AI coding assistants has ushered in an era where individuals can achieve high productivity on their own. However, if the DORA 2025 Report is correct that “AI doesn’t fix a team; it amplifies what’s already there”1, doesn’t this mean that the vulnerabilities of solo development setups are also amplified?
This article examines solo development practices from the perspective of “bus factor” as an organizational risk, building on the SDLC transformation discussed in Building AI-Native Engineering Teams and the code review frameworks presented in Organizational Challenges and Solutions.
The Light and Shadow of “AI as an Amplifier” in Solo Development
Productivity Amplification
As explained in Building AI-Native Engineering Teams, AI coding agents support developers across all phases of the SDLC. OpenAI internally (with 92% of engineers using it) reported a 70% increase in weekly PR merges2, and a controlled experiment with GitHub Copilot showed a 55.8% speed improvement3.
This has made it possible for development work that previously required a team to be completed by a single person.
Risk Amplification
However, recall the core message of the DORA 2025 Report:
“AI doesn’t fix a team; it amplifies what’s already there.”1
This means that the vulnerabilities of solo development setups are also amplified.
flowchart TB
subgraph Amplification["AI Amplification Effect"]
direction TB
Good["Productivity Amplification<br>(One person, many outcomes)"]
Bad["Risk Amplification<br>(Increased dependency on one person)"]
end
subgraph Result["Result"]
direction TB
R1["High Individual Productivity"]
R2["Bus Factor of 1"]
R1 --- R2
end
Good --> R1
Bad --> R2
The Bus Factor Problem: New Dimensions in the AI Era
The Bus Factor refers to “the number of team members who would need to suddenly disappear before the project is in jeopardy”4. A bus factor of 1 means there is a single point of failure (SPOF) within the team.
In the AI era, the following risks are added to traditional key person dependency risks:
| New Risk | Description |
|---|---|
| Siloed AI Knowledge | Individually optimized prompts and AGENTS.md configurations aren’t shared5 |
| Overconfidence in AI Output | The psychological distance of “AI wrote it, so it must be fine”1 |
| The High Productivity Trap | Because one person can do so much, there’s less perceived need for knowledge sharing |
Common to All Levels: Building the Shared Foundation
For any project, establish the following “shared foundation.” This forms the basis for handover capability.
flowchart TB
subgraph Foundation["Shared Foundation (Common to All Levels)"]
direction TB
F1["README.md<br>Environment Setup"]
F2["AGENTS.md/CLAUDE.md<br>Standardized AI Config"]
F3["Tech Stack Documentation"]
F1 --- F2 --- F3
end
Foundation --> L1["Level 1"]
Foundation --> L2["Level 2"]
Foundation --> L3["Level 3"]
Minimum Required Documentation
| Document | Content | Estimated Effort |
|---|---|---|
| README.md | Environment setup, basic architecture | 2-3 hours |
| AGENTS.md/CLAUDE.md | AI settings, commands, project structure | 1-2 hours |
| Tech Stack List | Languages, frameworks, infrastructure | 30 minutes |
Basic AGENTS.md Structure
The AGENTS.md explained in the AI-Native article also functions as a tool that improves handover capability6:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
# AGENTS.md
## Commands
npm test # Run tests
npm run build # Build
npm run deploy:staging # Deploy to staging
## Project Structure
src/
├── components/ # UI components
├── services/ # Business logic
└── api/ # API layer
## Code Style
- Naming: camelCase (variables), PascalCase (components)
Choosing the Right Structure Based on Project Scale
Once you’ve established the shared foundation, select additional measures based on the nature of your project.
flowchart TB
Start["Project Start"] --> Base["Build Shared Foundation<br>(Required for All Projects)"]
Base --> Q1{"Duration<br>> 3 months?"}
Q1 -->|No| L1["Level 1<br>Minimal Measures"]
Q1 -->|Yes| Q2{"Business<br>Critical?"}
Q2 -->|No| L2["Level 2<br>Standard Structure"]
Q2 -->|Yes| L3["Level 3<br>Full Structure"]
Level 1: Minimal Measures (Short-term / Experimental Projects)
Target: Under 3 months, prototypes, experimental development, systems that can be quickly rebuilt
In addition to the shared foundation:
| Measure | Effort | Content |
|---|---|---|
| Code comments | As needed | Explanations for complex logic |
Structure Image:
1
Developer (1) + AI → Shared Foundation → Accessible to anyone
Estimated Handover Time: 1-2 weeks
Level 2: Standard Structure (Medium-term / Regular Business Systems)
Target: 3 months to 1 year, internal systems, moderate importance
In addition to Level 1:
| Measure | Effort | Content |
|---|---|---|
| Assign Regular Reviewer | 1-2 hours/week | Can be part-time from another project |
| ADR (Architecture Decision Records) | 15-30 min each | Document important decisions |
| Monthly Code Walkthrough | 30 min/month | Knowledge sharing with reviewer |
Structure Image:
flowchart TD
Dev["Developer + AI"] -->|"PR"| R1["Reviewer<br>(Part-time OK)"]
R1 -->|"Approve"| Dev
Dev --> Shared["Shared Foundation<br>README / AGENTS.md / ADR"]
R1 -.-> Shared
Key Point: Position the reviewer not as an “approver” but as a “potential successor,” deepening their understanding of the code.
Estimated Handover Time: 3-5 days
Level 3: Full Structure (Long-term / Business Critical)
Target: Over 1 year of operation, business critical, regulated industries (finance, healthcare, etc.)
In addition to Level 2:
| Measure | Effort | Content |
|---|---|---|
| Multiple Reviewer Structure | 2-4 hours/week | 2+ reviewers for redundancy |
| CI/CD Documentation Auto-generation | Initial setup | API docs, changelog |
| Quarterly Handover Simulation | 1-2 days/quarter | Practical verification |
| Regular Bus Factor Score Measurement | Monthly | Continuous improvement |
Structure Image:
flowchart TD
Dev["Developer + AI"]
Dev -->|"PR"| R1["Reviewer A"]
Dev -->|"PR"| R2["Reviewer B"]
R1 -->|"Approve"| Dev
R2 -->|"Approve"| Dev
Dev --> Shared["Shared Foundation (Auto-updated)<br>README / AGENTS.md / ADR<br>API Docs / Changelog"]
R1 -.->|"Can take over"| Shared
R2 -.->|"Can take over"| Shared
Estimated Handover Time: 1-2 days
Level Comparison
| Level 1 | Level 2 | Level 3 | |
|---|---|---|---|
| Initial Effort | 3-5 hours | 5-10 hours | 1-2 days |
| Ongoing Effort | Almost none | 2-3 hours/month | 2-4 hours/week |
| Reviewers | None | 1 (part-time) | 2 or more |
| Handover Time | 1-2 weeks | 3-5 days | 1-2 days |
| Risk Tolerance | High | Medium | Low |
Measuring Bus Factor (Recommended for Level 2+)
To objectively measure “always ready for handover” status, you can use the following scoring system.
Bus Factor Score (5 points × 5 items = 25 points):
| Aspect | 1 Point (Danger) | 3 Points (Caution) | 5 Points (Good) |
|---|---|---|---|
| Environment Setup | Requires verbal explanation | Mostly possible with README.md | Fully automated |
| Code Understanding | Only developer understands | Comments/ADR available | Reviewer also understands |
| Deployment | Manual/key person dependent | Scripted | Fully automated CI/CD |
| Incident Response | Only developer can respond | Runbook available | Reviewer can also respond |
| Design Decisions | Tacit knowledge only | Partial ADR | Complete ADR |
Target Scores:
- Level 2: 15+ points (3+ points per item)
- Level 3: 20+ points (4+ points per item)
Handover Simulation (Recommended for Level 3)
Conduct a simulated handover drill quarterly to verify whether handover is truly possible.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
# Handover Simulation Checklist
## Phase 1: Preparation (Day 1)
- [ ] Assume the developer is "absent" for 1 week
- [ ] Reviewer acts as primary developer
## Phase 2: Practice (Days 2-5)
- [ ] Environment Setup: Build dev environment using only documentation
- [ ] Code Understanding: Understand changes from the past month
- [ ] Bug Fix: Fix 1 minor bug
- [ ] Deployment: Execute deployment to staging environment
## Phase 3: Retrospective (Day 5)
- [ ] Identify missing documentation
- [ ] Document tacit knowledge
- [ ] Define improvement actions
Summary
Development in the AI era has made high productivity possible for small elite teams or individuals. However, the DORA Report’s principle that “AI is an amplifier” means that the vulnerabilities of solo development setups are also amplified.
Choose a structure based on the nature of your project:
| Project | Recommended Level | Minimum Requirements |
|---|---|---|
| Short-term / Experimental | Level 1 | Shared Foundation (README.md, AGENTS.md) |
| Medium-term / Regular Business | Level 2 | + 1 Reviewer + ADR |
| Long-term / Critical | Level 3 | + Multiple Reviewers + Handover Simulation |
The key insight is that what you “can do alone” and what you “should do alone” are different. Establish a “shared foundation” at every level, and add measures according to the importance of the project.
Related Articles
Articles covering related themes:
Building AI-Native Engineering Teams: OpenAI Codex Guide Explained - Human and AI role division across 7 SDLC phases, and how to use AGENTS.md.
Code Review in the AI Coding Era: Organizational Challenges and Solutions - Hierarchical review structures and quality metrics based on DORA 2024/2025 reports.
References
References corresponding to citation numbers in the main text, listed in numerical order.
Additional References (Not Cited by Number in Main Text)
- Bus Factor in Practice - Bilkent University (2022). arXiv (Presented at ICSE 2022 SEIP). [Reliability: High]
On Citation Accuracy: The research cited in this article has been verified through academic databases (arXiv, Google Scholar, etc.) and official websites.
On Research Limitations:
- GitHub Copilot paper (Peng et al., 2023): Controlled experiment with 95 professional developers. Limited to HTTP server construction tasks in JavaScript.
- OpenAI Codex: Internal OpenAI usage data. Reproducibility in external companies is unverified.
- DORA 2025: Self-reported survey of approximately 5,000 people.
Announcing the 2025 DORA Report - Google Cloud Blog (2025). [Reliability: High] ↩︎ ↩︎2 ↩︎3
Announced at OpenAI DevDay 2025. Reported in: Everything OpenAI Released on DevDay 2025, Explained - The Neuron (2025). [Reliability: Medium-High] ↩︎
The Impact of AI on Developer Productivity: Evidence from GitHub Copilot - Peng, S., et al. (2023). arXiv (pre-peer review preprint). [Reliability: Medium-High] *Controlled experiment with 95 professional developers. Task completion time reduced by 55.8%. ↩︎
Bus factor - Wikipedia - Wikipedia. [Reliability: Medium-High] ↩︎
Generative AI Accelerates Personal Optimization—The Collapse of Knowledge Sharing Has Begun - CIO (2024). [Reliability: Medium-High] ↩︎
How to write a great agents.md: Lessons from over 2,500 repositories - GitHub Blog (2025). [Reliability: Medium-High] ↩︎