Los AI coding agents se están volviendo rápidos.

Pueden buscar en tu repo, editar archivos, correr tests, abrir pull requests y explicar un diff. En el último año empezaron a sentirse menos como autocomplete y más como junior engineers que realmente pueden tocar el codebase.

Eso cambia el modo de fallo.

El fallo antiguo era: el modelo escribe mal código.

El nuevo fallo es más sutil:

El agente escribe código razonable por una razón histórica equivocada.

Ve el código actual, la tarea, una implementación a medio terminar, un TODO, un endpoint viejo que aún funciona o un middleware legacy que parece removible.

Entonces cambia el código.

Y a veces esa es exactamente la acción incorrecta.

No porque el agente no entendiera el código, sino porque el código no contenía la razón.

El código dice qué existe. Rara vez dice por qué.

La mayoría de errores en codebases maduros no nacen de ignorar sintaxis.

Nacen de contexto perdido:

  • Este enfoque se intentó y fue abandonado.
  • Esta implementación fue superada por una decisión posterior.
  • Este fallback feo aún es requerido por un cliente.
  • Este endpoint está deprecated pero sigue recibiendo tráfico de un mobile client.
  • Este módulo parece no usado, pero se carga dinámicamente.
  • Esta migración se pausó porque el intento anterior causó pérdida de datos.
  • Esta restricción vive en la cabeza de un reviewer, un hilo de Slack o un comentario viejo de PR.

Los humanos aprenden estas cosas lentamente.

Pasamos por design reviews. Recordamos el incidente. Preguntamos a quién lo construyó. Leemos el comentario enojado de hace seis meses. Sabemos que el directorio legacy no es realmente legacy.

Los agentes no.

Un coding agent normalmente entra al repo con una tarea y una ventana de contexto. Puede inspeccionar el estado actual del código. Puede hacer grep, indexar, recuperar y razonar. Pero el estado actual del código no es lo mismo que la historia de decisiones que lo produjo.

Esa capa faltante se está volviendo un problema.

La trampa Redis

Imagina un repo con una cola Redis parcialmente implementada.

Hay un archivo redis.go, hay TODOs y docker-compose.yml define Redis. La implementación parece 60% hecha.

El usuario le pide al agente:

Finish the async billing event pipeline.

Un agente code-first ve la ruta Redis y hace lo obvio: termina la implementación Redis.

Suena razonable.

Pero quizás el equipo ya probó Redis hace tres semanas. Quizás fue abandonado porque replication lag causó billing events duplicados. Quizás la decisión correcta fue moverse a Postgres advisory locks. Quizás los archivos Redis quedaron en el repo porque la migración fue interrumpida.

El código no revela eso.

La respuesta correcta depende de intent abandonado, no de la implementación actual.

Ese es el tipo de problema donde los coding agents fallan hoy.

No es “escribe una función”, “arregla un type error” o “encuentra donde está definido este símbolo”.

El problema duro es:

Debe hacerse este cambio, dado lo que el equipo ya aprendió?

Los artifacts existentes no alcanzan

Los equipos ya tienen lugares donde aparece intent: commit messages, PR descriptions, issues, design docs, Slack, comments, ADRs, session transcripts y branch names.

Todos ayudan. Ninguno es la capa de memoria duradera que un agente necesita antes de editar código.

Commit messages son cortos y orientados al estado final.

PR descriptions están escritas para review, no para recuperación futura. Es fácil saltarlas, reescribirlas, squasharlas o perderlas en un tab cerrado.

Issues describen trabajo pendiente, pero no siempre las decisiones tomadas durante el camino.

Slack tiene la verdad, pero solo si sabes que buscar, quién lo dijo y cuando.

Design docs son útiles cuando existen, pero suelen describir el plan antes de que la realidad lo contradiga.

Session recorders capturan todo. Esa es su fuerza y su debilidad. Un transcript es evidencia, no un decision record compacto.

Para agentes, la unidad de memoria no debería ser la conversación.

Deberia ser el engineering intent.

Qué debería contener la memoria del repo

