Decidir es más difícil que construir

Hay un experimento famoso en psicología del consumo. En un supermercado, los investigadores pusieron una mesa con muestras de mermelada. Un día ofrecieron 24 variedades. Otro día, solo 6. Con 24 opciones, más personas se acercaron a probar. Pero con 6 opciones, diez veces más personas compraron. La abundancia atraía atención. La escasez generaba acción.

Barry Schwartz llamó a esto la paradoja de la elección: más opciones no producen mejores decisiones. Producen parálisis.

Software está viviendo su propio momento de las 24 mermeladas. Y casi nadie lo ha notado.

Durante décadas, el costo de construir software funcionó como un filtro natural. Querías desarrollar una app, necesitabas seis meses, un equipo de cinco personas y un presupuesto considerable. Esa restricción era dolorosa, pero tenía un efecto secundario valioso: te obligaba a elegir. No podías construir todo, así que tenías que decidir qué valía la pena. El costo de producción hacía el trabajo de edición por ti.

La IA eliminó ese filtro. Y nadie habla de lo que pasa cuando el filtro desaparece.

Cuando todo es viable, nada es obvio

Hoy, un equipo competente con herramientas de IA puede construir un MVP funcional en semanas, no en meses. Puede prototipar tres ideas en el tiempo que antes tomaba prototipar una. Puede explorar direcciones que antes hubieran sido descartadas por impracticables solo por el costo de implementación.

Esto suena a progreso puro. Y en cierto sentido lo es. Pero tiene una consecuencia que nadie anticipó: cuando el costo de construir se acerca a cero, el espacio de decisión explota.

Antes, si tu empresa tenía presupuesto para un proyecto al trimestre, la decisión era difícil pero manejable. Tenías diez ideas, podías ejecutar una, elegías la mejor. Era como un examen de opción múltiple con pocas respuestas posibles.

Ahora puedes ejecutar cinco proyectos al trimestre. O diez. La pregunta ya no es “qué podemos construir” sino “qué deberíamos construir entre las infinitas cosas que podemos construir.” No es un examen de opción múltiple. Es un ensayo de respuesta abierta. Y la mayoría de las organizaciones no están preparadas para ese formato.

Cuando construir era caro, el recurso escaso era capacidad técnica. Ahora que construir es barato, el recurso escaso es criterio para decidir qué vale la pena.

He visto esto en persona. Equipos que antes sufrían porque no podían ejecutar sus ideas ahora sufren porque pueden ejecutar todas sus ideas. Tienen tres prototipos corriendo simultáneamente, ninguno con suficiente convicción detrás. Los recursos técnicos no son el problema. La claridad estratégica sí.

La restricción como aliado

Hay una idea contraintuitiva que los creativos entienden bien: las restricciones no limitan la creatividad. La dirigen. Un soneto tiene catorce versos y una estructura rígida. Esas restricciones no impidieron que Shakespeare escribiera algunos de los mejores poemas en el idioma inglés. Lo obligaron a comprimir su pensamiento, a elegir cada palabra con precisión.

Un presupuesto limitado hace lo mismo para el desarrollo de producto. Te obliga a responder preguntas duras: ¿Esto realmente resuelve un problema? ¿Es el problema más importante? ¿Estamos construyendo esto porque lo necesitamos o porque podemos?

Cuando la IA elimina la restricción del costo de producción, esas preguntas dejan de tener una respuesta forzada. Antes, el costo te obligaba a priorizar aunque no quisieras. Ahora tienes que priorizar por convicción, no por necesidad. Y la convicción es mucho más difícil de conseguir que el presupuesto.

Esto explica algo que parece contradictorio: empresas con más recursos tecnológicos que nunca producen software más mediocre que nunca. No porque las herramientas sean malas, sino porque la abundancia de capacidad diluye el foco. Construyen más, pero cada cosa que construyen tiene menos pensamiento detrás.

Es la diferencia entre un chef que cocina un plato con cinco ingredientes y otro que tiene acceso a mil. El primero está limitado pero enfocado. El segundo tiene todo a su disposición y el riesgo de que el plato no sepa a nada en particular.

El nuevo cuello de botella

Si mapeas la cadena de valor del software, desde la idea hasta el usuario satisfecho, encontrarás que los cuellos de botella se movieron. Hace cinco años, el diagrama se veía así:

Idea (rápido) —> Especificación (medio) —> Desarrollo (lento) —> Pruebas (medio) —> Lanzamiento (rápido)

El desarrollo era el cuello de botella. Todo el sistema se optimizaba alrededor de esa restricción. Contratábamos más desarrolladores. Adoptábamos metodologías ágiles. Medíamos velocity. El objetivo era hacer que la parte lenta fuera más rápida.

