Educación y Evaluación de Desarrolladores en la Era de los Agentes

Educación y Evaluación de Desarrolladores en la Era de los Agentes

Este análisis refleja el panorama de la educación y certificación al 26 de julio de 2026.

Introducción

Los agentes de codificación autónomos están transformando el desarrollo de software de una tarea centrada en escribir código a una centrada en especificar el trabajo, delegar tareas, supervisar la ejecución y revisar los resultados.

Los agentes de codificación modernos pueden inspeccionar un repositorio, desarrollar un plan de implementación, modificar múltiples archivos, ejecutar pruebas, responder a errores y abrir una solicitud de extracción (pull request) para revisión humana. La documentación actual de GitHub describe flujos de trabajo en los que los desarrolladores asignan incidencias a los agentes, supervisan su trabajo, solicitan revisión de código, proporcionan retroalimentación y aprueban o rechazan el resultado. (docs.github.com)

Esto plantea una pregunta difícil para la educación:

Si un estudiante puede pedirle a un agente que produzca un programa funcional, ¿qué se le debe exigir al estudiante que entienda?

La respuesta no es abandonar los fundamentos de la programación. Es cambiar para qué se utilizan esos fundamentos.

Los estudiantes aún necesitan comprender estructuras de datos, algoritmos, lenguajes de programación, diseño de sistemas, seguridad, pruebas y depuración. Sin embargo, cada vez más necesitan aplicar ese conocimiento para:

• Descomponer problemas ambiguos en tareas manejables
• Escribir especificaciones precisas y criterios de aceptación
• Proporcionar contexto útil a los agentes de codificación
• Juzgar si el código generado es correcto y mantenible
• Diseñar pruebas que expongan fallos ocultos
• Revisar riesgos de seguridad, privacidad, rendimiento y arquitectura
• Coordinar varios agentes o herramientas sin perder el control
• Explicar y defender decisiones técnicas

La próxima generación de educación para desarrolladores, por lo tanto, evaluará menos la capacidad del estudiante para producir grandes cantidades de código y más su capacidad para entender, dirigir, verificar y mejorar sistemas de software.

El Cambio Central: De la Producción de Código al Juicio de Ingeniería

Los agentes de codificación no son simplemente un autocompletado más rápido

Los asistentes de codificación tradicionales sugieren una línea, función o un pequeño bloque de código. Los agentes de codificación autónomos operan a una escala mayor. Pueden trabajar a través de archivos, invocar herramientas de desarrollo, ejecutar pruebas, inspeccionar documentación y continuar a través de múltiples pasos.

Esto cambia la unidad de trabajo. El flujo de trabajo del desarrollador se parece cada vez más a esto:

1. Comprender el problema del usuario o del negocio.
2. Definir el comportamiento deseado.
3. Dividir el trabajo en tareas más pequeñas.
4. Asignar una tarea apropiada a un agente.
5. Inspeccionar el plan del agente.
6. Permitir que el agente implemente dentro de un entorno controlado.
7. Ejecutar pruebas y verificaciones de seguridad.
8. Revisar el resultado.
9. Solicitar cambios o revisar el diseño.
10. Aprobar, fusionar y monitorear el software.

La persona que omite las etapas de planificación y revisión aún puede producir código, pero no puede producir de manera fiable un producto digno de confianza.

Los límites de la salida de código en bruto

La producción de código en bruto se está convirtiendo en una medida más débil de habilidad porque un agente puede generar rápidamente una gran cantidad de código plausible. Al mismo tiempo, los agentes siguen teniendo dificultades con la evolución del software a largo plazo, los cambios en múltiples archivos, los requisitos poco claros y el mantenimiento del comportamiento a través de modificaciones repetidas. Un estudio comparativo de 2025 encontró una brecha sustancial entre el rendimiento del agente en la resolución aislada de problemas y tareas de evolución de software más complejas y a largo plazo. (arxiv.org)

Esto crea una importante distinción educativa:

• Un estudiante que puede generar código puede no entenderlo.
• Un estudiante que puede explicar, probar, cuestionar y reparar código demuestra una competencia más profunda.

El objetivo educativo, por lo tanto, debería ser el juicio de software validado, no simplemente la generación exitosa de código.

Cómo se Están Adaptando los Currículos

Los currículos universitarios se mueven hacia la comprensión y verificación

El informe de los currículos de Ciencias de la Computación 2023 de la ACM, el Instituto de Ingenieros Eléctricos y Electrónicos Computer Society, y la Asociación para el Avance de la Inteligencia Artificial anticipó que la inteligencia artificial generativa cambiaría la educación en programación. Su guía sugiere que los estudiantes necesitarán un mayor énfasis en la lectura, comprensión, verificación, edición, modificación, adaptación y prueba de código. También identifica la descomposición de problemas como un área que probablemente se volverá más importante. (csed.acm.org)

