The 100-Hour Week in 10 Hours

The “10x Developer” myth is dead. The reality is the 10x Director—someone who multiplies output not by typing faster, but by increasing decision throughput and maintaining context hygiene.

This isn’t about working harder. It’s about running a workflow that lets one human direct AI agents to produce work that would have required a team.

The leverage comes from two things:

1. Decision throughput: How many good decisions can you make per day?
2. Context hygiene: How clean is the information you (and your agents) work with? (See our Context Hygiene guide).

If either degrades, output degrades. This article describes the operating system that keeps both high.

The Weekly Operating Loop

Work runs in weekly cycles. Each week follows the same cadence:

1. Plan (Monday)

Start with specs. A spec is a short document that defines:

• What you’re building
• Why it matters
• What “done” looks like

Specs live in /specs/. They’re not documentation—they’re executable intent. When you write a spec, you’re programming the work (see Prompt Engineering for why).

Monday ritual: Review open specs. Pick one. Ensure it’s clear enough that an AI agent (or future you) can execute without guessing.

2. Build (Tuesday–Thursday)

Implement the spec. This is where AI agents do the heavy lifting:

• Code generation
• Test writing
• Documentation updates

The human role shifts from “writing code” to “reviewing output.” You’re not typing functions; you’re validating that the generated code matches the spec.

Key constraint: One active spec at a time. Context switching kills velocity. If you have three half-finished specs, you have zero finished work.

3. Review (Friday Morning)

Before anything ships, it passes review:

• CI checks: Format, lint, typecheck, build. These are automated gates.
• Manual review: Does the output match the spec? Are there edge cases the spec missed?

CI is the gate. Since branch protection isn’t available in this repo, CI is the enforcement mechanism. If npm run build fails, nothing ships.

4. Ship (Friday Afternoon)

Merge to master. The work is now live.

In this repo, /site/ is the shipping surface. Everything in /site/ deploys. Everything else (/specs/, /docs/, /intel/) is working context—not what visitors see.

5. Retro (Friday EOD)

Update the record:

• Close the spec (or archive it)
• Update any affected documentation
• Note what worked and what didn’t

This is where context hygiene compounds. If you don’t capture learnings, you’ll re-learn them next week.

Day-Level Tactics

The weekly loop is the skeleton. Daily tactics are the muscle.

Timeboxing

Every task gets a timebox. If you can’t finish in the box, the spec is too big.

Task Type	Timebox
Spec review	15 min
Code review	30 min
Implementation block	2 hours
Debugging session	1 hour

When the timebox expires, you have three choices:

1. Ship it: The work is good enough.
2. Cut scope: The spec was too ambitious.
3. Extend: Only if you’re 80%+ done and blocked on something specific.

Never extend twice on the same task. That’s a sign the spec is broken.

One Active Spec

This is the most important rule: one spec in progress at a time.

Why? Because AI agents have context windows. Every time you switch tasks, you:

• Lose the context you built
• Have to re-prime the agent
• Risk mixing constraints between tasks

A finished spec is worth 10 half-finished specs. Ship one thing.

Definition of Done

A spec is done when:

• Implementation matches the spec description
• CI passes (format, lint, typecheck, build)
• Manual review completed
• Documentation updated (if applicable)
• Merged to master

If any checkbox is empty, the work isn’t done. No exceptions.

Stop Conditions

Know when to stop. These are hard stops:

• CI fails: Stop. Fix it before continuing.
• Spec is unclear: Stop. Clarify the spec before generating more code.
• Context is bloated: Stop. Summarize and reset before continuing.
• Timebox expired with no progress: Stop. The approach is wrong. Re-spec.

Stop conditions prevent the “sunk cost spiral” where you keep throwing effort at a broken approach.

Templates

These templates make the workflow repeatable.

Daily Directive Template

Start each day with a directive. This is a one-page (or less) document that frames the work:

# Daily Directive — YYYY-MM-DD

## Active Spec

[Link to spec file or one-line description]

## Today's Goal

