Quien ha hecho obras en casa conoce la regla sin haberla leído en ningún sitio: pintar una pared se hace el fin de semana; cambiar un enchufe, con cuidado, también; tocar el cuadro eléctrico o tirar una pared es otra conversación — necesita a alguien que sepa, y a veces proyecto y licencia. El criterio no es el tamaño de la casa. Es qué pasa si sale mal, y cuánto cuesta aprender a hacerlo bien.
Con la IA ocurre lo mismo, y la diferencia de 2026 es que las herramientas de "hacerlo uno mismo" se han vuelto muy buenas. Un gestor sin formación técnica puede hoy, con Codex, Claude Code o Copilot, construir una automatización, un prototipo o un análisis que hace dos años exigía un equipo. Eso es cierto y es bueno. También es cierto que nunca fue tan fácil construir algo que funciona en la demo y que nadie puede mantener tres meses después.
Este artículo es un intento honesto de responder a la pregunta que nos hacen cada semana: "¿esto lo hacemos nosotros o necesitamos ayuda?" — incluyendo los casos en que la respuesta correcta es "hacedlo vosotros", que son muchos.
Qué han cambiado estas herramientas
Conviene separar tres cosas que suelen venir mezcladas.
Asistentes en el editor. GitHub Copilot nació como sugerencia de código dentro del IDE y hoy también responde preguntas sobre el código y ejecuta tareas — pero su lugar natural es al lado de quien programa, acelerando lo que esa persona ya sabe hacer. Si nadie programa, no hay a quién sugerir.
Agentes de código. El Codex de OpenAI y el Claude Code de Anthropic son otra categoría: reciben una tarea ("conecta este formulario a la base de datos y envía un email cuando llegue una solicitud"), leen el proyecto, escriben el código en varios archivos, ejecutan las pruebas y devuelven el resultado. Funcionan en el terminal, en el editor, en la nube. Esto es lo que permite a alguien sin equipo técnico construir cosas reales.
Los modelos detrás. Los mismos LLMs que alimentan estas herramientas están disponibles por API para construir productos y automatizaciones. Es otro nivel de trabajo, y el único en el que las herramientas de "hacerlo uno mismo" no bastan por sí solas.
Lo que las tres tienen en común: han bajado brutalmente el coste de empezar. No han bajado el coste de mantener, de integrar ni de responder cuando algo falla con datos de clientes dentro.
Cuándo hacerlo solo es la respuesta correcta
Hay más casos de los que a una consultora le gustaría admitir. Estos son los que vemos funcionar bien sin ayuda externa:
Uso personal y del equipo. Resumir reuniones, preparar la primera versión de un documento, analizar una hoja de cálculo, escribir un email difícil. No hay integración, no hay datos de terceros saliendo de la empresa (siempre que la herramienta sea la adecuada — ver más abajo), y el único riesgo es perder una hora. Hacedlo.
Prototipos para decidir. "¿Servirá de algo un asistente sobre nuestra base de conocimiento?" La mejor forma de responder es construir uno en dos días con un agente de código y enseñárselo a tres personas. Un prototipo así vale más que un estudio de viabilidad de cuarenta páginas — y si después se decide avanzar en serio, el prototipo es el mejor briefing que una consultora puede recibir.
Procesos internos de bajo riesgo. Un script que renombra archivos, una automatización que compila un informe semanal a partir de tres fuentes, un formulario interno. Si falla, alguien se da cuenta y lo hace a mano. No merece la pena involucrar a nadie de fuera.
Equipos técnicos que solo necesitan acelerar. Si ya hay programadores, Copilot o Claude Code son herramientas de productividad, no un proyecto. Corresponde al equipo adoptarlas — con un aviso, más adelante, sobre lo que dicen los estudios.
Cuando el objetivo es aprender. Hay empresas que quieren que el equipo entienda qué hace y qué no hace la IA antes de decidir dónde invertir. Construir cosas pequeñas, con las manos, es la mejor formación que existe. Ningún curso lo sustituye.
Lo que estos casos tienen en común: el coste de equivocarse es bajo, los datos son vuestros y nada depende de eso para funcionar mañana por la mañana.
Cuándo hacerlo solo sale caro
Las señales de que la obra ya no es de fin de semana:
Datos de clientes. En el momento en que la solución toca nombres, emails, contratos, facturas o histórico de compras, hay RGPD, hay encargados del tratamiento, hay la pregunta "¿a dónde va esto?" La mayoría de los problemas que vemos en soluciones hechas en casa no es el código — es el modelo recibiendo datos que no debería, sin que nadie lo haya decidido.
Integración con sistemas críticos. ERP, CRM, facturación, banco. Un agente de código escribe la integración en media hora; lo que no sabe es que la tabla de clientes tiene tres campos heredados que nadie documentó, que el ERP rechaza actualizaciones fuera de horario y que la sincronización ejecutándose dos veces duplica facturas. Quien ha roto una integración así sabe lo que cuesta.
Procesos que atraviesan equipos. Si la solución cambia la forma de trabajar de comercial, operaciones y financiero al mismo tiempo, el problema ha dejado de ser técnico. Es diseño de procesos, es gestión del cambio, es decidir quién hace qué. Ninguna herramienta de código resuelve eso.
"Funciona en mi portátil." La solución vive en la máquina de una persona, con una clave de API personal, sin control de versiones, sin nadie que la entienda si esa persona se va. Es el equivalente a una instalación eléctrica improvisada: funciona hasta el día en que no funciona.
Sin métrica de resultado. Se construyó porque era posible. Nadie definió qué debía cambiar — tiempo, coste, errores, ingresos — ni lo está midiendo. A los seis meses, nadie sabe si mereció la pena.
Sin nadie para mantenerla. Los modelos cambian, las APIs cambian, los precios cambian. Una solución con IA no es una hoja de cálculo: necesita a alguien que la acompañe. Si esa persona no existe, la solución tiene fecha de caducidad.
Y está el aviso que prometimos sobre equipos técnicos. Un estudio de METR de 2025, con programadores experimentados en proyectos open source reales, midió lo que nadie esperaba: con herramientas de IA, tardaron un 19% más en cerrar las tareas — y siguieron convencidos de haber sido un 20% más rápidos. El informe DORA de 2024 apunta en la misma dirección: la IA aumentó la productividad individual y la satisfacción, pero empeoró la estabilidad y el rendimiento de las entregas. La lección no es "no las uséis"; es que la sensación de velocidad no es velocidad, y que sin proceso alrededor la herramienta acelera a la persona y frena al sistema.
El término medio que funciona
En la práctica, la elección rara vez es binaria. Los dos modelos híbridos que más veces funcionan:
Diagnóstico externo, ejecución interna. Alguien de fuera mapea el proceso, identifica dónde merece la pena la IA y dónde no, define métricas y diseña la solución — y el equipo construye con las herramientas de agente. La empresa se queda con el conocimiento; la consultora entra donde cuenta la experiencia (saber qué suele salir mal) y sale antes de convertirse en una dependencia.
Piloto interno, escalar con ayuda. El equipo construye el prototipo, demuestra que hay valor, y solo después entra quien va a hacerlo robusto: integración, seguridad, datos, monitorización, formación. Es la versión de "pinté el salón yo mismo, llamé al electricista para el cuadro".
En ambos, la pregunta a la consultora es la misma: "¿cuándo os vais?" Si la respuesta es vaga, es señal de que el modelo de negocio es quedarse.
Las herramientas, sin precios
Los precios cambian de mes en mes y quedarían desactualizados antes de que se lea este artículo; para estimar costes de uso, mantenemos una guía de costes de IA actualizada. Lo que no cambia tan rápido es el posicionamiento de cada una:
- GitHub Copilot — el más integrado en el flujo de quien ya programa (editor, GitHub, revisión de código). La elección natural para equipos técnicos que quieren acelerar sin cambiar de herramientas.
- OpenAI Codex — agente de código con CLI, extensión para el editor y entorno en la nube; ejecuta tareas enteras, incluso en paralelo, y se integra con el ecosistema de OpenAI.
- Claude Code — agente de código que lee todo el proyecto, edita archivos, ejecuta comandos y se conecta a herramientas externas (documentos, tickets, bases de datos) por MCP; disponible en el terminal, el editor, una app de escritorio y el navegador.
Para quien no es técnico y quiere construir prototipos o automatizaciones, los dos agentes (Codex y Claude Code) son el punto de partida; Copilot presupone un programador en la silla. Para quien ya tiene equipo, cualquiera sirve — lo que decide es lo que el equipo ya usa.
Una nota que vale para las tres: leer qué hace cada una con los datos que se le dan (el código, los documentos, lo que se escribe en los prompts) y elegir los planes de empresa cuando hay datos de clientes de por medio. Es la diferencia entre pintar la pared y tocar el cuadro eléctrico.
Matriz de decisión
Tres preguntas, y la respuesta sale casi sola.
| Riesgo bajo (datos internos, reversible) | Riesgo alto (datos de clientes, sistemas críticos, dinero) | |
|---|---|---|
| Capacidad interna (hay quien construya y mantenga) | Hacerlo solo. Herramientas de agente, métrica definida, revisión al cabo de un mes. | Diagnóstico externo, ejecución interna. Alguien de fuera diseña y define los límites; el equipo construye. |
| Sin capacidad interna | Hacerlo solo para aprender, con alcance pequeño. Prototipos, automatizaciones personales, sin integración. | Consultoría con fecha de salida. Diagnóstico, implementación hasta que funcione, formación del equipo para mantener. |
La tercera pregunta es la urgencia: si el resultado hace falta en semanas y no hay capacidad interna, el coste de aprender por el camino es mayor que el coste de quien ya lo ha hecho.
Qué preguntar a una consultora antes de firmar
Si la matriz apuntó a ayuda externa, estas preguntas separan a quien acelera de quien vende horas:
- "¿Qué vais a decidir no hacer?" Una buena consultora saca cosas del alcance. Una mala acepta todo.
- "¿Cuál es la métrica, y cuándo la medimos?" Si la respuesta es "productividad" sin número, no hay métrica.
- "¿Qué se queda con nosotros al final?" Código, documentación, accesos, y un equipo que sepa mantener. Si quedan dependencias, quedan facturas.
- "¿Cuándo os vais?" Una fecha, o un criterio. "Cuando esté funcionando" es una respuesta aceptable si viene con la definición de "funcionando".
- "Enseñadme un caso en que dijisteis a un cliente que no usara IA." Quien nunca lo ha dicho o no tiene experiencia o no es honesto.
- "¿Quién hace el trabajo?" ¿Las personas que presentan la propuesta son las que van a ejecutar? Si no, quién, y con qué experiencia en procesos como el nuestro?
- "¿Qué pasa cuando el modelo cambia?" Los proveedores retiran modelos, cambian precios, cambian comportamientos. ¿Quién sigue eso después?
Nuestra respuesta a estas preguntas está en cómo trabajamos: decidimos qué cambia, nos quedamos hasta que funcione, con entregas semanales y una fecha de salida. Si la respuesta correcta para el caso es "hacedlo vosotros", es lo que decimos — y el diagnóstico gratuito sirve precisamente para descubrirlo antes de que haya contrato.
Preguntas frecuentes
¿Puedo construir una automatización con IA sin saber programar? Con un agente de código como Codex o Claude Code, sí, para casos de alcance pequeño y riesgo bajo: automatizaciones internas, prototipos, análisis. Lo que no se consigue sin experiencia es integrar con sistemas críticos, garantizar la protección de datos y mantener la solución cuando los modelos cambian.
Copilot, Codex o Claude Code — ¿cuál elegir? Si hay programadores, lo que el equipo ya usa; Copilot es el más integrado en el flujo de quien programa. Si no los hay, los agentes (Codex, Claude Code) son el punto de partida, porque ejecutan tareas enteras a partir de una descripción.
¿Cuándo se justifica una consultora? Cuando los datos son de clientes, la solución toca sistemas críticos, el proceso atraviesa equipos, o el resultado hace falta en semanas sin capacidad interna. Y debe entrar con fecha de salida.
¿Los estudios dicen que la IA hace más lentos a los programadores? Un estudio controlado de METR (2025) midió a programadores experimentados un 19% más lentos con herramientas de IA, aunque se sintieran más rápidos; DORA 2024 vio subir la productividad individual y bajar la estabilidad de las entregas. La conclusión es que la herramienta sin proceso acelera a la persona y frena al sistema — no que no deba usarse.
¿El prototipo que hicimos internamente sirve de algo si luego pedimos ayuda? Sirve de mucho: demuestra que hay valor, muestra el proceso real y es el mejor briefing posible. Lo que normalmente no sirve es el código del prototipo, que se hizo para demostrar y no para durar.
Fuentes
Escribe sobre IA aplicada, operación, GEO/SEO y cómo transformar empresas en máquinas que siguen funcionando incluso cuando nadie mira.