Flujos agénticos en ingeniería de software

Duración: 2 horas de clase + 1 hora de laboratorio Prerrequisitos: Semanas 1-12 (fundamentos hasta interacción humano-agente)

01Objetivos de aprendizaje

Al finalizar esta clase, los estudiantes serán capaces de:

1. Describir el panorama de los agentes de programación con IA y sus capacidades
2. Explicar cómo los flujos de trabajo agénticos difieren de la simple completación de código
3. Diseñar prompts y flujos de trabajo eficaces para agentes de programación en tareas no triviales
4. Identificar dónde encajan los agentes en los pipelines de CI/CD y el ciclo de vida del desarrollo de software
5. Evaluar críticamente las limitaciones y riesgos de la ingeniería de software asistida por agentes
6. Aplicar buenas prácticas de revisión de código, testing y seguridad al trabajar con agentes de IA
7. Analizar casos de estudio de ingeniería de software agéntica en organizaciones reales
8. Comparar frameworks de desarrollo de agentes y seleccionar el más adecuado para un caso de uso dado
9. Explicar por qué la observabilidad y la evaluación de agentes son críticas para los despliegues en producción
10. Describir cómo el uso de computador y los agentes de navegador extienden la automatización más allá de las API

021. Agentes de IA para generación y revisión de código

1.1 Por qué esto importa: la ingeniería de software se está transformando

Hemos dedicado las últimas doce semanas a construir una comprensión profunda de la IA agéntica: los fundamentos, las herramientas, los sistemas de memoria, los mecanismos de planificación, las medidas de seguridad y los patrones de interacción humana. Esta semana nos centramos en una de las aplicaciones más inmediatamente impactantes de toda esa teoría: la ingeniería de software agéntica.

La ingeniería de software es posiblemente el dominio donde la IA agéntica ha logrado más progreso y ha tenido más impacto. Hay una buena razón para ello: escribir código es una tarea susceptible de automatización de formas que muchas otras tareas de trabajo del conocimiento no lo son. El código tiene criterios claros de corrección (compila, los tests pasan, produce la salida correcta), es altamente estructurado (sigue reglas de sintaxis y patrones establecidos), y existe un enorme corpus de datos de entrenamiento (código open source en GitHub). Además, el bucle de retroalimentación es rápido: puedes ejecutar el código e inmediatamente ver si funciona.

Pero la transición de "IA que sugiere completados de código" a "IA que resuelve autónomamente tareas de ingeniería de software" no es solo una mejora cuantitativa. Es un cambio cualitativo que transforma la naturaleza del trabajo del desarrollador. Comprender este cambio, sus posibilidades y sus riesgos, es esencial para cualquiera que vaya a trabajar en ingeniería de software en los próximos años.

1.2 Del autocompletado a la programación autónoma: breve historia

La evolución de la programación asistida por IA ha pasado por cuatro etapas distintas, cada una representando un aumento fundamental de capacidad:

Etapa 1 -- Autocompletado estadístico (pre-2021). Herramientas como IntelliSense y el primer TabNine usaban modelos estadísticos (modelos n-gram, redes neuronales simples) para predecir los siguientes tokens. Las sugerencias se limitaban a completar la línea actual o pequeños fragmentos. El desarrollador tenía el control total y la contribución de la herramienta se limitaba a ahorrar pulsaciones de teclas.

Piensa en la Etapa 1 como el texto predictivo de tu teléfono: adivina la siguiente palabra basándose en lo que has escrito hasta ahora. Útil, pero no creativo. No podía escribir una frase que no estuvieras ya escribiendo.

Etapa 2 -- Completado neuronal de código (2021-2023). GitHub Copilot (basado en OpenAI Codex, a su vez basado en GPT-3) y Amazon CodeWhisperer introdujeron la generación de código basada en transformers. Estas herramientas podían generar bloques de código de varias líneas, funciones completas y código repetitivo (boilerplate). Pero eran fundamentalmente reactivas: completaban lo que el desarrollador ya estaba escribiendo. El desarrollador escribía la firma de la función y el docstring; el modelo generaba el cuerpo.

La Etapa 2 era como tener a un mecanógrafo muy rápido sentado a tu lado que podía convertir tus esquemas en prosa. Seguías necesitando saber qué querías escribir, pero el esfuerzo mecánico de escribirlo se reducía.

Etapa 3 -- Generación conversacional de código (2023-2024). ChatGPT, Claude y sistemas similares permitieron a los desarrolladores describir lo que querían en lenguaje natural y recibir código como respuesta. Esto fue un cambio del completado a la creación. Un desarrollador podía decir "escribe una API REST para gestión de usuarios con autenticación" y recibir una implementación funcional. Pero la interacción seguía siendo de un turno o pocos turnos: el desarrollador preguntaba, el modelo respondía, y había limitada retroalimentación o iteración.

La Etapa 3 era como contratar a un desarrollador freelance: describías lo que querías, entregaban código y tú lo revisabas. Pero no tenían acceso a tu base de código, tus tésts ni tu pipeline de despliegue.

Etapa 4 -- Programación agéntica (2024-presente). Los agentes de programación como Claude Code, Devin, Cursor Agent Mode y GitHub Copilot Workspace pueden ejecutar autónomamente tareas de ingeniería de software de múltiples pasos. Leen bases de código, entienden la estructura del proyecto, escriben código, ejecutan tests, depuran fallos e iteran. El rol del desarrollador pasa de "escribir código" a "especificar la intención y revisar los resultados."

La Etapa 4 es como tener un desarrollador junior en tu equipo: le das una tarea, él determina el enfoque, escribe el código, ejecuta los tésts, corrige los fallos y te presenta una implementación completada para revisión. Puede hacerte preguntas cuando se atasca y aprende de tu retroalimentación.

Idea clave: La diferencia clave entre la Etapa 3 y la Etapa 4 es el bucle cerrado. Un sistema de Etapa 3 genera código y te lo entrega. Un sistema de Etapa 4 genera código, lo ejecuta, observa los errores, los corrige, lo ejecuta de nuevo e itera hasta que los tésts pasan. Este bucle cerrado entre acción y observación es exactamente lo que define a un "agente" como lo definimos en la Semana 1.

1.3 ¿Qué hace "agéntico" a un agente de programación?

Un agente de programación no es sólo un generador de código. Tiene cinco características distintivas que corresponden a los componentes de agente que estudiamos a lo largo del curso:

1. Acceso a herramientas (Semanas 5-6): Puede leer archivos, escribir archivos, ejecutar comandos, ejecutar tests, consultar documentación, buscar en bases de código. Estas son las "manos" del agente.

2. Conciencia del entorno (Semana 7): Comprende la estructura del proyecto, las dependencias, los frameworks, las convenciones de código y los patrones existentes. Esta es la "memoria" del agente sobre el contexto del proyecto.

3. Planificación (Semanas 8-9): Puede descomponer una tarea en pasos y ejecutarlos secuencialmente. Una tarea como "corrige este bug" requiere: entender el bug, encontrar el código relevante, diagnosticar la causa, implementar la corrección, escribir un tést y verificar la corrección.

4. Bucles de retroalimentación (Semana 1): Puede ejecutar código, observar errores e iterar sobre las correcciones. Este ciclo observar-pensar-actuar es el núcleo de la agencia.

