La próxima guerra de la IA no es el chatbot: es tu workflow

Durante los últimos años hemos hablado mucho de chatbots. ChatGPT, Claude, Gemini, Copilot, Perplexity o Grok se han convertido en herramientas habituales para preguntar, resumir, traducir, programar, documentar o desbloquear ideas. Una caja de texto, una pregunta y una respuesta.

Pero la siguiente batalla de la IA no va solo de quién responde mejor. Va de algo bastante más importante: quién consigue quedarse dentro de tu forma de trabajar.

La IA ya no quiere ser una pestaña más del navegador. Quiere leer tus documentos, entender tu repositorio, modificar archivos, crear presentaciones, generar webs, automatizar el navegador, conectarse a tus herramientas y trabajar en tareas largas mientras tú haces otra cosa.

La guerra ya no es solo el chatbot. Es el workflow.

De una conversación a una tarea completa#

La primera etapa de la IA fue muy sencilla: preguntar algo y recibir una respuesta. Después llegó una segunda fase en la que empezamos a pedirle código, emails, resúmenes, estructuras de documentos o ideas de producto.

Pero ahora estamos entrando en una fase distinta. Ya no pedimos solamente “explícame este error” o “hazme esta función”. Cada vez es más normal pedir algo parecido a esto:

Revisa este repositorio, crea un plan, modifica los archivos necesarios,
pasa los tests, prepara el PR y resume los riesgos.

Eso ya no es una conversación. Es una tarea de trabajo. Y una tarea necesita contexto, permisos, herramientas, memoria, validaciones y límites.

Por eso las empresas de IA no están compitiendo solo por tener el mejor modelo. Están compitiendo por controlar la capa donde ocurre el trabajo: el editor, el navegador, los documentos, el repositorio, las automatizaciones y las integraciones.

OpenAI, Anthropic y Perplexity van hacia el mismo sitio#

OpenAI está empujando cada vez más la unión entre ChatGPT, Codex y herramientas profesionales. La idea de fondo es clara: que la IA no solo responda preguntas, sino que participe en tareas completas relacionadas con código, documentos, análisis, creación de contenido y trabajo diario.

Anthropic está siguiendo una dirección parecida con Claude Code y enfoques tipo coworker. Claude Code no se siente como un chatbot tradicional: se siente más como una herramienta que entra en el repositorio, lee contexto, propone cambios, edita archivos, ejecuta comandos y explica qué ha hecho.

Perplexity, que empezó destacando como buscador con IA, también está moviéndose hacia herramientas más orientadas a trabajo y desarrollo. El mensaje del mercado parece bastante claro: dar respuestas ya no es suficiente; el valor está en ayudar a terminar tareas.

El workflow vale más que la respuesta#

Una buena respuesta puede ahorrarte minutos. Un workflow bien integrado puede ahorrarte horas. La diferencia no está solo en la calidad del texto generado, sino en la continuidad del proceso.

Antes, muchas tareas con IA tenían demasiada fricción: buscar información, copiar contexto, pegarlo en un chat, recibir una respuesta, adaptarla, probarla, corregir errores, documentar el cambio y repetir. Era útil, pero seguía estando fuera del flujo real.

Un agente integrado puede hacer algo más cercano a esto:

1. leer el contexto del proyecto
2. proponer un plan
3. aplicar un cambio pequeño
4. ejecutar validaciones
5. resumir el diff
6. dejar una tarea o PR listo para revisar

Ese salto es importante. La IA deja de estar al lado del trabajo y empieza a estar dentro del trabajo.

Pero entrar en el workflow tiene un precio#

Cuanto más útil es un agente, más permisos necesita. Y cuanto más permisos necesita, más riesgos aparecen. No es lo mismo pedirle a una IA que te explique una función que darle acceso para leer archivos, modificar código, navegar, conectarse a APIs o ejecutar comandos.

Ahí empiezan las preguntas serias: qué puede leer, qué puede modificar, qué no debería tocar, qué acciones requieren confirmación, qué logs quedan, qué datos salen fuera, cuánto cuesta cada tarea y cómo se audita lo que ha hecho.

La IA dentro del workflow no es solo productividad. También es seguridad, arquitectura, gobierno del dato, costes y dependencia de proveedor.

Por eso no me convence la idea de “darle permiso a todo y que trabaje”. Un agente útil no debería ser un agente sin límites. Debería ser justo lo contrario: una herramienta potente, pero con contexto claro, permisos definidos y revisión humana en los puntos importantes.

El nuevo lock-in no será solo el modelo#

Durante mucho tiempo hemos hablado del lock-in de modelo: depender demasiado de GPT, Claude, Gemini o cualquier proveedor concreto. Pero quizá el lock-in más fuerte no sea el modelo. Quizá sea el workflow.

Si todo tu equipo trabaja dentro de una herramienta concreta, con sus agentes, conectores, permisos, automatizaciones, memoria, historial y forma de organizar tareas, cambiar de proveedor será mucho más difícil que cambiar de modelo.

El modelo se puede sustituir. El hábito de trabajo, no tanto.

