Ocho tareas de desarrollo: qué delegar en la IA y qué dejar en manos humanas

Durante mucho tiempo la rutina no cambió. Llegaba un requisito, se abría el editor, se buscaba en la documentación, se copiaban ejemplos y se escribía código. Aparecían errores, se buscaba más, luego venían los tests, luego la documentación, y muchas horas después la funcionalidad estaba lista.

La IA ha transformado ese ciclo. Describes un problema en lenguaje normal y un asistente te devuelve en segundos código, tests, documentación, consultas SQL, expresiones regulares, ideas de refactorización y pistas para depurar. Pero en el debate de «la IA sustituirá a los desarrolladores» suele perderse una distinción: generar código no es ingeniería.

La IA resuelve muy bien algunas partes del trabajo de software y otras de forma poco fiable. Una regla práctica es dejar que se encargue de la ejecución repetitiva mientras las personas siguen siendo responsables del criterio. Eso deja cinco tareas que vale la pena pasarle a la IA y tres que deberían seguir muy en manos humanas.

1. Código repetitivo

Probablemente sea lo más fácil de delegar. La lista habitual incluye endpoints CRUD, modelos de base de datos, componentes de UI y formularios, clientes de API, reglas de validación, archivos de configuración, serializadores, DTO y manejo básico de errores. Nada de esto es difícil. Solo es repetitivo.

Pensemos en una API de gestión de usuarios. Escrita a mano, implica montar una larga cadena de capas:

User Model
    ↓
Schema
    ↓
Repository
    ↓
Service
    ↓
Controller
    ↓
Validation
    ↓
Tests

Eso es teclear mucho. A un asistente de IA le basta una descripción sencilla, por ejemplo: un endpoint de registro en FastAPI con PostgreSQL que valide el email, haga hash de la contraseña, bloquee usuarios duplicados y devuelva el ID del nuevo usuario. Un primer borrador utilizable aparece casi al instante.

Hay una advertencia importante: el código generado nunca se acepta a ciegas. La autenticación, la autorización, la validación, las consultas SQL, el manejo de errores, las versiones de dependencias, la seguridad, el rendimiento y los casos límite necesitan la mirada de una persona. La IA aporta la primera implementación y el desarrollador es dueño de la definitiva.

Las cuentas de tiempo resultan atractivas. Una tarea que a mano lleva 45 minutos puede dar una primera versión en 2 minutos, seguida de unos 10 minutos de revisión y pruebas. La aceleración está bien, pero la ganancia mayor es cambiar menos de contexto. Nadie tiene que abandonar el problema real solo para teclear otras 30 líneas de andamiaje.

2. Tests unitarios

Los tests son el ejemplo perfecto de una ayuda que no quita responsabilidad. Veamos esta pequeña función:

def calculate_price(price, discount):
    return price - (price * discount / 100)

Un desarrollador tendría que pensar en descuentos normales, cero, 100 %, valores negativos, entradas no válidas, el comportamiento de los números de coma flotante y tipos inesperados. En lugar de escribir a mano la primera batería, se le pueden pedir a un asistente casos de pytest que cubran valores normales, límites, entradas no válidas y casos extremos. Podría devolver algo así:

def test_no_discount():
    assert calculate_price(100, 0) == 100


def test_full_discount():
    assert calculate_price(100, 100) == 0


def test_half_discount():
    assert calculate_price(200, 50) == 100

Luego viene la revisión, y ahí está el peligro. Los tests escritos por IA pueden engañar. Una batería puede alcanzar el 100 % de cobertura y aun así ser pésima, porque cobertura no es corrección. El asistente puede limitarse a repetir lo que hace el código actual y, si ese código está mal, los tests confirmarán alegremente el comportamiento erróneo.

Así que la pregunta es qué comportamiento debe garantizarse de verdad. Esa es la parte humana. La IA escribe el código de pruebas repetitivo y el desarrollador decide qué merece probarse.

3. Documentación

La documentación importa, y empezarla desde una página en blanco duele. Los equipos la aplazan prometiendo escribirla más adelante, y seis meses después nadie sabe explicar cómo funciona el sistema.

Con IA, el primer borrador cuesta mucho menos. Se le da el código fuente, las definiciones de la API, la configuración, notas de arquitectura, el README existente y las instrucciones de despliegue, y se le pide un README que cubra instalación, variables de entorno, desarrollo local, configuración de la base de datos, endpoints, pruebas y despliegue. Vuelve un documento estructurado que revisa una persona.

Resulta especialmente útil para:

• archivos README que explican cómo arrancar el proyecto
• documentación de API que describe endpoints y formatos de petición y respuesta
• comentarios en secciones de código enrevesadas
• changelogs que resumen las diferencias entre versiones
• documentos internos elaborados a partir de notas técnicas en bruto
• material de incorporación que ayuda a los recién llegados a entender un proyecto

4. Regex, SQL y otras tareas de «lo sé, pero olvidé la sintaxis»

Son pequeñas interrupciones que la IA elimina. El objetivo está claro y solo la sintaxis es difusa. Puede ser una regex, una consulta SQL complicada, un comando de shell, un conjuro de Git o un método de JavaScript. En vez de bucear en diez páginas de documentación, se describe lo que hace falta, por ejemplo: encontrar usuarios con al menos tres compras en los últimos 30 días y devolver su gasto total.

El asistente escribe la consulta y una persona la revisa. La IA pone la sintaxis y el humano comprueba la lógica.

Supongamos un esquema con estas tablas:

users
orders
payments

Supongamos que se piden los 10 clientes con más pagos en los últimos 30 días. La primera versión de la consulta llega rápido, pero la persona sigue revisando joins, filas duplicadas, el comportamiento de NULL, índices, límites de fechas, zonas horarias, agregación y rendimiento. Una consulta correcta con 1.000 filas puede arrastrarse con 100 millones, y el asistente no conoce el entorno de producción. El SQL generado es un borrador, nunca algo listo para producción de forma automática.

5. Depuración

La depuración es quizá donde la IA ahorra más tiempo. Lo caro rara vez son los bugs profundos. A menudo el culpable es una tontería: una variable de entorno sin definir, una versión de paquete que no coincide, un nombre mal escrito, una condición de carrera, ajustes que difieren entre entornos, un null perdido o una respuesta de la API con una forma inesperada. Lo doloroso es dar con la causa, y la IA ayuda bien en esa búsqueda.

Pegar solo un error pelado como este da resultados pobres:

TypeError: undefined is not a function

El contexto lo cambia todo. Indica el framework y la versión, di qué componente lanza el error y cuándo (por ejemplo, al enviar un formulario), incluye el código del componente, la traza de la pila y el comportamiento esperado, y pide las causas más probables junto con el arreglo seguro más pequeño.

Un flujo típico es este:

Error
   ↓
Collect Context
   ↓
Ask AI for Possible Causes
   ↓
Rank the Causes
   ↓
Test the Hypothesis
   ↓
Apply Fix
   ↓
Run Tests
   ↓
Verify

La IA no sustituye el proceso de depuración. Acelera la investigación, que es una imagen mucho más realista del desarrollo asistido por IA.

Las tres tareas que deben seguir siendo humanas

Si la IA puede escribir código, tests, SQL y documentación, ¿por qué no dejarle todo? Porque la ingeniería es más que generar código. Algunas decisiones exigen contexto, criterio, responsabilidad, comprensión del negocio, experiencia y comunicación, y en esas áreas las personas deben seguir muy implicadas.

6. Arquitectura del sistema

Una IA puede proponer una arquitectura, pero la última palabra no debería ser suya. Pide un diseño escalable para una plataforma de comercio electrónico y la respuesta probablemente se parecerá a esto:

Frontend
   ↓
API Gateway
   ↓
Microservices
   ↓
Message Queue
   ↓
Databases
   ↓
Cache
   ↓
Monitoring

Impresiona. Pero imagina una empresa con tres desarrolladores, 10.000 usuarios, un presupuesto ajustado, un solo producto y un tráfico modesto. ¿Necesita 15 microservicios? Seguramente no. Un monolito modular podría ser muchísimo más sencillo.

La arquitectura consiste en compromisos. Los microservicios aportan despliegue independiente, aislamiento, autonomía de los equipos y escalado independiente, pero cuestan complejidad operativa, trabajo de red, esfuerzo de observabilidad y fallos distribuidos. Un monolito es simple, fácil de desplegar, agradable para el desarrollo local y más fácil de depurar, pero escalar partes concretas cuesta más, el código crece y, si está mal diseñado, se cuela el acoplamiento.

Una IA puede explicar todo eso. Lo que no sabe por sí sola es qué compromiso le conviene a esta empresa en concreto. Eso es criterio de ingeniería.

7. Decisiones de producto

La IA puede analizar opciones, pero no debería ser dueña del roadmap. Digamos que una startup puede construir una de dos funcionalidades. La primera lleva dos meses y podría aumentar los ingresos. La segunda lleva tres días y mejora la retención. ¿Cuál gana?

