Restrições bem definidas moldaram as melhores eras do software e a minha própria carreira. Algumas abordagens opinativas, como os princípios do 12-factor app ou o MVC, nos deram uma linguagem compartilhada para construir serviços confiáveis e projetar a separação de responsabilidades. Eram regras simples, fáceis de enunciar, difíceis de seguir perfeitamente. Elas deram origem a indústrias inteiras: SaaS, PaaS, infraestrutura em nuvem. Tudo construído sobre o alicerce de restrições bem pensadas que diziam aos construtores: aqui está o limite, fique dentro deste limite, e coisas boas virão. Eu pessoalmente me beneficiei ao aplicar essas restrições em alguns dos meus melhores trabalhos.
Acredito que o software nativo de IA precisa de sua própria restrição. Aqui está a que criei.
Sua base de código tem um tamanho máximo. Isso não é uma questão de gosto. O limite é real, mensurável e menor do que você imagina.
O limite: metade da janela de contexto do modelo de IA que seus agentes usam para construir e manter seu produto. Isso significa que o tamanho da sua lógica de negócios principal e do contexto do sistema não deve exceder metade da janela de contexto do LLM no qual você confia.
Por que metade? A janela de contexto serve a dois propósitos. A primeira metade guarda seu código. A segunda metade é onde o agente raciocina, planeja e gera. Preencha toda a janela com código e você não deixa espaço para pensar. Metade para compreensão. Metade para cognição.
A parte mais difícil dos negócios de software nunca foi construir funcionalidades.
Todo fundador de tecnologia experiente sabe disso. A parte difícil era identificar o menor pedaço de software útil para um segmento de clientes grande o suficiente, e então reunir pessoas em torno do trabalho difícil de aquisição de clientes, atendimento ao cliente e retenção.
Construir software costumava ser caro. Engenheiros custam muito. Isso criava atrito, dando origem a processos de desenvolvimento iterativos, mas também impunha disciplina. Você tinha que escolher: O que os clientes mais precisam? Qual é a menor coisa que vale a pena construir? O custo humano da engenharia mantinha as equipes focadas. As restrições criavam clareza. As melhores empresas do Vale do Silício cresceram assim.
Agora, agentes de IA constroem quase tudo que você pedir. O gargalo desapareceu. A disciplina desapareceu junto com o gargalo.
Produção livre leva à superprodução. A superprodução é o modo de falha padrão das empresas nativas de IA.
Fundadores não técnicos e investidores precisam entender isso. Mais funcionalidades, mais código e mais área de superfície do produto para manter não são mais sinais de progresso. Eles sinalizam uma empresa sem restrições de alta qualidade e, às vezes, uma falta fundamental de clareza.
A superprodução sem distribuição e consumo escaláveis cria um vazamento massivo na captura de valor. Você entrega dez funcionalidades. Duas geram retenção. As outras oito adicionam complexidade que atrasa as duas que importam. Cada linha de código se torna um passivo disfarçado de ativo.
Construtores experientes conhecem o ponto de virada. O código passa de servir aos clientes para servir a si mesmo. A complexidade se torna inimiga do produto. As equipes passam mais tempo gerenciando software do que melhorando a experiência do cliente. O sistema começa a parecer pesado, os usuários começam a desistir e suas equipes de atendimento ao cliente ficam silenciosamente frustradas.
No mundo antigo, você atingia esse ponto de virada ao longo de anos. No mundo nativo de IA, você atinge o ponto de virada em semanas. Agentes nunca se sentem cansados, nunca contestam e nunca dizem: "isso é muito complexo, devemos parar."
Como você sabe quando parar? Quando a IA escreve código ilimitado de graça, qual é o sinal que te diz que já é suficiente?
É a Regra da Meia Janela.
Sua lógica de negócios principal deve caber dentro da metade da janela de contexto do modelo que mantém sua base de código. Meça sua base de código em tokens. Compare com metade da janela de contexto. Se você estiver acima, sua força de trabalho de IA já está se degradando — não visivelmente, não dramaticamente, mas silenciosa e constantemente.
O perigo: nada quebra obviamente quando você cruza essa linha. O agente não se recusa. O código parece correto. Os testes passam. O bug que você relatou é corrigido.
Mas o agente agora opera sem compreensão total do seu sistema. O agente faz correspondência de padrões em fragmentos em vez de raciocinar sobre o todo. Regressões sutis aparecem. A lógica é duplicada em partes da base de código que o agente não consegue ver. Os problemas são "resolvidos" adicionando código onde o código existente deveria ter sido alterado.
Você não notará imediatamente. A velocidade ainda parece alta. Pull requests ainda fluem. Cada um torna o próximo um pouco pior. A degradação composta trabalha contra você.
Quando você perguntar "por que nossos agentes estão andando em círculos?", você já estará no fundo do problema.
Esta regra é disciplina de negócios disfarçada de técnica.
A simplicidade se torna sua vantagem competitiva quando a produção não custa nada. Construa a menor base de código que entregue valor real aos clientes. Cada funcionalidade desnecessária, cada abstração desnecessária e cada linha de código especulativo consome o orçamento cognitivo da sua força de trabalho de IA. Eventualmente, isso consome a capacidade de movimento da sua empresa.
Os melhores produtos sempre foram os mais simples que resolvem um problema real completamente. A penalidade por violar este princípio agora chega mais rápido e se acumula mais fortemente. Seus agentes de IA não vão contestar da mesma forma que um engenheiro sênior frustrado teria contestado.
A regra escala com a arquitetura. Startup de produto único: aplica-se a toda a base de código. Empresa com múltiplos serviços: aplica-se a cada serviço independentemente. Qualquer parte do seu sistema que precisa ser compreendida como um todo deve caber dentro do limite onde seus agentes raciocinam sobre o quadro completo.
Sua arquitetura de produto espelhará os limites cognitivos de seus agentes, quer você planeje isso ou não. Os fundadores que projetam para isso deliberadamente superarão aqueles que aprendem através da dor.
Isso não é sobre perfeição. Você nem sempre ficará abaixo da linha. Bases de código crescem. Funcionalidades são adicionadas. A complexidade se acumula. O ponto é a aspiração, não a conformidade rígida. Se você mantiver esta regra em mente e ficar perto do limite, tomará melhores decisões sobre o que construir, o que dividir e o que excluir. A restrição te dá um ponto de referência quando tudo o mais diz 'construa mais'. Às vezes, isso significa redesenhar sua arquitetura de subagentes para se adequar à regra — muito semelhante a como as equipes humanas dividem a propriedade à medida que crescem.
Aspiro a seguir esta regra no meu próprio trabalho. Não porque quebrar a regra signifique falha instantânea, mas porque ficar perto desta restrição me ajuda a construir software que permanece útil, sustentável e valioso ao longo do tempo. Os fundadores que se orientam por isso irão longe. Aqueles que ignoram totalmente as restrições aprenderão através da dor.
Boas restrições não garantem sucesso. Elas tornam o sucesso mais provável ao remover as maneiras mais comuns de falhar. O 12-factor app era um conjunto de princípios que não construía sua empresa SaaS para você, mas se você os seguisse, sua infraestrutura funcionava quando você precisava escalar. A Regra da Meia Janela funciona exatamente da mesma forma. Siga o espírito. Fique perto do limite. Construa negócios de software úteis que duram.
A simplicidade sempre vence. Agora a simplicidade vence mais rápido.
Sobre o Autor: Abhishek Parolkar é o CEO da https://brain.pe - que ajuda empresas de Private Equity a criar seus cérebros de IA digitais para sua própria empresa ou negócios específicos. Você pode ter adotado a IA, mas a IA adotou você?
