Una tarde con Claude no es una estimación

En Nerdearla hubo un tema que volvía de charla en charla aunque no estuviera en el título. Los roles se están moviendo, y no solo el de quien desarrolla. CEOs y directivos ya no se quedan en gestionar el negocio: abren Claude o Cursor un sábado y prueban ellos mismos esa idea que llevaban años queriendo hacer. Vibe coding: describes lo que quieres, el modelo escribe el código, y en un par de horas tienes algo que se puede clickear.

Yo lo había visto antes de escucharlo ahí. A veces de cerca, a veces contado por otros. Y no tiene nada de malo. Validar una idea propia en una tarde, sin pedirle a nadie un sprint, es de lo mejor que trajo la IA.

El problema no es el prototipo. Es lo que el prototipo le hace a la vara.

Cada sesión de vibe coding termina igual: la idea funciona y tardó horas. Después de la tercera o la cuarta, eso deja de ser una experiencia y se vuelve una referencia. “Esto se hace en una tarde.”

Entonces llega una estimación del equipo. Seis semanas para algo parecido a lo del sábado. Y la reacción no es preguntar qué hay en esas seis semanas. Es pensar que el equipo es lento.

No es mala fe. Es un sesgo, y se arma solo, sesión a sesión, sin que nadie lo note.

Un prototipo hecho con IA resuelve el camino feliz. Una persona, un caso, datos de ejemplo, nada fallando. Todo lo demás no aparece, y por eso no se cobra:

• ¿Qué pasa cuando dos personas pagan al mismo tiempo?
• ¿Quién puede ver qué, y qué pasa cuando le cambian el rol?
• ¿Dónde quedan los logs cuando algo falla a las tres de la mañana?
• ¿Cómo migras los datos que ya existen sin romperle nada a quien ya paga?
• ¿Quién lo mantiene en seis meses, cuando el modelo que lo escribió ya no está en la conversación?

La parte transaccional, la operación y el mantenimiento son el producto. El prototipo es la idea con buena cara. Las dos cosas valen, pero no cuestan lo mismo, y quien solo hizo la primera mide la segunda con el reloj equivocado.

El sesgo no se queda en una conversación incómoda. Se filtra en decisiones:

• Una fecha comprometida con un cliente o un inversor antes de preguntarle a nadie del equipo.
• Un roadmap con tres features por trimestre, porque cada una “es una tarde”.
• Un equipo que, para cumplir, recorta lo que no se ve: tests, permisos, migraciones. Eso no desaparece. Vuelve como incidente.
• Gente que se quema intentando alcanzar una vara que nunca fue real, y que un día se va.

Y el más caro, porque no hace ruido: el equipo deja de estimar honesto. Si cada estimación real se lee como lentitud, la gente empieza a decir el número que el directivo quiere escuchar. A partir de ahí, quien decide pierde la única información que le decía cuánto cuesta lo que pide.

No era un problema de velocidad. Era un problema de confianza en los números.

No sirve discutir el código del prototipo. Lo escribió un modelo para que algo se viera, no para que aguantara, y casi nunca es lo que vas a mantener. Lo que sí vale es todo lo demás: qué problema quería resolver, qué pantalla le importó primero, qué dejó afuera sin darse cuenta. Ese prototipo es una spec, y muchas veces mejor que las que llegan en un documento.

Lo que me funciona es sentarme con quien lo hizo y recorrerlo juntos, separando tres listas:

• Lo que resuelve: el flujo que le importa, el dato que muestra, la decisión que habilita.
• Lo que asume: un solo usuario, datos limpios, nadie más tocando lo mismo, que nada falla.
• Lo que no sabe que existe: facturación, permisos, auditoría, soporte, la migración de lo que ya está en producción.

La primera lista es la tarde del sábado. Las otras dos son las seis semanas. Cuando están una al lado de la otra, la estimación deja de parecer inflada, porque quien preguntó está viendo lo mismo que el equipo.

A veces de ahí sale que no hacen falta seis semanas. Que la mitad de lo que asumía el prototipo puede esperar, y una versión más chica sale en dos. Esa también es una buena respuesta. Lo que no sirve es estimar a ciegas, en ninguna de las dos direcciones.

Que quien dirige pruebe sus ideas con Claude está bien. Llega a la conversación con algo más claro que muchas reuniones. Lo que no aguanta es que esa tarde se convierta en la vara con la que mide a su equipo.

Antes de comprometer una fecha, recorre el prototipo con alguien que lo vaya a mantener y separa las tres listas. La IA acelera la idea. Sostenerla sigue siendo trabajo de alguien, y ese trabajo no sale en pantalla.