Abre un repositorio seis meses después de que se haya lanzado una funcionalidad y podrás reconstruir muchas cosas. Puedes seguir la arquitectura, inspeccionar el esquema, leer las pruebas y ver exactamente qué líneas cambiaron.
Lo que normalmente no puedes reconstruir es la conversación que hizo necesarias esas líneas.
El código no te dirá que existe una regla de validación porque un cliente envía exportaciones mal formadas. No explicará que una política de reintentos extraña evita transacciones duplicadas en un sistema aguas abajo. No mostrará que la interfaz más limpia fue rechazada tras una prueba de accesibilidad, ni que un límite entre servicios refleja una restricción contractual más que una preferencia de ingeniería.
Git es excelente para preservar el historial del código. Solo preserva la intención cuando un equipo la documenta deliberadamente y la mantiene conectada con la implementación.
Esa brecha siempre ha formado parte de la ingeniería de software. Las herramientas de programación con IA la hacen más visible. Un sistema puede leer todos los archivos de un repositorio, seguir cada símbolo y generar un parche técnicamente convincente y aun así resolver el problema equivocado.
El problema no es que el código sea engañoso. El código está respondiendo a una pregunta más acotada.
Cinco capas de verdad en ingeniería
La mayoría de los cambios de software que importan dependen de cinco capas distintas de evidencia.
- Intención — ¿Qué resultado está pidiendo el usuario, el cliente o el negocio? Esto puede estar en una especificación, un ticket, una conversación de soporte o una nota de reunión.
- Restricciones — ¿Qué no debe romperse? Las promesas de compatibilidad, los límites de seguridad, las regulaciones, los contratos, los presupuestos y los plazos suelen estar fuera del repositorio.
- Implementación — ¿Cómo funciona hoy el sistema? El código, las pruebas, los esquemas, las dependencias y la configuración de despliegue aportan esta capa.
- Evidencia en tiempo de ejecución — ¿Qué está ocurriendo en el sistema real? Los logs, las trazas, las métricas, los datos de producción y los informes de incidentes pueden contradecir supuestos que en el código parecen razonables.
- Historial de decisiones — ¿Por qué se eligió el enfoque actual? Las pull requests, las discusiones de diseño, las alternativas descartadas y los incidentes anteriores contienen la respuesta.
El repositorio es más sólido en la tercera capa. Contiene partes de las demás, pero rara vez lo suficiente como para representarlas por completo.
Esto importa porque los fallos de software suelen aparecer en los límites entre capas. La implementación coincide con una especificación desactualizada. La corrección satisface el ticket pero viola una restricción operativa. Las pruebas pasan porque codifican los supuestos de ayer. El código es internamente coherente mientras los datos de producción siguen un patrón que nadie documentó.
Un parche correcto a nivel local puede seguir siendo el cambio equivocado.
Lo que el repositorio no puede responder por sí solo
Pensemos en un usuario que edita un documento y luego busca la frase actualizada, pero en los resultados sigue viendo la versión anterior. «Hacer que la búsqueda se actualice de inmediato» suena como una petición clara. El repositorio revela varios puntos posibles por donde empezar, pero no puede definir por sí solo cuál es la corrección adecuada.
| Pregunta | Fuente probable |
|---|---|
| ¿Qué versión del documento es la autoritativa? | Documento fuente e historial de revisiones |
| ¿Dónde permanece el texto antiguo? | Registros de sincronización, salida de extracción, índice de búsqueda o caché |
| ¿Qué significa «de inmediato» para este producto? | Promesa del producto u objetivo de servicio |
| ¿Cambiaron los permisos del documento junto con su contenido? | Permisos de origen e historial de auditoría |
| ¿El resultado desactualizado se limita a un usuario, fuente o región? | Trazas de solicitudes y métricas de producción |
El código de búsqueda puede explicar cómo se devuelven los resultados. No puede decirte si el defecto real es un retraso de sincronización, una extracción desactualizada, una invalidación de caché, una propagación de permisos o una expectativa que el producto nunca definió.
Esta distinción se vuelve aún más importante en sistemas maduros. Un campo que parece obsoleto puede seguir dando soporte a un cliente heredado. Un servicio que parece duplicado puede estar separando datos con requisitos de permisos distintos. Una comprobación aparentemente excesiva puede ser la única huella a nivel de código de un incidente en producción que el equipo actual nunca vio.
Eliminar complejidad tiene valor. Eliminar historia disfrazada de complejidad sale caro.
Más contexto también puede producir la respuesta equivocada
La solución obvia es darle a la IA más material: todo el repositorio, todos los tickets, todos los documentos, todos los mensajes y todos los registros.
Eso crea acceso, no comprensión.
Las fuentes pueden estar desactualizadas, ser contradictorias, especulativas o estar escritas para audiencias distintas. Una lluvia de ideas no debería tener más peso que una especificación aprobada. Un requisito de hace seis meses no debería anular en silencio la decisión de producto de ayer. Un registro de producción debería estar vinculado a la versión, el entorno y la ruta de código que lo generaron. Una solicitud de un cliente no debería tratarse como un requisito universal sin comprobar antes su alcance.
Por eso, un sistema de contexto serio necesita algo más que recuperación. Necesita una forma de razonar sobre:
- Autoridad: ¿Qué fuente está autorizada para definir el requisito?
- Vigencia: ¿Qué información está actualizada y qué ha sido reemplazado?
- Procedencia: ¿De dónde proviene cada afirmación, restricción o conclusión?
- Relaciones: ¿Qué incidencia, versión, cliente, conjunto de datos y ruta de código pertenecen al mismo contexto?
- Permisos: ¿Qué fuentes pueden usarse para esta tarea y mostrarse a esta persona?
El contexto no es un montón de tokens. Es un grafo con tiempo, autoridad y límites.
Más contexto debería producir más evidencia, no más confianza sin evidencia.
La verdadera unidad de trabajo es el cambio
Los editores y las herramientas de programación se organizan en torno a archivos porque los archivos son lo que modificamos. Los equipos de ingeniería se organizan en torno a cambios.
Un cambio empieza con un motivo. Se convierte en un requisito, toca código y datos, pasa por revisión, llega a producción y genera nueva evidencia. Si esas etapas permanecen desconectadas, cada tarea futura empieza con otra ronda de arqueología.
Un sistema de IA que trabaje sobre software real debería seguir ese ciclo de vida.
Antes de la implementación, debería identificar la solicitud, las restricciones relevantes y cualquier fuente en conflicto. Debería saber si está corrigiendo un defecto, cambiando un comportamiento esperado o introduciendo un nuevo contrato.
Durante la implementación, debería conectar cada decisión significativa con evidencia. ¿Por qué este módulo? ¿Por qué esta estrategia de migración? ¿Por qué conservar esta rama? La explicación debería sobrevivir más allá del chat que produjo el código.
Después de la implementación, debería adjuntar al cambio los resultados de la verificación, las decisiones de revisión y las nuevas restricciones descubiertas. De lo contrario, la siguiente persona —o la siguiente sesión de IA— tendrá que redescubrirlas.
Esta es la diferencia entre una herramienta que puede editar un repositorio y un sistema que puede participar en el trabajo de ingeniería.
La IA debería reducir la reconstrucción, no eliminar el criterio
A veces se presenta un mejor contexto como una vía hacia el desarrollo autónomo de software. El valor inmediato es menos dramático y más útil: reducir el coste de reconstruir la realidad antes de hacer un cambio.
La IA puede situar el requisito original junto al código pertinente. Puede sacar a la luz el incidente que explica una salvaguarda inusual. Puede vincular una métrica que falla con la versión que la cambió. Puede mostrar que dos fuentes autorizadas discrepan antes de que empiece la implementación.
Esas capacidades no eliminan el criterio de ingeniería. Hacen que ese criterio esté mejor informado.
Una persona todavía tiene que decidir qué compensación es aceptable, si un requisito está completo y cuánto riesgo puede asumir una versión. El sistema debería hacer visible la evidencia y permitir inspeccionar el razonamiento. No debería ocultar la incertidumbre detrás de un parche pulido.
El criterio no es «¿puede generar código?»
El criterio es «¿puede explicar por qué este es el cambio correcto ahora?»
De la conciencia del repositorio a la conciencia del trabajo
Los asistentes de programación empezaron a ser útiles al comprender el archivo que el desarrollador tenía delante. La conciencia del repositorio fue el siguiente gran paso: encontrar código relacionado, seguir símbolos y aplicar cambios en todo un proyecto.
El siguiente paso es la conciencia del trabajo que rodea al repositorio.
Eso significa conectar el código con la especificación que lo solicitó, la conversación que lo aclaró, la evidencia de producción que lo puso en cuestión y la decisión que debería recordarse después. También significa excluir el contexto que sea irrelevante, esté desactualizado o quede fuera de los permisos del usuario.
Mientras construimos Dvina, esta es una de las ideas a las que volvemos una y otra vez. El trabajo no ocurre dentro de un solo archivo, aplicación o conversación. El significado vive en las conexiones entre ellos y en cómo esas conexiones cambian con el tiempo.
El repositorio sigue siendo esencial. Es la fuente de verdad ejecutable sobre el comportamiento del sistema. Simplemente no es la fuente de verdad completa de la intención del producto, la realidad operativa ni la memoria organizativa.
La historia completa cambia lo que se construye
Con solo el código, la pregunta natural es:
¿Qué cambio encaja en este sistema?
Con un contexto más amplio, la pregunta pasa a ser:
¿Qué cambio encaja en este sistema, este requisito, esta historia y este momento?
Esa segunda pregunta detecta las limitaciones antes de que se conviertan en regresiones. Les da a quienes revisan el razonamiento detrás de la implementación. Ayuda a que las nuevas incorporaciones al equipo entiendan por qué el sistema es como es. Le da a la IA un papel bien fundamentado: no el de un oráculo dentro del editor, sino el de un participante capaz de reunir evidencia a lo largo del trabajo.
Tu repositorio nunca fue toda la historia.
La oportunidad está en construir sistemas capaces de leer todo lo demás y mostrar su trabajo.
