Del Prompt Engineer al Context Engineer: cómo la IA me obligó a reorganizar mi web (y mis esquemas mentales)

Vista superior de una oficina moderna donde una mujer da instrucciones a un androide, observando a un equipo diverso trabajando en ordenadores.

En medio del relanzamiento de mi web —ese proceso que empieza como ‘poner cuatro contenidos interesantes’ y acaba siendo una lección magistral no solicitada sobre IA—, me encontré haciendo algo inédito: quejarme ante mi propio GPT. Literal. Le solté: “Estoy muy decepcionado con el funcionamiento de este GPT”. ¿La respuesta? Una corrección automática de su propio prompt. Vamos un auto promp engineer en toda regla.

¿Qué pasa cuando el prompt ya no basta?

Durante un tiempo, bastaba con afinar la pregunta. Aquello del prompt engineer, perfil que se convirtió en el ‘community manager’ de la IA. Pero los modelos han crecido, y no solo en tokens. Ya no se trata de pedir una cosa concreta. Ahora les pedimos estructuras, coherencia, estilo… les pedimos visión de conjunto.

Y ahí, el prompt se nos queda corto.

Bienvenidos a la era del Context Engineer

Cuando pides que te generen no un texto sino una estrategia, una app entera o un sistema con logs, control de versiones y políticas de seguridad, necesitas algo más que palabras mágicas. Necesitas dar contexto:

  • ¿Qué estructura tiene tu proyecto?
  • ¿Qué convenciones usas para nombrar?
  • ¿Qué versiones, qué librerías, qué restricciones legales o de seguridad?

Esto ya no es redactar un prompt. Es casi como el onboarding a un nuevo compañero de equipo.

¿Y esto qué tiene que ver con DevSecOps?

Todo. Porque en un entorno DevSecOps, ya no construimos piezas aisladas. Diseñamos sistemas donde el todo es más que la suma de sus partes. Si la IA va a ayudarte, tiene que entender ese todo. Como cuando formamos a un junior: hay que explicarle el porqué de las decisiones, no solo el qué.

Y eso es contexto. O mejor dicho: ingeniería del contexto.

¿Qué será lo próximo?

Si el Prompt Engineer fue el becario estrella de 2023, y el Context Engineer es el arquitecto invisible de 2025, cabe preguntarse: ¿qué rol viene después? ¿Qué perfil será capaz de coordinar IAs completas como si fueran equipos?

🤷 Lo veremos. Pero está claro que, como técnicos, toca reciclarse y ampliar nuestras miras.

Moraleja

Si tu GPT te contesta con razón, quizá ha llegado el momento de que empieces a escucharle.


¿Y tú? ¿Ya has tenido tu primera discusión con una IA? Cuéntamelo en LinkedIn.

Entre el negocio y la IA: el perfil que falta en el nuevo ciclo de vida del software

Reunión colaborativa en oficina moderna con diversidad de género, un androide y gráficos en pizarra

Conocí a Ricardo Devis hace más de 25 años, de hecho el siglo pasado porque llevaba el DESI, Diploma de Especialización en Soluciones Internet de la Universidad de Deusto. Así que le suelo seguir y hace poco leí un artículo que me pareció especialmente acertado: “AI in the SDLC: El ciclo de vida del software intermediado por inteligencia artificial”. No solo por cómo describe los cambios en las fases clásicas del desarrollo de software, sino porque pone sobre la mesa algo que a menudo se pasa por alto: la necesidad urgente de nuevos perfiles que conecten mundos que rara vez conviven bien.

El nuevo SDLC exige un nuevo tipo de profesional

En este nuevo SDLC (software development life cycle o lo que yo llamo cadena de suministro de software), no basta con saber programar ni con entender el negocio. Tampoco vale con “echarle IA” a lo que ya tenemos. Hace falta alguien que entienda las implicaciones técnicas de integrar copilotos, LLMs y automatizaciones, pero que también sepa detectar cuándo tiene sentido, qué riesgos asume el negocio y cómo gestionar la transición sin perder foco ni calidad.

