Control de calidad

Veo varios problemas pero puedo resumirlos diciendo quela tecnología no es el problema, el problema es usar tecnología que no entiendes para resolver problemas que no has definido, esperando resultados que no se justifican.

Existen diversas escuelas de pensamiento de las que debemos estar enterados, no solo de resolución de problemas, sino de ética y cosas como lo que se le llama la deuda técnica. Es decir, cómo resolver un problema sin crearte uno mayor. Hay varios ejemplos. Hace unos años existía un proveedor de hospedaje llamado https://JodoHost.com ( que quizá aún existe ) que tenía dos o tres cosas muy buenas, incluyendo hospedaje con un sistema llamado H-Sphere como panel de control, y lo que hackeaban o tenía problemas a cada rato. Pero por unos años, sí, años, no meses, era el único lugar donde se podía conseguir a buen precio bases de datos MSSQL hosteadas, que evidentemente tú respaldabas por tu lado.

En ese caso específico, después hubo otras alternativas en sitios diferentes de alojar Postgres e incluso versiones pequeñas de Oracle. Uno de los puntos importantes era que todo el desarrollo que manejé ese año, era de ir convirtiendo en la medida de lo posible el proceso de un sistema en SQL Server al estándar Transact, llamado a veces SQL92, donde realmente no estás casado con la base de datos porque en la medida de lo posible usas instrucciones compatibles entre diversos sistemas de bases de datos. Me acabé desconectando de JodoHost cuando el problema que resolvía ya estaba resuelto porque todo el sistema era Transact compatible. Además empezaron a suceder problemas de uptime de jodohost, pero ya se estaba tratando desde el inicio de dejar mssql server, solo que jodohost resolvia el problema enonces.

La migración final fue cambiar dos líneas de un sistema para usar un perfil local de cPanel de MySQL en lugar del remoto de JodoHost. ¿Deuda técnica? Pues no. Al contrario, nos libramos de deuda técnica. Ese sistema, que yo recuerde, tenía unas 70 tablas y más de 100 vistas que no eran necesarias. Fue mucha optimización de índices y reescribir dos o tres pantallas de Visual Basic 6. Unas semanas después hice otro paso y lo mandé a PHP 5.3, que todavía permitía conexiones directas con SQL Server, y el objetivo era, entre otras cosas, mejorar el rendimiento, debido a que los discos compartidos en las fábricas donde corría esto provocaban que el protocolo NetBIOS/SMB para archivos compartidos en red fuera mucho más lento. La alternativa de usar PHP era por la velocidad de buscar sobre una IP directa a la base de datos en lugar de depender de unidades de red mapeadas.

Ese es un caso extremo. La tecnología avanza y a veces retrocede. Los precios y la complejidad de AWS y la inestabilidad de Azure son problemas muy serios para toda empresa mediana. Es comprar lo peor de cada tecnología. Usando otro ejemplo más conocido: @Autowired no es una llave mágica en JavaSpring/JPA/Hibernate. Es algo complicado de manejar unas semanas después. Imposible de depurar en cinco meses. Y en sistemas críticos que dependen de no tener paquetes alterados, una tecnología contradictoria no solo genera deuda técnica, sino porque el número de líneas cambia. Eso es válido en un sistema operativo, no en un aplicativo de negocios, sea web o de escritorio.

En el año 2020 tuvimos la pandemia. Se dieron una serie de detalles: empleados que murieron de COVID, clientes que no pagaron, y entre otras cosas la necesidad de no salir. Si bien los diez años anteriores viajé mucho por el interior del país, empecé a preferir usar ETN o servicios de camiones de lujo, para no lidiar con desgaste del coche en carretera ni con problemas de estacionamiento. Además, de manera progresiva desde 2005 se ha vuelto más inseguro viajar en carretera en un coche o camioneta decente por grupos criminales. En el 2020, entre muertos, clientes que desaparecieron y demás, no usé el coche. Y en una de las personas que despedí de la empresa, me pidió que le pagara con mi camioneta e incluso me dio efectivo. Buen trato. Algo similar me pasó con el coche: se quedó sin coche un cliente, y se lo vendí. Actualmente me muevo en metro, en taxi y ocasionalmente Uber, aunque no desde mi teléfono por reglas que tengo de ciertos clientes de no tener localizadores activos en mi teléfono, y eso incluye no apps de comida ni de transporte. La necesidad del coche nunca existió desde 2010.

Vivo en Ciudad de México. Probablemente en Monterrey o Guadalajara sí necesitaría un coche, pero de momento no. Hay razones a veces para usar AWS, pero no son demasiadas. La mayor parte de las empresas que usan servidores grandes o escalables, lo hacen para cubrir mala programación. A lo largo de los años he corregido sistemas medianos o grandes, simplificando y añadiendo funciones a la vez. Para mis clientes les interesa un sistema confiable. Y mucho de lo que hacen las LLM no es confiable. Los entornos cambian.