Por eso van a ser importantes las herramientas que permitan cierto margen de maniobra: BYOK, soporte para varios modelos, estándares abiertos, exportación de contexto, integración con MCP, workflows auditables y permisos claros.

No siempre serán las opciones más cómodas. Pero probablemente serán las que te den más control.

Qué debería controlar un developer#

Si una herramienta de IA va a entrar en tu flujo de desarrollo, conviene mirarla como parte de tu stack, no como un juguete. Yo revisaría estas capas:

Modelo
↓
Herramienta
↓
Contexto
↓
Permisos
↓
Acciones
↓
Validación
↓
Auditoría

Y me haría preguntas muy concretas: ¿puedo cambiar de modelo?, ¿puedo limitar carpetas?, ¿puedo impedir acciones destructivas?, ¿puedo ver qué archivos tocó?, ¿puedo exigir tests?, ¿puedo revisar antes de ejecutar?, ¿puedo separar análisis de modificación?, ¿puedo apagarlo sin romper mi forma de trabajar?

Si la respuesta a todo es “no”, quizá no tienes una herramienta. Tienes una dependencia.

El futuro no será elegir una sola IA#

No creo que el futuro del desarrollo sea elegir una única herramienta de IA y usarla para todo. Lo más realista es que acabemos con un stack de trabajo compuesto por varias piezas.

Copilot puede seguir teniendo sentido para autocompletado rápido. Claude Code puede encajar muy bien en tareas complejas dentro de un repositorio. Codex puede ser útil para planificación, generación, revisión o integración con entornos de trabajo. OpenCode puede aportar una capa más abierta con BYOK y varios proveedores. n8n puede seguir siendo muy potente para automatizaciones. MCP puede servir como estándar para exponer capacidades reales a agentes.

La pregunta dejará de ser “cuál es la mejor IA” y pasará a ser otra mucho más interesante:

> ¿qué parte de mi workflow quiero delegar y bajo qué límites?

Lo que sí delegaría#

Delegaría tareas con riesgo controlable y revisión clara: resumir documentación, generar tests iniciales, detectar deuda técnica, revisar errores comunes, preparar borradores, analizar logs, proponer planes, crear scaffolding, buscar inconsistencias o documentar módulos.

Son tareas donde la IA puede aportar mucho, sobre todo si tiene contexto suficiente y si el resultado pasa por revisión humana antes de convertirse en una decisión final.

También delegaría tareas repetitivas que consumen tiempo pero no requieren una decisión crítica: preparar estructuras iniciales, comparar cambios, generar checklists, crear resúmenes, revisar convenciones o lanzar validaciones.

Lo que no delegaría sin control#

No delegaría alegremente deploys a producción, borrado de datos, cambios de permisos, migraciones críticas, pagos o devoluciones, decisiones legales, respuestas finales a clientes, cambios grandes de arquitectura, modificación de secretos o creación de usuarios administradores.

Cuanto mayor sea el impacto de una acción, más humano debe haber en el bucle. La IA puede proponer, preparar y ayudar, pero no debería decidir sola en zonas donde un error puede tener consecuencias serias.

La productividad está bien. La irresponsabilidad automatizada, no.

El rol del developer cambia#

Si la IA entra de verdad en el workflow, el developer no desaparece. Pero sí cambia parte del trabajo. Habrá menos tiempo dedicado a escribir código repetitivo y más tiempo dedicado a definir intención, revisar cambios, diseñar límites, validar resultados, proteger arquitectura y decidir qué no debe hacerse.

Eso exige más criterio, no menos. Porque una IA con permisos puede ir muy rápido, pero alguien tiene que saber si va en la dirección correcta.

El developer que mejor use estas herramientas no será necesariamente quien escriba el prompt más largo. Será quien sepa dividir tareas, limitar alcance, revisar resultados, medir riesgo y mantener control sobre el sistema.

Conclusión#

La IA ya no quiere ser una caja de texto. Quiere estar en tu escritorio, en tu repo, en tus documentos, en tu navegador, en tus tareas y en tus automatizaciones.

Eso puede ser muy potente. Pero también exige pensar mejor, porque cuando una herramienta entra en tu workflow deja de ser un juguete y empieza a parecerse bastante a infraestructura.

La próxima guerra de la IA no será solo por quién tiene el mejor chatbot. Será por quién controla la capa donde trabajas.

Y ahí conviene entrar con los ojos abiertos: aprovechar la productividad, sí; entregar el control completo, no.

Fuentes#

• Reuters: OpenAI launches ChatGPT Work: https://www.reuters.com/business/openai-launches-chatgpt-work-2026-07-09/
• Business Insider: OpenAI makes its biggest play for the office: https://www.businessinsider.com/openai-codex-chatgpt-app-releases-gpt-5-6-models-2026-7
• Business Insider: Perplexity is building an AI coding tool named Teammate: https://www.businessinsider.com/perplexity-building-ai-coding-tool-take-on-cursor-and-openai-2026-7
• Reuters: Major AI offerings at a glance: https://www.reuters.com/world/china/major-ai-models-glance-2026-07-08/