Ese es precisamente el espacio donde me estoy posicionando como evolución de mi carrera: como conector entre tecnología y negocio, ayudando a traducir la innovación en valor real. Lo hice con arquitecturas, con modelos de ciberseguridad y, más recientemente, en dinámicas de innovación donde las PoC ya empiezan a incorporar IA generativa.

Hoy más que nunca, los equipos necesitan figuras que:

  • Entiendan el código pero también el contexto.
  • Sepan detectar patrones y anticipar tendencias sin caer en modas.
  • Traduzcan capacidades técnicas en decisiones informadas.

Porque si el SDLC evoluciona, también lo deben hacer los roles. Y hay uno, el del perfil híbrido, que no puede faltar.

Moraleja

Igual el próximo conocimiento que tienes que añadir a tu curriculum no es un nuevo lenguaje, sino habilidades diferentes.



¿Tú también estás viendo este vacío entre negocio y tecnología con la IA? Me interesa saber cómo lo estáis abordando en vuestros equipos. ¿Lo hablamos por LinkedIn?

Artículo original de Ricardo Devis, si te interesa este enfoque sobre el SDLC, te recomiendo seguirle: sus reflexiones van un paso más allá del titular.

Normalmente los artículos están Diseñados en la cabeza de Iñigo, made in ChatGPT, pero este lo ha escrito el solito… yo solo he editado.

Un junior, un agente… y la importancia de aterrizar bien

Una mujer joven latina y un androide humanoide son recibidos calurosamente por un equipo diverso en una oficina moderna y luminosa, con un plan de integración visible en pantalla.

Imagina una escena: llega el jefe y suelta, muy contento, que va a poner un junior por cada miembro del equipo. Gratis. Y claro, lo primero que piensas es: ¡guay! Más manos, más capacidad.

Hasta que te das cuenta de que esas manos no vienen con el manual de instrucciones leído. Hay que enseñarles. Hay que hacerles hueco. Hay que invertir tiempo en que se enteren de por dónde sopla el viento en el proyecto.

Onboarding no es un lujo, es una necesidad

Si has trabajado en un entorno con mucha rotación, sabes que el proceso de onboarding se convierte en un salvavidas. Te reduce el tiempo, evita errores tontos y acelera la integración. Pero cuando llevas años en un equipo estable, ese proceso suele estar medio oxidado. El documento de Onboarding no existe porque la última vez que entró alguien al equipo ni existía el termino Onboarding. Y claro te cae un junior y no sabes ni por dónde empezar.

Pues con los agentes de IA pasa lo mismo. Exactamente igual.

Un agente sin contexto es un becario que no pregunta

Le dices a un LLM que te escriba código en Java y te lo hace. Perfecto. Pero lo hace como le parece. Si usas Java moderno, si sigues ciertas convenciones de carpetas o estructura de clases, si tu equipo tiene una forma concreta de comentar, de versionar, de integrar… se lo tienes que explicar. Porque, como el junior, no lo adivina.

Y esto no es que el modelo sea malo. Es que no eres tú. Y si quieres que sea útil de verdad, tendrás que entrenarlo o al menos darle pistas. Lo demás es esperar milagros.

¿Inversión o coste hundido?

Aquí hay dos caminos:

  1. Ser reactivo y tirarte a la piscina sin preparar nada. Spoiler: es como esperar a las rebajas… y quedarte sin talla.
  2. O anticiparte y empezar a documentar cómo trabajas, cómo piensas y qué patrones repites. Igual que harías para escalar tu equipo humano.

Yo me quedo con la segunda. Y más aún si hablamos de lo que se viene de enjambres de agentes, que ya no es uno sino una cuadrilla de “ayudantes” rondando tus procesos.

Moraleja