5. Memoria (Semana 7): Mantiene contexto a lo largo de una tarea de múltiples pasos (y a veces entre sesiones). El agente recuerda qué archivos ha leído, qué enfoques ha probado y qué retroalimentación le ha dado el usuario.

1.4 El panorama de los agentes de programación (en 2026)

El panorama de los agentes de programación se ha diversificado rápidamente. Aquí una visión general de las principales herramientas:

1.5 Evaluación comparativa de agentes de programación

SWE-bench (Jiménez et al., 2024) es el benchmark estándar para evaluar agentes de programación. Consiste en issues reales de GitHub de repositorios Python populares (Django, Flask, scikit-learn y otros), emparejados con casos de tést que validan la corrección. El benchmark es significativo porque usa bugs reales de proyectos reales, no puzzles sintéticos.

SWE-bench Verified es un subconjunto validado por humanos de 500 problemas que elimina tareas ambiguas o mal especificadas. A principios de 2026, los agentes con mejor rendimiento resuélven aproximadamente el 50-60 % de estos problemas de forma autónoma.

Para poner esto en perspectiva: estos son bugs reales que desarrolladores humanos encontraron, reportaron y eventualmente corrigieron. Resolver el 50-60 % de ellos de forma autónoma es notable. Pero también significa que el 40-50 % de los bugs del mundo real siguen más allá de las capacidades de los agentes actuales, y los problemas no resueltos tienden a ser los más difíciles, que requieren una comprensión más profunda.

Idea clave: Los agentes de programación son asistentes potentes pero no reemplazos autónomos de los desarrolladores. Destacan en tareas bien definidas de complejidad media (corregir un bug específico, añadir una funcionalidad con requisitos claros, escribir tésts para código existente). Tienen dificultades con la comprensión arquitectónica profunda, los algoritmos novedosos, los requisitos ambiguos y las preocupaciones transversales que abarcan todo el sistema.

Inténtalo tú mismo: evalúa un agente

Si tienes acceso a algún agente de programación (Claude Code, Cursor, Copilot o incluso un chatbot de nivel gratuito), prueba este experimento:

1. Elige un pequeño proyecto open source con buena cobertura de tésts
2. Encuentra un issue cerrado con un informe de bug claro
3. Pide al agente que corrija el bug, dándole solo el informe de bug (no la corrección)
4. Compara la corrección del agente con la corrección humana real

Nota: ¿Dónde tuvo éxito el agente? ¿Dónde tuvo dificultades? ¿Qué información necesitaba que no tenía?

032. El flujo de trabajo agente-desarrollador: programación en pareja con IA

2.1 Modelos de flujo de trabajo

Cómo los desarrolladores trabajan con agentes de programación varía significativamente según la tarea, la capacidad del agente y la preferencia del desarrollador. Han surgido cuatro modelos principales:

Modelo 1: Agente como desarrollador junior

El humano arquitecto diseña el sistema y luego delega la implementación de componentes específicos al agente. El humano revisa la salida, proporciona retroalimentación y el agente itera.

Este modelo funciona bien cuando:

• La tarea está bien especificada (entrada clara, salida clara, restricciones claras)
• Hay patrones existentes que seguir (el agente puede imitar lo que ya está en la base de código)
• El humano puede revisar eficazmente la salida (la tarea está dentro del dominio de experiencia del humano)

Piénsalo como delegar a un becario: le das un brief claro, hace el trabajo, lo revisas y proporcionas correcciones. El rol del humano es la especificación y el aseguramiento de calidad.

Modelo 2: Programación en pareja ping-pong

El humano y el agente alternan contribuciones. El humano escribe la firma de una función, el agente implementa el cuerpo. El agente escribe un test, el humano lo refina. Este ciclo de colaboración estrecha mantiene a ambas partes involucradas.

Ejemplo de sesión:

Humano: [Escribe la firma de la función y el docstring]
Agente: [Implementa el cuerpo de la función]
Humano: [Revisa, sugiere un caso límite que el agente olvidó]
Agente: [Añade el manejo del caso límite y escribe tests]
Humano: [Ejecuta los tests, detecta un problema de rendimiento]
Agente: [Optimiza la implementación]
Humano: [Aprueba la versión final]

Este modelo funciona bien para el desarrollo exploratorio donde los requisitos emergen a través del proceso de escritura de código. Mantiene al humano involucrado (reduciendo la paradoja de la automatización de la Semana 12) mientras aprovecha la velocidad del agente.

Modelo 3: Primero el agente, revisión humana

El agente realiza una tarea completa de principio a fin. El humano revisa el resultado final (o puntos de control intermedios). Este es el modelo más eficiente para tareas bien definidas pero requiere que el humano sea un revisor cuidadoso y exhaustivo.

El riesgo de este modelo es que el humano se convierta en un sello de goma (lá paradoja de lá automatización de nuevo). Si el agente normalmente produce buen código, el humano puede dejar de revisar cuidadosamente, y lá vez que el agente produce mal código es lá vez que el humano no lo detecta.

Modelo 4: Multi-agente con orquestación humana

Múltiples agentes especializados manejan diferentes aspectos de una tarea: uno para la implementación, uno para tésting, uno para documentación, uno para revisión de seguridad. El humano orquesta el flujo de trabajo general.

Este modelo está emergiendo pero aún no es mainstream. Aprovecha los patrones multi-agente que estudiamos en la Semana 10 y es más útil para tareas grandes y complejas donde la especialización aporta valor.

2.2 Comunicación eficaz con agentes de programación

La calidad de la salida del agente depende en gran medida de la calidad del prompt. Aquí es donde las técnicas de prompting de semanas anteriores dan fruto directamente. Principios clave:

Sé específico con los requisitos. En lugar de "añade manejo de errores", di "añade bloques try-except para errores de conexión a la base de datos, con lógica de reintentos (3 intentos, backoff exponencial) y logging estructurado usando el logger existente."

La diferencia es dramática. El prompt vago deja al agente adivinando qué tipo de manejo de errores quieres, qué framework de logging usar y si debe reintentar. El prompt específico elimina las conjeturas y produce una salida que se ajusta a tus necesidades.

Proporciona contexto. Dirige al agente a archivos, patrones y documentación relevantes. "Sigue el patrón de src/services/user_service.py para el acceso a la base de datos." Esto es especialmente importante porque los agentes (a diferencia de los desarrolladores humanos) no tienen años de contexto acumulado sobre tu base de código. Cada pieza de contexto que proporcionas reduce la probabilidad de que el agente haga una suposición errónea.

Indica restricciones explícitamente. "No modifiques la API pública. Mantén la compatibilidad hacia atrás. Usa solo dependencias de la biblioteca estándar." Las restricciones son cosas que el agente NO debe hacer, y son tan importantes como lo que debe hacer. Sin restricciones explícitas, el agente podría elegir la solución óptima al problema que resulta que rompe la compatibilidad hacia atrás de una forma que no puedes aceptar.

Describe el 'por qué'. "Necesitamos esto porque la implementación actual falla silenciosamente cuando la base de datos no está accesible, causando pérdida de datos." El "por qué" ayuda al agente a tomar decisiones de juicio. Si entiende que el objetivo es prevenir la pérdida de datos, tomará decisiones de diseño diferentes que si cree que el objetivo es añadir logging.