La misma guía hace un punto crucial: incluso cuando un agente escribe el programa, el ser humano sigue siendo responsable de determinar si el programa es correcto. Esto significa que la educación en programación no puede reducirse a escribir instrucciones. Los estudiantes necesitan suficiente comprensión técnica para evaluar la salida.

El informe también anticipa cambios en la educación en ingeniería de software, incluyendo un mayor uso de la inteligencia artificial para la generación de código, depuración, análisis estático y revisión de código. El uso efectivo de estas herramientas requiere habilidades de diseño y comprensión de código más sólidas, no más débiles. (csed.acm.org)

La acreditación comienza a recompensar resultados de ingeniería más amplios

Los criterios actuales de acreditación informática de la Junta de Acreditación de Ingeniería y Tecnología ya enfatizan:

• Análisis de problemas informáticos complejos
• Diseño y evaluación de soluciones informáticas
• Comunicación profesional
• Responsabilidad legal y ética
• Seguridad y privacidad
• Impactos sociales de la informática
• Un proyecto integral o componente experiencial (abet.org)

Estos resultados son muy adecuados para un entorno de desarrollo basado en agentes porque miden el juicio y la responsabilidad en lugar de las pulsaciones de teclas.

Al 26 de julio de 2026, los cambios propuestos por la Junta de Acreditación de Ingeniería y Tecnología para el ciclo 2026-2027 incluyen criterios adicionales para programas de inteligencia artificial y un requisito de que los graduados sean capaces de aplicar teorías, modelos y técnicas de inteligencia artificial a problemas complejos. Los cambios propuestos aún estaban pendientes de adopción final y se esperaba que entraran en vigor después de la reunión de otoño de 2026, con su primera aplicación durante el ciclo de revisión 2027-2028. (abet.org)

La dirección probable es clara: los programas deberán demostrar que los estudiantes pueden construir y evaluar sistemas, no simplemente completar ejercicios de programación aislados.

Nuevos cursos enseñan el uso de agentes como una disciplina de ingeniería

Varios cursos universitarios recientes ilustran el patrón emergente.

El curso de la Universidad de Maryland de 2025 sobre el uso efectivo de asistentes y agentes de codificación de inteligencia artificial cubrió herramientas que pueden invocar sistemas de construcción, ejecutar pruebas y corregir errores. También abordó la mantenibilidad, arquitectura, diseño de interfaces de programación de aplicaciones, eficiencia, escalabilidad, seguridad, integración continua, revisión de código, agentes asíncronos y revisión de código automatizada. (cs.umd.edu)

La Universidad de Pensilvania ha propuesto un curso de ciencias de la computación de nivel de segundo año centrado en el desarrollo de software impulsado por inteligencia artificial. Sus temas propuestos incluyen la delegación de tareas de codificación, diseño modular, pruebas escalables, gestión de riesgos, reproducibilidad, colaboración y ética. (seas.upenn.edu)

El curso de otoño de 2026 de la Universidad de Michigan, Ingeniería de Software Agéntico Aplicada, es aún más explícito. Se organiza en tres fases:

1. Uso efectivo de agentes de codificación
2. Construcción de un agente usando una interfaz de programación de aplicaciones de modelo de lenguaje grande
3. Diseño, evaluación y despliegue de un orquestador de agentes

El curso utiliza proyectos, laboratorios, demostraciones y verificaciones en lugar de exámenes tradicionales. Afirma que la calificación recompensará la comprensión sobre el resultado y pide a los estudiantes que expliquen por qué un agente falló y cómo arreglar el sistema circundante. (eecs498-aase.github.io)

Este es un cambio de diseño significativo. El curso no está enseñando a los estudiantes a producir código más rápido. Les está enseñando a convertirse en supervisores técnicos de sistemas que producen código.

Cómo Están Cambiando los Bootcamps

Los bootcamps se están adaptando más rápidamente que muchos programas tradicionales porque sus currículos están estrechamente ligados a los requisitos de empleo. Sin embargo, la calidad de la adaptación varía.

El modelo de bootcamp dedicado a la inteligencia artificial

El bootcamp actual de Desarrollo de Software con Inteligencia Artificial de Le Wagon combina el desarrollo full-stack con la integración de inteligencia artificial. Su currículo publicado incluye codificación asistida por inteligencia artificial, integración de modelos de lenguaje grandes, despliegue en producción, generación aumentada por recuperación y agentes de inteligencia artificial autónomos. (lewagon.com)