Un asistente puede ayudar a sopesar el esfuerzo de desarrollo, el impacto posible, las tendencias del mercado y las opiniones de los clientes. La decisión, sin embargo, depende del negocio. Quizá el objetivo inmediato sea conseguir financiación. Quizá la retención sea el mayor problema. Quizá un cliente importante pidió la primera funcionalidad o la competencia acaba de lanzarla. La IA no tiene ese contexto a menos que se lo den.

La pregunta débil es «¿qué deberíamos construir?». La fuerte es «teniendo en cuenta nuestros objetivos, clientes, limitaciones y recursos, ¿qué deberíamos construir a continuación?». La segunda pregunta necesita contexto, y por eso el pensamiento de producto sigue siendo tan valioso.

8. Resolución creativa de problemas

Es el área que más conviene mantener en manos humanas. Los patrones ayudan con problemas conocidos, pero algunos problemas de ingeniería son realmente nuevos: la arquitectura existente no funciona, los requisitos se contradicen, el rendimiento es extrañamente malo, el producto tiene restricciones poco habituales o la solución obvia provoca otro problema. Ahí es donde importa la creatividad.

La IA es útil para hacer lluvia de ideas, siempre que no sustituya al pensamiento. Una buena secuencia es pedirle cinco enfoques poco convencionales, luego los puntos débiles de cada uno, luego la suposición que se está haciendo y, por último, qué pasaría si la solución obvia quedara descartada. En ese papel, la IA es un compañero de reflexión y no quien toma la decisión.

De autor a revisor

Puede que este sea el mayor cambio que trae la IA. Antes los desarrolladores pasaban buena parte de su tiempo escribiendo código. Ahora el código se genera mucho más rápido, lo que cambia el equilibrio de habilidades y hace que revisar sea más importante. Las preguntas que hay que hacerse son:

• ¿Es correcto? ¿Resuelve el problema real?
• ¿Es seguro? ¿Hay algo de lo que un atacante pueda abusar?
• ¿Es mantenible? ¿Lo entendería un compañero dentro de medio año?
• ¿Es eficiente? ¿Aguantará datos reales de producción?
• ¿Está probado? ¿Qué pasa en los extremos?
• ¿Es compatible? ¿Encaja con el resto del sistema?
• ¿Es necesario? ¿Se está añadiendo complejidad que nadie necesita?

Probablemente el futuro no sea de quien genere más código. Será de quienes sepan juzgar bien el código.

Los malos desarrolladores también van más rápido

La IA puede aumentar la productividad, y también la velocidad a la que alguien produce mal software. Sin entender de seguridad, arquitectura, bases de datos, redes, pruebas y rendimiento, un desarrollador puede obtener muy rápido mucho código plausible pero defectuoso. Eso es peligroso.

Imagina a alguien que no entiende SQL pidiéndole a la IA consultas a la base de datos. El resultado funciona, hasta que llega a producción:

100 users
   ↓
Works perfectly

100,000 users
   ↓
Slow

10,000,000 users
   ↓
Production incident

La IA no creó la carencia de conocimientos. Solo hizo que el resultado llegara antes.

Un conjunto de habilidades distinto

Los desarrolladores de hoy necesitan un abanico de capacidades algo más amplio. Programar ya no lo es todo:

Programming

Una imagen mejor sería esta:

Programming
     +
System Design
     +
AI Collaboration
     +
Code Review
     +
Testing
     +
Security
     +
Product Thinking

La IA es una herramienta más en la caja de herramientas de la ingeniería.

Un día realista

Un flujo de trabajo normal con IA podría ser así:

1. Entender primero la tarea. Leer uno mismo el requisito y no pasárselo enseguida a la IA, porque antes que nada el problema tiene que tener sentido.
2. Pedir alternativas. Describir el problema y solicitar tres enfoques con sus compromisos. A menudo así salen opciones que nadie había considerado.
3. Elegir. Este paso sigue siendo humano. Los factores son la complejidad, la experiencia del equipo, el rendimiento, el coste, la mantenibilidad y la seguridad.
4. Generar el código repetitivo. Ahora los modelos, interfaces, manejadores de API, tests, documentación y componentes básicos pueden salir del asistente, y aquí aparece el ahorro de tiempo.
5. Revisar. Leer el código generado entero, no solo las primeras líneas.
6. Probar. Ejecutar tests unitarios, de integración, comprobaciones manuales y casos límite. Si algo falla, devolverle el error a la IA.

La IA se queda con el tecleo y las personas conservan el pensamiento.