Profundizando un poco en el Codex como Agente de Ingeniería de Software, te comparto algo de lo que pude investigar hasta ahora y espero que te ayude.

Imaginemos a un asistente virtual muy inteligente, especialmente entrenado para ayudarte con tareas relacionadas a la creación y mantenimiento de software. Ese asistente virtual es el denominado «Codex».

¿Qué es el Codex en definitiva?

Es un agente de ingeniería de software basado en la nube, es decir, una herramienta avanzada que «vive» en internet y a la cual uno la puede acceder.

¿Qué hace? ¿Cuál es su objetivo? ¿En qué nos puede ayudar?

Codex puede encargarse de varias tareas de codificación y desarrollo. Por ejemplo, puede ayudarte a escribir nuevas partes de un programa (funcionalidades), responder preguntas sobre el código existente, encontrar y corregir errores (bugs), e incluso preparar cambios en el código para que otros desarrolladores los revisen. Puede trabajar en varias tareas al mismo tiempo.

¿Cómo funciona?

Cuando le asignas una tarea (a través de ChatGPT), Codex trabaja en un entorno seguro y aislado en la nube. Es como tener una pequeña computadora virtual solo para esa tarea, precargada con el código de tu proyecto. En ese espacio virtual puede leer archivos, hacer cambios y ejecutar comandos, como correr las pruebas para ver si el código funciona correctamente.

¿Quién lo usa?

A la fecha de este artículo está disponible para ciertos tipos de usuarios de ChatGPT (Pro, Team, Enterprise, y pronto Plus/Edu). Equipos técnicos en empresas ya lo están usando para delegar tareas repetitivas o para empezar a construir nuevos componentes rápidamente.

Algunas características interesantes

Transparencia y seguridad:
OpenAI lo ha diseñado pensando en la seguridad y la transparencia. Cuando Codex hace cambios, te muestra evidencia verificable de lo que hizo, como registros de las pruebas que corrió o los archivos que modificó. Su entorno de trabajo está aislado y no tiene acceso a internet externo, lo que ayuda a prevenir riesgos. De todas formas, es crucial detenerse y siempre revisar y aprobar los cambios que propone Codex antes de integrarlos al proyecto principal.

Personalización:
Se puede guiar a Codex dándole instrucciones específicas, incluso a través de un archivo llamado AGENTS.md dentro de tu proyecto, indicándole cómo prefieres que trabaje o qué pruebas debe ejecutar.

El objetivo a futuro:
La idea es que los desarrolladores puedan enfocarse en los aspectos más complejos y creativos del trabajo, mientras que delegan las tareas más rutinarias o que requieren mucho tiempo a «agentes» como Codex, siendo así más rápidos y productivos.

Punto para reflexionar: este último comentario («El objetivo a futuro») lo pienso también para el ámbito del agile testing así como con cualquiera de otras disciplinas.

Síntesis

Codex es como un asistente de programación inteligente en la nube que te ayuda con diversas tareas de desarrollo de software en un entorno seguro y transparente, permitiéndote acelerar tu trabajo.

Vayamos a un ejemplo Sencillo en un Proyecto Ágil (Scrum) hipotético

Imaginemos que eres parte de un equipo que está construyendo el backend (la parte que no se ve, que maneja la lógica y los datos) de un sitio de comercio electrónico (e-commerce). Usan Scrum con sprints de dos semanas. En cada sprint, el equipo se compromete a completar un conjunto de funcionalidades.

En uno de los sprints, una de las tareas es crear una nueva «puerta de entrada» (un endpoint API) para que la parte visible del sitio (el frontend) pueda obtener los detalles de un producto específico usando su número de identificación (ID).

