Restrições bem definidas moldaram as melhores eras do software e minha própria carreira. Algumas abordagens opinativas, como os princípios da aplicação de 12 fatores ou o MVC, nos deram uma linguagem comum 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, mantenha-se dentro deste limite, e coisas boas virão. Eu mesmo me beneficiei ao aplicar essas restrições em alguns dos meus melhores trabalhos.
Acredito que o software nativo de IA precise de suas próprias restrições. 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ê pensa.
O limite: metade do 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ócio central e do contexto do sistema não deve exceder metade do contexto do LLM no qual você confia.
Por que metade? O contexto serve a dois propósitos. A primeira metade contém seu código. A segunda metade é onde o agente raciocina, planeja e gera. Preencha todo o contexto com código e você não deixa espaço para o pensamento. 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, em seguida, 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 criou atrito, dando origem a processos de desenvolvimento iterativos, mas também impôs disciplina. Você tinha que escolher: Do 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, os agentes de IA constroem quase tudo que você pede. O gargalo desapareceu. A disciplina desapareceu 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 superfície de produto para manter já não são 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ê envia dez funcionalidades. Duas impulsionam a retenção. As outras oito adicionam complexidade que desacelera as duas que importam. Cada linha de código se torna um passivo disfarçado de ativo.
Construtores experientes conhecem o ponto de inflexão. O código deixa de servir aos clientes para servir a si mesmo. A complexidade se torna a 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 abandoná-lo e suas equipes de atendimento ao cliente ficam frustradas silenciosamente.
No mundo antigo, você atingia esse ponto de inflexão ao longo de anos. No mundo nativo de IA, você atinge o ponto de inflexão em semanas. Os agentes nunca se cansam, nunca contestam e nunca dizem: "isso é complexo demais, devemos parar."
Como saber quando parar? Quando a IA escreve código ilimitado de graça, qual é o sinal que lhe diz que já é suficiente?
É a Regra da Meia-Janela.
Sua lógica de negócio central deve caber dentro da metade do contexto do modelo que mantém sua base de código. Meça sua base de código em tokens. Compare com metade do contexto. Se você ultrapassou, 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ê ultrapassa esse limite. 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 ligeiramente pior. A degradação composta trabalha contra você.
No momento em que você pergunta "por que nossos agentes estão andando em círculos?", você já está 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 entrega valor real aos clientes. Cada funcionalidade desnecessária, cada abstração desnecessária e cada linha de código especulativo consomem o orçamento cognitivo de sua força de trabalho de IA. Eventualmente, eles consomem 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 com mais força. 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 vários serviços: aplica-se a cada serviço independentemente. Qualquer parte do seu sistema que precise ser compreendida como um todo deve caber dentro do limite onde seus agentes raciocinam sobre o quadro completo.
A arquitetura do seu 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 pela dor.
Isso não é sobre perfeição. Você nem sempre ficará abaixo do limite. As 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 permanecer perto do limite, tomará melhores decisões sobre o que construir, o que dividir e o que excluir. A restrição lhe 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 fracasso instantâneo, mas porque permanecer perto dessa restrição me ajuda a construir software que permanece útil, sustentável e valioso ao longo do tempo. Os fundadores que se orientarem em torno disso irão longe. Aqueles que ignorarem completamente as restrições aprenderão pela dor.
Boas restrições não garantem sucesso. Elas tornam o sucesso mais provável ao remover as maneiras mais comuns de falhar. A aplicação de 12 fatores era um conjunto de princípios que não construía sua empresa de 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 é CEO da https://brain.pe - que ajuda empresas de Private Equity a criar seus cérebros digitais de IA para sua própria empresa ou negócios específicos. Você pode ter adotado a IA, mas será que a IA adotou você?
