Lo siento, pero aún tienes que pensar
Los generadores de código con IA están permitiendo portar rápidamente aplicaciones existentes entre lenguajes, pero los ingenieros informan que las reescrituras sin intervención suelen introducir errores sutiles, degradación del rendimiento y pérdida de compensaciones de diseño importantes. Muchos sostienen que todavía necesitas entender los sistemas, especificar requisitos y revisar el código con cuidado; de lo contrario, el “workslop” desplaza el esfuerzo de los autores a los revisores y pone en riesgo la fiabilidad y mantenibilidad a largo plazo. Otros ven esto como parte de una tendencia más amplia: presión de la dirección para usar IA en todas partes, crecientes cuellos de botella de verificación e incertidumbre sobre si el pensamiento humano cuidadoso seguirá valorándose en el trabajo cotidiano de software.
Puertos de IA y los límites de las reescrituras “sin intervención”
- Muchos esperaban que la portabilidad basada en LLM (p. ej., Ruby → Rust/Elixir) fuera un caso de uso ideal: pruebas + implementación existente + objetivo claro.
- En la práctica, los puertos mostraron deriva semántica, desajustes arquitectónicos, regresiones de rendimiento y supuestos rotos (p. ej., caché frente a CSRF, sistemas de tipos, concurrencia).
- Los comentaristas sostienen que esto confirma que todavía necesitas comprensión humana del dominio, de los compromisos y de los modismos del lenguaje de destino, no solo traducción ciega.
Pensar, compromisos y fiabilidad del sistema
- Varios destacan que el verdadero trabajo consiste en hacer compromisos: compatibilidad frente a velocidad, latencia frente a rendimiento, límites de memoria, modos de fallo aceptables.
- La IA puede ayudar a implementar decisiones, pero no puede (todavía) asumir la responsabilidad de esas decisiones; los prompts vagos llevan a elecciones arbitrarias.
- Algunos argumentan que los modelos de frontera ahora hacen preguntas aclaratorias y que las críticas basadas en un comportamiento anterior están desactualizadas; otros discrepan.
Calidad del código, “workslop” y carga de revisión
- La generación barata más la verificación costosa es un tema recurrente.
- Los revisores describen enormes cambios generados por LLM que son frágiles, superficiales o están mal arquitectados, desplazando el esfuerzo de pensar de los autores a los revisores.
- Se invoca la ley de Brandolini: es mucho más fácil producir bazofia que refutarla o repararla, especialmente bajo presión de la dirección para “usar IA para todo”.
Incentivos organizacionales y ética
- Algunos lugares de trabajo supuestamente estigmatizan la programación manual o el escepticismo hacia la IA, incluso cuando la salida de la IA es incorrecta.
- Hay preocupación de que las empresas puedan aceptar racionalmente software peor si reduce costos, apoyándose en la adhesión, el bloqueo o el lobby en lugar de la calidad.
Cómo usar bien la IA
- Patrones sugeridos:
- Usar la IA intensamente para boilerplate, puertos con pruebas sólidas y glue mundano.
- Mantener a los humanos al mando de la arquitectura, los requisitos no funcionales y el diseño de pruebas.
- Escribir manualmente o recorrer paso a paso los cambios sugeridos por la IA para mantener la comprensión.
- Hay interés en estudios empíricos de proyectos con mucha IA frente a proyectos con poca IA (estabilidad, bugs, rendimiento).
Futuro más amplio: pensar, UBI y cultura hacker
- Debate sobre si la IA + una posible UBI liberarán a más personas para pensar, o si el capital reprimirá eso.
- Algunos prevén que la “cultura hacker” y los inventores humanos quedarán obsoletos; otros insisten en que la IA está muy lejos de reemplazar el juicio profundo de ingeniería.