Verify Outside the Agent

Where most of the company lacking at this point is verification layer. at this point, how you can write your verification layer and what are all the hooks you need to write pre-hook, post hook, what needs to happen and when to stop, how you can classify what is low risk, what is high risk. This is the main thing what I usually map with companies because they they know all these tools, usually, engineers and product managers are very smart to figure things out on their own, they figure things out how to operate and what is optimal for them to operate and so on. But when it comes to verification layer, you need to define as a company, not just as an individual, but as a company. Why? For example, you are creating a even just in a Claude Code session. you are you are prompting to AI and you you you even done a plan mode, and then after the plan you execute it. Now, if your Claude Code, the same agent is going to verify your process. Then what will happen is like since that is the one which reads your actual issue, it will always say this is my understanding, and based on my understanding, I was able to verify my code, and this is the verified code, and this is done. Is it really done? Unless and until you verify with your own holdout test, which is created beyond that agent, then only you will know whether it is verified or not. So you need to create your process in a way, you need to have execution agent as well as you need to have verification agent, where verification needs to be created as part of the plan. When you are actually creating your plan, you need to have what is the holdout test test that needs to happen. Usually until before AI, this is something product people do or QA teams do. That is the same thing we need to still do, but as a part of engineering process itself, we need to start doing it. So that layer is what we heavily focus on in our build camp and then delivery that you already know whether to merge the pull request or whether to you know have a human review for that pull request, that is up to the company and their immunity, and of course, the when you are creating very large pull requests, it is humanly impossible to you know do a review. So automatically, in your planning stage itself, in your execution stage itself, you need to make sure a bigger epic need to be you know constructed in a way it is smaller in chunks, it is not very very granular, which is hard to you know manage. What is the logical pieces to it, or it is not too long with one big epic with 120 file changes, rather, it needs to be you know modular enough to review for human as well, and in delivery as well, like how you can you know auto merge some of these PR, which is low risk. That is also something you can automate again, depends on how your delivery processes how the company's delivery process. If it is agile and continuous, then probably you can automate it. If it is always like you will park it for a week and week on delivery or every mission cycle delivery every six weeks, we are delivering it based on those details. you can do what is needed for your company.