Un buen record de repo memory debería responder preguntas duraderas:

  • Por qué existio este trabajo?
  • Que decisión tomó el equipo?
  • Que alternativas fueron rechazadas?
  • Que riesgos fueron aceptados?
  • Que anti-patterns deben evitar futuros agentes?
  • Que archivos o subsistemás toca?
  • Este intent fue merged, abandoned, superseded o reverted?
  • Que commits lo implementaron?

No es un diario.

No es un productivity dashboard.

No es una grabacion completa de lo que dijo o hizo el agente.

Es la parte duradera de la memoria de ingeniería: lo que debería importar la semana que viene, el mes que viene y la próxima vez que un agente toque la misma zona.

Los agentes necesitan memoria antes de editar

Muchas herramientas muestran contexto después del hecho.

Un PR description explica el diff cuando el código ya cambio. Un review comenta el resultado cuando la branch ya existe. Un session replay ayuda a inspeccionar que paso después de que el agente actuo.

El momento más valioso es anterior.

Antes de que el agente edite.

Antes de que borre el fallback, reviva el enfoque abandonado, agregue una columna al endpoint deprecated o empiece una segunda migración que choca con otra intención en curso.

El agente debería poder preguntar:

Que debo saber sobre este repo antes de tocar esta parte del código?

Ese es el primitive que falta.

Llameslo repo memory, intent memory o agent context protocol.

Lo importante es que exista antes del diff.

Por qué Git-native importa

Si la memoria del repo es importante, no debería vivir solo dentro del chat history de un proveedor.

La memoria de ingeniería del repo debe pertenecer al repo.

Eso significa que debe ser portable, inspecciónable, versionada, local-first, agent-agnostic, usable sin una cuenta SaaS y durable entre herramientas.

Git es el sustrato obvio.

Los developers ya confian en Git como system of record del código. Los equipos ya hacen fetch, push, branch, review, merge y audit con Git. Si la memoria está atada al repo, futuros agentes y humanos pueden recuperarla sin importar que coding assistant la produjo.

Esto importa porque el mercado de agentes se mueve rápido.

Hoy un equipo puede usar Cursor. Manana Claude Code. Otro puede usar Codex, Copilot, Windsurf, Devin o un agente interno.

Si la memoria vive dentro de un vendor, el repo depende de ese vendor.

Si la memoria vive en Git, el repo posee su historia.

RAG no alcanza

Code retrieval ayuda a encontrar archivos relevantes.

No dice si un enfoque fue abandonado.

Grep verifica que existe ahora.

No explica que decisión superó una implementación anterior.

Static analysis ayuda con dependencias.

No captura restricciones de reviewer, lecciones de incidentes o alternativas rechazadas.

Un buen workflow para agentes debería parecerse a esto:

read prior intent
inspect current code
make the change
record new intent

No a esto:

grep everything
guess why it exists
edit optimistically
hope review catches it

La capa faltante no es más búsqueda de código.

Es memoria de ingeniería estructurada.

Session memory tampoco alcanza

Session memory captura prompts, respuestas, tool calls, snapshots y diffs. Sirve para replay, audit, rollback y provenance.

Pero futuros agentes normalmente no necesitan la sesión completa.

Necesitan la conclusion duradera:

  • Probamos Redis y lo abandonamos.
  • Elegimos JWT sobre sessions porque mobile necesita auth stateless.
  • Mantuvimos OAuth middleware hasta que mobile v3 haga sunset.
  • CSV está deprecated; Parquet es el camino.
  • Aceptamos este riesgo de migración y agregamos un follow-up.

El transcript completo puede ser evidencia. Pero es demásiado ruidoso para ser la memoria por defecto antes de futuras ediciones.

Los agentes necesitan algo más pequeno y más intencional.

Necesitan el registro del por qué.

También cambia el review loop

Repo memory no es solo para agentes.

También cambia el review humano.

Hoy los reviewers leen un diff e infieren intent hacia atrás:

Por qué tocaron este archivo? Por qué este diseño? Sabían de la restricción vieja? Este riesgo fue intencional? Están deshaciendo una decisión del mes pasado?

Con intent memory, el review puede empezar desde el por qué:

Este PR existe para reemplazar el legacy refresh-token flow. El agente vio la decisión previa de no remover OAuth middleware. Declaró el riesgo de compatibilidad. Evitó el path Redis abandonado. Ahora revisemos la implementación contra ese intent.

Eso convierte review de “adivinar la intención del autor” a “verificar la implementación contra la intención declarada”.

Cuando los PRs generados por IA sean más comunes, esa diferencia importará.

Qué estamos construyendo

Estamos construyendo Mainline: una capa de memoria Git-native para coding agents.

Mainline registra engineering intent como records estructurados adjuntos al repo. Los agentes pueden leer decisiones previas, riesgos, anti-patterns, enfoques abandonados y decisiones superadas antes de editar. Después de trabajo significativo, escriben el nuevo intent para que el siguiente agente también tenga memoria.

El objetivo no es reemplazar Git.

No es reemplazar PRs.

No es grabar cada token de una sesión de IA.

El objetivo es más simple:

Dar a los coding agents el por qué histórico antes de cambiar lo que existe hoy.

Un loop típico debería sentirse así:

mainline context --current --json
# read relevant prior intent before non-trivial edits

mainline start "Add JWT auth"
# claim the work

mainline append "Implemented JWT middleware"
# record meaningful progress

mainline seal
# preserve the durable decision record

Los humanos no deberían memorizar ese protocolo. El agente debería correrlo.

Los humanos deberían ver principalmente el resultado: intents recientes, decisiones importantes, open risks, anti-patterns, archivos con inherited constraints, PRs sin intent y razones históricas detrás del código.

El agente escribe memoria. El repo guarda memoria. El reviewer lee memoria.

Lo que no es

Mainline no es un productivity dashboard.

No creemos que el futuro correcto sea rankear developers por cuantos intents crearon, cuantos prompts escribieron o cuanto código generado por IA enviaron.

El punto no es vigilancia.

El punto es continuidad.

Mainline tampoco reemplaza design docs, PRs, issues, RAG, grep o session history. Todo eso sigue siendo útil.

Mainline es el tejido conectivo: el engineering intent duradero que futuros agentes y humanos deberían recuperar antes de cambiar código.

Por qué ahora

Hace un ano, este problema era molesto.

Pronto sera estructural.

A medida que los coding agents sean más capaces, los equipos correran más de ellos. Trabajaran en repos más grandes, sistemás más viejos y zonas más sensibles. Abriran más PRs. Haran más cambios plausibles.

Los cambios plausibles son los peligrosos.

Un syntax error es fácil de atrapar.

Una reintroduccion plausible de un enfoque abandonado es más difícil. Remover plausiblemente una restricción legacy es más difícil. Actualizar tanto APIs deprecated como actuales es más difícil. Una migración plausible que choca con otra en curso es más difícil.

El agente no necesita más confianza.

Necesita memoria.

El repo del futuro tiene memoria

En el futuro, un repo serio no tendra solo:

README.md
CONTRIBUTING.md
AGENTS.md
.github/

También tendra una capa de memoria duradera que los agentes pueden consultar.

Antes de editar auth code, un agente debería conocer decisiones previas de auth. Antes de cambiar billing, debería conocer enfoques de billing abandonados. Antes de tocar una migración, debería conocer riesgos no resueltos. Antes de borrar algo que parece muerto, debería saber si el equipo lo mantuvo vivo a propósito.

Esa memoria debe ser abierta, portable, Git-native y propiedad del repo.

Esa es la direccion que exploramos con Mainline.

Si estas corriendo coding agents sobre un codebase real y has sentido este problema, queremos hablar.

Buscamos design partners que usen AI agents para trabajo de ingeniería no trivial y quieran que sus repos recuerden por qué se tomaron decisiones.

Mainline es para equipos que creen que los coding agents no solo deben leer código. Deben heredar memoria de ingeniería.