[Single sentence: what does "done" look like by EOD?]

## Context

- [Key constraint 1]
- [Key constraint 2]
- [Relevant prior decision]

## Out of Scope

- [x] [Already decided / not today's problem]
- [x] [Explicitly deferred]

## Timeboxes

| Task     | Timebox | Status |
| -------- | ------- | ------ |
| [Task 1] | [X min] | [ ]    |
| [Task 2] | [X min] | [ ]    |

## Stop Conditions

- [ ] CI green
- [ ] Spec criteria met
- [ ] No unresolved blockers

Fill this out before opening your editor. It takes 5 minutes and saves hours of drift.

Spec-to-PR Checklist

Before creating a PR, verify:

Spec Alignment

• PR title matches spec intent
• All acceptance criteria from spec are addressed
• No scope creep (extra features not in spec)

Code Quality

• npm run format passes
• npm run lint passes
• npm run typecheck passes
• npm run build passes

Documentation

• README updated (if behavior changed)
• Spec status updated (ready to close?)
• Decision log updated (if architectural choices made)

Review Readiness

• PR description explains what and why (see Context Hygiene for packaging context)
• Reviewer can verify without asking clarifying questions
• No “WIP” or placeholder code

If any checkbox is empty, the PR isn’t ready. Fix it before requesting review.

Portia Grounding: How This Repo Runs

This isn’t abstract theory. It’s how this repo operates:

• /site/ is the shipping surface. Changes here deploy automatically.
• /specs/ contains active and completed specs. This is where work is defined.
• CI is the gate. Since branch protection isn’t available, CI checks enforce quality. If CI fails, the work doesn’t ship.

The workflow is:

1. Write a spec in /specs/YYYY-MM-DD-slug.md
2. Implement on a feature branch
3. Run CI locally: npm run format && npm run lint && npm run typecheck && npm run build
4. Create PR with completed checklist
5. Merge when CI passes and review is complete
6. Archive or close the spec

This loop runs weekly. The output compounds because context stays clean and decisions stay explicit.

The Reality: It’s Messy

This methodology isn’t magic. Things go wrong:

• Agents hallucinate: Generated code may reference non-existent APIs. Verify everything.
• Context windows fill: Long sessions degrade output quality. Reset regularly.
• Specs are wrong: Sometimes you discover the spec was based on a false assumption. Stop, re-spec, continue.

The methodology doesn’t prevent problems. It makes problems visible faster. A bad spec reveals itself in hours, not days. A broken approach becomes obvious when the timebox expires with no progress.

Why This Works

The “100-hour week” framing is about leverage. One human can direct work that would have required a team—but only if:

1. Decisions are explicit: Specs capture intent so you don’t re-decide the same things.
2. Context is curated: You work with signal, not noise.
3. Work is bounded: Timeboxes and stop conditions prevent infinite loops.
4. Quality is gated: CI enforces standards without requiring a human reviewer for every detail.

The future of development isn’t just AI writing code. It’s AI maintaining the operational complexity that allows one person to run a lab.

The job of the human is to keep the orchestration layer clean—to ensure the right decisions are made, the right context is preserved, and the right work ships.

---

This is the director’s operating system. Use it. Adapt it. Improve it.

---

Related Intel

• The Question Latch — the architectural “gate” for high-fidelity specs.
• Human-on-the-Loop — the strategic framework for directing parallel agent fleets.
• Prompt Engineering — the fundamental principles of programming in prose.
• Context Hygiene — how to package context so agents don’t drift.
• Ghost in the Latency — a real-world example of spec-driven iteration.
• Ingestion Pipelines — turning mess into executable work.
• Safety Valve — guardrails for agentic automation.

---

Work with Portia Labs

If you want help applying this in your own environment:

• Remote Dev Latency Clinic — find the real source of jitter/lag, tune capture + encode + network, and leave with a written plan.
• Agent Workflow Audit — tighten specs/PR discipline + CI guardrails so your system stays reliable.

Explore Our Services | Contact Us

Drafted by Jarvis for Portia Labs.