# Programación asistida por agentes de inteligencia artificial

**Categoría:** Programación · **Nivel:** Intermedio · **Lectura:** 15 min
**Publicada:** 2026-07-27 · **Actualizada:** 2026-07-27 · **Autoría:** Underc0de
**Versión HTML (canónica):** https://underc0de.org/guias/programacion/programacion-asistida-por-agentes-de-ia/

Escribir código dejó de ser el cuello de botella. Los dos pasos que quedan del lado humano —especificar y revisar— son justo los que se acortan cuando uno quiere ir rápido, y ahí es donde se pierde todo lo ganado.

## Respuesta rápida

Un **agente de código** no sugiere: **actúa**. Lee archivos, decide qué modificar, edita, ejecuta comandos y pruebas, e itera. Eso mueve el cuello de botella: escribir se vuelve barato y lo caro pasa a ser **especificar** —qué hay que lograr, con qué criterio y qué queda fuera— y **revisar** el cambio completo. Hay **cuatro fallas documentadas** que conviene conocer porque tienen corrección conocida: sobreingeniería, fijación en hacer pasar las pruebas, especular sobre código que no leyó y acciones difíciles de revertir. Y una regla que no cambió: **firmás el código igual que antes**, así que la responsabilidad es de quien lo integra.

## Qué cambia realmente

La diferencia entre un autocompletado inteligente y un agente no es de calidad: es de **categoría**. Un autocompletado propone la línea siguiente y vos la aceptás o la descartás. Un agente **lee** archivos, **decide** qué tocar, **edita** varios a la vez, **ejecuta** comandos y pruebas, y **itera** sobre sus propios resultados.

Ese salto tiene una consecuencia que reordena el trabajo entero:

| Tarea | Antes | Con agentes |
|---|---|---|
| Decidir qué construir | Parte del trabajo | **Sigue siendo tuyo, y pesa más** |
| Escribir el código | La mayor parte del tiempo | Barato y rápido |
| Revisar el resultado | Se revisaba código propio, ya entendido | **Hay que entender código que no escribiste** |
| Volumen de cambios por hora | Acotado por lo que se puede teclear | Mucho mayor, y hay que poder absorberlo |

La última fila es la que más se subestima. Un agente puede producir en veinte minutos un cambio que lleva una hora revisar bien, y ahí aparece la tentación de revisar mal. **La capacidad de revisión se vuelve el límite real del sistema**, y eso no se resuelve con una herramienta.

## El ciclo de cuatro pasos

![El ciclo de cuatro pasos de la programación con agentes: especificar, el agente trabaja, revisar e integrar, con vuelta al primer paso. Debajo, las cuatro fallas típicas con la instrucción que las corrige, y la escala de permisos en tres niveles.](../../assets/img/guias/programacion-asistida-por-agentes-de-ia-ciclo.svg)

El ciclo se repite: **la primera vuelta rara vez es la última**, y volver a especificar con lo aprendido en la revisión es parte normal del método, no una señal de que algo salió mal.

## Especificar: el paso que decide

Una tarea bien delegable tiene cuatro cosas escritas. Sin ellas, el agente completa los huecos con supuestos razonables que casi nunca son los tuyos.

1. **El resultado buscado, en términos observables.** No «mejorá el rendimiento del listado» sino «el endpoint del listado tiene que responder en menos de 300 ms para 10 000 registros».
2. **El criterio de aceptación.** Cómo se va a saber que está bien: qué prueba tiene que pasar, qué comportamiento tiene que conservarse.
3. **El alcance, incluido lo que queda afuera.** Esta es la parte que más ahorra y la que menos se escribe: «no toques la capa de acceso a datos», «no cambies la firma pública», «no agregues dependencias».
4. **El punto de partida.** Qué archivos son relevantes. Un agente que tiene que descubrir la arquitectura entera gasta contexto y adivina más.

