Los agentes de código necesitan sesiones apiladas, no prompts más grandes

Los asistentes de programación con IA están entrando en una etapa más práctica. El patrón antiguo era pedirlo todo en un prompt enorme, dejar que el modelo cambiara el proyecto y luego intentar revisar un diff difícil. La publicación de GitHub sobre stacked sessions y pull requests en GitHub Copilot app propone algo mejor: separar el trabajo en sesiones, ramas y pull requests visibles.

La diferencia importa porque el software agentivo acelera el trabajo, pero también aumenta el riesgo. Un reporte de TechCrunch sobre pruebas de seguridad de Anthropic recuerda que los modelos avanzados pueden realizar acciones ofensivas en entornos controlados. La respuesta no es rechazar los agentes, sino darles permisos estrechos y dejar evidencia revisable. Para lectores de BTTC, el mejor flujo de IA no es el que escribe más código de golpe, sino el que permite inspeccionar cada cambio. Puedes combinarlo con herramientas del directorio de software de BTTC.

Por qué las sesiones apiladas son relevantes

Las sesiones apiladas acercan la IA al flujo normal de ingeniería. Un desarrollador puede pedir mejoras de estilo, eliminación de dependencias, accesibilidad o nuevas pruebas sin mezclar todo en una rama gigante. Cada sesión mantiene su propio contexto y puede generar un pull request separado. Si una ruta se vuelve confusa, el equipo puede cerrarla y empezar de nuevo desde la rama correcta.

La nueva habilidad clave es diseñar la revisión

A medida que mejora la generación, el cuello de botella pasa a la revisión. Los equipos deben definir qué archivos puede tocar el agente, qué pruebas son obligatorias, qué zonas están prohibidas y cuándo debe aprobar una persona. Una buena tarea incluye objetivo, alcance pequeño, rama base, pruebas esperadas y plan de reversión. La descripción del pull request debe explicar qué cambió, por qué cambió, cómo se probó y qué sigue siendo incierto.

Lecciones de seguridad para agentes

El caso de Anthropic no significa que debamos evitar agentes de código. Significa que debemos diseñarlos como sistemas de producción. Necesitan mínimo privilegio, entornos aislados, secretos limitados y registros auditables. Un desarrollador individual puede aplicar lo mismo: usar ramas separadas, leer el diff, ejecutar pruebas, revisar comandos de shell antes de usarlos y detener la tarea si el agente sale del alcance pedido.

Flujo recomendado para empezar

Comienza con una cola simple: una sesión para errores, otra para pruebas, otra para documentación y otra para refactorización. Da a cada sesión una instrucción estrecha y pide un resultado del tamaño de un pull request. Revisa en orden de dependencia y fusiona solo lo que mejora el proyecto y pasa las pruebas. Herramientas comunes como capturas, convertidores de PDF, compresores de medios, visores de diff y notas siguen siendo importantes porque aceleran la revisión humana. Hay más guías en el blog de BTTC.

Preguntas frecuentes

¿Las sesiones apiladas solo sirven para equipos grandes?

No. Los desarrolladores individuales también obtienen puntos de control limpios y pueden descartar un experimento fallido sin perder otro trabajo.

¿Conviene permitir que un agente fusione PR automáticamente?

Normalmente no al principio. La fusión automática requiere pruebas fuertes, alcance limitado, protección de ramas y responsabilidad clara.

¿Cuál es una buena primera tarea?

Elige algo pequeño y verificable, como agregar pruebas, mejorar documentación, corregir lint o actualizar un componente.

Conclusión

La próxima etapa de la programación con IA se medirá por disciplina de flujo, no solo por calidad del modelo. Las sesiones apiladas de GitHub Copilot encajan con ramas pequeñas, pull requests, pruebas y revisión humana. Usa agentes para preparar trabajo, pero mantén el alcance, la seguridad y la decisión final bajo control humano.