Define cuándo está terminado. "La tarea está completa cuando todos los tests existentes pasen, los nuevos tests cubran los escenarios de error, y el código siga nuestras reglas de lint." Sin una definición clara de completado, el agente no sabe cuándo dejar de iterar.

043. Testing automatizado con agentes

3.1 Agentes como escritores de tests

Una de las aplicaciones más inmediatamente valiosas de los agentes de programación es la generación automatizada de tests. Escribir tests a menudo se percibe como tedioso por los desarrolladores, lo que significa que la cobertura de tests es frecuentemente inadecuada. Los agentes, que no experimentan tedio, pueden aumentar dramáticamente la cobertura de tests. Los agentes pueden:

• Generar tests unitarios a partir de firmas de función y docstrings
• Crear tests de casos límite analizando rutas de código y condiciones frontera
• Escribir tests de integración que ejerciten endpoints de API o flujos de trabajo
• Generar tests basados en propiedades usando frameworks como Hypothesis
• Crear tests de regresión a partir de informes de bugs (asegurando que el bug no recurra)

3.2 Desarrollo dirigido por tests con agentes

Un flujo de trabajo interesante invierte el ciclo TDD tradicional:

1. El humano escribe los requisitos en lenguaje natural
2. El agente genera tests a partir de los requisitos (la fase "roja")
3. El agente implementa el código para pasar los tests (la fase "verde")
4. El humano revisa tanto los tests como el código
5. El agente refactoriza manteniendo los tests en verde (la fase "refactorizar")

Esto se llama a veces "Desarrollo dirigido por especificación" cuando se trabaja con agentes: el humano escribe la especificación, el agente escribe los tests y la implementación. El rol del humano se convierte en la especificación y la revisión, que son posiblemente las partes de mayor valor del desarrollo de software.

La ventaja clave de este flujo de trabajo es que los tests sirven como una especificación verificable por máquina. En lugar de discutir si el código "hace lo correcto", puedes señalar casos de test específicos y decir "¿pasa estos tests?"

3.3 Ejemplo: suite de tests generada por un agente

A continuación se muestra un ejemplo de cómo dirigir a un agente de programación para generar una suite de tésts completa. Presta atención a cómo el agente cubre no solo el camino feliz sino también los casos límite, las condiciones de error y la concurrencia.

"""
Prompt to the agent:
"Write a comprehensive test suite for the following TaskQueue class.
Cover normal operation, edge cases, error handling, and concurrency.
Use pytest. Include both unit tests and integration-style tests."
"""

# The class to test (provided to the agent as context):
import threading
import time
from collections import deque
from dataclasses import dataclass, field


@dataclass
class Task:
    task_id: str
    payload: dict
    priority: int = 0
    created_at: float = field(default_factory=time.time)


class TaskQueue:
    """Thread-safe priority task queue with size limits."""

    def __init__(self, max_size: int = 100):
        self.max_size = max_size
        self._queue: list[Task] = []
        self._lock = threading.Lock()
        self._not_empty = threading.Condition(self._lock)
        self._not_full = threading.Condition(self._lock)

    def put(self, task: Task, timeout: float | None = None) -> bool:
        with self._not_full:
            if len(self._queue) >= self.max_size:
                if not self._not_full.wait(timeout=timeout):
                    return False
            self._queue.append(task)
            self._queue.sort(key=lambda t: -t.priority)
            self._not_empty.notify()
            return True

    def get(self, timeout: float | None = None) -> Task | None:
        with self._not_empty:
            if not self._queue:
                if not self._not_empty.wait(timeout=timeout):
                    return None
            task = self._queue.pop(0)
            self._not_full.notify()
            return task

    def size(self) -> int:
        with self._lock:
            return len(self._queue)

    def is_empty(self) -> bool:
        return self.size() == 0


# --- Agent-generated test suite below ---

import pytest


class TestTaskQueueBasic:
    """Basic functionality tests."""

    def test_put_and_get_single_task(self):
        """Verify that a task can be added and retrieved."""
        queue = TaskQueue()
        task = Task(task_id="1", payload={"action": "test"})
        assert queue.put(task) is True
        result = queue.get()
        assert result is not None
        assert result.task_id == "1"

    def test_fifo_order_same_priority(self):
        """Tasks with the same priority should come out in FIFO order."""
        queue = TaskQueue()
        for i in range(5):
            queue.put(Task(task_id=str(i), payload={}, priority=0))
        ids = [queue.get().task_id for _ in range(5)]
        assert ids == ["0", "1", "2", "3", "4"]

    def test_priority_ordering(self):
        """Higher priority tasks should come out first."""
        queue = TaskQueue()
        queue.put(Task(task_id="low", payload={}, priority=1))
        queue.put(Task(task_id="high", payload={}, priority=10))
        queue.put(Task(task_id="mid", payload={}, priority=5))

        assert queue.get().task_id == "high"
        assert queue.get().task_id == "mid"
        assert queue.get().task_id == "low"

    def test_size_tracking(self):
        """Size should accurately reflect queue contents."""
        queue = TaskQueue()
        assert queue.size() == 0
        assert queue.is_empty() is True

        queue.put(Task(task_id="1", payload={}))
        assert queue.size() == 1
        assert queue.is_empty() is False

        queue.get()
        assert queue.size() == 0

    def test_max_size_enforcement(self):
        """Queue should reject tasks when full (with timeout)."""
        queue = TaskQueue(max_size=2)
        assert queue.put(Task(task_id="1", payload={})) is True
        assert queue.put(Task(task_id="2", payload={})) is True
        # Third put should timeout since queue is full
        assert queue.put(Task(task_id="3", payload={}), timeout=0.1) is False


class TestTaskQueueConcurrency:
    """Thread safety tests."""

    def test_concurrent_put_and_get(self):
        """Multiple producers and consumers should not lose tasks."""
        queue = TaskQueue(max_size=1000)
        results = []
        errors = []

        def producer(start_id, count):
            try:
                for i in range(count):
                    queue.put(Task(task_id=f"p{start_id}-{i}", payload={}))
            except Exception as e:
                errors.append(e)

        def consumer(count):
            try:
                for _ in range(count):
                    task = queue.get(timeout=5.0)
                    if task:
                        results.append(task.task_id)
            except Exception as e:
                errors.append(e)

        n_items = 100
        producers = [
            threading.Thread(target=producer, args=(i, n_items))
            for i in range(4)
        ]
        consumers = [
            threading.Thread(target=consumer, args=(n_items,))
            for _ in range(4)
        ]

        for t in producers + consumers:
            t.start()
        for t in producers + consumers:
            t.join(timeout=10)

        assert len(errors) == 0
        assert len(results) == 4 * n_items

    def test_get_blocks_until_item_available(self):
        """get() should block until a task is put."""
        queue = TaskQueue()

        def delayed_put():
            time.sleep(0.2)
            queue.put(Task(task_id="delayed", payload={}))

        threading.Thread(target=delayed_put).start()
        task = queue.get(timeout=2.0)
        assert task is not None
        assert task.task_id == "delayed"