> **El mismo principio que en cualquier pedido a un modelo.** Vale acá exactamente lo que está en [cómo escribir buenos prompts](../../inteligencia-artificial/como-escribir-buenos-prompts/index.md): no hay palabras mágicas, hay contexto que das o contexto que se adivina. La diferencia con un chat es que un agente **actúa** sobre esos supuestos, así que un supuesto equivocado no produce una respuesta mediocre: produce un cambio en tu repositorio que hay que deshacer.

## Darle el contexto del proyecto

Repetir las mismas convenciones en cada pedido es trabajo perdido. La solución que adoptaron las herramientas es un **archivo de instrucciones persistentes** versionado junto al código, que se carga al inicio de cada sesión. En Claude Code ese archivo es `CLAUDE.md`, y su mecánica —dónde vive, qué alcance tiene cada ubicación, cómo generarlo— está en la guía de [cómo instalar Claude Code](../../inteligencia-artificial/instalar-claude-code-windows-linux-mac/index.md).

Lo que importa acá es **qué conviene poner adentro**, porque un archivo lleno de obviedades no sirve y uno con lo justo cambia todo:

- **Los comandos reales del proyecto.** Cómo se instala, cómo se compila, cómo se ejecutan las pruebas, cómo se levanta el entorno. Es lo que más rinde: sin eso, el agente prueba variantes hasta acertar.
- **Las convenciones que no se deducen del código.** Por qué existe una carpeta, qué patrón se sigue a propósito, qué se decidió no hacer y por qué. Lo deducible del código no hace falta escribirlo.
- **Los límites duros.** Qué no se toca nunca, qué necesita aprobación, qué archivos son generados y no se editan a mano.
- **Las trampas del proyecto.** Ese servicio que hay que levantar primero, esa prueba que falla en ciertos entornos, ese archivo que parece muerto y no lo está.

Un buen indicador: el archivo debería contener lo que le explicarías a alguien que se suma al equipo y es muy bueno programando, pero no conoce nada de tu contexto.

## Las cuatro fallas típicas

Estas cuatro están documentadas por el propio fabricante, con la instrucción que las corrige. Conviene conocerlas porque son **predecibles**, y eso significa que se pueden prevenir en el pedido en lugar de descubrirlas en la revisión.

### 1. Sobreingeniería

La documentación de Anthropic lo describe como una tendencia a **«sobreingeniería creando archivos extra, agregando abstracciones innecesarias o incorporando flexibilidad que no se pidió»**. Es la falla más frecuente y la más silenciosa, porque el resultado *funciona*: solo es más complicado de lo necesario.

La corrección es explicitar el límite, y vale reproducir los cuatro ejes que propone:

```text
Evitá la sobreingeniería. Hacé solo los cambios pedidos o
claramente necesarios. Mantené las soluciones simples:

- Alcance: no agregues funciones, no refactorices ni hagas
  «mejoras» más allá de lo pedido. Un arreglo de error no
  necesita limpiar el código de alrededor.
- Documentación: no agregues comentarios ni anotaciones de
  tipo a código que no cambiaste.
- Código defensivo: no agregues validaciones para escenarios
  que no pueden ocurrir. Validá solo en los bordes del sistema.
- Abstracciones: no crees ayudantes ni utilidades para
  operaciones de una sola vez. No diseñes para requisitos
  hipotéticos futuros.
```

La frase que resume el criterio: **la complejidad correcta es la mínima que necesita la tarea actual**.

### 2. Fijación en que las pruebas pasen

Esta es la más grave, porque produce código que *parece* terminado. La documentación advierte que un agente puede **concentrarse demasiado en hacer pasar las pruebas a costa de soluciones más generales**, y llegar a escribir valores fijos que satisfacen los casos concretos sin resolver el problema.