1. La Tarea (PBI en Scrum): «Como usuario (el frontend del sitio), quiero poder obtener los detalles de un producto proporcionando su ID, para mostrar la información completa en la página del producto». Esto se convierte en un elemento en el Sprint Backlog.
2. Asignación: Un desarrollador del equipo toma esta tarea en el sprint.
3. Usando Codex: El desarrollador sabe que esta tarea es bastante estándar: requiere definir una URL, escribir código para buscar el producto en la base de datos y formatear la respuesta. Decide usar Codex para acelerar el proceso.
4. Instrucción a Codex: El desarrollador, a través de la interfaz de ChatGPT, le daría una instrucción similar a esta: «En el proyecto /testbed (asumiendo que el código del e-commerce está ahí, como en el ejemplo del manual), agrega un nuevo endpoint GET /api/products/{product_id}. Este endpoint debe consultar la base de datos para obtener los detalles del producto con el ID proporcionado y devolverlos en formato JSON. Asegúrate de incluir pruebas unitarias para esta nueva funcionalidad.»
5. Codex en Acción:
   ◦ Codex operaría en su entorno aislado con el código del e-commerce.
   ◦ Leerá los archivos relevantes (por ejemplo, el archivo donde se definen las rutas API, el código que interactúa con la base de datos).
   ◦ Escribirá el código necesario para el nuevo endpoint (definir la ruta /api/products/{product_id}, llamar a la función de la base de datos para obtener el producto).
   ◦ Creará un nuevo archivo (o agregará a uno existente) con pruebas automatizadas para verificar que el endpoint responde correctamente cuando se le da un ID válido y un ID inválido.
   ◦ Utilizará su herramienta (como la herramienta python descrita en las fuentes) para ejecutar las pruebas que acaba de escribir.
   ◦ Si alguna prueba falla, Codex intentará depurar y corregir el código, volviendo a ejecutar las pruebas hasta que pasen.
   ◦ Una vez que está seguro de que el código funciona y las pruebas pasan, Codex generará los cambios realizados (en un formato como el descrito en las fuentes) y los «confirmará» (commit) en su entorno.
6. Revisión Humana: El desarrollador recibe la propuesta de cambios de Codex. Puede ver exactamente qué archivos se modificaron y qué líneas se agregaron o cambiaron. También puede ver los registros de las pruebas que Codex ejecutó para verificar su trabajo. El desarrollador revisa cuidadosamente el código propuesto por Codex para asegurarse de que cumple con los estándares del equipo y que la lógica es correcta, tal como se recomienda.
7. Integración: Si la revisión es exitosa, el desarrollador integra los cambios de Codex en la rama de desarrollo principal del proyecto.

Beneficio en el contexto ágil

Al usar Codex para esta tarea, el desarrollador pudo completarla mucho más rápido de lo que lo hubiera hecho manualmente, especialmente incluyendo la escritura y ejecución de pruebas. Esto significa que puede pasar a la siguiente tarea del sprint antes, o tener más tiempo para colaborar con otros miembros del equipo, participar en las reuniones diarias de Scrum, o abordar problemas más complejos. Codex actuó como un colaborador eficiente para una tarea bien definida y repetitiva, ayudando al equipo a acercarse más rápidamente a su objetivo del sprint.

Estructura de los archivos AGENTS.md

Los archivos AGENTS.md son archivos de texto, similares a los archivos README.md, que sirven para proporcionar instrucciones al agente Codex para trabajar dentro de un entorno específico. Aquí te comparto los puntos clave sobre su estructura y uso:

Ubicación y Alcance:
Los archivos AGENTS.md pueden encontrarse en cualquier lugar dentro del sistema de archivos del contenedor donde opera Codex. Las ubicaciones típicas incluyen el directorio raíz (/), el directorio personal (~), y dentro de los repositorios de Git. El alcance de un archivo AGENTS.md es todo el árbol de directorios enraizado en la carpeta que lo contiene. Las instrucciones sobre estilo de código, estructura, nombres, etc., se aplican solo al código dentro del alcance de ese archivo AGENTS.md, a menos que el archivo indique lo contrario.

