Probablemente habrás oído hablar de la famosa regla de los 2 minutos de David Allen: si puedes hacer algo en menos de dos minutos, simplemente hazlo. De lo contrario, posponerlo, añadirlo a tu lista de tareas y retomarlo más tarde acabará llevándote más tiempo que los 2 minutos que habrías “invertido” en resolverlo en primera instancia.

Creo que ahora necesitamos una regla similar para el vibe coding:

Si puedes crear la aplicación que necesitas en dos horas o menos, simplemente hazla.

Hace poco creé con vibe coding en dos horas una pequeña aplicación para gestionar gastos compartidos en viajes con amigos. Y otra para mostrar aleatoriamente fotos de mis carpetas de Google Drive (sí, un lugar un poco extraño para guardar fotos familiares). Obviamente, es muy probable que existan muchas aplicaciones para ambas cosas. Pero buscarlas, compararlas, probarlas, crear una cuenta, descubrir que la versión gratuita es demasiado limitada, darte cuenta de que la aplicación no funciona exactamente como quieres, frustrarte y probar otra puede llevarte fácilmente más de dos horas… Así que, ¿por qué no utilizar esas dos horas para crear exactamente la pequeña aplicación que necesitas?

Lo sé, lo sé, esto va en contra de la recomendación tradicional de evitar el síndrome Not Invented Here. Hasta ahora, desarrollar tu propia versión de una aplicación ya existente era, en la mayoría de los casos, una pésima manera de emplear tu tiempo. Pero el vibe coding (o “desarrollo agéntico”, si queremos que suene más sofisticado) cambia la economía de esta decisión. Para una categoría cada vez mayor de pequeñas aplicaciones, crear la herramienta que necesitas puede ser ahora más rápido que buscar una ya existente y adaptar tu forma de trabajar a ella.

Me refiero, básicamente, a aplicaciones sencillas que te resultan útiles a ti, aunque nadie más llegue a utilizarlas nunca. De hecho, mejor incluso si no las haces públicas de forma generalizada (eso requeriría más funcionalidades, como gestión multiusuario, análisis de seguridad…, y ya nos saldríamos de las 2 horas). Pueden ser aplicaciones desechables. No necesitan una hoja de ruta, una comunidad ni una arquitectura sofisticada. Las utilizas mientras te resulten útiles y después las descartas.

Pero asegúrate de que realmente es una aplicación de dos horas

Permíteme insistir en este punto: mi regla tiene un riesgo. Lo que parece una aplicación de dos horas puede acabar requiriendo dos días, dos semanas o mucho más.

Esto ocurre especialmente cuando la gente intenta clonar una aplicación existente. Como comentaba en el porqué clonar una aplicación puede acabar mal, al clonar una aplicación tendemos a reproducir únicamente lo que podemos ver. Y lo que vemos es mucho menos de lo que la aplicación hace realmente. No vemos todas sus reglas de validación, comprobaciones de seguridad, mecanismos de gestión de errores, funcionalidades de accesibilidad, procedimientos de recuperación ni casos límite. De hecho, solo vemos la parte de su comportamiento que corresponde a nuestra forma personal de utilizarla. Después de dos horas podemos tener algo que se parece a la aplicación original. Eso no significa que la hayamos clonado.

Por tanto, el objetivo de la regla de las 2 horas no debería ser reproducir un producto existente. Debería ser construir la aplicación más pequeña posible que resuelva tu problema concreto. Y las dos horas deben ser un límite de tiempo real:

Si después de dos horas no tienes una versión útil, para y reconsidera si seguir desarrollándola tú mismo sigue siendo la mejor opción.

Evita la falacia del sunk cost. Haber invertido ya 2 horas (y unos cuantos tokens) no debería ser una razón para invertir todavía más. Esto también se aplica al mantenimiento de la aplicación. Un prototipo creado en dos horas que después genera decenas de horas de mantenimiento no es una aplicación de dos horas.

Ten en cuenta que la regla de las 2 horas no es una invitación a reconstruir todo el software que utilizamos. Es una invitación a reconocer que, a veces, crear una pequeña herramienta adaptada a tus necesidades resulta ahora más barato que encontrar la opción “óptima” ya existente.