Las buenas restricciones han definido las mejores épocas del software y también mi propia carrera. Unos pocos enfoques con principios claros, como los principios de la aplicación de 12 factores o MVC, nos dieron un lenguaje común para construir servicios confiables y diseñar la separación de responsabilidades. 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 les decían a los constructores: aquí está el límite, quédate dentro de este límite, y cosas buenas sucederán. Yo personalmente me he beneficiado 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 piensas.
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 exceder 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. Si llenas toda la ventana con código, 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 con experiencia lo sabe. La parte difícil era identificar la pieza más pequeña de software útil para un segmento de clientes lo suficientemente grande, y luego reunir a las personas en torno al difícil trabajo de adquirir clientes, atenderlos y retenerlos.
Construir software solía ser caro. Los ingenieros costaban mucho. Esto generaba fricción, dando origen 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 costo 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ó junto 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 necesitan entender esto. Más funcionalidades, más código y más superficie de producto que mantener ya no son señales de progreso. Indican una empresa sin restricciones de alta calidad y, a veces, una falta fundamental de claridad.
La sobreproducción sin una distribución y un consumo escalables crea una enorme fuga en la captura de valor. Lanzas diez funciones. 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 sentirse torpe, los usuarios comienzan a abandonarlo y tus equipos de atención al cliente se frustran en silencio.
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 resisten y nunca dicen: "esto es demasiado complejo, deberíamos parar".
¿Cómo saber cuándo parar? Cuando la IA escribe código ilimitado de forma gratuita, ¿cuál es la señal que te dice que es suficiente?
Es la Regla de la Mitad de la 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 la superas, tu fuerza laboral de IA ya se está degradando, no de forma visible, ni dramática, 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 empareja patrones con 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 aún se siente alta. Las solicitudes de extracción aún fluyen. Cada una hace que la siguiente sea ligeramente peor. La degradación compuesta juega en tu contra.
Para cuando te preguntas "¿por qué nuestros agentes andan 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 consume el presupuesto cognitivo de tu fuerza laboral de IA. Con el tiempo, estos consumen la capacidad de movimiento de tu empresa.
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 agrava más. Tus agentes de IA no se resistirá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 con múltiples servicios: se aplica a cada servicio de forma independiente. Cualquier pieza de tu sistema que deba entenderse como un todo debe caber dentro del límite donde tus agentes razonan sobre el panorama completo.
La arquitectura de tu producto reflejará los límites cognitivos de tus agentes, lo planifiques o no. Los fundadores que diseñen para esto 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 implica rediseñar la arquitectura de tus 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 12 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 Mitad de la Ventana funciona exactamente igual. 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?
