La IA para empresas avanza solo hasta donde la usa su líder: según Shensi Ding, CEO de Merge, si un ejecutivo no adopta la inteligencia artificial en su día a día, ese es el techo de fluidez de toda la organización. En una entrevista publicada por OpenAI el 28 de octubre de 2026, Ding cuenta que dirige el lado no técnico de su empresa y, aun así, escribe código todos los días con Codex.
La frase que resume su postura es directa: “si eres un ejecutivo, eres el techo de la fluidez en IA de tu organización”. No es una declaración de marketing. Ding empezó la empresa escribiendo código a mano, sin IA, y tuvo que reaprender cuando estas herramientas aparecieron. Hoy usa Codex para rediseñar funcionalidades de su propio producto y para entender, desde adentro, dónde su negocio puede moverse más rápido.
Ese detalle cambia la conversación. La discusión habitual sobre adopción de IA en una empresa mediana gira alrededor del presupuesto, las licencias o el proveedor. La experiencia de Merge sugiere que el factor decisivo es otro: cuánto entiende el que decide. En este artículo veremos qué hizo Ding concretamente, qué significa para equipos no técnicos y qué puede hacer una empresa peruana esta misma semana.
¿Qué hizo exactamente Shensi Ding con Codex?
Ding necesitaba rediseñar una funcionalidad de su producto y no encontraba el mejor camino. En lugar de convocar una reunión de diseño, se sentó a trabajar con Codex. Le pidió que tomara inspiración de otras partes del producto para entender cómo se ve el sistema de diseño de la compañía y que diera su mejor intento.
El resultado la sorprendió por una razón específica. Según su testimonio, otros sistemas de IA suelen “olvidar” y ejecutar solo la última instrucción recibida. Codex, en cambio, recorrió cada tarea pendiente, las ejecutó una por una y rellenó con sentido común los huecos que ella no había especificado.
Esa diferencia parece técnica, pero es profundamente práctica. En una empresa mediana, el trabajo rara vez llega con instrucciones perfectas. Llega con un correo a medias, una captura de pantalla y una idea vaga. Un asistente que exige especificaciones completas es inútil en ese contexto. Un asistente que infiere lo obvio a partir del contexto se vuelve utilizable.
Ding lo describe como una experiencia de “best shot”: pedirle a la herramienta que intente su mejor versión con lo que tiene. Es la diferencia entre una calculadora y un colega junior con criterio.
¿Por qué los equipos no técnicos son los más beneficiados?
El segundo hallazgo de la entrevista es el que más debería interesar a un gerente en Perú. Ding afirma que estas herramientas han sido “especialmente geniales” para los miembros de su equipo que no están en ingeniería, porque ahora pueden construir lo que necesiten sin esperar a que otro los ayude.
Antes, el proceso era siempre el mismo: alguien de ventas, marketing o finanzas detectaba una fricción, escribía el pedido, lo mandaba al área de sistemas y esperaba su turno. Ese turno podía tardar días. Y cuando por fin llegaba la solución, muchas veces ya no era lo que se necesitaba.
Ahora la lógica es distinta. La persona piensa en el flujo que le ayudaría, lo describe y lo construye ella misma. Ding lo resume así: “pueden pensar en algo y un flujo de trabajo que les sería realmente útil, e inmediatamente crearlo para sí mismos”.
Esto conecta directamente con el mundo de los agentes de IA. Un agente no es un chatbot que responde preguntas: es un sistema que ejecuta una secuencia de pasos para cumplir un objetivo. Cuando alguien de operaciones arma un agente que revisa pedidos, avisa al vendedor y actualiza una hoja de cálculo, acaba de programar sin saber programar.
En la práctica, esto se traduce en automatización con IA al alcance de quien sufre el problema, no de quien tiene el conocimiento técnico. Y libera al equipo de desarrollo para lo que de verdad lo necesita: el sistema central, la integración crítica, la arquitectura.
Mi lectura, con una advertencia honesta: la entrevista no demuestra que cualquiera pueda construir software crítico sin criterio técnico. Ding habla de flujos internos y herramientas de apoyo, no de reemplazar a un equipo de ingeniería. Tampoco ofrece métricas de ahorro ni de calidad. Lo que muestra es una dirección, no una garantía. Una empresa que abra esta puerta sin gobierno, sin revisión y sin datos claros puede terminar con veinte herramientas sueltas que nadie mantiene.
¿Qué significa esto para una empresa en Perú o Latinoamérica?
En una PYME peruana típica, el área de TI es pequeña y está saturada. El jefe de sistemas tiene una cola de pedidos que va desde “arreglar el reporte de ventas” hasta “integrar el facturador con el ERP”. Todo compite por las mismas horas. Cuando un pedido pequeño entra a esa cola, no compite en igualdad de condiciones: siempre pierde frente a lo urgente.
Ese es exactamente el cuello de botella que la entrevista pone sobre la mesa. Si la contadora puede construir su propio flujo para conciliar cobranzas, el jefe de TI deja de ser un cuello de botella y vuelve a ser un arquitecto. Si el gerente comercial puede armar un tablero de seguimiento sin abrir un ticket, la información llega el mismo día en que se necesita.
Hay un matiz local que conviene no ignorar. En muchas empresas de la región, la cultura de “eso lo ve sistemas” está muy instalada. Cambiarla no depende de comprar una herramienta, sino de que alguien con autoridad la use primero. Y ahí volvemos a Ding: el techo lo pone el líder. Si el gerente general nunca abre la herramienta, el mensaje que envía al equipo es que la IA es un tema de otros.
También hay una oportunidad concreta con los sistemas de gestión. En empresas que ya trabajan con un ERP como Odoo, los datos ya están ordenados y disponibles. Eso hace que cualquier automatización construida encima tenga sentido: hay información confiable que leer y reglas claras que ejecutar. Sin esa base, el agente más brillante trabaja sobre el desorden.
¿Cómo aplica esto en tu empresa?
El primer paso no es técnico, es de comportamiento. Elige un proceso que hoy te haga perder tiempo cada semana y constrúyelo tú mismo, aunque no quede perfecto. No delegues el primer experimento: hazlo. La razón es simple, si no entiendes qué puede y qué no puede hacer la herramienta, no vas a poder dirigir a nadie que la use.
El segundo paso es abrir la puerta a los equipos no técnicos con reglas claras. Define qué tipo de automatizaciones se pueden construir libremente (recordatorios, reportes internos, seguimiento de tareas) y qué tipo requiere revisión de TI (todo lo que toque datos de clientes, facturación o sistemas productivos). Sin ese límite, el entusiasmo se convierte en riesgo.
El tercer paso es medir. Antes de empezar, anota cuánto demora hoy el proceso que quieres mejorar. Después de automatizarlo, vuelve a medirlo. Sin ese número no sabrás si ganaste algo o solo cambiaste de problema. Si quieres revisar cómo se ve esto en tu caso particular, puedes conversar con nosotros sobre tu caso y ordenar el punto de partida.
Y si tu interés está en construir flujos que se ejecuten solos, vale la pena conocer ContentFlow, nuestro enfoque de automatización de contenido y procesos.
Preguntas Frecuentes
¿Qué es Codex y para qué sirve en una empresa?
Codex es la herramienta de programación asistida por IA de OpenAI. En una empresa sirve para dos cosas concretas: acelerar el desarrollo de software y permitir que personas sin perfil de ingeniería construyan flujos de trabajo internos. Según el testimonio de Shensi Ding, CEO de Merge, su valor está en que ejecuta tareas en secuencia y completa con sentido común lo que el usuario no especificó.
¿Puede una persona sin conocimientos de programación crear sus propias herramientas con IA?
Sí, siempre que se trate de herramientas internas de apoyo: recordatorios, reportes, seguimiento de tareas o flujos simples. Ding afirma que esta capacidad ha sido especialmente valiosa para los miembros de su equipo que no están en ingeniería, porque ya no dependen de otro para resolver sus propias necesidades. Lo que no reemplaza es el criterio técnico para sistemas críticos, integraciones con facturación o arquitectura de datos.
¿Cómo empiezo a usar agentes de IA en una PYME peruana?
Empieza por un solo proceso doloroso y medible, no por un proyecto grande. Documenta cómo se hace hoy, cuánto tiempo toma y quién lo sufre. Luego construye una primera versión con la herramienta disponible y pruébala en paralelo al proceso manual durante unas semanas. Si el resultado es mejor y más rápido, recién ahí extiéndelo a otras áreas. El orden importa: primero el hábito, después la escala.
Conclusión: ¿quién debería dar el primer paso con IA en tu empresa?
La entrevista de Merge deja una idea incómoda y útil: la adopción de IA en una organización no se decide en un comité, se decide en la agenda del que manda. Ding codea todos los días no porque le toque, sino porque entiende que su nivel de fluidez marca el límite de lo que su equipo se atreve a intentar.
Para una empresa peruana, eso significa que el primer experimento no debería esperar al área de TI. Debería empezar en el escritorio de quien tiene la autoridad para cambiar cómo se trabaja. Un proceso, una persona, un resultado medible.
Si quieres definir por dónde empezar en tu empresa, conversemos sobre tu caso.
Por Edgar Vásquez, Consultoría TI · actualizado el 30 de octubre de 2026
Fuentes y Referencias
- OpenAI (YouTube) — Why Merge CEO Shensi Ding stays hands-on with Codex, publicado el 28 de octubre de 2026.
- Subvolts — resumen y análisis de la entrevista a Shensi Ding.
- The Split — Rebuilding Merge for the AI Era, con Shensi Ding.
✨ Contenido generado con ContentFlow — Consultoría-Ti