Cambios en los límites de responsabilidad provocados por el Codex

Cuando presenté Codex al equipo a gran escala por primera vez, lo primero que bueno fue que finalmente estaba dispuesto a hacer algunos pequeños cambios.

Una situación común en el pasado era que todos lo sabían claramente: este código debe refactorizarse, este script debe probarse y este límite debe registrarse. Pero todos están atrapados en la misma realidad. Hay que prestar atención a los costos para empezar a escribir y hay que revisarlos después de escribir.

Codex reduce la “fricción práctica”.

Los problemas empezaron a surgir a partir de ese día.

Porque a medida que la fricción disminuye, los límites de la responsabilidad también se mueven silenciosamente.

A primera vista, puede pensar que está comprando autores más rápidos, pero lo que en realidad está comprando son más cambios. Cuando hay demasiados cambios, el sistema necesita una aceptación más clara y mecanismos de control más sólidos.

De lo contrario, la eficiencia del Codex se manifestará de otra forma: accidentes en línea, fatiga de revisión y retrabajo que “parece correcto pero es inestable” una y otra vez.

¿Cómo fue que las cosas se convirtieron gradualmente en “el revisor es responsable”?

En la primera semana después de la introducción del Codex, todo el mundo lo utilizó con mucha moderación.

-Escribir un widget

• Cambiar el nombre de un párrafo
• Añadir un juicio si

Estos cambios, si no perfectos, conllevan un riesgo limitado.

A partir de la segunda semana, los cambios se hicieron mayores.

Algunas personas comenzaron a pedirle a Codex que “organizara el código circundante por cierto”, algunas personas comenzaron a pedirle que “refactorice este módulo juntos” y algunas incluso reemplazaron una sección completa de lógica compleja con una versión generada.

En esta etapa, la frase más común es:

Mira, el código está todo escrito y la lógica es correcta.

El problema es que hay una sustitución oculta en esta oración.

En el pasado, el autor era el principal responsable de si la lógica era correcta o no. El autor debe pasar por una convergencia total al escribir: las razones de los cambios, cuáles son los límites, qué sucederá si falla y cómo retroceder.

El Codex aplana el proceso de convergencia en el medio. El autor se convierte en “el que exige” y deja la moderación al crítico.

Entonces el límite de responsabilidad comienza desde:

• El autor es responsable de hacer converger los cambios hasta que estén listos para su publicación.

se convirtió en:

• Los revisores son responsables de filtrar los cambios hasta que no causen problemas.

Esta no es una cuestión moral, es una cuestión mecánica.

El modo de generar código tiende naturalmente a “escribir una versión primero” en lugar de “pensar claramente en los límites primero”. Esta transferencia de responsabilidad ocurre siempre que el proceso no establezca límites explícitos.

A menudo el precio se pagará en tres lugares inmediatamente

1) La revisión se convierte en “arqueología”

En el pasado, la revisión analizaba las elecciones del autor:

• Utilice esto para lograr
• Dividir en estas funciones
• Añade esta protección aquí

Ahora la revisión analiza el resultado:

• ¿Este código generado perdió algún límite?
• ¿Se han introducido nuevos efectos secundarios?
• ¿Ha cambiado silenciosamente la semántica de la vieja lógica?

No es el mismo tipo de trabajo.

El primero es juzgar el proceso de razonamiento del autor y el segundo es encontrar trampas en un código desconocido. Este último es más caro y depende más de la familiaridad del revisor con el contexto.

Pronto verás un fenómeno:

• El código está fusionado.
• Algo salió mal en línea
• Durante la revisión, nadie supo por qué estaba escrito así.

Porque el “por qué” nunca está escrito.

2) Las pruebas se tratan como “opcionales”

La mayor tentación al generar código es: parece completo.

Las funciones están bellamente divididas, los nombres son los mismos e incluso se proporcionan algunas pruebas individuales adicionales.

El problema es que estas pruebas unitarias a menudo “verifican la implementación” en lugar de “verificar los requisitos”.

Los síntomas típicos son:

• Mayor cobertura
• Muchos accidentes

Porque lo que falta son criterios de aceptación, no la falta de un formato JUnit/pytest.

3) Se olvida la ruta de reversión

Los cambios escritos a mano a menudo conducen a pensamientos naturales de “¿y si no funciona?”.

Generar cambios puede fácilmente dar la ilusión de que se trata de una implementación más limpia y que debería estar bien.

