LLM en el desarrollo: los 4 enfoques que usan los equipos y en qué se diferencian

Los LLM han dejado de ser un simple autocompletado inteligente y se han convertido en una herramienta de desarrollo en toda regla. Pero bajo la frase «programar con IA» se esconden prácticas muy distintas, desde sugerencias puntuales hasta la delegación casi total del código al modelo.

Los dos ejes principales

Para no meter todos estos escenarios en una misma categoría, conviene fijarse en dos parámetros. El primero es cuánto se implica la persona en el código: si lo escribe a mano, lo lee, lo corrige y lo revisa, o si sobre todo encarga la tarea al modelo y recibe fragmentos o módulos completos. El segundo es cómo comprueba el equipo el resultado: por intuición y pulsando botones a mano, o mediante mecanismos formales como pruebas, tipos y especificaciones.

En el cruce de ambos ejes surge una matriz sencilla de 2×2. Es útil porque elimina el falso debate sobre si usar IA en el desarrollo es «correcto» o «incorrecto». En la práctica, la cuestión no es ideológica, sino de modo de trabajo. La misma herramienta puede ser un acelerador seguro en un proceso y una fuente de caos en otro, si el equipo no tiene claro quién responde por el código y qué confirma que es correcto.

Cuatro modos de trabajo

De este esquema salen cuatro enfoques prácticos, y cada uno parece normal a su manera para un equipo. No difieren solo en el grado de confianza en el modelo, sino también en la disciplina de ingeniería que se necesita tras la generación. En unos casos el LLM sigue siendo un ayudante cómodo junto al desarrollador; en otros se convierte en un ejecutor casi autónomo. Por eso las discusiones sobre la utilidad de la IA suelen errar el tiro: se comparan procesos que no son equivalentes.

• Código manual + verificación informal. El desarrollador escribe lo principal y el LLM ayuda con el autocompletado, la refactorización y piezas pequeñas. La verificación es una ejecución rápida y una inspección visual.
• Código manual + verificación formal. La IA sigue siendo asistente, pero cada cambio pasa por pruebas, tipado, linters y revisión de código. Es el modo más predecible para un equipo de producto.
• Código delegado + verificación informal. Se encargan al modelo funciones, páginas o servicios enteros, y una persona comprueba si «parece que funciona». La velocidad es alta, pero el riesgo de defectos ocultos lo es aún más.
• Código delegado + verificación formal. La opción más ambiciosa: el LLM genera grandes partes del sistema y la calidad descansa en un buen conjunto de pruebas, contratos y restricciones estrictas del entorno.

La diferencia principal entre estos modos no es el volumen de texto generado, sino el coste del error y la rapidez con que se detecta. Mientras el modelo ayuda en puntos locales, la persona suele notar las rarezas al leer el código. Pero cuando se le entregan grandes bloques de responsabilidad, sin validación formal el proyecto empieza pronto a acumular errores, lógica duplicada y dependencias poco evidentes. Cuanto mayor es la autonomía del modelo, más caro resulta el control superficial.

Por qué importa la elección

Muchos equipos confunden la rapidez del primer resultado con la rapidez del desarrollo en conjunto. La verificación informal da, en efecto, sensación de avance: la pantalla se abre, el botón responde, luego todo está listo. Pero este enfoque detecta mal las regresiones, los casos límite y los errores de arquitectura. Se nota sobre todo cuando el LLM escribe con aplomo código en un estilo ajeno al equipo o añade soluciones que parecen verosímiles pero contradicen las reglas internas del proyecto.

De ahí la conclusión práctica: cuanto más se avanza hacia la delegación, más sólida debe ser la capa de verificación automática. Sin ella, la IA no reduce el trabajo, sino que lo desplaza en el tiempo: los problemas afloran más tarde, cuando el código ya está integrado en el producto. Si las pruebas, los tipos y las especificaciones están bien configurados, el modelo puede usarse con mucha más audacia: no solo para sugerencias, sino para implementaciones preliminares de tareas completas.

Qué significa esto

No existe una forma universal de «programar con LLM». A los equipos les conviene más no debatir sobre la magia de la IA y elegir con honestidad su modo: dónde la persona debe leer y corregir el código y dónde se puede delegar, y qué se considera verificación suficiente y qué no. Esa combinación, y no el volumen de las promesas, decide si el LLM será un acelerador del desarrollo o una fábrica de errores costosos.