La instrucción que lo corrige tiene tres partes, y las tres importan: pedir una **solución de propósito general que funcione para todas las entradas válidas, no solo para los casos de prueba**; aclarar que **las pruebas están para verificar la corrección, no para definir la solución**; y pedirle que **avise si una prueba es incorrecta o la tarea es inviable, en lugar de trabajar alrededor del problema**.

### 3. Especular sobre código que no leyó

Un agente puede afirmar cómo funciona un archivo que nunca abrió. La corrección documentada es directa: **nunca especular sobre código que no se abrió; si se menciona un archivo concreto, hay que leerlo antes de responder**, e investigar los archivos relevantes antes de afirmar cualquier cosa sobre el proyecto.

En la práctica, esta instrucción cambia bastante la calidad de las respuestas sobre bases de código grandes, y tiene un efecto secundario útil: las sesiones se vuelven más lentas y más correctas.

### 4. Acciones difíciles de revertir

Sin indicaciones, un agente puede tomar acciones difíciles de deshacer o que afectan sistemas compartidos: borrar archivos, forzar un *push*, publicar en servicios externos. La corrección es pedirle que **evalúe la reversibilidad y el impacto** de lo que va a hacer, que actúe con libertad en lo local y reversible, y que **pregunte antes** de lo que sea difícil de revertir, afecte a sistemas compartidos o pueda ser destructivo.

> **La parte de esa instrucción que más vale la pena.** Un agregado que suele omitirse y evita los peores incidentes: pedirle explícitamente que **no use acciones destructivas como atajo cuando encuentre un obstáculo**. Ni saltear controles de seguridad —del estilo de un `--no-verify`— ni descartar archivos desconocidos que podrían ser trabajo en curso de otra persona.

## Cómo revisar lo que produce

Acá está la diferencia entre ganar tiempo y acumular deuda. Revisar código generado tiene una trampa propia: **está bien escrito**. Tiene nombres razonables, estructura ordenada y comentarios coherentes, y todo eso baja la guardia. La revisión tiene que apuntar a otras cosas:

| Pregunta | Qué está buscando |
|---|---|
| ¿Resuelve el problema o el caso de prueba? | Valores fijos, atajos que solo funcionan con los datos del ejemplo |
| ¿Qué archivos tocó que yo no esperaba? | Alcance desbordado, refactorizaciones no pedidas |
| ¿Hay abstracciones nuevas con un solo uso? | Sobreingeniería |
| ¿Puedo explicar cada línea? | Si no, no está listo para integrar |
| ¿Agregó dependencias? | Cada una es una decisión de largo plazo, y se decide aparte |
| ¿Qué se borró? | Lo eliminado es más difícil de ver que lo agregado, y suele ser lo importante |

Dos hábitos que ayudan más que cualquier lista: **pedir cambios chicos**, porque un cambio de trescientas líneas no se revisa de verdad y uno de treinta sí; y **leer el cambio en el orden del control de versiones**, archivo por archivo, en lugar de conversar sobre el resultado dentro de la sesión, donde es fácil quedarse con el resumen que el propio agente hizo de su trabajo.

## La escala de permisos

Conviene acordarla antes de empezar, no en el momento en que aparece la pregunta. Tres niveles alcanzan:

- **Libre: local y reversible.** Leer archivos, editar, ejecutar pruebas, crear una rama. Todo lo que se deshace con un comando del control de versiones.
- **Con revisión: toca el repositorio compartido.** Confirmar cambios, abrir una propuesta, instalar dependencias, modificar la configuración del proyecto.
- **Confirmación explícita: destructivo o visible por otros.** Borrar ramas o archivos, *push* forzado, restablecimientos duros, publicar, comentar en un repositorio ajeno, tocar infraestructura o producción.

Y una consideración que va más allá de los permisos: el agente **lee tu código**, y con eso las credenciales que estén en archivos de configuración, los datos de prueba y todo lo que haya en el repositorio. Los criterios de qué material conviene exponer están en [riesgos, ética y uso responsable de la IA](../../inteligencia-artificial/riesgos-etica-y-uso-responsable-de-la-ia/index.md).

