Sigue siendo trabajo humano: las tareas que necesitan criterio e intuición cuando la IA escribe el código

La promesa de la generación de código con IA es que ya no hay que escribirlo. Describe la funcionalidad, acepta el diff y publícala. Para gran parte del trabajo, eso ya es básicamente cierto: el scaffolding, los endpoints CRUD, los esqueletos de pruebas, el código de integración, los scripts puntuales y el aburrido 90% de una funcionalidad conocida pueden generarse más rápido de lo que tardas en abrir los archivos correctos.

Así que esta es la pregunta más interesante, y el tema de este artículo: cuando la máquina escribe la mayor parte del código, ¿qué le queda por hacer a la persona?

La respuesta corta es criterio e intuición; y resulta que eso constituye la mayor parte del trabajo real. A medida que generar código se vuelve barato, la habilidad escasa no es producirlo: es decidir qué construir, detectar cuándo un resultado que “parece correcto” está mal de forma sutil y hacerse responsable de lo que ocurre cuando llega a producción. Un ingeniero, Isacco Sordo, llamó a esto el cuello de botella del criterio: el trabajo no desapareció, el cuello de botella simplemente se trasladó.

TL;DR

• La IA es realmente buena produciendo código; no lo es tanto para decidir, detectar y asumir la responsabilidad. Eso sigue siendo humano.
• Dos habilidades humanas distintas sostienen el trabajo: el criterio (decisiones deliberadas y justificables sobre qué es lo correcto) y la intuición (la sospecha rápida, cultivada con la experiencia, de que algo no encaja, aunque parezca estar bien).
• Las tareas que siguen siendo humanas se agrupan en unas cuantas áreas: decidir qué construir, convertir intenciones ambiguas y reglas tácitas en especificaciones, arquitectura y compromisos, buen juicio estético e integridad conceptual, detectar resultados incorrectos pero convincentes, razonamiento crítico para la seguridad y la integridad de las personas, depuración difícil y problemas novedosos, refactorizaciones grandes y transversales, y responsabilidad.
• Una regla útil para decidir cuánta intervención humana mantener: ajústala al radio de impacto × ambigüedad. El trabajo de bajo riesgo y bien especificado puede ejecutarse casi de forma autónoma; el trabajo ambiguo o con un gran radio de impacto necesita a una persona en los puntos críticos.
• Esto es una buena noticia para ingenieros y PMs: el trabajo que queda es la parte interesante.

Qué aprenderás aquí

• La diferencia entre criterio e intuición, y por qué la IA actual carece de ambos
• Un mapa de dónde intervienen ahora las personas en el ciclo de desarrollo de código con agentes
• Un catálogo concreto de las tareas que aún requieren a una persona y por qué la IA tiene dificultades con cada una
• Un mapa de decisiones para distinguir qué delegar a la IA y qué asumir tú
• Un ejemplo real de código “incorrecto pero convincente” y cómo lo detecta una persona
• Una lista de verificación para saber cuándo mantener a una persona involucrada y una distribución sencilla de responsabilidades entre PM e ingeniería

Criterio vs. intuición: dos superpoderes humanos diferentes

La gente usa estas palabras con cierta ligereza, pero cumplen funciones distintas, y la IA falla en ellas por razones diferentes.

El criterio es deliberado. Es la capacidad de tomar una decisión justificable en condiciones de incertidumbre, sopesando compromisos, consecuencias y contexto que no está documentado en ninguna parte. “¿Deberíamos construir esto siquiera?”. “¿Es Postgres o una cola la base adecuada aquí?”. “¿Es aceptable asumir este riesgo al publicar un viernes por la tarde?”. El criterio es lento, explícito y conlleva responsabilidad.

La intuición es rápida. Es el reconocimiento de patrones que desarrollas tras años de ver fallar sistemas: esa sensación silenciosa de “esto parece correcto, y justamente por eso no confío”. Es buen juicio estético: la sensación de que una abstracción está mal, un nombre es engañoso o una función hace demasiado, antes de poder explicar completamente por qué.

Por qué la IA actual carece de ambos:

Ruchit Suthar lo expresa con claridad al hablar de la intuición: la IA “no tiene buen juicio estético, solo patrones” y “afirma cosas incorrectas exactamente con el mismo tono seguro que usa para las correctas”. Ese tono seguro es la trampa, y la sospecha entrenada de una persona es lo que permite detectarla.

Dónde intervienen ahora las personas en el ciclo

El ciclo anterior pasaba por tu teclado. El nuevo gira a su alrededor, y los puntos de control humanos se desplazan a los extremos y a la parte intermedia de mayor riesgo.

HUMAN   decide what to build; set intent, constraints, acceptance criteria
  |
  v
AI      generate the boring 90%: scaffolding, CRUD, glue code
  |
  v
GATES   lint · types · tests · security scanners · CI            (automated)
  |
  v
AI      second-pass review (a different model catches many real bugs)
  |
  v
HUMAN   review by RISK: taste · intent gaps · security · load-bearing paths
  |
  v
HUMAN   accept & OWN it — you answer for production

Observa lo que la persona ya no hace (escribir el código aburrido) y lo que sigue siendo esencialmente humano: los extremos (la intención y la responsabilidad) y la parte intermedia crítica (la revisión ajustada al riesgo). Como señala Addy Osmani, puedes y deberías ejecutar un segundo modelo para revisar al primero —detecta muchos errores reales—, pero aun así no te dirá si este era el cambio correcto que había que construir.

Las tareas que aún necesitan a una persona

Aquí tienes la guía práctica. Para cada tarea: qué es, por qué la IA tiene dificultades y qué aporta realmente una persona.

1. Decidir qué construir (y qué no)

Esta es la tarea humana con mayor impacto y para la que la IA está menos preparada. Un modelo construirá con gusto algo equivocado y lo hará de maravilla. No tiene una opinión sobre si la funcionalidad vale la pena, si una versión más sencilla permitiría probar la hipótesis o si sería mejor no construir nada y eliminar un requisito.

• Por qué la IA tiene dificultades: optimiza para completar la tarea que le diste, no para cuestionarla. No tiene contexto del producto, ni roadmap, ni nada en juego.
• Aporte humano: definir el problema, priorizar y tener la disciplina de decir “esto no”.

2. Convertir intenciones ambiguas y reglas tácitas en una especificación

La mayoría de los requisitos reales viven en la cabeza de las personas, en hilos de Slack y en una década de reglas de negocio “obvias” que nadie documentó. La IA es fuerte cuando la especificación es precisa y débil cuando tiene que inferir la intención.

• Por qué la IA tiene dificultades: revisa el código que existe; rara vez señala el comportamiento que nadie especificó. Addy Osmani llama a esto “el problema incómodo… un vacío con forma humana que no espero que se cierre pronto”.
• Aporte humano: hacer preguntas a las partes interesadas, sacar a la luz las reglas tácitas y escribir los criterios de aceptación con los que se evaluará al modelo.

3. Arquitectura y compromisos de gran impacto

Los agentes de IA no pueden ver tu arquitectura. No conocen tu volumen de datos, tus requisitos de consistencia, la capacidad operativa de tu equipo ni tus restricciones regulatorias, así que producen recomendaciones que suenan plausibles pero carecen de contexto.

• Por qué la IA tiene dificultades: la arquitectura es una optimización global que considera restricciones externas al repositorio. Los modelos tienden a ser plausibles a nivel local e incoherentes a nivel global.
• Aporte humano: elegir abstracciones y límites entre servicios, y evaluar los compromisos (costo vs. latencia vs. simplicidad vs. tiempo) que el análisis de Deloitte sobre el futuro de la ingeniería identifica como el núcleo del rol moderno.

4. Buen juicio estético e integridad conceptual

Distinguir lo bueno de lo que simplemente funciona. Saber si una ingeniosa línea de código le causará problemas a la siguiente persona que la mantenga. Saber si el sistema sigue formando un todo coherente después del 40.º pull request generado.

• Por qué la IA tiene dificultades: tiene patrones, no buen juicio estético; y a lo largo de una sesión extensa con múltiples archivos pierde de vista decisiones anteriores (por límites de contexto y sesgo de recencia), por lo que se desvía de sus propias convenciones.
• Aporte humano: mantener la coherencia conceptual del sistema y darle el pulido humano que la IA tiende a uniformar: buenos mensajes de error, estados vacíos considerados y valores predeterminados razonables.

