- En la era de la IA, la práctica más contraintuitiva es saber cuándo bajar la velocidad, y cuanto más barata se vuelve la ejecución, más importante se vuelve la toma de decisiones en la etapa previa
- Aplica el marco de System 1 (emparejamiento rápido de patrones) y System 2 (pensamiento analítico lento) de Daniel Kahneman al desarrollo de software en la era de la IA
- Los requisitos incorrectos o las suposiciones de diseño erróneas la IA las propaga más rápido, por lo que se maximiza la relación costo-beneficio de la etapa lenta previa a la ejecución
- También es posible usar la IA no solo para ejecutar, sino para acelerar etapas de reflexión como la revisión previa, el pre-mortem y la exploración de casos límite
- Para responder a la nueva cultura de presión por la velocidad del “¿No basta con usar IA?”, hace falta una estrategia que haga visibles explícitamente las etapas lentas y las acote en el tiempo
Dos velocidades de pensamiento
- Aplica a la era del desarrollo con IA los dos modos de pensamiento presentados en Thinking, Fast and Slow de Daniel Kahneman
- System 1: pensamiento rápido, automático y basado en el reconocimiento de patrones
- System 2: pensamiento lento, deliberado y analítico
- En una conversación con Dwarkesh Patel, Andrej Karpathy comparó a los LLM con fantasmas o genios: destilados estadísticos del texto humano, seres esencialmente de tipo System 1 en los que entran palabras, se hace una coincidencia de patrones y salen palabras
- La IA sobresale en el emparejamiento rápido de patrones a gran escala, pero decidir qué construir, por qué importa y si se está resolviendo el problema correcto sigue siendo terreno del juicio humano
- La idea central, contraintuitiva, es que la IA no hizo menos importante la etapa lenta, sino más importante
- Cuando la ejecución se vuelve barata y rápida, la palanca se desplaza hacia la toma de decisiones previa a la ejecución
- Los requisitos equivocados, los problemas mal entendidos y las suposiciones de diseño defectuosas se propagan a todo lo que construye la IA, y ahora se propagan más rápido
- Cuanto más poderoso se vuelve el System 1, mayor es el costo de hacer mal el System 2
La ilusión de la velocidad
- Viejo chiste del mundo académico: “lo que tomaría unas horas en la biblioteca lleva semanas en el laboratorio”; su versión en software es: “unas semanas de código ahorran unas horas de planificación”
- La clave es que en realidad ocurre al revés: cuando uno empieza con prisa, después descubre errores fundamentales y llega un retrabajo doloroso
- En ingeniería de software existe una intuición clara: los errores hay que detectarlos lo antes posible, idealmente en la etapa de requisitos o diseño
- Un diagrama de cajas se cambia fácil, un requisito mal entendido es más difícil, y una arquitectura de despliegue defectuosa de raíz ya es nivel de reescritura
- El problema con la IA: puede generar deuda técnica más rápido que nunca
- Si las decisiones previas a la ejecución están defectuosas, la IA implementa fielmente esos defectos en una forma que parece código funcional completo
- Puede generar miles de líneas de código a partir de requisitos mal entendidos y construir con entusiasmo una solución elegante para el problema equivocado
- La ilusión de la velocidad: se siente como si hubiera avance, pero en realidad se está cavando un hoyo más profundo
- La respuesta no es renunciar a la velocidad, sino ubicarla de forma intencional: la velocidad de la IA debe desplegarse solo después de confirmar que se va en la dirección correcta
Cuándo la lentitud sí rinde
- Los puntos donde la lentitud deliberada genera valor no han cambiado demasiado
- Cambiar requisitos es barato cuando todavía son palabras en un documento, y caro cuando ya son código desplegado que atiende a usuarios reales
- Las decisiones de diseño son fáciles de corregir en diagramas y difíciles en sistemas de producción
- La IA no cambió esta física fundamental; lo que hizo fue aumentar la palanca cuando se aplica bien
- Protocolo Thinking First: antes de pasarle una tarea a la IA, el punto más barato para detectar errores es invertir tiempo en aclarar qué es lo que realmente se quiere
- Hay una paradoja interesante: la IA puede usarse no solo para acelerar la ejecución, sino también para acelerar la reflexión misma
- Aclarar requisitos antes de programar: dedicar 10 minutos a escribir qué problema se quiere resolver, cuáles son los criterios de éxito y qué restricciones hay, y luego pedirle a la IA que revise lo escrito antes de generar nada
- Ejecutar un pre-mortem: antes de cerrar un diseño, preguntarle a la IA “¿qué podría salir mal con este enfoque?” para sacar riesgos que no se habían considerado
- Invertir el problema: preguntarle a la IA “¿qué haría fracasar este proyecto?” para exponer supuestos ocultos
- Construir un prototipo descartable: hacerlo con IA en unas horas, mostrarlo a las partes interesadas y validar el entendimiento antes de invertir; usar velocidad al servicio de la lentitud
- Construir una herramienta interna sencilla: antes de gastar en el producto real, crear primero con IA una versión rústica para entender qué se necesita de verdad y qué no
- Detectar casos límite temprano: antes de empezar a implementar, pedirle a la IA que genere casos límite y modos de falla del diseño para resolverlos en la etapa de diagramas
Un nuevo viento cultural en contra
- “¿No basta con usar IA?” es una nueva forma de presión por la velocidad, y es especialmente peligrosa porque confunde la apariencia de productividad con el rendimiento real
- La IA puede generar código en segundos, pero generar código y resolver el problema correcto no son lo mismo
- Estrategias de respuesta:
- Compartir explícitamente en qué etapa se está: si se está en una etapa lenta, explicar que se está aclarando requisitos, pensando casos límite o verificando que se resuelve el problema correcto
- Involucrar a las partes interesadas: incorporar su aporte ahora es barato; más adelante será caro
- Compartir el proceso de trabajo: hacer visibles los entregables de la etapa lenta, como documentos de requisitos, bocetos de diseño o resultados del pre-mortem, para demostrar que sí hay avance
- Poner límites de tiempo a la etapa lenta: establecer fronteras claras, por ejemplo “dos días de aclaración de requisitos antes de escribir código”, para que la lentitud deliberada se perciba como algo planificado y no abierto
- Compartir lo aprendido: actualizar brevemente sobre casos límite descubiertos o supuestos que resultaron falsos, convirtiendo la etapa lenta en un flujo visible de valor
- Mostrar quick wins: crear temprano un prototipo descartable o un mockup para demostrar que se puede avanzar rápido y así ganar confianza para el trabajo lento y cuidadoso
- Se parece al concepto de Hill Chart del método Shape Up de Basecamp
- Subida: etapa lenta en la que hay mucha incertidumbre y se descubre la naturaleza real del trabajo
- Bajada: etapa rápida donde el camino ya está claro y solo queda ejecutar
- No es una excusa para retrasarse, sino una explicación de cómo ocurre realmente el buen trabajo: a largo plazo, los equipos que lanzan más rápido suelen ser justamente los que saben bajar la velocidad en el momento adecuado
Cómo ponerlo en práctica
- Antes de la próxima tarea asistida por IA, probar esto:
- Dedicar 10 minutos a escribir el problema que realmente se quiere resolver, cómo se vería el éxito y qué queda fuera de alcance
- Antes de empezar a construir, pedirle a la IA que ejecute un pre-mortem sobre el enfoque
- Si el trabajo es de cierta magnitud, construir primero un prototipo descartable para validar la dirección
Conclusión
- La velocidad y la lentitud no son opuestas, sino herramientas para etapas distintas
- La IA sirve para ambas: ejecución rápida cuando la dirección está clara y reflexión acelerada cuando todavía no lo está
- La capacidad clave es entender en qué etapa se está y aplicar el ritmo adecuado
4 comentarios
Existe el dicho: despacio y rápido.
Era algo que mi profesor me decía seguido en la maestría,
me está dando PTSD otra vez después de tanto tiempo.
Lo escuché en el ejército.
Lo leí en la partitura
allegro non troppo (rápido, pero sin apresurarse)