Un año más estuvimos en la Fredcon, la conferencia sobre liderazgo técnico y gestión de personas que organiza Manfred, y un año más volvimos con la sensación de haber estado en un evento tan sui generis como necesario: un espacio pensado para cuestionar la industria, no para celebrarla.
La edición de 2026 estuvo dedicada, como no podía ser de otra forma, a la inteligencia artificial. No se habló tanto de herramientas como de lo que la IA hace con y en las organizaciones, con los roles y, por lo tanto, con las personas que formamos parte de ellas. Una idea se repitió: la IA no solo crea retos nuevos; muchos de los que trae consigo no son más que retos que ya teníamos, pero amplificados.
El año pasado se advirtió de que aplicar IA sobre un proceso deficiente solo sirve para ampliar sus problemas. Este año esa advertencia dejó de ser un susurro en los pasillos para convertirse en el hilo conductor de la mayoría de las ponencias.
+AI o AI first: ¿herramienta o transformación?
La primera pregunta que planteó la jornada es qué significa ser AI first. No es lo mismo entender la IA como una herramienta más, que se suma a las que ya usamos (+AI), que entenderla como algo que transforma la forma de trabajar. Y los ponentes lo entienden de diferentes formas.
En «Beyond Adoption: Building a Company That Works with AI», Félix López (Technosylva) fue el más explícito. Su empresa logró que la IA se adoptara, pero descubrieron que esa adopción, por sí misma, no es más que otra vanity metric: usar IA no es ser AI first. Serlo implica transformar la forma de trabajar y medirlo contra resultados de negocio, no contra el número de personas que la usan.
Outputs frente a outcomes: la reflexión no es nueva. El año pasado, en esta misma conferencia, Eduardo Ferro ya la planteó en «Incentivos Perversos» contra el «Taylorismo Digital».
Miriam Martín (IBM), en «El tiempo que nos devolvió la IA», también presentó el paso de +AI a AI first como una transformación: eliminar, simplificar, automatizar y rediseñar los procesos alrededor de la IA. Añadió un matiz importante: AI first no significa IA en todo, sino saber dónde y cómo usarla.
Laura Lacarra (Telefónica) invirtió el orden: primero el proceso y el para qué, después la herramienta. Entre estas diferentes experiencias, la conclusión es que la IA solo es transformacional cuando cambia cómo trabajamos, no cuando se limita a acelerar lo que ya hacíamos.
Estrategia en un contexto reactivo
Félix también contó cómo empezaron: sin estándares, sin gobernanza, sin cultura y, sobre todo, sin estrategia. Su aprendizaje nos muestra que implantar la IA exige una estrategia que permita ser lo menos reactivos posible.
Esto puede parecer aspiracional, porque la reactividad es consustancial al momento que vivimos: las herramientas cambian constantemente y las estamos usando antes de que exista ningún marco. Por eso la estrategia no consiste en adelantarse a todo, que es imposible, sino en tener criterios claros para decidir qué adoptar, cómo medirlo y cuándo corregir.
Parte de esa estrategia pasa por algo tan poco vistoso como la práctica. En Technosylva, la formación teórica y la evangelización no funcionaron. Lo que funcionó fueron los espacios de práctica sobre problemas reales, como un hackathon con tareas que llevaban tiempo bloqueadas.
Cada contexto es diferente
En «Liderazgo aumentado: acompañar equipos sin añadir presión», Henar Vega (Origance Studio) presentó los resultados de una investigación de más de tres años sobre cómo está afectando la adopción de la IA a los profesionales del sector. Dejó muchos aprendizajes, pero quizás el más importante fue que el contexto y las circunstancias de cada empresa lo condicionan todo.
La modalidad de trabajo es un ejemplo. En los equipos remotos la IA se usa más para resolver problemas, a menudo para suplir canales o procesos que no son suficientemente buenos. En los presenciales hay más sensibilidad hacia las cuestiones éticas, porque se debaten en los momentos informales que el remoto no ofrece de forma natural.
La propia jornada lo ilustró: hubo charlas que proponían imponer herramientas de forma decidida y otras que advertían de los riesgos de convertirnos en policías, visiones optimistas sobre el futuro del trabajo y otras abiertamente escépticas. No son contradicciones, son contextos distintos.
Conviene no repetir errores del pasado, como cuando en la industria empezamos a copiar en masa modelos organizativos como los squads sin preguntarnos si encajaban en nuestra realidad concreta. Siempre es bueno recordar el aforismo de George Box: «todos los modelos son erróneos, pero algunos son útiles».
La IA transforma los roles
Uno de los impactos más relevantes de la IA es el cambio que se está produciendo en los roles de las compañías. En «Diseñando a velocidad terminal», Ismael Canal (GitHub) habló del Design Engineer, un rol que ilustra bien ese cambio.
Durante años, el diseño ha trabajado separado del desarrollo: la propuesta se entregaba cerrada, llegaba al equipo técnico y, en ese traspaso, se recortaba lo que no era viable.
Si ahora los equipos de desarrollo multiplican su capacidad de entrega, ese modelo se convierte en un cuello de botella. El Design Engineer rompe esa frontera.
No es un diseñador que aprende a programar, sino alguien que se siente cómodo en el entorno de desarrollo, entiende su lenguaje y, con ayuda de agentes, genera código sin necesidad de escribirlo. Eso lo acerca a una pregunta que antes resolvía otro: si lo que propone es viable.
Su valor no está en producir pantallas, sino en asumir el ownership del sistema de diseño. Es su arquitecto: define los componentes, las convenciones y las decisiones de diseño (qué se ha hecho y por qué), y las lleva al repositorio para que desarrolladores y agentes trabajen sobre la misma base.
Las herramientas, como los componentes documentados, las reglas que avisan cuando algo se sale del sistema o las pruebas de regresión visual, son el medio. El fin es que el handoff deje de ser una entrega y se convierta en una conversación continua con el resto del equipo, que también funciona a la inversa: los desarrolladores pueden participar en el discovery con más seguridad.
Es un ejemplo concreto de algo más amplio: estamos haciendo un trabajo muy distinto con los roles de antes, y todavía no hemos reflexionado lo suficiente sobre cómo deben cambiar ni hacia dónde lo están haciendo.
Liderar sigue siendo lo mismo
En «Management 101», Pau Ramón (Ramensoft) recordó que los retos de liderar siguen siendo los de siempre. Delegamos porque hay problemas que no podemos resolver solos, pero delegar no nos libera de la responsabilidad sobre esos problemas.
Esa responsabilidad se ejerce a través de las decisiones sobre las personas, como a quién incorporar o cómo ayudarlas a crecer, y ninguna es posible si no entendemos lo que hemos delegado.
El paralelismo con la IA es evidente. Cuando delegamos algo en un agente, seguimos siendo responsables del resultado. Javi Velasco (Vercel) lo resumió en «AI Won’t Replace Craftsmanship»: desde hace meses apenas escribe código, «pero los commits llevan mi nombre».
Podemos delegar la ejecución, pero no las decisiones ni la responsabilidad. Revisar lo que ha hecho un agente no equivale a haberlo hecho, y exige un criterio que solo se construye con práctica y oficio.
La importancia del contexto
Si la responsabilidad no se delega, lo que sí cambia es cómo se trabaja con quien ejecuta. En «How much does your agent really know about your company?», Elisenda Bou (Cala) definió el contexto como todo lo que necesitas para tomar una decisión.
Parte de él es explícito (documentos, procesos, políticas) y parte implícito (el juicio, la experiencia, la cultura). Los modelos comprimen el conocimiento y, al comprimir, lo pierden.
Por eso las organizaciones necesitan una estrategia para generar contexto: registrar, organizar y actualizar lo que saben, codificar cómo deciden y no solo qué deciden.
Javi Velasco llegó a la misma conclusión desde la ingeniería: el artesano de hoy es quien diseña el contexto con el que trabaja el agente. Ese contexto puede faltar, puede ser engañoso o puede sobrar. Y los atajos que tomamos acaban convertidos en convenciones que la IA reproduce.
Lo que es esencialmente humano
Miriam Martín propuso una forma práctica de abordar la pregunta de qué hace cada uno: descomponer cada función en sus competencias y clasificarlas en tres categorías, según la IA pueda potenciarlas, puedan convertirse en agénticas o sean esencialmente humanas. Cuanto más determinista es una tarea y más volumen tiene, más potencial agéntico tiene.
Esa parte esencialmente humana enlaza con el craftsmanship de Javi Velasco: diseñar antes de escribir, modelar el dominio, pensar a largo plazo. La IA minimiza la parte ejecutiva del trabajo y hace más importante la del oficio, una palabra que viene del latín officium, de opus (obra) y facere (hacer). Tener oficio no es solo ejecutar: es saber hacer la obra.
Laura Lacarra, con la charla más ecléctica de la jornada, pero una de las que más hicieron pensar, señaló otra de esas capacidades y su fragilidad: el criterio y el espíritu crítico. Su pérdida es, a su juicio, uno de los riesgos más serios que plantea el momento actual.
Nuevos planes, idénticas estrategias
La Fredcon26 deja una conclusión menos espectacular de lo que suele prometer el discurso sobre IA, y por eso es más útil. La mayoría de los retos a los que nos enfrentamos (procesos frágiles, roles poco definidos, liderazgo sin recursos, conocimiento disperso) existen desde hace mucho tiempo. La IA los amplifica y los hace visibles. Pero no los soluciona.
No se trata de refugiarse en el mantra de que «los humanos somos irremplazables»: la IA está aquí y forma parte de la industria.
Lo que la jornada señaló es más concreto: lo que no se puede delegar en la IA es la responsabilidad sobre el resultado, el criterio para juzgarlo, el contexto que da sentido a una decisión y el aprendizaje al que solo se llega haciendo. En otras palabras, lo que no se puede delegar en la IA es el oficio.
Nuestra reflexión
Como el año pasado, la Fredcon ha sido para nosotros tanto una confirmación como un reto. Nos llevamos tres compromisos:
- IA con criterio, no IA por inercia. Queremos medir el impacto de la IA en cómo entregamos valor, no en cuánto la usamos, y decidir en cada caso dónde aporta y dónde no.
- La responsabilidad es de quien delega. Delegar en la IA no cambia quién responde por el resultado. Por eso ponemos el foco en entender antes de delegar y en cuidar el oficio de quienes diseñan y construyen.
- Nuestro contexto primero. Somos un equipo 100 % remoto y sabemos que ningún modelo externo se aplica tal cual. Nos gustaría adaptar lo aprendido a nuestra realidad, cuidando especialmente los espacios de conversación y debate que el remoto no da por sí solo.
Recent Comments