Hoy conversamos con Jordi Cabot, investigador en ingeniería del software en el Luxembourg Institute of Science and Technology (LIST) y profesor afiliado en la Universidad de Luxemburgo. Su trabajo se centra en cómo desarrollar better software faster: crear software más rápido y con menos errores mediante modelado, desarrollo dirigido por modelos e inteligencia artificial.

Partimos de una pregunta central: ¿está la inteligencia artificial transformando radicalmente la ingeniería del software? Jordi defiende que el desarrollo de software es una ingeniería, no un arte. Igual que en la construcción de un edificio, primero se definen requisitos, luego se diseñan modelos y solo después se construye el sistema. El problema no es escribir código, sino asegurar que el software haga exactamente lo que el usuario necesita.

Hablamos del desarrollo dirigido por modelos, donde el sistema se describe mediante modelos de datos, comportamiento e interfaz. A partir de ellos puede generarse automáticamente gran parte del código, dejando los aspectos más específicos para programación manual. Este enfoque, que hoy se comercializa como low-code, no es nuevo, pero está cobrando fuerza en el contexto actual.

Analizamos también el llamado vibe coding, es decir, generar aplicaciones directamente en lenguaje natural con ayuda de modelos de lenguaje. Frente a esta aproximación, Jordi propone usar la IA para generar modelos (los “planos”) y no directamente el código final, lo que permite validar la estructura antes de construir el sistema y reducir errores ocultos.

Abordamos la idea recurrente de que la IA hará desaparecer a los programadores. Según Jordi, cada revolución tecnológica ha generado ese temor, pero la realidad es que cuanto más fácil es crear software, más software se produce y mayor es la necesidad de profesionales capaces de entender, validar y diseñar sistemas complejos.

También discutimos el concepto de software responsable: sistemas energéticamente sostenibles, sin sesgos, accesibles y adaptables a distintos perfiles de usuario. La IA puede facilitar esa personalización, pero también introduce riesgos que deben gestionarse con criterio.

Finalmente, hablamos de su libro Research Rants y de los retos actuales del sistema científico: la presión por publicar, la competitividad extrema y el impacto creciente de la IA en la escritura y evaluación de artículos. Una conversación sobre software, inteligencia artificial y el futuro de la investigación.

Enlaces:

· Web de Jordi Cabot: https://jordicabot.com

· Plataforma BESSER (low-code open source): https://besser-pearl.org/

· Libro Research Rants: https://research-rants.com/ y https://lowcode-book.com/

· Grupo en LIST: https://www.list.lu

Si el episodio te ha resultado interesante, puedes apoyarlo dándole a like, suscribiéndote o compartiéndolo en tu plataforma habitual (Spotify, Apple Podcasts, iVoox, YouTube, etc.). Es un gesto que te cuesta muy poco y que ayuda muchísimo a que este podcast siga creciendo y llegue a más personas.

¿Te imaginas obtener un 94% o un 95% en una convocatoria Marie Curie y aun así quedarte fuera porque el corte está en el 96%? Eso es lo que ha ocurrido recientemente. Un umbral que hace unos años rondaba el 90–91% ahora se sitúa en cifras que rozan la perfección. Y no es un caso aislado: está pasando en proyectos europeos, ERC y otras convocatorias. El sistema se ha vuelto mucho más competitivo y la pregunta ya no es solo cómo escribir una buena propuesta, sino qué está cambiando para que necesitemos prácticamente la excelencia absoluta para entrar.

Una de las causas más evidentes es el uso masivo de inteligencia artificial por parte de los solicitantes. Investigadores con buenas ideas y buen currículum, pero menos tiempo o habilidad de redacción, ahora pueden generar propuestas sólidas con apoyo de estas herramientas. Resultado: más solicitudes y, en promedio, mejor presentadas. Si aumenta el número de propuestas competitivas, el corte necesariamente sube.