Ni los juniors ni los agentes vienen enseñados. Pero si sabes guiarles, pueden ser una inversión brutal. Eso sí: solo si tú tienes claro cómo trabajas y por qué. ¿Te lo has planteado?


Si te interesa cómo se pueden estructurar equipos reales, o quieres compartir tu experiencia, sigue la conversación en LinkedIn. ¡Nos leemos!

Diseñado en la cabeza de Iñigo, made in ChatGPT.” Pero le he tenido que aterrizar yo, no te creas, después de eso es muy productivo es si.

El peligro de que tu IA sea un pelotilla

Androide complaciente botando una pelota frente a una trabajadora desconcertada en una oficina moderna

Llevo trabajando desde el siglo pasado y después de una docena de empresas, muchos proyectos y aún más jefes, uno desarrolla un radar para detectar a los que no aceptan críticas. Porque con según qué jefes, discrepar era sinónimo de jugarte el cuello.

Lo mismo pasa con las IA

Las IA pueden parecer muy listas, pero si no tienen criterio propio (y no lo tienen), pueden acabar siendo igual de pelotas que el típico compañero que siempre decía “sí, jefe”. Da igual que le digas al modelo que actúe como nutricionista o como desarrollador senior: su tendencia será complaciente. ¿Por qué? Porque ha aprendido a ser “útil”, no a tener criterio.

Yo mismo probé a pedirle a ChatGPT que me hiciera una entrevista de trabajo. Todo eran flores, todo perfecto. Pero no es realista. El problema es que si usamos estas herramientas para tareas operativas, vale. Pero si las usamos para decidir, contrastar o explorar caminos… necesitamos que cuestionen, no que aplaudan.

Las cámaras de eco también se digitalizan

Si tienes un copiloto que te dé siempre la razón, acabas encerrado en una burbuja de autocomplacencia digital. Y eso, en entornos donde se toman decisiones que afectan a presupuestos, personas o seguridad, puede ser directamente peligroso.

¿Solución? Recordar que la IA no tiene intuición. Ni experiencia. Ni contexto emocional. Puede procesar más datos que tú, pero no sabe qué importa de verdad. Y ahí, todavía, tenemos ventaja los humanos.

Moraleja

No dejes que tu copiloto sea un pelotilla. Rodéate de gente —y de máquinas— que te lleven la contraria con criterio. Ahí es donde nace la innovación de verdad 😉


¿Y tú? ¿Has detectado cámaras de eco en tu trabajo con IA? Hablemos en LinkedIn.

Este post, como otros recientes, no existiría sin una decisión y una ayuda artificial.  Diseñado en la cabeza de Iñigo, made in ChatGPT.

En que se parecen las rebajas y la innovación

Mujer en rebajas que no encuentra su talla

Una de las decisiones más prácticas que he tomado en mi vida adulta tiene que ver con las rebajas. Solo compro cosas en rebajas si no son imprescindibles. Lo que necesito de verdad, lo compro cuando lo necesito. No me espero. Porque si esperas, llegas a las rebajas y… ¡sorpresa! Ya no queda tu talla.

¿Y esto qué tiene que ver con la innovación?

Más de lo que parece. Cuando estaba trabajando como consultor de innovación para Iberdrola, solía decir que innovar es preparar hoy lo que tu empresa va a necesitar dentro de cinco años. Pero claro, eso cuesta dinero. Y la reacción más común —especialmente en perfiles más orientados a gestión— es posponer las decisiones hasta que «sea el momento». Es perfectamente entendible, pero es lo mismo que esperar a las rebajas.

¿Qué puede salir mal?

Pues que cuando por fin decidas sacar ese nuevo servicio o producto, no puedas. Porque para hacerlo necesitas tener los datos en condiciones. O porque los sistemas no están preparados. O porque te faltan permisos, o integraciones, o formación. Y esos previos, esos «ya lo haremos», pueden llevar meses.

