X and YouTube are plastered with people sharing their agentic development setup. There are skills on GitHub that are crashing any star scoreboards. If you followed all of these and, even worse, tested them, you would not do anything productive anymore. But they are still useful. Mostly to read their approaches, reflect on them, and see what parts can be useful for your setup. And the nice thing is that you don’t have to do that yourself. But more on this later. Here is my current setup for analytics engineering and some web app work. And in AI terms, it is already a veteran setup. In that general shape, I have been using this for about 7 months (ages). Before sharing the details, let’s frame it all properly, shall we? ## The objectives Any good system needs objectives. It’s fine to play around with stuff, but at some point you should ask yourself, what are the things you want to achieve with the setup? My initial objective was simple: I don’t want to write any SQL anymore. The reason is simple: I just don’t enjoy it. SQL feels slow to me, and I've never enjoyed it. When I started covering data pipelines, I extended it to Python. It was more consequential here, since I like to write Python code. But the principle only works when you avoid the manual writing layer at all. The next one came later, but it's a natural progression. I don’t review SQL models or Python code. I did it for quite some time, but the rhythm felt strange. When I review my code, it is not a problem. When I review code others have written, I already struggle. The energy to think into someone else's design is just too high for my purpose. This gets us to my current objectives. My two current objectives are autonomous work time and output quality. The first one is easy to define and measure. It means the time an agent spends doing development work and not waiting for my feedback. It is also easy to measure. Claude Code has hooks; Pi can be extended to add proper time tracking. I can then even go further and also measure idle time. But this is a trickier metric. So work time is the baseline. But by itself, this metric is like lines of code or used tokens, pretty useless. To extend or balance it, my second objective is output quality. And it gets more complex. I just wrote that I don't want to review SQL or Python code. How do you approach quality? It's a multi-level approach (of course it is). The most important part, and the one that took me most of the time, is to define, in an abstract way, what high quality is for me. Because when you move away from, let me look at the model or the code and say, yes, that is good, or better, improve that, now you need to define it in a way that it can be applied to all implementations. At the base level, we can work with tests. For models, we can review our dbt tests, cluster them, and define what we see as must-haves. This is important because agents love to write tests for any stupid thing. So we need to be on the other end and have a clear idea of what tests we want to require and which ones are not adding any value. But tests won't get me where I want the models and code to be. What I am using on top of that are principles. Or, to be more precise, this is my main input work. A principle is a short statement that expresses clearly enough what should be true for you. Let me give you three examples: - Make the smallest complete change - Fix the observed problem without expanding the scope. A missing patch should never trigger a full refactor or a new approach. - Preserve meaning while changing implementation - Optimizations and cleanup must retain business rules, exact monetary arithmetic, NULL behavior, duplicates, and ordering. We don't weaken checks just to get green tests. - Give every CTE one clear job - Follow FITT-Pure: map_* prepares inputs, idr_* resolves identities and joins, and biz_* applies business rules and shapes the final result. Keep these responsibilities separate so each step is easy to understand and test It takes a bit to create these, because it requires you to take a step back and really think about what is important for you and what it should look like. The agents use these principles when they work. Additionally, I use juror/evaluator agents to check the work against these principles. I also use the principles to define the deterministic tests I want to run so these principles hold true. I don't work with quality scores, but it's on my list to introduce them. I can see this as a great use case for a classification model like Jev. Let it test against the principles, see which ones are violated, and come up with a score. ### The bottleneck With these principles, you can build a straightforward context for an implementation agent. Every implementation agent gets a fresh, task-specific engineering brief and not extensive context. I am using three layers: General engineering instructions - these come from the principles; the PM agent decides which principles apply to the task and adds them here Project instructions - a small relevant version of Agent.md, project context, and existing contracts Task brief - Exact outcome (definition of done), starting state, evidence, implementation path, checks and permissions Once the work is finished, the PM agent checks whether the definition of done is met and whether principles are applied or violated. I have been using this with small changes for over 8 months now, and it works really well. It is usually quite agnostic to new model versions and changes that come with them. But when this is in place, the next bottleneck appears. How do you break down an idea into an implementation task? An idea or a feature has a significant size. It can be something like: we now have Buffer to collect all our social media post performance data; let's bring it into our model and reporting datasets. This could be a Jira ticket, but a data team would break it down into different tasks: loading the data, adding it to the data model, defining metrics, and making it available. Of course, you can just tell your agent this, and it will do something, but it will not be the quality level that we were talking about before. ### Missions My first solid try to solve it was the mission format. I turned an idea into a mission, then used a skill to break it down into epics and stories, define a global definition of done, and provide relevant context. What I add is the outcome I want to achieve. The better I can describe it and make it tangible, the better the delivery. "Add social media metrics" is a weaker outcome than "use the Buffer app data to add it to our data model based on our principles, define 5 core metrics it can deliver, and create or enrich existing analytics datasets". Using voice-to-text helps to add all relevant context. Good news: you can also ramble, as long as it is not generic rambling. The skill then takes this input, checks the project context and what is already in place (models, pipelines), checks principles, decides if it needs web data (in the buffer case, yes), and pulls it. Then it decides if the task is feasible or if important aspects are missing. If yes, it will ask and collect your feedback until the context is rich enough. Then it will write a good definition of done (https://www.scrum.org/resources/blog/simple-example-definition-done) - how it looks comes down to your taste. I love acceptance criteria in a very specific shape. With the DoD in place, it determines the simplest path to success. This was an important addition along the way since the agents tend to create a proper implementation theatre here, especially with the newer models. It asks the model to find the first and easiest path to fulfill the definition of done and record non-blocking gaps for future work. Then it creates the boundaries of the mission. What permissions it has, what tools it can use, and potential resource limits (like how many turns of implementation and evaluation). It also defines how the results are reviewed. It will also determine remaining blocking questions and will never set a mission to ready when these are not answered. I usually ask the model to lead every question with different alternatives I can pick from or propose an alternative. Creating a mission will never start the execution. This is a separate step. Once the mission is ready, I can review it or trust the model. Next is executing the mission. Missions are written as TOML files in the project. TOML is just a personal preference, yaml, json or MD will also work. This also lets me check in missions for future reference or work split across systems. When you run the execution command, it prepares the mission and then runs the defined execution. The agent reads the mission file; it checks the repository state again and whether the defined parts are still true. It decides, based on the mission definition, whether a worktree is required and how to create a feature branch. It also checks if there is unrelated, uncommitted work present. It has several stop criteria and returns why it had to stop, along with recommendations on how to unblock it. Next up, it decides how to break down the work into epics and stories. These are my old product owner roots. For each, it creates a smaller definition of done. Then it either starts working on each epic and story in the same agent session or uses a subagent to do it. To be honest, I did not see big differences between the two approaches. And when you follow agentic development X, you will see the pendulum swinging between both on a weekly basis. The key addition is an evaluation step: when an implementation is marked ready, a separate evaluation checks the result and declares whether the definition of done is met. If not, it does another implementation round. The run is finished when all epics and stories are done, and the final definition of done is met. This can take 30-60 minutes uninterrupted, and with some fine-tuning, you will end up with good results. ### The bottleneck part 2 This worked great, but it leaves you with creating missions. Still a kind of manual step that can slow you down. I often build greenfield setups or huge extensions of a data model. I usually know what I need to build. In the mission model, it would mean creating these missions step by step. And as always in the agentic game, we go one level up. ### The PM strikes back When I was working as a PM, and only as a PM, I actually had fun breaking down complex and long work into smaller chunks to make it possible to plan the execution and finally work against timelines. So it was a good time to bring back the good old stuff. I experimented a bit with PM skills and fine-tuned them to my understanding of how to break down a project step by step into smaller, manageable parts. Good thing with skills: I can now use this in Claude, ChatGPT, or in Pi, where I run all my development work. And by using a central task system, I can easily hook any interface up to it. First I used Linear, and now I have something home-built, because you always end up there. Depending on the project, I can produce 40 to 60 tasks, each with a clear definition of done and a clear owner type (agent, human). These tasks are mini-missions with less context about the final implementation. When implementation starts, I can evaluate a chunk of tasks with the implementation agent. It will run similar checks we did before, understand the repository state, and determine the simplest path to done. It updates the tasks. And then I have a simple command: pm-next. It launches a technical pm agent that checks all available tasks and picks the one it thinks makes the most sense (that works surprisingly well). Then it launches a subagent and, technically, a hill-climbing session. The implementation agent implements; when it thinks it has reached the definition of done, it passes it back to the PM agent, which evaluates the definition of done and the principles used. If it is not happy, it might pass it back to the subagent with feedback. Since it is always the same trigger command, I can now also run a pm-loop. The benefit of this approach is that I have a clear path to significant milestones and don't have to think about what comes next. Is it perfect? Of course not. It still happens that an implementation dives into a rabbit hole and loses itself in micro-implementation and management. But I now see the main problems start with task creation, so I have more control over designing the task context well and keeping the implementation from derailing. ### Future work The work never stops, but I like that it now happens at the process and design level. One thing I want to investigate is to push the principles further. Poteto's pstack is a good inspiration for next levels: https://x.com/poteto/article/2094457600259842065?lang=en It has more principles, better routing, and more depth to each principle. The analytics part is completely missing. Right now, I don't measure things at all (typical data person behavior). I also don't do evals. A good next step for analytics is to add a good event stream to capture task starts and finishes, tool usage (potentially), and evaluation runs (potentially with scoring). Maybe I test the council approach again vs. one evaluator. But not sure if this will change things significantly. Another thing is automatically creating tasks. I have a model shape check I can run for a setup. It checks the whole data model against a big set of principles and determines where things went off. This can now add new tasks to the setup, which will then be picked up automatically. I follow some people who are using this extensively already. If you have anything I should try, please let me know. Same if you have any questions.