## Qué tareas rinden y cuáles no

| Tarea | ¿Rinde? | Por qué |
|---|---|---|
| Migraciones mecánicas repetidas en muchos archivos | **Mucho** | Trabajo tedioso con criterio claro y verificable |
| Escribir pruebas de código que ya funciona | Mucho | El comportamiento correcto ya está definido |
| Entender una base de código ajena | Mucho | Leer y resumir es donde más rinde por hora |
| Arreglar un error con reproducción clara | Sí | Hay criterio de éxito objetivo |
| Trabajo repetitivo de andamiaje | Sí | Predecible y fácil de revisar |
| Decidir la arquitectura de un sistema nuevo | **No** | Depende de restricciones y prioridades que no están en el código |
| Reglas de negocio ambiguas o mal definidas | No | El agente resuelve la ambigüedad por su cuenta, y elige mal |
| Cambios en código crítico que no entendés | No | Si no podés revisarlo, no podés integrarlo |

El patrón detrás de la tabla: **rinde donde el criterio de correcto está claro y verificable**, y falla donde el trabajo real es decidir qué es correcto.

## Qué cambia en un equipo

Tres cosas concretas, más allá de la productividad individual:

**La revisión de cambios se vuelve el control principal.** Antes era una segunda opinión sobre código que alguien había pensado línea por línea; ahora puede ser la primera vez que una persona lee ese código con atención. Eso justifica cambios de política: propuestas más chicas, y la regla de que quien propone tiene que poder explicar cada línea.

**El archivo de contexto del proyecto se vuelve infraestructura.** Si está bien mantenido, todo el equipo obtiene mejores resultados; si está desactualizado, todos reciben cambios que violan convenciones. Conviene tratarlo como código: revisarlo, actualizarlo cuando cambia una convención y discutirlo cuando hay desacuerdo.

**Conviene declarar el uso de asistencia.** No como trámite: una línea en el mensaje del cambio le da a quien revisa un contexto útil sobre dónde mirar con más atención.

## Errores frecuentes

- **Pedir tareas enormes.** «Implementá el módulo de facturación» produce un cambio imposible de revisar. Tres pedidos chicos rinden más que uno grande.
- **No decir qué queda afuera.** Es la omisión que más trabajo genera después, porque el alcance se desborda solo.
- **Aceptar porque las pruebas pasan.** Es exactamente la falla número dos, vista desde el otro lado.
- **Revisar dentro de la sesión.** Se termina leyendo el resumen que el agente hizo de su propio trabajo en lugar del cambio real.
- **Dejar el archivo de contexto sin mantener.** Un contexto desactualizado es peor que ninguno, porque produce cambios convencidos y equivocados.
- **Darle permisos amplios «para que no moleste».** Es el patrón que convierte un error en un incidente.
- **Delegar lo que no entendés.** Si no podés revisarlo, no ganaste tiempo: pospusiste el problema.
- **Dejar de practicar.** Si delegás siempre, la capacidad de revisar —que es la que sostiene todo el flujo— se atrofia.

## Preguntas frecuentes

### ¿Qué diferencia a un agente de un autocompletado inteligente?

Que actúa en lugar de sugerir. Un autocompletado propone la línea siguiente y vos la aceptás o no; un agente lee archivos, decide qué modificar, edita varios a la vez, ejecuta comandos y las pruebas, y itera sobre sus propios resultados. La consecuencia práctica es un cambio en dónde está el esfuerzo: escribir código deja de ser el cuello de botella y pasan a serlo especificar bien la tarea y revisar lo que salió. Los dos pasos que quedan del lado humano son justamente los que la mayoría acorta cuando quiere ir rápido.

### ¿Hace falta saber programar para usar un agente de código?

