Principio: Demuestre, no solo diga

Search for a command to run...

No comments yet. Be the first to comment.
En Santiago de los Caballeros, Republica Dominicana. Volví de República Dominicana con la batería cargada… y con el corazón un poco más Java. Gracias, JConf Dominicana. Hay conferencias que te dejan s

La Inteligencia Artificial no hace que un equipo sea 10 veces más productivo por arte de magia. Lo que realmente marca la diferencia es el contexto que le das a la IA. Muchos equipos prueban ChatGPT,

Muchos piensan que una IA mejora automáticamente con cada conversación. La realidad es diferente. Si no capturas los errores, los aciertos y los patrones que aparecen durante el desarrollo, la IA volv

Cuando la mayoría de las personas empieza a desarrollar aplicaciones con IA, suele pensar que el camino para obtener mejores resultados es: Usar un modelo más potente. Escribir mejores prompts. Aum

Uno de los errores más comunes al construir soluciones con Inteligencia Artificial es querer crear un asistente que haga absolutamente todo desde el inicio. La realidad es otra: las mejores soluciones

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.
Imagina que contratas a un desarrollador nuevo.
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.
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.
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.
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.
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.
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