Beakman, Ford y dividir para entregar

Cuando era niño, no me perdía El mundo de Beakman en TV Cultura. Era ruidoso y raro, y me enseñó cómo funcionan las cosas. Un episodio se me quedó para toda la vida: el de Henry Ford y la línea de montaje. La idea de que podías agarrar una tarea enorme e intimidante, armar un auto entero, y convertirla en una secuencia de pasos pequeños y repetibles que cualquier persona podía hacer bien.

Décadas después, sigo pensando así en cómo entregar software. El instinto de la mayoría de los equipos, frente a algo grande, es mapear todos los requisitos antes de escribir código. Parece responsable, pero así es como el proyecto se traba.

Cuarenta endpoints y un squad trabado en la especificación

Un ejemplo al que siempre vuelvo: un squad estaba atrasado en una integración con unos cuarenta endpoints. El equipo estaba paralizado, tratando de especificar los cuarenta antes de construir nada. La especificación solo crecía, el plazo solo se movía, y nada funcionaba de verdad.

Entonces hice una pregunta distinta: ¿y si, en vez de mapear los cuarenta endpoints, hacemos el sistema de punta a punta con uno solo? Un endpoint, pero conectado por el sistema entero, de la petición a la respuesta, autenticación, manejo de errores, logs, todo. De repente el equipo tenía algo real andando. Se podía validar el enfoque viéndolo andar. Y, igual de importante, llegó la sensación de completitud, la prueba de que el camino funcionaba. Después de eso, los endpoints restantes dejaron de ser un muro y se volvieron un checklist. Cada uno era solo un tramo más de un camino que ya habían pavimentado.

El mismo truco, en migraciones de CRM

Hago lo mismo en migraciones de datos. La tentación es siempre mapear todos los campos antes de mover un solo registro. En vez de eso, arranco con un ejemplo simple y representativo y lo llevo hasta el final. Ese único registro te enseña la forma real de la conexión, las mañas de la autenticación, los límites de tasa, los campos que no coinciden, mucho más rápido que cualquier documento de mapeo. Y le da al cliente algo para ver y comentar en pocos días.

No cambió con la IA. Se volvió más importante.

Veo gente cometiendo el mismo viejo error con una herramienta nueva: tratar de construir una solución de IA compleja de una sola vez, con prompt, agente, herramientas y evaluación entrando juntos. Como ya dijo Matt Pocock, los procesos de ingeniería de software siguen valiendo, incluso con IA en el medio. El modelo cambia cómo escribes el código; la disciplina de entregar una rebanada fina, validarla e iterar sigue valiendo.

Ford simplificó el proceso, una estación a la vez, y yo lo vi en un programa de ciencia para niños antes de escribir mi primera línea de código.