Es 11 de enero de 2026, domingo, madrugada.
Ayer almorcé con Hobo. Después de mucho tiempo sin vernos, hablamos mucho en la mesa. Él mostró un gran interés por nuestra situación reciente y nuestro trabajo. Intercambiamos muchas ideas.
Envidio que él, trabajando en una empresa extranjera, pueda usar sin límites LLMs como GPT y Claude Opus para asistir en su trabajo y mejorar la eficiencia. En contraste, en nuestro entorno laboral en China, todavía existen muchas restricciones e inconvenientes para usar estas herramientas.
Nuestro consenso es que, actualmente en el trabajo de codificación, el código escrito por un LLM no puede ir directamente a producción. Es muy, muy poco confiable.
Observabilidad
Le pregunté: si se limita a un módulo y pasa pruebas unitarias y de referencia estrictas, ¿se podría usar? Él añadió que también se necesita una muy buena observabilidad, ya que hay que considerar la estabilidad del servicio a largo plazo. Además, el costo de dividir un sistema enorme en muchos módulos pequeños tan bien definidos es en sí mismo muy alto.
Este es realmente un problema que había pasado por alto antes. En este artículo mencioné que, después de pasar las pruebas de estilo de interfaz, las pruebas unitarias y las pruebas de referencia, las personas podrían confiar en el código generado por el LLM. Una vez construí una prueba de referencia que, al considerar el uso de CPU y memoria, demostró que solo con pruebas de referencia ordinarias no se pueden detectar los problemas de rendimiento en el código generado por el LLM. Es necesario aplicar pruebas de estrés de antemano para descubrir los problemas. Las pruebas de estrés tampoco pueden simular realmente los diversos escenarios complejos del entorno de producción, por lo que finalmente se necesita una muy buena observabilidad para poder usar el código generado por el LLM en producción.
Pero, ¿cómo se debe diseñar y probar la observabilidad?
La observabilidad en sí misma es también una herramienta para probar si la situación real cumple con las expectativas, solo que su entorno de ejecución es el de producción, no el de pruebas.
Además, puede necesitar invadir el código de implementación para recopilar suficiente información. (La instrumentación intrusiva generalmente implica mayores costos de mantenimiento).
Si simplemente se recopilan algunos datos de métricas fuera de la interfaz y en la información del entorno, a menudo solo se pueden descubrir una parte de los problemas. Por ejemplo, no se puede observar si el estado interno del módulo es correcto, si está consumiendo demasiados recursos, si hay fugas de memoria, si hay bloqueos mutuos (deadlocks), etc.
Y las métricas de observabilidad a menudo están relacionadas con el aislamiento de recursos, como CPU, memoria, E/S, etc. Sin un muy buen aislamiento de recursos, a menudo es difícil descubrir problemas.
Además, la clave de la observabilidad radica en el sistema de alertas. Hobo mencionó una vez: "Cada métrica instrumentada implica que debería tener una regla de alerta correspondiente; de lo contrario, esa instrumentación no tiene sentido".
En la práctica habitual, las reglas de alerta son trabajo de operaciones (Ops), pero la instrumentación es trabajo de desarrollo. Quizás esta práctica en sí misma sea problemática. ¿Por qué no consideramos incrustar directamente las reglas de alerta en el código?
Por ejemplo, cada punto de instrumentación podría llevar una definición de regla de alerta, de modo que cuando una métrica supere cierto umbral, se active automáticamente una alerta. De esta manera, los desarrolladores, al escribir el código, podrían considerar directamente la observabilidad y las reglas de alerta, mejorando así la calidad y confiabilidad del código.
Por ejemplo, al instrumentar, también se podría diseñar un mecanismo de aserción; si la aserción no pasa, se activa una alerta. Esto se parece mucho al mecanismo de error/advertencia. ¿Registrar un error o una advertencia significa que necesita atención?
Podríamos comenzar con los registros (logs), enfocándonos en registrar errores y advertencias, utilizando estos registros como parte de la observabilidad y combinándolos con el sistema de alertas para mejorar la confiabilidad del sistema.
Estoy muy de acuerdo con el punto de vista de Hobo: el código que va a producción debe tener una muy buena observabilidad; de lo contrario, no se puede garantizar la estabilidad a largo plazo.
Nivel de inteligencia del LLM vs. Métodos de ingeniería
Además, Hobo también mencionó el problema de la influencia del nivel de inteligencia propio del LLM en la calidad del código. Aquí tenemos algunas diferencias.
Él cree que el nivel de inteligencia del LLM es el factor clave que determina la calidad del código; si el nivel de inteligencia es insuficiente, no puede completar la tarea. Yo creo que, si bien el nivel de inteligencia del LLM es importante, lo más crucial es cómo diseñar bien la tarea y el flujo de pruebas para asegurar que el código generado cumpla con las expectativas.
Hobo se inclina hacia la capacidad de élite, es una perspectiva innatista; mientras que yo tiendo más hacia la optimización del sistema, es una perspectiva constructivista.
Ambas tienen razón, pero en etapas diferentes.
Por debajo del punto crítico de capacidad del modelo, yo tengo razón absoluta. Para la gran mayoría de aplicaciones comerciales actuales, el valor de los métodos de ingeniería es mucho mayor que esperar el próximo modelo "más inteligente". Una cadena de prompts cuidadosamente diseñada, un conjunto completo de pruebas y un proceso iterativo pueden hacer que un modelo de capacidad media produzca código estable y utilizable. Este es el camino principal y exitoso para la implementación actual de aplicaciones de IA.
Al enfrentar verdaderos límites cognitivos, la perspectiva de Hobo se hace evidente. Cuando la complejidad de la tarea alcanza un nivel que requiere una verdadera comprensión, abstracción e innovación (por ejemplo, diseñar un algoritmo completamente nuevo, o entender un requisito extremadamente vago y contradictorio), el "techo de inteligencia" del modelo se convierte en un obstáculo insuperable. En ese momento, ni el mejor proceso puede hacer que el modelo complete algo que "cognitivamente no puede hacer".
Yo represento la "pragmática del ingeniero", el motor central que hace que la IA cree valor en el presente. Hobo representa la "visión del investigador", enfocándose en los puntos de ruptura de las capacidades futuras.
El estado ideal es "inteligencia de élite" más "métodos de ingeniería de élite".
Usar el mejor proceso para estimular y gobernar la inteligencia más poderosa. Nuestra diferencia no es sobre quién tiene razón o no, sino sobre el enfoque (optimización actual vs. avance fundamental) y la escala de tiempo (implementación a corto plazo vs. evolución a largo plazo).
En un equipo, esta perspectiva complementaria es muy valiosa.