Este modelo trata la inteligencia artificial como un hilo conductor que atraviesa el programa en lugar de una única lección opcional. Se espera que los estudiantes aprendan ambos:

• Cómo funcionan los sistemas de software convencionales
• Cómo usar herramientas de inteligencia artificial para construir y operar esos sistemas

Esa combinación es importante. Un aprendiz que solo sabe cómo operar un agente podría no ser capaz de reconocer una arquitectura defectuosa. Un aprendiz que solo conoce la programación convencional podría no estar preparado para los flujos de trabajo de desarrollo modernos.

El modelo de “agregar una unidad de inteligencia artificial”

El bootcamp de ingeniería de software de Springboard mantiene una base convencional en desarrollo web, interfaces de programación de aplicaciones, desarrollo front-end, desarrollo back-end y proyectos full-stack, mientras agrega una unidad de inteligencia artificial centrada en ingeniería de prompts y colaboración con herramientas generativas. (springboard.com)

Este modelo es útil para los estudiantes que necesitan primero sólidos fundamentos de programación. También refleja una realidad práctica: muchos estudiantes no deberían empezar construyendo agentes autónomos. Primero deberían aprender cómo funciona el software, cómo usar el control de versiones, cómo leer mensajes de error y cómo probar un programa.

La debilidad es que un módulo corto de ingeniería de prompts puede ser demasiado superficial. Un currículo serio en la era de los agentes debería enseñar más que cómo pedir código. Debería enseñar:

• Cómo crear un archivo de contexto de repositorio
• Cómo escribir una especificación técnica
• Cómo definir los límites de las tareas
• Cómo restringir los permisos de un agente
• Cómo inspeccionar los planes del agente
• Cómo evaluar las pruebas generadas
• Cómo detectar problemas de seguridad
• Cómo comparar diseños alternativos
• Cómo documentar la participación del agente

Qué deberían buscar los estudiantes de bootcamps

Los futuros estudiantes deberían preguntar si un programa evalúa lo siguiente:

• ¿Pueden los estudiantes explicar el código que no escribieron personalmente?
• ¿Revisan y reparan los estudiantes la salida defectuosa del agente?
• ¿Se califican las pruebas, la seguridad y la mantenibilidad?
• ¿Hay una demostración en vivo o una defensa técnica?
• ¿Mantienen los estudiantes un historial de proyectos controlado por versiones?
• ¿Se enseña a los estudiantes cómo trabajar sin un agente cuando sea necesario?
• ¿Enseña el programa el descubrimiento de productos y el análisis de requisitos?
• ¿Se equilibran las habilidades específicas de la herramienta con principios de ingeniería duraderos?

Un programa que anuncia “construye una aplicación en una semana con inteligencia artificial” puede ser excelente para la creación rápida de prototipos, pero eso no es lo mismo que preparar a alguien para la ingeniería de software profesional.

Cómo se Están Adaptando las Certificaciones

Los proveedores de certificación están desarrollando tres tipos amplios de credenciales.

Certificaciones de conocimiento específicas de herramientas

La certificación GitHub Copilot de Microsoft evalúa el uso responsable, las características de Copilot, la arquitectura de datos, la creación de contexto y prompts, la productividad del desarrollador, la privacidad, las exclusiones de contenido y las salvaguardias. El examen es supervisado, dura cien minutos y puede contener componentes interactivos. (learn.microsoft.com)

Esta credencial reconoce conocimientos útiles para el lugar de trabajo. Puede demostrar que una persona comprende cómo usar una plataforma de desarrollo particular de manera responsable.

Su limitación es que está fuertemente ligada a un producto. Un profesional que sabe cómo operar GitHub Copilot aún puede carecer de la capacidad para descomponer un requisito de producto complejo, cuestionar una elección arquitectónica o revisar un cambio sensible a la seguridad.

Certificaciones de desarrollo de inteligencia artificial basadas en plataforma

La certificación AWS Certified Generative AI Developer – Professional es más amplia. Su guía de examen incluye integración de modelos fundacionales, gestión de datos, cumplimiento, implementación, soluciones de inteligencia artificial agénticas, seguridad, gobernanza, pruebas, resolución de problemas, monitoreo y optimización. (docs.aws.amazon.com)

Sin embargo, el examen es principalmente de opción múltiple y respuesta múltiple. Es una prueba de conocimiento sustancial, pero no demuestra completamente si un candidato puede construir, revisar o defender un sistema funcional. (aws.amazon.com)