5. Detectar resultados “incorrectos pero convincentes”

Este es el terreno de la intuición: código generado por IA que parece correcto, pasa la prueba del caso ideal y está mal de una forma sutil y costosa. Un análisis de 2026 sobre agentes que trabajaban bajo restricciones reales de ingeniería encontró una configuración que alcanzó una tasa de éxito de 78.6% en las aserciones, pero solo 8.3% en pass@1: una corrección parcial que parece impresionante y aun así es demasiado frágil para llevarla a producción.

• Por qué la IA tiene dificultades: afirma cosas incorrectas con el mismo tono que usa para las correctas, y la corrección parcial es su forma natural de fallar.
• Aporte humano: la sospecha entrenada para desconfiar de resultados que parecen impecables y la experiencia para saber dónde buscar. (Veremos un ejemplo concreto más adelante).

6. Razonamiento crítico para la seguridad y la integridad de las personas

Autenticación, autorización, criptografía, manejo de entradas y cualquier ámbito donde equivocarse pueda causar una vulneración. El código de IA en estas áreas tiene más probabilidades de contener vulnerabilidades sutiles que el código puramente algorítmico.

• Por qué la IA tiene dificultades: la seguridad trata en gran medida de lo que no debería ocurrir: una ausencia que el modelo no ve. Reproduce patrones inseguros de los datos de entrenamiento y omite verificaciones que nadie pidió explícitamente.
• Aporte humano: modelado de amenazas, revisión deliberada de las áreas sensibles para la seguridad y elevar, no reducir, el nivel de exigencia de la revisión del código generado.

7. Depuración difícil y problemas verdaderamente novedosos

Depurar un sistema distribuido complejo o resolver un problema que no aparece en la distribución de entrenamiento todavía requiere un razonamiento que las herramientas no pueden realizar de forma confiable.

• Por qué la IA tiene dificultades: estas tareas exigen mantener en mente un sistema grande que solo se comprende parcialmente y razonar sobre comportamientos emergentes y no locales.
• Aporte humano: formular y poner a prueba hipótesis que cruzan los límites del sistema; el verdadero trabajo de ingeniería para cuando no hay una respuesta en Stack Overflow.

8. Refactorizaciones grandes y transversales

Cuando un cambio afecta muchos archivos, módulos o sistemas, los agentes empiezan a perder la cuenta de qué interfaces cambiaron y qué invocadores e invariantes se rompieron.

• Por qué la IA tiene dificultades: las ventanas de contexto y el sesgo de recencia hacen que las decisiones anteriores se “desvanezcan” durante sesiones largas, por lo que las refactorizaciones grandes acumulan inconsistencias sutiles.
• Aporte humano: establecer la secuencia de la refactorización, preservar las invariantes y ser la memoria consistente de la que carece el modelo.

9. Responsabilidad y compromiso con el resultado

Alguien tiene que responder por el código en producción, en la revisión de un incidente y en la auditoría de seguridad. Eso no se puede delegar a un modelo.

• Por qué la IA tiene dificultades: la responsabilidad no escala como los prompts. Como lo expresó InfoWorld, un desarrollador puede revisar un cambio de IA, quizá veinte; pero una flota de agentes que publica cientos de pull requests plantea la pregunta: ¿quién entiende realmente lo que está pasando?
• Aporte humano: hacerse cargo. Quien hace merge asume la responsabilidad: depurar el código después, ampliarlo y explicarlo.

Un mapa de decisiones: qué delegar y de qué hacerte cargo

No necesitas a una persona en cada línea. Necesitas la atención humana adecuada en los cambios adecuados. El factor más útil, tomado del planteamiento de Addy Osmani, es el radio de impacto: ¿qué pasa si esto falla? Combínalo con la ambigüedad: ¿qué tan claramente está especificado el trabajo?

                     LOW AMBIGUITY                  HIGH AMBIGUITY
                     (clear spec + tests)           (fuzzy intent, tacit rules)