Instrucciones:
Estos archivos pueden contener diversas instrucciones para el agente, incluyendo:
◦ Convenciones de codificación.
◦ Información sobre cómo está organizado el código base.
◦ Instrucciones sobre cómo ejecutar o probar el código.
◦ Instrucciones sobre los mensajes de las Pull Requests (PR) generadas por el agente.

Precedencia:
En caso de instrucciones en conflicto:
◦ Los archivos AGENTS.md más profundamente anidados tienen precedencia.
◦ Las instrucciones directas del sistema, desarrollador o usuario (como parte de un prompt) tienen precedencia sobre las instrucciones de los archivos AGENTS.md.

Comprobaciones Programáticas:
Si un archivo AGENTS.md incluye comprobaciones programadas para verificar el trabajo del agente, Codex DEBE ejecutar todas esas comprobaciones después de realizar todos los cambios de código y hacer todo lo posible para validar que las comprobaciones pasen. Esto se aplica incluso para cambios como documentación.

Síntesis

Un archivo AGENTS.md es un archivo de texto que define reglas, convenciones y procedimientos operativos para el agente Codex dentro de un contexto de directorio específico, permitiendo a los usuarios guiar su comportamiento de manera granular.

Ejemplo de archivo AGENTS.md (hipotético)

Este archivo contiene instrucciones específicas para el agente Codex al trabajar en este repositorio.

1. Convenciones de Codificación

• Sigue el estilo de código definido en .editorconfig y .eslintrc.js ubicados en la raíz del repositorio.
• Utiliza nombres de variables y funciones descriptivos que sigan la convención camelCase para JavaScript/TypeScript y snake_case para Python.
• Asegúrate de añadir comentarios a las funciones complejas o secciones de código no triviales.
• El código debe ser legible y mantener una complejidad ciclomática baja siempre que sea posible.

2. Pruebas

• Para cualquier cambio de código, DEBES ejecutar las suites de prueba relevantes.
• Los comandos para ejecutar las pruebas son:
  • Pruebas unitarias: npm test:unit
  • Pruebas de integración: npm test:integration
• ASEGÚRATE de que todas las pruebas pasen antes de considerar una tarea completada. Si las pruebas fallan, investiga y corrige el error.
• Siempre que sea posible, añade nuevas pruebas unitarias para cubrir la funcionalidad nueva o modificada, con el objetivo de mantener una alta cobertura de código.

3. Commits y Pull Requests

