Recientemente, veo a menudo la frase "El desarrollo por contrato está muerto" en mi timeline. Generalmente se discute en el contexto de que la IA está haciendo que el software sea más rápido y más barato de construir, por lo que el modelo tradicional de "construir y entregar exactamente lo que el cliente pide" está perdiendo valor rápidamente.
Al principio, honestamente pensé: "¿Esto es solo otro ciclo de hype de 'X está muerto'?"
Después de todo, la gente ha estado diciendo "El desarrollo por contrato está muerto" durante décadas, incluso antes de la IA. Desarrollo interno, la nube, subcontratación multinivel, offshoring — cada vez, la gente decía "esta vez realmente va a morir", pero el desarrollo por contrato sobrevive como un zombie.
En realidad, pasé mucho tiempo trabajando para empresas de productos, así que solía observar estos temas desde la barrera. Recuerdo que pensaba que el desarrollo por contrato parecía difícil y era algo a lo que no quería acercarme.
Luego, hace tres años, me uní a Hololab Inc., y ahora estoy en medio del trabajo con clientes, incluido el desarrollo por contrato. Para ser honesto, cuando me uní, el término "desarrollo por contrato" me dio un poco de pausa. Aun así, el desafío de la transformación traída por la nueva tecnología y el atractivo de la empresa en sí misma ganaron. Pensé que sería poco cool quejarme del "desarrollo por contrato" sin haberlo probado realmente.
Han pasado tres años desde entonces. Me uní al equipo directivo y me he enfrentado al desarrollo por contrato de frente. Por eso esta vez quiero enfrentar la frase "El desarrollo por contrato está muerto" sin huir.
¿Es cierto que "El desarrollo por contrato está muerto"?
Es cierto.
Incluso antes de la IA, hubo movimientos hacia el no-código en el contexto de la Transformación Digital (DX) y una tendencia hacia el desarrollo interno. Luego llegó la ola de la IA (especialmente los agentes de IA), y esta tendencia se intensificó instantáneamente. Ahora incluso los no ingenieros pueden crear software.
Cuando surge este tema, los ingenieros que viven de ello tienden a hacer escándalo sobre la "calidad" o la "seguridad", argumentando que "el desarrollo de software no es tan fácil".
Sin embargo, la calidad requerida para el software varía según el propósito y el caso de uso. El software para clientes o entornos de producción requiere un cierto nivel de servicio. Por otro lado, el nivel requerido para herramientas internas o PoCs (Pruebas de Concepto) suele ser relativamente bajo. Y es precisamente esta área la que es fácilmente reemplazable por agentes de IA, o más bien, donde el reemplazo ya ha comenzado.
En cuanto a seguridad y calidad, siento que la brecha se está cerrando cada año a medida que los modelos evolucionan y se acumula el conocimiento humano sobre la utilización de la IA. Hace solo dos o tres años, la opinión predominante era "la IA puede ayudar, pero es demasiado pronto para dejarle escribir código", y ahora la IA escribe código más a menudo que no. Mirando esta velocidad de cambio, incluso en áreas donde actualmente es difícil delegar por completo, podría darse fácilmente una situación en la que "la IA sea más confiable que los humanos" en un futuro cercano.
Para ser honesto, como ingeniero, una parte de mí no quiere creer que el trabajo que he hecho pueda ser reemplazado tan fácilmente. Pero puedo ver claramente lo que está muriendo justo frente a mí. Esto no es hype ni un discurso de posición; es un cambio que realmente está ocurriendo.
Sin embargo, esto no significa que "el desarrollo por contrato en su conjunto esté muriendo". Lo que está muriendo no es el desarrollo por contrato, sino el desarrollo de software que es "solo construir". Explicaré por qué pienso esto.
1. No se puede meter todo el "desarrollo por contrato" en el mismo saco
Incluso si dices "desarrollo por contrato" de un tirón, el contenido varía desde empresas que solo venden meses-hombre hasta integradores de sistemas, consultores, socios de producto, PMO y soporte de DX. Así que la pregunta que hay que hacer no es "¿Está muerto el desarrollo por contrato?" sino "¿Qué exactamente está muerto?"
Cuando lo desglosas, la disminución del valor debido a la IA no ocurre de golpe; progresa por etapas. La primera ola golpea el valor del acto de "escribir código". De hecho, la productividad del desarrollo está aumentando y la estructura de ganancias de los proyectos está comenzando a cambiar.
Y esta ola no se detendrá en escribir código. Se extenderá gradualmente al diseño, la definición de requisitos y la fase de conceptualización anterior. Por eso quiero distinguir qué valores caerán primero y cuáles permanecerán.
Entonces, lo que está muriendo es el trabajo de "solo escribir código como te dicen". Ya sea desarrollo por contrato o no, no importa. Y esta área ya se está reduciendo.
Sin embargo, la reducción no es uniforme. Los desarrolladores por contrato pequeños y medianos y los pequeños desarrollos internos están sintiendo toda la fuerza de las olas del desarrollo interno y la IA generativa, y los proyectos están comenzando a desaparecer. Por otro lado, a menudo escucho que los sistemas complejos para grandes empresas aún no están en muchos problemas porque no pueden ser manejados solo por equipos internos. El impacto varía enormemente según la escala y la base de clientes, por lo que mezclarlos nubla la conversación.
2. Los clientes no están comprando "código" en primer lugar
Cuando piensas si los clientes contratan porque quieren que se escriba código, la respuesta es no.
Lo que los clientes esperan es la resolución de problemas: quieren organizar estrategias de negocio, pensar juntos los requisitos, obtener ayuda con la toma de decisiones, asistencia con la coordinación interna y reducir riesgos. El código es solo un medio para ese fin.
Pensando de esta manera, la lógica de "el código se abarató = el desarrollo por contrato está muerto" es bastante miope. Los medios se volvieron más baratos, pero la sustancia esperada no ha desaparecido en absoluto.
Esto coincide con mi propia experiencia trabajando tanto en empresas de productos como en desarrollo por contrato. Hay sitios de desarrollo por contrato que se sumergen profundamente en el negocio, y hay equipos de desarrollo interno que actúan como contratistas internos, construyendo solo lo que el departamento de negocio les dice. Trazar una línea entre "empresa de producto vs. desarrollo por contrato" ya no captura la realidad.
Además, esto no se trata solo del desarrollo por contrato. El límite entre el desarrollo y la consultoría también se está derritiendo. Las firmas de consultoría están cada vez más construyendo equipos de desarrollo, y los integradores de sistemas están comenzando a apoyar el negocio. "SaaS está muerto" sigue la misma estructura: las empresas que solo venden software están acabadas, mientras que las empresas que se sumergen en BPO, operaciones, asociaciones y garantías de rendimiento están creciendo. Consultoría, integradores, SaaS y empresas de producto se están superponiendo cada vez más. El destino es el "valor" para el cliente.
3. "Pensar" y "Construir" se están acercando
Durante mucho tiempo, el costo de construir software era demasiado alto. Por lo tanto, "pensar" y "construir" inevitablemente estaban separados. Los roles se dividían, los títulos de trabajo se dividían, las organizaciones se dividían, e incluso las empresas tendían a dividirse.
La IA ha reducido el costo de "construir". Como resultado, "pensar" y "construir" naturalmente están empezando a converger. Los roles, títulos de trabajo, organizaciones y empresas se están acercando. Este es el cambio que está ocurriendo ahora.
Y lo que el desarrollo Agile quería lograr era exactamente esto: acercar "pensar" y "construir". Finalmente nos estamos acercando al ideal que no se pudo realizar completamente en ese entonces porque el costo de construir era demasiado alto.
De hecho, en nuestro propio trabajo con clientes, los casos que no terminan solo con el desarrollo están aumentando. Lo que comienza como un desarrollo normal a menudo se convierte en "queremos consultar sobre cómo proceder con el negocio", expandiéndose a PMO, diseño de modelos de negocio, promoción de proyectos y apoyo en la toma de decisiones. Hoy en día, hay sitios donde pasamos más tiempo "construyendo el negocio" que "construyendo el sistema". Al principio me preguntaba si esto seguía siendo desarrollo por contrato, pero he dejado de preocuparme por los límites.
He estado escuchando mucho el término FDE (Ingeniero de Despliegue Adelantado) últimamente, y probablemente sea parte de la misma tendencia. Entrar en el sitio del cliente, pensar juntos los problemas y escribir código si es necesario. No un "pensador" y un "constructor", sino una "persona que construye mientras piensa". Un malentendido común aquí es que la esencia está en estar en el sitio o físicamente cerca del cliente. No lo es. Se trata de estar cerca de la resolución de problemas.
Sin embargo, este cambio es un arma de doble filo. Recientemente escuché esta historia en una gran empresa: Comenzó con una estrategia de negocio. El desarrollo del sistema comenzó. A mitad de camino, construir se convirtió en el único objetivo. La estrategia desapareció. Y quedó una enorme cantidad de sistemas no utilizados. Esta realidad existía mucho antes de la IA. Pero a medida que la IA reduce el costo de construir, esta tragedia ocurrirá más fácilmente y en mayor volumen. Cuanto más fácil sea construir, más pesado se vuelve el peso de "qué construir".
Por lo tanto, para el desarrollo por contrato que se sumerge en la resolución de problemas, la IA es un viento a favor, no en contra. Está lejos de estar "muerto". Sin embargo, en el momento en que te alejas de la resolución de problemas, ese viento a favor se convierte en una "máquina de producción en masa de cosas inútiles".
4. En última instancia, la fuente de valor son las "personas"
Cuando llegas hasta aquí, parece que la fuente de valor del desarrollo por contrato, la consultoría y el SaaS es la misma. No es el software en sí mismo. Son las personas.
El trabajo que cualquier empresa puede resolver será reemplazado. El trabajo que la IA puede resolver también será reemplazado. Pero "tiene que ser esta gente resolviéndolo" permanece. "Quiero trabajar con esta gente" también permanece.
Así que el objetivo no es entregar un producto, sino ser un socio para que el cliente alcance el valor. Haz que sientan valor en las personas, no en el objeto.
El ejemplo principal es la toma de decisiones. La IA puede generar cualquier cantidad de candidatos. Pero quien decide es un humano. Y solo mejoras en la toma de decisiones tomando decisiones.
Cómo formamos a las personas también está cambiando. En mi departamento, nos estamos moviendo hacia "pensar + construir", y por supuesto hay dificultades. Pero esto no es algo que se aprenda en la formación. Solo crece dentro del trabajo.
Mencionaré la contratación brevemente. Recientemente, más empresas están reduciendo la contratación de juniors debido a la IA. La lógica es: "Si la IA escribe código, no necesitamos juniors". Pero yo creo lo contrario. Los juniors nativos de IA, al carecer de ideas fijas, tienen el potencial de idear formas de usarla que nunca se nos ocurrirían. Incluso si la contratación se restringe a corto plazo, si no puedes crear un entorno donde la gente crezca, esa industria solo declinará. Eso no es culpa de la IA; es solo un fracaso en adaptarse a los cambios que la IA trajo.
La profesión de ingeniero no está desapareciendo. El trabajo del ingeniero que "solo construye" está desapareciendo.
Todo el desarrollo de software se está acercando al "valor"
"El desarrollo por contrato está muerto" es cierto. Sin embargo, no es que el desarrollo por contrato esté muriendo, sino que el desarrollo de software que es "solo construir" está muriendo. No es que la profesión de ingeniero esté desapareciendo, sino que el trabajo del ingeniero que "solo construye" está desapareciendo. Y ya ha comenzado. El desarrollo por contrato simplemente está en primera línea.
Si das un paso atrás y miras estos cambios, surge un panorama más amplio. Desarrollo por contrato sumergiéndose en el negocio. Firmas de consultoría con equipos de desarrollo. SaaS adentrándose en garantías de rendimiento. FDEs entrando en los sitios de los clientes. Las posiciones y formatos son todos diferentes, pero la dirección es la misma. Todo el desarrollo de software se está acercando al "valor" a su manera.
Además, esto no es una tendencia nueva. Los ingenieros saben desde hace mucho tiempo que "solo construir no es suficiente", y han intentado acercarse a los clientes, usuarios y valor. El ejemplo representativo es el desarrollo Agile. Han pasado 25 años desde que nació Agile. Ese ideal de acercar "pensar" y "construir" está siendo acelerado de golpe por la IA en estos pocos años. Así es como lo veo.
Por lo tanto, ya no deberíamos obsesionarnos con la "forma" del desarrollo de software. ¿Desarrollo por contrato o empresa de producto? ¿Integrador de sistemas o consultor? En lugar de gastar energía ahí, la pregunta que hay que hacerse es: "¿Qué tan profundo puedes sumergirte en el valor?"
El 24/7, tendré una discusión en vivo sobre el tema "El desarrollo por contrato está muerto" hasta el amanecer
El 24/7, hablaré en un evento organizado por Creationline titulado "El futuro del desarrollo por contrato en la era de la IA — Más allá de 'El desarrollo por contrato está muerto'".
https://creationline.connpass.com/event/398146/
Viernes 24 de julio de 2026, 19:00–20:30, a través de Zoom, entrada gratuita.
Tendré una discusión exhaustiva y honesta con @samuraiRed y @sasakendayo sobre el tema "El desarrollo por contrato está muerto".
Como somos tres personas que podríamos hablar de cosas que no deberíamos, les dije a los organizadores durante la reunión preparatoria: "Por favor, deténgannos si se sale de control". Seguramente habrá una sensación de presencia que solo se puede experimentar en tiempo real.
¿De qué tipo de cosas hablaremos?
La respuesta es... ¡Tranquilo! ¡No te apresures!
Los espero ese día.
El blog está aquí:
