Cómo utilizar Codex y sus límites en proyectos reales

Una situación común es preguntar “cómo utilizar el Codex”. De forma predeterminada, pregunta sobre las teclas de método abreviado, las plantillas de mensajes de texto y cómo hacer que escriba más código.

Más tarde descubrí que esta pregunta se hizo en la dirección equivocada.

El mayor valor de Codex es permitir que los equipos inicien cambios con mayor frecuencia y de forma más económica. El riesgo real también está aquí: después de aumentar la frecuencia de los cambios, el mecanismo de registro original del equipo puede no ser suficiente.

Por eso no hablaré de las “Diez técnicas de palabras clave” en este artículo. Solo hablaré de una línea principal: Conectar Codex a una canalización de cambios que pueda aceptarse, revertirse y rastrearse.

1. Primero seleccione la “unidad de trabajo adecuada para el Codex”

El uso más fácil de anular es enviar un requisito vago directamente al Codex:

• “Refactorizar este módulo”
• “Optimizar el rendimiento”
• “Haz este lugar más elegante”

Ciertamente ofrece muchos cambios y todos parecen correctos. El problema es que no hay forma de aceptarlo o revisarlo.

He condensado las tareas adecuadas para el Codex en tres categorías, cada una con “condiciones de finalización” claras.

A. Cambios de comportamiento que se pueden escribir como afirmaciones

La característica es: ¿se pueden describir la entrada y la salida en una oración?

• Agregar procesamiento de límites a una función
• Se corrigió un error definitivo.
• Migrar una parte de la lógica a una nueva interfaz pero mantener la semántica sin cambios.

La mejor manera de lograr la aceptación es escribir pruebas directamente, o al menos escribir un script de aserción ejecutable.

B. Cambios mecánicos enumerables

Las características son: reglas claras y cobertura controlable.

• Cambio de nombre por lotes
• Actualizar llamadas API
• Completa capacidad de nulidad/manejo de errores

Codex es poderoso para este tipo de trabajo, pero se le debe permitir generar una “lista de modificaciones” y un “alcance de cambios que se pueda buscar”, de lo contrario tiende a omitir rincones.

C. Optimización local con indicadores concretos

La característica es: la capacidad de definir métodos de medición.

• Reducir IO una vez durante la fase de inicio
• Reducir la serialización una vez para un determinado enlace.
• Reducir la reorganización innecesaria de una determinada página.

No optimice sin métricas. Codex confundirá “parece más rápido” con “es realmente más rápido”.

2. Escriba los requisitos como “criterios de aceptación” y luego escriba las palabras clave.

Una situación común es escribir palabras clave como escribir deseos:

• “Por favor escribe elegantemente”
• “Siga las mejores prácticas”

Estos son inaceptables.

Requiero que cada vez, antes de permitir que Codex actúe, primero escriba un criterio de aceptación y lo escriba en la misma descripción de la tarea:

• ¿Qué comportamiento cambiará este cambio?
• ¿Qué conductas no se permite cambiar?
• Cómo comportarse cuando fallas
• Cómo retroceder

Descubrirá que una vez que los criterios de aceptación están claramente escritos, las palabras clave se vuelven más cortas.

Una estructura que uso a menudo es:

1. Antecedentes (dos o tres frases, no hables de historia)
2. Objetivo (solo comportamiento de escritura, no implementación)
3. Restricciones (lo que no se puede mover)
4. Aceptación (puntos de prueba o guiones)
5. Formato de salida (primero proporcione el plan y luego el parche)

3. Pídale a Codex que proporcione primero un “plan de cambio”, en lugar de proporcionar el código final directamente.

Lo más caro en proyectos reales es “descubrir que la semántica ha cambiado después de la fusión”.

Así que hice que la salida predeterminada del Codex fuera un proceso de dos pasos:

• Paso 1: enumere qué archivos se cambiarán, por qué se cambiarán y los riesgos de cada cambio.
• Paso 2: aplique el parche nuevamente

Si genera un fragmento completo de código tan pronto como aparece, simplemente lo llamaré y dejaré que haga el plan.

La razón es sencilla:

• La etapa de planificación puede revelar si comprende los límites.
• Si los cambios excesivos se pueden eliminar a tiempo durante la etapa de planificación.

