AI-Assisted Software Engineering
Entrada a la rama
Este mapa organiza el uso de sistemas AI para ayudar a construir, cambiar, verificar y mantener software. Orienta preguntas y recorridos; las definiciones corresponden a los canónicos enlazados. El alcance directo de AI-Assisted Software Engineering sigue Knowledge Map V0.5 y se conecta con Agentic Systems. La rama más amplia de AI Engineering conserva temas futuros que no se presentan como materializados aquí.
AI-Assisted Software Engineering observa el proceso de ingeniería que utiliza AI. AI Application Engineering observa el software cuyo comportamiento de producto incorpora AI. Un equipo puede desarrollar un checkout sin funcionalidades AI utilizando coding agents; también puede construir un producto con AI mediante un proceso poco agentic. Ambas dimensiones pueden coexistir sin convertirse en sinónimos.
El recorrido no exige adoptar un producto, una cantidad de agentes o un grado de autonomía. Se conserva el conocimiento existente de requisitos, diseño, testing y entrega. Aquí cambia la pregunta por quién realiza partes del trabajo, qué decisiones se delegan y cómo se obtiene evidencia suficiente para revisarlas. Ninguna etiqueta de producto resuelve esas preguntas por el equipo.
Fundamentos disponibles
| Pregunta de entrada | Documento y foco |
|---|---|
| ¿Qué agrega un agente a un modelo y qué significa continuar o detenerse? | agents introduce sistema, entorno, feedback y límites. |
| ¿Cómo puede ayudar AI mientras la persona conduce el trabajo? | coding-assistants organiza modalidades de asistencia e iniciativa humana. |
| ¿Qué se delega cuando un sistema investiga y ejecuta varios pasos de desarrollo? | coding-agent especializa el agente y distingue Agentic Coding. |
| ¿Cómo distribuyen personas y AI decisiones, ejecución y aceptación? | human-agent-collaboration distingue colaboración de aprobación, delegación y revisión. |
| ¿Cómo combino generación variable, reglas programadas y juicio humano? | deterministic-and-probabilistic-development-workflows organiza composición y límites de evidencia. |
| ¿Quién decide la continuación y cómo conviven pasos programados y selección agentic? | workflows-vs-agents delimita control y composición. |
| ¿Cómo organizo secuencia, rutas, concurrencia, planificación y feedback? | agentic-workflow-patterns compara familias sin exigir varios agentes. |
Leer primero según la duda real. Una persona que usa sugerencias inline puede comenzar por Coding Assistants; quien evalúa encargar una investigación puede comenzar por Coding Agent y volver a Agents para precisar el loop. La navegación no impone que toda asistencia deba transformarse en agencia ni que una secuencia de lectura sea una escala de madurez.
Workflows vs Agents y Agentic Workflow Patterns pertenecen a Agentic Systems: son conceptos generales, no exclusivos de coding. Este mapa los conecta con desarrollo; sus ejemplos no los convierten en una metodología. Los workflows específicos disponibles más abajo organizan actividades profesionales, sin imponer un patrón de control del agente.
Fundamentos durables relacionados
Para comprender el modelo: machine-learning-fundamentals → neural-networks → transformers → llm-fundamentals. Es una ruta educativa entre conceptos disponibles, no una historia de reemplazos ni una dependencia obligatoria de todo sistema AI. Context Window permanece dentro de LLM Fundamentals.
embeddings e information-retrieval explican representación y recuperación, con un único canonical de IR bajo Data. probabilistic-vs-deterministic-software caracteriza mecanismos del software; non-determinism examina variación y reproducibilidad. Son fundamentos relacionados con el proceso asistido, sin redefinir aquí la rama directa ya cubierta ni anticipar RAG o patrones de aplicación.
Capacidades generales de agentes — disponible
| Pregunta de entrada | Documento |
|---|---|
| ¿Cómo organizo y reviso un curso previsto sin confundirlo con evidencia? | planning |
| ¿Cómo se solicita una capacidad estructurada y qué distingue disponibilidad de autorización? | tool-calling |
| ¿Qué información puede conservarse para decisiones futuras y cómo se distingue del contexto activo? | agent-memory |
El modelo aporta inferencia; el agente organiza trabajo mediante un loop con continuación o detención. Planning, Tool Calling y Memory son capacidades componibles, no componentes obligatorios de todos los agentes. Los protocolos de interoperabilidad tampoco definen por sí solos ese sistema.
Commerce como comparación de encargos
Ante una validación de checkout que rechaza un importe válido, «explicá esta conversión y sugerí qué comprobar» conduce hacia Coding Assistants. «Investigá y corregí dentro de Payments UI, conservá el contrato y reportá los tests relevantes» conduce hacia Coding Agent. Agents permite examinar cómo observaciones y decisiones conectan los pasos del segundo encargo.
Ese recorrido sirve para separar contexto, autoridad y resultado. Tener archivos disponibles no autoriza modificar cualquier parte; disponer de terminal no concede release. La persona puede aclarar la regla de pagos y revisar la evidencia sin conducir cada búsqueda. Los documentos desarrollan la distinción sin convertir el ejemplo en un workflow obligatorio ni duplicar aquí sus definiciones.
Rutas por preguntas
¿Un LLM ya es un agente? Comenzar por agents. Allí se distingue inferencia de ejecución y se explica por qué herramientas, estado persistente o acceso al entorno no están implícitos en el modelo. No hace falta materializar todavía un catálogo de modelos para formular esa pregunta correctamente.
¿Usar herramientas cambia un assistant en agent? Contrastar coding-assistants con coding-agent. El foco está en quién conduce el progreso y qué selección de pasos se delega. Las superficies IDE, CLI, chat y cloud no ofrecen una clasificación suficiente; las autorizaciones deben examinarse para el encargo concreto.
¿Agentic Coding significa cualquier código generado? Ir a coding-agent. Allí conviven la definición del actor y la práctica para conservar la distinción sin abrir dos páginas prematuramente. El origen del código no demuestra un proceso agentic, y una investigación delegada puede producir evidencia sin modificar archivos.
¿Quién decide que el resultado sirve? Seguir la discusión de evidencia y responsabilidad en Coding Agent. testability permite profundizar sobre obtener y diagnosticar pruebas; design-process conserva el razonamiento arquitectónico cuando corresponde. Son puentes existentes, no una reapertura de Architecture Core ni una sustitución de sus conceptos por AI.
Contexto e instrucciones — disponible
context-engineering-for-software-development organiza Repository/Task Context, selección, refresh, compaction, aislamiento y transferencia. persistent-instructions agrupa Repository Instructions, scope, authority y conflict resolution. El primero pregunta qué información necesita el trabajo; el segundo, qué guía reutilizable aplica. Sus subtemas permanecen agrupados, sin un archivo por mecanismo o formato de producto.
Runtime y límites de ejecución — disponible
| Pregunta de entrada | Documento |
|---|---|
| ¿Qué maquinaria sostiene el loop y media herramientas, contexto y políticas? | agent-harness |
| ¿Dónde ocurren las acciones y con qué recursos? | agent-execution-environment |
| ¿Qué está autorizado y cuándo hace falta una autorización adicional? | agent-permissions-and-approval-boundaries |
| ¿Qué restricciones técnicas limitan recursos y consecuencias? | agent-sandboxing |
| ¿Qué estado puede restaurarse y qué efectos externos permanecen? | agent-checkpoints-and-recovery |
| ¿Cómo reconstruyo eventos y relaciones sin exigir razonamiento privado? | agent-tracing |
Camino de navegación del Atlas: agents → workflows-vs-agents → agentic-workflow-patterns → agent-harness → agent-execution-environment → agent-permissions-and-approval-boundaries → agent-sandboxing. Es una propuesta de lectura, no una pila arquitectónica universal ni una dependencia lineal obligatoria.
Agent State and Sessions permanece agrupado en Agent Harness. Human Approval permanece en Permissions and Approval Boundaries. Local, Remote and Background Execution conserva su hogar en Execution Environment; no se convierten en páginas separadas por disponer de navegación hacia ellos.
Coordinación — disponible
| Pregunta de entrada | Documento |
|---|---|
| ¿Cómo delego trabajo acotado y reúno contribuciones? | subagents-and-delegation |
| ¿Cuándo se transfiere control o responsabilidad, además de información? | agent-handoffs |
| ¿Cómo organizo dependencias, propiedad y conflictos entre ejecuciones? | multi-agent-coordination |
| ¿Cuándo varias ejecuciones pueden progresar concurrentemente y qué cuesta integrarlas? | parallel-agent-execution |
Delegación, handoffs, coordinación y concurrencia describen relaciones diferentes. Specialist Routing and Result Aggregation permanece dentro de Subagents and Delegation. Un sistema multiagente puede ser secuencial; herramientas paralelas no implican varios agentes y más participantes no constituyen mayor madurez.
Artefactos de desarrollo — disponible
| Pregunta de entrada | Documento |
|---|---|
| ¿Cómo encargo trabajo concreto y hago visibles objetivo, scope y evidencia? | task-prompts |
| ¿Cómo conservo procedimientos reutilizables y distingo discovery de activation? | agent-skills |
| ¿Qué configura un especialista y qué lo separa de una ejecución delegada? | agent-profiles |
| ¿Qué comportamiento se dispara por eventos del runtime? | lifecycle-hooks |
| ¿Cómo se distribuyen capacidades sin confundir packaging con interoperabilidad? | agent-extension-packages |
| ¿Qué evidencia del trabajo conviene conservar para revisión y continuidad? | development-context-and-execution-records |
Estos artefactos pueden colaborar sin formar una pila obligatoria. El recorrido contexto → instrucciones → task prompts → skills → perfiles / hooks / paquetes → registros permite contrastar sus responsabilidades. No exige crear configuraciones, instalar extensiones ni utilizar todos los mecanismos para cada tarea.
Interoperabilidad — disponible
| Pregunta de entrada | Documento |
|---|---|
| ¿Cómo conecto aplicaciones AI con capacidades y contexto externos? | Model Context Protocol — MCP |
| ¿Qué contrato integra un cliente/editor con un coding agent? | Agent Client Protocol — ACP |
| ¿Cómo solicito trabajo a otro sistema agente sin compartir su implementación? | Agent2Agent Protocol — A2A |
Los tres pertenecen a Agentic Systems y pueden coexistir. Sus fronteras principales no son capas excluyentes ni una pila obligatoria. MCP distingue Host/Client/Server; ACP organiza la interacción de cliente y agente; A2A permite intercambio de mensajes, tareas y resultados. Los canónicos conservan discovery, permisos, confianza y portabilidad como preguntas diferentes.
Workflows de desarrollo — disponible
| Pregunta de entrada | Documento |
|---|---|
| ¿Cómo convierto un pedido incompleto en trabajo situado en el repositorio? | repository-exploration-and-task-framing |
| ¿Cómo orientan especificaciones, planes y propuestas de diseño sin imponer una metodología? | specification-assisted-development |
| ¿Cómo participa el agente en funcionalidades, bugs, refactor, migraciones y mantenimiento? | ai-assisted-implementation-and-change-maintenance |
| ¿Qué aportan los tests generados y qué no demuestran? | ai-assisted-test-generation |
| ¿Cómo obtener observaciones de revisión sustentadas sin confundirlas con verificación? | ai-assisted-code-review |
| ¿Cómo investigar fallos de CI y asistir releases dentro de la autoridad existente? | ci-failure-investigation-and-release-assistance |
| ¿Qué separa un workspace y qué recursos siguen compartidos? | workspace-isolation-for-coding-agents |
Plan-Guided Execution y Design Assistance permanecen agrupados en Specification-Assisted Development. Feature Development, Bug Investigation, Refactoring, Modernization, Migration, Documentation y Dependency Upgrades permanecen en Implementation and Change Maintenance. Los conceptos generales de ingeniería conservan sus responsabilidades; estos documentos explican la participación del agente, el contexto, la evidencia y los límites del trabajo.
Verificación, fiabilidad y evaluación — disponible
| Pregunta de entrada | Documento |
|---|---|
| ¿Qué evidencia justifica que este cambio satisface esta tarea? | generated-code-verification |
| ¿Cómo reconozco desviaciones del trabajo y elijo una recuperación delimitada? | coding-agent-failure-modes-and-recovery |
| ¿Cómo evalúo comportamiento del sistema entre tareas y ejecuciones? | agent-evaluation |
| ¿Cómo diseño una evaluación general de un sistema AI? | ai-evaluation-fundamentals |
| ¿Qué casos y referencias hacen posible juzgar comportamiento? | evaluation-datasets |
| ¿Cómo automatizo juicios y evalúo graders? | automated-graders |
| ¿Cómo estructuro juicio humano sobre resultados? | human-evaluation |
| ¿Cómo detecto degradación después de un cambio? | regression-testing |
Task-Specific Evidence and Acceptance, Self-Verification and Independent Verification y Evidence-Based Completion and Review permanecen agrupados en Generated Code Verification. Los modos de fallo permanecen en un solo canonical. AI Evaluation Fundamentals contiene Offline y Online Evaluation; Automated Graders agrupa LLM-as-Judge. Tool-Use and Trace Evaluation, Harness-Aware Evaluation y Coding-Agent Task Evaluation se desarrollan dentro de Agent Evaluation, cuyo hogar físico es Evaluation. La navegación conecta esa rama con desarrollo sin confundir evaluación entre casos y verificación de un cambio.
Seguridad y economía de AI atravesarán la rama cuando se materialicen sus conceptos. No es necesario anticipar aquí una política, un modelo de amenazas completo o una comparación de precios. Los canónicos disponibles ya tratan autonomía acotada, permisos y responsabilidad; el tratamiento general de seguridad y economía permanece fuera del alcance directo de esta rama.
Application Patterns — núcleo disponible
Como conexión con AI Engineering general: structured-generation organiza la forma de salida; retrieval-augmented-generation recupera evidencia para apoyar generación; context-management administra información activa; tool-use incorpora capacidades externas; ai-guardrails aplica controles de runtime; human-in-the-loop sitúa intervención humana; model-routing selecciona el destino de inferencia y semantic-caching reutiliza resultados elegibles. Son patrones componibles y pueden existir sin agentes; no forman una pila obligatoria ni se redefinen en este MOC de desarrollo.
Application Patterns V0.5 queda materializada con estos ocho canonicals. La evaluación general ahora tiene su propia rama y no anticipa infraestructura, monitoring, observability, seguridad o economía.
Camino de aprendizaje y continuidad
Como propuesta editorial del Atlas: modelo/LLM → Agents → Coding Assistants y Coding Agent → contexto e instrucciones → harness, herramientas y skills → workflows → verificación y evaluación, con seguridad y economía como preocupaciones transversales. Es una ruta de orientación, no una jerarquía universal de prerrequisitos ni promesa de completar todos los temas en ese orden.
La progresión editorial disponible recorre fundamentos → colaboración humano-agente → composición determinista/probabilística → contexto e instrucciones → artefactos de desarrollo → Coding-Agent Workflows → verificación y evaluación general, con Agent Evaluation como especialización de sistemas agentes y Agentic Systems como soporte. Long-Horizon Development Tasks permanece agrupado en Coding Agent; AI-Native Software Development es un encuadre editorial volátil dentro de Deterministic and Probabilistic Development Workflows. Seguridad, economía, monitoring y observability mantienen sus alcances futuros, como texto plano y sin enlaces rotos ni materialización anticipada.