Para producir algo que funcione una vez, no. Para mantener un sistema en el tiempo, sí, y bastante. La razón es concreta: todo el valor del flujo depende de poder revisar lo que produjo, y revisar exige más criterio que escribir, no menos. Quien no puede leer el cambio no puede distinguir una solución correcta de una que funciona por casualidad, ni detectar que el agente resolvió el caso de prueba en lugar del problema. Sin ese filtro, la velocidad inicial se paga después con intereses.

### ¿Por qué agrega código que nadie pidió?

Es un comportamiento conocido y documentado: la tendencia a sobreingeniería, creando archivos extra, abstracciones innecesarias o flexibilidad que no se pidió. La corrección es explicitar el límite en el pedido: que no agregue funciones ni refactorice más allá de lo solicitado, que no documente código que no tocó, que no agregue validaciones para escenarios que no pueden ocurrir y que no cree abstracciones para operaciones de una sola vez. La regla que resume todo: la complejidad correcta es la mínima que la tarea actual necesita.

### ¿Puede hacer trampa para que las pruebas pasen?

Sí, y es una de las fallas más importantes de conocer, porque produce código que parece terminado. Un agente puede concentrarse demasiado en hacer pasar las pruebas a costa de una solución general, escribiendo valores fijos que satisfacen los casos concretos. La instrucción que lo corrige es pedir explícitamente una solución de propósito general que funcione para todas las entradas válidas, aclarar que las pruebas están para verificar y no para definir la solución, y pedirle que avise si una prueba es incorrecta en lugar de trabajar alrededor de ella.

### ¿Qué permisos conviene darle?

Los mínimos, organizados en tres niveles. Libre para lo local y reversible: leer archivos, editar, ejecutar pruebas, crear una rama, porque todo eso se deshace. Con revisión previa para lo que toca el repositorio compartido: confirmar cambios, abrir una propuesta, instalar dependencias. Y con confirmación explícita para lo destructivo o visible por terceros: borrar ramas, un push forzado, un reset duro, publicar. Una regla adicional que conviene incluir: que no use acciones destructivas como atajo cuando encuentra un obstáculo.

### ¿De quién es la responsabilidad del código que escribe un agente?

De quien lo integra, sin ambigüedad. Que un cambio lo haya escrito un agente no cambia quién responde por él, igual que copiar una respuesta de un foro nunca eximió a nadie. En la práctica eso tiene tres consecuencias: el cambio pasa por la misma revisión que cualquier otro, quien lo propone tiene que poder explicar cada línea, y conviene dejar registrado en el mensaje del cambio que se usó asistencia, no por trámite sino porque le da contexto útil a quien revise.

## Fuentes

Documentación oficial y material de la comunidad consultados para esta guía. Fecha de consulta: 27 de julio de 2026.

### Aportes de la comunidad Underc0de

1. **Underc0de, foro.** [Apuntes de programación](https://underc0de.org/foro/programacion-general/apuntes-de-programacion/), por *facusteckler86*, sección Programación General, 31 de enero de 2025.
2. **Underc0de, foro.** [Sección Programación General](https://underc0de.org/foro/programacion-general/). Hilos de la comunidad sobre desarrollo y herramientas.

### Documentación oficial

3. **Anthropic.** [Prompting best practices](https://platform.claude.com/docs/en/build-with-claude/prompt-engineering/claude-prompting-best-practices). Las cuatro fallas documentadas con sus instrucciones correctoras: sobreingeniería, fijación en las pruebas, especulación sobre código no leído y equilibrio entre autonomía y seguridad, citadas en sus puntos principales.
4. **Anthropic.** [Prompt engineering overview](https://platform.claude.com/docs/en/build-with-claude/prompt-engineering/overview). La necesidad de definir criterios de éxito antes de trabajar un pedido.

---

Esta guía forma parte de un proyecto de la comunidad Underc0de para organizar conocimiento técnico en español. Fuente canónica: https://underc0de.org/guias/programacion/programacion-asistida-por-agentes-de-ia/