Última actualización: 31 de agosto de 2026
El 29 de agosto de 2026, el analista Nathaniel Whittemore dedicó su programa diario a una idea incómoda para muchos directivos: programar con IA está dejando de ser una habilidad de ingenieros para convertirse en una competencia básica de cualquier profesional. La consecuencia práctica para una empresa de 5 a 200 personas no es contratar desarrolladores, sino aprender a reconocer qué problemas del día a día tienen forma de software.
¿Qué significa que programar con IA sea ya una competencia básica?
Significa que el coste de construir una herramienta pequeña ha caído tanto que la barrera ya no es técnica, sino de criterio. Hoy el cuello de botella no es quién escribe el código, sino quién sabe formular el problema.
Durante veinte años, una empresa mediana solo tenía dos opciones ante una necesidad concreta: comprar un producto que hacía el 60 por ciento de lo que necesitaba, o pagar un desarrollo a medida que tardaba meses y costaba decenas de miles de euros. Entre ambas opciones había un hueco enorme de problemas demasiado pequeños para justificar un proyecto y demasiado molestos para ignorarlos. Ese hueco es exactamente el terreno que la IA acaba de abrir.
En CenteIA lo vemos cada semana en empresas industriales y de servicios: la mayor parte de la fricción operativa no está dentro del ERP ni dentro del CRM, sino en las costuras que hay entre ellos. Y esas costuras casi nunca justifican un proyecto formal.
¿Cómo se reconoce un problema con forma de software en una pyme?
Un problema tiene forma de software cuando alguien de tu equipo repite el mismo trabajo manual siguiendo reglas que podría explicarte en cinco minutos. Si la persona sabe explicar las reglas, la herramienta se puede construir.
Las señales concretas que buscamos en una auditoría son estas:
- Alguien mantiene un Excel que nadie más entiende y del que depende una decisión semanal.
- Un dato se copia a mano de un sistema a otro más de tres veces por semana.
- Un informe se monta cada lunes juntando piezas de cuatro sitios distintos.
- Existe un procedimiento escrito que la gente se salta porque cumplirlo cuesta más que el error.
- Alguien tiene que "acordarse" de revisar algo, y a veces no se acuerda.
Cuando aparecen dos o más de estas señales sobre el mismo proceso, hay una herramienta interna esperando a ser construida. No un proyecto de transformación digital: una herramienta de una pantalla que hace una cosa bien.
¿En qué se diferencia esto de delegar tareas a la IA?
Es la distinción que más confusión genera y la que más dinero ahorra. Delegar una tarea a la IA significa que el modelo hace el trabajo cada vez que se lo pides, y pagas y supervisas cada vez. Construir una herramienta significa usar la IA una sola vez, al principio, para fabricar algo que después funciona solo.
La diferencia importa porque cambia la estructura de coste. Un proceso que se ejecuta doscientas veces al mes y siempre igual no debería pasar por un modelo doscientas veces: debería convertirse en código que se ejecuta gratis. La IA es cara cuando se usa como músculo repetitivo y barata cuando se usa como fábrica.
Regla de decisión: si el proceso cambia cada vez y exige juicio, delega en la IA. Si el proceso es siempre el mismo y solo cambian los datos, pide a la IA que te construya la herramienta y luego apártala.
¿Automatizar, mejorar o inventar: qué tipo de proyecto te toca?
Whittemore propone tres categorías, y son útiles porque cada una tiene un perfil de riesgo distinto. Esta es la traducción a una empresa de 5 a 200 personas:
| Tipo | Qué haces | Ejemplo realista | Riesgo |
|---|---|---|---|
| Automatizar | Sustituyes trabajo manual que ya se hace | El informe semanal de incidencias que alguien monta a mano cada lunes | Bajo: sabes qué salida esperar y puedes compararla |
| Mejorar | Añades capacidad a algo que ya funciona | Un buscador interno sobre los presupuestos de los últimos cinco años | Medio: hay que validar la calidad de la información |
| Inventar | Creas algo que antes no existía porque no era viable | Un panel que cruza margen por cliente con horas realmente dedicadas | Alto: nadie sabe todavía si esa información cambiará decisiones |
El error más común es empezar por "inventar" porque es lo más emocionante. Empieza por automatizar. Un proyecto de automatización tiene una ventaja decisiva: ya conoces el resultado correcto, así que puedes verificar si la herramienta funciona el primer día.
¿Cuál debería ser tu primer proyecto y cómo elegirlo?
El primer proyecto no se elige por impacto, se elige por capacidad de aprendizaje. Necesitas algo que puedas terminar en menos de dos semanas y evaluar sin discusión.
- Pregunta a tu equipo qué parte de su semana odian. No preguntes qué automatizarían: pregunta qué les da pereza el domingo por la noche. La respuesta suele señalar el proceso correcto.
- Descarta todo lo que toque dinero, nóminas o datos personales sensibles. Para el primer proyecto quieres aprender, no gestionar un incidente.
- Exige que el resultado sea comprobable. Si no puedes decir "esto está bien" o "esto está mal" mirando la salida durante treinta segundos, no es un buen primer proyecto.
- Fija un plazo de dos semanas y un responsable con nombre. Sin dueño, la herramienta se queda en demo y nadie la usa.
Si esta lista te resulta difícil de aplicar sobre tus propios procesos, ese es justamente el trabajo de un diagnóstico de IA previo a invertir: poner sobre la mesa los procesos candidatos y ordenarlos por esfuerzo y retorno antes de tocar nada.
¿Qué riesgos tiene construir tu propio software con IA?
Tres, y ninguno es técnico en el sentido clásico. El primero es el mantenimiento: construir cuesta días, mantener cuesta años. El segundo es la seguridad: una herramienta hecha en una tarde que accede a datos de clientes es un problema de cumplimiento, no un experimento. El tercero es la dependencia de una sola persona.
Sobre el segundo punto hay una señal reciente que conviene leer con atención. El 28 de agosto de 2026 se filtró que OpenAI está probando un "modo persistente" en Codex, capaz de trabajar de forma autónoma durante días. La propia compañía frenó su lanzamiento comercial por falta de garantías de control, y mantiene la exigencia de aprobación humana explícita para cambios críticos en sistemas externos. Si el fabricante pone ese freno, tu empresa tampoco debería dar acceso directo a producción a una herramienta recién construida.
La mitigación es sencilla y aburrida: entorno separado, datos de prueba, revisión humana antes de cada paso que escriba en un sistema real, y una persona responsable del código que no sea la única que lo entiende. Cuando la herramienta demuestra que aporta valor, entonces sí conviene profesionalizarla con un desarrollo a medida bien planteado que incluya mantenimiento, documentación y traspaso.
¿Qué necesita saber tu equipo para que esto funcione?
Menos de lo que la gente teme y más de lo que las herramientas prometen. Nadie de tu equipo necesita aprender a programar, pero sí necesita aprender a describir un proceso con precisión, a comprobar un resultado y a saber cuándo parar.
Esa es la competencia real que separa a las empresas que sacan partido de la IA de las que acumulan suscripciones. En nuestra experiencia acompañando a compañías industriales y de servicios, la diferencia entre un equipo que construye sus propias herramientas y otro que no lo consigue casi nunca está en el talento técnico: está en si alguien les enseñó a formular problemas. Es exactamente el objetivo de la formación a medida para equipos, y encaja con el trabajo previo de automatizar procesos con criterio en lugar de automatizar por moda.
¿Por dónde empezar esta semana?
Hoy es 31 de agosto de 2026 y septiembre es, en la práctica, el mes en el que las empresas españolas reordenan prioridades. Es un buen momento para hacer tres cosas concretas: reunir al equipo durante treinta minutos y listar los cinco procesos manuales más repetitivos, elegir uno que cumpla los cuatro criterios de arriba, y darle dos semanas y un responsable.
Si prefieres hacer ese primer recorrido acompañado, y salir con una lista priorizada en lugar de con una intuición, reserva 30 minutos con nuestro equipo. Revisamos tus procesos, señalamos cuáles tienen forma de software y cuáles no, y te decimos con honestidad cuáles no merecen la pena.