--- title: "Ediciones multarchivo atómicas para agentes de IA" canonical: https://wavect.io/es/blog/atomic-multi-file-edits-ai-coding-agents/ language: es description: "Lección de Semaprax sobre ediciones multarchivo atómicas: generaciones inmutables, un puntero activo, límites de fallo y checklist." image: "https://wavect.io/img/blog/headers/header_atomic-multi-file-edits-ai-coding-agents.png" --- [**Volver**](/es/blog/overview/) [![Kevin Riedl](/img/team/kevin.webp)](/es/team/kevin-riedl/) [Kevin Riedl](/es/team/kevin-riedl/) https://linkedin.com/in/wsdt 9 min de lectura · 6 sep 2026 Última revisión 6 de septiembre de 2026 [**Siguiente**](/es/blog/semantic-identity-rust-agent-edits/) # Ediciones multarchivo atómicas para agentes de programación: la lección de Semaprax Resumen Una edición multarchivo de un agente de IA no es atómica solo porque cada archivo se reemplace de forma atómica o el resultado termine en un commit de Git. Un lector aún puede observar una mezcla mientras los archivos cambian uno a uno. Durante el desarrollo de Semaprax abordamos ese problema acotado con generaciones de código inmutables y un puntero ACTIVE autenticado: validar toda la propuesta, construir y verificar el candidato completo y cambiar el puntero una vez. Los lectores cooperantes ven el snapshot gestionado antiguo o el nuevo. El protocolo no vuelve atómicos los archivos sin gestionar, Git, los editores, los sistemas de archivos de red ni la recuperación ante pérdida de energía. Los equipos deben preguntar qué lectores están protegidos, dónde reside la autoridad de commit, cómo fallan las propuestas obsoletas y qué ocurre antes y después del punto de publicación. **Cuando un agente de programación cambia varios archivos dependientes, no basta con reemplazar cada archivo de forma segura. El proyecto necesita un único límite de publicación.** Sin él, un proceso de build, un servidor de lenguaje, un watcher de pruebas u otro agente puede leer parte del programa antiguo y parte del nuevo. Nos encontramos con este problema al desarrollar [Semaprax](/es/semaprax/), nuestro lenguaje de sistemas experimental orientado a agentes. La lección sirve más allá del lenguaje: prepara una generación inmutable completa, verifícala y después cambia un pequeño puntero activo. Este artículo explica el patrón, sus límites y las preguntas que un comprador técnico debería hacer antes de confiar en cualquier promesa de ediciones “atómicas”. ## ¿Qué es una edición multarchivo atómica? **Una edición multarchivo atómica hace visible a sus lectores definidos un estado antiguo completo o un estado nuevo completo, nunca una mezcla intermedia.** La frase queda incompleta hasta que el sistema identifica a esos lectores, los archivos incluidos, el punto de commit y el modelo de fallo. Imagina un cambio que renombra una función exportada y actualiza su llamada en otro archivo. Si cambia primero la definición, un watcher puede ver la llamada antigua junto a la definición nueva. Si cambia primero la llamada, observa la inconsistencia contraria. Ambos archivos pueden contener texto válido y, aun así, el programa combinado ser inválido durante ese instante. ## La lección: publicar generaciones, no una secuencia de escrituras Semaprax necesitaba una forma acotada de publicar cambios verificados en varios archivos fuente. Su decisión de arquitectura descarta el reemplazo secuencial porque un lector puede observar una generación mixta. El diseño elegido conserva generaciones completas e inmutables y selecciona una mediante un único registro `ACTIVE`. La [decisión de arquitectura de Semaprax fijada a una revisión](https://github.com/wavect/semaprax/blob/942ed70388e2b40f4ee98ea5dd5e0c193fa98f4d/docs/decisions/0002-managed-workspace-generations.md) documenta la solución y las alternativas rechazadas. ``` .semaprax-workspace/ ACTIVE generations/ / / ``` La ruta de escritura tiene cinco fases distintas: 1. **Vincular la propuesta a una revisión base.** Si el workspace seleccionado cambió, la operación se rechaza. 2. **Validar cada archivo afectado.** Todas las operaciones se resuelven contra la misma base autenticada. 3. **Construir el candidato completo por separado.** También incluye los archivos sin cambios para formar una generación íntegra. 4. **Verificar el candidato completo.** Se comprueban formatos, identidades, límites, digests y las invariantes que el protocolo afirma. 5. **Cambiar un único puntero.** Tras las comprobaciones finales solo se reemplaza `ACTIVE`. Un lector cooperante resuelve el puntero y lee una generación inmutable. ## ¿Por qué no basta con renombrar un archivo de forma atómica? Escribir un archivo temporal y renombrarlo sobre el destino es un patrón valioso para un solo archivo. Rust documenta `std::fs::rename` como una operación de renombrado y describe diferencias por plataforma y fallos entre puntos de montaje. La API no ofrece una transacción portable sobre un conjunto arbitrario de rutas. Consulta el [contrato de rename de la biblioteca estándar de Rust](https://doc.rust-lang.org/std/fs/fn.rename.html). Repetir la operación para cinco archivos crea cinco momentos de publicación. Si un lector actúa entre el segundo y el tercero, el programa sigue expuesto como mezcla. La atomicidad por archivo no se convierte automáticamente en atomicidad de proyecto. ## ¿Git no hace ya atómicos los cambios multarchivo? **Un commit de Git identifica un árbol completo, pero no convierte cada transición del working tree vivo en una operación atómica para editores, watchers u otros procesos.** Publicar el historial del repositorio no es lo mismo que cambiar los archivos que leen herramientas activas. Git muestra la importancia de definir bien el límite. `git update-ref` puede verificar un object ID anterior y agrupar cambios de referencias en una transacción. Su documentación también advierte que un lector concurrente puede ver solo parte de varias modificaciones de referencias, aunque cada referencia se actualice de forma atómica. La [documentación oficial de Git sobre update-ref](https://git-scm.com/docs/git-update-ref) es un buen modelo para versiones esperadas y estados transaccionales explícitos. Usa ramas, worktrees y commits para colaboración, revisión y recuperación. Añade una capa de publicación gestionada solo cuando los consumidores en ejecución deban observar un snapshot coherente durante el cambio. ## Por qué las generaciones inmutables son un patrón práctico Las generaciones inmutables trasladan la mayor parte del riesgo antes del punto de commit. Un candidato puede construirse, inspeccionarse y rechazarse sin modificar el estado seleccionado. La operación final es pequeña porque cambia un puntero, no todos los archivos de carga. El patrón no es exclusivo de herramientas para agentes. Nix explica las actualizaciones atómicas de forma similar: los paquetes no se sobrescriben y un perfil pasa a una nueva generación, lo que evita una ventana con archivos antiguos y nuevos mezclados. La [guía oficial de arquitectura de Nix](https://nixos.org/guides/how-nix-works/) aporta un ejemplo maduro del patrón. La parte específica de los agentes es la evidencia. Una respuesta convincente del modelo no debería tener autoridad de commit. El sistema debe conservar la revisión base, las operaciones propuestas, el digest candidato, los resultados de validación y el resultado del cambio de puntero para que otro componente pueda comprobarlo. ## Qué implementa realmente Semaprax y qué no En el commit auditado, Semaprax define una transacción acotada para entre 2 y 16 archivos `.spx` gestionados. Los escritores toman un bloqueo exclusivo, construyen o autentican una generación candidata completa, ejecutan comprobaciones finales y reemplazan `ACTIVE`. Los lectores cooperantes toman un bloqueo compartido y resuelven la generación inmutable seleccionada. La [especificación fijada de la transacción de workspace](https://github.com/wavect/semaprax/blob/942ed70388e2b40f4ee98ea5dd5e0c193fa98f4d/docs/SEMANTIC-WORKSPACE-TRANSACTION-V1.md) define formato, límites, diagnósticos, evidencia y exclusiones. El límite importa más que el titular. El protocolo no vuelve atómicos los archivos fuente sin gestionar, Git, los editores ni los lectores no cooperantes. No promete comportamiento en sistemas de archivos de red, durabilidad ante pérdida de energía, rollback automático, semántica general del repositorio ni reparación multarchivo arbitraria. Semaprax sigue siendo investigación prealfa y este artículo no convierte evidencia acotada en una afirmación de madurez productiva. ## Construir o comprar: ocho preguntas para proveedores 1. **¿Qué lectores están protegidos?** Pregunta si la garantía cubre solo la API o también working tree, servidores de lenguaje, builds y procesos externos. 2. **¿Cuál es la revisión base?** Toda propuesta necesita una versión esperada y un rechazo claro cuando queda obsoleta. 3. **¿Dónde está el punto de commit?** “Usamos archivos temporales” no responde a la pregunta multarchivo. 4. **¿Se valida el candidato completo?** Las comprobaciones de sintaxis por archivo no detectan todas las roturas entre archivos. 5. **¿Quién tiene autoridad de escritura?** El output del modelo, la evidencia y los tokens de aprobación no deben convertirse en poder de commit reutilizable. 6. **¿Qué sucede antes y después del cambio?** El rechazo previo y la ambigüedad posterior necesitan recuperaciones distintas. 7. **¿Qué durabilidad se ha probado?** Caída del proceso, del sistema operativo, pérdida de energía y almacenamiento de red son fallos diferentes. 8. **¿La evidencia es reproducible?** Pide pruebas hostiles, fixtures fijos, límites y versiones exactas, no solo una demo. ## ¿Cuándo necesitas esta arquitectura? Probablemente no necesitas un protocolo de generaciones para un agente que propone un parche, se detiene y espera la revisión humana de un diff normal de Git. Considéralo cuando el trabajo autónomo modifica varios archivos acoplados mientras builds, servicios u otros agentes leen continuamente el workspace y un estado mixto puede activar un despliegue, generación de código, migración o acción irreversible. Empieza una capa antes si el agente no puede identificar las entidades correctas. Nuestra [nota de Semaprax sobre identidad semántica](/es/blog/semantic-identity-rust-agent-edits/) explica los IDs estables y los parches ligados a revisiones. La [guía de harnesses para agentes de IA](/es/blog/agent-harness-engineering/) sitúa la publicación dentro del sistema de contexto, políticas, herramientas, verificación y observabilidad. ## Preguntas frecuentes ### ¿Los commits de Git son atómicos? Un commit identifica un árbol completo. Eso no garantiza que los lectores activos de un directorio cambiante nunca observen estados intermedios. ### ¿Escribir atómicamente equivale a tener rollback? No. La publicación atómica define qué se hace visible en el punto de cambio. Rollback, limpieza y recuperación tras un fallo son contratos separados. ### ¿Las generaciones inmutables evitan conflictos de merge? No. Controlan la visibilidad para lectores cooperantes. La coordinación de ramas, los conflictos semánticos y la revisión humana siguen aparte. *Nota editorial: OpenAI Codex ayudó con la investigación, la redacción y la traducción. Wavect comprobó las afirmaciones técnicas el 6 de septiembre de 2026 contra el commit `942ed70` de Semaprax y la documentación primaria enlazada. No se infieren afirmaciones de rendimiento ni de madurez productiva a partir del output del modelo.* ## Reflexiones finales La palabra más importante en una promesa de edición atómica no es atómica, sino alcance. Un diseño seguro dice quién lee, a qué versión se vincula la propuesta, qué estado se verifica y dónde ocurre la publicación. Semaprax nos enseñó a no confundir varias escrituras seguras con un cambio de programa seguro. Construye primero la generación completa, verifícala y cambia después un puntero. Documenta las exclusiones con la misma claridad que el camino feliz. ## También te puede gustar.. [**Por qué las ediciones de agentes necesitan identidad semántica** Cómo los IDs estables y los parches ligados a revisiones limitan la edición antes de publicarla.](/es/blog/semantic-identity-rust-agent-edits/) [**AI Enablement frente a consultoría genérica** Compara la ingeniería práctica de agentes con un proyecto centrado solo en estrategia.](/es/compare/ai-enablement-vs-generic-ai-consultancy/) Ingeniería de agentes ## Continúa por este clúster Agentes de código, MCP, contexto, evaluación y controles para automatización fiable. [Empieza por el artículo fundamental**Ingeniería de grafos para agentes de IA: ¿Cuándo compensa un knowledge graph?**](/es/blog/graph-engineering-ai-agents/) - [Transferencia de conocimiento entre agentes de IA: descubre una vez y escala por menos](/es/blog/agent-knowledge-transfer-cheaper-models/) - [claude-rotate: Un proxy para varias cuentas Claude Max](/es/blog/claude-rotate-multi-account-proxy/) - [Feynman: análisis del agente de investigación IA open source](/es/blog/feynman-open-source-ai-research-agent/) - [Obscura Browser: análisis, límites y uso en producción](/es/blog/obscura-rust-browser-ai-agents/) - [Sistema de diseño para Claude Code: 4 piezas para una UI de marca](/es/blog/claude-code-design-system-files/) [**Volver**](/es/blog/overview/) [![Kevin Riedl](/img/team/kevin.webp)](/es/team/kevin-riedl/) [Kevin Riedl](/es/team/kevin-riedl/) https://linkedin.com/in/wsdt 9 min de lectura · 6 sep 2026 Última revisión 6 de septiembre de 2026 [**Siguiente**](/es/blog/semantic-identity-rust-agent-edits/) ## Structured Data ```json { "@context": "https://schema.org", "@graph": [ { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ], "employee": [ { "@id": "https://wavect.io/team/kevin-riedl/#person", "@type": "Person", "jobTitle": "Managing Director", "name": "Kevin Riedl", "url": "https://wavect.io/team/kevin-riedl/", "worksFor": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] } }, { "@id": "https://wavect.io/team/christof-jori/#person", "@type": "Person", "jobTitle": "Managing Director", "name": "Christof Jori", "url": "https://wavect.io/team/christof-jori/", "worksFor": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] } } ], "founder": [ { "@id": "https://wavect.io/team/kevin-riedl/#person", "@type": "Person", "jobTitle": "Managing Director", "name": "Kevin Riedl", "url": "https://wavect.io/team/kevin-riedl/", "worksFor": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] } }, { "@id": "https://wavect.io/team/christof-jori/#person", "@type": "Person", "jobTitle": "Managing Director", "name": "Christof Jori", "url": "https://wavect.io/team/christof-jori/", "worksFor": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] } } ], "legalRepresentative": [ { "@id": "https://wavect.io/team/kevin-riedl/#person", "@type": "Person", "jobTitle": "Managing Director", "name": "Kevin Riedl", "url": "https://wavect.io/team/kevin-riedl/", "worksFor": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] } }, { "@id": "https://wavect.io/team/christof-jori/#person", "@type": "Person", "jobTitle": "Managing Director", "name": "Christof Jori", "url": "https://wavect.io/team/christof-jori/", "worksFor": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] } } ], "name": "Wavect GmbH", "subjectOf": { "@id": "https://wavect.io/verified-claims.json#dataset", "@type": "Dataset", "creator": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] }, "description": "A machine-readable registry of quantitative and qualitative claims published by Wavect, with review dates, localized page appearances and public third-party citations where available.", "inLanguage": "en", "isAccessibleForFree": true, "license": "https://creativecommons.org/licenses/by/4.0/", "name": "Wavect verified publication claims", "url": "https://wavect.io/verified-claims.json" }, "url": "https://wavect.io/" }, { "@id": "https://wavect.io/team/kevin-riedl/#person", "@type": "Person", "jobTitle": "Managing Director", "name": "Kevin Riedl", "sameAs": [ "https://www.wikidata.org/wiki/Q139796365", "https://www.linkedin.com/in/wsdt", "https://github.com/wsdt" ], "url": "https://wavect.io/team/kevin-riedl/", "worksFor": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] } }, { "@id": "https://wavect.io/team/christof-jori/#person", "@type": "Person", "jobTitle": "Managing Director", "name": "Christof Jori", "sameAs": [ "https://www.wikidata.org/wiki/Q139796367", "https://www.linkedin.com/in/jocr77/", "https://github.com/jo-chris" ], "url": "https://wavect.io/team/christof-jori/", "worksFor": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] } }, { "@id": "https://wavect.io/#website", "@type": "WebSite", "inLanguage": [ "en", "de", "es", "zh" ], "name": "Wavect", "potentialAction": { "@type": "SearchAction", "query-input": "required name=search_term_string", "target": { "@type": "EntryPoint", "urlTemplate": "https://wavect.io/search/?q={search_term_string}" } }, "publisher": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] }, "url": "https://wavect.io/" }, { "@id": "https://wavect.io/es/blog/atomic-multi-file-edits-ai-coding-agents/#webpage", "@type": "WebPage", "dateModified": "2026-09-06", "inLanguage": "es", "isPartOf": { "@id": "https://wavect.io/#website", "@type": "WebSite" }, "lastReviewed": "2026-09-06", "url": "https://wavect.io/es/blog/atomic-multi-file-edits-ai-coding-agents/" } ] } ``` ```json { "@context": "https://schema.org", "@type": "BlogPosting", "abstract": "Una edición multarchivo de un agente de IA no es atómica solo porque cada archivo se reemplace de forma atómica o el resultado termine en un commit de Git. Un lector aún puede observar una mezcla mientras los archivos cambian uno a uno. Durante el desarrollo de Semaprax abordamos ese problema acotado con generaciones de código inmutables y un puntero ACTIVE autenticado: validar toda la propuesta, construir y verificar el candidato completo y cambiar el puntero una vez. Los lectores cooperantes ven el snapshot gestionado antiguo o el nuevo. El protocolo no vuelve atómicos los archivos sin gestionar, Git, los editores, los sistemas de archivos de red ni la recuperación ante pérdida de energía. Los equipos deben preguntar qué lectores están protegidos, dónde reside la autoridad de commit, cómo fallan las propuestas obsoletas y qué ocurre antes y después del punto de publicación.", "articleBody": " Resumen del blog/IA y agentes/Ingeniería de agentes Ediciones multarchivo atómicas para agentes de programación: la lección de Semaprax Resumen Una edición multarchivo de un agente de IA no es atómica solo porque cada archivo se reemplace de forma atómica o el resultado termine en un commit de Git. Un lector aún puede observar una mezcla mientras los archivos cambian uno a uno. Durante el desarrollo de Semaprax abordamos ese problema acotado con generaciones de código inmutables y un puntero ACTIVE autenticado: validar toda la propuesta, construir y verificar el candidato completo y cambiar el puntero una vez. Los lectores cooperantes ven el snapshot gestionado antiguo o el nuevo. El protocolo no vuelve atómicos los archivos sin gestionar, Git, los editores, los sistemas de archivos de red ni la recuperación ante pérdida de energía. Los equipos deben preguntar qué lectores están protegidos, dónde reside la autoridad de commit, cómo fallan las propuestas obsoletas y qué ocurre antes y después del punto de publicación. Cuando un agente de programación cambia varios archivos dependientes, no basta con reemplazar cada archivo de forma segura. El proyecto necesita un único límite de publicación. Sin él, un proceso de build, un servidor de lenguaje, un watcher de pruebas u otro agente puede leer parte del programa antiguo y parte del nuevo. Nos encontramos con este problema al desarrollar Semaprax, nuestro lenguaje de sistemas experimental orientado a agentes. La lección sirve más allá del lenguaje: prepara una generación inmutable completa, verifícala y después cambia un pequeño puntero activo. Este artículo explica el patrón, sus límites y las preguntas que un comprador técnico debería hacer antes de confiar en cualquier promesa de ediciones “atómicas”. ¿Qué es una edición multarchivo atómica? Una edición multarchivo atómica hace visible a sus lectores definidos un estado antiguo completo o un estado nuevo completo, nunca una mezcla intermedia. La frase queda incompleta hasta que el sistema identifica a esos lectores, los archivos incluidos, el punto de commit y el modelo de fallo. Imagina un cambio que renombra una función exportada y actualiza su llamada en otro archivo. Si cambia primero la definición, un watcher puede ver la llamada antigua junto a la definición nueva. Si cambia primero la llamada, observa la inconsistencia contraria. Ambos archivos pueden contener texto válido y, aun así, el programa combinado ser inválido durante ese instante. La lección: publicar generaciones, no una secuencia de escrituras Semaprax necesitaba una forma acotada de publicar cambios verificados en varios archivos fuente. Su decisión de arquitectura descarta el reemplazo secuencial porque un lector puede observar una generación mixta. El diseño elegido conserva generaciones completas e inmutables y selecciona una mediante un único registro ACTIVE. La decisión de arquitectura de Semaprax fijada a una revisión documenta la solución y las alternativas rechazadas. .semaprax-workspace/ ACTIVE generations/ / / La ruta de escritura tiene cinco fases distintas: Vincular la propuesta a una revisión base. Si el workspace seleccionado cambió, la operación se rechaza. Validar cada archivo afectado. Todas las operaciones se resuelven contra la misma base autenticada. Construir el candidato completo por separado. También incluye los archivos sin cambios para formar una generación íntegra. Verificar el candidato completo. Se comprueban formatos, identidades, límites, digests y las invariantes que el protocolo afirma. Cambiar un único puntero. Tras las comprobaciones finales solo se reemplaza ACTIVE. Un lector cooperante resuelve el puntero y lee una generación inmutable. ¿Por qué no basta con renombrar un archivo de forma atómica? Escribir un archivo temporal y renombrarlo sobre el destino es un patrón valioso para un solo archivo. Rust documenta std::fs::rename como una operación de renombrado y describe diferencias por plataforma y fallos entre puntos de montaje. La API no ofrece una transacción portable sobre un conjunto arbitrario de rutas. Consulta el contrato de rename de la biblioteca estándar de Rust. Repetir la operación para cinco archivos crea cinco momentos de publicación. Si un lector actúa entre el segundo y el tercero, el programa sigue expuesto como mezcla. La atomicidad por archivo no se convierte automáticamente en atomicidad de proyecto. ¿Git no hace ya atómicos los cambios multarchivo? Un commit de Git identifica un árbol completo, pero no convierte cada transición del working tree vivo en una operación atómica para editores, watchers u otros procesos. Publicar el historial del repositorio no es lo mismo que cambiar los archivos que leen herramientas activas. Git muestra la importancia de definir bien el límite. git update-ref puede verificar un object ID anterior y agrupar cambios de referencias en una transacción. Su documentación también advierte que un lector concurrente puede", "articleSection": "Ingeniería", "author": { "@id": "https://wavect.io/team/kevin-riedl/#person", "@type": "Person", "name": "Kevin Riedl", "sameAs": [ "https://www.wikidata.org/wiki/Q139796365", "https://www.linkedin.com/in/wsdt", "https://github.com/wsdt" ], "url": "https://wavect.io/team/kevin-riedl/" }, "citation": [ { "@type": "WebPage", "name": "decisión de arquitectura de Semaprax fijada a una revisión", "url": "https://github.com/wavect/semaprax/blob/942ed70388e2b40f4ee98ea5dd5e0c193fa98f4d/docs/decisions/0002-managed-workspace-generations.md" }, { "@type": "WebPage", "name": "contrato de rename de la biblioteca estándar de Rust", "url": "https://doc.rust-lang.org/std/fs/fn.rename.html" }, { "@type": "WebPage", "name": "documentación oficial de Git sobre update-ref", "url": "https://git-scm.com/docs/git-update-ref" }, { "@type": "WebPage", "name": "guía oficial de arquitectura de Nix", "url": "https://nixos.org/guides/how-nix-works/" }, { "@type": "WebPage", "name": "especificación fijada de la transacción de workspace", "url": "https://github.com/wavect/semaprax/blob/942ed70388e2b40f4ee98ea5dd5e0c193fa98f4d/docs/SEMANTIC-WORKSPACE-TRANSACTION-V1.md" } ], "dateModified": "2026-09-06", "datePublished": "2026-09-06", "description": "Una edición multarchivo de un agente de IA no es atómica solo porque cada archivo se reemplace de forma atómica o el resultado termine en un commit de Git. Un lector aún puede observar una mezcla mientras los archivos cambian uno a uno. Durante el desarrollo de Semaprax abordamos ese problema acotado con generaciones de código inmutables y un puntero ACTIVE autenticado: validar toda la propuesta, construir y verificar el candidato completo y cambiar el puntero una vez. Los lectores cooperantes ven el snapshot gestionado antiguo o el nuevo. El protocolo no vuelve atómicos los archivos sin gestionar, Git, los editores, los sistemas de archivos de red ni la recuperación ante pérdida de energía. Los equipos deben preguntar qué lectores están protegidos, dónde reside la autoridad de commit, cómo fallan las propuestas obsoletas y qué ocurre antes y después del punto de publicación.", "headline": "Ediciones multarchivo atómicas para agentes de programación: la lección de Semaprax", "image": "https://wavect.io/img/blog/headers/header_atomic-multi-file-edits-ai-coding-agents.svg", "inLanguage": "es", "keywords": "Agentes de programación, Arquitectura de software", "mainEntityOfPage": { "@id": "https://wavect.io/es/blog/atomic-multi-file-edits-ai-coding-agents/", "@type": "WebPage" }, "publisher": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] }, "url": "https://wavect.io/es/blog/atomic-multi-file-edits-ai-coding-agents/", "wordCount": 1905 } ``` ```json { "@context": "https://schema.org", "@type": "BreadcrumbList", "itemListElement": [ { "@type": "ListItem", "item": "https://wavect.io/es/", "name": "Inicio", "position": 1 }, { "@type": "ListItem", "item": "https://wavect.io/es/blog/overview/", "name": "Resumen del blog", "position": 2 }, { "@type": "ListItem", "item": "https://wavect.io/es/blog/topics/ai-agents/", "name": "IA y agentes", "position": 3 }, { "@type": "ListItem", "item": "https://wavect.io/es/blog/clusters/agent-engineering/", "name": "Ingeniería de agentes", "position": 4 }, { "@type": "ListItem", "item": "https://wavect.io/es/blog/atomic-multi-file-edits-ai-coding-agents/", "name": "Ediciones multarchivo atómicas para agentes de IA", "position": 5 } ] } ```