Pero el cambio también está en la evaluación. Cada vez hay más indicios de que se utilizan modelos de lenguaje para realizar un primer filtrado: cargar las bases, cargar la propuesta y pedir una evaluación por criterios. Después, el evaluador humano revisa las mejor puntuadas. Podemos debatir si es adecuado o no, pero lo prudente es asumir que puede estar ocurriendo y prepararse para ello.

Eso implica actuar en dos niveles. Primero, competir mejor: leer en profundidad las bases, entender exactamente qué se evalúa y formular el proyecto con el lenguaje y las palabras clave que activan la máxima puntuación. No basta con tener buenas ideas; deben estar expresadas como espera la convocatoria. Segundo, simular el filtro algorítmico: evaluar nuestra propuesta con distintos modelos, varias veces, identificar patrones de debilidad y corregirlos de forma iterativa. No infinitamente, pero sí lo suficiente para eliminar puntos ciegos.

Después llega la fase humana. Ahí importa la coherencia global, la claridad y la credibilidad científica. En ese punto es clave obtener feedback de supervisores, colegas con experiencia o incluso consultores especializados. Porque aunque la IA pueda filtrar, la decisión final sigue dependiendo de personas.

Y una última idea estratégica: no apostar todo a una única convocatoria. Diversificar, buscar programas nicho menos masificados y reducir la densidad competitiva puede ser tan importante como optimizar el texto. La carrera investigadora implica aplicar de forma constante. Si el sistema cambia, nuestra manera de prepararnos también debe cambiar.

Puedes contactarme a horacio@horacio-ps.com si quieres hablar más en detalle de todos estos procesos y recibir asistencia.

Hoy hablamos de modelización hidrológica, pero también, y quizá sobre todo, de lo que significa investigar en España hoy.

Adrián López-Ballesteros nos explica cómo se construye un modelo hidrológico, qué significa realmente eso de “gemelo digital”, cómo se calibra, por qué lo difícil no es montarlo sino hacerlo funcionar y cómo se utilizan estos modelos para responder preguntas del tipo “¿qué pasaría si…?”. Desde cambios en cultivos hasta escenarios de lluvias extremas, pasando por gestión de recursos hídricos e impacto ambiental.

Entramos en dos casos muy concretos:

A) Por un lado, el Mar Menor: qué está ocurriendo a nivel de cuenca, por qué la eutrofización no es un problema aislado sino sistémico y qué muestran los modelos cuando se evalúan distintas medidas de actuación. Una idea clave: las soluciones aisladas tienen efecto limitado; las combinaciones generan efectos sinérgicos mucho más relevantes. Ciencia aplicada que intenta dialogar con la administración y evaluar si las medidas que se están implementando realmente funcionan.

B) Por otro lado, la DANA de Valencia (2024). Aquí la conversación se vuelve especialmente interesante: modelos hidrológicos e hidráulicos validados con “sensores sociales”, es decir, datos geolocalizados extraídos de redes sociales para contrastar hasta dónde llegó el agua y en qué momento. Ciencia frente a bulos. Modelización frente a ruido. Y una reflexión sobre cómo la frontera entre ingeniería e informática, la llamada hidroinformática, puede abrir nuevas vías de investigación y desarrollo de herramientas útiles para otros investigadores.

Hablamos también de herramientas abiertas, de Google Earth Engine, de reducir la curva de aprendizaje de modelos complejos como SWAT y de qué significa “éxito” en investigación. Para Adrián, ser útil. Desarrollar herramientas que otros puedan usar. Cerrar el ciclo entre investigación, publicación y divulgación.

Y, finalmente, entramos en la parte menos técnica pero más estructural: la carrera investigadora como maratón, o incluso como 90K. Becas predoctorales, Juan de la Cierva, Marie Curie, Ramón y Cajal. Competencia creciente. Inteligencia artificial y redacción de propuestas. Métricas, perfiles R1–R4, sesgo del superviviente, estabilidad, familia y decisiones personales.

Una conversación honesta sobre incertidumbre, vocación, presión y equilibrio. Sobre cuándo seguir, por qué seguir y hacia dónde orientar la energía. Porque investigar no es solo publicar: es sostener en el tiempo una forma de estar en el mundo.

Enlaces mencionados en el episodio:

- Publicaciones de Adrián sobre Mar Menor y DANA: https://doi.org/10.1016/j.ijdrr.2025.105966 (DANA); https://doi.org/10.1016/j.jenvman.2025.125033 (Mar Menor 1); https://doi.org/10.1016/j.scitotenv.2022.160144 (Mar Menor 2); https://doi.org/10.1016/j.jhydrol.2021.127150 (Mar Menor 3)

- Canal de YouTube de Adrián López-Ballesteros (@AdrLBallesteros): https://www.youtube.com/@AdrLBallesteros, https://youtube.com/playlist?list=PLc5YYSH07rwBuwL3ykA_m4CCsUJzi-VC6&si=BDtGt8OWNia3fPCH (📢Divulgación Científica🌍)

- Documento “La carrera investigadora en España en una mirada”: https://www.fecyt.es/publicaciones/researcher-career-path-spain-glance

- Recursos sobre perfiles R1–R4: https://www.upv.es/entidades/vinv/2025/10/03/descriptores-de-perfil-investigador-r1-r4/

Hoy exploramos el estudio de lo social desde la inteligencia artificial, centrándonos en los sistemas multiagente. Hablamos con Carles Sierra, investigador del IIIA-CSIC y referente internacional en este campo, sobre cómo los sistemas formados por múltiples agentes autónomos pueden ayudarnos a entender fenómenos sociales complejos como la cooperación, el conflicto, las normas o la confianza.

Durante la conversación abordamos qué es exactamente un agente, cómo se define formalmente y qué implica que tenga autonomía, reactividad, proactividad y una dimensión social. Discutimos también dos enfoques principales para su diseño: los modelos basados en conocimientos, donde las reglas se programan explícitamente, y los modelos basados en datos, donde los agentes aprenden a partir de ejemplos. Además, hablamos del papel creciente de los modelos híbridos, que combinan grandes modelos de lenguaje con razonamiento simbólico para sortear algunas de las limitaciones actuales.

Carles explica con detalle cómo su grupo utiliza estos enfoques para simular situaciones sociales reales. Un ejemplo especialmente interesante es el uso del juego cooperativo Hanabi como laboratorio para estudiar la teoría de la mente en agentes, es decir, su capacidad para inferir lo que otros agentes saben o creen. Este tipo de simulaciones no solo permite mejorar el diseño de agentes más sofisticados, sino también plantear hipótesis sobre el comportamiento humano desde una perspectiva computacional.

La charla también aborda aplicaciones prácticas como la simulación de evacuaciones en contextos de emergencia o el uso de realidad virtual para entrenamiento. En todos estos escenarios es clave el trabajo conjunto con expertos en psicología, sociología o cuerpos de emergencia, lo que refuerza la dimensión multidisciplinar de esta línea de investigación.

Hablamos además de la conexión con la teoría de juegos y la racionalidad, de cuellos de botella técnicos como la comunicación entre agentes, y de cómo los modelos de lenguaje actuales están empezando a ofrecer soluciones en ese frente. Carles comparte su visión sobre la evolución de este campo, los retos futuros y el contexto global, con referencias al crecimiento exponencial de la investigación en inteligencia artificial en países como China.

En la parte final, reflexiona sobre su trayectoria, los momentos que más satisfacción le han dado como investigador y ofrece recomendaciones claras para quienes quieran adentrarse en este tipo de investigación.

Recursos mencionados

- Hanabi (juego cooperativo): https://boardgamegeek.com/boardgame/98778/hanabi

- Teoría del equilibrio de Nash: https://en.wikipedia.org/wiki/Nash_equilibrium

- Congreso IJCAI: https://ijcai.org/

- Congreso AAMAS: https://aamas.org/

- Proyecto ADA (China): red de satélites con LLMs embebidos

Para contactar a Carles Sierra:

- Instituto de Investigación en Inteligencia Artificial (IIIA-CSIC): https://www.iiia.csic.es/~sierra/

Si el episodio te ha resultado interesante, puedes apoyarlo dándole a like, suscribiéndote o compartiéndolo en tu plataforma habitual (Spotify, Apple Podcasts, iVoox, YouTube, etc.). Es un gesto que te cuesta muy poco y que ayuda muchísimo a que este podcast siga creciendo y llegue a más personas.

En este episodio de _Investigando la Investigación_ reflexiono sobre una forma de investigar que no siempre parte de una pregunta clara ni de una metodología cerrada: la investigación exploratoria. Una investigación que surge al hacer, al probar y al interactuar con sistemas que nos devuelven feedback, incluso cuando no sabemos exactamente qué estamos buscando.

Parto del propio recorrido del podcast, que comenzó centrado en investigación académica en informática y que, con el tiempo, se ha ido abriendo a otras ciencias, a las humanidades, al arte y, en general, a cualquier contexto donde exista un proceso investigador. Tras cerca de 380 episodios, el objetivo sigue siendo el mismo: documentar y explorar cómo se investiga, dentro y fuera de los marcos académicos reglados.

Para concretar esta idea, comparo dos contextos muy distintos. Por un lado, la investigación que hacemos en mi grupo de investigación, basada en el screening computacional de miles o millones de compuestos químicos para identificar posibles candidatos con utilidad farmacológica u otras aplicaciones. Se trata de un proceso altamente metodológico, algorítmico y con métricas objetivas bien definidas. Por otro lado, mi exploración personal en la creación sonora y musical, utilizando herramientas de producción digital desde una posición no profesional y completamente autodidacta.

A partir de esta comparación, una de las conclusiones centrales del episodio es que la ausencia de una pregunta de investigación clara al inicio no invalida el proceso investigador. En los contextos exploratorios, la pregunta, la metodología y los criterios de evaluación pueden emerger progresivamente, a medida que el investigador interactúa con el sistema que está explorando. Además, el hecho de trabajar con respuestas subjetivas, como ocurre en la investigación sonora, no convierte la investigación en algo arbitrario: esas respuestas forman parte del propio objeto de estudio y proporcionan un feedback relevante.

En este sentido, la diferencia entre una investigación más objetiva y una exploratoria no es la existencia o no de rigor, sino el tipo de señal que se obtiene. En el cribado de compuestos químicos, la molécula no responde al investigador; en la exploración sonora, el sonido sí lo hace, generando sensaciones que informan el proceso. En ambos casos, sin embargo, existe un proceso sistemático de acumulación de experiencia, reflexión y generación de conocimiento.

De esta exploración musical surgen también conclusiones metodológicas concretas. Por ejemplo, he identificado flujos de trabajo que para mí resultan más eficientes, como trabajar con un número reducido de pistas o instrumentos. También he observado la importancia del caos y la aleatoriedad frente a enfoques completamente deterministas, tanto en la preparación del sistema como en la ejecución. Estas decisiones, aunque personales, forman parte del resultado de la investigación y pueden ser compartidas y discutidas.

Este episodio sirve además como punto de partida de una nueva línea dentro del podcast, centrada en procesos de investigación exploratoria, especialmente en contextos donde la pregunta y la metodología se definen a posteriori. En próximos episodios entraré en ejemplos más concretos y compartiré material sonoro como apoyo, entendiendo ese resultado final casi como material suplementario, mientras que el foco principal sigue siendo el proceso investigador.

Si el episodio te ha resultado interesante, puedes apoyarlo dándole a like, suscribiéndote o compartiéndolo en tu plataforma habitual (Spotify, Apple Podcasts, iVoox, YouTube, etc.). Eso ayuda a que _Investigando la Investigación_ siga creciendo y llegue a más personas.