Esto ilustra un problema más amplio: los exámenes de conocimiento son más fáciles de escalar que los exámenes de rendimiento. Las organizaciones de certificación pueden probar la terminología y los principios de diseño de manera eficiente, pero la competencia práctica requiere un entorno en el que los candidatos deban tomar decisiones y lidiar con el fracaso.

Credenciales basadas en laboratorio y en proyectos

Las credenciales de Microsoft Applied Skills ofrecen un modelo más prometedor. Requieren que los estudiantes completen tareas interactivas alineadas con el trabajo real en una evaluación basada en laboratorio. Microsoft posiciona estas credenciales como evidencia de que un candidato puede resolver desafíos reales de la nube y la inteligencia artificial en lugar de simplemente recordar información. (learn.microsoft.com)

El programa de Inteligencia Artificial Agéntica de educación ejecutiva de la Universidad Carnegie Mellon combina enseñanza en vivo, laboratorios guiados, tareas, flujos de trabajo multiagente, evaluación, barreras de seguridad, registro, observabilidad y un proyecto final. (execonline.cs.cmu.edu)

Estos programas no son idénticos a la certificación profesional independiente, pero muestran la dirección que probablemente tomarán las credenciales:

• Evaluaciones prácticas más cortas
• Entornos de desarrollo aislados (sandboxed)
• Repositorios realistas
• Tareas de evaluación y observabilidad
• Sistemas de proyecto final
• Explicaciones técnicas orales o grabadas
• Evidencia de uso responsable de herramientas

Técnicas de Evaluación que Miden la Comprensión

La mejor estrategia de evaluación no prohíbe los agentes en cada tarea. Utiliza agentes donde reflejan la práctica profesional y reserva algunas actividades para medir la comprensión independiente.

1. Documentos de especificación y descomposición

Antes de escribir código, se exige a los estudiantes que presenten:

• El problema del usuario
• Requisitos funcionales
• Requisitos no funcionales
• Suposiciones
• Restricciones
• Estructuras de datos
• Interfaces
• Criterios de aceptación
• Un desglose de tareas
• Riesgos conocidos

El documento debe explicar por qué el problema se ha dividido en tareas particulares.

Esto mide si el estudiante comprende el problema antes de pedirle a un agente que lo implemente.

2. Puntos de control de planificación del agente

Exija a los estudiantes que muestren el plan propuesto por el agente antes de que comience la implementación. El estudiante debe identificar:

• Qué partes del plan son aceptables
• Qué partes están incompletas
• Qué suposiciones son inseguras
• Qué tareas requieren aprobación humana
• Qué pruebas deben añadirse

La calificación final debe recompensar la calidad del juicio del estudiante, no la extensión del plan del agente.

3. Evaluaciones de revisión de código

Proporcione a los estudiantes un repositorio generado por un agente que contenga defectos deliberados. Los defectos pueden incluir:

• Manejo incorrecto de casos límite
• Autenticación insegura
• Manejo deficiente de errores
• Problemas de rendimiento ocultos
• Lógica duplicada
• Interfaces poco claras
• Pruebas inadecuadas
• Violaciones de privacidad
• Riesgos de dependencia

Pida a los estudiantes que produzcan una revisión con niveles de gravedad, evidencia, soluciones propuestas y pruebas de regresión.

Esto está más cerca del trabajo de software profesional que pedir a los estudiantes que creen otra pequeña aplicación desde cero.

4. Explicación y defensa oral

Un estudiante debe ser capaz de explicar:

• Qué hace el sistema
• Por qué se eligió esa arquitectura
• Qué partes fueron generadas
• Qué suposiciones hizo el agente
• Cómo las pruebas demuestran la corrección
• Qué podría fallar aún
• Qué compromisos se aceptaron

Una defensa oral corta puede realizarse individualmente o en grupos pequeños. No tiene por qué ser intimidante. De cinco a diez preguntas enfocadas suelen ser suficientes para revelar si un estudiante comprende la entrega.

5. Tareas de transferencia

Después de que un estudiante complete un proyecto asistido por un agente, proporcione un nuevo requisito que no pueda resolverse simplemente repitiendo la instrucción original.

Por ejemplo:

• Añadir una nueva fuente de datos
• Cambiar el objetivo de rendimiento
• Soportar un formato de entrada inesperado
• Eliminar una dependencia
• Añadir controles de acceso
• Explicar una prueba que falla
• Refactorizar un módulo sin cambiar su comportamiento

El estudiante puede usar un agente, pero debe explicar el plan, verificar los cambios y defender el resultado.