class TestTaskQueueEdgeCases:
    """Edge case tests."""

    def test_get_from_empty_queue_with_timeout(self):
        """get() on an empty queue with timeout should return None."""
        queue = TaskQueue()
        result = queue.get(timeout=0.1)
        assert result is None

    def test_large_payload(self):
        """Queue should handle tasks with large payloads."""
        queue = TaskQueue()
        big_payload = {"data": "x" * 1_000_000}
        queue.put(Task(task_id="big", payload=big_payload))
        task = queue.get()
        assert len(task.payload["data"]) == 1_000_000

    def test_negative_priority(self):
        """Negative priorities should be handled correctly."""
        queue = TaskQueue()
        queue.put(Task(task_id="neg", payload={}, priority=-5))
        queue.put(Task(task_id="pos", payload={}, priority=5))
        assert queue.get().task_id == "pos"
        assert queue.get().task_id == "neg"

Observa cómo los tests generados por el agente cubren múltiples dimensiones: funcionalidad básica, garantías de ordenación, restricciones de tamaño, seguridad en concurrencia, comportamiento de bloqueo y casos límite. Un revisor humano debería verificar la completitud y añadir escenarios específicos del dominio que el agente podría haber pasado por alto.

054. Integración con CI/CD: agentes en el pipeline de desarrollo

4.1 Dónde encajan los agentes en CI/CD

Los agentes pueden participar en múltiples etapas del pipeline de desarrollo, no solo en la escritura de código:

Pre-commit. Los agentes revisan el código antes de que entre en el repositorio, detectando problemas tempranamente. Esto puede incluir comprobaciones de estilo, escaneo de seguridad y revisión lógica que va más allá de lo que las herramientas de análisis estático pueden hacer.

Revisión de pull requests. Los agentes revisan automáticamente los pull requests, proporcionando comentarios sobre calidad del código, bugs potenciales, tésts faltantes y lagunas en la documentación. Herramientas como CodeRabbit y GitHub Copilot PR review automatizan esto. El agente lee el diff, comprende el contexto de los cambios y proporciona retroalimentación específica de la base de código.

Correcciones automatizadas. Cuando el CI detecta un test fallido o un error de linting, un agente puede crear automáticamente un PŔ con la corrección. Esto cierra el bucle entre detección y resolución, reduciendo el tiempo que un build permanece roto.

Gestión de releases. Los agentes pueden redactar notas de release, actualizar changelogs y verificar que se cumplen todos los criterios de release. Estas son tareas mecánicas bien adecuadas para la automatización.

4.2 Ejemplo: agente en un flujo de trabajo de GitHub Actions

# .github/workflows/agent-review.yml
name: Agent Code Review

on:
  pull_request:
    types: [opened, synchronize]

jobs:
  agent-review:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
        with:
          fetch-depth: 0

      - name: Get changed files
        id: changes
        run: |
          echo "files=$(git diff --name-only origin/main...HEAD | tr '\n' ' ')" >> $GITHUB_OUTPUT

      - name: Run agent review
        env:
          ANTHROPIC_API_KEY: ${{ secrets.ANTHROPIC_API_KEY }}
          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
        run: |
          # Agent reviews each changed file and posts comments
          python scripts/agent_review.py \
            --files "${{ steps.changes.outputs.files }}" \
            --pr-number "${{ github.event.pull_request.number }}"

Este flujo de trabajo se activa en cada pull request, identifica los archivos modificados y ejecuta una revisión asistida por agente que pública comentarios directamente en el PR. El agente puede proporcionar retroalimentación más contextual y matizada que las herramientas de linting tradicionales porque comprende el código semánticamente.

4.3 Integración continúa con bucles de retroalimentación del agente

Un patrón potente es el CI con agente en el bucle donde el agente participa activamente en el proceso de CI:

1. El desarrollador hace push del código
2. El CI ejecuta los tests; algunos fallan
3. El agente analiza los fallos de tests (lee los mensajes de error, traza el código)
4. El agente propone correcciones
5. Si las correcciones son sencillas, el agente crea un commit
6. Si las correcciones son complejas, el agente crea un issue o comentario detallado explicando el problema
7. El desarrollador revisa y aprueba

Esto reduce el tiempo de respuesta para corregir fallos de CI de horas (esperando a que un desarrollador investigüe) a minutos.

065. Agentes de refactorización y migración de código

5.1 Por qué los agentes destacan en refactorización

La refactorización es particularmente adecuada para los agentes de programación por varias propiedades:

• Mecánica: Muchas operaciones de refactorización siguen patrones bien definidos (renombrar, extraer método, mover clase)
• Testeable: La refactorización no debería cambiar el comportamiento, por lo que los tests existentes validan el resultado
• Tediosa: Los humanos encuentran la refactorización a gran escala aburrida y propensa a errores (aquí es donde los agentes brillan: no se aburren ni se descuidan)
• Intensiva en contexto: Los agentes pueden rastrear todas las referencias a un símbolo en toda una base de código grande, algo que los humanos tienen dificultad para hacer manualmente

5.2 Tareas comunes de refactorización asistida por agente

Renombrado y reestructuración. Renombrar variables, funciones, clases y módulos de forma consistente en toda la base de código. Mover código entre archivos y actualizar todas las importaciones. Esto parece trivial, pero en una base de código grande con cientos de archivos, un renombradó puede ser sorprendentemente propenso a errores.

Migración de API. Cuando una biblioteca lanza una nueva versión de API, los agentes pueden actualizar todos los puntos de uso. Por ejemplo, migrar de una biblioteca de cliente HTTP antigua a una más nueva, actualizando firmas de funciones, cambiando nombres de parámetros y adaptándose a nuevos tipos de retorno.

Aplicación de patrones. Aplicar un patrón consistente en toda la base de código: añadir manejo de errores a todas las llamadas a base de datos, convertir callbacks a async/await, añadir logging a todos los endpoints de API, o añadir anotaciones de tipo a una base de código sin tipado.

Actualización de dependencias. Actualizar dependencias y corregir cambios que rompen compatibilidad. El agente lee el changelog, identifica el código afectado y aplica las modificaciones necesarias.

5.3 Caso de estudio: migración a TypeScript a gran escala

Una tarea común del mundo real es migrar una base de código JavaScript a TypeScript:

Tarea: Convertir src/utils/*.js a TypeScript

Enfoque del agente:
1. Leer cada archivo .js y analizar el código
2. Inferir tipos a partir de patrones de uso, comentarios JSDoc y comprobaciones en tiempo de ejecución
3. Renombrar .js a .ts
4. Añadir anotaciones de tipo
5. Corregir errores de tipo reportados por el compilador
6. Ejecutar los tests existentes para verificar que el comportamiento no cambia
7. Iterar sobre errores de tipo hasta que el build tenga éxito

Un agente puede manejar archivos sencillos (funciones de utilidad puras con tipos claros) casi perfectamente. Los archivos complejos (los que usan patrones dinámicos, construcción de tipos en tiempo de ejecución o metaprogramación intensiva) requieren asistencia humana. El flujo de trabajo práctico suele ser: dejar que el agente maneje el 80 % de los archivos que son sencillos, y luego que un humano se encargue del 20 % restante.

076. Generación de documentación

6.1 Tipos de documentación que los agentes pueden generar

Documentación de API. A partir de firmas de función, docstrings y ejemplos de uso, los agentes pueden generar documentación de API completa. Esto funciona bien porque la fuente de verdad (el código) está disponible para el agente.

Documentación de arquitectura. Analizando imports, dependencias y estructura de archivos, los agentes pueden generar diagramas de arquitectura y explicaciones. El agente puede identificar los componentes principales, sus dependencias y sus patrones de comunicación.

Generación de README. Los agentes pueden crear READMEs de proyecto a partir de la base de código, incluyendo instrucciones de configuración, ejemplos de uso y directrices de contribución.

Comentarios inline. Los agentes pueden añadir comentarios explicativos a secciones de código complejas, haciendo la base de código más accesible para nuevos contribuidores.

Generación de changelog. A partir del historial de git y las descripciones de PR, los agentes pueden compilar changelogs estructurados que resumen lo que cambió entre releases.

6.2 Consideraciones de calidad

La documentación generada por agentes tiene inconvenientes conocidos que se deben vigilar:

Repetir lo obvio. Los agentes a menudo generan comentarios qué reformulan el código en lugar de explicar la intención: # Increment counter by 1 encima de counter += 1. La buena documentación explica el por qué, no el qué.

Detalles alucinados. El agente podría describir comportamiento que el código en realidad no implementa. Esto es especialmente peligroso en la documentación porque los lectores confían en la documentación como fuente autorizada.

Obsolescencia. La documentación generada a partir del código se queda obsoleta cuando el código cambia. Si generas la documentación una vez y nunca la actualizas, eventualmente será engañosa.

Contexto faltante. Los agentes describen lo que hace el código pero pueden pasar por alto por qué fue escrito de esa forma. El contexto de negocio, las decisiones históricas y la justificación de los compromisos a menudo no están en el código.

Buena práctica. Usa agentes para redactar documentación, luego haz que un humano revise la precisión, relevancia y completitud. Integra la generación de documentación en el CI para que se mantenga actualizada con el código.

087. Agentes de depuración y resolución de incidencias

7.1 El flujo de trabajo de depuración

La depuración es donde las capacidades agénticas realmente brillan porque requiere exactamente el tipo de razonamiento multi-paso y multi-archivo en el que los agentes son buenos. Un flujo de trabajo de depuración sistemático para un agente es:

1. Reproducir: Leer el informe de bug, entender el comportamiento esperado vs. el real
2. Localizar: Buscar en la base de código el código relevante, analizar trazas de pila, identificar la ubicación probable del bug
3. Diagnosticar: Entender por qué el código se comporta incorrectamente, trazando la lógica a través de múltiples funciones si es necesario
4. Corregir: Implementar la corrección
5. Verificar: Escribir un test que capture el bug y confirmar que la corrección lo resuelve
6. Prevenir: Sugerir mejoras para prevenir bugs similares en el futuro

7.2 Cuándo los agentes tienen dificultades con la depuración

Los agentes son menos eficaces cuando:

• El bug implica interacciones de estado complejas entre muchos componentes
• El problema es ambiental (funciona en una máquina pero no en otra)
• El bug requiere comprender sistemas externos (API de terceros, hardware)
• La causa raíz está en una dependencia, no en el código propio del proyecto
• Reproducir el bug requiere condiciones de timing o concurrencia específicas

7.3 Ejemplo: dirigiendo a un agente para un bug no trivial

Prompt: "Los usuarios reportan que nuestra API ocasionalmente devuelve datos obsoletos.
El endpoint es GET /api/v2/products/:id. Nuestro stack es:
- Next.js API routes
- Redis cache (TTL: 5 minutos)
- Base de datos PostgreSQL
- El problema ocurre aproximadamente en 1 de cada 20 solicitudes
- Solo ocurre después de una actualización de producto vía PUT /api/v2/products/:id

Investiga este bug. Comprueba la lógica de invalidación de caché,
la consulta a la base de datos y el handler de la ruta de la API.
Busca condiciones de carrera o problemas de coherencia de caché."

Un buen agente de programación:

1. Leerá los handlers de las rutas GET y PUT
2. Trazará la lógica de invalidación de caché en el handler PUT
3. Identificará si hay una ventana entre la actualización de la base de datos y la invalidación de caché
4. Comprobará condiciones de carrera cuando llegan solicitudes concurrentes de lectura y escritura
5. Propondrá una corrección (probablemente: invalidar la caché antes de retornar del handler PUT, o usar un patrón caché-aside con seguimiento de versiones)

Este tipo de depuración multi-archivo y multi-sistema es donde las capacidades agénticas realmente brillan. El agente puede leer muchos archivos, formar un modelo mental del flujo de datos y trazar flujos de lógica que llevarían a un humano significativamente más tiempo.

098. Limitaciones y riesgos

8.1 Preocupaciones sobre la calidad del código

Bugs sutiles. Los agentes pueden producir código que parece correcto pero contiene errores lógicos sutiles, especialmente en casos límite. El código compila, los tests pasan (si los tests son insuficientes), pero el comportamiento es incorrecto en escenarios específicos. Este es el modo de fallo más peligroso porque es invisible.

Código no idiomático. Los agentes entrenados en bases de código diversas pueden producir código que funciona pero no sigue las convenciones del proyecto ni las mejores prácticas de la comunidad del lenguaje. El código es correcto pero no "se siente bien" para los desarrolladores experimentados del equipo.

Sobreingeniería. Los agentes pueden añadir abstracciones, patrones o dependencias innecesarias cuando una solución más simple bastaría. Si se le pide añadir un archivo de configuración, el agente podría crear un sistema completo de gestión de configuración con soporte de variables de entorno, vigilancia de archivos y validación de esquemas cuando un simple diccionario sería suficiente.

Patrones desactualizados. Los datos de entrenamiento de los agentes tienen una fecha de corte. Pueden usar API obsoletas o prácticas desactualizadas. Esto es especialmente relevante en ecosistemas que evolucionan rápidamente como JavaScript/TypeScript, donde las mejores prácticas cambian con rapidez.

8.2 Vulnerabilidades de seguridad

Pearce et al. (2022) estudiaron la seguridad del código generado por GitHub Copilot y encontraron que aproximadamente el 40 % del código generado contenía vulnerabilidades de seguridad en escenarios específicamente diseñados para producir código sensible a la seguridad. Los problemas comunes incluyen:

• Inyección SQL por concatenación de cadenas en lugar de consultas parametrizadas
• Validación de entrada ausente (confiando en la entrada del usuario)
• Uso inseguro de funciones criptográficas (usar MD5 para hash de contraseñas)
• Vulnerabilidades de traversál de rutas (no sanitizar las rutas de archivos)
• Credenciales o secretos codificados en el código

Mitigación. Ejecuta siempre herramientas de escaneo de seguridad (SAST/DAST) en el código generado por agentes. Trata la salida del agente con el mismo escrutinio que el código de un contribuidor no verificado. Nunca asumás que, porque una IA lo escribió, es seguro.

8.3 Dependencia excesiva y atrofia de habilidades

Una preocupación significativa es que los desarrolladores que dependen excesivamente de los agentes de programación pueden experimentar atrofia de habilidades:

• Capacidad reducida de escribir código desde cero (siempre empezando con la salida del agente)
• Comprensión disminuida de algoritmos y estructuras de datos subyacentes
• Debilitamiento de habilidades de depuración (confiando en el agente para depurar)
• Disminución de la comprensión del código (aceptando la salida del agente sin entenderla completamente)

Esto refleja la paradoja de la automatización discutida en la Semana 12: a medida que la herramienta se vuelve más capaz, la capacidad del humano para verificar y corregir su salida puede disminuir. Un desarrollador que no puede escribir código sin un agente está en una posición precaria: no puede evaluar si el código del agente es bueno porque carece de la habilidad para escribir una alternativa.

Mitigación. Práctica deliberadamente la escritura de código sin asistencia de agentes. Mantén las habilidades fundamentales mediante katas, retos de código o días periódicos de desarrollo "sin IA".

8.4 Propiedad intelectual y licencias

El código generado por agentes de IA plantea cuestiones de propiedad intelectual que permanecen en gran medida sin resolver:

• ¿És el código generado por agentes susceptible de derechos de autor? (Varía según la jurisdicción; la Oficina de Derechos de Autor de EE. UU. dice que la producción puramente de IA no lo es)
• Si el agente fue entrenado con código open source, ¿el código generado hereda alguna licencia? (No está claro; hay varias demandas pendientes)
• ¿Puede el desarrollador reclamar autoría exclusiva del código asistido por agente? (Éticamente cuestionable si el agente hizo la mayor parte del trabajo)

El enfoque seguro es tratar el código generado por agentes como si fuera escrito por un colega: revísalo, entiéndelo, asume la responsabilidad y prepárate para explicar y defender cada línea.

109. Casos de estudio de ingeniería de software agéntica en la práctica

9.1 Caso de estudio: SWE-agent (Princeton NLP Group)

Yang et al. (2024) presentaron SWE-agent, un sistema diseñado para resolver issues reales de GitHub de forma autónoma. La idea clave fue el concepto de Agent-Computer Interface (ACI): comandos personalizados diseñados para la forma en que los agentes LLM interactúan con el código, en lugar de acceso directo al shell.

En lugar de dar al agente comandos bash como grep, cat y sed, SWE-agent proporciona comandos como open_file, search_dir, edit_file y run_tests. Estos son semánticamente más claros y menos propensos a errores para el modelo. El agente piensa en qué hacer, ejecuta una acción, observa el resultado y repite.

SWE-agent alcanzó un 12,47 % en el dataset original de SWE-bench, estableciendo una línea base que los sistemas posteriores mejoraron significativamente.

Lección: La interfaz entre el agente y sus herramientas importa enormemente. Las herramientas bien diseñadas que se ajustan al "estilo cognitivo" del agente superan a las interfaces crudas de bajo nivel. Esto refleja lo que aprendimos en las Semanas 5-6 sobre el diseño de herramientas.

9.2 Caso de estudio: Copilot Workspace (GitHub)

GitHub Copilot Workspace representa un enfoque de "planificar y ejecutar":

1. El desarrollador describe una tarea (o selecciona un issue de GitHub)
2. El sistema analiza la base de código y genera un plan (qué archivos cambiar y por qué)
3. El desarrollador revisa y edita el plan
4. El sistema implementa el plan en todos los archivos afectados
5. El desarrollador revisa los cambios y puede iterar

Este es un enfoque de autonomía de Nivel 3 (automatización condicional de la Semana 12): el agente hace el trabajo, pero el humano aprueba el plan y revisa el resultado.

Lección: Mostrar el plan antes de la ejecución construye confianza y detecta malentendidos tempranamente. Los usuarios prefieren abrumadoramente la capacidad de modificar el plan antes de que el agente comience a trabajar. Este es el patrón de aprobación a nivel de plan de la Semana 12 en acción.

9.3 Caso de estudio: Claude Code (Anthropic)

Claude Code opera como una herramienta de CLI que combina un bucle agéntico con acceso completo al terminal. Aspectos clave:

• Acceso directo al sistema de archivos y terminal: El agente puede leer, escribir, buscar y ejecutar comandos directamente
• Contexto a nivel de proyecto: Usa archivos CLAUDE.md para instrucciones y convenciones específicas del proyecto
• Sistema de permisos: Pide aprobación antes de ejecutar operaciones potencialmente peligrosas
• Pensamiento extendido: Usa razonamiento de cadena de pensamiento para planificar operaciones complejas

En la práctica, los equipos reportan que Claude Code es más eficaz para tareas de refactorización multi-archívo, comprensión y navegación de bases de código desconocidas, implementación de funcionalidades bien especificadas en proyectos establecidos, escritura de suites de tésts completas y depuración de problemas complejos con pasos claros de reproducción.

Lección: Combinar la generación de código con acceso al terminal y conciencia del sistema de archivos hace al agente significativamente más capaz que la generación de código basada en chat solamente. El agente no solo genera código; interactúa con el entorno de desarrollo completo.

1110. Agentes de programación modernos: una mirada más cercana (2025-2026)

10.1 Claude Code (Anthropic)

Claude Code es un asistente de programación agéntico basado en terminal. A diferencia de los plugins de IDE, opera como un proceso CLI independiente.

Arquitectura: Claude Code sigue un bucle observar-pensar-actuar. Lee el estado actual de la base de código (observar), razona sobre qué hacer a continuación usando pensamiento extendido (pensar), y luego ejecuta una acción como editar un archivo o ejecutar un comando (actuar). Este bucle continúa hasta que la tarea está completa.

Características clave:

• Configuración CLAUDE.md: Los proyectos incluyen un archivo CLAUDE.md con instrucciones específicas del proyecto que moldean el comportamiento del agente entre sesiones.
• Sistema de permisos: Pide aprobación explícita del usuario antes de operaciones destructivas.
• Hooks: Hooks pré- y post-acción que aplican políticas personalizadas.
• Servidores MCP (Model Context Protocol): Conexión a herramientas y fuentes de datos externas a través de una interfaz estandarizada.
• Sub-agentes: Genera sub-agentes para tareas paralelizables.
• Nativo de git: Integración profunda con git para staging, commits y diffs.

10.2 Cursor

Cursor es un IDE AI-first (un fork de VS Code) con IA en cada nivel:

• Tab completion: Autocompletado contextual que predice ediciones multi-línea.
• Edición inlíne Cmd+K: Selecciona código y describe un cambio en lenguaje natural.
• Modo chat agéntico (Composer Agent): Modo agéntico completo con ediciones multi-archivo y comandos de terminal.
• .cursorrules: Configuración de proyecto para convenciones del agente.
• Indexación de la base de código: Búsqueda semántica en todo el proyecto.

10.3 Windsurf (Codeium)

Windsurf es otro IDE AI-first:

• Cascade: Un motor de flujo agéntico para tareas multi-paso y multi-archivo.
• Supercomplete: Predice las próximas varias acciones del desarrollador.
• Conciencia en tiempo real: Rastrea la actividad del IDE como contexto implícito.

10.4 GitHub Copilot

Copilot ha evolucionado significativamente:

• Modo agente (2025): Realiza ediciones multi-archivo y ejecuta comandos de terminal en VS Code.
• Copilot Workspace: Flujos de trabajo planificar-y-ejecutar desde issues de GitHub.
• Copilot para PRs: Comentarios de revisión automatizados y correcciones sugeridas.
• Copilot Extensions: Integraciones de terceros.

10.5 Devin (Cognition Labs)

Devin opera en su propio entorno aislado en la nube:

• Entorno completo: Navegador, shell y editor de código en una VM en la nube.
• Tareas de larga duración: Diseñado para tareas que llevan horas.
• Integración con Slack/issues: Se le asignan tareas vía Slack o issues de GitHub.

10.6 OpenHands (anteriormente OpenDevin)

OpenHands es open source:

• Entorno Docker aislado: El agente opera dentro de un contenedor.
• Múltiples implementaciones de agente: Soporta diferentes arquitecturas.
• Navegación web: Puede consultar documentación durante el trabajo.
• Competitivo en SWE-bench: Se posiciona consistentemente entre los mejores.

10.7 SWE-agent (Princeton NLP)

La contribución principal de SWE-agent es la Agent-Computer Interface (ACI): comandos personalizados optimizados para la interacción de agentes LLM con código. La idea de que el diseño de herramientas importa tanto como la capacidad del modelo ha influido en todos los agentes de programación posteriores.

1211. Frameworks de agentes para desarrolladores

11.1 OpenAI Agents SDK

Un framework ligero para construir aplicaciones agénticas:

• Agent: Un LLM configurado con instrucciones, herramientas y guardrails.
• Handoffs: Transferencia de control entre agentes especializados.
• Guardrails: Validadores de entrada/salida ejecutándose en paralelo.
• Tracing: Registro de ejecución integrado.

from agents import Agent, Runner, handoff

billing_agent = Agent(
    name="Billing Agent",
    instructions="Handle billing inquiries. Be concise.",
    tools=[lookup_invoice, process_refund],
)

triage_agent = Agent(
    name="Triage Agent",
    instructions="Route the user to the right department.",
    handoffs=[handoff(billing_agent)],
)

result = Runner.run_sync(triage_agent, "I need a refund for order #1234")

11.2 Claude Agent SDK (Anthropic)

Soporta conversaciones multi-turno, uso de herramientas y salida estructurada con pensamiento extendido e integración MCP.

11.3 LangGraph

Flujos de trabajo de agentes basados en grafos con transiciones explícitas, persistencia y soporte human-in-the-loop:

from langgraph.graph import StateGraph, END

graph = StateGraph(AgentState)
graph.add_node("plan", plan_step)
graph.add_node("execute", execute_step)
graph.add_node("review", human_review_step)
graph.add_edge("plan", "execute")
graph.add_edge("execute", "review")
graph.add_conditional_edges("review", should_continue, {
    "iterate": "plan",
    "approve": END,
})

11.4 CrewAI

Enfoque de juego de roles con agentes especializados:

from crewai import Agent, Task, Crew

researcher = Agent(
    role="Technical Researcher",
    goal="Find the best architecture for the given requirements",
    backstory="You are a senior architect with 15 years of experience.",
    tools=[web_search, read_docs],
)

developer = Agent(
    role="Senior Developer",
    goal="Implement the architecture recommended by the researcher",
    backstory="You are a detail-oriented developer who writes clean code.",
    tools=[file_write, run_tests],
)

crew = Crew(agents=[researcher, developer], tasks=[research_task, impl_task])
result = crew.kickoff()

11.5 Semantic Kernel (Microsoft)

Orientado a empresa con integración Azure, arquitectura de plugins y soporte multi-lenguaje (Python, C#, Java).

11.6 Comparación de frameworks

1312. Observabilidad y evaluación de agentes

12.1 Por qué importa la observabilidad

Los flujos de trabajo de agentes son intrínsecamente complejos. Sin observabilidad, estás volando a ciegas:

• Ejecución multi-paso: Un agente podría hacer 20-50 llamadas a herramientas por tarea. Cualquier paso puede fallar.
• No determinismo: El mismo prompt puede llevar a diferentes caminos de ejecución.
• Seguimiento de costes: Sin observabilidad, los costes pueden dispararse.
• Aseguramiento de calidad: Los equipos necesitan verificar la calidad de la salida del agente a lo largo del tiempo.
• Bucles de depuración: Los agentes pueden quedarse atrapados en bucles. La observabilidad los detecta y los interrumpe.

12.2 Herramientas clave

LangSmith (LangChain): Trazado, evaluación y monitorización con vistas jerárquicas de trazas.

Langfuse (open source): Autoalojable con trazas, puntuaciones, gestión de prompts y seguimiento de costés.

Braintrust: Framework de evaluación con integración CI.

12.3 SWE-bench como estándar de evaluación

SWE-bench proporciona 2.294 tareas del mundo real de 12 repositorios Python. SWE-bench Verified (500 problemas) es el estándar de referencia. A principios de 2026, los mejores agentes resuelven el 50-60 % de las tareas Verified.

Otros benchmarks: HumanEval/MBPP (a nivel de función), WebArena (tareas web), GAIA (asistente general), TAU-bench (atención al cliente).

1413. Uso de computador y agentes de navegador

13.1 Más allá de las API: interacción visual

Un desarrollo de frontera son los agentes que interactúan con interfaces gráficas de la misma forma que un humano: mirando la pantalla y usando acciones de ratón y teclado.

Claude Computer Use (Anthropic) captura pantallás, analiza el contenido visual y emite acciones de ratón y teclado. Esto permite la automatización de tareas para las que no existe API.

Casos de uso en ingeniería de software:

• Testing de GUI (verificar el renderizado visual)
• Testing cross-browser
• Interacción con sistemas legacy (sistemas con solo GUI)
• Testing de flujos de trabajo end-to-end

Limitaciones: Más lento que las llamadas a API. Menos fiable que el uso estructurado de herramientas. Cambios menores en la UI pueden romper los flujos de trabajo.

13.2 Agentes de navegador

• Browser Use: Biblioteca open source para navegación por el navegador.
• Playwright MCP: Servidor MCP que expone las capacidades de Playwright.
• Stagehand (Browserbase): Automatización de navegador AI-nativa que combina comprensión visual con acceso al DOM.

13.3 Benchmark WebArena

WebArena (Zhou et al., 2024) evalúa agentes de navegación web en tareas realistas en aplicaciones web autoalojadas. Los mejores agentes resuelven aproximadamente el 30-40 % de las tareas, lo que indica un margen significativo de mejora.

1514. Buenas prácticas para trabajar con agentes de programación

14.1 Prácticas de revisión

1. Revisa el código del agente tan críticamente como el código humano. No asumas que es correcto porque lo escribió una IA.
2. Comprueba los casos límite. Los agentes a menudo manejan bien el camino feliz pero pasan por alto los casos límite.
3. Verifica la seguridad. Ejecuta herramientas de escaneo de seguridad en todo el código generado por agentes.
4. Entiende antes de aceptar. Si no entiendes lo que hace el código, no lo aceptes.
5. Ejecuta los tests. Nunca fusiones código generado por agentes sin ejecutar la suite de tests completa.

14.2 Prácticas de prompting

1. Proporciona contexto completo. Incluye archivos relevantes, restricciones y convenciones.
2. Sé específico con los requisitos. La ambigüedad lleva a suposiciones incorrectas.
3. Define criterios de aceptación. ¿Qué aspecto tiene "terminado"?
4. Itera. Trata la salida del agente como un primer borrador, no como un producto final.
5. Usa archivos de proyecto. Configura CLAUDE.md, .cursorrules o equivalente.

14.3 Prácticas organizacionales

1. Establece políticas. Define qué tareas pueden manejar los agentes de forma autónoma.
2. Rastrea las contribuciones del agente. Conoce qué código fue generado por agentes para auditoría.
3. Mantén las habilidades. Asegura que los desarrolladores escriban código regularmente sin asistencia de agentes.
4. Comparte patrones. Documenta prompts y flujos de trabajo eficaces para tu equipo.
5. Mide el impacto. Rastrea la velocidad, la tasa de defectos y el tiempo de revisión de código.

1615. Preguntas de discusión

1. El debate sobre la pérdida de habilidades: ¿El uso generalizado de agentes de programación llevará a una generación de desarrolladores que no pueden programar sin asistencia de IA? ¿Es esto un problema, o es similar a cómo las calculadoras cambiaron la educación matemática? Considera que no se espera que los matemáticos de hoy hagan divisiones largas a mano.

   Pista: Piensa en qué habilidades se vuelven más importantes (especificación, revisión, arquitectura, estrategia de testing) y cuáles se vuelven menos importantes (velocidad de escritura, memorización de sintaxis, generación de boilerplate).

2. Propiedad del código: Si un agente escribe el 80 % de una base de código, ¿quién es el autor? ¿Quién es responsable de los bugs? ¿Cómo afecta esto a la cultura de revisión de código?

3. El mito del desarrollador 10x: Algunos afirman que los agentes de programación convierten a cada desarrollador en un "desarrollador 10x." Crítica esta afirmación. ¿Qué habilidades se vuelven más valiosas cuando los agentes manejan la implementación?

   Písta: Si el cuello de botella pasa de la implementación a la especificación y la revisión, entonces los desarrolladores que mejor comprenden los requisitos y evalúan la calidad del código se convierten en los más valiosos, no los que escriben más rápido.

4. Implicaciones para el open source: ¿Cómo afectan los agentes de programación al ecosistema open source? Si los agentes pueden generar código que se parece mucho al código open source existente, ¿cuáles son las implicaciones de licencias?

5. Dinámica competitiva: A medida que los agentes de programación se vuelven más capaces, ¿qué pasa con la demanda de desarrolladores junior? ¿Cómo debería adaptarse la educación en ciencias de la computación?

1716. Resumen y puntos clave

1. Los agentes de programación representan la Etapa 4 de la programación asistida por IA, con un bucle cerrado de acción y observación que los distingue de herramientas de generación de código más simples.

2. El panorama es diverso: Desde herramientas integradas en IDE (Copilot, Cursor) hasta agentes CLI (Claude Code, Aider) pasando por sistemas totalmente autónomos (Devin, OpenHands). Cada uno ofrece diferentes compromisos entre autonomía y control.

3. Los flujos de trabajo eficaces agente-desarrollador van desde "agente como desarrollador junior" hasta "programación en pareja ping-póng" hasta "primero el agente, revisión humana." El modelo adecuado depende de la tarea, la capacidad del agente y la experiencia del desarrollador.

4. Los agentes destacan en tareas específicas: generación de tests, refactorización, documentación, depuración de problemas bien definidos e implementación de funcionalidades con especificaciones claras. Tienen dificultades con algoritmos novedosos, decisiones de arquitectura profundas y preocupaciones transversales.

5. La integración con CI/CD permite que los agentes participen a lo largo del ciclo de vida del desarrollo: revisando PRs, corrigiendo fallos de CI y asistiendo con los despliegues.

6. La seguridad es una preocupación real: Los estudios muestran que el código generado por IA frecuentemente contiene vulnerabilidades. El escaneo de seguridad, la revisión cuidadosa y el "confiar pero verificar" son esenciales.

7. Los riesgos de dependencia excesiva incluyen la atrofia de habilidades, la aceptación acrítica de la salida del agente y la comprensión reducida del código. Los equipos deben mantener deliberadamente las habilidades humanas de programación.

8. Los frameworks de agentes (OpenAI Agents SDK, Claude Agent SDK, LangGraph, CrewAI, Semantic Kernel) permiten a los desarrolladores construir agentes personalizados, cada uno con diferentes compromisos.

9. La observabilidad es innegociable: Herramientas como LangSmith, Langfuse y Braintrust proporcionan el trazado, la evaluación y la monitorización necesarios para la fiabilidad en producción.

10. El uso de computador y los agentes de navegador representan una nueva frontera donde los agentes interactúan con GUIs visualmente, permitiendo la automatización de tareas para las que no existe API.

11. Las buenas prácticas se centran en tratar la salida del agente como un primer borrador: revisar críticamente, verificar la seguridad, ejecutar tests y asegurar la comprensión antes de aceptar.

1817. Referencias

• Chen, M., Tworek, J., Jun, H., Yuan, Q., Pinto, H. P. D. O., Kaplan, J., ... & Zaremba, W. (2021). Evaluating large language models trained on code. arXiv preprint arXiv:2107.03374.

• Jiménez, C. E., Yang, J., Wettig, A., Yao, S., Pei, K., Press, O., & Narasimhan, K. (2024). SWE-bench: Can language models resolve real-world GitHub issues? Proceedings of the 12th International Conference on Learning Representations (ICLR 2024).

• Pearce, H., Ahmad, B., Tan, B., Dolan-Gavitt, B., & Karri, R. (2022). Asleep at the keyboard? Assessing the security of GitHub Copilot's code contributions. 2022 IEEE Symposium on Security and Privacy (SP), 754-768.

• Yang, J., Jiménez, C. E., Wettig, A., Liber, K., Yao, S., Narasimhan, K., & Press, O. (2024). SWE-agent: Agent-computer interfaces enable automated software engineering. arXiv preprint arXiv:2405.15793.

• Vaithilingam, P., Zhang, T., & Glassman, E. L. (2022). Expectation vs. experience: Evaluating the usability of code generation tools powered by large language models. CHI Conference on Human Factors in Computing Systems Extended Abstracts, 1-7.

• Barke, S., James, M. B., & Polikarpova, N. (2023). Grounded copilot: How programmers interact with code-generating models. Proceedings of the ACM on Programming Languages, 7(OOPSLA1), 85-111.

• Zhou, S., Xu, F. F., Zhu, H., Zhou, X., Lo, R., Sridhar, A., ... & Neubig, G. (2024). WebArena: A realistic web environment for building autonomous agents. Proceedings of the 12th International Conference on Learning Representations (ICLR 2024).

• OpenAI (2025). Agents SDK: A lightweight framework for building agentic applications. OpenAI Documentation. https://openai.github.io/openai-agents-python/

• Anthropic (2025). Claude Code: An agentic coding tool. Anthropic Documentation. https://docs.anthropic.com/en/docs/claude-code

• Anthropic (2025). Model Context Protocol (MCP). Anthropic Documentation. https://modelcontextprotocol.io/

Estos apuntes de clase forman parte del curso de IA Agéntica. Licenciados bajo CC BY 4.0.