En la mañana del lunes 2 de marzo me encontré con que Copilot, Claude y Gemini tenían problemas. No era yo ni mi conexión: mi segunda conexión de internet desde mi segunda computadora igual. Lo único que necesitaba era una corrección de ortografía. Lo confieso: no he cambiado todavía el teclado de la computadora; y no me afecta demasiado si una LLM me puede corregir la ortografía.
Soy de los que programan desde hace muchos años, con una hoja en blanco. No me afecta estar sin LLM (finalmente la ortografía empecé a arreglarla con Qwen en modo local antes de que Copilot reaccionara después de 20 minutos de intentos más tarde).
Quizá el título te parezca confuso. Aviso que cuando uso “sistemas” me refiero a programas de computadora, no hardware.
Hay una forma de organizar sistemas en base a un diseño previo y preciso, que suele quedarse corto cuando hay requisitos cambiantes, si lo burocratizas demasiado. A ese nivel de diseño y una arquitectura en mente, se le llama a veces catedral, o monolito. Tiene una ventaja muy fuerte: son menos archivos, por lo que es más fácil encontrar errores o respaldar.
La arquitectura contraria es ir añadiendo pequeños módulos a los sistemas. Se le llama bazar. Imagínate un puesto de tianguis, o lo que se llama top manta en otros países. Difícil de controlar, y la idea es que los pequeños archivos van a ser más rápidos. En realidad, si no has tenido que investigar qué archivos tienen referencia a una función, vas a quedar con código espagueti imposible de mantener. Una vez que más o menos funciona, vas a encontrarte problemas por cosas que no sabías que existían, o dependencias que nadie sabe de dónde salieron.
La solución muchas veces es ir hacia programación funcional, y hacer el equivalente de una plaza comercial: una función. No comprar ropa en McDonald’s y hamburguesas en Cinemex.
El 13 de septiembre de 2010 estaba “discutiendo” o explicando en un pizarrón a uno de mis programadores por qué teníamos que manejar un monolito compacto en factura electrónica. No podías distribuir el proceso. Y en esas me interrumpe mi jefa inmediata, una contadora joven que después descubrimos mentía a los socios y a los empleados en algunas cosas. Su interrupción era sobre los problemas técnicos: ella, como contadora, dijo que los problemas no eran ciertos. ¿Cómo podía ella saber que no deben usarse más de 50 sesiones FTP en un servidor con 2 GB de RAM?
Finalmente yo renuncié. Me pidieron quedarme, y dos meses después entregué el sistema completo para un máximo de 10 FTP simultáneos, porque lo demás iba a ser vía XML-RPC. El 23 de noviembre de ese mismo año me quitaron del puesto, pasándome a proyectos especiales, y todo se les fue abajo. Dos años después mi área funcionaba, pero el problema de FTP los llevó a implementar cientos de máquinas virtuales en clientes de 5 USD al mes, en los servidores del cliente. Ahora imagina el desastre que era actualizar entre 100 y 200 máquinas virtuales en clientes que no daban utilidad.
Este desastre terminó en que me negué a hackear 200 máquinas virtuales y quitar la integridad referencial de lo que hice tres años antes. Te lo comento, lector, porque la catedral tiene que ver con control: es más fácil sacar respaldo y detectar problemas en una sola cuenta de banco que en 200 cuentas de banco.
He convertido sistemas de microservicios a monolitos con cuidado, haciendo pruebas, modificando enrutamientos (routers) y eliminando uno por uno los archivos secundarios. No solo disminuyes el costo, sino que ganas control. A lo que me refiero es que hay personas que usan archivos o vistas LLM, Twig, Blades o su forma de hacer templates, de manera que te encuentras con un desastre sin precedentes e inmanejable.
Un ejemplo no tan extremo es bajar AdminLTE, una interfaz muy bonita de PHP para dashboards. El problema es que usaba varios miles de archivos. ¿Cómo puedes auditar eso? ¿Cómo puedes hacer sistemas de factura electrónica, de sector salud o cualquier sector de finanzas con esa estructura?
Adjunto una pantalla de adminlte
Es un buen software, y su manejo de data tables es muy intuitivo.
Si te rompen una ventana en tu edificio, o se descompone una PC, tratas de arreglarlo lo más pronto posible.
Cuando tienes miles de archivos, no es tan simple.
¿Qué haces? Usando el ejemplo de PHP:
// file uno.php
echo "uno";
// file dos.php
echo "dos";
Puedes tener cientos de archivos así.
Resulta mucho mejor usar:
// file numeros.php
<?php
function uno() {
return "uno";
}
function dos() {
return "dos";
}
?>
Pero hay algo más. Trabajé unos 15 a 20 minutos y Copilot me volvió a dar problemas. Estoy revisando ortografía ahora en mi Qwen local.
¿Tienes control de tus archivos, o no?
Si usas un celular Android, respaldar tus fotos y documentos bajados es bastante complicado. Lo mismo sucede cuando tienes miles de pequeños archivos o microservicios.
Claude y Gemini pueden manejar un entorno de tokens grande, que nadie sabe medir. Por ejemplo, he cargado en Claude archivos PDF de 400 hojas y pedir un análisis completo, y lo hace. No perfecto, pero puede hacerlo. Gemini tiene en su ventana y textarea, o donde escribes, capacidad para unas siete hojas de texto. Pero la conversación tiene un límite.
¿Qué tiene que ver esto?
¿Cómo vas a depurar decenas de archivos que no sabes qué hacen?
La métrica durante muchos años fue evitar funciones mayores de 80 líneas, que es lo que podías ver en tu computadora. Algunos dicen 50 líneas; en lo personal creo que debes evitar archivos demasiado pequeños, a menos que no se modifiquen y sea importante que no se modifiquen. Pero usando casos como el ejemplo de uno.php y dos.php, es mucho más fácil trabajar con menos archivos.
Y ahí tenemos el problema.
La paradoja de la búsqueda
La “paradoja de la búsqueda” se refiere comúnmente al dilema filosófico de Menón: es imposible buscar lo que no se conoce (porque no sabes qué buscas) y tampoco puedes buscar lo que ya conoces (porque no necesitas buscarlo). El concepto implica que la búsqueda de nuevo conocimiento es intrínsecamente paradójica.
Alguna vez has gastado de más en tu quincena?
Seguro que sí. Quizá aprendiste a limitarte y ya no te pasa. Esos límites son importantes. ¿Le darías control de tu PC, cuenta de correo y cuenta de banco a una inteligencia artificial? No voluntariamente.
A eso se le llama virus o ransomware.
Existen salvaguardas como no gastar de más, cancelar tarjetas de crédito, salir con una cantidad razonable de dinero. La mayoría de las personas confía en su autocontrol. Pero hay un nuevo tipo de lectores que pueden leer de manera inalámbrica los chips de tarjeta de crédito y vaciártela. Una de las soluciones más comunes es no perder de vista tu tarjeta.
Pero eso no te protege de ti mismo. Imagínate.
Quizá has oído de PayPal. He sabido de casos de personas a las que les congeló recursos o dinero.
Mis tarjetas de débito tienen un límite. Claro, son de débito: no necesito las de crédito. No pienso en situaciones ideales, solo en situaciones reales. Y además tengo cuidado de tener las tarjetas bloqueadas cuando no las uso.
He convertido sistemas de cientos o miles de archivos en menos de 20. No porque me gusten las catedrales. Son mucho más fáciles de mantener, y puedes hacerlos crecer con una nueva sección, o con un microservicio que quizá después descubres que no es necesario. A veces las API y losmicroservicios son necesarios. Pero dije “A VECES”. No puedes tener miles de dependencias react en un entorno de hospitales. “Puedes” hasta que te cae una auditoría de Cofepris. Cada microservice, api, es un punto de ataque.
Pero la única forma de trabajar con inteligencia artificial en Agentics es dándole control de tu “tarjeta de crédito” o tu disco. Virus. Metiste un virus tú solito. Solo puedes engañar a aquellos que son muy codiciosos o demasiado nobles.
No seas codicioso.
Ahora vamos a ver las ventanas de entorno.
Hemos visto por otros ejercicios en la sección Pruébalo ya que Claude, por lo general, maneja un máximo de 1000 a 1200 líneas sin problemas, pero se traba o usa el 100% de recursos en modo gratuito. Copilot, su ventana son 400 líneas. Poco a poco te vas a dar cuenta de un límite real al respecto. No es que se trate de que más o menos líneas sean malas. Es lo que puede manejar un LLM.
En las finanzas no debes gastar más de tus quincenas. En ventanas de contexto no puedes pedir más de lo que el LLM soporte.
Quiero dejar claro que mi recomendación en lenguajes como PHP es dejar procesos muy delicados en su propio archivo, que además casi no tiene cambios. Y es muy raro que pase de 5000 líneas en un archivo por varias razones. La catedral es entonces un mecanismo para saber dónde está tu material, y es más fácil encontrar un problema en un archivo grande que en miles de archivos pequeños.
Por lo general, tengo que hacer siempre un programa cuando tomo control de nuevos proyectos, que me busque todas las ocurrencias de cada cadena x en los archivos de varios subdirectorios. Y luego lo voy convirtiendo a funciones. Primero en su propio archivo, y luego integrados en otro más largo.
Tu buscas localización rápida de problemas y de reducción de complejidad.
Vamos a suponer que tienes cinco hijos. Si tienes cinco hijos, cada uno de ellos debe ser independiente. Una función en sí mismos.
Se oye muy bonito que uno sea médico, que otro ingeniero, que otro abogado. Pero deben, en la medida de lo posible, ser independientes, no esclavos de otros. Los microservicios no conocen de tradiciones familiares. Si tu hijo Azure falla, o tu hijo dominio, ¿qué vas a hacer? Todos caen. Es como un coche que funciona bien hasta que se estrella.
Por tercera vez tengo problemas en dos horas en corrección de ortografía. Tu facturación puede estar detenida por eso. Y no te lo corrige Amazon. Te lo corrige tener tu servidor en seis lugares diferentes con un balanceo de carga e integración. Se cae Amazon, todos sufren, menos los que tienen su balanceo de cargas apuntando a diversas plataformas. Y no es caro en realidad. No puedes permitirte estar sin una adecuada protección.
Amazon y Google Cloud no ponen límites a tu consumo. He visto sustos fuertes en su facturación.
Es posible que siempre hayas operado en microservicios. Ahora necesitas redundancia para 500 microservicios, si es el caso estándar. ¿Qué pasa cuando un Lambda cae? Además, la mayoría de las personas usan us-east-1 en Amazon. Todo funciona bien hasta que no funciona.
¿Te has lastimado las rodillas o los tobillos? Es muy doloroso e incómodo. Pero al usar de manera excesiva microservicios, estás creando múltiples puntos de falla, múltiples rodillas, múltiples tobillos que pueden dislocarse. Y los tendones se rompen. Tienes un número limitado de tendones y un número limitado de errores que te perdona la industria, tus clientes o la cartera.
Los límites de tarjetas de crédito, los límites de ventanas de entorno son tus amigos. Las tarjetas ilimitadas, o el crédito abierto de Amazon, no lo son.
Seguiremos hablando después de las ventanas de entorno.
Los límites son tus amigos. Entiende los límites de tu LLM y no les des control de una máquina real. Solo de secundarias. No le des tu corazón, ni tu correo principal, ni tus tarjetas. Puede ser un error muy grave no entender tus límites o los límites de las LLM.
El problema de los cinco hijos es el mismo de tener muchos microservicios: no sabes qué hacen y dependes de ellos.
La paradoja de la búsqueda tiene que ver con eso. Hay límites de lo que puedes hacer — eso puede ser tu tarjeta de crédito, o los microservicios. Así como revisas los estados de cuenta, debes ver el estado de tus microservicios.
Las LLM no pueden corregir lo que no pueden encontrar. Tienes que estructurar en pocos archivos, en funciones claras que puedas pausar una a la vez y que quepan en su entorno.
Así que para mí, la clave es ser capaz de tener un control de versiones a nivel de funciones, del tamaño de entorno que realmente maneja tu LLM. En lo personal, 300 a 400 líneas es lo que me parece óptimo en manejos internos por subproyectos. Y Claude a veces me convierte tres archivos de 300 líneas en uno de mil, que es mucho más fácil de mantener que tres de 300.
Personalmente creo que tener varios LLM en tu propia computadora es necesario: cada LLM es un solo archivo y no depende de que la nube se caiga, lo puedes respaldar sin problemas.
Mi consejo es que vayas detectando los límites de entorno de máquinas locales. Hoy fallaron tres LLM a la vez, ¿qué vas a hacer cuando tu LLM público desaparezca?
Los límites Pro aumentan el entorno y te hacen dependiente de ello.
Los sistemas catedral como Qwen son tus amigos. Solo puedes conservar aquello que puedes respaldar.