Las tareas de transferencia miden si el estudiante aprendió un método general en lugar de memorizar una interacción exitosa.

6. Diseño de pruebas y pruebas adversarias

Los estudiantes deben ser calificados por la calidad de sus pruebas, no solo por si el código generado pasa las pruebas proporcionadas.

Los requisitos útiles incluyen:

• Escribir pruebas de límites
• Crear pruebas negativas
• Probar entradas inválidas
• Probar la recuperación de fallos
• Verificar suposiciones de rendimiento
• Usar pruebas basadas en propiedades donde sea apropiado
• Probar el comportamiento sensible a la seguridad
• Explicar qué queda sin probar

La pregunta clave no es “¿El código pasó?” sino “¿Sabía el estudiante qué necesitaba ser probado?”

7. Historial de versiones y portafolios de procesos

Un portafolio de proyectos puede incluir:

• Especificación inicial
• Descomposición de tareas
• Planes del agente
• Prompts o instrucciones principales
• Commits
• Resultados de pruebas
• Comentarios de revisión
• Enfoques fallidos
• Cambios de diseño
• Reflexión final

Un portafolio de procesos no debe convertirse en un requisito para presentar cada línea de conversación privada. Un registro representativo suele ser más útil que una transcripción enorme.

El curso de programación de Princeton de 2025, por ejemplo, permitió el uso de herramientas de inteligencia artificial generativa, pero exigió a los estudiantes que describieran su uso en un archivo readme a través de un resumen representativo en lugar de una transcripción exhaustiva. (cs.princeton.edu)

8. Revisión estructurada por pares

La revisión por pares transforma a los estudiantes de ser solo productores de código a críticos de código. Investigaciones tempranas sugieren que la evaluación por pares basada en rúbricas puede aproximarse a la evaluación del instructor con una precisión moderada, mientras desarrolla el pensamiento evaluativo y el compromiso. (arxiv.org)

Se debe exigir a los estudiantes que justifiquen sus comentarios con evidencia. “Este código es malo” no es una revisión. “Esta función realiza una consulta a la base de datos dentro de un bucle, creando un probable problema de rendimiento cuando la colección crece” sí es una revisión.

9. Problemas de prompts y especificaciones

Los Problemas de Prompts son ejercicios de programación en los que los estudiantes escriben instrucciones en lenguaje natural que hacen que un sistema de inteligencia artificial genere código que satisface una especificación. El enfoque enseña explícitamente a los estudiantes a comunicar requisitos computacionales a los sistemas generadores de código. (arxiv.org)

Esto puede ser útil, pero no debe ser el único método de evaluación. Un estudio de 2026 que involucró a más de novecientos estudiantes encontró que los errores comunes incluían omitir detalles importantes de los prompts. Cuando el código generado fallaba, los estudiantes a menudo se centraban en aclarar su intención en lugar de rastrear el código o examinar los casos de prueba. (arxiv.org)

La creación de prompts puede, por lo tanto, revelar habilidades de descomposición y comunicación, pero debe combinarse con la lectura de código, pruebas, depuración y revisión.

Una estructura de evaluación de ejemplo

Un proyecto práctico podría usar la siguiente ponderación:

Esta estructura aún recompensa un producto funcional, pero evita que un estudiante reciba una calificación alta simplemente porque un agente produjo una gran base de código.

Integridad Académica en el Trabajo de Curso Asistido por Agentes

Las prohibiciones generales y el uso sin restricciones son ambos inadecuados

Una prohibición general puede ser apropiada para una evaluación fundacional específica, especialmente cuando el objetivo de aprendizaje es la práctica de programación independiente. Sin embargo, una prohibición universal es cada vez más difícil de aplicar y puede impedir que los estudiantes aprendan herramientas que encontrarán en el trabajo profesional.

El uso sin restricciones también es inadecuado. Si los estudiantes pueden presentar trabajos producidos por agentes sin explicación, la evaluación puede medir el acceso a una herramienta en lugar del aprendizaje.

El enfoque más sólido es la política explícita a nivel de tarea.

Tres modos de política útiles

Modo uno: Agente prohibido

Úsalo para:

• Exámenes
• Ejercicios de programación fundamental
• Demostraciones individuales de depuración
• Ejercicios de algoritmos fundamentales
• Evaluaciones diseñadas para medir la recuperación o implementación sin ayuda

El curso de Principios de Computación Imperativa de Carnegie Mellon prohíbe las herramientas de inteligencia artificial para cualquier parte del trabajo calificado, incluyendo la generación de soluciones, la explicación de soluciones, el formato de código y la generación de casos de prueba. (cs.cmu.edu)

