A founder's playbook for managing AI coding agents

Developer Mitesh Ethos details a workflow that treats AI agents like junior engineers, focusing on high-quality planning, enforced guardrails, and a multi-model review process to ship code.

Developer Mitesh Ethos reports a workflow where the primary task is no longer writing code. Instead, his effort has shifted almost entirely to planning and system design, with AI agents handling implementation. The core insight is that as AI makes code execution nearly free, the quality of the architectural plan becomes the primary determinant of the final product's quality.

This approach recasts the founder's role from a hands-on coder to the architect of a human-AI system. The leverage comes not from prompting an AI to write a single function, but from building a durable, automated environment in which AI agents can operate effectively.

The plan is the product

In this model, most of the work happens before an AI agent is assigned a task. Ethos describes his effort concentrating on architecture, edge cases, failure modes, and test strategy. A vague plan, he notes, results in an agent confidently implementing the wrong solution.

Once a detailed plan is complete, it is broken down into small, independent pieces. Each piece must be executable by an agent without requiring further clarification. These atomic tasks then become tickets in a project management system, ready for an agent to implement.

Enforce rules, don't just state them

A key lesson Ethos shares is that instructions given to an AI model are guidance, not guarantees. He provides a specific example where an instruction to "always use a git worktree" was occasionally ignored by an agent. The reason was simple model drift.

The solution is to enforce critical rules through deterministic mechanisms rather than relying on natural language instructions. If a step is essential, it should be built into a hook, a script, a validation step, or a continuous integration check. This principle removes ambiguity and ensures compliance with architectural standards. If it is important, make it impossible to skip.

Use a second AI model for code review

After an agent completes a task and opens a pull request, the code is not immediately passed to a human. Instead, a different AI model performs the initial review. Ethos argues that using a separate model is crucial because different models have different strengths, weaknesses, and blind spots.

Disagreements between the implementing model and the reviewing model often highlight the most critical issues. This AI-to-AI review process handles a significant amount of feedback before a human needs to intervene. Human review is reserved for changes affecting critical infrastructure, security, or core architecture. For lower-risk changes that pass automated checks and AI review, a line-by-line human inspection may not be necessary.

WHAT WE'D CHANGE

This playbook is for a highly technical founder. It does not reduce the need for deep engineering expertise; it concentrates it. The entire system of plans, guardrails, and review processes requires a skilled architect to build and maintain. A non-technical founder could not implement this workflow.

The model's scalability is also an open question. While it appears effective for a solo developer, it does not address the complexities of multi-agent or multi-human collaboration. The communication overhead and potential for conflicting agent actions in a larger codebase are not explored.

Furthermore, the economic viability is unstated. Running multiple powerful AI models for implementation and review carries a direct cost. For a bootstrapped product, these API costs could become significant, especially as the volume of code generation increases. The playbook is presented as a workflow improvement, but a cost-benefit analysis is absent.

LANDING

The process described by Ethos is less about AI writing code and more about a founder designing a system that enables AI to work productively. The workflow—Plan, Deconstruct, Implement, Review, Merge—treats the AI as a junior team member that requires a highly structured environment to succeed. The founder's time shifts from producing code to producing clarity. The ultimate leverage is found in continuously improving the harness, not the horse.

The investor read

This playbook signals the emergence of the solo founder as a 'systems architect' capable of producing the output of a small engineering team. For investors, this increases the capital efficiency and potential technical depth of solo-founded or micro-team startups. Products that were previously too complex for a single founder become viable. However, this model concentrates risk. The entire operational intelligence resides with one person, creating an extreme 'bus factor.' These ventures are best viewed as highly-leveraged bootstrapped or lifestyle businesses until the founder's architectural knowledge can be codified into a product or delegated to a team, which remains a significant challenge.

Pull quote: “If it is important, make it impossible to skip.”