Gestión de ingeniería después de que el coste del código se desplomó
A medida que los modelos de lenguaje grandes hacen drásticamente más barato y rápido generar código, muchos ingenieros sostienen que los verdaderos cuellos de botella del desarrollo de software ahora son el diseño del sistema, la estructura organizativa y la comprensión de bases de código complejas, no teclear implementaciones. Los comentaristas debaten si el código escrito por IA es mantenible o simplemente acelera la deuda técnica, y algunos informan de grandes mejoras en productividad y calidad cuando los humanos se centran en la arquitectura y la revisión, mientras que otros ven una caída en la fiabilidad y la claridad. Bajo todo esto hay una pregunta más amplia sobre cómo deberían evolucionar la gestión de ingeniería, la composición de los equipos y las métricas cuando el trabajo de “plomería” es casi gratis, pero el contexto, la coordinación y la responsabilidad a largo plazo siguen siendo costosos.
Impacto de los LLM en los costos de codificación y los cuellos de botella
- Muchos coinciden en que el acto mecánico de escribir código ahora es más barato y rápido.
- Varios sostienen que escribir código rara vez era el verdadero cuello de botella; la coordinación, los requisitos y la comprensión de sistemas complejos siguen dominando los plazos.
- Otros responden que la implementación sí era en realidad un gran lastre, y que los LLM eliminan grandes cantidades de “trabajo pesado”, permitiendo más pensamiento arquitectónico e iteración.
Calidad del código, mantenibilidad y deuda técnica
- Hay una fuerte división: algunos informan que los LLM ahora generan código de calidad de producción, bien probado, en muchos lenguajes; otros dicen que los resultados siempre se reescriben y no son mantenibles.
- Preocupación de que los LLM aceleren la acumulación de “slop” sin revisar y de bases de código enormes, profundizando la deuda técnica.
- Debate sobre si el código escrito por LLM puede mantenerse de forma segura por futuros LLM o si se convertirá en cajas negras opacas e ininteligibles.
- Temores de que los prototipos se conviertan en diseños de facto, con poco trabajo de diseño inicial y abstracciones pobres ya asentadas.
Mejores usos de los LLM en el desarrollo
- Amplio apoyo a los LLM como revisores de código, ayudas para refactorización, comprobadores de seguridad y para pequeños scripts o migraciones.
- Desacuerdo sobre la planificación: algunos abogan por el desarrollo guiado por especificaciones, con los LLM haciendo planes y código; otros encuentran vagos y poco fiables los planes generados por LLM.
- Informes mixtos sobre la capacidad de los LLM para evaluar la arquitectura o predecir el costo del cambio; los intentos se describen como específicos del proyecto y no comparables entre repositorios.
Implicaciones organizativas y de gestión
- Muchos señalan que los problemas reales son la estructura del equipo, la priorización y la toma de decisiones, no la velocidad al teclear.
- Algunos temen que la dirección use la IA para justificar tratar la ingeniería puramente como un centro de costos, ignorando el mantenimiento y la calidad a largo plazo.
- Otros argumentan que los fundamentos de una buena gestión (impacto, contexto, propiedad) no cambian; el uso de tokens y las LOC siguen siendo malas métricas.
- Debate sobre si la propia gestión es más automatizable que la ingeniería, frente a la necesidad de que los humanos asuman las consecuencias y den forma a las abstracciones y los incentivos.
Escritura, documentación y “AI slop”
- Quejas de que la IA ha derrumbado el costo del texto largo, inundando la web de contenido verboso y genérico.
- Varios lectores encontraron que el artículo enlazado tenía un estilo “AI-ish”, debatieron su autenticidad y criticaron los encabezados contundentes y la prosa inflada.
- Algunos piden una escritura más corta y densa, y mejores herramientas o formación para evitar la verbosidad al estilo de la IA.