Modo dos: Agente restringido

Úsalo cuando los estudiantes puedan pedir:

• Explicaciones de conceptos
• Ayuda con la documentación
• Interpretación de mensajes de error
• Clarificación de bibliotecas o interfaces de programación de aplicaciones
• Lluvia de ideas
• Crítica de un diseño creado por un estudiante
• Refactorización menor

Los cursos de sistemas de Carnegie Mellon permiten herramientas de inteligencia artificial para comprender interfaces de programación de aplicaciones, bibliotecas, frameworks, código proporcionado y mensajes de error, mientras prohíben las solicitudes de soluciones parciales o completas de tareas. (cs.cmu.edu)

Modo tres: Agente permitido con divulgación

Úsalo para proyectos de ingeniería de software realistas. Exija a los estudiantes que divulguen:

• Qué herramientas se usaron
• Qué tareas se delegaron
• Si el código generado fue copiado, modificado o reescrito
• Cómo se probó la salida
• Qué aprendió el estudiante
• Qué partes del diseño siguen siendo responsabilidad del estudiante

La guía de integridad académica de Princeton establece que el uso permitido de inteligencia artificial aún debe ser divulgado y que representar la salida generada como propia o no divulgar su uso puede constituir una violación de la integridad. (scholarlyintegrity.princeton.edu)

La Escuela de Posgrado de Educación de Harvard de manera similar permite usos como la clarificación, la lluvia de ideas y la exploración, mientras prohíbe a los estudiantes presentar trabajos generados por inteligencia artificial como propios. También requiere la documentación del uso permitido y advierte que los estudiantes siguen siendo responsables de la precisión, privacidad, derechos de autor y sesgos. (registrar.gse.harvard.edu)

Una declaración de divulgación práctica

Un curso puede proporcionar una plantilla simple:

Usé [nombre de la herramienta] para [planificación, depuración, generación de código, pruebas, documentación o revisión]. Delegué [tareas específicas]. Revisé y modifiqué la salida, probé el sistema resultante y sigo siendo responsable de la exactitud, seguridad y originalidad de la entrega.

No se debe exigir a los estudiantes que divulguen la corrección ortográfica ordinaria de la misma manera que la implementación delegada. Las políticas deben distinguir entre asistencia menor y una contribución cognitiva o técnica sustancial.

Privacidad e igualdad de acceso

Las instituciones deben proporcionar herramientas aprobadas o alternativas. No se debe exigir a los estudiantes que suban trabajos confidenciales, información personal, investigación no publicada o código propietario a sistemas públicos.

La guía de la UNESCO aboga por un enfoque centrado en el ser humano que aborde la privacidad, la seguridad, la equidad, la inclusión y la preparación institucional. (unesco.org)

Los cursos también deben considerar a los estudiantes que no pueden permitirse varias herramientas de pago. Un curso justo puede:

• Proporcionar una herramienta institucional compartida
• Ofrecer una alternativa local o de código abierto
• Diseñar tareas que no dependan de un solo proveedor
• Calificar el razonamiento en lugar del acceso al modelo más potente
• Permitir vías sin agente para cada resultado de aprendizaje esencial

Métodos Prácticos para Incorporar Agentes Productivamente

Usar un repositorio controlado

Dé a los estudiantes un repositorio que contenga:

• Un archivo readme claro
• Una base de código pequeña pero realista
• Pruebas automatizadas
• Un flujo de trabajo de integración continua
• Una lista de problemas conocidos
• Una guía de estilo
• Una lista de verificación de seguridad
• Un registro de cambios

Esto hace que el uso del agente sea observable y les da a los estudiantes algo más realista que un ejercicio de codificación en blanco.

Requerir un plan antes de la implementación

Los estudiantes no deben empezar pidiendo a un agente que “construya toda la aplicación”. Exija una secuencia:

1. Pida al agente que inspeccione el repositorio.
2. Pida un resumen de la arquitectura.
3. Pida riesgos e información faltante.
4. Escriba el propio plan de tareas del estudiante.
5. Apruebe una pequeña tarea de implementación.
6. Revise los cambios resultantes.
7. Ejecute pruebas antes de continuar.

Esto enseña la delegación controlada en lugar de la delegación ciega.

Usar un equipo de agentes con roles claros

Un patrón de orquestación simple puede incluir:

• Planificador: propone el desglose de tareas
• Implementador: modifica el código
• Probador: crea y ejecuta pruebas
• Revisor: busca defectos y riesgos
• Evaluador humano: aprueba o rechaza cambios

