Pensar antes de programar

Últimamente parece que todas las herramientas quieren pujar por lo mismo: que programemos cada vez más rápido, que los agentes de IA estén en todos sitios, que cualquier herramienta pueda escribir una funcionalidad de nuestro producto. Desde Linear, desde Cursor, desde Vercel, desde Sentry. Prácticamente todas están pidiendo acceso a nuestro código y ofreciendo construir la funcionalidad, o arreglar el bug, directamente desde ahí.

La verdad es que soy parcialmente escéptico. En Punto llevamos programando con AI de forma intensiva casi dos años. Tenemos código en producción gestionando millones de euros al año, con datos delicados, en un sector —la tramitación para la administración pública— donde el margen de error es pequeño. Intentamos ser todo lo agresivos que podemos para aumentar la productividad del equipo, a la vez que mantenemos un nivel de calidad muy alto.

Por eso permitidme ser escéptico con este empuje de agentes AI en todos sitios. Hay un paso básico en construir un producto que es pensar. Y cuando estas herramientas cogen el email de un cliente, lo convierten en una funcionalidad y nos dejan el PR preparado para revisar, o cogen un supuesto bug en producción y nos plantean directamente el fix, se están saltando ese paso.

Los agentes resuelven las accidental tasks. Las essential tasks siguen ahí

En 1986 Fred Brooks —el mismo que escribió The Mythical Man-Month— publicó No Silver Bullet: Essence and Accident in Software Engineering. Os recomiendo encarecidamente leerlo. En él distingue dos tipos de dificultad en construir software:

All software construction involves essential tasks, the fashioning of the complex conceptual structures that compose the abstract software entity, and accidental tasks, the representation of these abstract entities in programming languages and the mapping of these onto machine languages within space and speed constraints.

Las accidental tasks son la representación: escribir la sintaxis correcta, mapear las estructuras abstractas a un lenguaje de programación, hacer que corra dentro de las restricciones de máquina. Las essential tasks son otra cosa: construir la estructura conceptual que resuelve el problema.

Los agentes de IA están resolviendo, y muy bien, las accidental tasks. Lo que queda —lo que sigue siendo esencial— es entender qué queremos priorizar y cuál es la solución ideal. Ese reto no ha desaparecido. La IA nos ayuda, pero no tiene el criterio. Estamos igual que hace cuarenta años.

Descubrir y definir, antes de desarrollar y entregar

Llevamos decenas de años de aprendizaje colectivo en producto que apunta en la misma dirección: antes de construir, hay que descubrir cuál es el problema y tenerlo claro, y definir bien cuál es la solución. Para eso existen marcos como el Double Diamond, del Design Council británico.

La idea es sencilla: hacemos un ciclo de descubrir y definir, y solo cuando eso está claro entramos en desarrollo y entrega. Marty Cagan lleva defendiendo lo mismo desde hace más de una década, separando explícitamente discovery de delivery: son dos actividades distintas, con objetivos distintos. Es un fallo muy común del equipo de producto saltarse la primera.

Si directamente programamos, nos estamos saltando el paso de descubrir y definir. Porque estamos tomando muchas decisiones a la vez. He leído artículos y tuits defendiendo que se puede programar directamente sobre el código, coger feedback real, e iterar. El problema es que al implementarlo el agente de IA ha tomado ya muchas decisiones de usabilidad, de estructura, de modelo de datos, de arquitectura, de modularización y de refactorización entre muchos otros temas. Son muchas decisiones tomadas cuando todavía no sabemos si es la mejor solución de producto. Y cada una de esas decisiones, tomada sin pensar, es un producto y un código que vamos a tener que mantener.

Un enfoque distinto, y el adecuado bajo mi punto de vista, es programar un prototipo fuera del código de producción que nos sirve para descubrir y definir. El otro día compartía un ejemplo nuestro de cómo iteramos el prototipo en vivo según hacíamos pruebas de usuario. Es un código que vamos a tirar a la basura. Lo que queremos llevarnos son los aprendizajes de producto.

El problema que nos cuentan no siempre es el problema real

Hay otra buena práctica de producto que merece la pena recordar aquí: entender el job to be done. Clayton Christensen lo popularizó con el ejemplo del batido: los usuarios expresan su problema de una manera, pero muchas veces el problema real es otro. Relacionado, pero no exactamente igual.

Nos pasa a todos constantemente. Hace un par de semanas el equipo de operaciones nos pedía añadir una funcionalidad para que los clientes nos avisaran de un tipo concreto de incidencia. Al profundizar, resultó que los clientes en realidad estaban intentando resolver otra cosa. Relacionada, pero distinta a lo que pedía el ticket.

Si un agente de AI lo hubiese implementado tal cual venía en el feedback, no habría sido la solución correcta. Habría liado a los usuarios y no habría cubierto todas las casuísticas. Lo resolvimos bien porque nos abstraímos y entendimos el problema real. Eso exige tiempo y una conversación que un agente, lanzado directamente desde el ticket a programar, no tiene forma de tener.

Las herramientas no tienen la visión del producto

Hay dos motivos más por los que sigo siendo escéptico de saltarnos pasos.

El primero: por mucho que tengamos recursos y sea más rápido, no significa que queramos solucionar algo ahora. Todo esfuerzo de código nos va a recaer en mantenimiento de producto y de ingeniería. Si nos entretenemos con cualquier mejora pequeña, dejamos de centrarnos en lo que de verdad tiene impacto en el producto. Una funciónalidad nos consume mucho más tiempo que solo programarla.

El segundo: estas herramientas no tienen la visión del producto. La que tenemos en la cabeza de hacia dónde va Punto es difícil de transmitir de forma que un agente lo tenga presente de forma constante en cada decisión que toma. Y cuando tratamos un tema entre varias personas, del debate salen mejores soluciones. Si un agente pasa directamente de la idea al código, sin que haya habido esa conversación entre personas, no va a salir la mejor solución.

Quedémonos con los principios, incorporemos lo nuevo

Estamos en una nueva era, y algunas prácticas van a cambiar. Pero antes de tirarlo todo por la borda, hay que entender el porqué de lo que ya sabíamos. Los principios de cómo queremos trabajar —entender el problema, decidir si es prioritario ahora, tener visión de producto, debatir antes de construir— se mantienen. Lo que cambia es la velocidad a la que podemos ejecutar una vez que hemos pensado.

Llamadme artesano, pero creo que el criterio es lo que nos define como profesionales, y debe seguir siendo lo que nosotros fijemos. Hay mucho trabajo que la IA nos está quitando, y nos quitará aún más. Pero esa parte —cuál es el problema, cuándo lo queremos solucionar, cuál es el enfoque— es algo que debemos seguir pensando y dedicándole un rato.

En próximos artículos contaré más ejemplos de cómo estamos trabajando en Punto esta fase de discovery y la transición al desarrollo.