The docs-first approach mentioned in the comments aligns with something deeper: the idea that context needs to be explicit, versioned, and shared — not just for the AI, but for the whole team.

What you're describing as "agentic for non-vibe coders" is essentially what responsible AI-assisted development looks like: maintaining human oversight, having clear architecture docs, keeping context alive across sessions. The vibe coding approach tends to skip all of this, which is why so many projects hit a wall after the initial sprint.

This is exactly the territory the Agile Vibe Coding Manifesto (https://agilevibecoding.org) tries to address. It extends the original Agile Manifesto specifically for environments where AI agents are generating significant code. A few of its principles are directly relevant here: "Context is explicit and versioned" and "Architecture guides and constrains generation" — both of which describe what you're doing with your PITCH.md/ARCHITECTURE/IMPLEMENTATION approach.

Worth a read if you're thinking about how to formalize these practices across a team.

My workflow for building side projects and work tools with AI coding agents that actually survive past the first month. Covers model choices (Claude Opus, Codex, Qwen), a docs-first approach (PITCH/ARCHITECTURE/IMPLEMENTATION), guardrails, context management via slash commands, and what I stopped using (MCP servers, multi-agent teams, instruction files). Includes dogfooding results — what shipped and what broke.

the docs-first approach is the part most people skip everyone wants to jump straight to prompting but without a PITCH.md or equivalent, the agent has no north star and you spend half your time correcting drift instead of building the context save/restore slash commands are underrated too losing context mid-session and having to re-explain the whole codebase is where most of my time used to go.