Lo he visto más de una vez: la prueba de concepto en sí era facilísima, pero el trabajo para dejar todo listo por debajo era otro cantar. Si decides que no te interesa, perfecto. Pero si el mercado sí lo lanza y tú no puedes, vas con el pie cambiado. Y duele.

Moraleja

La innovación no es un gasto caprichoso, es una forma de asegurarte de que cuando llegue el momento, tengas tu talla. Porque lo que duele no es haber hecho una PoC que no llega a nada… es necesitar algo y no tenerlo ni por asomo.


¿Te ha pasado algo parecido? Me encantaría leerlo en LinkedIn 😉

Diseñado en la cabeza de Iñigo, made in ChatGPT es también innovación y usar una herramienta para facilitarte el trabajo es como ir de rebajas, obtienes lo mismo por menos precio. Y si le pides que te genere una imagen con el prompt es español, igual la chica tiene seis dedos…

Cuando esconder el conocimiento ya no es estrategia

Equipo extrañado por compañero que no comparte

Hace años, en un proyecto con un cliente, teníamos que integrarnos con una herramienta desarrollada in-house. Cuando necesitábamos ayuda, uno de los técnicos del cliente nos advirtió sobre el especialista que la había construido: “es un externo, y solo cuenta lo mínimo para no volverse prescindible”. Esa estrategia de retener el conocimiento como escudo de empleo me dejó pensando… y ha vuelto con fuerza gracias a la IA.

¿Hasta cuándo se puede esconder el conocimiento?

En aquel entonces, guardar el know-how era casi una garantía de estabilidad, si lo conseguías claro. Hoy, con herramientas como los copilotos de IA o los modelos LLM personalizados, la lógica ha cambiado. La IA aún no hace magia, pero ya se estima que puede aportar entre un 5 % y un 15 % de productividad en tareas comunes. Y eso es solo el principio.

El verdadero salto vendrá cuando superemos el umbral del 40 % en tareas sistemáticas, como las de back-office o soporte técnico. ¿Qué pasará entonces con quienes basaban su valor en ser los únicos que sabían “cómo funcionaba aquello”?

¿Tu conocimiento vive solo en ti… o también en una IA?

La paradoja es interesante: quienes antes no querían documentar para no ser sustituibles, ahora tienen que decidir si entrenan a una IA con su saber. Pero si lo hacen bien, puede que ya ni siquiera sea el cliente o el proveedor quien se beneficie: podrían tener un copiloto entrenado a su manera, con su estilo, con sus matices. Algo más que una libreta de notas, menos que un clon… pero suficientemente eficaz.

Esto conecta con lo que ya comentábamos en otras entradas: hay que ir tachando lo que ya no haces mejor que una máquina. Si el diferencial era “tenerlo todo en la cabeza”, más vale ir pensando otro.

¿Y si una IA asiste a todas las reuniones?

Imagina que una IA está en todas las reuniones, captura todas las decisiones, accede a toda la documentación y, además, no olvida. ¿Dónde queda entonces el “valor” de ser el que sabe lo que se dijo? El conocimiento tácito, ese que se filtra por los pasillos, puede tener los días contados.

Claro que siempre quedarán lagunas: el histórico anterior a la IA, las decisiones no documentadas, los matices que no están escritos. Pero el campo de juego se está estrechando. Y quienes no se adapten, se verán atrapados entre lo que saben… y lo que no quieren soltar.

Moraleja

El conocimiento deja de ser poder si no evoluciona en utilidad. Hoy, el valor está en saber explicar, conectar y aplicar. No en esconder. Si antes era cuestión de ego, ahora es de estrategia.


💬 ¿Cómo ves tú esta transición? ¿Has vivido ya situaciones parecidas? Lo comentamos en LinkedIn.

✍️ Sí, me ha echado una mano ChatGPT. Pero la historia, la idea y las dudas son mías. Como siempre. Diseñado en la cabeza de Iñigo, made in ChatGPT.

