Decimos que construimos software. Como si fuera algo sólido. Como si hubiera planos definitivos, materiales estables y un momento claro en el que alguien pudiera decir: “ya está”.

A los desarrolladores nos gusta pensar que escribimos código y el sistema emerge, limpio, coherente, casi elegante. Los diseñadores definen experiencias, flujos, journeys, que después contamos a los clientes. A los clientes les decimos que vamos a construir una solución que cubre sus necesidades actuales… y las futuras, si el presupuesto lo permite.

La palabra clave es construir. Porque suena a control. A previsibilidad. A dominio técnico.

La realidad es otra.

En realidad no construimos software. Negociamos constantemente con la ambigüedad.

No implementamos requisitos. Interpretamos frases incompletas dichas en reuniones largas. No diseñamos pantallas. Tomamos decisiones irreversibles basadas en hipótesis que sabremos si eran correctas meses después. No entregamos soluciones. Entregamos compromisos temporales entre tiempo, coste, expectativas y deuda técnica.

El código no es el producto. El código es el rastro fósil de decisiones humanas.

Cada línea existe porque alguien tuvo que elegir rápido, porque algo no estaba claro, porque “de momento vale”. Y ese “de momento” acaba sosteniendo un negocio entero.

Y entonces llegó la IA.

La nueva ilusión es que ahora el software se escribe solo. Que la fricción del desarrollo ha desaparecido. Que si una IA genera código, el problema ya no es técnico sino “solo de ideas”.

Pero la fricción nunca estuvo en teclear.

La fricción está en decidir qué construir. En entender por qué algo no funciona. En asumir las consecuencias de una decisión seis meses después, cuando el contexto ha cambiado y nadie recuerda por qué se hizo así.

La IA no elimina esa fricción. La desplaza.

Ahora el código aparece más rápido, sí. Pero también aparecen más decisiones, más temprano, con más superficie de error. La complejidad no se reduce: se acelera.

Y aquí entra otra ilusión peligrosa: la de la experiencia de desarrollador perfecta.

Pensamos que mejorar la Developer Experience es eliminar fricción. Pero la fricción no es el enemigo. La fricción mal situada lo es.

Un buen entorno no elimina la dificultad. La coloca donde aporta valor.

Cuando la DX es mala, el desarrollador lucha contra herramientas, procesos y plataformas. Cuando es buena, lucha contra el problema real.

La IA promete eliminar fricción, pero en realidad exige más criterio, más contexto y más responsabilidad. Porque alguien tiene que validar. Alguien tiene que entender. Alguien tiene que decir “esto no”.

Y ese alguien sigue siendo humano.

Hemos creado una industria entera basada en ilusiones compartidas: que el software se puede planificar como una obra civil, que los requisitos existen antes de empezar, que el usuario sabe lo que quiere, y ahora, que la IA entiende el problema mejor que nosotros.

Y, sin embargo, la ilusión no es un fallo. Es el pegamento.

Sin ella, sería imposible empezar. Nadie firmaría un proyecto diciendo: “Durante los próximos 12 meses aprenderemos cosas, cambiaremos de opinión, reescribiremos partes clave y al final tendrás algo distinto a lo que imaginabas, pero probablemente más útil.”

Y, sin embargo, hay gente que sí firma. No porque ignore la ambigüedad, sino precisamente porque la reconoce. No creen en la ilusión de control, creen en la capacidad de adaptarse. Han pasado ya por proyectos donde el plan inicial murió pronto, pero el resultado final fue mejor. Han visto que el valor no estaba en acertar a la primera, sino en aprender más rápido que los demás.

Estas personas no compran certezas. Compran criterio. No esperan promesas cerradas, esperan equipos que piensen, que digan “no lo sé” a tiempo y que sepan corregir el rumbo sin dramatismos. No buscan la ausencia de riesgo, buscan gente que ya haya navegado en él y haya vuelto con cicatrices útiles.

Para ellos, la ambigüedad no es una amenaza. Es una señal de honestidad.

Porque saben que el verdadero riesgo no es no saber. El verdadero riesgo es fingir que se sabe.

Son los que han visto proyectos fracasar no por falta de talento, sino por exceso de seguridad. Los que han aprendido que un roadmap rígido tranquiliza al principio, pero asfixia al final. Los que prefieren un equipo incómodo con preguntas difíciles antes que uno cómodo repitiendo respuestas antiguas.

Con esa gente no se “construye” software. Se construye confianza.

Y desde ahí, el software aparece como consecuencia, no como promesa. Cambia, evoluciona, a veces decepciona, pero casi siempre enseña algo útil. No porque estuviera perfectamente diseñado desde el inicio, sino porque hubo espacio para pensar, para frenar y para corregir.

Quizá por eso la ilusión sigue siendo necesaria para empezar, pero deja de serlo para avanzar.

Al final, el software no lo sostienen los planes, ni el código, ni ahora la IA. Lo sostienen personas que ya han vivido el caos y, aun así, deciden volver a entrar.

Así que seguimos diciendo que construimos software. Y ahora decimos que lo hace la IA.

Aunque en realidad seguimos haciendo lo mismo de siempre: explorar, ajustar, equivocarnos, renegociar y volver a empezar.

La diferencia es que ahora todo va más rápido. Y cuando te equivocas, también.