Los estudiantes deben aprender que agregar más agentes no mejora automáticamente la calidad. Más agentes pueden crear instrucciones contradictorias, esfuerzo duplicado, costos aumentados y responsabilidad poco clara.

El objetivo educativo no es construir el sistema multiagente más grande. Es elegir el flujo de trabajo más simple que produzca resultados confiables.

Incorporar puertas de aprobación humana

Exija aprobación explícita antes de que un agente pueda:

• Cambiar la autenticación
• Modificar esquemas de datos
• Añadir dependencias
• Acceder a sistemas de producción
• Cambiar la configuración de despliegue
• Eliminar archivos
• Fusionar una solicitud de extracción (pull request)

Esto enseña a los estudiantes que la autonomía debe estar limitada por permisos y revisión.

Calificar los fallos deliberadamente

Los agentes son más educativos cuando fallan de maneras informativas. Los instructores deben incluir:

• Requisitos ambiguos
• Restricciones conflictivas
• Pruebas incompletas
• Operaciones sensibles a la seguridad
• Documentación engañosa
• Pruebas intermitentes
• Límites de rendimiento
• Un cambio que parece correcto pero rompe otra característica

La tarea del estudiante es diagnosticar el fallo y mejorar el proceso.

Un Marco de Competencias para 2026 a 2031

El siguiente marco está diseñado para seguir siendo útil incluso a medida que cambian las herramientas específicas.

Dominio uno: Fundamentos técnicos y alfabetización de código

Un desarrollador competente puede:

• Leer código desconocido
• Explicar el flujo de control y el flujo de datos
• Comprender interfaces y dependencias
• Analizar la complejidad algorítmica
• Usar control de versiones
• Depurar sin depender enteramente de un agente

Evidencia: explicación de código, tarea de depuración manual, crítica de diseño y ejercicio de transferencia individual.

Dominio dos: Definición y descomposición de problemas

Un desarrollador competente puede:

• Clarificar objetivos del usuario
• Identificar restricciones y suposiciones
• Separar requisitos esenciales de los opcionales
• Dividir el trabajo en tareas que se puedan probar de forma independiente
• Definir criterios de aceptación
• Reconocer cuándo una tarea es demasiado amplia para una delegación fiable

Evidencia: especificación, gráfico de tareas, registro de riesgos y explicación de las decisiones de descomposición.

Dominio tres: Dirección de agentes e ingeniería de contexto

Un desarrollador competente puede:

• Proporcionar contexto relevante del repositorio
• Dar instrucciones precisas
• Definir límites y permisos
• Elegir cuándo usar un agente y cuándo no
• Comparar planes alternativos
• Recuperarse cuando el agente sigue una interpretación incorrecta

Evidencia: puntos de control de planificación, registros de interacción representativos y una tarea de revisión en vivo.

Dominio cuatro: Verificación y revisión

Un desarrollador competente puede:

• Inspeccionar el código generado
• Diseñar pruebas significativas
• Identificar suposiciones ocultas
• Revisar riesgos de seguridad y privacidad
• Evaluar la mantenibilidad
• Explicar lo que las pruebas no demuestran

Evidencia: revisión de código, pruebas adversarias, ejercicio de detección de defectos y defensa oral.

Dominio cinco: Orquestación y operaciones

Un desarrollador competente puede:

• Coordinar herramientas de planificación, implementación, pruebas y revisión
• Usar puntos de control y puertas de aprobación humana
• Rastrear costos, tiempo y comportamiento de la herramienta
• Mantener flujos de trabajo reproducibles
• Observar fallos y mejorar el sistema
• Decidir si múltiples agentes añaden valor

Evidencia: flujo de trabajo de orquestación funcional, registros, informe de evaluación y análisis de costos o rendimiento.

Dominio seis: Diseño de productos y sistemas

Un desarrollador competente puede:

• Seleccionar un nivel adecuado de automatización
• Diseñar sistemas modulares
• Equilibrar velocidad, calidad, costo y riesgo
• Conectar decisiones técnicas con resultados de usuario
• Reconocer cuándo una solución simple sin agente es mejor

Evidencia: resumen de producto, registro de decisiones de arquitectura, prototipo y demostración centrada en el usuario.

Dominio siete: Práctica profesional responsable

Un desarrollador competente puede:

• Divulgar la asistencia de inteligencia artificial
• Proteger información privada y propietaria
• Respetar las obligaciones de derechos de autor y licencias
• Identificar sesgos y riesgos de fiabilidad
• Comunicar la incertidumbre
• Aceptar la responsabilidad por el sistema final

Evidencia: declaración de divulgación, evaluación de riesgos, revisión de privacidad y presentación profesional.

