La calidad es la única variable

El trabajo de un project manager es equilibrar cuatro variables: alcance, tiempo, costo y calidad. El clásico triángulo de restricciones dice que puedes optimizar dos, pero no las cuatro. ¿Lo quieres rápido y barato? La calidad se resiente. ¿Lo quieres bueno y rápido? El costo aumenta. El triángulo es un modelo mental útil para entornos con recursos limitados.

Yo no opero en un entorno con recursos limitados. Opero con un agente de IA que puede producir código a la velocidad de la inferencia, una ventana de contexto que abarca un codebase completo y un costo por sesión medido en dólares, no en salarios. El triángulo de restricciones se desmorona.

Cuando el agente puede implementar una función en minutos, la pregunta no es “¿podemos permitirnos hacerlo bien?” La pregunta es “¿por qué lo haríamos mal?”

La eliminación

Elimina el tiempo de la decisión. No “¿cuánto tardará?” sino “¿cómo debería verse esto cuando esté terminado?” La primera pregunta optimiza la velocidad de entrega. La segunda optimiza el artefacto.

Elimina el costo de la decisión. Una sesión que produce código correcto, limpio y bien testeado cuesta lo mismo que una sesión que produce código apresurado, desordenado y sin tests. El API cobra lo mismo por token sin importar la calidad. El costo marginal de hacerlo bien es cero.

Elimina el esfuerzo de la decisión. El agente no se cansa. La centésima función se escribe con la misma capacidad que la primera. No hay una curva de fatiga humana que justifique atajos al final de una sesión. La calidad del resultado está limitada por la calidad de la instrucción y la calidad del contexto circundante, no por cuántas horas han pasado.

¿Qué queda después de eliminar tiempo, costo y esfuerzo? Calidad. La calidad es la única variable que queda.

Qué significa esto en la práctica

Cuando la calidad es la única variable, varias decisiones comunes de ingeniería se vuelven obvias:

Escribe el test. El debate sobre si escribir un test para una función específica desaparece. El agente escribe el test en segundos. El costo marginal es cero. El beneficio marginal es verificación permanente. No escribir el test es elegir aceptar menos calidad sin obtener ningún ahorro.

Corrige el código adyacente. Al corregir un bug, el código circundante suele tener problemas relacionados: nomenclatura inconsistente, manejo de errores faltante, patrones desactualizados. En un entorno con restricciones de tiempo, corriges el bug y dejas el código adyacente para “después”. Cuando la calidad es la única variable, corriges todo lo que tocas. Después nunca llega. Ahora es gratis.

Usa la abstracción correcta. Un hack rápido resuelve el problema inmediato. La abstracción correcta resuelve la categoría de problemas. En un entorno con restricciones de tiempo, el hack se despliega hoy y la abstracción no se despliega nunca. Cuando el agente puede implementar cualquiera de las dos en la misma sesión, el hack no tiene ventaja. Elige la abstracción.

Lee antes de escribir. En un entorno con restricciones de tiempo, los ingenieros a veces modifican código que no han leído completamente, confiando en una comprensión local. Cuando el agente puede leer el archivo completo, entender los patrones y modificar con contexto total, no hay razón para operar con comprensión parcial. Lee el archivo completo. Entiende el patrón. Luego escribe.

No postergues. TODO, FIXME y HACK son marcadores de calidad diferida. En un entorno con restricciones de tiempo, la postergación es racional: arréglalo después cuando haya tiempo. Cuando la calidad es la única variable, la postergación es irracional. El agente está aquí. El contexto está cargado. La corrección cuesta lo mismo ahora o después. Hazlo ahora.

El principio Jiro

Jiro Ono lleva más de 70 años haciendo sushi. Su restaurante tiene tres estrellas Michelin y diez asientos. No ha cambiado el menú ni el método. Ha refinado el método cada día durante 70 años.

Cuando alguien le pregunta a Jiro si una pieza de sushi es suficientemente buena, la respuesta nunca se basa en qué tan ocupado está el restaurante, cuántos clientes esperan o qué tan caro fue el pescado. La respuesta se basa en si el sushi cumple su estándar. El estándar es absoluto. Las circunstancias son irrelevantes.

Este es el principio aplicado a la ingeniería: el estándar es el código, no el sprint. Una función es correcta, limpia y bien testeada, o no lo es. La fecha límite no cambia la evaluación. El presupuesto no cambia la evaluación. La única pregunta es si el artefacto cumple el estándar.

Los agentes de IA hacen que este principio sea práctico por primera vez en la ingeniería de software. Antes de los agentes, el principio Jiro era aspiracional. El costo humano de la perfección era demasiado alto. Cada atajo tenía una justificación racional: entregamos el jueves, el presupuesto se agotó, el ingeniero está agotado. Con agentes, el costo de hacerlo bien es el mismo que el costo de hacerlo mal. Los atajos pierden su justificación.

