Durante mucho tiempo, el costo de desarrollar software cumplió una función que nadie le había asignado: obligaba a discutir.

Antes de dedicar meses a una funcionalidad, alguien tenía que explicar por qué valía la pena construirla. Los equipos debían decidir qué entraba, qué quedaba afuera y qué problema justificaba el esfuerzo. El proceso era lento y no siempre producía buenas decisiones, pero creaba una pausa.

La IA está eliminando gran parte de esa fricción. Hoy podemos probar una interacción en una tarde o convertir una idea en algo funcional antes de decidir si realmente la necesitamos.

Es una mejora importante. También crea un problema menos visible: cuando construir se vuelve barato, también se vuelve barato construir de más.

En The Convergence Trap, escribí sobre cómo distintos equipos, trabajando con modelos similares y enfrentando las mismas restricciones, terminan llegando a soluciones parecidas. Las arquitecturas se repiten. También las interfaces e incluso el lenguaje usado para describir el producto.

El modelo sugiere la respuesta más probable. Cuando muchos equipos comienzan con esa respuesta, sus productos convergen.

Pero hay otra consecuencia. Esas soluciones similares no solo se repiten entre productos. También empiezan a acumularse dentro de cada uno.

Aparece una tarea manual y automatizarla parece razonable. Los usuarios siguen haciendo la misma pregunta, así que alguien propone un asistente. Cada incorporación tiene un argumento convincente detrás y, muchas veces, una demo que funciona. Con el tiempo, el producto puede hacer mucho más sin necesariamente resolver mejor su problema original.

Parte de esa similitud es razonable. Problemas parecidos suelen tener soluciones parecidas, y usar un patrón conocido no es una falta de imaginación. La dificultad empieza cuando la respuesta técnica reemplaza una decisión que depende del contexto.

En un proyecto de procesamiento de documentos, por ejemplo, dos campos podían representar una cantidad. El modelo podía elegir uno y producir una respuesta perfectamente plausible. La decisión real estaba en otro lado: cuál de los dos campos tenía autoridad y qué debía ocurrir cuando se contradecían.

Un mejor prompt no podía resolverlo.

Algo parecido ocurrió con una herramienta de conocimiento. Extraer una afirmación de un documento era relativamente sencillo. La pregunta importante era si esa afirmación debía entrar al sistema como un hecho o permanecer pendiente hasta que una persona la confirmara. La diferencia técnica parecía menor. La diferencia en la confianza del usuario era considerable.

Ambos casos tenían respuestas fáciles de implementar. Ninguna de esas decisiones podía delegarse por completo al modelo.

Este es el costo que las estimaciones suelen omitir. Una funcionalidad no cuesta solamente lo que lleva construirla. Después hay que integrarla, explicarla, mantenerla y asignarle los permisos adecuados. Hay que anticipar sus fallas. También consume atención. Una funcionalidad puede operar exactamente como fue diseñada y aun así empeorar el producto.

Con IA, “menos es más” es una disciplina de producto, no una estética minimalista. Algunos problemas complejos requieren productos complejos. La pregunta es si cada parte existe por una necesidad observada o porque la tecnología hizo tentador agregarla.

Un producto pequeño también puede ser genérico. Quitar funcionalidades no crea criterio por sí solo. Las decisiones que permanecen deben surgir del flujo real, de sus excepciones y de las consecuencias de equivocarse.

La IA también puede ayudarnos a construir menos. Permite crear prototipos descartables y probar la hipótesis central antes de convertir una idea en una funcionalidad permanente. Si el experimento muestra que nada importante cambia, eliminarlo es un resultado útil.

Antes de agregar algo, deberíamos poder explicar qué comportamiento específico busca cambiar. Si funciona, también deberíamos preguntar qué parte del producto podría desaparecer. La revisión termina cuando podemos explicar por qué esta solución pertenece a este producto en particular y no a cualquier otro.

En el pasado, la pausa venía impuesta por los presupuestos y los plazos. Ahora hay que introducirla de forma deliberada, justo cuando el primer prototipo empieza a sentirse como una decisión ya tomada.

De lo contrario, la IA nos ayudará a construir mucho más rápido, incluso aquello que nadie necesitaba.