Codex para desarrollo
Aprende a trabajar con Codex sobre un repositorio, definir tareas verificables y revisar cambios y pruebas antes de decidir qué incorporar al proyecto.
Encuentra tu punto de partida
Encaja cuando ya trabajáis con código y control de versiones y queréis revisar cambios de Codex mediante criterios y comprobaciones técnicas.
- Duración y sesiones
- 12 horas en directo · 6 sesiones de 2 h.
- Tamaño del grupo
- Hasta 12 participantes por formador como referencia, ajustable según la práctica y el feedback.
Qué aprenderás
- 01
Preparar contexto y criterios de aceptación para una tarea de desarrollo.
- 02
Revisar un cambio propuesto y relacionarlo con el comportamiento solicitado.
- 03
Ejecutar comprobaciones y documentar resultados y dudas para revisión.
Una propuesta de trabajo
Trabajaréis con Codex sobre un repositorio preparado de solicitudes internas en TypeScript y React. Añadiréis un filtro por estado y corregiréis un fallo con una prueba de regresión. Las doce horas incluyen contexto, reproducción, planificación, cambios, comprobaciones y revisión de una entrega que otra persona pueda evaluar.
Adaptamos la selección y la profundidad de los módulos al punto de partida y los objetivos del grupo.
01Dar contexto al agente
Estructura del repositorio, instrucciones del proyecto y alcance de una tarea acotada.
Trabajarás en
- Explorar estructura, instrucciones del proyecto y comandos; comprobar el estado inicial del repositorio.
- Reproducir un fallo con datos ficticios y separar el comportamiento observado del esperado.
- Acotar las dos tareas y sus criterios de aceptación antes de pedir cambios a Codex.
- Práctica
- Preparar el contexto del gestor y reproducir que acepta un asunto compuesto solo por espacios.
- Cómo lo comprobarás
- Una tarea verificable con instrucciones, reproducción y criterios para el filtro y la corrección.
02Trabajar sobre cambios
Exploración de código, propuesta de implementación y revisión del diff con supervisión.
Trabajarás en
- Pedir un plan que relacione cada cambio con los archivos, comportamientos y pruebas afectados.
- Implementar el filtro Todas, Abiertas y Cerradas, conservando Todas como estado inicial.
- Corregir el asunto en blanco y revisar el diff para detectar cambios ajenos al alcance.
- Práctica
- Guiar la implementación en una rama de práctica y contrastar el cambio con los criterios acordados.
- Cómo lo comprobarás
- Un diff acotado que puede explicarse a partir del comportamiento solicitado.
03Verificar antes de integrar
Pruebas relevantes, documentación del resultado y criterios para aceptar o corregir cambios.
Trabajarás en
- Comprobar que la prueba de regresión detecta el fallo antes de corregirlo y pasa después.
- Ejecutar las pruebas relevantes de Vitest y Playwright, incluidos entrada vacía, filtro sin resultados y retorno a Todas.
- Revisar código y resultados con otra persona; documentar comandos, límites y dudas antes de integrar.
- Práctica
- Contrastar casos normales y límite, corregir hallazgos y preparar una entrega para revisión.
- Cómo lo comprobarás
- Cambios y pruebas revisados, con resultados reproducibles y asuntos pendientes explícitos.
Un filtro útil, con una corrección que las pruebas detectan
Ejemplo docente
Resolverás una tarea pequeña en un repositorio de práctica, revisarás los cambios generados y prepararás una entrega con comprobaciones y limitaciones documentadas.
Caso ficticio de aula. El repositorio Faro contiene un gestor de solicitudes, datos inventados y pruebas configuradas. Trabajamos en una rama local con Codex, TypeScript, React y Vite; Vitest y Playwright están listos antes de la formación.
- Punto de partida
- Queremos filtrar por Todas, Abiertas y Cerradas, con Todas al iniciar. La app también acepta asuntos formados solo por espacios: debemos reproducir el fallo y evitar que vuelva.
- Primera propuesta
- La primera propuesta del ejemplo inicia el filtro en Abiertas y prueba solo la función de filtrado. La lista parece correcta, pero cambia el estado inicial y la creación sigue admitiendo un asunto de espacios.
- Qué revisamos
- El docente pide volver a los criterios y mostrar evidencia. El grupo añade una prueba que detecta el asunto en blanco antes de corregirlo, conserva Todas al iniciar y comprueba una lista sin coincidencias y el retorno a Todas. Revisa además los archivos modificados.
- Resultado
- El ejemplo revisado vincula el filtro y la validación con sus pruebas. La entrega reúne un diff pequeño, comandos y resultados, y explica los límites del repositorio docente. En la práctica se contrasta esa evidencia antes de decidir qué aceptar.
Del comportamiento esperado a la evidencia
Contexto
Repositorio Faro
Código y datos de práctica preparados
Dos tareas
Filtro de estado y asunto en blanco
Cambio
Todas al iniciar
Abiertas, Cerradas y estado vacío
Asunto válido
Rechazar entradas de solo espacios
Evidencia
Vitest y Playwright
Regresión y recorrido comprobados
Diff y entrega
Comandos, resultados y límites
Representación didáctica de un caso ficticio. No es un resultado garantizado de Codex; cada cambio debe revisarse y comprobarse en el repositorio.
Antes de darlo por terminado
- El diff responde a las dos tareas y conserva Todas como estado inicial.
- La regresión detecta el fallo previo; las pruebas relevantes cubren entrada vacía, ausencia de resultados y retorno a Todas.
- La entrega permite repetir las comprobaciones y distingue resultados observados de dudas pendientes.
Sesiones para llevarlo a la práctica.
Edición de referencia · 12 h en directo
Edición de referencia: 12 horas en directo, en 6 sesiones de 2 horas. Incluye contexto, reproducción, plan, implementación, regresión y revisión del diff. El repositorio y las herramientas deben funcionar antes de empezar; la entrega queda preparada para revisión.
- Sesión 12 h
Entender el repositorio y el contexto
Recorrer la app, leer instrucciones y localizar lógica, componentes y pruebas; ejecutar las comprobaciones iniciales.
Al terminarUn mapa breve del proyecto y un estado inicial documentado.
- Sesión 22 h
Reproducir y definir lo esperado
Reproducir el asunto de espacios, preparar una prueba que lo detecte y concretar los criterios del filtro.
Al terminarUn fallo reproducible y criterios de aceptación antes de modificar la app.
- Sesión 32 h
Planificar un cambio acotado
Revisar con Codex archivos afectados, pasos y pruebas; cuestionar supuestos y dejar fuera cambios innecesarios.
Al terminarUn plan que relaciona las dos tareas con su implementación y comprobación.
- Sesión 42 h
Implementar y leer los cambios
Añadir el filtro y corregir la validación en la rama de aula; inspeccionar el diff y ajustar el alcance.
Al terminarUna implementación que se puede explicar mediante los criterios acordados.
- Sesión 52 h
Contrastar regresión y casos límite
Ejecutar Vitest y Playwright; probar asuntos vacíos, ausencia de coincidencias y retorno a la lista completa.
Al terminarUn registro de pruebas y correcciones con resultados esperados y observados.
- Sesión 62 h
Revisar el diff y preparar la entrega
Intercambiar la revisión, atender hallazgos y repetir las pruebas afectadas; documentar comandos y límites.
Al terminarUna entrega lista para decidir qué aceptar, corregir o investigar antes de integrar.
Si vuestro equipo necesita ir más allá
- Adaptar el recorrido a un repositorio del equipo requiere revisar previamente lenguaje, dependencias, permisos y datos autorizados.
- Añadir backend, migraciones, despliegue o automatización de CI requiere objetivos y comprobaciones propios.
Aprender con alguien que desarrolla proyectos para empresas.
Borja Martínez
Consultor de The Optimal Flow
Más de dos años de experiencia desarrollando proyectos para empresas de todas las industrias y tamaños.
Borja es el docente previsto para este programa. Las fechas, el idioma y su disponibilidad se confirman al acordar la edición.
Con guía, práctica y acompañamiento.
Cada edición incluye materiales de trabajo, feedback sobre la práctica y evaluación según los objetivos acordados.
Materiales que podéis conservar
Guía, ejercicios y criterios de revisión descargables y versionados, para uso interno.
Para preparar y cerrar la edición
Recomendación breve, kit editable de comunicación e informe de aprendizaje del grupo.
Diploma propio de TOF
De aprovechamiento, al superar la evaluación acordada. No es una certificación del fabricante.
Un mes de soporte por correo
Sobre lo trabajado en clase, hasta dos horas acumuladas para todo el grupo.
La práctica la realiza tu equipo. Los servicios de implantación se acuerdan aparte. Ver el alcance →
