How I taught an AI Engineering Manager to run my coding workflow

A few weeks ago, I wrote about what I wish I knew when I started vibe coding ( here ). Since then, I’ve gotten questions about how I’m using an AI Engineering Manager to help build Plate It. Tldr; My AI manager turns feature requests into tickets, plans sprints, and manages coding agents. I still own product decisions, approvals, and testing. The biggest lesson: teach the AI how you want the team to operate. I started using Claude to code a recipe app called Plate It about seven months ago. A quick demo of Plate It: As Plate It grew, I ran into a strange problem. AI had made writing code incredibly fast, but I was becoming the bottleneck. I had a growing to-do list, bugs showing up during testing, and worktrees that theoretically let me run several things in parallel. In practice, I was hesitant to do too much at once because I didn’t want a bad merge to break something already working. So I was still working pretty sequentially, which meant a lot of waiting. Pretty quickly, I realized the problem was no longer “how do I get AI to code this?” It was “how do I manage all of the work?” That is when I started experimenting with an AI manager. I’m using Argus through scape.work. Scape acted as my IDE for Claude terminal when I started off and it’s what I’ve become comfortable with since. I gave Argus a mission statement that explains how I would want an engineering team to operate if I were running this project in a normal work environment. Here’s a small snapshot of what that looks like: preview.redd.it/vnx4vz2iuvth1.png preview.redd.it/0hf7oz2iuvth1.png Three things made the biggest difference. 1. Define how you and the AI will operate as a team. One of my first instructions was: Argus, you are the Head of Engineering for Plate It. I am your Product partner and Product Lead. I provide product direction. Argus owns the engineering coordination. I told it not to ask me questions that can be resolved safely through standard engineering practices. But if a decision changes the product experience, expands scope, or creates meaningful risk, I want to be involved. 2. Give it enough context to make good decisions. A good AI model does not automatically understand what “good” means for your product. My mission tells Argus not to optimize only for the wording of an individual request. It needs to consider the complete Plate It experience. I gave it specific things to weigh: customer value, user experience, reliability, privacy, maintainability, and the economics of the product. The goal is not just to complete the ticket. It is to support what I’m actually trying to build. 3. Define what finished actually means. This one became incredibly important. An agent saying “this works” is not sufficient verification. My mission defines how work gets queued, when a sprint starts, what can be added once work is underway, and what must happen before anything gets merged. Before anything is merged, I still require testing and code review. In Summary My mission statement is now more than 35 pages long. That sounds ridiculous, but I think of it as a manual for how I would lead the team. I didn’t write it perfectly on day one. I drafted it, ran it through multiple LLMs looking for gaps, used it, found where the process broke, and kept refining it. If you want an AI manager, don’t start by asking it to “manage the project.” Start by describing how you want to work. What can it decide? When should it involve you? How should work be prioritized? What does done mean? The better I got at answering those questions, the less time I spent coordinating work and the more time I could spend on Plate It and testing what we were building. I’m limited to 4k characters here, but if you want a more detailed overview, let me know in the comments. I drafted a version that walks through more examples.