La IA logró eso. El desarrollo ya no es el cuello de botella. Pero el sistema tiene un nuevo punto de constricción:

Idea (???) —> Especificación (lento) —> Desarrollo (rápido) —> Pruebas (rápido) —> Lanzamiento (rápido)

El cuello de botella se movió aguas arriba. Ahora está en la fase de “qué construir” y “cómo definirlo.” Y esa fase no se resuelve con más herramientas. Se resuelve con mejor pensamiento.

La teoría de restricciones de Goldratt dice que cualquier mejora que no sea en el cuello de botella es una ilusión de progreso. Si el cuello de botella es la decisión de qué construir, optimizar la velocidad de construcción es como ampliar una autopista que termina en un camino de tierra. Los autos llegan más rápido al punto donde todo se frena.

Esto se manifiesta de formas concretas. Cualquiera que trabaje en producto las reconocerá. El backlog crece en lugar de encogerse, porque generar ideas es fácil y filtrarlas es difícil. Los sprints se llenan de features que nadie priorizó con rigor porque “total, son rápidas de implementar.” Los roadmaps se vuelven documentos de fantasía donde todo es prioridad uno, porque cuando el costo de ejecución baja, la presión de elegir desaparece.

Y el resultado paradójico: equipos que entregan más que nunca y productos que mejoran menos que nunca. La velocidad de entrega superó la velocidad de pensamiento. Lo que sobra no es capacidad de construcción sino claridad de dirección.

Aceleramos la producción y descubrimos que el verdadero problema siempre estuvo antes: en saber qué producir.

Las habilidades que no cotizaban

Esto tiene implicaciones incómodas para cómo la industria del software valora a las personas. Durante años, las habilidades más cotizadas eran técnicas: dominar un lenguaje, conocer un framework, optimizar rendimiento. Las habilidades “blandas” (comunicación, pensamiento estratégico, empatía con el usuario, capacidad de decir no) eran secundarias. Bonitas de tener. No esenciales.

Ese orden se invirtió.

La persona que sabe hacer la pregunta correcta antes de que se escriba una línea de código ahora es más valiosa que la persona que escribe la línea de código más elegante. La persona que puede sentarse con un cliente, escuchar lo que dice, entender lo que quiere decir, y definir un problema con claridad: esa persona es el nuevo cuello de botella humano. En el mejor sentido.

No porque las habilidades técnicas dejaron de importar. Importan. Pero dejaron de ser diferenciadoras. Cuando un modelo de lenguaje escribe código aceptable en segundos, la habilidad de escribir código manualmente ya no te separa del resto. Lo que te separa es saber qué código debería existir.

Es una transición análoga a lo que pasó en la música cuando los sintetizadores reemplazaron a los músicos de sesión. La habilidad técnica de tocar un instrumento dejó de ser el filtro. Lo que quedó fue la capacidad de componer: de decidir qué notas, en qué orden, para qué efecto emocional. Los músicos que eran fundamentalmente compositores que usaban instrumentos como medio prosperaron. Los que eran fundamentalmente ejecutantes de las ideas de otros enfrentaron una competencia brutal.

Lo que esto cambia

La consecuencia práctica es que las organizaciones necesitan invertir en capacidad de decisión con la misma seriedad con que antes invertían en capacidad de ejecución. Eso significa cosas concretas:

Significa que el descubrimiento de producto --- entender qué construir antes de construirlo --- deja de ser un paso opcional que se comprime cuando el timeline aprieta. Se convierte en el trabajo.

Significa que las personas que funcionan bien en la ambigüedad se vuelven críticas. Las que no se paralizan ante preguntas sin respuesta clara, que pueden avanzar con información incompleta, que saben cuándo una decisión al 70% es suficiente.

Significa que la cultura de “construir primero, preguntar después” que dominó la era de las startups necesita revisarse. Cuando construir era caro, construir rápido y aprender era eficiente porque la alternativa --- analizar por meses --- costaba lo mismo que un prototipo. Pero cuando construir es casi gratis, puedes construir diez prototipos sin aprender nada si no sabes qué preguntas estás intentando responder.

La paradoja final: la IA hizo más fácil construir y, al hacerlo, hizo más difícil decidir. Las organizaciones que traten la decisión como el nuevo cuello de botella, que inviertan en pensamiento con la misma intensidad con que invirtieron en velocidad, van a producir software que resuelve problemas reales.

Las que sigan optimizando la velocidad de producción van a producir más software que nadie pidió, más rápido que nunca.

El costo de construir mal solía ser meses. Ahora es semanas. Lo que no cambió es el costo de decidir mal: sigue siendo todo.