Estás en el blog de Nicolau Roca
Usar IA no es una profesión
Hay una frase que se está repitiendo demasiado en el circo actual de la inteligencia artificial: “el futuro no es saber programar, es saber dar buenas instrucciones”.
La frase suena bien. Tiene ese aire de revelación moderna que queda perfecto en LinkedIn, especialmente si le pones un emoji de cerebro, una palabra en inglés y alguna referencia vaga a “el futuro del trabajo”. El problema es que, como muchas frases que suenan demasiado bien, es una media verdad empaquetada para vender una idea bastante pobre.
Porque sí, claro que saber dar buenas instrucciones importa. Claro que una mala especificación genera basura. Claro que pedirle algo a una IA sin contexto, sin restricciones y sin criterio suele acabar en una respuesta aparentemente brillante y técnicamente sospechosa. Hasta ahí, todos de acuerdo.
Pero de ahí a decir que lo importante ya no es saber hacer, sino saber pedir, hay un salto enorme. Y ese salto es donde empieza el humo.
La IA no elimina el oficio. La IA elimina, automatiza o devalúa partes mecánicas del oficio que durante demasiado tiempo confundimos con valor profesional. Eso es muy distinto. Una cosa es que la IA cambie profundamente cómo trabajamos, qué tareas siguen teniendo sentido, qué perfiles quedan expuestos y qué competencias pasan a ser obligatorias. Otra cosa muy diferente es vender que ahora basta con “saber pedir” para ocupar el espacio de alguien que entiende software, datos, producto, arquitectura, seguridad o negocio.
No. No funciona así.
Y si te parece que sí, la pregunta es bastante sencilla: ¿sabrías detectar cuándo la IA te está dando una solución incorrecta, frágil, insegura, mal planteada o directamente inútil? Porque ahí empieza la profesión. No en el prompt. En la validación.
Excel tampoco convirtió a nadie en contable
Vamos con el ejemplo incómodo, porque se entiende demasiado bien: Excel.
Cuando las hojas de cálculo se generalizaron, el trabajo contable, financiero y administrativo cambió de forma radical. Muchas tareas que antes exigían horas de cálculo manual, revisión, copia, conciliación, comprobación y preparación de informes pasaron a hacerse de otra forma. Más rápido, con menos fricción, con más capacidad de análisis y con mucha más flexibilidad.
Excel destrozó una parte del trabajo mecánico. ¡Y menos mal! Pero Excel no eliminó al contable.
Nadie serio pensó que, como ahora se podían hacer sumas, tablas dinámicas, modelos financieros y reportes con una hoja de cálculo, ya no hacían falta contables, auditores, controllers o financieros. Lo que ocurrió fue bastante más interesante: cambió el estándar mínimo. El contable que sabía usar Excel empezó a ser más productivo que el que seguía trabajando como si estuviera en 1985. El financiero que entendía el negocio y además sabía modelar ganó potencia. El controller que sabía cruzar datos, explicar desviaciones y construir reporting útil se volvió más valioso.
Y el perfil que solo aportaba paciencia para mover cifras empezó a quedarse sin excusa.
Ahí está la clave.
Excel no sustituyó el criterio contable. Sustituyó parte del trabajo manual que algunos confundían con el oficio. El buen contable nunca fue bueno por sumar columnas a mano. Era bueno porque entendía fiscalidad, auditoría, reporting, control financiero, riesgo, normativa, negocio y consecuencias. Excel no eliminó eso, al contrario: hizo que eso importara más, porque la parte mecánica se volvió más barata.
Ahora dime una cosa: ¿se creó una carrera profesional llamada “Ingeniero en Excel”? ¿Pasó el mercado a contratar “Prompt Engineers de hojas de cálculo”? ¿Se llenaron las empresas de “Excel Architects” cuya función era simplemente saber usar BUSCARV con mucha personalidad?
No.
Hubo gente experta en Excel, por supuesto. Hubo perfiles mucho más valiosos porque sabían usarlo bien, también. Y quien no se puso al día seguramente lo pasó mal. Pero Excel no era el oficio. Era una herramienta dentro del oficio.
Con la IA estamos repitiendo exactamente la misma historia, solo que con más ansiedad, más dinero encima de la mesa y más gente intentando bautizar competencias básicas como si fueran carreras profesionales completas.
El prompt no te hace ingeniero
El problema del discurso actual es que confunde acceso con competencia. Como una persona puede pedirle a una IA que genere una API, algunos empiezan a insinuar que esa persona ya no necesita un backend developer. Como puede pedir una consulta SQL, parece que ya no necesita un data engineer. Como puede pedir una pantalla, parece que ya no necesita un frontend. Como puede pedir una cláusula, parece que ya no necesita un abogado. Como puede pedir una estrategia, parece que ya no necesita saber de negocio.
Es una fantasía preciosa, y también es bastante peligrosa. Porque producir algo que se parece al resultado de una profesión no es ejercer esa profesión.
Una IA puede generar código, sí. Eso no significa que haya entendido el sistema, las dependencias, los límites, la seguridad, el mantenimiento, los costes, los datos, la deuda técnica ni el producto. Una IA puede generar SQL, claro. Eso no significa que entienda la granularidad de la tabla, la semántica de la métrica, el linaje del dato, el impacto de duplicar registros o la diferencia entre una query que devuelve filas y una query que responde correctamente a una pregunta de negocio.
La IA puede producir una respuesta. Lo que no puede hacer por ti es convertirte mágicamente en alguien capaz de saber si esa respuesta es buena.
El valor profesional no está solo en pedir. Está en saber qué pedir, por qué pedirlo, qué restricciones imponer, qué riesgos anticipar, qué resultado aceptar, qué resultado rechazar y qué consecuencias tiene llevar eso a producción. Si no sabes hacer eso, no estás dirigiendo una IA. Estás jugando a la ruleta con una interfaz muy educada.
“Saber pedir” es la nueva forma elegante de no saber de qué hablas
Hay que decirlo con claridad: “saber pedir” sin dominio es una habilidad muy limitada. Puede hacerte parecer competente durante un rato, sobre todo delante de alguien que tampoco sabe demasiado del tema. Pero en cuanto el resultado toca un sistema real, un dato real, un cliente real o una decisión real, la fiesta se acaba.
Puedes estructurar un prompt perfecto. Puedes escribir contexto, objetivo, restricciones, formato de salida, criterios de aceptación y hasta pedirle a la IA que “actúe como un arquitecto senior con veinte años de experiencia”. Maravilloso. Ya tienes teatro.
Ahora viene la parte adulta: ¿sabes si lo que te ha devuelto tiene sentido?
Porque el software tiene una cualidad especialmente traicionera: puede parecer correcto mucho antes de ser correcto. Puede compilar. Puede pasar un test superficial. Puede funcionar en la demo. Puede devolver justo lo que esperabas en el caso feliz. Puede tener nombres bonitos, estructura limpia y una explicación impecable. Y aun así estar mal diseñado, ser inseguro, no escalar, duplicar lógica, romper una abstracción, introducir deuda técnica o crear un problema que explotará dentro de seis meses, cuando ya nadie recuerde el prompt original ni al iluminado que lo pegó en el chat.
La IA no elimina esa responsabilidad. La desplaza.
Antes escribías más código directamente. Ahora puedes dirigir más generación, revisar más propuestas, validar más cambios y decidir más rápido. Pero alguien sigue teniendo que entender. Alguien sigue teniendo que decir: esto no entra, esto rompe el modelo, esto no escala, esto es deuda, esto no resuelve el problema real, esto parece bonito pero es una bomba de relojería.
Si ese alguien no existe, lo que tienes no es productividad. Tienes una fábrica de basura con copiloto.
Anthropic no está diciendo lo que algunos quieren leer
El estudio de Anthropic sobre Claude Code es interesante precisamente porque no dice la tontería simple de “los programadores ya no hacen falta”. Lo que muestra es bastante más serio: en sesiones reales con Claude Code, el humano conserva mucho peso en la planificación, en la dirección y en la evaluación, mientras que el agente asume una parte importante de la ejecución operativa.
Traducido: la IA puede hacer mucho más “cómo”, pero el “qué”, el “por qué”, el “hasta dónde”, el “con qué restricciones” y el “esto está bien o está mal” siguen dependiendo de la pericia del usuario.
Y esto es justo lo contrario de la interpretación barata del “solo hay que saber dar instrucciones”.
Anthropic habla de retornos persistentes a la pericia. No de retornos persistentes al prompt bonito. No de retornos persistentes al que sabe poner “paso a paso”. No de retornos persistentes al que tiene una plantilla de Notion con treinta comandos mágicos.
Pericia. Qué palabra tan incómoda para la economía del humo.
La pericia no consiste en escribir “actúa como un senior backend engineer”. La pericia consiste en saber cuándo la respuesta que te ha dado ese supuesto senior backend engineer imaginario es una chapuza envuelta en seguridad lingüística. Y esto lo cambia todo, porque la IA no premia al que sabe pedir en abstracto. Premia al que tiene suficiente conocimiento del problema para formular bien, dirigir bien, corregir bien y validar bien.
A veces ese conocimiento será técnico. A veces será de negocio. A veces será legal, financiero, operativo, clínico o de producto. Muchas veces será una mezcla de varios. Pero siempre hay dominio detrás.
Sin dominio, el prompt es decoración.
DORA lo deja bastante claro: la IA amplifica lo que ya tienes
El informe DORA/Google sobre desarrollo asistido por IA plantea una idea que muchas empresas deberían leer antes de montar otro comité de innovación con camisetas negras y nombres de agentes en una pizarra: la IA amplifica fortalezas y debilidades.
Esto es mucho más importante de lo que parece.
Si tienes buenos procesos, buena cultura técnica, buena plataforma interna, buen gobierno, equipos maduros, arquitectura razonable y capacidad real de validar, la IA puede darte muchísimo. Puede quitar fricción, acelerar análisis, mejorar documentación, generar tests, ayudar a refactorizar, reducir tiempo de investigación y desbloquear trabajo que antes quedaba atascado en tareas repetitivas.
Pero si tienes tickets basura, deuda técnica descontrolada, datos mal definidos, managers confundiendo demo con producto y equipos sin capacidad de revisar lo que generan, la IA no te salva. Te pone una turbina en el vertedero.
Esto conviene repetirlo: la IA no arregla una organización rota. La acelera.
Y por eso el discurso de “ahora cualquiera podrá construir software” es tan irresponsable. Cualquiera podrá generar cosas. Eso sí. Cosas habrá muchas. Muchísimas. Vamos a tener una inflación preciosa de prototipos, automatizaciones, dashboards, apps internas, asistentes conversacionales y repositorios que parecen escritos por alguien con criterio hasta que intentas mantenerlos.
La producción se abarata. La validación se vuelve más importante.
Y si tu empresa no entiende esa diferencia, no está adoptando IA. Está comprando una máquina para fabricar deuda técnica con mejor marketing.
Los desarrolladores no desconfían de la IA por romanticismo artesanal
Stack Overflow 2025 muestra una realidad bastante sana: los desarrolladores usan IA, pero mantienen una desconfianza importante sobre su precisión. Esto no es nostalgia de señor con barba diciendo que antes se programaba mejor. Es experiencia.
Quien ha trabajado con sistemas reales sabe que el mayor peligro de la IA no es que se equivoque de forma escandalosa, eso se ve rápido. El verdadero problema es que se equivoque de forma plausible. Que genere una solución razonable, bien explicada, con estructura limpia y suficiente apariencia de competencia como para que alguien sin criterio la acepte.
La IA no solo produce errores. Produce errores convincentes.
Y un error convincente es mucho más peligroso que un error evidente. El evidente se rechaza. El convincente entra en producción, se documenta, se integra, se copia en otro módulo, se convierte en dependencia y luego alguien lo descubre tres meses después, normalmente un viernes, normalmente tarde, normalmente cuando ya hay usuarios afectados.
Pero sí, claro, lo importante era saber escribir el prompt.
La productividad no es producir más cosas
Una de las grandes trampas de la IA es que aumenta el volumen de output de una forma tan espectacular que mucha gente lo confunde con valor. Más código, más tickets, más documentos, más propuestas, más automatizaciones, más respuestas, más commits, más dashboards. Todo más rápido, todo más brillante, todo con esa capa de seguridad artificial que hace que hasta una mala idea parezca una consultoría de 80.000 euros.
Pero más output no es más valor.
Más código no es mejor software. Más documentación no es más conocimiento. Más dashboards no son mejores decisiones. Más automatizaciones no son mejores procesos. Más velocidad no es mejor dirección.
A veces la IA acelera una tarea local y ralentiza el sistema completo. Te permite escribir antes una solución que luego cuesta más entender. Te genera una arquitectura que parece limpia en la demo y se vuelve insoportable en mantenimiento. Te crea tests que dan tranquilidad pero no cubren el riesgo real. Te documenta cosas que nadie ha pensado lo suficiente. Te da avance aparente.
Y el avance aparente es una droga muy cómoda en empresas que ya confundían actividad con progreso antes de que llegara la IA.
Esto no significa que la IA no mejore productividad. La mejora en muchos contextos. Hay evidencia de mejoras reales y hay casos donde el impacto es enorme. Pero el punto no es ese. El punto es que la productividad profesional no se mide solo por la velocidad de generación. Se mide por la calidad del resultado, su mantenibilidad, su utilidad, su impacto y su coste total.
Si produces el doble de basura en la mitad de tiempo, no has descubierto el futuro del trabajo. Has industrializado el problema.
AI Engineer puede ser serio. “Usuario avanzado de IA” no
Aquí hay que ser justos, porque no todo lo que lleve IA en el título es humo.
Un AI Engineer puede ser un rol perfectamente serio si hablamos de ingeniería real: diseñar sistemas con modelos, integrar APIs, construir arquitecturas RAG, definir evaluaciones, controlar costes, gestionar privacidad, implementar guardrails, diseñar agentes con herramientas, observar fallos, versionar prompts y configuraciones, desplegar soluciones robustas y conectar IA con procesos empresariales.
Eso sí es ingeniería. Eso exige software, datos, arquitectura, seguridad, producto y operación. No es “sé usar ChatGPT”. Es construir sistemas en los que la IA es una pieza más, con sus rarezas, sus riesgos y sus límites.
Lo ridículo es llamar AI Engineer a alguien cuyo valor principal es usar una herramienta de IA con más soltura que el resto. Eso no es ingeniería. Es alfabetización de herramienta.
Y no pasa nada. La alfabetización de herramienta es importante. Saber usar IA va a ser obligatorio en muchos trabajos, igual que saber usar Excel, internet, Git, SQL, PowerPoint, un IDE o un CRM. Pero una competencia obligatoria no es automáticamente una profesión.
Saber Git no te convierte en Git Engineer. Saber Excel no te convierte en Excel Engineer. Saber buscar en Google no te convierte en Search Prompt Architect. Saber usar Jira no te convierte en Ticket Flow Strategist, aunque no demos ideas, que todavía aparece alguien vendiendo el curso.
Con la IA pasa exactamente lo mismo.
Si construyes sistemas reales con IA, hay especialización. Si integras IA en procesos críticos, hay producto, arquitectura y operación. Si evalúas modelos, mides calidad y controlas riesgo, hay ingeniería. Si lo único que haces es pedirle cosas a un chatbot y vestirlo de metodología, tienes una habilidad útil. No una carrera profesional.
El junior no desaparece, pero el junior barato lo va a pasar mal
Hay una parte incómoda de todo esto que conviene no esconder: la IA sí puede golpear fuerte ciertos tramos de entrada a la profesión.
Si antes un junior aprendía haciendo tareas pequeñas, repetitivas y supervisables, y ahora esas tareas las hace una IA, las empresas tienen un problema serio. No porque ya no necesiten profesionales, sino porque pueden cargarse parte de la escalera de aprendizaje. Querrán perfiles que sepan decidir, validar, diseñar y responsabilizarse, pero sin haber pagado el proceso mediante el cual alguien aprende a decidir, validar, diseñar y responsabilizarse.
La broma se cuenta sola.
Muchas empresas quieren seniors baratos, juniors autónomos y agentes que rellenen el hueco. Luego se sorprenden de que el código sea inmantenible, de que la gente no entienda los sistemas y de que nadie tenga criterio. Es lo que pasa cuando intentas automatizar la formación y llamarlo eficiencia.
La IA puede hacer que algunos roles de entrada exijan capacidades más maduras desde el principio. Esto no significa que la profesión desaparezca. Significa que la transición hacia la profesión se vuelve más exigente y que las organizaciones tendrán que tomarse en serio cómo forman talento. Si no lo hacen, no tendrán una empresa más productiva. Tendrán un pequeño grupo de expertos revisando montañas de output generado por gente que nunca aprendió los fundamentos.
Eso no es transformación digital. Es deuda organizativa con interfaz futurista.
El programador no desaparece. Desaparece una versión mediocre del programador
“La IA sustituirá a los programadores” es una frase torpe. La frase correcta es bastante más desagradable: la IA sustituirá a mucha gente que se escondía detrás de tareas mecánicas para parecer profesional.
Eso sí va a pasar.
Va a afectar al programador que solo traducía tickets pobres en código sin entender producto. Al analista que solo movía datos de una tabla a otra sin entender la métrica. Al consultor que solo reempaquetaba obviedades en slides. Al técnico que confundía conocer una herramienta con tener criterio. Al manager que pensaba que una demo generada en dos horas era una solución implantable.
La IA no tendrá demasiada piedad con el trabajo mecánico que no aporta juicio.
Pero eso no es el fin del oficio. Es el fin de algunas coartadas.
Y, sinceramente, quizá hacía falta.
Porque llevamos años rodeados de output sin criterio: dashboards que nadie usa, aplicaciones internas que resuelven mal el problema, automatizaciones que automatizan procesos absurdos, documentación que no documenta nada útil, informes que no ayudan a decidir, código que funciona hasta que alguien tiene que mantenerlo y reuniones donde se confunde estar ocupado con avanzar.
La IA puede empeorar todo eso si se usa mal. Puede producir más dashboards inútiles, más apps frágiles, más informes decorativos y más código sin dueño. Pero también puede hacer algo bastante sano: quitar valor a la ejecución mecánica y obligarnos a mirar de frente dónde está el criterio.
Qué problema resuelve esto. Qué decisión mejora. Qué riesgo introduce. Qué coste tiene mantenerlo. Qué dato estamos usando. Qué pasa si falla. Quién valida. Quién responde.
Ahí empieza el trabajo serio.
No en el prompt.
La IA no convierte a todos en ingenieros
La promesa barata de la IA es que cualquiera podrá construir cualquier cosa. La realidad profesional es más incómoda: cualquiera podrá generar una primera versión de casi cualquier cosa, y precisamente por eso vamos a vivir rodeados de primeras versiones mal pensadas.
El problema dejará de ser producir. El problema será discriminar.
Qué sirve y qué no. Qué escala y qué no. Qué se mantiene y qué se pudre. Qué es seguro y qué solo lo parece. Qué cumple y qué nos mete en un lío. Qué tiene sentido y qué existe únicamente porque fue fácil generarlo.
Ese es el nuevo cuello de botella.
Y para eso no basta con prompting. Hace falta oficio.
La IA no convierte a un usuario en ingeniero de software por escribir “créame una aplicación”. Igual que Excel no convertía a nadie en auditor por saber hacer una tabla dinámica. Igual que una calculadora científica no convertía a nadie en matemático. Igual que internet no convertía a nadie en periodista, investigador o médico.
La herramienta baja barreras. No transfiere criterio.
Y si hay una frase que deberíamos poner encima de cada presentación corporativa sobre IA es esta: bajar la barrera de producción no elimina la barrera de responsabilidad.
De hecho, la hace más importante.
No necesitamos una profesión llamada “usar IA”
La conclusión es bastante simple, aunque a algunos les estropee la landing page del curso.
No necesitamos una nueva profesión llamada usar IA. Necesitamos profesionales que sepan integrar IA en su profesión.
Desarrolladores que usen IA para construir mejor software, no para producir más deuda técnica con más velocidad. Data engineers que usen IA para acelerar documentación, validaciones, modelado y debugging, no para generar SQL que nadie entiende. Analistas que usen IA para explorar hipótesis y comunicar mejor, no para fabricar conclusiones con apariencia ejecutiva. Abogados que usen IA para revisar y comparar mejor, no para delegar criterio jurídico. Financieros que usen IA para analizar y explicar mejor, no para maquillar números con prosa automática. Managers que usen IA para reducir fricción y mejorar decisiones, no para pedir más output sin entender qué están multiplicando.
Esa es la diferencia entre transformación y circo.
La IA como competencia profesional es obligatoria. La IA como identidad profesional aislada es sospechosa. Y el prompting, salvo contextos muy concretos de diseño de sistemas, evaluación, comportamiento conversacional o producto basado en modelos, no es una profesión. Es una habilidad. Una habilidad útil, sí. Una habilidad necesaria, probablemente. Pero una habilidad dentro de un oficio.
- La herramienta no es el oficio.
- La herramienta revela el oficio.
Y también revela cuando debajo no había demasiado oficio que revelar.
Quizá por eso tanta gente está tan interesada en decir que el futuro consiste en “saber pedir”. Porque es mucho más cómodo aprender a pedir que aceptar que, cuando la máquina ya puede producir, lo único que queda al descubierto es tu criterio.
Y si no tienes criterio, la IA no te convierte en profesional. Solo te ayuda a parecerlo más rápido.