4. Deje que Codex genere un “parche revisable” en lugar de solo un montón de texto

Copiar y pegar cientos de líneas de código en el IDE convierte la revisión en un trabajo manual.

El enfoque correcto es: dejar que el Codex genere la salida en forma de diferencia/parche, o dejar que solo haga los cambios fusionables más pequeños.

Cumpliré con dos limitaciones en el equipo:

• Un único RP no abarca dos intenciones no relacionadas
• La diferencia principal de un solo RP está dentro de las 200 líneas (de lo contrario, debe dividirse)

Es fácil escribir cada vez más códices y deben estar “cerrados en una pequeña caja” con restricciones de relaciones públicas.

5. Deje que la prueba sea el “primer resultado”, no la “última adición”

El error más común del Codex es que la implementación está completamente escrita y las pruebas parecen estar ahí, pero la prueba solo valida la implementación que escribió.

Entonces le pedí que saliera en orden:

1. Lista de casos de prueba (qué límites están cubiertos)
2. Código de prueba clave
3. Implementar parche

Si no puede proporcionar puntos de prueba, significa que los requisitos no están claramente escritos o que este cambio no es adecuado para él.

6. Escriba la “ruta de reversión” en el cambio.

Las personas que hacen cambios a mano a menudo dejan inconscientemente un camino alternativo.

Es fácil que la persona que hizo el cambio lo olvide.

Requeriría que cada cambio de compilación satisfaga al menos una política de reversión:

-indicador de características

• Interruptores de configuración
• Mantener el antiguo camino por un tiempo (doble recorrido)

Los cambios importantes sin una ruta de reversión, sin importar quién los haya escrito, no deberían implementarse. Codex simplemente facilita la realización de “grandes cambios”.

7. Tratar la trazabilidad como un “elemento de costo” del uso del Codex

Si sólo cuenta “cuánto tiempo de desarrollo se ahorra”, a menudo se le animará a escribir más y más Codex.

Lo que más me importa es si el problema se puede reproducir.

Entonces, en el proceso registraré enérgicamente tres cosas:

• Descripción de la tarea para el Codex esta vez (incluidos los criterios de aceptación)
• Plan de cambio proporcionado por el Codex.
• Parche final y resultados de las pruebas.

Estos tres elementos son la cadena de evidencia durante la revisión del accidente.

Sin iniciar sesión, cuanto más utilice Codex, más se sentirá como si estuviera ejecutando un sistema irreproducible.

8. Un conjunto de esqueletos de palabras que se pueden usar directamente

El siguiente párrafo es el cambio mínimo para que su salida esté en línea.

Puede copiarlo directamente y reemplazar los corchetes:

Es necesario realizar cambios en un proyecto real.

Antecedentes: [Dos o tres frases que describen la situación y los problemas actuales] Metas (nivel de comportamiento):

• Debe hacer: [Enumere 2-4 elementos]
• Nunca cambiar: [Lista 2-4] Restricciones:
• No se permite introducir nuevas dependencias/no se permite cambiar la API pública/debe ser compatible con datos antiguos (seleccione según sea necesario) Aceptación:
• da una lista de puntos de prueba
• Proporcione al menos [N] códigos de casos de prueba clave Formato de salida:

1. Dar primero un plan de cambio (lista de documentos + puntos de riesgo)
2. Proporcione el parche más pequeño (diff), no incluya texto explicativo largo

Límites aplicables

Los escenarios en los que Codex no es adecuado también son claros:

• Ni siquiera puedo decir qué comportamiento quiero, así que sólo puedo “probarlo primero”
• Se trata de un cambio de alto riesgo que implica migración de datos, permisos y financiación, pero no existe un entorno de aceptación total.
• Dependencia del conocimiento tácito (cambios en línea, estrategias en escala de grises, incidentes históricos) sin documentación

En estos escenarios, Codex solidificará la incertidumbre directamente en el código.

Resumen

La respuesta a “cómo utilizar el Codex” es un conjunto de limitaciones de ingeniería.

Pensar en ello como una creación más rápida pone la responsabilidad en la revisión y en línea.

Trátelo como una sección del proceso, utilice criterios de aceptación, pruebas, reversión y trazabilidad para contener los cambios, y se convertirá en una verdadera herramienta de eficiencia.