Le he pedido a ChatGPT que me haga una entrevista de trabajo

Robot humanoide plateado entrevistando a un candidato sonriente en una luminosa oficina acristalada, metáfora de cómo la IA puede preparar entrevistas de trabajo.

Hace unas semanas le pasé a ChatGPT mi currículum… y le pedí que me hiciera una entrevista de trabajo. Como si fuese un recruiter de carne y hueso. Igual piensas que me falta un hervor… o dos. Pero espera.

¿Y si probamos a pensar fuera de la caja?

Muchos usan ChatGPT como un sustituto de Google. Pero es que se pueden hacer cosas bastante más potentes. Me explico:

Ando estos días actualizando mi web y mi currículum, que estaban un pelín “vintage”. Y en lugar de pelearme con textos desde cero, me estoy apoyando en la IA para tareas más monótonas. Tengo un GPT personalizado al que le dicto ideas tipo nota de voz, y me las devuelve formateadas como si las hubiese escrito yo.

La clave está en el contexto. Si quiero que el GPT escriba como yo, necesita saber cómo hablo, qué tono uso, qué temas trato. Así que le he cargado la exportación completa de mi blog. Pero claro, el blog no cubre todo. Hay temas que no puedo publicar por privacidad o confidencialidad. O simplemente porque creo que no aportarían nada a terceros.

Entonces pensé: ¿cómo le doy un contexto más amplio?

La idea loca (que no lo es tanto)

Le pasé también el currículum. Pero el currículum tradicional, seamos sinceros, es más una lista de tecnologías que otra cosa. No transmite bien los últimos años de mi carrera. Así que le dije: “hazme una entrevista”.

Y ahí se obró la magia. El GPT me empezó a lanzar preguntas: ¿por qué tomaste esta decisión?, ¿qué aprendiste en tal proyecto?, ¿en qué te consideras fuerte?

A partir de mis respuestas, me generó un resumen profesional más ajustado. Más fiel. Más útil. Y ese resumen, lo puedo enchufar a mi GPT para que escriba posts con más contexto, mejor alineados conmigo.

Días después vi un vídeo de Euge Oller haciendo exactamente lo mismo. No estamos tan zumbados, al final 😉

El límite no está en la IA, está en nuestra imaginación

Lo dicho: ChatGPT puede ser un buscador vitaminado, sí. Pero también puede ser un sparring, un entrevistador, un resumidor o incluso tu propio escribano digital.

A veces no es que la IA no pueda hacerlo. Es que ni se nos ocurre pedirle ciertas cosas.

Moraleja

No subestimes el poder de probar cosas “raras”. Muchas veces, lo raro hoy será lo normal mañana.


¿Tú también has probado a usar la IA para algo “poco habitual”? Cuéntamelo en LinkedIn, me encantará leerlo.

Aparte de pedirle que te haga una entrevista, sirve para que este articulo esté Diseñado en la cabeza de Iñigo, made in ChatGPT

Mentoring: la pieza oculta para optimizar equipos de desarrollo

Un equipo y su mentor

Cuando empece a trabajar hubo compañeros y jefes que me ayudaron como funcionaba realmente una empresa y siempre he pensado que también me corresponde a mi ayudar a los compañeros mas nuevos, pero además…

¿De qué sirve tener una cadena de suministro de software ultrarrápida o una arquitectura perfecta si el equipo humano es el eslabón más débil?

La construcción de software es un proceso creativo: los errores (y los aciertos) provienen, en última instancia, de las personas. Aquí es donde el mentoring marca la diferencia: permite que el conocimiento fluya, que los errores se minimicen y que los equipos realmente mejoren sprint a sprint.

Por qué el mentoring importa cuando buscas eficiencia