Si bien la necesidad del coche desde 2010 para mí es prácticamente cero, hubo una época en que lo normal era tener dos coches, principalmente para poder moverme si uno fallaba. De momento no tomaría clientes que me exijan ir a diario a lugares medio lejanos, como Villa de las Flores o Villa Nicolás Romero en Estado de México. Además, por lo que sé, incluso por seguridad no es buena idea. Sería crearme un problema que no necesito. Pero, por ejemplo, lugares como Atizapán, Tultitlán, Valle Dorado no tienen ese problema. Y sí, si un proyecto es lo suficientemente importante para esa zona, quizá conseguiría otro coche, pero de momento no lo necesito. Estamos moviéndonos por miedo. Las LLM sí dan cosas que deben revisarse, pero en la mayoría de las situaciones el costo es insuperable y un problema real. Para mí el problema real es la degradación de los modelos. Veo más probable usar un sistema limitado que no se degrada, como Kimi, o las LLM locales como Qwen que no van a cambiar. Llevamos unas tres semanas oyendo del Claude/Fable, antes Mythos, o el modelo más reciente de z.ai, o ahora Kimi 5.3. Y yo solo sé que los modelos en general, menos Kimi, se han degradado. Usarlos me crea un problema. Literalmente confío más en los LLM que tengo locales que en Gemini, Grok o ChatGPT.

Otro punto importante, aunque son tecnologías de 2003 y 2015, he visto en los datos que me pasan, más solicitudes de Power Bi y Tableau los ultimos seis meses que lo que vi en los ultimos diez años JUNTOS.

1. La promesa de las LLM no se cumplió para análisis de datos
   • Los modelos generativos son buenos para texto, pero malos para números consistentes. Un CFO no puede presentar un reporte donde el total de ventas cambia cada vez que refrescas el prompt. Tableau y Power BI, a pesar de sus limitaciones, dan el mismo número siempre cuando los datos no cambian.
2. Deuda técnica en el “vibe coding” de dashboards
   • Muchas empresas generaron “dashboards” con LLMs en 2024-2025 que eran visualmente impresionantes pero inconsistentes en los cálculos. Ahora necesitan alguien que arme algo que funcione de verdad, con fuentes de datos limpias, DAX correcto, y modelos de datos que no se rompan.
3. La regulación y la trazabilidad
   • En LATAM, y especialmente en México, la SAT y otros organismos exigen reportes auditables. Un dashboard generado por IA sin trazabilidad de cómo llegó al número no sirve para un auditor. Tableau y Power BI tienen linaje de datos documentado.
4. El ciclo de “moda tecnológica”
   • Es el mismo patrón que describes con ActiveX, VRML, Genexus: una tecnología madura vuelve a ser relevante cuando la nueva no cumple. Tableau y Power BI nunca desaparecieron, solo quedaron en segundo plano mientras el hype estaba en otra parte. Ahora que el hype de las LLM muestra grietas, las empresas recuerdan que necesitan herramientas que funcionen, no que impresionen.

5. El contexto económico de LATAM
   • Como dices, no todos pueden pagar suscripciones caras de IA. Power BI, integrado con Office 365 que muchas empresas ya tienen, es más accesible que contratar desarrolladores de LLM o pagar tokens de API.

Fin de kimi

Yo lo he visto esto mezclado con que piden Python. El problema es que estamos creando un mercado como fue en su momento Crystal Reports. Había versiones más débiles nativas de Visual Basic, pero en una temporada cualquier trabajo que no fuera MySQL quería Crystal Reports. En su momento yo tenía que hacer cotizaciones de sistemas, y ponían un número determinado de reportes incluidos, y cobraban por reporte extra. Probablemente fue en 2002 que empecé a generar primeros PDF desde HTML, usando algo de ActiveX y lenguaje C. Finalmente no estaba casado con plataforma y mi velocidad no se resentía.

Parte del problema es que las personas usan un cañón para matar a una mosca. Usando un ejemplo: he hecho muchos sistemas de reportes, pero por SQL mal construidas, sea o no por LLM, a veces un registro no aparece. Digamos que tengo una base de 100 mil registros, pero en una columna hay uno o dos campos en blanco, y la consulta SQL si está mal hecha o demasiado cerrada te da 99,998. Eso puede indicar que no cobres a un cliente o que se te eche a perder un producto. Nosotros debemos comprobar que realmente tenemos todos los datos, y eso no es trivial en ningún reporteador, porque además necesitas saber cuántos registros son desde antes. Prefiero llenar los datos aparte si es necesario con otra consulta, o que el espacio se llene en blanco, pero sí quiero analizar la caja de zapatos de 100 mil registros. No podemos ignorar los datos. No podemos inventar los datos.

