If we treat the agent as a ‘junior implementer’ embedded behind a CLI or MCP-like surface, which assumptions from traditional apprenticeship and pairing (about seeing the whole system, owning features end-to-end, and learning by doing) break down, and how would a team redesign its craft bar and feedback loops to avoid producing architects who can’t code or implementers with no taste?

Answer

Key breakdowns and a compact redesign.

1. Apprenticeship assumptions that break

• C1: If agents do most first-pass implementation, “learning by doing” no longer guarantees juniors see enough raw problem-solving to build deep skill.
• C2: With a CLI/MCP agent, juniors can ship PRs without understanding flows end-to-end, so the old assumption that ownership implies comprehension fails.
• C3: Pairing shifts from two humans co-navigating the codebase to a human mediating between spec and agent, so juniors may not build the same mental model of the whole system.
• C4: Seniors can drift into pure architects if their only contact with code is reviewing diffs and writing prompts, not writing and debugging real paths.

2. Craft bar redesign

• C5: Define craft bar in human terms: “can you, unaided, explain and modify this flow?” not “can you route work to the agent?”
• C6: Require every engineer (senior or junior) to ship some agent-free or minimally-assisted changes each cycle, especially in core paths, to keep coding muscles live.
• C7: Make merge-worthy code include a check: the author can orally walk through key files, data flow, and failure modes without reading prompts.

3. Feedback loop redesign

• C8: Use triad sessions (senior + junior + agent) but reserve the first and last minutes for human-only design and refactor passes where no agent calls are allowed.
• C9: For each agent-heavy PR, add a short “understanding check” in review: reviewer asks 2–3 pointed questions about tradeoffs, not syntax; merge is blocked if the author can’t answer.
• C10: Rotate roles: seniors sometimes drive the harness while narrating, and sometimes code by hand with agents off; juniors sometimes implement small tasks mostly by hand with the agent limited to lookup.
• C11: Tag some tickets as “ownership reps”: junior must handle design, tests, and rollout plan, using the agent only as a helper; review focuses on judgment and taste over speed.

4. Guardrails against architects-who-can’t-code

• C12: Make senior advancement contingent on recently shipping nontrivial code (or migrations/tests) they largely wrote or refactored themselves.
• C13: Expect seniors to edit agent output directly at least sometimes, not only nudge via prompts, to preserve a feel for ergonomics and edge cases.

5. Guardrails against implementers-without-taste

• C14: Encode a small style/taste charter (naming, boundaries, testing patterns) in the harness and PR templates, and review against that, not just correctness.
• C15: Require each engineer to periodically refactor or improve an existing agent-generated flow for clarity or UX, with a short before/after note on why it’s better.
• C16: In standups and retros, talk about “where the agent’s solution was technically fine but wrong for our taste,” so taste stays explicit and teachable.

Overall: treat the agent as a power tool inside an apprenticeship system that still measures humans on understanding, direct coding ability, and taste—not on how many CLI tasks they can route.