Stripe — coding agents / harness

Harness over hero model

Stripe's public material on coding agents (Minions-class internal tooling) stresses environment isolation, verification gates, and incremental apply over monolithic "model writes entire repo" demos. The model proposes; the harness decides what may touch disk, run in shell, or merge.

Your agentic workflow module introduced validate → sandbox → verify. This lab specializes that pattern for code: the highest-risk everyday agent surface.

Reading focus

From Stripe.minions / harness writeups, note:

• Proposal vs apply — diff preview before write
• Sandbox — restricted filesystem, network, command allowlist
• Verification — tests/lint as merge gate
• Human review — still required for production merges at scale
• Telemetry — traces per harness stage

Map each to your prior harness diagram in industry/stripe/comparison.md.

Callout — Minions is not "autonomous staff engineer": It is a controlled loop with explicit stop conditions and verify — same philosophy as your milestone 9 harness.

Sandboxed coding agent architecture

Task → Validate repo path
     → Plan (optional LLM)
     → Generate patch
     → Apply in temp worktree
     → Run lint + tests in sandbox
     → [pass] expose diff / [fail] feed errors to model (bounded retries)

Implementation choices for portfolio:

• Git worktree or temp copy of repo
• Subprocess with cwd locked to sandbox
• Command allowlist from coding skill module

Never run agent shell against $HOME or production credentials.

Lint/test gates as hard verify

Reuse coding skill commands exactly — no ad-hoc pytest paths per run.

Structured verify output:

{"lint": "pass", "tests": {"passed": 12, "failed": 0}, "duration_ms": 4200}

Promotion blocked on any fail — model cannot argue its way past JSON.

Compare to milestone 9 harness

Write explicit diff table:

Identify one gap you still have (e.g. no human PR review step — document as future).

Failure modes

• Sandbox escape via path traversal — validate paths resolve under root
• Test flakiness — agent loop spins; cap retries
• Overfitting tests — agent cheats narrow tests; keep eval cases separate

Diff size limits

Production harnesses cap lines changed per agent turn — prevents blow-up refactors. Lint gate plus git diff --stat threshold (e.g. 200 lines) forces incremental progress; model receives error when exceeded.

Review queue integration

After verify pass, push diff to human review queue (GitHub PR stub) — harness ends at PR create, not merge. Minions-class systems keep human merge authority; document that boundary in comparison.md.

Environment parity

Sandbox must match CI node version — "works in agent sandbox, fails CI" wastes trust. Pin tool versions in sandbox Dockerfile same as GitHub Actions workflow.

Putting it together in practice

ShipAI treats this lesson as executable curriculum, not reading alone. Before marking complete, trace one real request through your portfolio stack and label where this lesson's concepts apply — even if the first pass is messy. Document what broke in the module README; that gap list becomes your next sprint.

Compare your implementation against the industry callouts cited earlier without copying their scale. Name one deliberate simplification you kept (mock auth, SQLite not Postgres, single-region deploy) and one simplification you refuse to ship without (no eval gate, no trace on mutating tools, no fail-closed guardrail on exfil cases). That contrast is what interviewers and graders look for.

Callout — Teach back: Explain this lesson's core tradeoff to a peer in five minutes without slides. If you cannot, re-read the failure modes section and add an example from your own run logs.

Common questions and misconceptions

"Is this overkill for a side project?" Side projects can skip pieces; capstones and production cannot skip knowing the pieces exist. You may waive cost accounting in v1 but your architecture diagram should still show where it would attach.

"Should I rewrite from scratch?" Extend what you built in prior modules — graders reward evolution, not parallel unused folders. Link file paths in your checklist.

"Which metric matters most?" The metric tied to user harm or revenue: policy violations, failed refunds, silent wrong answers — not vanity leaderboard scores.

Extension paths after the micro-project

After the micro-project passes smoke check, choose one extension aligned with your capstone pillar: tighten eval coverage, add a chaos or red-team case, or wire observability into SSE streams. Extensions belong in BACKLOG unless scope freeze explicitly includes them — avoids capstone death by optional polish.

Engineering problem (staff framing)

Study public engineering patterns around Stripe: Coding agent harness. Rebuild the idea, not scraped proprietary text — focus on transferable architecture.

Diagram — Stripe pattern (conceptual)

flowchart LR
  Task-->Harness-->Tools-->Tests-->PR

Precise definitions & mental model

Extract 3 transferable patterns from Stripe's public tech narrative on Coding agent harness; map each to a ShipAI module artifact.

Tradeoffs — when to use what

Failure modes (interview + on-call)

Cargo-culting brand names without metrics; inventing fake citations; cloning UI not architecture.

Production & OSS practices

Write a lab README: hypothesis, architecture diagram, eval, cost model, what you'd ask their eng in an interview.

Micro-project: Sandboxed coding agent + gates

Ship in industry/stripe/:

1. Reading notes + comparison.md to Agentic workflows harness.
2. Coding agent applying patches only in sandbox worktree.
3. Lint + test gates blocking promotion.
4. Trace showing validate/sandbox/verify spans with timing.
5. Demo: fix seeded bug → green tests; demo: bad patch → verify fail → bounded retry.

Acceptance: bad code never lands outside sandbox; verify JSON logged.

Checklist

• Stripe reading notes committed
• Sandbox worktree isolation verified
• Lint/test gates enforced
• comparison.md vs Agentic workflows harness
• Trace with harness stage timings