Extremely valuable advice sirr!! This covers basically everything in my fragmented notes about AI assisted dev. Js one thing though, do u maintain a change log or smt? Is that necessary?
I wholeheartedly endorse this approach. I’m gaining a wealth of knowledge by utilizing AI in this way. As a systems engineer, I typically don’t implement much, but I do specify functionality at a more abstract requirement level for my team. Now, I can iterate on my ideas much faster before discussing them in more detail with the developers.
Thanks for such a detailed article with a lot of practical advice. I like the planning spec approach and need to explore that more in 2026. I too have had success with AI reviewing AI for a second opinion.
This is a masterclass in disciplined AI-assisted development. The emphasis on planning, chunked iteration, context, testing, and human oversight shows that AI isn’t a replacement, it’s a force multiplier. Your workflow demonstrates how to stay in control, maintain quality, and continuously grow as a developer while leveraging AI.
A key takeaway: Developers should use only familiar tech stacks, as human review of AI-generated code requires understanding the implementation. It goes without saying that this step would be like a bottleneck to the process and could end up slowing progress. What do you guys think?
Management would more than likely call it a bottle neck; However, I would view it as a necessary inspection point. If you are writing and maintaining true production code that has any level of complexity to it you, the human, better understand what it is that you are allowing into the repos. It will be you who will be held responsible, not the LLM. Mature software practices always apply.
I don't know if it's really a bottleneck though. If you can't review what the agent wrote, what are you actually doing? That's the part that matters. I'd rather be slower and know what's in my codebase than ship faster without knowing.
Great post, I think the most interesting so far. Any chance to share some examples of plan templates or any docs that you feed AI to AI? Or do you use default ones in Cursor / Antigravity? For me the default ones are okayish for small tasks, but I still prefer to build my specifications that go much deeper than default ones
Thanks Addy, for sharing this detailed workflow, it's incredibly thoughtful and aligns closely with how I approach how AI augment engineer workflow. I especially appreciate the emphasis on upfront specs, iterative chunks, extensive context, and always keeping a human in the loop with careful review and testing. These principles have been core to my own process too.
On that note, I've been building something similar: AI-DevKit, a CLI toolkit for structured AI-assisted development with phase-based templates (requirements, design, planning, etc.) and setups for tools like Cursor, Claude Code, etc. It's all about enforcing disciplined workflows while keeping the engineer in control.
I took a brief look at your AI-devkit. What I saw looked good. Of course, I'm a structured software development type a guy; Most of what I worked on over the years was contract driven requirements for the final products. We had latitude in how we implemented those requirements but we also had long-term maintenance contracts. What you've layed out is essentially the, older, Waterfall SDLC, which is great for control. Of course, a set of feedback edges can be added. That is essentially what a spiral model is. I intend to check out your repo a little more deeply :-)
Thank you so much for taking a look and sharing your perspective. The idea of "Waterfall SDLC" is spot on. I want to create a workflow that can happen in minutes, and the engineer is still at the center, going through each step to ensure problem understanding, proper planning, and accurate execution.
Let's connect and share back if you have any ideas or face any problems when trying it.
I have a recurring concern, especially in light of recent reading and discussions.
In your opinion, is TDD still truly relevant when developing with AI, particularly when it acts as an assistant directly integrated into the code editor?
Two main positions seem to be in opposition, and I partially agree with each of them.
1. TDD as a framework for controlling AI
On the one hand, some believe—and this is also a view I share—that TDD allows for better control of what the AI produces. By writing tests upfront, we clearly define the expected behavior, which limits deviations, reduces ambiguity, and guides the AI toward an implementation that aligns with the developer's intent.
2. Let AI Explore Freely
On the other hand, some argue that since AI already has a good idea of what it will produce for a given feature, imposing TDD on it is almost like asking a cheetah to pretend it knows how to run.
According to this approach, it would be more effective to:
let the AI propose a complete implementation of the requested feature, then intervene with an expert eye to adjust:
"this part should be implemented this way, that part differently."
Proponents of this approach also highlight a significant advantage: letting AI explore to its full potential can allow it to produce code covering edge cases that the developer themselves wouldn't have considered, which can be very beneficial.
My Question
I find both sets of arguments quite relevant. However, this leads me to wonder:
is it still worthwhile to invest so much energy in mastering TDD today?
The distinction between CLAUDE.md for process rules and Skills for durable context—that's the gap I keep bumping into.
I've been working on something similar with Glenn Ericksen (https://x.com/glennericksen). What we've found is that CLAUDE.md handles process stuff well ("prefer functional style," "follow lint rules"), but domain constraints are harder to make stick. Things like "we never do X in this codebase because Y"—the agent drifts once it's outside the files you've explicitly shown it.
Have you hit that wall? Or does your setup handle domain-specific rules better than we've managed?
People act like LLMs can code but half the time they generate garbage that takes longer to fix than writing it yourself. Sure, use them for boilerplate, but calling yourself a developer while copying prompts is a stretch.
Thank you for sharing!
My pleasure!
Can’t believe this is free! My new year’s resolution should look like this.
Extremely valuable advice sirr!! This covers basically everything in my fragmented notes about AI assisted dev. Js one thing though, do u maintain a change log or smt? Is that necessary?
I wholeheartedly endorse this approach. I’m gaining a wealth of knowledge by utilizing AI in this way. As a systems engineer, I typically don’t implement much, but I do specify functionality at a more abstract requirement level for my team. Now, I can iterate on my ideas much faster before discussing them in more detail with the developers.
Thanks for such a detailed article with a lot of practical advice. I like the planning spec approach and need to explore that more in 2026. I too have had success with AI reviewing AI for a second opinion.
Love it!
This is a masterclass in disciplined AI-assisted development. The emphasis on planning, chunked iteration, context, testing, and human oversight shows that AI isn’t a replacement, it’s a force multiplier. Your workflow demonstrates how to stay in control, maintain quality, and continuously grow as a developer while leveraging AI.
TLDR don’t be lazy with AI
A key takeaway: Developers should use only familiar tech stacks, as human review of AI-generated code requires understanding the implementation. It goes without saying that this step would be like a bottleneck to the process and could end up slowing progress. What do you guys think?
Management would more than likely call it a bottle neck; However, I would view it as a necessary inspection point. If you are writing and maintaining true production code that has any level of complexity to it you, the human, better understand what it is that you are allowing into the repos. It will be you who will be held responsible, not the LLM. Mature software practices always apply.
I don't know if it's really a bottleneck though. If you can't review what the agent wrote, what are you actually doing? That's the part that matters. I'd rather be slower and know what's in my codebase than ship faster without knowing.
Great post, I think the most interesting so far. Any chance to share some examples of plan templates or any docs that you feed AI to AI? Or do you use default ones in Cursor / Antigravity? For me the default ones are okayish for small tasks, but I still prefer to build my specifications that go much deeper than default ones
Thanks Addy, for sharing this detailed workflow, it's incredibly thoughtful and aligns closely with how I approach how AI augment engineer workflow. I especially appreciate the emphasis on upfront specs, iterative chunks, extensive context, and always keeping a human in the loop with careful review and testing. These principles have been core to my own process too.
On that note, I've been building something similar: AI-DevKit, a CLI toolkit for structured AI-assisted development with phase-based templates (requirements, design, planning, etc.) and setups for tools like Cursor, Claude Code, etc. It's all about enforcing disciplined workflows while keeping the engineer in control.
Would love to hear your feedback if you get a chance to check it out: https://github.com/codeaholicguy/ai-devkit (or https://ai-devkit.com/).
Thanks again for the great post!
I took a brief look at your AI-devkit. What I saw looked good. Of course, I'm a structured software development type a guy; Most of what I worked on over the years was contract driven requirements for the final products. We had latitude in how we implemented those requirements but we also had long-term maintenance contracts. What you've layed out is essentially the, older, Waterfall SDLC, which is great for control. Of course, a set of feedback edges can be added. That is essentially what a spiral model is. I intend to check out your repo a little more deeply :-)
Thank you so much for taking a look and sharing your perspective. The idea of "Waterfall SDLC" is spot on. I want to create a workflow that can happen in minutes, and the engineer is still at the center, going through each step to ensure problem understanding, proper planning, and accurate execution.
Let's connect and share back if you have any ideas or face any problems when trying it.
Thank you for your work, thoughts, and image flair
++ Good Post, Also, start here how to build tech, Crash Courses, 100+ Most Asked ML System Design Case Studies and LLM System Design
How to Build Tech
https://open.substack.com/pub/howtobuildtech/p/how-to-build-tech-10-how-to-actually?r=14q3sp&utm_campaign=post&utm_medium=web&showWelcomeOnShare=false
https://open.substack.com/pub/howtobuildtech/p/how-to-build-tech-06-how-to-actually?r=14q3sp&utm_campaign=post&utm_medium=web&showWelcomeOnShare=false
https://open.substack.com/pub/howtobuildtech/p/how-to-build-tech-05-how-to-actually?r=14q3sp&utm_campaign=post&utm_medium=web&showWelcomeOnShare=false
https://open.substack.com/pub/howtobuildtech/p/how-to-build-tech-04-how-to-actually?r=14q3sp&utm_campaign=post&utm_medium=web&showWelcomeOnShare=false
https://open.substack.com/pub/howtobuildtech/p/how-to-build-tech-03-how-to-actually?r=14q3sp&utm_campaign=post&utm_medium=web&showWelcomeOnShare=false
https://open.substack.com/pub/howtobuildtech/p/how-to-build-tech-01-the-heart-of?r=14q3sp&utm_campaign=post&utm_medium=web&showWelcomeOnShare=false
https://open.substack.com/pub/howtobuildtech/p/how-to-build-tech-02-how-to-actually?r=14q3sp&utm_campaign=post&utm_medium=web&showWelcomeOnShare=false
Crash Courses
https://open.substack.com/pub/crashcourses/p/crash-course-09-part-1-hands-on-crash?utm_campaign=post-expanded-share&utm_medium=web
https://open.substack.com/pub/crashcourses/p/crash-course-07-hands-on-crash-course?utm_campaign=post-expanded-share&utm_medium=web
https://open.substack.com/pub/crashcourses/p/crash-course-06-part-2-hands-on-crash?utm_campaign=post-expanded-share&utm_medium=web
https://open.substack.com/pub/crashcourses/p/crash-course-04-hands-on-crash-course?r=14q3sp&utm_campaign=post&utm_medium=web&showWelcomeOnShare=false
https://open.substack.com/pub/crashcourses/p/crash-course-03-hands-on-crash-course?r=14q3sp&utm_campaign=post&utm_medium=web&showWelcomeOnShare=false
https://open.substack.com/pub/crashcourses/p/crash-course-02-a-complete-crash?r=14q3sp&utm_campaign=post&utm_medium=web&showWelcomeOnShare=false
https://open.substack.com/pub/crashcourses/p/crash-course-01-a-complete-crash?r=14q3sp&utm_campaign=post&utm_medium=web&showWelcomeOnShare=false
LLM System Design
https://open.substack.com/pub/naina0405/p/very-important-llm-system-design-be9?utm_campaign=post-expanded-share&utm_medium=web
https://open.substack.com/pub/naina0405/p/very-important-llm-system-design-577?utm_campaign=post-expanded-share&utm_medium=web
https://open.substack.com/pub/naina0405/p/very-important-llm-system-design-4ea?utm_campaign=post-expanded-share&utm_medium=web
https://open.substack.com/pub/naina0405/p/very-important-llm-system-design-499?r=14q3sp&utm_campaign=post&utm_medium=web&showWelcomeOnShare=false
https://open.substack.com/pub/naina0405/p/very-important-llm-system-design-63c?r=14q3sp&utm_campaign=post&utm_medium=web&showWelcomeOnShare=false
https://open.substack.com/pub/naina0405/p/very-important-llm-system-design-bdd?r=14q3sp&utm_campaign=post&utm_medium=web&showWelcomeOnShare=false
https://open.substack.com/pub/naina0405/p/very-important-llm-system-design-661?r=14q3sp&utm_campaign=post&utm_medium=web&showWelcomeOnShare=false
https://open.substack.com/pub/naina0405/p/very-important-llm-system-design-83b?r=14q3sp&utm_campaign=post&utm_medium=web&showWelcomeOnShare=false
https://open.substack.com/pub/naina0405/p/very-important-llm-system-design-799?r=14q3sp&utm_campaign=post&utm_medium=web&showWelcomeOnShare=false
https://open.substack.com/pub/naina0405/p/very-important-llm-system-design-612?r=14q3sp&utm_campaign=post&utm_medium=web&showWelcomeOnShare=false
https://open.substack.com/pub/naina0405/p/very-important-llm-system-design-7e6?r=14q3sp&utm_campaign=post&utm_medium=web&showWelcomeOnShare=false
https://open.substack.com/pub/naina0405/p/very-important-llm-system-design-67d?r=14q3sp&utm_campaign=post&utm_medium=web&showWelcomeOnShare=false
https://open.substack.com/pub/naina0405/p/most-important-llm-system-design-b31?r=14q3sp&utm_campaign=post&utm_medium=web&showWelcomeOnShare=false
https://naina0405.substack.com/p/launching-llm-system-design-large?r=14q3sp
https://naina0405.substack.com/p/launching-llm-system-design-2-large?r=14q3sp
[https://open.substack.com/pub/naina0405/p/llm-system-design-3-large-language?r=14q3sp&utm_campaign=post&utm_medium=web&showWelcomeOnShare=false
https://open.substack.com/pub/naina0405/p/important-llm-system-design-4-heart?r=14q3sp&utm_campaign=post&utm_medium=web&showWelcomeOnShare=false
https://open.substack.com/pub/naina0405/p/very-important-llm-system-design-63c?r=14q3sp&utm_campaign=post&utm_medium=web&showWelcomeOnShare=false
I have a recurring concern, especially in light of recent reading and discussions.
In your opinion, is TDD still truly relevant when developing with AI, particularly when it acts as an assistant directly integrated into the code editor?
Two main positions seem to be in opposition, and I partially agree with each of them.
1. TDD as a framework for controlling AI
On the one hand, some believe—and this is also a view I share—that TDD allows for better control of what the AI produces. By writing tests upfront, we clearly define the expected behavior, which limits deviations, reduces ambiguity, and guides the AI toward an implementation that aligns with the developer's intent.
2. Let AI Explore Freely
On the other hand, some argue that since AI already has a good idea of what it will produce for a given feature, imposing TDD on it is almost like asking a cheetah to pretend it knows how to run.
According to this approach, it would be more effective to:
let the AI propose a complete implementation of the requested feature, then intervene with an expert eye to adjust:
"this part should be implemented this way, that part differently."
Proponents of this approach also highlight a significant advantage: letting AI explore to its full potential can allow it to produce code covering edge cases that the developer themselves wouldn't have considered, which can be very beneficial.
My Question
I find both sets of arguments quite relevant. However, this leads me to wonder:
is it still worthwhile to invest so much energy in mastering TDD today?
It's all a bit of a jumble in my head 😄.
Any answer would help me a lot.
Thanks in advance 🙏
The distinction between CLAUDE.md for process rules and Skills for durable context—that's the gap I keep bumping into.
I've been working on something similar with Glenn Ericksen (https://x.com/glennericksen). What we've found is that CLAUDE.md handles process stuff well ("prefer functional style," "follow lint rules"), but domain constraints are harder to make stick. Things like "we never do X in this codebase because Y"—the agent drifts once it's outside the files you've explicitly shown it.
Have you hit that wall? Or does your setup handle domain-specific rules better than we've managed?
People act like LLMs can code but half the time they generate garbage that takes longer to fix than writing it yourself. Sure, use them for boilerplate, but calling yourself a developer while copying prompts is a stretch.