Recientemente, veo a menudo la frase "El desarrollo por contrato ha muerto" en mi cronología. 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 'X ha muerto'?"
Después de todo, la gente ha estado diciendo "El desarrollo por contrato ha muerto" durante décadas, incluso antes de la IA. Desarrollo interno, la nube, subcontratación multinivel, deslocalización—cada vez, la gente decía "esta vez realmente va a morir", pero el desarrollo por contrato sobrevive como un zombie.
De hecho, pasé mucho tiempo trabajando para empresas de producto, así que solía ver estos temas desde la barrera. Recuerdo pensar que el desarrollo por contrato parecía difícil y que 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, incluyendo 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 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 de gestión y he enfrentado el desarrollo por contrato de frente. Por eso, esta vez quiero enfrentar la frase "El desarrollo por contrato ha muerto" sin huir.
¿Es cierto que "El desarrollo por contrato ha muerto"?
Es cierto.
Incluso antes de la IA, había 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. Incluso los no ingenieros ahora pueden crear software.
Cuando surge este tema, los ingenieros que viven de ello tienden a hacer un 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 esta es exactamente el área que es fácilmente reemplazada por los 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 el conocimiento humano sobre la utilización de la IA se acumula. Hace solo dos o tres años, la opinión predominante era "la IA puede ayudar, pero es demasiado pronto para dejar que escriba código", y ahora la IA escribe código más a menudo de lo que no. Mirando esta velocidad de cambio, incluso en áreas donde actualmente es difícil delegar completamente, una situación en la que "la IA es más confiable que los humanos" podría ocurrir fácilmente 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 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 así.
1. No se puede agrupar todo el "desarrollo por contrato"
Incluso si dices "desarrollo por contrato" de una vez, el contenido varía desde empresas que solo venden meses-hombre hasta SIers, consultores, socios de producto, PMOs y soporte de DX. Entonces, la pregunta a 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 toda a la vez; progresa en etapas. La primera ola afecta 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. Gradualmente se extenderá 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 se te dice". 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 pequeños y medianos desarrolladores por contrato y los pequeños desarrollos internos están sintiendo toda la fuerza de las olas de internalización y de IA generativa, y los proyectos están comenzando a desaparecer. Por otro lado, a menudo escucho que los sistemas complejos para grandes empresas todavía 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 difumina 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 volvió barato = el desarrollo por contrato ha muerto" es bastante miope. El medio se volvió más barato, pero la sustancia esperada no ha desaparecido en absoluto.
Esto coincide con mi propia experiencia trabajando tanto en empresas de producto 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, solo construyendo 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 construyendo cada vez más equipos de desarrollo, y los SIers están comenzando a ofrecer soporte empresarial. "SaaS ha 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. La consultoría, los SIers, SaaS y las 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" estaban inevitablemente 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" están comenzando naturalmente a converger. Los roles, los títulos de trabajo, las organizaciones y las 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 desarrollo normal a menudo se convierte en "queremos consultar sobre cómo proceder con el negocio", expandiéndose a PMO, diseño de modelo 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.
Últimamente he estado escuchando mucho el término FDE (Forward Deployment Engineer), y probablemente sea parte de la misma tendencia. Entrar en el sitio del cliente, pensar juntos sobre 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 es 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 una espada de doble filo. Hace poco escuché esta historia en una gran empresa: Comenzó con una estrategia de negocio. Comenzó el desarrollo del sistema. A mitad de camino, construir se convirtió en el único objetivo. La estrategia desapareció. Y quedó una gran cantidad de sistemas sin usar. 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 se vuelve construir, más pesado es 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 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 estas personas resolviéndolo" permanece. "Quiero trabajar con estas personas" también permanece.
Entonces, 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, estamos cambiando hacia "pensar + construir", y por supuesto, hay dificultades. Pero esto no es algo que se aprenda en la capacitació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, porque carecen 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 las personas crezcan, 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 ha 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 la primera línea.
Si te alejas y observas estos cambios, surge una imagen más grande. Desarrollo por contrato sumergiéndose en el negocio. Firmas de consultoría con equipos de desarrollo. SaaS entrando en garantías de rendimiento. FDEs entrando en sitios de clientes. Las posiciones y los 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 han sabido durante 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.
Entonces, ya no deberíamos obsesionarnos con la "forma" del desarrollo de software. ¿Desarrollo por contrato o empresa de producto? ¿SIer o consultor? En lugar de gastar energía ahí, la pregunta a hacer es: "¿Qué tan profundo puedes sumergirte en el valor?"
El 7/24, tendré una discusión en vivo sobre el tema "El desarrollo por contrato ha muerto" hasta la mañana
El 7/24, 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 ha muerto'".
https://creationline.connpass.com/event/398146/
Viernes, 24 de julio de 2026, 19:00–20:30, realizado vía Zoom, entrada gratuita.
Tendré una discusión exhaustiva y honesta con @samuraiRed y @sasakendayo sobre el tema "El desarrollo por contrato ha 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énganme si se descontrola". 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!
Te espero el día del evento.
El blog está aquí:
