No puedes hacer pruebas unitarias para el gusto
¿Se puede capturar en pruebas o código el “gusto” subjetivo en el diseño de software o UX, especialmente cuando los agentes de IA hacen cada vez más parte de la implementación? Los comentaristas sostienen que, aunque algunos aspectos de la calidad pueden formalizarse mediante guías de estilo, linters, pruebas de snapshot o modelos de ML entrenados con datos de pulgar arriba/pulgar abajo, un gran resto dependiente del contexto resiste ser externalizado en reglas o pruebas unitarias. Esto plantea preguntas más amplias sobre los límites del TDD y la evaluación automatizada, el papel de los humanos como árbitros finales del diseño y la arquitectura, y hasta dónde pueden llegar realmente los LLMs más allá de ser colaboradores inteligentes pero inexpertos.
Naturaleza del “gusto” y si se puede probar
- Muchos sostienen que no puedes hacer pruebas unitarias completas para el gusto porque:
- El gusto es la parte de la especificación que olvidaste o que no puedes articular.
- Las reglas necesitan excepciones, cuyas excepciones son juicio contextual; lo que queda es “gusto”.
- Solo puedes externalizar una pequeña parte, parecida a una regla; el resto sigue siendo implícito.
- Otros responden que algunas partes sí se pueden codificar:
- Comparaciones por pares de “me gusta o no” pueden entrenar funciones de puntuación de ML.
- Guías de estilo, lenguajes de patrones y directrices de UI capturan algunos estándares compartidos.
- Linters y scripts pueden hacer cumplir convenciones (nombres, colores de marca, límites entre capas).
IA, LLMs y el gusto personal/organizacional
- Se describe a los LLMs como potentes pero atascados en el nivel de un “nuevo empleado inteligente”:
- Sin memoria persistente e individualizada a largo plazo.
- El RL / la retroalimentación tiende a promediar hacia un estilo genérico, no hacia el gusto de una persona.
- Los modelos a menudo toman decisiones seguras, pero sin gusto o arriesgadas, salvo que estén estrictamente gobernados.
- Enfoques propuestos:
- Entrenar modelos de preferencia separados por persona/equipo; fallar cuando discrepen.
- Usar agentes más “gates” humanos o tickets de validación antes de cerrar el trabajo.
- Tratar a los LLMs como desarrolladores junior; codificar decisiones en ADRs/documentos y dejar que los sigan.
Filosofía de pruebas y los límites del TDD
- Se considera que las pruebas sirven para asegurar que algo “no está mal”, no para hacerlo “bueno” o con buen gusto.
- Se critica el TDD intenso y las pruebas unitarias de bajo nivel:
- La corrección no se compone de forma limpia; el comportamiento emergente aparece en niveles más altos.
- El exceso de mocking y los objetivos de cobertura del 100% reducen la confianza y ralentizan los cambios.
- Otros defienden el TDD cuando se aplica en niveles adecuados de abstracción y para bugs.
- Se sugieren pruebas de snapshot y regresión visual para gráficos/UI, pero no capturan el “se siente bien”.
UX, visuales y “sensación”
- Muchos señalan que las UIs/imágenes generadas por IA a menudo se sienten baratas o extrañas.
- Algunos creen que las redes neuronales pueden reconocer cualidades como “cursi”, dado suficiente número de ejemplos etiquetados.
- Las herramientas pueden probar aspectos objetivos (colores, consistencia del diseño), pero la fricción subjetiva de UX sigue requiriendo humanos.
Intuición, antropomorfización y pragmatismo
- La intuición humana (por ejemplo, percibir un fallo estructural) se compara con el gusto: basada en la experiencia pero difícil de codificar.
- El uso de “nosotros” con colaboradores de IA genera preocupación por una antropomorfización sutil.
- Varias voces abogan por aceptar lo “suficientemente bueno”, usando la IA como herramienta de apoyo mientras los humanos conservan el gusto final y la gobernanza.