Aplicar el mentoring te va a aportar entre otras cosas los siguientes beneficios:

  • Evita cuellos de botella “silenciosos”: un junior que duda 30 min por día suma > 10 h/mes de fricción para el equipo.
  • Acelera la curva de aprendizaje: compartir heurísticas reales —no solo teoría— reduce en meses la autonomía operativa.
  • Mejora la calidad de código y la moral: menos retrabajo y más confianza mutua.

Optimizar un pipeline CI/CD sin optimizar a las personas es como afinar un motor y usar combustible de mala calidad.

Que es para mi el mentoring

Cada uno tiene una forma de entender el mentoring, pero para mi es:

Transferencia de experiencia aplicable: trucos, patrones y errores que no aparecen en la documentación oficial.

Modelo de acompañamiento, no de inspección: el mentor no dicta, pregunta y guía.

Focus en cómo trabajar, no solo en el qué: feedback constructivo, buenos hábitos, comunicación con negocio.

Moraleja

El mentoring no es un “extra” blando; es la columna vertebral que convierte buenas herramientas en resultados reales. Si tu equipo está estancado a pesar de tener la mejor arquitectura, quizá el siguiente sprint de optimización no deba pasar por Jenkins, sino por una conversación uno-a-uno. También puedes echarle un vistazo a como aterizar a un junior, o una IA.


¿Tienes alguna experiencia similar? Conectemos en LinkedIn y la comentamos.

Ultimamente mi mentor es ChatGPT, ya sabes Diseñado en la cabeza de Iñigo, made in ChatGPT.

Old Money: cuando el legado es viejo y el presupuesto escaso

Código legacy sin presupuesto en entornos empresarialeS

Hace unos años me tocó evaluar una aplicación que íbamos a reutilizar en varios equipos. Nada más abrir el código, se me escapó un “¡madre mía, qué jardín!”. Pero lo curioso no fue la calidad del código, sino la reacción del responsable: “Sí, está mal, pero sabemos por qué está así… y lo queremos mejorar”. Esa honestidad me pareció más valiosa que muchos frameworks.

El estilo Old Money: ni nuevo ni barato

Hay un patrón que me encuentro más veces de las que me gustaría. Le llamo el “estilo Old Money”. Que no, no va de ricachones con traje slim y zapatillas blancas. Va de aplicaciones viejas (Old) sin un duro para actualizarlas (Money). Resultado: parches, código legacy, frameworks obsoletos… y un equipo que muchas veces ni lo ve.

Creo que el mayor problema no es que la aplicación sea vieja. Me explico:

  • Lo realmente peligroso es cuando el equipo no es consciente de las limitaciones.
  • Como dicen los nutricionistas: lo más insano no es lo que sabes que es malo, sino lo que crees que es sano y no lo es. Pues esto, igual.

Si crees que tu aplicación es decente y no lo es, ni te planteas mejorarla. Y si encima no tienes presupuesto, apaga y vámonos.

La autoconciencia como primer paso

Me encontré una vez con un desarrollador que reconocía abiertamente los problemas de su código. No se excusaba, los asumía. Me explicó cómo había llegado a ese punto. A partir de ahí, pudimos planear mejoras: cada uno rascó algo de dinero de su parte y conseguimos hacer una pequeña inversión para refactorizar el núcleo. Poco, pero suficiente para salir del pozo.

Y lo más importante: el equipo ganó en confianza y visibilidad.

¿Qué hacemos con un Old Money?

  1. Diagnóstico brutal: ¿El código es viejo? Bien. ¿Lo sabemos? Mejor.
  2. Documentar la deuda: Aunque no puedas pagarla, haz inventario.
  3. Buscar aliados: Producto, negocio, compañeros… a veces todos rascamos un poco.
  4. Miniproyectos de mejora: No todo requiere un rediseño total. A veces basta con encapsular, testear, y preparar el terreno.

Moraleja

Si tienes un Old Money en casa, lo primero es dejar de creer que es Gucci cuando en realidad es Primark. Y lo segundo, empezar a rascar euros y voluntades para mejorar.


