Good constraints have shaped the best eras of software and my own career. A few opinionated approaches, like the 12-factor app principles or MVC, gave us a shared language for building reliable services and designing 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 benefited from applying these constraints in some of my best 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. This means the size of your core business logic and system context should not exceed half of the context window of whichever LLM you rely on.
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, customer service, and retention.
Building software used to be expensive. Engineers cost a lot. This created friction, giving birth to iterative development processes, but it 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 has 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, and more product surface area to maintain are no longer signs of progress. They signal a company without high-quality constraints, and sometimes, a fundamental 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. Teams spend more time managing software than improving the customer experience. The system starts to feel clunky, users begin to drop off, and your customer-facing teams silently grow 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, and 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 it to half the context window. If you are over, your AI workforce is already degrading—not visibly, not dramatically, but 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 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, and 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 means re-designing your sub-agent architecture to suit the rule—very similar to how human teams divide ownership as they grow.
I aspire to follow this rule in my own work. Not because breaking the rule means instant failure, but 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 was a set of principles that didn't build your SaaS company for you, but if you followed them, your infrastructure worked when you needed to scale. The Half-Window Rule works the exact 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 their own firm or specific deals. You may have adopted AI, but has the AI adopted you?