HIGH BLAST RADIUS    REVIEW HARD                    HUMAN-LED
(auth, money,        AI drafts, but a human owns    Decide and spec first.
 data, infra)        the load-bearing review.       AI assists; human owns
                     e.g. payment refactor          design, review, and result.
                                                    e.g. a new authorization model

LOW BLAST RADIUS     AUTOPILOT                      CLARIFY FIRST
(internal tools,     Let AI run; skim the diff.     Cheap to get wrong, but pin
 tests, prototypes)  Spend judgment elsewhere.      down intent so you do not
                     e.g. CRUD, scaffolding         build the wrong thing fast.

La regla práctica: la intervención humana que mantengas debe aumentar con el radio de impacto, no con la culpa. ¿Un proyecto individual sin usuarios? Dejar que la IA revise casi todo es una postura defendible en 2026. ¿Mantienes algo de lo que dependen muchas personas? Deja que la máquina se encargue de la primera pasada y del aburrido 90%, pero mantén a una persona real involucrada en cualquier cosa que pueda perjudicar a alguien.

Un ejemplo de código: el diff “incorrecto pero convincente”

La teoría es fácil; el peligro es concreto. Aquí tienes un ejemplo realista de código generado que parece correcto, pasa una prueba básica y es peligrosamente defectuoso de forma sutil.

El prompt: “Agrega un endpoint para obtener una factura por id.”

Resultado de la IA (TypeScript / Express):

// GET /invoices/:id
router.get("/invoices/:id", requireAuth, async (req, res) => {
  const invoice = await db.invoice.findUnique({
    where: { id: req.params.id },
  });

  if (!invoice) {
    return res.status(404).json({ error: "Not found" });
  }

  return res.json(invoice);
});

Es limpio. Verifica la autenticación. Maneja el 404. La prueba del caso ideal pasa: inicias sesión, solicitas tu propia factura y obtienes un 200. ¿Lo publicamos?

No. Este es un IDOR (referencia directa insegura a objetos) de manual. requireAuth demuestra quién eres, no qué tienes permitido ver. Cualquier usuario que haya iniciado sesión puede leer cualquier factura —incluidas las de otros tenants— adivinando o enumerando ids. El modelo produjo código plausible a nivel local y omitió silenciosamente la regla que nadie había documentado: una factura pertenece a una cuenta y solo puedes leer las tuyas.

La intuición que se activa aquí no dice “encontré un bug”. Dice: “un endpoint que autoriza el acceso sin hacer referencia al usuario actual es sospechoso”. Luego el criterio llena el vacío con la regla de negocio tácita:

// GET /invoices/:id
router.get("/invoices/:id", requireAuth, async (req, res) => {
  const invoice = await db.invoice.findUnique({
    where: { id: req.params.id },
  });

  // Authn proves who you are; authz proves you may see THIS row.
  if (!invoice || invoice.accountId !== req.user.accountId) {
    return res.status(404).json({ error: "Not found" });
  }

  return res.json(invoice);
});

Hay dos cosas que observar. Primero, la corrección incorpora una regla de negocio que el prompt nunca mencionó: precisamente el vacío del “comportamiento que nadie especificó”. Segundo, devolver 404 (no 403) para la factura de otra persona es en sí una decisión de criterio: no confirmar que el registro existe a alguien que no debería saberlo. Un modelo no tomará esa decisión por ti, porque no es una cuestión de corrección del código. Es una cuestión humana.

Todo el artículo cabe en un diff: la IA lo generó, las pruebas automatizadas pasaron y el valor surgió de la sospecha de una persona sumada a su conocimiento de una regla no escrita.

Lista de verificación para mantener a una persona involucrada

Usa la IA sin reservas, pero exige un punto de control humano cuando se cumpla cualquiera de estas condiciones:

• El cambio afecta autenticación o autorización, dinero, PII, migraciones o infraestructura compartida
• “Qué es lo correcto construir” no es obvio o hay desacuerdo al respecto
• El comportamiento correcto depende de reglas de negocio que no están en el repositorio
• El cambio es una refactorización grande y transversal (muchos archivos / invariantes)
• El resultado parece correcto, pero es difícil de verificar (concurrencia, cálculos monetarios, casos límite)
• Una falla sería costosa o irreversible en producción
• No te sentirías cómodo explicando este código en la revisión de un incidente