Debemos decir los datos tal como son. Y de momento veo más problemas que beneficios con el uso en México de la inteligencia artificial. Esperan ganancias imposibles con herramientas caras, creando problemas que antes no tenían.

Una de las ventajas competitivas que tengo es tener el menor número de pendientes posible. Incluso en trabajos de tiempo completo, rara vez tengo algo que me tome más de dos días; mi salida de resolución de tickets de Jira o similares siempre es alta, con satisfacción del usuario. Sí, en mi vida personal y profesional algunas cosas deben esperar: por ejemplo, no puedo ver Avengers con Doctor Doom hasta diciembre que se estrena. Esa es una demora por el tiempo. Pero es raro que me pidan algo y no tenga la respuesta en menos de 5 minutos. Las cosas no tan triviales, en menos de una hora. Y yo creo que por lo general en lo que me tardo más es en rastrear problemas de cuentas de correo, que son muchas pruebas. Te lo dice alguien para quien manejar sistemas propios de 60 mil líneas son suficientes, para lo que otros usan a veces dos o tres millones de líneas. Lo que importa es que un sistema sea confiable, y para mí es más confiable un LLM local que ChatGPT o Gemini desde marzo. Tener los insumos necesarios de sistemas es una cosa, pero eso aplica exactamente lo mismo a tener el refrigerador lleno. No esperas a la necesidad: vas a tener que comer, vas a tener que cambiar el mouse o pagar la electricidad.

En realidad creo que son buenos ejemplos de que lo que importa es otra cosa. Me han llamado la atención por hacer bien mi trabajo, y en una ocasión por problemas de personas de mi puesto, pero yo era el único que trabajaba, y por algo los clientes internos o usuarios de mis sistemas solo querían hablar conmigo. Es algo normal. Si tratas a las personas con cortesía y haces tu trabajo, solo se van a oponer a ti los que no les interesa que hagas tu trabajo o que tengan problemas personales, y tú eres solo el pretexto.

El problema, como tal, tiene que ver con control de calidad. Muchos piensan que pueden ser directores de orquesta: después de todo, la batuta no suena. Pero en realidad, si tienes buenos productos a un precio decente, tu negocio tiene más posibilidades de sobrevivir. De momento necesitas conocer las reglas del negocio, no escupir software. Y la mayor parte de las personas no les interesa aprender las reglas del negocio. Y si no están bien preparados, los softwares que hagan, sea con inteligencia artificial o sin ella, no van a funcionar.

Voy a poner otro ejemplo, muy simple. En el software que hago suelo usar una regla de poner derechos reservados, año inicial – año actual. Esto lo hago con variables y separar la fecha; en PHP sería un date. Por ejemplo, un software que instalé en 2022, si se viera hoy la pantalla de inicio, debería de mostrar 2022-2026, y el año que entra 2027. Ayer me reportaron un problema de un software de la paraestatal de la que salí, y por reflejo ( literalmente se me olvidó que no me pagaron del año pasado cinco meses ) entré al link que me mandaron del problema. Y al ver el contenido decía 2022-2023. ¿Qué significa eso? Supongo que  por los servidores míos que, por falta de pago, ya desaparecieron, regresaron a una versión de hace CUATRO años, mutilada. Y lo digo con conocimiento de causa, porque todos los avances tecnológicos los hice en 2024, y corregir problemas de las bases de datos y detalles como el 2022-año, lo hice en 2023. Así que volvieron a cargar probablemente un software que tenían respaldado de hace tres años, de antes de mis servidores desaparecidos por falta de pagos. Y si lo hicieron es porque no entendieron la documentación de mi disco duro, o más probablemente porque borraron todo por error y decidieron cargar un respaldo que tenían. Eso explica muchas cosas que me he enterado.

Qué tiene que ver esto con dominar la caja negra de los LLM?

• Cuando premias a los inútiles, obtienes un montón. No usas LLM que te están dando basura. La alejas de los clientes.
• Tienes que tener control de calidad. Si no saben programar, menos van a poder controlar la calidad.
• La abstracción que te oculta los cien mil registros de la caja de zapatos es tu enemiga. Un SQL simple que te da los 100 mil es el que funciona, no la estupidez optimizada que te desaparece cinco registros.

Nota:

• La imagen que me dio Gemini fue MALISIMA.
• La de Grok igual, mala pero un poco mejor
• Incluso Meta hizo esto, pero me lo dio en .webp no jpg
• Debo mejorarlo después
• Y es otro caso de problemas de control de calidad. Esto no pasaba hace tres meses.