En este episodio de Investigando la Investigación me adentro en un terreno más técnico de lo habitual para hablar de herramientas de inteligencia artificial aplicadas a la programación y, sobre todo, del cambio de paradigma que estamos viviendo en la forma de desarrollar software. Empiezo recordando cómo usábamos —y muchos seguimos usando— modelos como ChatGPT para programar: pedir fragmentos de código, copiarlos en un editor, ejecutarlos, detectar errores y volver a iterar en un proceso manual y relativamente lento. Ese enfoque sigue siendo útil, pero empieza a quedarse corto frente a lo que está apareciendo ahora.

En los últimos meses han surgido muchas herramientas que introducen la llamada programación basada en agentes. Ya no hablamos solo de generar código, sino de sistemas que analizan una petición, la descomponen en tareas, orquestan agentes que trabajan en paralelo y deciden cómo implementar una solución completa. Menciono brevemente algunas de estas herramientas, pero el foco del episodio se centra en Cursor, que a día de hoy me parece una de las opciones más completas. Cursor es, en esencia, un fork de Visual Studio Code que integra este enfoque y permite trabajar con proyectos reales, con múltiples ficheros, relaciones complejas y ejecución directa del código generado.

Uno de los puntos clave del episodio es entender los distintos modos de trabajo de Cursor. Por un lado está el modo pregunta, pensado para discutir ideas y requisitos sin generar código. Luego está el modo plan, donde el sistema traduce esas ideas en un plan detallado de implementación que conviene revisar con calma y nunca aceptar a la primera. A partir de ahí entramos en el modo agente o de construcción, donde la herramienta despliega uno o varios agentes que implementan el plan, a menudo en paralelo. Finalmente, el modo depuración introduce un enfoque muy interesante basado en la generación y comprobación sistemática de hipótesis para localizar errores, de una forma mucho más transparente que los métodos anteriores.

También hablo de aspectos prácticos importantes, como la posibilidad de elegir distintos modelos de lenguaje según la tarea, la necesidad de controlar bien los permisos que damos a los agentes y la importancia crítica del versionado del código para poder volver atrás cuando una iteración rompe algo que antes funcionaba. Dedico además parte del episodio a explicar las limitaciones del contexto y la memoria de estos sistemas y cómo gestionar sesiones largas para evitar errores sutiles.

Para cerrar, planteo una reflexión más general: el rol del programador está cambiando hacia uno más cercano al de gestor de proyectos. Cada vez menos escribimos código línea a línea y cada vez más diseñamos planes, supervisamos agentes y validamos resultados. En este nuevo escenario, el trabajo realmente crítico pasa a ser el diseño de buenos planes y, sobre todo, de tests sólidos y fiables, que se convierten en el verdadero contrato del sistema. Todo apunta a que este cambio no ha hecho más que empezar.

Si este episodio te ha resultado interesante, te agradecería mucho que desde la plataforma donde lo estés escuchando le des a like, lo marques como favorito o te suscribas al podcast. Es un gesto muy sencillo, pero ayuda enormemente a que Investigando la Investigación crezca y pueda llegar cada día a más gente.

PD: Episodios relacionados: 234, 240, 309, 340, 341, 378

En este episodio parto de algo que, a primera vista, parece no tener nada que ver con la investigación que hago en mi grupo de investigación ni con el día a día de cualquiera de nosotros: los agujeros negros. Uso el límite de Chandrasekhar como excusa conceptual para hablar de otra cosa muy distinta. Igual que una estrella colapsa cuando supera cierta masa crítica, las personas colapsamos cuando superamos nuestro propio límite de tareas simultáneas. No importa que las tareas sean fáciles o cortas: a partir de cierto número aparece una fricción cognitiva enorme que lo vuelve todo inmanejable.

