# The Half-Window Rule for AI-Native Businesses

> A constraint for knowing when to stop building features or products.

**Published by:** [Abhishek Parolkar's Writings](https://abhishek.parolkar.com/)
**Published on:** 2026-07-19
**URL:** https://abhishek.parolkar.com/the-half-window-rule-for-ai-native-businesses

## Content

Good constraints have shaped the best eras of software and my own career. Few opinionated approaches like the 12-factor app principles or MVC gave us a shared language for building reliable services and design the separation of concerns. These were simple rules, easy to state, hard to follow perfectly. They gave birth to entire industries. SaaS, PaaS, cloud infrastructure. All built on the back of well-thought constraints that told builders: here is the boundary, stay within range of this boundary, and good things follow. I have personally benefitted from applying these constraints in best of my work. I believe AI-native software needs its own constraint. Here is the one I came up with. Your codebase has a maximum size. This is not a matter of taste. The limit is real, measurable, and smaller than you think. The limit: half the context window of the AI model your agents use to build and maintain your product. It also means size of your core business logic/context should not be more than half of the most advanced LLM model there is. Why half? The context window serves two purposes. The first half holds your code. The second half is where the agent reasons, plans, and generates. Fill the whole window with code and you leave zero room for thinking. Half for comprehension. Half for cognition. The hardest part of software businesses was never building features. Every experienced tech founder knows this. The hard part was identifying the smallest piece of useful software for a large enough customer segment and then rallying people around the difficult work of customer acquisition, service, and retention. Building software used to be expensive. Engineers cost a lot. This created pain, gave birth to iterative development processes, but also imposed discipline. You had to choose. What do customers need most? What is the smallest thing worth building? The human cost of engineering kept teams focused. Constraints created clarity. The best companies in Silicon Valley grew this way. Now AI agents build almost anything you ask for. The bottleneck disappeared. The discipline disappeared with the bottleneck. Free production leads to overproduction. Overproduction is the default failure mode of AI-native companies. Non-technical founders and investors need to understand this. More features, more code, more product surface area to maintain. These are no longer signs of progress. They signal a company without good quality constraints (sometimes it also signals lack of clarity). Overproduction without scalable distribution and consumption creates massive leakage in value capture. You ship ten features. Two drive retention. The other eight add complexity that slows down the two that matter. Every line of code becomes a liability disguised as an asset. Experienced builders know the tipping point. Code shifts from serving customers to serving itself. Complexity becomes the product's enemy. The team spends more time managing software than improving the customer experience. The system starts to full clunky users start to hate it and your customer facing people start to silently resent or get frustrated. In the old world, you reached that tipping point over years. In the AI-native world, you reach the tipping point in weeks. Agents never feel tired, never push back, never say "this is too complex, we should stop." How do you know when to stop? When AI writes unlimited code for free, what is the signal that tells you enough? It is The Half-Window Rule. Your core business logic must fit within half the context window of the model that maintains your codebase. Measure your codebase in tokens. Compare to half the context window. If you are over, your AI workforce is already degrading. Not visibly. Not dramatically. Silently and steadily. The danger: nothing obviously breaks when you cross this line. The agent does not refuse. The code looks correct. Tests pass. The bug you reported gets fixed. But the agent now operates without full comprehension of your system. The agent pattern-matches on fragments instead of reasoning about the whole. Subtle regressions appear. Logic gets duplicated in parts of the codebase the agent cannot see. Problems get "solved" by adding code where existing code should have changed. You will not notice immediately. Velocity still feels high. Pull requests still flow. Each one makes the next slightly worse. Compound degradation works against you. By the time you ask "why do our agents keep going in circles?" you are deep in the problem. This rule is a business discipline in technical clothing. Simplicity becomes your competitive advantage when production costs nothing. Build the smallest codebase that delivers real value to customers. Every unnecessary feature, every unneeded abstraction, every line of speculative code eats your AI workforce's cognitive budget. Eventually these eat your company's ability to move. The best products have always been the simplest ones that solve a real problem completely. The penalty for violating this principle now arrives faster and compounds harder. Your AI agents will not push back the way a frustrated senior engineer would have. The rule scales with architecture. Single-product startup: applies to the whole codebase. Multi-service company: applies to each service independently. Any piece of your system that must be understood as a whole must fit within the boundary where your agents reason about the full picture. Your product architecture will mirror the cognitive boundaries of your agents. Whether you plan for this or not. The founders who design for this deliberately will outrun those who learn through pain. This is not about perfection. You will not always stay under the line. Codebases grow. Features get added. Complexity accumulates. The point is aspiration, not rigid compliance. If you keep this rule in mind and stay close to the boundary, you will make better decisions about what to build, what to split apart, and what to delete. The constraint gives you a reference point when everything else says "build more". Sometimes this may mean that you re-design the sub-agents' organization to suite the rule somewhat similar to how division of work and responsibility happened in human-teams. I aspire to follow this rule in my own work. Not because breaking the rule means instant failure. Because staying close to this constraint helps me build software that remains useful, maintainable, and valuable over time. The founders who orient around this will go far. The ones who ignore constraints entirely will learn through pain. Good constraints do not guarantee success. They make success more likely by removing the most common ways to fail. The 12-factor app were set of principles which did not build your SaaS company for you but if you followed its principles, your infrastructure worked when you needed to scale. The Half-Window Rule works the same way. Follow the spirit. Stay close to the boundary. Build useful software businesses that last. Simplicity always wins. Now simplicity wins faster. -------------------------------------------------------- About the Author: Abhishek Parolkar is the CEO of https://brain.pe - which helps Private Equity firms create their digital AI brains for own firm or specific deals. You may have adopted AI but has the AI adopted you? Follow his work at Linkedin or X .

## Publication Information

- [Abhishek Parolkar's Writings](https://abhishek.parolkar.com/): Publication homepage
- [All Posts](https://abhishek.parolkar.com/): More posts from this publication
- [RSS Feed](https://api.paragraph.com/blogs/rss/@parolkar): Subscribe to updates
- [Twitter](https://twitter.com/parolkar): Follow on Twitter