Principio: Demuestre, no solo diga
Esta diapositiva transmite una idea muy importante cuando trabajas con Claude Code, ChatGPT o cualquier agente de IA:
No basta con decirle las reglas. Hay que enseñarle ejemplos.
Por eso el título dice:
Show, Don't Just Tell
Muestra, no solo digas.
Un ejemplo con personas
Imagina que contratas a un desarrollador nuevo.
Opción 1: Solo le dices la regla
Le dices:
"Escribe código limpio."
¿Qué significa "código limpio"?
Para una persona puede significar una cosa y para otra, otra diferente.
La regla es demasiado abstracta.
Opción 2: Le enseñas ejemplos
Le dices:
❌ No hagas esto
public Point(double x, double y) {
this.x = x;
this.y = y;
}
Porque no valida los datos.
Luego le muestras:
✅ Haz esto
if (Double.isNaN(x) || Double.isNaN(y)) {
throw new IllegalArgumentException( "Coordinates cannot be NaN");
}
Ahora ya no hay duda.
El desarrollador sabe exactamente qué esperas.
Con la IA ocurre exactamente lo mismo.
¿Por qué el ejemplo es mejor?
La IA no entiende "código limpio" como un ser humano.
Si le dices:
Escribe código limpio.
Puede generar diez versiones distintas.
Pero si le dices:
Siempre valida los parámetros del constructor.
Y además le muestras cómo hacerlo:
if (Double.isNaN(x)) {
throw ...
}
Entonces empezará a repetir ese patrón.
¿Qué significa "Never do this"?
La caja roja dice:
public Point(double x, double y) {
this.x = x;
this.y = y;
}
Parece correcto.
Pero tiene un problema.
¿Qué pasa si alguien hace?
Point p = new Point(Double.NaN, 10);
o
Point p = new Point(15, Double.NaN);
NaN significa "Not a Number", un valor especial de double.
El objeto se crea igual.
Ahora tienes un objeto inválido.
Más adelante alguien hace cálculos:
double distancia = p.x + 100;
Resultado:
NaN
Todo empieza a propagarse.
¿Qué propone la caja verde?
Antes de guardar los valores:
if (Double.isNaN(x) || Double.isNaN(y)) {
throw new IllegalArgumentException( "Coordinates cannot be NaN");
}
Si alguien intenta crear un objeto inválido:
new Point(Double.NaN, 20);
El programa responde inmediatamente:
IllegalArgumentException
Es decir:
"No voy a permitir crear un objeto inválido."
Ese es un principio muy usado en DDD:
Los objetos deben proteger sus propias invariantes.
¿Y la "War Story"?
Abajo aparece:
En enero de 2025 ocurrió un incidente en producción porque llegaron coordenadas NaN y todo el proceso de exportación falló.
La enseñanza es:
Siempre validar en los constructores.
¿Por qué incluyen esta historia?
Porque las personas y la IA recuerdan mejor el motivo de una regla cuando conocen la consecuencia de no seguirla.
No es solo:
Valida los parámetros.
Sino:
Valida los parámetros porque una vez un sistema completo cayó por no hacerlo.
Eso hace que la regla tenga más peso.
No lo olvide: La IA aprende mucho mejor a partir de ejemplos concretos que de reglas generales, porque puede identificar y reproducir patrones de forma consistente.
Enjoy!
Joe
