Originalmente publicado en: Podcast +D episodio 125. Final de semestre 2025. Las fusiones que no mejoran una empresa. – Blog Oficial Más Dividendos +D
Comentamos el resumen de mercados del primer semestre de 2025.
Importancia de las Inteligencia Artificial en el mundo en general y en la inversión en particular.
Hablamos de las fusiones, compras y demás situaciones empresariales que no siempre han salido como se esperaba.
Este programa llega a ti gracias a https://www.ford.es/
Hola
En Spotify no me aparece el capitulo ¿Es normal ?
A mi me sale sin problema, aunque no en primera posición porque ha salido un nuevo episodio de la actualidad semanal posteriormente.
Ps: pueden ver que en casa se escucha lo que manda la peque de 1 año y poco.
Nos ha contraprogamado @arturop , ciertamente 
En relación a lo que comenta Arturo en el podcast de que al hacer una búsqueda no dice las fuentes siempre se le puede preguntar cuáles son y desde ahí indagar
Ahora si lo veo, desde que veo que sale el capitulo en Youtube hasta que sale en Spotify pasan horas o quizá 1 día
A lo mejor es normal y soy un “cagaprisas” 
Un saludo
Excelente podcast, como siempre.
Me gustaría compartir mi opinión como ingeniero informático y, sobre todo, como programador de sistemas de bajo nivel, respecto al tema de la programación y la inteligencia artificial. Creo que es fundamental entender el contexto actual del mundo del software y, más específicamente, de la programación: de dónde venimos y cómo ha cambiado el paradigma.
Lo primero que hay que decir es que, con el paso de los años, el concepto de “programador” se ha degradado enormemente. Saber hacer llamadas a una API usando un lenguaje de programación no convierte a alguien en programador, del mismo modo que saber unir dos piezas de PVC no convierte a nadie en fontanero. Programar es solo una herramienta para resolver problemas, y llevamos más de 15 años en una industria centrada en resolver problemas de muy bajo valor añadido.
Hablo desde la experiencia de haber trabajado en banca, consultoría y, más recientemente, en la industria del videojuego, donde actualmente lidero un equipo de 10 personas. He participado en proyectos tanto grandes como pequeños; he contratado, despedido y, a día de hoy, sigo realizando entrevistas de forma habitual. La realidad es que el nivel de programación e ingeniería de software ha descendido drásticamente con los años. Los lenguajes de alto nivel, junto con la idea de que se puede desarrollar software sin tener en cuenta el hardware, nos han llevado a una situación en la que se necesitan muchísimos programadores para tareas muy básicas.
Es bien sabido en la industria que hay personas que, literalmente, trabajan unas pocas horas a la semana y son capaces de completar todas sus tareas en empresas enormes como Google, Apple o Facebook. El impacto por programador es bajísimo en la mayoría de compañías.
Recuerdo, por ejemplo, que en 2014, recién salido de la universidad, hice una entrevista con Facebook en la que me dijeron que tenían 550 programadores trabajando exclusivamente en su aplicación de iOS. Otras tecnologías también han seguido esa dirección: miles de dependencias, equipos gigantes y, al final, un impacto individual que en algunos casos puede llegar a ser incluso negativo. Si quieren reírse un poco, busquen vídeos de “mi día a día trabajando en una big tech”, porque realmente te hacen replantearte muchas cosas.
En este contexto, donde programar se había reducido a entender un lenguaje y conectar cajas negras, cualquier persona que hiciera un bootcamp de unos meses podía alcanzar sueldos muy competitivos. Esto, por supuesto, también fomentó la externalización masiva, por razones puramente económicas.
Si haces entrevistas técnicas y preguntas conceptos básicos de computación, es deprimente ver el nivel general. De ahí el surgimiento de un fuerte movimiento en redes que intenta cambiar la manera en la que se hace software, promoviendo el trabajo en capas más cercanas al hardware, con equipos más pequeños y mayor impacto individual.
Este modelo de capas sobre capas, conectando APIs unas con otras, se ha intensificado durante la última década. Y para este tipo de tareas, una IA combinada con un ingeniero que realmente sepa lo que hace puede sustituir a varios programadores que se limitan a actualizar un par de Jiras por semana y cobrar un pastizal.
En este contexto, a nivel individual, le diría a cualquier estudiante de ingeniería que, por supuesto, se acerque a las nuevas tecnologías, pero solo si entiende primero los fundamentos. El cuello de botella en esta industria nunca ha estado en escribir código, sino en resolver problemas de forma eficiente y adecuada.
Y, desde el punto de vista financiero, no es lo mismo trabajar en problemas de bajo valor añadido que en otros de alto valor. Hay muchas razones por las cuales un ingeniero de rendering cobra más que uno de frontend web.
Por eso, no creo que la IA vaya a cambiar el paradigma de forma radical, sino que va a desinflar la enorme burbuja que se había generado en esta industria: poco valor añadido, trabajo deficiente, equipos sobredimensionados, exceso de capas intermedias y una preocupante falta de conocimiento técnico. A un programador de verdad —uno de esos 10x engineers de los que tanto se habla—, darle una herramienta de IA siempre le será útil. En cambio, para quien no sabía resolver problemas desde el principio, la IA no marca ninguna diferencia real.
Como añadido, les comparto este estudio en el que se demuestra que el uso de IA hacía un 20 % más lentos a los desarrolladores, aunque ellos creían que iban más rápido:
https://fortune.com/2025/07/20/ai-hampers-productivity-software-developers-productivity-study
Low code y ese tipo de cosas habrá influido y pinta que con la IA va a ir a más, viendo lo que las propias plataformas de desarrollo están metiendo dentro.
Esto lo comenté hace un tiempo en el hilo de True Value y la famosa Nagarro.
Es algo lógico si uno piensa en el impacto que el procesamiento en Cloud ha tenido en el mundo empresarial. Es una batalla que considero bastante perdida, pero es muy difícil programar considerando el hardware si no se sabe nada del hardware porque es un negocio externo bastante opaco.
90+ Cloud Computing Statistics: A 2025 Market Snapshot
Me gustaría saber su definición de “problemas de bajo valor añadido”. Porque el éxito del LowCode o NoCode actual es que son capaces de ofrecer soluciones decentes a lo que ellos consideran sus problemas más apremiantes.
Tengo pendiente escuchar el podcast así que no puedo comentar nada más.
En nuestro caso, el conocimiento del hardware es necesario porque estamos hablando de videojuegos, que tienen que capturar el input del jugador, simular y renderizar un frame en 16.6 ms. Pero, en general, cualquier pieza de software optimizada te ofrece ventajas competitivas, aunque no sea aparente.
A mí me parece, por ejemplo, que una de las razones por las cuales Apple ha ganado la carrera de los smartphones es, sobre todo, gracias a la optimización de software. Esto les permite vender teléfonos menos potentes, pero ofrecer una experiencia que, para el cliente, se percibe como superior frente a otras alternativas.
En el caso de la nube, creo que, una vez tienes toda tu infraestructura montada en AWS, Azure o la que sea, es muy difícil salirse. Y ahí está su mayor ventaja competitiva. Luego te cobran hasta por pestañear, y cuando dejen de crecer, veremos qué ocurre con esas facturas. Hace poco salió, por ejemplo, que el 12 % de todo el revenue de Figma se iba en la factura de AWS.
En cuanto a problemas de valor añadido, llevándolo a un ejemplo mencionado en el podcast, como es Pixar, podemos tener a un pedazo de ingeniero como Íñigo Quílez —a quien les recomiendo revisar en YouTube si les gustan las matemáticas—, que trabajó en la compañía generando césped procedural mediante ecuaciones para películas como Brave o Coco. Este tipo de problema genera muchísimo más valor añadido que cuando yo trabajaba para bancos holandeses y me pedían añadir una funcionalidad en la app para poder calcular cuánto tocaba pagar por cabeza en la cuenta de un restaurante.
Ambos requerían de un ingeniero para poder implementarse, pero uno claramente demanda conocimiento de dominio y estar al día con el estado del arte de su industria, mientras que el otro puede resolverlo cualquier persona que sepa programar.
Muchas gracias por la respuesta, tenemos la misma preocupación sobre la nube. Discrepamos en la definición de valor añadido.
De hecho en este ejemplo, siendo canónico, la utilidad que se gana por tener un césped del copón puede ser cuestionable. Pero la tonta operación para dividir la cuenta puede hacer que un camarero atienda a X mesas más por hora, añadiendo utilidad a cada transacción. Similar al caso del inventor de la fregona, añadir un palo fue bastante tonto, pero aportó mucho valor.
Todo depende del contexto claro.
Tiene razón que sin explicar el contexto mi ejemplo no está bien formulado.
En el caso del césped procedural una de las mayores ventajas es que al ser auto generado en la película, no es necesario que artistas o animadores tengan que hacerlo a mano ahorrando tiempo y muchos puestos de trabajo. También el hacer de esta manera el césped te permite que sea físicamente correcto en cuanto a su reacción al viento que si lo hiciese un humano frame a frame, no tener que gestionar manualmente la colisión con otros elementos de la escena, etc. Ahí creo que se entiende mejor la ventaja competitiva que te da tener a un ingeniero como Iñigo y la solución que el mismo ofreció a Pixar para la película.
En el caso del banco, literalmente era una opción en la app del banco para particulares, lo que luego se vio que no tenia mucho sentido pues el usuario al coger el movil podia abrir la calculadora directamente y en ya muchos establecimientos por aquel entonces en el ticket te ponía el precio por comensal. Sin embargo se nos fue fácilmente 3 semanas de trabajo en implementarlo y no llegaba a un uso de 0.0001% en nuestros usuarios diarios.
Mi objetivo era explicar que una tarea como la de Pixar requiere de un ingeniero que sea capaz de resolver problemas permitiendo a artistas y animadores centrarse en hacer la película mejor y la del banco simplemente era resolver una cosa que nuestros clientes ni pedían ni aun teniéndola disponible usaban.
La industria del software muchas veces resuelve más de las segundas que de las primeras.
No puedo resistirme a comentar sobre el libro del que habla @arturop en el podcast, Solenoide. Les recomiendo, además de ese (y de otros varios) el último libro del autor: Theodoros. Es La Iliada de nuestro tiempo.
Cartarescu es, quizás, el mejor escritor que haya leído nunca. Rebosa literatura, estética, gramática, imaginación, lírica… es un titán, un coloso descomunal. Es el ejemplo, y pocos quedan, de los que mantienen la literatura en su estatus de puro arte. El eterno candidato a premio Nobel, que espero no gane, pues siempre hay algo de mística en que un escritor de semejante calibre quede al margen del establishment, pintado con trazos de genio inadaptado.
Y me voy que me pongo intensito y el podcast merece la pena por muchas otras cosas.
Gracias a los tres por su tiempo y sus reflexiones.
La verdad es que llevando a término la obsesión con los insectos del autor en esta obra, me tiene como mosquito que va a la luz una atracción (fatal, aprovechando que mi Sra. no me lee) sin saber muy bien si es una trampa lumínica como algún exterminador de insectos y sin entender muy bien por qué lo hago. Ahí queda eso.
Igual digo una tontería pero el Low Code va a dejar de tener sentido si no ha dejado de tener sentido ya. Más allá de mantener ciertos artilugios y arcos de iglesia que se han hecho a medida durante tantos años.
100% de acuerdo. Ahora mismo veo más robusto un sistema “de Orquestación” mantenido por herramientas de software IA (cuyas alucinaciones tienden a nada a poco que pagues algo por ellas), que el tener una solución de producto. Que no me oigan decir esto desde SAP…
Lo único real que sé, en mi caso, es que he sustituido (si es que alguna vez hubo…) al departamento de Marketing, Calidad y documentación en menos de 3 meses. Tengo que decir que a mi ese trabajo no me gusta nada pero, con la IA haciendo todo y con esta calidad, me está resultando hasta divertido.
Esa ha sido, justamente, la razón por la que existe en empresas usuarias de ERPs el 99% de programación a medida que se ha generado. Siempre ha sido porque nadie ha comprendido de forma contextual el reto o problema consultivo real de como solucionarlo, y se ha ofrecido lo que no se pedía o muchas veces “un imposible sin sentido”. Porque la programación sin control, lo permite todo.
En casi 30 años de profesión en SAP, no había visto algo tan sumamente disruptivo. En el caso de la programación de “sumas y restas”, porque SAP no hace, renderizados ni dibujos ni historias de programación muy de nivel, simplemente organiza información de DEBE Y HABER por todas las transacciones.
Y todo el sistema de desarrollo que gira alrededor de procesos parecidos, se hace prácticamente al 99%. Y enfrentando IAs, se pueden hacer hasta controles de calidad que antes ni se hacían ni se soñaban.
Para no hablar de que en la parte consultiva, hasta el Stream de Googe Ai Studio, te dice lo que tienes que hacer sobre la propia pantalla.
En fin… palomitas 
