La IA cambia la economía de las reescrituras de software
Las herramientas de IA están cambiando la forma en que los equipos piensan sobre reescribir software heredado, y algunos ingenieros informan migraciones más rápidas y construcciones a medida más baratas cuando los modelos pueden seguir de manera fiable las pruebas y la documentación. Otros responden que las refactorizaciones a gran escala siguen fallando por las mismas razones de siempre: mala cobertura de pruebas, arquitecturas desordenadas y cultura organizacional, y sostienen que los LLM a menudo pasan por alto casos límite, olvidan restricciones o producen código de “parche sobre parche” que es difícil de mantener. El intercambio también refleja un escepticismo más amplio hacia las afirmaciones infladas, al estilo LinkedIn, de que la IA ha “resuelto” la programación, y enfatiza que el juicio de ingeniería cuidadoso, las especificaciones claras y las buenas pruebas siguen siendo esenciales.
La IA y la economía de las reescrituras
- Muchos sostienen que la IA sí hace que las reescrituras sean más baratas y rápidas, especialmente para bases de código pequeñas y medianas, y que hace que el “costo hundido” sea una barrera menor.
- Otros dicen que esto ignora en gran medida el costo de los bugs, el mantenimiento y la disfunción organizacional; intercambiar símbolos más rápido no arregla problemas más profundos.
- Algunos ven la IA como una forma de reducir el costo de los “ports exactos en funcionalidades” (por ejemplo, para escapar de frameworks o plataformas obsoletos) sin cambiar la semántica.
Pruebas, fidelidad y mantenibilidad
- Hay un consenso fuerte: la utilidad de las reescrituras con IA depende mucho de la cobertura de pruebas y de los harnesses.
- Los partidarios afirman que la IA puede preservar mejor que los humanos los casos límite heredados y puede ayudar a generar harnesses de prueba.
- Los escépticos informan que los LLM pasan por alto casos extremos, “lijan los bordes”, olvidan restricciones y necesitan corrección constante.
- Incluso con IA, verificar la paridad de comportamiento a menudo requiere una correspondencia línea por línea y pruebas manuales o automatizadas extensas.
Cuándo tienen sentido las reescrituras (o no)
- Algunos enfatizan la cautela al estilo de Joel Spolsky: las reescrituras a menudo fallan, especialmente cuando cambias características y tecnología al mismo tiempo.
- Otros responden que la deuda técnica extrema y las pilas obsoletas pueden paralizar a las organizaciones; a veces una reescritura más simplificación es necesaria.
- Una visión predominante: si vas a reescribir, primero apunta a un reemplazo idéntico en comportamiento y luego simplifica y evoluciona.
Elección de stack, comprar vs construir y factores organizacionales
- Los stacks populares y estables ayudan tanto a la IA como a la contratación; una deprecación fuerte puede confundir a los modelos.
- Una buena documentación interna puede hacer que los frameworks a medida sean viables para la IA.
- La IA reduce el costo de construir soluciones a medida, pero tanto “comprar” como “construir” siguen incluyendo mantenimiento a largo plazo.
- Muchos señalan que la cultura organizacional, los incentivos y las restricciones regulatorias a menudo dominan la economía técnica.
Límites percibidos y patrones de uso de los LLM
- Los LLM se comparan con desarrolladores junior: buenos para tareas localizadas cuando se les guía; malos como arquitectos autónomos o refactorizadores a gran escala.
- Los informes incluyen fallos en DSL inusuales, clasificación errónea del comportamiento del sistema y razonamiento irregular.
- Algunos ven potencial en transpilers asistidos por IA y en usar IA para diseñar arquitectura y pruebas, pero solo con supervisión humana.
Meta: calidad del artículo y discurso sobre IA
- Varios comentarios critican el texto enlazado como “broetry” al estilo LinkedIn y probablemente escrito por un LLM, con poca sustancia empírica.
- Se expresa una frustración más amplia por la repetitiva, polarizada y de baja señal de los comentarios sobre IA.