Un asistente de código sugiere; una persona acepta, fusiona y asume las consecuencias. Esa cadena de responsabilidad no cambia porque cambie quién escribe el borrador, y conviene que no cambie: es lo único que garantiza que exista alguien a quien preguntar cuando el sistema haga algo inesperado en producción.
El problema aparece cuando la responsabilidad se diluye de forma implícita, sin que nadie lo decida. Nadie declara que ya no responde de su código. Simplemente, la distancia entre quien acepta y quien entendió se va ampliando.
Cette confusion est coûteuse car elle absorbe le budget et nuit à la crédibilité de l'initiative. Six mois plus tard, lorsqu'on demande ce qui s'est amélioré, la réponse honnête est généralement « l'expérience initiale », ce qui ne justifie pas un programme de transformation.
Tres mecanismos, los tres silenciosos:
La revisión se vuelve superficial. Cuando llegan cambios grandes con frecuencia, el revisor pasa de «entiendo esto y estoy de acuerdo» a «parece razonable». El informe DORA de 2024 midió el efecto agregado: al aumentar la adopción de IA, la estabilidad de entrega caía un 7,2%, asociada al crecimiento del tamaño de los lotes de cambio.
La autoría se difumina. En un incidente, la pregunta «¿quién escribió esto?» empieza a tener como respuesta «lo generamos». Es una respuesta que no permite continuar la conversación.
La confianza sustituye a la comprobación. El código funciona en las pruebas, así que se asume que está bien. Funciona y estar bien son cosas distintas: la segunda incluye qué pasará cuando cambie el contexto.
En el mismo informe DORA, el 39,2% de los desarrolladores declaraba poca o ninguna confianza en el código generado. Es un dato incómodo en la dirección contraria: hay desconfianza declarada y, aun así, el volumen aceptado crece.
No es una cuestión de culpa. Es la capacidad de responder a cuatro preguntas sobre cualquier parte del sistema:
Quien puede responder a las cuatro es responsable de ese código, lo haya escrito una persona o una herramienta. Quien no puede responder a ninguna no es responsable, aunque figure como autor en el repositorio.
Rôle | Qué aporta la herramienta | Qué sigue siendo humano |
|---|---|---|
Diseño | Alternativas y ejemplos | Elegir y asumir la elección |
Implementación | Borrador funcional | Comprobar que hace lo que el negocio espera |
Revisión | Detección de patrones conocidos | Juicio sobre encaje y consecuencias |
Opération | Alertas y diagnóstico | Decidir qué hacer cuando algo falla |
Responsabilidad | Aucun | Toda |
La última fila no es retórica. Ninguna herramienta comparte la responsabilidad ante un cliente, un auditor o un tribunal. La organización responde de lo que su software hace, con independencia de cómo se produjo, como quedó establecido en el caso del chatbot de Air Canada resuelto en 2024.
Nadie fusiona lo que no podría explicar. La regla básica. No exige entender cada detalle, sí poder responder a las cuatro preguntas anteriores.
Cada cambio tiene un responsable con nombre. No un equipo. Una persona que responde de esa parte del sistema y a la que se puede preguntar.
Las pruebas críticas las escribe una persona. Si la misma herramienta genera la implementación y la prueba que la valida, el circuito se cierra sobre sí mismo y no comprueba nada relevante.
El tamaño del cambio está limitado. Es la medida que hace posibles las tres anteriores. Un cambio grande no se puede revisar con profundidad, por muy buena que sea la intención del revisor.
Si tu empresa externaliza el desarrollo, esta conversación tiene una traducción contractual directa. Tres preguntas al proveedor:
¿Quién responde de los defectos del código entregado? Un defecto no es un cambio de alcance. Debería corregirse sin coste y estar por escrito. En nuestro caso es la Garantía Lluvia: los defectos del código que entregamos los corregimos nosotros, de por vida.
¿Podéis explicar cualquier parte del sistema seis meses después? La prueba es sencilla: pedir la explicación de un módulo elegido al azar.
¿Qué documentación de decisiones se entrega? No comentarios línea a línea, sino por qué se eligió cada enfoque y qué se descartó. Es lo que permite que otro equipo tome el relevo.
Un proveedor que asume esas tres condiciones está diciendo que mantiene la cadena de responsabilidad intacta. Uno que las matiza está indicando dónde quedará el hueco.
Para una dirección técnica que quiera saber en qué situación está su equipo, hay un ejercicio que cuesta una hora: elegir tres partes del sistema al azar y pedir a sus responsables que respondan a las cuatro preguntas.
El resultado no mide la calidad del código. Mide algo más importante: si la organización controla su sistema o solo lo posee.
La persona que lo acepta y lo incorpora al sistema, y la organización que lo pone en producción. Ninguna herramienta comparte responsabilidad ante un cliente, un auditor o un tribunal: la empresa responde de lo que su software hace, con independencia de cómo se produjo.
Con cuatro preguntas: qué hace esto en términos de negocio, por qué está así y qué alternativa se descartó, qué se rompe si se cambia, y cómo se sabe que sigue funcionando. Quien puede responder a las cuatro es responsable de ese código, lo escribiera una persona o una herramienta.
Por tres vías silenciosas: la revisión se vuelve superficial cuando los cambios crecen de tamaño, la autoría se difumina hasta que la respuesta ante un incidente es «lo generamos», y la confianza en que las pruebas pasan sustituye a la comprobación de que el comportamiento es el que el negocio espera.
Cuatro: nadie fusiona lo que no podría explicar, cada cambio tiene un responsable con nombre y no un equipo, las pruebas críticas las escribe una persona y no la misma herramienta que generó la implementación, y el tamaño de los cambios está limitado para que la revisión sea posible.
Que responda de los defectos del código entregado sin coste y por escrito, que pueda explicar cualquier parte del sistema seis meses después, y que entregue documentación de las decisiones tomadas y de las alternativas descartadas, no solo comentarios en el código.
Según el informe DORA de 2024, el 39,2% declaraba poca o ninguna confianza en él. Es un dato relevante porque convive con un aumento del volumen aceptado, lo que sugiere que la desconfianza declarada no siempre se traduce en más comprobación.
¿Podría tu equipo explicar cualquier parte de vuestro sistema? Nuestra auditoría técnica evalúa arquitectura, código, deuda y capacidad real de mantenimiento, por escrito y en 10 días hábiles. Demander l'audit → |
Español Español 
English
Français
العربية
Português
Deutsch
Italiano
