La fábrica de software OpenAI Codex sustituye la programación por la supervisión de agentes
OpenAI ha convertido Codex, en cuestión de meses, de un asistente de programación opcional en la capa operativa detrás de casi todo el trabajo interno. La fábrica de software OpenAI Codex conecta ahora agentes con código, documentación, sistemas de comunicación, infraestructura de pruebas y telemetría de producción.
Esa conclusión proviene de Gergely Orosz, quien visitó la sede de OpenAI y entrevistó a siete ingenieros y líderes de ingeniería. Su relato desde dentro describe una organización en la que los agentes crean, inspeccionan, despliegan y monitorizan software de forma creciente.
El conflicto importante ya no es Codex frente a la velocidad de escritura humana. Es el rendimiento de los agentes frente a la atención humana, los sistemas de revisión y los controles organizativos necesarios para confiar en esa producción.
La experiencia de OpenAI también representa un caso excepcionalmente favorable. Sus empleados tienen amplio acceso a modelos, integraciones internas profundas y equipos dedicados a mejorar el arnés de agentes. La mayoría de las empresas carece de esas condiciones, por lo que la replicación es menos segura de lo que sugieren los resultados de los titulares.
La fábrica de software OpenAI Codex se convierte en el flujo de trabajo predeterminado
El cambio más claro es que Codex ha pasado de ayudar a desarrolladores individuales a coordinar el trabajo en toda OpenAI.
Orosz informa que la transición comenzó alrededor de enero de 2026. En cuatro meses, el uso de Codex entre las organizaciones no técnicas habría pasado de casi nada a aproximadamente el 90 %.
Empleados de finanzas, contratación, legal, marketing e investigación se unieron a los ingenieros en la adopción del sistema. Casi todos los empleados de OpenAI utilizan ahora Codex o ChatGPT Work durante una semana típica, según se informa.
El propio análisis del lugar de trabajo de OpenAI respalda la dirección general de ese relato. La empresa afirma que Codex genera ahora más del 85 % de los tokens de salida del empleado promedio.
Su proporción alcanza el 99 % para el ingeniero promedio, según OpenAI. En toda la empresa, Codex representa presuntamente el 99,8 % de los tokens de salida semanales generados con herramientas de OpenAI.
Esas cifras miden la producción del modelo, no el valor de negocio completado. Aun así, indican que la interfaz para el trabajo interno con IA ha pasado de forma decisiva de la conversación a la ejecución delegada.
Un chatbot suele esperar cada nueva instrucción. Un agente recibe un objetivo, utiliza herramientas, examina resultados y continúa trabajando a través de una secuencia más larga de decisiones.
Esa distinción explica por qué Codex se extendió más allá del desarrollo de software. Investigar un tema, elaborar una presentación, transformar una hoja de cálculo y monitorizar Slack implican artefactos digitales que los agentes pueden manipular mediante software.
OpenAI lanzó su aplicación de escritorio Codex para Mac en febrero de 2026 y amplió la disponibilidad a Windows en marzo. ChatGPT Work, que utiliza el mismo arnés de agentes subyacente, llegó en julio.
La curva de adopción habría comenzado antes de que la interfaz resultara amigable para perfiles no técnicos. Orosz afirma que el uso entre esos empleados se acercó al 40 % mientras el producto seguía mostrando código y presuponiendo familiaridad técnica.
Ese patrón cuestiona una visión común sobre la adopción de IA en el trabajo. Una interfaz refinada fue menos importante que la capacidad de un agente para completar una tarea sustancial y devolver un artefacto utilizable.
El trabajo de mayor duración parece haber acelerado la transición. Orosz informa que el uso interno subió de alrededor del 60 % al 90 % entre abril y mayo, a medida que mejoraban los flujos de trabajo basados en objetivos.
Un empleado puede especificar un resultado y permitir que un agente continúe a través de varios pasos. El sistema también puede delegar subtareas a agentes adicionales, en lugar de exigir que el empleado supervise cada hilo.
OpenAI describe una tendencia similar en el uso externo. Para mayo, el 70,2 % de los usuarios individuales analizados había realizado al menos una solicitud que representaba más de una hora de trabajo humano estimado.
La empresa afirma que el 25,6 % había solicitado trabajo estimado en más de ocho horas. Esas estimaciones procedían de juicios del modelo, por lo que OpenAI aconseja tratarlas como indicativas, no exactas.
La personalización interna importó tanto como una mayor duración de las tareas. Los equipos crearon habilidades y plugins específicos por función que proporcionaban al agente general procedimientos repetibles, herramientas y contexto de dominio.
Esa combinación ayudó a que Codex se convirtiera en infraestructura en lugar de otra aplicación. Los empleados ya no necesitaban traducir cada flujo de trabajo recurrente en una conversación nueva.
La dependencia siguió a la adopción. Orosz informa que incluso interrupciones menores pueden generar quejas internas antes de que la monitorización automatizada alerte a los equipos responsables.
Por tanto, OpenAI ha creado tanto un motor de productividad como un punto compartido de fallo. Cuanto más trabajo fluye a través de un mismo arnés de agentes, mayor es el impacto operativo cuando ese arnés se ralentiza o falla.
Un código más rápido somete la revisión y la entrega a presión
Codex ha reducido el coste de producir código, pero no ha eliminado el coste de validarlo y ponerlo en producción.
Orosz informa de un menor uso de entornos de desarrollo integrados en OpenAI desde enero. Un IDE combina edición de código, navegación, pruebas y depuración en una única interfaz para desarrolladores.
Los ingenieros delegan cada vez más la implementación mediante Codex. Su trabajo se desplaza hacia definir resultados, proporcionar contexto, evaluar los resultados y decidir qué cambios merecen ser desplegados.
Esto modifica el recurso escaso. Cuando un agente puede generar varias implementaciones mientras una persona asiste a una reunión, el tiempo de escritura humana deja de limitar la producción.
La atención se convierte en el cuello de botella. Los ingenieros todavía deben identificar problemas valiosos, reconocer soluciones débiles, resolver ambigüedades y asumir la responsabilidad por los resultados en producción.
Las solicitudes de extracción tradicionales se diseñaron en torno a un flujo más lento de cambios creados por humanos. Ofrecen a los compañeros un paquete delimitado de código para inspeccionar antes de integrarlo en un repositorio compartido.
Ese modelo se tensiona cuando cada ingeniero puede iniciar muchos agentes. Venkat Venkataramani, vicepresidente de ingeniería de infraestructura aplicada de OpenAI, describió el volumen de solicitudes de extracción como creciente a un ritmo acelerado.
La producción adicional no afecta solo a la revisión de código. Cada cambio consume capacidad de compilación, ejecución de pruebas, infraestructura de despliegue, almacenamiento, observabilidad y atención de los revisores.
Los equipos de OpenAI están reconsiderando la integración continua y el despliegue continuo en torno a este mayor volumen. Estos sistemas compilan, prueban y liberan automáticamente los cambios después de que los desarrolladores los envían.
La secuencia anterior asumía que crear código era relativamente costoso. El desarrollo agéntico invierte esa relación porque proponer otro cambio se vuelve barato, mientras demostrar su seguridad sigue siendo costoso.
OpenAI está respondiendo con agentes especializados en revisión. En vez de pedir a un modelo general que inspeccione un cambio, el flujo de trabajo puede asignar perspectivas separadas de seguridad, infraestructura, rendimiento o cumplimiento.
Cada revisor recibe conocimiento relevante del repositorio y normas organizativas. Los cambios de alto riesgo pueden activar revisiones más extensas por agentes y una aprobación humana obligatoria.
Las áreas de menor riesgo pueden utilizar controles más ligeros. Algunos repositorios pueden permitir que un agente apruebe cambios clasificados de forma restringida sin esperar a una persona.
Se trata de un cambio desde pasos de revisión universales hacia un enrutamiento basado en riesgos. También depende de una clasificación precisa, documentación actualizada y controles de acceso fiables.
Este enfoque presiona a las organizaciones que aún miden la adopción de IA mediante sugerencias aceptadas o encuestas a desarrolladores. Esas medidas pasan por alto los costes posteriores creados por código adicional y una experimentación más rápida.
Un equipo puede integrar más solicitudes de extracción sin mejorar los resultados para los clientes. También puede generar más obligaciones de mantenimiento, ruido operativo e inconsistencia arquitectónica.
La entrega de aplicaciones móviles nativas expone claramente esa brecha. OpenAI puede generar rápidamente un cambio en una aplicación, pero las actualizaciones significativas de iOS y Android aún pasan por procesos de revisión externos.
La aprobación de las tiendas de aplicaciones puede tardar horas o días. Por ello, más cambios generados por agentes se acumulan detrás de un sistema de distribución que los agentes no controlan.
El mismo desajuste aparece dentro de las empresas. Las evaluaciones de seguridad, los comités de gestión de cambios, las revisiones de cumplimiento y la validación de clientes rara vez se aceleran simplemente porque la implementación se volvió más rápida.
Los competidores afrontan la misma presión estructural. La investigación de Anthropic sobre aproximadamente 400.000 sesiones de Claude Code concluyó que los humanos seguían tomando la mayoría de las decisiones de planificación, mientras el agente gestionaba más decisiones de ejecución.
Su estudio de uso también concluyó que la experiencia de dominio seguía asociada a un mayor éxito. Los agentes de programación cambiaron la distribución del trabajo sin volver irrelevante el juicio.
Por tanto, la competencia emergente no es OpenAI Codex contra Claude Code en benchmarks aislados de programación. Es qué organización puede rediseñar todo su sistema de entrega en torno a una ejecución abundante por máquinas.
OpenAI posee actualmente una ventaja importante porque desarrolla conjuntamente los modelos, los productos y el entorno interno. Puede ajustar el agente cuando sus propios flujos de trabajo revelan una debilidad.
Los compradores empresariales deben integrar agentes en repositorios, controles y cadenas de aprobación heredados. Su factor limitante será a menudo la preparación organizativa, más que el acceso a modelos.
La fábrica funciona mediante contexto y ciclos de retroalimentación
El modelo de OpenAI se asemeja a una fábrica porque los agentes participan durante todo el ciclo de producción, no porque la generación de código sea totalmente autónoma.
El proceso comienza con una persona que define el resultado deseado. Esa persona decide qué problema importa, qué restricciones se aplican y qué debe lograr un resultado aceptable.
Codex recopila entonces contexto de repositorios, documentación, Slack, Notion, registros, sistemas de monitorización y fuentes de datos internas. Esa fase de recuperación determina qué puede comprender el agente antes de cambiar nada.
OpenAI habría acercado la documentación al código fuente. Esto facilita que tanto los agentes como los ingenieros encuentren conocimiento operativo dentro del repositorio.
El agente implementa un cambio, ejecuta pruebas, corrige fallos y abre una solicitud de extracción. Puede continuar monitorizando la solicitud y responder cuando las comprobaciones automatizadas identifican problemas.
Los cambios sensibles al rendimiento pueden entrar en una evaluación adicional. Un arnés de rendimiento somete compilaciones seleccionadas a comparaciones controladas para detectar regresiones antes del despliegue.
Después, múltiples agentes de revisión inspeccionan el trabajo desde distintas perspectivas de dominio. Su valor procede de instrucciones enfocadas y del acceso a conocimiento específico de OpenAI, no de adoptar simplemente etiquetas de expertos.
El flujo de trabajo clasifica los cambios por riesgo. Esa clasificación determina si el cambio necesita más revisiones por agentes, una decisión humana o una vía de aprobación más sencilla.
Un humano todavía aprueba el despliegue en producción en el proceso documentado por Orosz. Tras la aprobación, otro agente sigue el cambio durante su lanzamiento y observa sus señales operativas.
Ese agente de despliegue puede localizar una marca de funcionalidad, interpretar el cambio, seleccionar métricas de éxito y crear un panel de monitorización. Después observa el lanzamiento en busca de indicios de problemas.
El comportamiento en producción retroalimenta el nuevo desarrollo. La Perf Factory de OpenAI, según se informa, agrupa alertas, identifica regresiones de latencia, investiga causas probables y propone correcciones.
Otro sistema interno, Sevbot, ayuda durante los incidentes de servicio. Recopila contexto, sugiere mitigaciones y responde preguntas dentro del canal de respuesta.
Hoy, Sevbot no ejecuta de forma independiente las mitigaciones que propone. Un ingeniero debe autorizar una acción específica, preservando una decisión humana en un límite de alto riesgo.
Todo este ciclo es más importante que cualquier respuesta individual del modelo. Los agentes reciben contexto estructurado, operan mediante herramientas restringidas, se enfrentan a pruebas automatizadas y devuelven evidencia a etapas posteriores.
OpenAI denomina arnés al sistema circundante. Un arnés conecta el modelo con herramientas, datos, permisos, entornos de ejecución, memoria y mecanismos de retroalimentación.
El anterior experimento de arnés de la empresa ilustra por qué esta ingeniería importa. Un equipo afirma que Codex produjo cada línea de un producto interno que contiene aproximadamente un millón de líneas de código.
OpenAI estimó que el proyecto requirió cerca de una décima parte del tiempo necesario para una implementación manual. Sigue siendo una estimación de la empresa procedente de un proyecto interno desarrollado desde cero, no una referencia independiente del sector.
La enseñanza más reveladora fue que los agentes requerían un entorno legible. El conocimiento del repositorio necesitaba una organización clara, las pruebas debían proporcionar retroalimentación útil y las restricciones arquitectónicas requerían una aplicación verificable por máquinas.
Los ingenieros también tuvieron que eliminar el desorden acumulado. Un agente puede reproducir patrones obsoletos rápidamente cuando el repositorio presenta esos patrones como ejemplos válidos.
Por tanto, un alto rendimiento aumenta la importancia de lo que OpenAI denomina recolección de basura. Los equipos deben eliminar documentación obsoleta, abstracciones duplicadas, código muerto y convenciones inconsistentes antes de que se acumulen.
Posteriormente, OpenAI desarrolló Symphony, una especificación de orquestación que conecta agentes de programación con un gestor de incidencias. Cada tarea apta puede recibir un espacio de trabajo dedicado y un agente que sigue trabajando hasta completarla.
La empresa afirma que su flujo de trabajo Symphony produjo un aumento del 500 por ciento en pull requests integradas para algunos equipos durante las primeras tres semanas.
De nuevo, el volumen de pull requests es una medida de producción, no una medida de valor para el cliente. Sin embargo, el experimento identifica otro cuello de botella importante: a las personas les cuesta supervisar simultáneamente muchas sesiones interactivas de agentes.
OpenAI afirma que la mayoría de los ingenieros podía gestionar cómodamente entre tres y cinco sesiones antes de que el cambio de contexto se volviera doloroso. Symphony traslada la supervisión de las sesiones individuales a los estados de las tareas y los entregables.
El gestor de incidencias se convierte en un plano de control. Los agentes toman trabajo sin bloqueos, se reinician tras fallos, crean tareas de seguimiento y mantienen la ejecución entre repositorios.
Los humanos inspeccionan planes, prioridades y resultados terminados en lugar de volver a dar instrucciones a cada sesión repetidamente. Ese patrón sitúa al ingeniero un nivel por encima de la implementación.
También cambia lo que hace que una organización esté preparada para el desarrollo agéntico. Los buenos tickets, la documentación actualizada, los sistemas observables y las pruebas deterministas se convierten en infraestructura de producción.
Los equipos que exploran flujos de trabajo similares necesitan una fuente fiable de contexto organizacional. Una base de conocimiento de ingeniería consultable puede ayudar, aunque la recuperación de información por sí sola no crea automatización fiable.
Por tanto, la metáfora de la fábrica debe usarse con cuidado. OpenAI no ha eliminado a las personas del desarrollo de software, y sus decisiones más sensibles siguen conservando control humano.
En cambio, ha automatizado una mayor parte del camino entre la intención y la evidencia. El trabajo humano se desplaza hacia diseñar ese camino, evaluar sus resultados y mantener sus restricciones.
La historia de productividad aún tiene una brecha de verificación
La evidencia interna de OpenAI es llamativa, pero todavía no demuestra que la mayoría de las empresas pueda reproducir las mismas ganancias de forma segura.
OpenAI opera con ventajas inusuales. Sus empleados pueden utilizar una amplia capacidad de cómputo, grandes presupuestos de tokens, modelos internos avanzados y acceso directo a los equipos que desarrollan Codex.
El sistema interno también se conecta con repositorios de la empresa, herramientas de comunicación, datos operativos y documentación. Los clientes públicos reciben un producto más acotado con menos integraciones específicas de la organización.
Esa diferencia importa porque los agentes dependen del contexto. Un agente conectado a documentación incompleta o permisos fragmentados producirá resultados distintos de los de uno integrado en todo un laboratorio de modelos.
Las cifras de OpenAI también hacen hincapié en el uso y la producción. La proporción de tokens, el volumen de pull requests y las líneas de código revelan actividad, pero no miden directamente la fiabilidad, la satisfacción del cliente ni el coste total de mantenimiento.
Incluso las estimaciones de tiempo requieren cautela. Las afirmaciones de OpenAI sobre tareas de larga duración utilizan un modelo para estimar el esfuerzo humano equivalente, en lugar de registrar a una persona realizando la misma asignación.
La evidencia independiente sigue siendo mixta. Un estudio aleatorizado de METR concluyó que desarrolladores experimentados de código abierto tardaron un 19 por ciento más al utilizar herramientas de IA de principios de 2025 en repositorios conocidos.
La prueba con desarrolladores contó con 16 desarrolladores que completaron 246 tareas. Los participantes habían trabajado con sus respectivos repositorios durante unos cinco años de media.
Ese experimento capturó herramientas anteriores y tareas de aproximadamente 20 minutos a cuatro horas. No prueba los flujos de trabajo de 2026, de mayor duración, descritos dentro de OpenAI.
El contraste sigue ofreciendo una advertencia útil. La capacidad del modelo, la forma de la tarea, el diseño del repositorio, la experiencia del usuario y el coste de verificación pueden invertir el resultado aparente de productividad.
El entorno de OpenAI ha sido rediseñado para agentes. Muchas empresas inicialmente colocarán un agente dentro de sistemas optimizados para humanos y luego se preguntarán por qué el resultado sigue siendo poco fiable.
La seguridad crea otro problema de replicación. Un agente útil necesita acceso al código fuente, las credenciales, los sistemas de comunicación, las herramientas de despliegue y la información de producción.
Cada nueva conexión amplía el posible impacto de los errores o de las instrucciones manipuladas. La inyección de prompts puede ocultar directrices hostiles dentro de documentos, sitios web, mensajes o resultados de herramientas que un agente lee.
OpenAI afirma que limita estos riesgos mediante sandboxing, políticas de red gestionadas, autenticación centralizada, reglas de comandos y telemetría detallada. Sus protecciones de Codex bloquean el acceso abierto a la red y requieren aprobación para destinos desconocidos.
La empresa también registra los prompts, la actividad de las herramientas, las aprobaciones y las decisiones de las políticas de red. Los equipos de seguridad pueden combinar esos registros con alertas de endpoints para reconstruir por qué un agente realizó una acción inusual.
Esos controles forman parte del producto, no son decoración administrativa opcional. Un agente rápido con permisos amplios puede convertir un pequeño malentendido en una rápida serie de acciones con consecuencias.
La automatización de la revisión introduce su propia incertidumbre. Un agente especializado puede detectar defectos que un humano ocupado pasa por alto, especialmente cuando puede inspeccionar cada cambio de forma consistente.
Sin embargo, varios agentes que utilizan modelos relacionados pueden compartir los mismos puntos ciegos. El acuerdo entre revisores automatizados no garantiza que un cambio sea correcto.
Los equipos también corren el riesgo de caer en el sesgo de automatización. Los revisores pueden examinar con menos cuidado los cambios aprobados por máquinas porque el proceso parece exhaustivo.
La fábrica también puede debilitar la comprensión compartida. Tradicionalmente, los ingenieros aprenden los sistemas al implementar funciones, depurar fallos y revisar las decisiones de sus colegas.
Cuando los agentes realizan una mayor parte de ese trabajo, las organizaciones necesitan otra forma de preservar el conocimiento arquitectónico. De lo contrario, los humanos pueden conservar la autoridad de aprobación mientras pierden el contexto necesario para ejercerla.
La respuesta comunicada por OpenAI es un mayor énfasis en el criterio, el juicio y la capacidad de actuación. Esas cualidades ayudan a los ingenieros a especificar mejores resultados y rechazar implementaciones plausibles pero indeseables.
Sin embargo, son difíciles de evaluar y enseñar. Históricamente, los ingenieros junior han desarrollado juicio mediante tareas de implementación más pequeñas que los agentes absorben cada vez más.
Por tanto, las implicaciones a largo plazo para la contratación siguen sin resolverse. Los flujos de trabajo agénticos pueden ampliar lo que logra un ingeniero experimentado y, al mismo tiempo, estrechar las vías tradicionales de entrada a la profesión.
El caso de OpenAI tampoco debe reducirse a la sustitución de empleos. El sistema documentado sigue dependiendo de las personas para la priorización, la experiencia en el dominio, la aceptación de riesgos y la autoridad sobre incidentes.
El cambio inmediato es más concreto. Las organizaciones pueden generar trabajo propuesto más rápido de lo que sus sistemas de gobernanza, infraestructura y aprendizaje pueden absorber.
Eso hace decisiva la calidad de los ciclos de retroalimentación. Las pruebas débiles y la documentación desactualizada permiten que los errores se propaguen rápidamente, mientras que los controles sólidos convierten los intentos fallidos en información útil.
La afirmación central es creíble en su dirección, pero incompleta en su alcance. OpenAI ha mostrado hasta qué punto un agente puede transformar una empresa diseñada para respaldarlo.
Todavía no ha demostrado que la misma arquitectura siga siendo económica, segura y mantenible en empresas ordinarias con sistemas fragmentados y experiencia limitada en IA.
Tres señales mostrarán si el modelo se traslada
La próxima prueba es si OpenAI puede convertir su modelo operativo interno en un sistema repetible para los clientes sin transferir un riesgo inaceptable.
La primera señal es una evidencia más amplia sobre los resultados. Los compradores deberían buscar cambios medidos en el tiempo de ciclo, los incidentes, las tasas de reversión, el impacto en los clientes y el esfuerzo de mantenimiento.
Más código no basta. La fábrica de software OpenAI Codex solo será convincente fuera de la sede central cuando equipos independientes mejoren la entrega sin aumentar los defectos ni la carga operativa.
La evidencia más sólida compararía equipos similares antes y después de la adopción. Debería incluir el tiempo dedicado a revisar, corregir y mantener cambios generados por agentes.
La segunda señal es cómo evolucionan los controles de revisión y despliegue. La arquitectura actual de OpenAI aún sitúa a los humanos en límites seleccionados de producción y respuesta a incidentes.
Las futuras versiones revelarán qué decisiones se vuelven autónomas y cuáles siguen siendo deliberadamente humanas. La ubicación de esos límites definirá el modelo práctico de riesgo del sistema.
Observe si los paneles generados por agentes, las revisiones especializadas y las clasificaciones de riesgo detectan fallos que los controles existentes pasan por alto. Observe también si los puntos ciegos comunes de los modelos generan fallos de revisión correlacionados.
La tercera señal es la respuesta competitiva de Anthropic, Google, Microsoft y los proveedores de software empresarial. Cada uno tiene un incentivo para controlar la interfaz donde las personas delegan trabajo.
Anthropic ya ha conectado agentes Claude de larga duración a entornos de desarrollo y flujos de trabajo empresariales. Google y Microsoft pueden combinar agentes con grandes suites de productividad, plataformas en la nube y sistemas de identidad.
El premio estratégico va más allá de la generación de código. El sistema ganador puede convertirse en la capa de control que lee el contexto organizacional, distribuye tareas y devuelve artefactos completados.
Esa posición crea costes de cambio sustanciales. Las habilidades, los permisos, las políticas de revisión, el conocimiento institucional y el historial de flujos de trabajo se acumulan en torno al arnés elegido.
También concentra la dependencia operativa. Una regresión del modelo, una interrupción del servicio, un defecto de seguridad o un cambio de política pueden interrumpir el trabajo de muchos departamentos simultáneamente.
Por tanto, la adopción empresarial dependerá tanto de la portabilidad y la auditabilidad como de la capacidad bruta. Los compradores necesitan entender a qué accedió un agente, qué decidió, qué cambió y qué entregó a otro agente.
Los estándares abiertos para habilidades, conexiones de herramientas, trazas y evaluación reducirían la dependencia de un único proveedor. Las integraciones internas cerradas pueden ofrecer avances más rápidos, pero dificultan la migración.
El papel de los ingenieros seguirá siendo la cuarta pregunta, de más largo plazo, detrás de estas tres señales. Los empleados de OpenAI dedican menos tiempo a producir código directamente y más a dirigir sistemas.
Eso no elimina la experiencia en ingeniería. Cambia el punto del proceso en que interviene, desplazándola hacia la especificación, la arquitectura, la evaluación, la seguridad y el criterio operativo.
Las organizaciones más capaces no se limitarán a añadir un agente a un flujo de trabajo antiguo. Decidirán qué conocimiento debe volverse legible para las máquinas y qué decisiones deben seguir siendo responsabilidad de las personas.
También medirán los experimentos descartados, el coste de revisión y la recuperación ante fallos. Una implementación barata no lo es cuando genera una incertidumbre costosa más adelante.
La visita de Orosz capta una transición importante mientras aún está tomando forma. OpenAI ya no utiliza Codex únicamente para ayudar a los ingenieros a desarrollar software más rápido.
Está reorganizando la producción de software en torno a agentes que recopilan contexto, ejecutan tareas, revisan cambios, supervisan despliegues y aprenden de las señales de producción.
El resultado es una fábrica de software basada en agentes, pero no una fábrica oscura sin humanos. Las personas siguen eligiendo los objetivos, definiendo las restricciones, aceptando riesgos e interviniendo cuando los sistemas se comportan de forma inesperada.
La pregunta práctica para los lectores no es si deben copiar de inmediato el flujo de trabajo de OpenAI. Es qué parte de su sistema de entrega se convierte en el cuello de botella cuando la implementación se abarata drásticamente.
Empiece por identificar un flujo de trabajo acotado, con resultados medibles, pruebas fiables, contexto actualizado y acciones reversibles. Después, mida toda la carga de revisión y mantenimiento, no solo la velocidad visible del agente.
Si ese experimento tiene éxito, amplíe el sistema de retroalimentación antes de ampliar la autonomía. La fábrica de software de OpenAI Codex sugiere que los agentes escalan mediante mejores entornos, mientras que el criterio humano determina si su resultado merece llegar a producción.