Pero lo más doloroso en línea es que “los cambios son demasiado grandes y no se puede retroceder”.

Cuando los cambios generados abarcan varios archivos y se refactorizan en varios lugares, la reversión ya no se trata de deshacer una confirmación, sino de reconstruir la semántica anterior.

Este es el proyecto de ley más caro después de que se traspasaron los límites de responsabilidad.

Para recuperar los límites de la responsabilidad, lo que debemos hacer no es “desactivar el Codex”

Cuando muchos equipos ven estos problemas, su primera reacción es restringir su uso:

• Deshabilitar la generación de segmentos grandes
• Está prohibida la modificación de los módulos principales.
• La lógica clave debe escribirse a mano.

Estas reglas son útiles a corto plazo, pero rápidamente se vuelven formalistas.

El enfoque verdaderamente eficaz es hacer avanzar la parte de “responsabilidad del autor” al proceso de utilización del Codex.

Finalmente lo reduje a cuatro requisitos estrictos. Si falta alguno de ellos, no me rendiré:

1. La intención del cambio debe escribirse claramente: describa el comportamiento que se va a cambiar en una oración, no “refactorizarlo”.
2. Los criterios de aceptación deben ser ejecutables: cuáles son las entradas, cuáles son las salidas esperadas y cómo comportarse en caso de falla.
3. Se debe enumerar el límite de riesgo: ¿Qué personas que llaman se ven afectadas por este cambio y cuál es el peor de los casos?
4. El plan de reversión debe ser claro: a qué versión revertir, cómo procesar los datos y dónde está el interruptor de degradación.

Codex puede ayudar a escribir implementaciones, pero no puede reemplazar estos cuatro elementos.

Más importante aún: después de escribir estos cuatro elementos, la reseña se volvió más ligera.

El revisor no necesita adivinar “qué es exactamente lo que quiere hacer” a partir del código, solo necesita juzgar “si la intención escrita y la implementación son consistentes”.

Los malentendidos más comunes

Malentendido 1: Tratar a Codex como “un recién llegado que puede escribir código”

Los recién llegados se quedan atrapados en lugares que no conocen, hacen preguntas y exponen la incertidumbre.

El Códice no lo hace.

Le dará la respuesta que le parezca más cómoda cuando no esté seguro. Sin criterios de aceptación, se entierra la incertidumbre en el código.

Mito 2: Usar más palabras clave para compensar los procesos de ingeniería faltantes

Las palabras clave pueden ayudar a que se ajuste más al estilo, pero no pueden reemplazar el mecanismo de control.

Rellenar los procesos faltantes en el mensaje terminará con una “memoria organizacional que se escribe cada vez más”, pero no tiene control de versiones, ni estrategia de reversión ni simulacros de fallas.

Malentendido 3: Contar únicamente “cuánto tiempo se ahorra”

La métrica más peligrosa es: cuánto tiempo de desarrollo se ahorra por requisito.

Porque impulsará a todos a buscar un mayor alcance generacional.

Prefiero centrarme en dos indicadores:

• Generar tasa de retrabajo después de la integración del cambio.
• Proporción de incidencias introducidas por cambios generacionales

Están relacionados con los límites de la responsabilidad.

Límites aplicables

No todos los equipos necesitan limitaciones tan estrictas.

Si el sistema es lo suficientemente pequeño, las versiones son lo suficientemente frecuentes y las reversiones son lo suficientemente simples, el riesgo del Codex será absorbido.

Pero una vez que se cumpla cualquiera de los siguientes, los límites de responsabilidad deben hacerse explícitos:

• Los cambios afectarán enlaces de alto costo como pago, control de riesgos y aprobación.
• Ciclo de lanzamiento largo y alto costo de reversión
• La propiedad del código es ambigua y la revisión ya es un cuello de botella.

En estos escenarios, lo “más rápido” del Codex primero pasará a ser más lento.

Resumen

Codex ciertamente hace que escribir código sea más rápido.

Pero lo que realmente cambia es la respuesta predeterminada del equipo a “¿quién es responsable del cambio?”

Si la intención, la aceptación, los límites y las reversiones no avanzan, la responsabilidad naturalmente pasará al revisor.

Al final, descubrirá que lo que se ahorra no es tiempo de desarrollo, sino que se gasta la atención de todo el equipo. Esta cuenta es mucho más cara que el token.