Análisis / Desarrollo y agentes
Cómo pasar un prototipo con IA a producción sin rehacerlo todo
El prototipo ya funciona y convence en pantalla. Antes de publicarlo, necesitas saber qué partes son fiables, cuáles solo sirven para la demo y cuánto trabajo requiere mantenerlas.
Qué demuestra realmente un prototipo
Un prototipo responde si una idea puede funcionar y permite descubrir requisitos. Todavía no demuestra que el sistema soporte usuarios reales, recupere datos después de un fallo o pueda actualizarse sin romperse.
Las herramientas generativas acortan la primera exploración. Ese ahorro es valioso si se utiliza para probar antes las decisiones importantes; se pierde cuando el resultado inicial se trata como una aplicación terminada.
Empieza por escribir qué parte de la demo debe sobrevivir. Puede ser el recorrido, una interacción o el resultado de una tarea. Lo demás puede cambiar durante la construcción. Si el prototipo utiliza Astra, consulta también qué revisar antes de incorporarlo a un proyecto.
El hueco entre lo que se nota y lo que se mide
Hay un dato que explica buena parte del entusiasmo. METR publicó el 10 de julio de 2025 un ensayo aleatorizado con 16 desarrolladores con experiencia sobre 246 tareas reales de sus propios repositorios. Antes de empezar, estimaban que la IA les haría un 24 % más rápidos. Con las herramientas encima, tardaron un 19 % más. Y al terminar, después de haber tardado más, seguían calculando que habían ido un 20 % más rápidos.
Entre lo que se sintió y lo que se midió hay casi cuarenta puntos. Ese hueco es el motivo por el que un equipo puede estar convencido de que va lanzado mientras el calendario dice otra cosa, y por el que una demo convence tanto a quien la enseña como a quien la ve.
Lo que se acumula cuando nadie vuelve
GitClear analizó 623 millones de cambios de código entre 2023 y 2026 y publicó los resultados en enero de 2026. La duplicación de bloques subió un 81 % desde 2023 y está en el nivel más alto que tienen registrado. El código movido, que es la señal de que alguien vuelve atrás y reordena, cayó del 21 % en 2022 al 3,8 % en lo que va de 2026, mientras el copiar y pegar subía al 15,7 %. Las llamadas a funciones de otros ficheros bajaron un 35 %.
Dicho en corto: se escribe mucho más y se reorganiza mucho menos. Cada trozo nuevo se pega al lado del anterior en lugar de sustituirlo.
El informe OSSRA de Black Duck, publicado el 25 de febrero de 2026 sobre 947 bases de código comerciales de 17 sectores, enseña dónde acaba ese camino: el 93 % contiene componentes sin actividad de desarrollo en los dos últimos años. La media de vulnerabilidades abiertas por base de código subió un 107 %, hasta 581. Y el 68 % tiene conflictos de licencia, frente al 56 % del año anterior. Elegir con qué se construye pesa más cada año, y de eso va cómo elegir un stack pensando en su mantenimiento.
Dónde aparece la factura
CodeRabbit revisó 470 pull requests públicas de GitHub y publicó el resultado el 17 de diciembre de 2025: 320 con participación de IA y 150 escritas solo por personas. Las primeras llegaron con 10,83 incidencias por pull request frente a 6,45 de las segundas. En vulnerabilidades de seguridad la diferencia sube hasta 2,74 veces. El propio informe avisa de que la autoría se deduce por indicios, no está confirmada una por una.
La factura tampoco la paga siempre quien generó. Daniel Stenberg, que mantiene curl, contó el 14 de julio de 2025 que alrededor del 20 % de los informes de seguridad que recibía ese año era ruido generado con IA, y que solo un 5 % del total resultaba válido. El trabajo de descartar lo que no vale se lo estaba comiendo el proyecto, hasta el punto de replantearse el programa de recompensas que llevaba desde 2019.
Es el mismo patrón que vimos con los modelos 3D: algo que se ve bien en el visor y no sirve en producción no ahorra trabajo, lo mueve de sitio.
Cómo saber si lo que tienes aguanta
| Criterio | Qué comprobar |
|---|---|
| Dueño | Quién lo mantiene dentro de seis meses, con nombre y horas |
| Origen | Qué partes se generaron, con qué herramienta y en qué fecha |
| Dependencias | Cuántas son y cuándo se actualizó cada una por última vez |
| Licencias | Si lo que entra permite de verdad lo que vas a hacer con ello |
| Pruebas | Qué falla al cambiar una línea y quién se entera de que falla |
| Datos | Dónde quedan y quién puede leerlos si el prototipo se publica |
| Rehacer | Qué costaría hacerlo bien desde cero frente a mantener esto |
La última fila evita dos extremos: conservar una base frágil por inercia o rehacer sin medir. Compara ambas rutas por tiempo, riesgo y mantenimiento antes de decidir.
Qué pedir antes de llevarlo a producción
Tres cosas por escrito, antes de tocar nada. Qué tiene que hacer el proyecto cuando esté hecho, con una frase por cada cosa que alguien va a comprobar. Qué partes están generadas y cuáles se han revisado a mano. Y quién responde cuando falle, con nombre y con tiempo asignado. Escribir eso antes de empezar es justo lo que mide el desarrollo guiado por especificación.
Con esas tres respuestas, una demo generada es un buen punto de partida y se puede presupuestar. Sin ellas, lo que hay es una pieza que funciona el día que se enseña, y el coste real aparece más tarde, repartido entre quien la mantenga.
Si tienes un prototipo generado y quieres saber qué costaría llevarlo a producción, cuéntanos qué hace y qué lo sostiene.
Fuentes
Comprobado el 20 de septiembre de 2026