Todo lo demás —scaffolding, herramientas internas, CRUD bien probado, prototipos— es un excelente terreno para dejar trabajar a la máquina y dedicar tu criterio a otra cosa.

Cómo se reparten el criterio los PMs y los ingenieros

Como gran parte del trabajo restante depende del criterio, ahora es una tarea compartida. Una distribución clara:

El patrón saludable no es “el PM le da un prompt a la IA y hace merge del pull request”. Es que los PMs y los ingenieros dediquen el tiempo que liberó la IA a las decisiones que esta no puede tomar.

Las habilidades en las que vale la pena profundizar

Si producir código es barato, invierte en lo que escasea:

• Acumula práctica que desarrolle la intuición. En especial, los perfiles júnior todavía necesitan rastrear bugs, leer código fuente y construir a mano módulos difíciles: así se desarrolla la capacidad de percibir que “algo aquí huele mal”. Si omites esa práctica, puedes terminar produciendo código más rápido de lo que puedes entenderlo.
• Cuestiona, no te limites a generar. Trata al modelo como un compañero de práctica: “¿Por qué es correcto? ¿Cuáles son los posibles modos de falla? ¿Qué podría romper esto?”. Los mejores ingenieros revisan a fondo los resultados de la IA, como lo harían con los de un compañero que se incorporó la semana pasada.
• Escribe la especificación y las pruebas. Las pruebas diseñadas por personas delimitan el espacio de búsqueda del modelo; si este no logra pasarlas limpiamente, esa es la señal de que debes intervenir.
• Practica hacerte cargo del resultado. El factor diferenciador ya no es quién puede producir código, sino quién puede decidir, detectar problemas y responder por ellos.

Conclusión

La IA no eliminó la ingeniería del software. Eliminó la escritura del código, que antes ocultaba el hecho de que el criterio y el buen juicio estético siempre fueron el trabajo real.

Las tareas que siguen siendo humanas no son las sobras. Son las partes más interesantes del trabajo: decidir qué vale la pena construir, detectar cuándo algo está mal de forma sutil y responder por lo que llega a producción. Cuando el código se vuelve barato, esas tareas se vuelven más valiosas, no menos.

La máquina puede escribir el código. Decidir si es el código correcto —y hacerse responsable de lo que sucede después— sigue siendo, sin lugar a dudas, trabajo humano.

Fuentes

• Revisión de código con agentes - Addy Osmani (radio de impacto, el aumento de 441.5% en la duración mediana de la revisión, “el comportamiento que nadie especificó”)
• El cuello de botella del criterio: ingeniería de software en la era de la IA - Isacco Sordo, June 2026 (cuello de botella del criterio; “oráculo en lugar de colaborador”; síntesis de Deloitte)
• ¿La IA acaba con el oficio? Buen juicio estético y criterio en el código generado - Ruchit Suthar (“sin buen juicio estético, solo patrones”, reconocimiento de errores sutiles, integridad conceptual)
• Los agentes de código con IA necesitan buenos ingenieros de software - InfoWorld (la responsabilidad no escala; tareas acotadas vs. arquitectura y reglas de negocio)
• Por qué fallan los agentes de código con IA cuando el software se enfrenta a la realidad - Antoine Buteau (las restricciones degradan la calidad; 78.6% de aserciones vs. 8.3% en pass@1; fallas en la capa de datos)
• Agentes de código con IA en 2026: para qué son realmente buenos - Tanuj Garg (contexto arquitectónico, sutilezas de seguridad, desviaciones en grandes refactorizaciones, lógica de negocio tácita)
• Asistentes de código con IA en 2026: dónde ayudan y dónde perjudican - The Curated Weekly (abstracciones, depuración de sistemas distribuidos, descubrimiento de necesidades de las partes interesadas)
• Agentes de código con IA en ingeniería: dónde generan un impacto real - Tamer Fahmy (la infraestructura, los sistemas distribuidos y la arquitectura de seguridad siguen requiriendo mucha intervención humana)
• El futuro de la ingeniería de software - Deloitte (los ingenieros supervisan agentes, evalúan compromisos y abordan problemas novedosos)