Idea principal

Prescindir de la revisión de un desarrollador sobre una herramienta que uno mismo se ha fabricado tiene una contrapartida que no es opcional: cuando esa herramienta se rompe, nadie más está comprometido. Quien eligió construirla come su propia comida, y la reparación le corresponde.

Ahí es donde la promesa se agrieta. Un asistente de código ha eliminado la barrera de entrada — escribir la funcionalidad — sin eliminar la competencia de salida: entender por qué lo que funcionaba ayer ya no funciona, leer una traza de error, aislar una regresión, distinguir un problema de datos de un problema de lógica. Muchos Product Managers saben ya hacer producir una pantalla y no saben resolver el bug que acaban de crear.

La asimetría es el núcleo del asunto: la producción se ha vuelto accesible, la explotación no lo ha hecho al mismo ritmo.

Por qué es importante

Esto da un criterio de entrada más honesto que el nivel de código: no "¿sabrías escribirlo?", sino "¿sabrás apañártelas cuando se rompa, sin movilizar a otra persona?". Una herramienta que no sabrías reparar no es una herramienta personal, es una deuda depositada en casa del vecino.

También nombra lo que se esconde detrás de muchas peticiones de revisión: menos un control de calidad que una manera de transferir por adelantado la responsabilidad de la reparación.

Matices y límites

El asistente recoge una parte de la carga — lee la traza, propone una corrección, explica lo que ha hecho. El límite no es, por tanto, absoluto; recae sobre los casos en los que entender el problema es el paso previo a la pregunta que habría que hacerle.

Y la regla supone que la herramienta siga siendo personal. En cuanto un equipo depende de ella, la avería deja de ser un problema privado, y la responsabilidad individual ya no basta para absorberla.

Preguntas abiertas

• ¿Qué competencia mínima de diagnóstico — leer una traza, consultar un log, repetir una consulta — hay que exigir antes de autorizar a alguien a poner en servicio una herramienta que ha hecho producir?