La idea clave es sencilla y bastante poco glamurosa: no podemos tenerlo todo delante a la vez. La mayoría tenemos listas interminables de cosas por hacer, pero casi nunca es necesario —ni realista— ejecutarlas todas hoy. Mi propuesta es volver de forma deliberada a una cota inferior de ese “límite de Chandrasekhar” personal: quedarnos solo con tres, cinco tareas como máximo en el corto plazo, las únicas que realmente vamos a ejecutar. El resto no se eliminan, simplemente desaparecen de nuestra vista para no consumir energía mental. No es procrastinar, es organizar la ejecución.

Donde esto se vuelve especialmente delicado es en el correo electrónico. El email mezcla tareas, información, seguimientos y ruido, todo sin estructura clara. Aquí cuento cómo uso la opción de posponer correos, por ejemplo en Gmail, pero con cabeza: no mandar todo a la misma fecha futura, sino distribuirlos según urgencia y prioridad. Algunos volverán en días, otros en semanas, otros quizá en un mes. Y, de vez en cuando, revisar esa lista de correos pospuestos para asegurarse de que nada se descontrola. La idea, en el fondo, es siempre la misma: evitar que nuestro sistema mental colapse por exceso de masa.

Si este episodio te ha resultado útil, te agradecería que en la plataforma donde lo estés escuchando le des a like, dejes un comentario o te suscribas al podcast. Estos pequeños gestos ayudan a que Investigando la Investigación tenga más alcance y pueda llegar a más personas interesadas en entender y vivir la investigación desde dentro.

En la investigación no todo es generar ideas o redactar manuscritos. También hay un momento inevitable en el que otras personas evalúan aquello en lo que hemos invertido mucho tiempo y esfuerzo. En el caso de los artículos científicos, este proceso suele permitir réplica y nuevas oportunidades. Sin embargo, en las convocatorias de financiación la situación es distinta, ya que muchas veces no existe la posibilidad de volver a presentarse.

Cuando una convocatoria es única o no se repite, un rechazo puede tener un impacto mucho mayor. Este episodio no se centra en el rechazo en sí, sino en las opciones reales que existen para afrontarlo de forma crítica. Una de ellas es la alegación, un mecanismo que, aunque suene legal o ajeno al ámbito investigador, puede ser legítimo y necesario en determinadas circunstancias.

La alegación solo tiene sentido cuando existe un informe de evaluación detallado y unas bases de convocatoria claras. Antes de iniciar este proceso, es imprescindible un ejercicio de honestidad personal. No todas las evaluaciones negativas son injustas, y alegar solo es recomendable cuando existen errores objetivos, omisiones claras o contradicciones con las propias normas de la convocatoria.

Entre los errores más habituales que pueden justificar una alegación se encuentran la supuesta falta de documentación que sí fue entregada o críticas a aspectos que no eran exigidos. En estos casos, el proceso pasa por analizar el informe con calma, identificar los puntos problemáticos y redactar un documento formal, respetuoso y constructivo, dirigido a la entidad financiadora.

La alegación debe centrarse exclusivamente en hechos verificables y argumentos sólidos, evitando opiniones personales o valoraciones subjetivas. Herramientas de inteligencia artificial pueden ayudar a mejorar el lenguaje o el tono final del documento, pero el contenido y el razonamiento deben partir siempre de la persona solicitante.

Más allá del resultado, el proceso de alegación tiene un valor formativo importante. Obliga a comprender mejor cómo funcionan los sistemas de evaluación y ayuda a desarrollar una mirada crítica que será útil tanto para futuras solicitudes como para el día en que uno mismo esté al otro lado, evaluando propuestas de otras personas.

Si este episodio te ha resultado útil, te agradecería que en la plataforma donde lo estés escuchando le des a like, dejes un comentario o te suscribas al podcast. Estos pequeños gestos ayudan a que Investigando la Investigación tenga más alcance y pueda llegar a más personas interesadas en entender y vivir la investigación desde dentro.