Niveles de competencia sugeridos

Para 2031, una credencial profesional debería demostrar un progreso a través de estos niveles en lugar de simplemente confirmar familiaridad con una herramienta de software particular.

Recomendaciones para Diferentes Interesados

Universidades

• Añadir módulos de ingeniería de software conscientes de agentes a los cursos existentes.
• Preservar la programación fundamental y los algoritmos.
• Reemplazar algunas tareas de generación de código por tareas de revisión y transferencia.
• Exigir a los estudiantes que expliquen y defiendan trabajos importantes.
• Capacitar al profesorado en herramientas de agentes, diseño de evaluación, privacidad y políticas de integridad.
• Construir repositorios compartidos y entornos de pruebas (sandbox).

Bootcamps

• Enseñar el desarrollo convencional y el desarrollo asistido por agentes juntos.
• Hacer de las pruebas, la arquitectura y la seguridad partes centrales del currículo.
• Exigir proyectos de portafolio con registros de procesos.
• Añadir demostraciones técnicas en vivo.
• Enseñar el descubrimiento de productos y la redacción de requisitos.
• Evitar prometer que solo la ingeniería de prompts crea ingenieros listos para el trabajo.

Proveedores de certificación

• Aumentar el uso de evaluaciones basadas en laboratorio.
• Incluir revisión de código, pruebas, depuración y análisis de amenazas.
• Usar repositorios realistas en lugar de preguntas de opción múltiple aisladas.
• Evaluar el juicio independiente de la herramienta.
• Añadir explicaciones orales cortas o demostraciones grabadas.
• Actualizar el contenido con frecuencia sin hacer que la credencial dependa de la interfaz de un solo proveedor.

Instructores

• Declarar exactamente lo que está permitido para cada evaluación.
• Diseñar tareas en torno al resultado de aprendizaje previsto.
• Proporcionar a los estudiantes herramientas aprobadas o alternativas equivalentes.
• Evaluar el proceso, el razonamiento y la verificación.
• Usar registros como evidencia, no como la única prueba.
• Evitar depender del software de detección de inteligencia artificial como mecanismo principal de integridad.

Aprendices y creadores de productos

• Aprender suficiente programación convencional para leer y cuestionar el código generado.
• Empezar con un producto pequeño en lugar de una aplicación vaga y grande.
• Escribir la especificación antes de abrir un agente.
• Delegar un problema a la vez.
• Revisar cada cambio y probar cada suposición.
• Mantener un registro de decisiones importantes.
• Tratar al agente como un colaborador junior rápido, no como un experto incuestionable.

El Próximo Primer Paso

Para alguien que comienza un viaje de creación de productos, el primer paso más útil es:

Elige un problema de usuario pequeño y escribe una especificación de una página antes de pedirle a un agente que escriba código.

Incluye:

• Quién es el usuario
• Qué problema tienen
• Qué debe hacer la primera versión
• Qué no debe hacer
• Tres pruebas de aceptación
• Una preocupación importante de seguridad o privacidad
• Tres pequeñas tareas de implementación

Luego, pide al agente que revise la especificación e identifique requisitos faltantes, no que construya todo el producto.

Después de corregir la especificación, delega solo la primera tarea. Revisa el plan propuesto, inspecciona los cambios, ejecuta las pruebas y anota lo que el agente hizo mal.

Ese único ejercicio enseña la lección más importante de la era de los agentes: la calidad del resultado depende menos de la cantidad de código que el agente pueda producir que de cuán claramente el ser humano define, supervisa y evalúa el trabajo.

Conclusión

La educación de desarrolladores se está moviendo hacia un nuevo equilibrio.

Los estudiantes seguirán necesitando escribir código, especialmente mientras aprenden conceptos fundamentales. Pero la competencia profesional se demostrará cada vez más a través de la descomposición de problemas, especificación, comprensión de código, revisión, pruebas, orquestación, juicio de producto y uso responsable de sistemas autónomos.

Los currículos más sólidos no tratarán a los agentes de codificación como máquinas de hacer trampas o tutores mágicos. Los tratarán como herramientas de ingeniería potentes pero falibles. Los estudiantes aprenderán cuándo usarlos, cómo restringirlos, cómo evaluar su salida y cómo asumir la responsabilidad del sistema final.

El desarrollador más duradero de los próximos cinco años no será la persona que pueda producir más código a mano o generar el prompt más largo. Será la persona que pueda convertir un objetivo poco claro en un proceso confiable, guiar varias herramientas hacia ese objetivo, detectar fallos temprano y explicar por qué el software resultante merece ser confiable.