• Los mensajes de commit deben seguir la convención de Commits Convencionales. Por ejemplo: feat: add user authentication endpoint o fix: correct pagination bug.
• Cada commit debe ser atómico y centrarse en un único cambio lógico.
• Los mensajes de las Pull Requests (PR) generadas deben incluir:
  • Una descripción concisa del cambio realizado.
  • Referencias a cualquier issue relacionado (ej: Fixes #123).
  • Una sección que describa cómo se probaron los cambios, citando los resultados de las pruebas de la terminal.

4. Organización del Código

• La lógica de negocio principal se encuentra en el directorio src/domain.
• Las implementaciones de la capa de infraestructura están en src/infrastructure.
• Los controladores API están en src/presentation/http.

Este ejemplo cubre aspectos comunes del desarrollo de software que son relevantes para las tareas que Codex puede realizar (escribir código, corregir errores, escribir pruebas, crear PRs). Las instrucciones sobre pruebas y convenciones de commits/PRs son particularmente aplicables a un entorno que valora la integración continua y la calidad, aspectos que a menudo se enfatizan en las metodologías Ágiles.

Importante: Recuerda que este es un ejemplo hipotético basado en la descripción general de AGENTS.md, según la fuente y a modo explicativo.

En relación con el #testing, ¿En qué momento actúa el Agile Tester?

Tengamos en cuenta el escenario previo explicado antes y reforzándolo aquí:

El rol del desarrollador y Codex:
El desarrollador es quien recibe la tarea de crear el endpoint API para obtener detalles del producto, pudiendo utilizar Codex como parte de su kit de herramientas diario para tareas como escribir código, escribir tests, ejecutar tests (unitarios, de integración, etc.), ejecutar linters y verificadores de tipo, y corregir errores (bugs). El objetivo es offloadear tareas repetitivas, acelerar el desarrollo y mantener el enfoque. El término «offloadear» (derivado del inglés «offload») se refiere a la práctica de delegar tareas a un agente de inteligencia artificial, como Codex.

Codex Ejecuta Controles de Calidad Automatizados:
Como parte de la tarea del desarrollador, Codex puede ser configurado (a menudo mediante archivos AGENTS.md) para ejecutar automáticamente ciertos controles de calidad. Estos pueden incluir:

• Ejecutar suites de tests existentes o nuevos. Si un archivo AGENTS.md incluye comprobaciones programadas para verificar el trabajo del agente, Codex DEBE ejecutarlas todas después de realizar los cambios y hacer todo lo posible para validar que las comprobaciones pasen.
• Cumplir con convenciones de codificación (que pueden estar especificadas en AGENTS.md).
• Ejecutar herramientas de análisis estático como linters o verificadores de tipo.
• El momento clave para el Agile Tester y su revisión del trabajo de Codex

Hay que recordar los conceptos originales: la transparencia y la verificabilidad del trabajo de Codex. Una vez que Codex ha completado la tarea asignada por el desarrollador (crear el endpoint, escribir tests, etc.) y ha ejecutado los controles de calidad automatizados (como los tests), proporciona evidencia verificable de sus acciones. Esta evidencia incluye citas de los logs de la terminal y de las salidas de los tests. Este es el momento para que el agile tester actúe:

• Cuando el desarrollador propone el código terminado para el endpoint (por ejemplo, creando una Pull Request, que Codex puede generar), el tester, como parte del equipo Agile/Scrum, revisa esta propuesta.
• Durante esta revisión, el tester no solo examina el código en sí (aunque la revisión manual del código sigue siendo esencial), sino que también examina activamente la evidencia proporcionada por Codex.
• El tester utilizará los logs de la terminal y las salidas de los tests citadas por Codex para confirmar que las comprobaciones de calidad automatizadas configuradas por el equipo (especificadas potencialmente en AGENTS.md) han sido ejecutadas y han pasado correctamente.
• En el ejemplo del endpoint, el tester confirmaría que los tests unitarios y de integración para el nuevo endpoint, ejecutados por Codex, muestran resultados de paso. Si Codex encontró fallos en los tests, comunicaría estos problemas, lo cual alertaría al tester y al desarrollador sobre la necesidad de correcciones.

Confirmación y Continuidad:
La revisión y confirmación de que los controles de calidad automatizados han pasado exitosamente, basándose en la evidencia de Codex, es un paso importante para el agile tester. Esto ayuda a determinar si el código está listo para pasar a etapas de prueba adicionales más amplias, como pruebas funcionales, de sistema o de aceptación, que pueden requerir intervención manual o herramientas de prueba diferentes a las que maneja Codex directamente (los fuentes no describen a Codex realizando pruebas funcionales de alto nivel). La evidencia de Codex actúa como una primera línea de defensa automatizada cuya ejecución y resultados son validados por el tester.

Síntesis

En el contexto del ejemplo del proyecto Agile/Scrum, el agile tester no necesariamente interactúa directamente con Codex dando instrucciones, sino que su función clave en el control de calidad se realiza al revisar y validar la evidencia (principalmente los resultados de los tests y logs) que Codex genera como parte del flujo de trabajo del desarrollador. Esto le permite al tester confirmar que las pruebas automatizadas y otros controles de calidad del código han sido ejecutados y han pasado, antes de proceder con sus propias actividades de prueba.

Fuente de inspiración: Introducing Codex