Boundary and Context Are Yours

boundary, context skills, execution, verification, and delivery. Probably these things you might have heard in very very different terms in many places, like evaluation, governance, or you know, sandbox execution, creating your own skills, memory, context engineering, harness engineering, loop engineering, graph engineering. At the end of the day, everything comes into these six stages. Boundary is what it can execute, what it can't execute. So every company is different, every company has different immunity. For example, for kaas.team, my immunity is pretty big because I am I'm a small company, and my products are not something which is which is directly user facing, rather it is a service. So whatever I create, even if it breaks, for example, an ebook I create or a video lessons I create. If it breaks, I I have sufficient time. Does the same go for a pharmacy company or you know for a pharma company or a finance company or bank sector? No, it is not the case. So immunity differs from company to company. So boundary differs from company to company, regardless of what you use. I can use Claude Code and those companies can use Claude Code, but your you need to define your company's boundary, your engineering boundary, what you are building, and based on that, you can able to set what you can do, what you can't do, and this is my engineering process. For example, I can define, like, okay, you write the test and then verify for the test, and you can do this. But another company might say you have these hook. If it hits, then stop it and let the human review, and after that you execute it. So different boundary for different people. Now, context. Context is universal. In this case, it is the brain. What is the product documentation or I wouldn't even call documentation at this point? Rather, what product you are building, what domain you are building, that knowledge is yours. I am consulting for immigration teams at Jobbatical, it is an EU based product company where you know immigration laws differ from country to country, their knowledge is very very diverse from, for example, Netherlands and Germany immigrations are very different, Spanish immigrations are very different, and UK immigration is very different, Estonia's in immigration is very different, even though all are very nearby countries inside EU, but all are different countries with different immigration policies. So that context is very much needed when you are building a product for whole EU immigration, then automatically every context what you are providing that is what's shaping your product. You can't build an universe solution for all. You need to build based on that context. This is product context, and then your own technical context. I have a different standards in terms of in terms of writing code, and another big team, which is 10 20 members inside a single squad, they have a very different context in place and different standards in place and different immunity in place. For example, my front-end lighthouse score, if it crosses 95, then I'm okay with it. And there are companies like Airbnb, they might need front-end lighthouse score with a very clear point like okay, the front-end loading size need to be like 500 Kb and or or even smaller, like 100 Kb and within milliseconds it need to load. Now they need to define that parameters and that details in their tech what is okay, what is not okay.