Building my ultimate engineering workflow and team in the AI era.

Plan for actual development. 
1. Idea phase
	1. where we have a vague idea for something we want to do but haven’t discussed how or why yet. 
	2. Interview the builder and the main user subset to understand exactly what we are trying to accomplish. 
2. Research phase 
	1. First discuss if we should do it and if we yea first look and find out if someone else already built it. 
	2. If not trigger deep research phase on each of the pieces that this might require. So this is the tool specs phase essentially. Grab all the docs we will need etc. 
	3. deep focus on doc reading and best practices build the reference material for the project. And examples. Especially at scale. 
	4. Build small toy examples of a thing fast and dirty to test the limitations of our assumptions. Do this as early as possible. 
	5. Have each of the specialized agent critique the plan and research in their specific area. 
3. Design phase
	1. This is where we write the official readme with all of the mermaid docs that show how all of the systems are going to work and work together to be fed with research to spec phase?
4. Full project spec phase or feature spec
	1. This is the building of the final large spec that should live as your go line or North Star for building the project.
	2. Should have enough detail for every ticket to go through a dev cycle. What is passing and what is failing. Goal how to test etc. 
	3. these are similar for full project vs feature add on but we should talk about how they are different. Mainly size and scope. 
5. PM phase
	1. This is where we take the spec that the devs have made and turn it into smaller features and each of those features are broken down into smaller tickets/tasks.
	2. Create the metrics to test against. 
6. Dev phase
	1. An orchestrater or SE boss who determines what tickets should be worked on by the dev team
	2. Each dev takes the ticket assigned and goes through the dev cycle updates linear (plane) so no other agents take that ticket. 
	3. Should define possible roles. Data engineer, Dev ops, frontend, backend, QA, UAT, Code Review, documentation,AI engineer, 
	4. Focus on scalability and quality of code, terse to do same thing is welcomed
	5. Ticket evaluation phase where we gather all of the data on the run and save somewhere for permanent Evals
7. Final Testing Phase
	1. This is End to End as well as human in the loop evaluation of the current product. 
	2. Decision made to pass to project specs if yes go to next step. If no go to research phase for issues and feed back through system. 
8. Performance evaluation phase
	1. This is after the project we will evaluated each of the agents individually as well as each of the stages. 
	2. Give them performance evals and make notes about how it could have been done better.
	3. Give detailed examples and metrics that support that information. 
	4. This is the project debrief we should suggest changes to the systems skills tools etc in this phase. 
	5. What skills would have been useful that we didn’t have at the start?
	6. What type of messages were sent multiple times by an agent or human. We probably want a skill for that. 
	7. Should we change any of our base assumptions? This is something like python is the best for agents or TS is best for frontend. Or Claude now works like this instead. 
	8. Cost metrics work these out. 
9. Update the machine
	1. This is where you take the perform evals and put them to practice in updating the whole flow to be better. 
	2. Update all documentation especially readme to have all most relevant and up to date info possible. 
	3. Clean up the repo test scripts and non essential md files gotta go. We want a clean repo 
10. Maintenance phase
	1. Have something watch for big tickets related to this project. 
	2. Determine if they can be handled with current information. If yes start in design phase. 
	3. Make updates directly to bug ticket or sub ticker. 
	4. New features should go through all phases. Note the diff between bug and feature 



Some limitations
1. We want to be language, tool and model provider agnostic. 
2. Default to python for AI orchestration, TS for web frontend, whatever else is best for others but don’t force it just pick the best languages for each thing. Identified in the research phase. 
3. Make sure to have skills that critique each of the phases. Especially planning and skills like code review. 
4. Figure out prime because that setup is not efficient enough
5. Track your token usage overall and per provider. Have lookups to see if you have enough cash or usage left to do the task. Always assume 200% of what AI predicts. Have a balancing feature that reviews metrics for our performance like number of tokens estimated vs used at each phase or ticket and get better at predicting. 
6. Should have something like a cron that checks if there are new tickets with specific label or something to kick off a run. 
7. Notifications if an agent is stuck. 
8. Give them 3 tries to implement if they fail tell me and we will have to manually work together.


Other thoughts
1. Can you combine the idea from zettlekasten for the priming of an agent. Like each folder has an atomic note about what it does. With an index of sorts so if an agent traverses down the path it only needs to originally read these to find where info is. It could write these live I suppose and always update. And have a check in performance how that did? Make sure they are up to date. 
2. Understand the knowledge path of rules for coding agents. Like Claude local vs global. How to keep these in line without overlap. 
3. Use the right tool or mcp for everything. Perplexity for research? Claude for code? Who’s the best at design? 
4. What is duckDB?
5. Try and build with open source first unless prev specified. 
6. All phase fit into explore execute review and maintain. 
7. How can we build simulations into this? 
8. News watcher bot that tried to keep me up to date on things that could improve our system? 


Base assumptions
1. TDD
2. Markdown for all human reading. Combo of md, xml, json and toon for AI to read?
3. Pydantic AI is king for building agents. 
4. Strict linting and type checks. And formatting. 
5. Modular design of everything. It might be put into another project built it according. That means in python make modules that we then use to do the business/task specific things. Same with TS or React. Make the components and then be able to use them across projects. Etc applies to all languages and tools. 
6. Look up voice open source that is killing eleven labs. I want AI to read to me as well. 
7. Open source everything you can. Make them pay for using servers or whatever. 
8. MCP servers where available but with the assumption that they are not eating context windows track this rigorously.
9. If there is an open source option that is just as good we should use that. Especially if self hosted.
10. When I say linear I mean we need to integrate with PM tools. Linear and Pane seem to be most important to me. Linear work Plane self hosted private workflow. Lets test on both.


Projects (DO NOT BGUILD YET, JUST IDEAS)
1. Beads for the concept of spac-ing correctly. 
2. RSS feed
3. EV gambling.
4. CLI baby tools 
5. Better TUI IDE experience. 
6. Dev cost metrics
7. Interviewing UI
8. Skill builder 
9. Can you build open source linear? Is that pane? https://github.com/makeplane/plane
10. Build a list of the tools I actually use.
11. Open source Calendar?
12. Snowflake example data research.


Important notes
1. You must explicitly say create an agent team for us to use that feature.



Agents
- Research
- Python
- Security
- DevOps
- TypeScript
- UI/UX
- Data Engineer
- SQL
- NoSQL
- Rust
- Operating Systems
- Project Manager
- Team Lead (CEO or CVO)
- Agent Builder
- Code Reviewer
- Quality Assurance
- UAT with playwrite?
- Video Testing Agent? Maybe use Googles video software?
- Data Scientist (AI/ML)
- Data Analyst (BI)
- Plan Critic
- Devil's Advocate
- Interviewer
- Changelog and Git commit Writer (And ticket updates? so like a PM skill?)

Some of these are buckets of a team.

Search agent should be Haiku but complier of search should be Opus. Most coding things should be sonnet. reviewers should opus. documentation haiku or notifications at least.

Having as many keyboard shortcut commands as possible, especially for command line interfaces, or for building small command line interfaces that can help us improve any projects or ideas, is also a big part of our workflow and how we should think about this in the future. Like if I just want to spin up a quick command line that accesses the HubSpot API and pulls deal data down based on deal ID or something along those lines. Just as an example of something that we've done in the past, I want to be able to build those quickly and easily and efficiently. And I also want to get aliases and bash aliases involved as well. The least amount of typing that we can possibly do to get things to do what we want, that's the best case scenario.