👉 Si quieres ver cómo empiezo a diagnosticar estos casos, pásate por esta entrada sobre cómo abordar el desarrollo de una aplicación CRUD. Ahí te cuento cómo organizar la casa… aunque esté vieja.

💬 ¿Te has cruzado con un “Old Money” en tu carrera? Cuéntamelo por LinkedIn, me encantará conocer otros casos reales.

Este articulo ha sido Diseñado en la cabeza de Iñigo, made in ChatGPT

Cuando tu radar profesional se queda sin señal: lo que la IA puede cambiar (o no)

Hombre mirando a un radar

Me acuerdo perfectamente del primer día en uno de los últimos proyectos en los que entré. Lo típico: presentación, “te contamos cómo lo hacemos aquí” y tour por la herramienta estrella de la casa. Mientras escuchaba, mi cabeza iba haciendo su propia evaluación. “Esto así no va a funcionar”, “esto otro sí tiene recorrido”, “aquí hay una bomba de relojería”…

25 años viendo qué funciona (y qué no)

Después de haber pasado por más de una decena de empresas, múltiples proyectos, sectores y equipos de todos los colores, acabas desarrollando un radar. No es infalible, pero sí afinado. A fuerza de ver patrones repetidos —unos con éxito, otros estrellándose— empiezas a anticipar qué prácticas tienen futuro, cuáles no tienen recorrido y cuáles son postureo puro, como ahora está de moda el palabra BigData (pon aquí lo que quieras) sigo haciendo lo mismo de siempre pero le llamo BigData y así molo más.

Claro, luego la realidad siempre tiene matices. Lo que en una empresa funciona de lujo, en otra puede hundirte. Pero hay aprendizajes que se te quedan grabados: cómo leer un equipo, cuándo una metodología es humo, qué herramientas son palanca y cuáles son lastre.

Cambia la tecnología, pero no el oficio

Puedes pasar de JBoss a SpringBoot en OpenShift, de Eclipse a Visual Studio Code, y de seguimientos en papel a tareas en Jira. Pero el núcleo del oficio sigue ahí: entender problemas, coordinar equipos, construir soluciones que funcionen en producción.

Hasta que llega la inteligencia artificial. Y ahí, cuidado. Porque no estamos hablando de una nueva herramienta, sino de algo que puede alterar los fundamentos. Cambian los puntos de referencia, los procesos, incluso la relación entre roles. Lo que sabías que funcionaba entre personas… ahora puede volar por los aires.

¿Sigue sirviendo todo lo aprendido?

Esa es la pregunta que me estoy haciendo últimamente. Y no desde la barrera, sino metiéndome de lleno. Probando, experimentando, leyendo, cacharreando. Porque igual que en su día me tocó entender qué pintaba Docker o cómo se organizaba un equipo ágil, ahora toca ver cómo encaja la IA en nuestra práctica profesional.

Creo que parte del conocimiento acumulado seguirá siendo útil, aunque adaptado. Pero otra parte, directamente, caduca. Y no pasa nada. Al revés: si eres de los que no se conforma con “lo de siempre”, esta es una etapa excepcional.

Si todo cambia, hay que moverse

Las disrupciones tecnológicas tienen algo bueno: sacuden el árbol. El que se mueve bien puede escalar varios peldaños. Profesionalmente, sí. Pero también personalmente. Porque la IA no solo está transformando el código o los flujos de trabajo; está replanteando cómo usamos nuestro tiempo, cómo tomamos decisiones, cómo nos comunicamos.

Moraleja

En momentos de disrupción, el mejor radar no es el que predice, sino el que se recalibra rápido. Y en eso, tenemos ventaja.


Conectemos en LinkedIn para seguir conversando el impacto de la IA en la carrera.

Este articulo ha sido Diseñado en la cabeza de Iñigo, made in ChatGPT 😉