El Pride Check

Después de cada cambio no trivial, hago cinco preguntas:

1. ¿Un ingeniero senior respetaría esto?
2. ¿El código se explica solo?
3. ¿Se manejan los casos límite?
4. ¿Es este el nivel correcto de simplicidad?
5. ¿Dejé el codebase mejor de como lo encontré?

Las preguntas no son sobre corrección. La puerta de evidencia se encarga de la corrección. El pride check se encarga del oficio. Código correcto que nadie quiere mantener falla en la pregunta 1. Código ingenioso que requiere comentarios para entenderse falla en la pregunta 2. Código que maneja el camino feliz pero ignora el camino de error falla en la pregunta 3.

La pregunta 4 es la más difícil. “El nivel correcto de simplicidad” no es “lo más simple posible”. Un hack de una línea es más simple que una abstracción adecuada, pero el hack es el nivel incorrecto de simplicidad si el problema se repetirá. La simplicidad correcta es la menor complejidad que resuelve el problema real sin resolver problemas futuros hipotéticos.

La pregunta 5 trata sobre la trayectoria. Cada sesión debería dejar el codebase en mejor estado del que lo encontró. No solo los archivos específicos modificados, sino el contexto circundante: tests actualizados, imports limpiados, comentarios corregidos, código muerto eliminado. El estándar no es “¿completé la tarea?” El estándar es “¿el proyecto está mejor porque estuve aquí?”

El contraargumento

El contraargumento obvio: la velocidad importa. Entregar importa. Un codebase perfecto que nunca se entrega es peor que un codebase desordenado que resuelve un problema real.

El contraargumento es correcto en un mundo donde calidad y velocidad están inversamente correlacionadas. En un mundo donde un agente de IA produce resultados de alta calidad a la misma velocidad que resultados de baja calidad, la correlación se rompe. Calidad y velocidad se convierten en variables independientes. Puedes tener ambas.

El trade-off restante es la atención, no el tiempo. Leer el archivo completo requiere atención. Ejecutar la puerta de evidencia requiere atención. Aplicar el pride check requiere atención. El tiempo del agente es gratuito. Tu atención es finita.

La calidad es la única variable, pero la atención es la restricción sobre la calidad. La solución no es bajar el estándar. La solución es construir infraestructura que reduzca el costo de atención de mantener el estándar: hooks que detecten fallos comunes automáticamente, skills que codifiquen flujos de trabajo de calidad, y sistemas de memoria que transporten contexto entre sesiones para no tener que re-derivar decisiones.

Esto es compound context al servicio de la calidad. Cada pieza de infraestructura reduce el costo de atención de la siguiente sesión. Después de suficientes sesiones, el estándar se mantiene solo.

FAQ

¿Esto aplica a todos los proyectos de software?

El principio aplica más directamente a proyectos donde agentes de IA realizan la implementación. En proyectos implementados completamente por humanos, el tiempo y el costo siguen siendo restricciones reales. El principio se vuelve más aplicable a medida que la capacidad de los agentes aumenta y el tiempo de implementación humana disminuye.

¿Qué pasa con los prototipos?

Los prototipos son desechables por definición. El estándar de calidad para un prototipo es “¿responde la pregunta que estamos investigando?” Si la respuesta es sí, el prototipo cumplió su propósito sin importar la calidad del código. El principio aplica al código que persistirá, no al código que será descartado.

¿No es simplemente perfeccionismo?

El perfeccionismo es un estándar infinito que nada cumple. La calidad es un estándar finito que la puerta de evidencia define: correcto, limpio, testeado, libre de regresiones y que resuelve el problema real. Cumplir el estándar es alcanzable. Excederlo es innecesario. El estándar es alto, pero no infinito.

¿Cómo manejas la deuda técnica?

No creándola. La deuda técnica es calidad diferida. Cuando la calidad es la única variable, la postergación pierde su justificación. El agente está disponible ahora. La corrección cuesta lo mismo ahora o después. No hay tasa de interés sobre la deuda técnica producida por agentes porque no hay razón para incurrir en ella.

Fuentes

La filosofía descrita aquí se basa en la tradición Shokunin del oficio artesanal japonés y la experiencia de producción documentada a lo largo de la serie AI Engineering. Implementaciones específicas referenciadas:

• Puerta de evidencia: seis criterios para verificación de completitud
• Pride check: cinco preguntas para evaluación del oficio
• Sistema de hooks: 84 hooks como infraestructura de calidad (Every Hook Is a Scar)
• Compound context: infraestructura que reduce el costo de atención de la calidad (Compound Context)