Las buenas restricciones han moldeado las mejores épocas del software y mi propia carrera. Algunos enfoques con criterio, como los principios de la aplicación de doce factores o el MVC, nos dieron un lenguaje común para construir servicios fiables y diseñar la separación de preocupaciones. Eran reglas simples, fáciles de enunciar, difíciles de seguir a la perfección. Dieron origen a industrias enteras: SaaS, PaaS, infraestructura en la nube. Todo construido sobre la base de restricciones bien pensadas que decían a los constructores: aquí está el límite, mantente dentro de este límite, y sucederán cosas buenas. Yo me he beneficiado personalmente de aplicar estas restricciones en algunos de mis mejores trabajos.
Creo que el software nativo de IA necesita su propia restricción. Aquí está la que se me ocurrió.
Tu base de código tiene un tamaño máximo. Esto no es cuestión de gustos. El límite es real, medible y más pequeño de lo que crees.
El límite: la mitad de la ventana de contexto del modelo de IA que tus agentes utilizan para construir y mantener tu producto. Esto significa que el tamaño de tu lógica de negocio principal y el contexto del sistema no debe superar la mitad de la ventana de contexto del LLM del que dependas.
¿Por qué la mitad? La ventana de contexto cumple dos propósitos. La primera mitad contiene tu código. La segunda mitad es donde el agente razona, planifica y genera. Llena toda la ventana con código y no dejas espacio para pensar. La mitad para la comprensión. La mitad para la cognición.
La parte más difícil de los negocios de software nunca fue construir funcionalidades.
Todo fundador tecnológico experimentado lo sabe. La parte difícil era identificar la pieza de software más pequeña y útil para un segmento de clientes lo suficientemente grande, y luego reunir a las personas en torno al difícil trabajo de la adquisición de clientes, el servicio al cliente y la retención.
Construir software solía ser caro. Los ingenieros costaban mucho. Esto creaba fricción, dando lugar a procesos de desarrollo iterativos, pero también imponía disciplina. Tenías que elegir: ¿Qué necesitan más los clientes? ¿Cuál es la cosa más pequeña que vale la pena construir? El coste humano de la ingeniería mantenía a los equipos enfocados. Las restricciones creaban claridad. Las mejores empresas de Silicon Valley crecieron así.
Ahora los agentes de IA construyen casi cualquier cosa que les pidas. El cuello de botella ha desaparecido. La disciplina desapareció con el cuello de botella.
La producción gratuita conduce a la sobreproducción. La sobreproducción es el modo de fallo por defecto de las empresas nativas de IA.
Los fundadores no técnicos y los inversores deben entender esto. Más funcionalidades, más código y más superficie de producto que mantener ya no son signos de progreso. Señalan una empresa sin restricciones de alta calidad y, a veces, una falta fundamental de claridad.
La sobreproducción sin distribución y consumo escalables crea una fuga masiva en la captura de valor. Envías diez funcionalidades. Dos impulsan la retención. Las otras ocho añaden complejidad que ralentiza las dos que importan. Cada línea de código se convierte en un pasivo disfrazado de activo.
Los constructores experimentados conocen el punto de inflexión. El código pasa de servir a los clientes a servirse a sí mismo. La complejidad se convierte en enemiga del producto. Los equipos pasan más tiempo gestionando el software que mejorando la experiencia del cliente. El sistema empieza a senterse torpe, los usuarios empiezan a abandonarlo y tus equipos de cara al cliente se frustran silenciosamente.
En el mundo antiguo, llegabas a ese punto de inflexión en años. En el mundo nativo de IA, llegas al punto de inflexión en semanas. Los agentes nunca se sienten cansados, nunca se oponen y nunca dicen: "esto es demasiado complejo, deberíamos parar".
¿Cómo sabes cuándo parar? Cuando la IA escribe código ilimitado gratis, ¿cuál es la señal que te dice que ya es suficiente?
Es la Regla de la Media Ventana.
Tu lógica de negocio principal debe caber dentro de la mitad de la ventana de contexto del modelo que mantiene tu base de código. Mide tu base de código en tokens. Compárala con la mitad de la ventana de contexto. Si te pasas, tu fuerza laboral de IA ya se está degradando, no visiblemente, no dramáticamente, sino silenciosa y constantemente.
El peligro: nada se rompe obviamente cuando cruzas esta línea. El agente no se niega. El código parece correcto. Las pruebas pasan. El error que reportaste se corrige.
Pero el agente ahora opera sin una comprensión completa de tu sistema. El agente busca patrones en fragmentos en lugar de razonar sobre el conjunto. Aparecen regresiones sutiles. La lógica se duplica en partes de la base de código que el agente no puede ver. Los problemas se "resuelven" añadiendo código donde el código existente debería haber cambiado.
No lo notarás de inmediato. La velocidad sigue sintiéndose alta. Las solicitudes de extracción siguen fluyendo. Cada una hace que la siguiente sea ligeramente peor. La degradación compuesta juega en tu contra.
Para cuando preguntas "¿por qué nuestros agentes dan vueltas en círculos?", ya estás metido en el problema.
Esta regla es disciplina empresarial con ropa técnica.
La simplicidad se convierte en tu ventaja competitiva cuando la producción no cuesta nada. Construye la base de código más pequeña que ofrezca valor real a los clientes. Cada funcionalidad innecesaria, cada abstracción superflua y cada línea de código especulativo se come el presupuesto cognitivo de tu fuerza laboral de IA. Eventualmente, se comen la capacidad de tu empresa para moverse.
Los mejores productos siempre han sido los más simples que resuelven un problema real por completo. La penalización por violar este principio ahora llega más rápido y se acumula más fuerte. Tus agentes de IA no se opondrán como lo habría hecho un ingeniero senior frustrado.
La regla escala con la arquitectura. Startup de un solo producto: se aplica a toda la base de código. Empresa de múltiples servicios: se aplica a cada servicio de forma independiente. Cualquier parte de tu sistema que deba entenderse como un todo debe caber dentro del límite donde tus agentes razonan sobre el panorama completo.
Tu arquitectura de producto reflejará los límites cognitivos de tus agentes, tanto si lo planificas como si no. Los fundadores que diseñen para ello deliberadamente superarán a aquellos que aprendan a través del dolor.
Esto no se trata de perfección. No siempre estarás por debajo de la línea. Las bases de código crecen. Se añaden funcionalidades. La complejidad se acumula. El punto es la aspiración, no el cumplimiento rígido. Si mantienes esta regla en mente y te mantienes cerca del límite, tomarás mejores decisiones sobre qué construir, qué dividir y qué eliminar. La restricción te da un punto de referencia cuando todo lo demás dice "construye más". A veces esto significa rediseñar tu arquitectura de subagentes para adaptarse a la regla, muy similar a cómo los equipos humanos dividen la propiedad a medida que crecen.
Aspiro a seguir esta regla en mi propio trabajo. No porque romper la regla signifique un fracaso instantáneo, sino porque mantenerme cerca de esta restricción me ayuda a construir software que sigue siendo útil, mantenible y valioso con el tiempo. Los fundadores que se orienten en torno a esto llegarán lejos. Los que ignoren las restricciones por completo aprenderán a través del dolor.
Las buenas restricciones no garantizan el éxito. Hacen que el éxito sea más probable al eliminar las formas más comunes de fracasar. La aplicación de doce factores era un conjunto de principios que no construían tu empresa SaaS por ti, pero si los seguías, tu infraestructura funcionaba cuando necesitabas escalar. La Regla de la Media Ventana funciona exactamente de la misma manera. Sigue el espíritu. Mantente cerca del límite. Construye negocios de software útiles que perduren.
La simplicidad siempre gana. Ahora la simplicidad gana más rápido.
Sobre el autor: Abhishek Parolkar es el CEO de https://brain.pe - que ayuda a las firmas de capital privado a crear sus cerebros digitales de IA para su propia firma o para acuerdos específicos. Puede que hayas adoptado la IA, pero ¿la IA te ha adoptado a ti?
