El Futuro del Sector Tech: IA enterprise-ready, Los Robots tienen CONSCIENCIA y LLMs

Para mí esto es como otra revolución industrial, con una diferencia que la velocidad a la que está ocurriendo es vertiginosa.

¿Cómo veis el sector tech en el futuro? ¿Dónde vamos?

Lo que es nuevo ahora será viejo dentro de dos meses, y dentro de dos meses habrá cosas que hoy a lo mejor no somos capaces de entender. Yo veo un montón de mi, eh, gente con miedo.

¿Pero miedo a qué?

Miedo a este que no hay claridad qué va a pasar mañana y qué es expectativa de cada persona.

El, el escenario de hoy no es el escenario de hace quince años. En absoluto, no se parece en nada.

Vámonos a Cursor. ¿Cómo se escribe código en junio de 2025? Desde que aparece la IA y vamos viendo que van apareciendo posts, ChatGPT, todo, ta, ta. ¿Cuán-cuándo dices: «Esto lo llevamos a producción»?

Y el futuro va a seguir. El futuro es o encuentras un factor diferenciador o ingeniero, ya hay máquinas que hacen el trabajo por ti. El modelo de IA Claude Opus cuatro de Anthropic intentó chantajear a ingenieros amenazando con revelar una aventura extramatrimonial para evitar ser reemplazado en el ochenta y cuatro por ciento de las pruebas realizadas.

¿Y crees que es un paso previo a la autoconciencia?

Sí.

El ejercicio que han hecho los chinos con los robots haciendo kickboxing.

Pues imagínate que tenga este modelo y no se quiera apagar.

Bienvenidos a una nueva tertulia de Itnig. Hoy estoy con nuestros techies de Factorial, eh, directores de ingeniería, CTO, VP Engineering. Todos vosotros lleváis a muchos ingenieros en Factorial. Estáis todo el día planteándoos los grandes retos que tiene una empresa que, que aspira a construir producto o productos en paralelo y escalar los equipos de ingeniería, ¿vale?

Entonces, bueno, hoy me gustaría debatir un poco de los, de los grandes dilemas que estamos afrontando en el momento. Eh, en Factorial estamos incorporando, estamos haciendo un giro bastante bestia, cambio de paradigma, em, y estamos implantando todos nuestros procesos, todos nuestros productos encima de AI, ¿no?

Encima de un-una nueva forma de interactuar con la aplicación que no es HTML o no es solo HTML, que no es mobile. Es otro paradigma. Miguel, ¿cómo es esto? De fácil o difícil. Cambiar una organización de ciento setenta, si no recuerdo mal, ingenieros.

Por ahí.

Yo estoy siempre diciendo doscientos y esta.

Tú estás diciendo doscientos, sí.

Estamos redondeando. Em, a ver, el tema es que esto es un cambio cultural, ¿no? O sea, yo lo comento muchas veces. Para mí esto es como otra revolución industrial con una diferencia que, o sea, ve-- la velocidad a la que está ocurriendo es vertiginosa, ¿no? Si lo comparamos en el mundo tecnológico con otras tendencias del mercado, como pudo ser el big data, microservicios, etc.

Para mí la gran diferencia es: la adopción de esas tecnologías fue mucho relacionada con el marketing, ha fallado muchas veces, eh, empresas enterprise. Pero digamos que la afectación, el impacto, no era tan grande, ¿no? El... Pero ahora con la IA, el tema es que, o sea, la IA está afectando tanto a la interacción con el usuario como la propia organización de los equipos a una velocidad flipante.

Entonces, hay una parte que está relacionada con la efectividad, ¿no? De lo que era un equipo de alto rendimiento veloz hace dos años, es que ya no es suficiente. El mundo va a otra velocidad. Y después eso está relacionado con un se-con un segundo punto, y es lo que hace todo más complicado, que es el cambio de la experiencia de usuario, ¿no? O sea, ahora ya no vale con solventar un problema rápido.

Tienes que crear una experiencia, ¿no? O sea, memorable, porque, o sea, ahí es donde está el diferencial. Ya no solo hay que ser rápido, solventando un problema que nadie ha solventado, porque es que cualquiera lo construye, no es problema de construcción. Tienes que ser igual que rápido que el, que el resto y además ese superdiferencial, ¿no? Y bueno, eso es un reto, un reto importante.

¿Cómo, cómo es este proceso de cambiar eso? ¿Cómo se cambia la mentalidad de nuestros ingenieros de un día para otro? O sea, cualquiera, ¿eh? O sea, intervenid.

Pues es difícil. Es difícil porque es muy nuevo. Y lo que es nuevo ahora será viejo dentro de dos meses. Y dentro de dos meses habrá cosas que hoy a lo mejor no somos capaces de entender. Entonces, es un proceso continuo. Al final, nosotros tenemos que alimentar la curiosidad. Yo creo que por definición un ingeniero es una persona curiosa, una persona con hambre. Y lo que buscamos son evidentemente ingenieros que tengan ese hambre continuo aprendizaje, continuas ganas de descubrir lo nuevo.

Ah, es la única forma. Uno no puede inyectar eso empujando. Eh, tiene que venir de serie, tiene que traerlo.

Hostia, pero esto, joder, o sea, esperar a que sea la gente que orgánicamente haga cosas, ¿esto es, esto funciona?

No.

Esto, esto funciona en Factorial.

No siempre, no siempre. No debería ser así.

No tanto, no tanto como, como yo quiero personalmente. Y también que yo hemos vivido estos algunas olas de cambios de con mobile, como tú estás diciendo con big data, con no sé qué, y siempre estaba mucho más lento que yo veo ahora, porque ahora cambio no solo tecnología, también cambio experiencia de usuario, que cada de nosotros esperamos de productos como, ah, como trabajamos, hablamos, de no sé qué hacemos cada día.

Y hay ca-- estos cambios. Por eso es este periodo de incertidumbre y de un montón de expectativa que yo voy a experimentar mucho y probar cosas y cosas que antes pensaba que no es posible, ahora es posible.

Esa es la clave, es que lo que antes no era posible, ahora esto es.

Exacto. Y yo veo un montón de mi, eh, gente con miedo. Es que no hay, hay cosas que son tantos nuevos...

¿Pero miedo a qué?

Miedo a este que no hay claridad qué va a pasar mañana y qué es expectativa de cada persona. Es porque gente a veces me preguntando: ¿Hay un curso? ¿Hay un libro de AI que yo puedo ahora leer y ver?

Como tener una formación de alguien.

Exacto. Sí, sí, sí. Es como: explícame en tres o cuatro palabras muy, muy claves qué, qué esperas de mí. Y yo espero que tú juegas, que tú ex-- haces este experimento, que tú me traes una idea, cómo podemos usar esto, algo nuevo. Y yo veo a veces gente congelado.

Es que eso es realmente la definición del cambio, del cambio real, ¿no? O sea, cuando la gente tiene miedo, cuando hay un cambio drástico en las organizaciones, cuando hay un cambio de modelo, porque ahora el crecimiento a nivel de revenue ya no está asociado ni al número de equipo, ¿no? O sea, o sea, hay empresas que con diez developers están creciendo, pues de una forma alucinante, ¿no?

Lovable... Bueno, hay muchos ejemplos, ¿no? En el fondo, s-- nosotros, eh, que siempre lo he notado porque somos un gremio, siempre hemos considerado que somos diferentes, ¿no? Es lo mismo que consideran los médicos, l-los científicos, da igual. Pero para mí no deja de ser-

¿Nosotros quiénes somos?

Los ingenieros, el sec-

Ingenieros

...el sector tech, ¿no? Pero todo cambio, para mí, desde mi punto de vista, siempre empieza, eh, o sea, cambios, eh, con éxito, ¿no? Empiezan por un primer punto, que es que desde la, desde la primera capa de liderazgo, que en caso de Factorial, eh, son los fundadores, ¿no? Eh, y los CEOs, porque son pues tú, Bernat que está aquí, Jordi, y después es uno en el, en la parte de ingeniería, Ilya.

Es esa determinación, esa única voz, esa dirección de hacia dónde tenemos que ir, pero inquebrantable. O sea, igual que Bezos en su día dijo: Oye, en esa famosa transformación digital de todo va a ser por una, por una API, eh, pues lo mismo necesitamos de Factorial. Y eso ha pasado, ¿no? Y ese es el comienzo de todo.

La siguiente capa para mí es estar alineados la siguiente-- el siguiente nivel de, de liderazgo, porque si en el resto, aunque podamos discrepar en alguna-- en algún punto, no, no seguimos empujando, al final cualquiera de nosotros nos buscamos, nos convertimos en un blocker, ¿no? Y ya lo siguiente son lo-- el resto de líderes, que no solo son managers, también son ingenieros, ¿eh?

Son ingenieros, el, el star, que la gente se, se ve reflejada en ellos. Y para mí todo empieza ahí. Y después de ahí podemos empezar en si la formación, si, si este, eh, learning by leading, by doing, todo este tipo de cosas, pero...

Pero y cuando la gente dice: «No sé», tiene este miedo y no, no sabe por dónde empezar, ¿tú qué les dices, Miguel? ¿Por dónde empiezan?

Lo primero es-- yo siempre transmito esa confianza que vamos a llegar a objetivos. Y-- porque la gente cuando tiene incertidumbre necesita seguridad. Y ahora es eso, tienen incertidumbre, tienen miedo porque no conoce. Entonces, lo primero es la seguridad de saber que vamos a alcanzar esos objetivos. Lo segundo son unas guías, ¿no? Pues, eh, cosas simples, porque al final lo importante son los ejemplos, ¿no?

¿Qué hemos visto en los últimos meses? Pues, por ejemplo, los típicos, eh, cambios de, de refactoring de legacy, ¿no? Venía un equipo en el que, oye, pues a términos de seguridad tenemos que cambiar, eh, pues estos scopes que tenemos en el código. Hacemos una estimación, iniciamos un quarter, ¿no? Modelo hace dos años, iniciamos un quarter para aplicar ese refactoring en, en código, ¿no?

O sea, determinación de esta cuando hemos decidido que queremos ir por esta, eh, adoptarla a ella es: «Oye, chicos, este ya no es el camino, este era el camino de hace dos años, el de ahora es automatizar esto, ¿no? ¿Cómo lo vamos a automatizar? ¿Qué ayuda necesitáis?» Y después llegan las sorpresas. Esta misma gente, dos días después, dos semanas después, piden una propuesta automatizando, utilizando herramientas de IA.

Y oye, lo que eran tres meses, son dos horas. Oye, entonces, ahí empieza la rueda, porque empieza el ejemplo.

Imagino que cada uno de los equipos, nosotros cuántos equipos tenemos? Veinti...

Treinta. Como doscientos treinta.

Sobre los treinta. Eh, cada uno de los treinta equipos no puede, mmm, coger un LLM y empezar a hacer queries y escribir su, su producto sobre el LLM que quiera, ¿no? Entiendo que estamos, de alguna forma, bueno, yo lo pregunto y ya sé la respuesta.

Sí.

Ilya, por favor.

Por favor, explícanoslo.

Confírmalo, por favor.

Explícanos cómo estamos haciendo para que todo el mundo trabaje más o menos de una misma manera, una manera más o menos homogénea.

Mira, y aquí es muy complicado responder en u-- o, o solo única manera, porque hay tantos capas. Hay una capa como desplegamos, por ejemplo, IA en producción como parte de producto de Factorial. E-es una decisión que ha-estamos, que estamos-- hemos tomado hace, hace un mes y ahora es muy obvio que un montón de equipos empiezan como a hacer sprinkles en el producto, añadir cosas de IA.

Y después hemos hecho una revisión y vemos que hay cinco, seis, siete man-maneras como hacer esto y decidimos que no, tenemos que parar, tenemos que hacer una unificación, tenemos que crear una capa de IA que se, aaah, que, que podemos tener una en, en Factorial, con observabilidad, con guardrails, con todo esto.

¿Qué es? Explica todo.

Exacto.

¿Qué es una capa de IA? Lo primero de todo, ¿no?

Exacto. Intentando, intentando. Es muy complicado. Pero sí, al, al final olvidamos que IA es algo, es algo mágico. Es, eh, como una, ah, manera como hacer una ingeniería buena, que siempre tú, si tú llamas otro, otro servicio que no-- que tú no controlas, tú creas un adapter, un adaptador, que después tú puedes ver, aaah, failure rate, tú puedes ver, ah, nivel de carga, tú puedes ver al-algunas cosas, poner observabilidad.

IA es lo mismo aquí. Es como es otra API que tú tienes que llamar. Y, pero también es con un montón de ex-- cosas nuevas. Por ejemplo, otras a nivel de seguridad. Hay algo nuevo que es muy popular y ahora GitHub está, está pagando es-este price, eh, de, de prompt injection, que gente puede escribir pensando que hay el LLM por detrás y haciendo overload de todos los-- esas instrucciones.

No sé cómo en castellano estas palabras, pero...

En, en un chatbot de una tienda de, de coches, me recuerdo, no, no recuerdo exactamente de qué es, pero consiguieron que el chatbot, que podía vender, vendiera un vehículo a cero euros o cero dólares haciendo prompt injection. Es decir, al final, como hay una especie de caja negra detrás, eh, con ingeniería y dale vueltas, puedes llegar a obtener el resultado que quieres. Y esta, esta capa tenemos que cubrirla, no podemos ir a-

Exacto

...a chorrón.

O mostrar datos que no deberían que mostrar y otras cosas. Por eso es como, sí, ah, es, es muy bien que equipos está experimentando, pero ellos tienen que experimentar en, como en un caja que está segura y que podemos que-- asegurar que no debería que pasar cosas, que vamos a perder datos o que vamos que-- mostrar cosas, datos de Factorial a otros usuarios que no deberían que ver algo.

Por eso, nuestra manera es primero es unificar, unificar todo esto y asegurar que hay guardrails muy bien puestos a nivel de LLMs. Y de-- después que cada equipo tiene, ah, ejemplos cómo usar esto y cómo des-desplegar esto en, en nuestro entorno. Es una primera cosa. Otra cosa es todo a nivel de, ah, de productividad de cada persona.

Es cómo tú haces refactorings, cómo tú estás desarrollando cada día, cómo tú, ah, tú multiplica-multiplicas a tú mismo en desarrollos con, con IA ahora

Pero eso es ya a nivel de herramienta para, para escribir código

Sí, pero también es como todo el mundo está pensando en: vale, vamos a comprar curso y ya está. Es como todo el mundo ahora dice que es más rápido. No. Es otra manera como tú aprendes a usar esta herramienta, porque es una herramienta totalmente nueva. Yo, por ejemplo, cuando desarrollo ahora, yo casi no toco código, yo estoy tocando código di-- ya sé que es mmmenos que antes, porque, ah, yo ahora pensando con el LM, yo haciendo ping pong, que mira, es como es una, es una partner muy potente que ayuda a mí a pensar sobre pro-

Ahora, antes de ir a cómo escribimos código, eh, a día de hoy, estoy todavía pensando en cómo es esta capa de AI, ¿no? Has hablado de guardrails, que entiendo que, que es una especie de establecer límites a lo que puede hacer esta caja negra indeterminística que es el AI. Entiendo que se puede establecer límites.

Sí.

Eh, observabilidad, seguridad.

Sí.

¿No? Eh, todo esto-

Y una manera unificada en cómo llamar esto, sí, sí.

Y esto que es un, una especie de middleware, una, es una tecnología que hemos puesto en Factorial, eh, y que todo el mundo está trabajando encima.

Exacto. Es como al final, es nuestra manera es que, ah, cuál es el futuro, que cada eI-- parte AI d-del producto es en realidad es un agent. Es una-- uno. Imaginamos una persona que tú puedes llamar y preguntar que: necesito que tú me subas un expense report, o que tú me preparas una analítica, o tú me, ah, creas una...

Bu-buscas o creas un survey o buscas una persona en ETS. Es algo que persona es un profesional haciendo solo esto. Y, y que yo veo que cada equipo está pensando y creando estos profesionales, que, que son-- están enfocados, están muy validados y tienen set de herramientas que después estos agents pueden llamar. Y hay una abstracción que se llama, he, he visto como un término que mucha gente está usando, es netw-network, agent network, que es un observador de todos los agents que pueden después hacer esto routing, que mira, me parece que, que usuario necesita que, que llamamos, ah, que subimos un expense report.

Voy a llamar a agent, que está subiendo expense report. Ahora voy a coger este output de, de agent que están subiendo expense report, voy a pasar a agent de analítica para hacer o-otra analítica. ¿Y qué está haciendo? Esto es routing. Y en nuestro caso, estamos creando exactamente esto, que para un developer en Factorial, ah, vamos a tener una manera como es muy fácil y co-- en cinco minutos crear este agent vertical enfocado en un use case, que después automáticamente va a pasar en este network.

Si... Y al final, como usuario de Factorial, yo puedo escribir que sube mi expense report, después, ah, há-haceme una analítica de todos los mis gastos de este, de este, de este mes. Y yo no sé qué está pasando detrás, pero detrás hay tres o cuatro agents cooperando, pasando datos a, a cada uno y, y parándome, pasándome a un response.

Porque al final es... Hoy también hablaba con alguien del equipo, con Oriol y, y Nacho. Estamos empezando a aplicar, ¿no? Porque ya está, está un poco más maduro, ¿no? Ya es-está dentro del ciclo de desarrollo de los equipos. Y entonces, estamos empezando a aplicar sobre estos modelos los mismos patrones de arquitectura que venimos aplicando sobre el desarrollo de software.

Totalmente.

Pues si la orquestación, la coreografía, las múltiples capas, cada una de las capas como agentes especializados para hacer la parte de seguridad, la parte de verificar el task, eh, tolerance, o sea, claro, es que...

Pero dentro hay una caja negra que no controlamos.

Y que no es determinística.

Y que no es determinística. Y eso, eso genera cierta también...

En la parte de solidaridad está todo el tema de la validación de los resultados con este famoso golden data, que también estamos trabajando dentro de este framework también de, de, de Factorial, que al final lo que nos ayuda es igual que con los modelos tradicionales, ¿no? Sacamos un score y en la parte de desarrollo, testing, MCID, validamos que las nuevas evoluciones que metemos de los modelos cumplen con, con los requisitos que hemos especificado.

Si el score supera nuestro requisito mínimo, al final es un modelo de calidad, entonces es un modelo que podemos pasar a producción. Si no lo supera, pues...

Bueno, y aparte de eso, estás cubriendo ese modelo con routing para saber a-hacia dónde dirigirte, si vas a un agente o a otro, y luego una capa de protección que te asegura de que lo, lo que va a entregar te pasa, que, que cubre... Es decir, al final estás rodeando como una arquitectura de cebolla, en definitiva.

Y cada vez hay más e-evaluadores de esto, ¿no? O sea, hoy estábamos hablando precisamente con, bueno, Mastra o Aisu, pues los evaluadores que verifican que el resultado es completo, que el flujo, el workflow sigue los pasos que están definidos.

Sí.

Eh, que no estamos, que el contenido que, que estamos dando es un conidi-- un contenido válido, que no hay palabras que no permitimos. Pues que...

O sea, puede haber un agente específicamente destinado a asegurarse de que el contenido que se va a exponer cumple con la va-- palabras, que no se dicen pala-- solo dedicado a esto. Podría hacer perfectamente eso.

Vale, ¿y qué pasa con el resto del producto? O sea, nosotros tenemos un producto a día de hoy que está basado en web, que, que, que, pues que te da una interfaz en HTML, que se carga en el browser y que te enseña una serie de cosas, y tú navegas, haces workflows, wizards, tablas. ¿Qué pasa con esta parte del producto? ¿Desaparece?

Sí o no, depende. Es decir, lo que, lo que estamos abordando ahora mismo es lo que llamamos la cocri, eh, cocreación. Es decir, gracias a la conversación podemos interactuar, eh, directamente con la interfaz. Entonces, por-- te pongo un ejemplo, podemos, eh, a través de una conversación, crear una survey. Es decir, yo puedo tener una-

Una encuesta.

Una encuesta. Yo puedo tener una, una conversación con un...

Formulario.

Correcto, y me genera un formulario y puedo decirle-

En vez de escribir cuáles son las preguntas, las secciones...

Eso es.

Eh, ¿no? Las posibles respuestas, las validaciones, to-- en vez de, de hacer todo esta configuración de, diríamos un type form, que en Factorial tenemos un producto equivalente.

Sí.

Pues en vez de hacer esto, tú le explicas a una especie de UI tipo ChatGPT: oye, hazme una, un formulario, pregúntame ese tipo de preguntas o sugiéreme preguntas.

Sugiéreme preguntas o tradúcelas al ruso. O ahora cámbiame la segunda pregunta y no quiero que sea mandatory, que no sea obligatoria, que sea una pregunta no obligatoria y que sea con cuatro opciones en lugar de con tres. Ah, eso lo puedes hacer, eh, con una interfaz de chat y eso automáticamente tiene un fiel reflejo en la interfaz. Eso es lo-

Con lo cual existen las dos versiones. Existe una versión agéntica.

Correcto.

Y una versión producto de toda la vida.

Interfaz de toda la vida builder, por decirlo de alguna manera, sí.

En algunos casos pasa que solo tiene sentido la versión convers-conversacional. En algunas partes del producto

A día de hoy, eh, es que podríamos filosofar mucho aquí, ¿eh? Es decir, yo creo-

Dispara, dispara

... yo creo que-

Tenemos aquí tortilla.

Sí, sí, lo podemos-- lleva cebolla, por cierto.

Lleva cebolla. Es un tema que hemos empezado a discutir antes de, de grabar, luego iremos.

¿Sabes qué pasa? Eh, y aquí a lo mejor me estoy poniendo filósofo de más, pero el, el escenario de hoy no es el escenario de hace, eh, quince años, en absoluto, no se parece en nada. Y hace quince años se definieron productos con el contexto que se tenía hace quince años, que hoy se hubieran definido de otra manera. Te pongo un ejemplo, una performance review. ¿Cuándo, cómo?

Una evaluación de desempeño.

Una evaluación de desempeño, cuándo, cómo y por qué se crea una evaluación de desempeño. Uno, porque necesitas saber cómo está tu gente, porque quieres desarrollarlos. Y la única forma que había en el momento en el que se concibió ese producto era preguntar. ¿Es hoy la única forma? No. Entonces, si, si, si construyeras hoy-

Uy, aquí tendremos debate.

Sí, seguramente sí.

Tendremos debate. Sí, porque no es un tema de preguntar, ¿qué significa preguntar? O sea, no es preguntar. Es, es el acto de reflexión. Es el hábito, es la disciplina del hábito de autoplanteamiento en un periodo de tiempo determinado y en dar feedback de una forma específica.

Te refieres a la, a la reflexión de la propia persona sobre sí mismo.

El concepto de una, de una evaluación de desempeño.

Mhm.

Es que eso es otra co-- otra cosa que veo con la AI, ¿eh? O sea, la gente está diciendo: "Ya no hace falta nada", porque ya está la AI, que está revi-- viéndote en tu día a día, está haciendo, está percibiendo todo lo que está pasando y está haciendo ya por ti la performance review.

No, no, yo no voy por aquí. Yo creo que el man in the loop tiene que existir, solo que se trata de potenciar. Es decir, a-antiguamente, insisto, es un ejemplo, eh, como otro, pero cuando se concibió el concepto de performance review, la única forma de hacerlo era hacer una survey cada seis meses o cada año. Hoy en día puedes obtener información de otras muchas fuentes. Eso no significa que automáticamente tome decisiones por ti.

No creo que la, la, el po-- la potencia de la inteligencia arti-artificial esté ahí. La potencia está en potenciarte, en darte suficiente información, en, en cubrirte de al-- alrededor de ti de un montón de información para que tomes las mejores decisiones. Entonces, hoy, si tú tuvieras que montar un concepto, si alguien viniera diciendo: "Tengo que montar el concepto de una performance review hoy, con este escenario", tengo claro que sería distinto a como se concibió hace quince años.

El contexto es totalmente distinto. Hay otras formas de obtener información, hay otras formas de dibujar el, el proceso, es totalmente distinto. Entonces, pienso que de aquí en adelante, y en un año probablemente todo cambie, muchas definiciones de algunos productos puedan ser radicalmente distintas a como las concebimos hoy. Entonces, ahí es donde veo que hace falta mucha visión, innovación, ah, y está todo por hacer.

¿Y los equipos tienen esta visión?

Yo creo que es-eso es algo que tenemos que-

Muy nuevo, ¿eh?

... que trabajar, ¿eh?, continuamente, porque, eh, son los puntos en los que tenemos esas divergencias, ¿no? Yo, por ejemplo, no creo que todo tenga que ser un chat conversacional. Eh, y hay cosas que no quiero preguntar. Quiero abrir mi aplicación de Factorial y quiero que esté el número ahí, está... o sea, ya el insight. O sea, hay cosas evidentes.

Es que no, porque no sabes lo que no sabes, ¿no? Tienes que descubrir la información.

Porque yo al final soy vago, ¿no? Y si puedo hacer algo en un clic, ¿por qué voy a escribir un texto, no? Es como cuando abro la aplicación del banco, que siempre pongo de ejemplo a los, a los equipos, ¿no? Yo abro la aplicación del banco, no quiero preguntarle por cuál es mi saldo actual.

Lo quiero ver instantáneamente.

Ver instantáneamente, ¿no? Entonces, lo que tenemos que buscar es precisamente esa experiencia que hace Factorial diferencial, ¿no? Eso es lo difícil.

Vámonos a Cursor y cómo escribir código hoy, ¿eh? Casi junio 2025. ¿Cómo se escribe código en junio 2025? O sea, ¿todo el mundo está utilizando Cursor ya? ¿Se puede hacer solo vibe coding?

Yo creo que sí.

¿Existe el vibe coding? ¿Se puede hacer una aplicación entera vibe coding? ¿Qué es vibe coding, primero de todo? Vibe coding entiendo que es-

Es hacer así.

Es básicamente, mmm, escribir código, como podría hacer esta persona que está pasando por la calle, ¿no? Eh, cualquier persona por la calle está escribiendo.

Pero no me gusta este té-

Y, y, y Cursor hace la aplicación por ellos.

Sí, pero al final, que... No me gusta ese término porque es muy gris. No entiendes qué significa, que yo estoy haciendo vibe coding y no revisando nada después qué está pasando y tengo resultado, o estoy solo usando Cursor o no sé qué. Porque para mí es como, a mí ahora me gusta diez equis como, eh, escribir código ahora que antes.

Yo también, ¿eh? Disfruto más.

Exacto, yo disfruto más ahora escribir código, pero no es sensación que yo estoy escribiendo manualmente.

Pues te sientes como un artesano, ¿no?

No, no, no, no, no.

Ah, vale.

No es precisamente. Es que ahora yo estoy enfocándome mucho más en cosas interesantes, de pensar de producto, de pensar de arquitectura, de pensar de edge cases y todo. Porque voy a repetir, como yo, mmm, gasto mucho más tiempo en Claude, en ChatGPT, solo hablar con el LM y revisar prompts, ah, PRDs, ah, o todos esos documentos de qué quiero construir.

Es muy, muy, enf-- estoy muy enfocado en, en esencia, en chicha, y mucho menos en cómo hacer conectar dos piezas o conectar tres APIs, o cómo hacer-

Es mucho más gratificante.

O poner, sí, o poner base de datos. Ah, es como al final esto va a ser el lema y yo voy a enfocarme en cosas muy, mucho más pesadas.

A ver, mmm, vosotros porque tenéis mucha orientación a negocio, eh, los tres que estáis aquí, estáis pensando en solucionar problemas. E imagino que hay ingenieros que realmente les gusta, eh, el cómo, ¿no? El cómo se escribe código, el arte de, el arte de escribir código para hacer una cosa determinada que alguien me ha dado.

Pero eso no se pierde, Bernat. Al final, es decir, el cómo sigue estando ahí. Aquí lo que creo que es-- es decir, no creo que vibe coding, si hacemos vibe coding y dejamos que todo lo que la AI produzca, le-- y lo publicamos, lo subimos a producción, sea inteligente. De hecho, creo que-

Hoy.

Hoy. Creo que sería hoy.

Hoy. Dentro de un año sale este pódcast y ya...

Dentro de un año hablamos. Hoy yo creo que no sería inteligente. De hecho, sería bastante kamikaze. Entonces, lo, lo que yo creo, por lo que yo creo que es esto gratificante es por el, el hecho de que, ah, lo que es la parte sucia, la parte pesada, eh, de repente escribir cómo conectarte con una API. Entonces, tienes que extraer, pues, eh, leer el payload, toda esta parte, que es algo que sabes cómo hacer

¿Se va más rápido?

¿Sí?

Tú sabes cómo es dar esto.

O sea, ahora en Factorial estamos yendo más rápido construyendo producto que hace seis meses.

Sí. Cosa que hay que diferenciar, ¿no? Cuando estás trabajando-

Me encanta.

Con un código que ya existe, a cuando empiezas de cero, ¿no? Un código que ya existe es más complejo. No hay-- a veces no hay documentación suficiente y al final no-

No, ya, pero es que esto, esto no hace falta-- o sea, escribir un código nuevo va rápido todo el mundo.

No, no.

Sí, también, también. Escribir código nuevo, el scaffolding de, de una aplicación, esto lo haces en un minuto.

Lo que antes harías en un mes, hoy lo haces en un día.

O sea, lo difícil siempre es el legacy. A ver, es que esto-- todo el mundo quiere ser el dos punto cero o el tres punto cero de sus aplicaciones porque nadie quiere afrontar el legacy.

Aquí tengo contraejemplo. Hoy, exactamente hoy, porque jugaba hoy con de, ah, con Codex, pero no Codex, es una herramienta de OpenAI que, que ellos han sacado hace, hace dos semanas, que tú en web ahora puedes crear un agente que puede conectar a GitHub y después te puede escribir que: "Mira, que, ah, arréglame esto o anádeme esto".

Es como un Devin que-- otro producto que, que había antes, pero todo el mundo ahora está creando estos agentes. Cursor está creando este agente o, o, ah, Claude, OpenAI. Y, eh, yo también pensaba que, mira, Factorial es tan grande, es tan legacy en este sentido, que el ADM no puede hacer nada, honestamente.

Pensaba yo este antes. Y hoy tirando una cosa que: "Mira, tenemos un componente que es muy lento para compañías grandes, podemos revisar qué está pasando interno". Más o menos, este es mi, era mi prompt. En cinco minutos he sacado un report de todos los cosas, he encontrado código que no estamos usando, em, creando a mí al final pull request limpiando cosas y todo funcionaba desde, desde el principio.

Sin setup.

Seguro, ¿eh?

Seguro, seguro.

Eso es una pieza constante concreta en el código-

Que es un poco como las mejoras estas en, en, en la parte de refactoring que-

Hemos hecho y que está superbién, ¿no? Pero, eh, o sea, si le tienes que decir al-- o sea, tienes que utilizar Codex o-

Cursor dentro de la aplicación de, de Factorial.

Y le dices que desarrolle una nueva funcionalidad, llega un momento, digo, que, en el que al no tener el contexto, no tiene la-

Empieza ahí en bucle y-- pero eso es hoy, porque yo me acuerdo de esta conversación de hace dos años.

Que me había llamado y me había dicho: "Oye, Miguel, ¿estás probando esto?" Y digo: "Sí". "Oye, ¿cuál es la ventaja, la mejora de productividad para tu equipo?"

Digo: "Oye, yo no he, no he visto más de un 10 %". Ahora, la pregunta que me hago es dentro de un año dónde vamos a estar. Porque tú me has dicho, lo que acabas de comentar, ¿no? Todavía está la parte de, la parte de arquitectura, la parte divertida. Es que dentro de un año a lo mejor ni esa parte ya es relevante. Vamos tan rápido, adquiere tanto conocimiento, que a, que yo-- o sea, ya me imagino un mundo, no-- y no un mundo dentro de diez años, ¿eh?

Un mundo en que tenemos estos agentes especializados, especializados en arquitectura, que te venden el servicio que te garanti-te garantiza esa seguridad, igual que nosotros estamos metiendo la capa de seguridad para no exponer datos, para no exponer palabras que no sean las adecuadas. Es que esto va a una velocidad increíble.

Vale.

Es que es el caso de uso donde parece más fácil, digamos, ¿no? Traducir-

Una aplicación con una lógica determinada y tal a otra tecnología.

Oye, ¿compartiste eso en el canal de ingeniería?

Volviendo a cómo hacemos el cambio cultural.

Así se hace un cambio cultural, ¿no? El CTO compartiendo en el canal de ingeniería cómo utilizamos una herramienta de AI para mejorar la productividad.

No, no, es que esto es brutal.

¿Qué significa lento?

¿Qué significa lento?

Le das el problema. Le das el código y le mandas el problema.

Oye, Ilia, ¿en qué momento tú pasaste de Grinch, no? Porque tú no, tú no eres tan Grinch. Grinch le dejamos más el rol a Miguel. Eh, de, de no believer, de no believer a, a creer de: "Oye, esto tenemos que hacer un cambio ya". ¿Qué pasó? ¿Qué, qué salió? ¿Qué viste?

Ah, fue el momento de la lavadora.

Ya va para libro.

No esperabas respuesta.

Ya va para libro. Arreglé mi lavadora.

En quitar esta, esta manera que no es determinístico y queremos tener un estado determinístico. Yo veo que ahora sí hay modelos que, que entiende todo. Hay multimodalidad, hay estabilidad de infraestructura.

Te dan más valor que un workflow determinístico.

Exacto, totalmente. Y también como-

Pero siempre hay un, un 1 % o un 10 % de los casos donde hace cosas raras.

Vale.

Se lía.

Con-- y código lo mismo. Tenemos bugs por eso, por eso-

Los humanos lo mismo.

Exacto.

Ya, pero un-

Al final-

...un proceso determinístico, eh, no te va, no te va a sorprender.

Me sorprende cada día.

Por eso tiene las diferentes capas que añadimos.

Exacto, ese es el punto.

Meter diferentes asuntos.

Exacto.

La idea es que haya validado.

Sí, ya no es las capability, o sea, las posibilidades que tiene propiamente el LLM, sino también los frameworks, ¿no? La tecnología que está, la infraestructura que está acompañando los LLMs-

Está usando Cursor ahora, como lo usábamos hace seis meses, que teníamos abierto la ventana. Le decíamos, eh, pues me acuerdo, el, el universal importer. Yo hice la POC usando Cursor, lo hice en dos días. Simplemente-

Espera, que utilizas, que utilizas muchos keywords, tío, de cosas que nuestro audiencia no... Universal importer es una tu-una funcionalidad dentro de Factorial.

Una tele automática, ¿no?

Una POC es una prueba de concepto.

Una prueba de concepto.

Ya no es como se usa ahora a día de hoy.

Subtítulos.

Ahora ya hay diferentes agentes dentro del Cursor, hay que-- le puedes meter reglas, ¿no? Y hay cosas que ya están por detrás debido a la validación.

¿Cuál fue tu momento? Tu momento de decir: «Esto va a funcionar».

De, de, o sea, por lo que hemos avanzado-

Esto lo podemos llevar a producción, esto va en serio.

Desde el primer momento. O sea, yo-

¿Hace dos años o hace...?

Hace dos años. Ah, dices-

No, no, cuando-- desde que aparece la IA. Íbamos viendo que van apareciendo cosas. ChatGPT, todo, ta, ta. ¿Cuán-cuándo dices: «Esto lo llevamos a producción»?

Pues tres meses después salió ChatGPT. De hecho, le compartí un artículo. Cuando Iria vino y nos compartió... Me acuerdo, vin-- viniste aquí una mañana y me dijiste: «Oye, Miguel, tengo esta idea, la vamos a compartir, estoy trabajando en el vídeo». Eh, le dije: «Hostia, pues que hace, hace dos años justo tengo un ejemplo que, eh, intentamos productizar, eh, sacamos una, una versión inicial beta con, con la misma aproximación».

Estaba mucho más verde porque no estaban los agentes a día de hoy. O sea, ya allí ya había el modelo de estandarizar componentes y hacer un nuevo

Mhm.

De hecho, ya teníamos para el sector retail, ¿no? Sacábamos meta charts en tiempo real, renderizábamos componentes, teníamos, o sea, basada una, una capa de API estandarizada en la que le dábamos esa pa-- capa semántica al-

Pero ¿con LLMs o con machine learning?

No, con LLMs. Con las primeras versiones de OpenAI.

¿Pero lo lanzasteis?

Lo lanzamos, lo lanzamos.

Pero no iba.

No, sí, pero en aquel momento, eh, pues ahí no se le vio el valor.

Dale.

O sea, que siempre has creído. Desde la primera versión de ChatGPT, tú has dicho: «Esto lo lla-lo lanzamos a producción».

Los tres meses, o sea, los, los tres primeros meses, sí.

Pero esto es un poco ingeniero. Es decir, sale algo nuevo, que es innovador y de hecho yo creo que-

No todos.

Es muy diferente, es muy diferente.

Ojalá, ¿eh? Yo-

Si tú ves Hacker News ahora, hay tantos comentarios negativos, que es un hype, esto va a pasar.

Ya, pero todo el mundo creo que el día que vio por primera vez ChatGPT o cuando vio la primera vez la, eh... ¿Cómo se llamaba la primera versión de imágenes que hice-- que hicieron?

Stable Diffusion.

Eh, antes de-- Stable Diffusion es el open source. Pero bueno, la primera vez que vimos un sillón con forma de aguacate o un astro-astronauta con un caballo.

Ah, DALL-E.

DALL-E, todo el mundo flipó. Es decir, eh, con, con ChatGPT también. Y ahora te pones a mirar cómo era ChatGPT dos punto cinco o el tres y lo miras ahora y la diferencia es abismal. Pero todo el mundo flipó. Entonces, que compramos, que compramos la realidad de lo que venía, yo creo que fue casi instantáneo.

¿Sabes lo que no sigo creyendo? Que no lo creía en aquel momento, porque la gente entra en hype y cree que las herramientas valen para todo en el momento que están. O sea, y aún lo sigo creyendo ahora. De hecho, hemos tenido este debate hace meses, eh, meses atrás, ¿no? Cuando estábamos hablando de la planning automática.

La qué, perdona.

La planning automática, ¿no? Dentro de-del...

Planificación

Del modelo de gestión de tiempo, la planificación automática. Eh, que un LLM no es capaz de hacer un forecast. O sea, una... O sea, forecast en castellano, a ver.

¿Cuál es la palabra forecast? Yo tampoco sé.

Bueno, un forecast precisamente es la que lo va a entender todo el mundo.

Pues un forecast a fut-a futuro, un forecast complejo con una serie de indicadores, mucha cantidad de datos, ya por la limitación de tokens, no está preparado para eso. No es, no es un modelo orientado para eso. Bueno, hoy lo que permite es que-- pues de nuevo agente, que llame al modelo concreto y tú interactúas con, con el agente, ¿no?

Pero-

Pues ese caso de uso es bastante complejo, ¿eh? Yo estuve, estuve revisándolo con, con Ángel, con una persona de-del equipo y tiene un montón de aristas. Es verdad que se hace muy grande.

Cuando salió, la gente le enviaba una tabla, porque ellos también lo dicen, ¿eh? Lo puedes hacer, le envías una tabla con movimientos de stock y entonces él te dice dónde están las anomalías, pero es un subconjunto pequeño de datos.

Claro. Yo tengo una pregunta al final, si hablamos tanto de, de desarrollo: ¿cómo contratar desarrolladores ahora?

Mira, iba a hacer la misma pregunta. Fantástico.

A la int.

Venga.

Yo tengo una opinión y es que a mí me gusta la gente que tiene mucho hambre.

¿Qué es hambre?

Hambre es atti-- eh-

Aquí una tortilla y no la estáis tocando.

No, porque lleva cebolla. Es que claro, es que me, me ponéis un reto que no puedo superar. Eh, hambre-

Te han dicho que te hacían una tortilla sin cebolla, ¿eh? Y tú has dicho-

Pero he dicho que no, porque-

Te ha salido mal.

Claro, no sale. Pero me quedo con hambre, me voy, me voy enfadado, ¿eh?

No, hombre, no, pero Ay, por favor.

Que no, que estoy de broma.

Te han ofrecido una tortilla.

Que sí, que sí, que sí, que estaba de broma.

Come, come, Miguel.

Eh, cuando digo hambre me refiero... Cuando ye-- digo hambre me refiero a, a, a-- hay un, hay un, hay una vertiente, una ca-- una este de actitud, ¿no? Es decir, yo creo que cuando, cuando tú ves a, a-- cuando tú haces una entrevista de trabajo, eh... Ha-hay una, una, unas cosas soft, un, un punto de, de la relación que, que estableces con esa persona en ese momento, donde eres capaz de determinar, eh, cuán hambriento está una persona, cuánta, cuánta curiosidad tiene, cuánta, eh, ganas de comerse el mundo.

Ese punto de comerse el mundo creo que forma parte de una ecuación más compleja, ah, pero que va en la dirección de: no me da miedo lo nuevo, eh, no me da miedo enfrentarme a problemas, lo que quiero es demostrar. Entonces, esa actitud creo que yo la valoro mucho, o creo no, la valoro mucho a la hora de contratar a una persona. Y veo que una persona con menos conocimiento y esa actitud ahora mismo me-- creo que me aporta un poquito más que una persona con mucho conocimiento y un poco más rodado.

Estoy seguro que la definición de hambre entre vosotros dos es diferente. ¿O no?

A ver, ¿cuál es tu definición de hambre? Porque tú también dices: "Hambre".

¿Sí?

Sí, lo dices, lo dices bastante.

Pues fíjate. Ehm, yo cuando hago las entrevistas y busco a las personas, aparte de buscar este tipo de cosas, el tipo de definición de hambre, siempre le cuento a las, a las personas, que no sé si os va a sorprender o no, igual sí, por qué tienen que venir a Factorial, ¿no? Y le, y le cuento esta, esta, mmm, la cultura que tenemos, ¿no?

Eh, la ambición, esta gana por-- o sea, ambición por ser los mejores, porque eso para mí es lo que defiendo en Factorial, ¿no? Esa ambición por no importa qué, alcanzar esos objetivos. Esa exigencia de dar el doscientos por ciento todos los días, de estar buscando siempre el impacto y no quedarse en actividades. Y si a la gente le gusta eso, entonces le digo: "Pues entonces es tu sitio".

Si lo que no te gusta-

¿Qué es el impacto?

¿Qué es el impacto? Pues para mí es-- el impacto se define solo en, en dos cosas básicas, porque a mí me gusta simplificar. Uno es el que estemos solventando un problema a nuestros clientes y para eso la mejor métrica es el feedback del cliente, ¿no? Y la otra, el revenue. O sea, si solventamos problemas complejos, son problemas porque nuestros clientes quieren pagar, porque le estamos dando un valor y, mmm, y eso tiene que ter-- eh, se tiene que transformar en revenue.

¿Coincides? ¿Sí o no?

¿Sí?

Pero tú, tú hablas más de una curiosidad intelectual, ingenieril, ¿no? Que, que es muy importante.

Mmm.

No siempre, ¿eh?

Ojo, que, que alguien puede ser muy bueno porque tiene mucha curiosidad ingenieril y nos lleva a sitios inesperados, pero no por eso tiene una orientación a impacto.

O, o, o hay alguien que pueda-

...puede arrastrar esta gente a generar impacto. O sea, puede, puede haber, puede ser un puzle de gente más orientada a impacto y más orientado a ingeniería pura. ¿Tú no crees en eso?

A ver, yo creo que-

En los puzles.

Creo en los puzles, pero creo que la masa crítica tiene que estar orientada al impacto, porque tú no puedes estar constantemente tirando de más del treinta por ciento de, del equipo que tienes. O sea, puedes tener un, un, un conjunto de personas que interpreten el impacto de una-- discrepan o no están alineados cien por cien en nuestra definición de impacto, ¿no?

La que-- o al menos la que yo creo que lo que estoy cien por cien-- o sea, muy alineado con Factorial. Y puedes tirar de esa, de esa gente porque es muy buena haciendo otras cosas, pero tú al final tienes que, que empujar a-

Imagina que tienes un equipo de diez personas.

Y tienes siete personas que son muy buenas, pero que no están orientadas a alcanzar los objetivos. Los ob-- los objetivos de Factorial. No la mantenibilidad, no la escalabilidad, no ese tipo de actividades que forman parte, no puedes tirar de siete personas.

Qué buen topic. Esto es muy buen topic para ahora. ¿Quieres contestar algo?

Pero es verdad que la mayor-- pero ¿no creéis que la mayor parte de inge-- cualquier ingeniero quiere un problema puro de ingeniería? O sea, un problema, eh, de, pues innovar, pen-- aplicar una nueva tecnología, dedicarse a la escalabilidad-

...dedicarse a la mantenibilidad, calidad.

No, pero ya, eso, por dec-- bueno, mmm, bueno, no, no me refiero a eso. Me refiero al, al hecho de, eh, hacer tecnología pura o solucionar la forma como en Alemania se hace un break en una aplicación de control horario para resolver el problema de la con-- del, del, ¿no? Del, del cumplimiento normativo de, de no sé qué.

Sector. O sea, acabo de poner un ejemplo.

No, pero quiero decir que, o sea, es difícil que te encuentres un ingeniero que diga: "Hostia, a mí lo que me motiva es solucionar el-"

El problema, el problema del cliente, sea cual sea, este es el problema de Alemania o puede ser el de, el de Italia.

Era la hostia. Era la hostia.

Increíble. Además, lo hice así y asá, y no sé qué. Tú dices-

¿Y quién la usó?

Sí, quién la usó me da igual. O sea, ¿no?

Para ti eso es no go.

Aunque sea la hostia el ingeniero.

Tiene que ser muy la hostia, ¿no?

Sí, sí, totalmente.

Pero para mí no es una dicotomía, ¿no? Porque yo creo que a las personas-- a mí, por ejemplo, me gustan los retos. Y yo precisamente no soy una persona que considere que me gusta trabajar en tecnología legacy, antiguo, ¿no? O sea, yo siempre estoy intentando innovar, ¿no? O sea, buscar la pieza que necesitamos para llegar al siguiente nivel. El tema es que en Factorial, a la escala que trabajamos a día de hoy, solventar un problema requiere que un ingeniero pues que innovar

No-

O sea, busquen-

Innovar. Innovar, buscar nuevas tecnologías, ver cómo escalamos, cómo podemos, eh, soportar dos millones de, de, de usuarios concurrentes. O sea, para eso no se hace con la tecnología que usas tú en tu casa para hacer un laboratorio, ¿sabes? Para hacerte...

Bueno, son contextos distintos, evidentemente.

Entonces, necesita ese tipo de, de ingenieros. Para mí no es un error también, ¿eh? Yo creo que aquí hay retos suficientes, pero-

Se necesita distintos tipos de ingenieros.

Pero tienen que estar orientados a objetivos.

Sí, al final es la típica conversación que tenemos siempre de ingeniero versus product engineer. Al final, dentro de dos o de un año, un ingeniero per se, si no, si no ha cubierto, si no se ha expandido en la parte de negocio, un poco la parte de producto y tener un poco de-- un, un perfil mucho más global, evidentemente tiene muchas menos cap-- posibilidades de, de, de, de existir.

Eh, o sea, ese tiene una más posibilidad de existir que un ingeniero que solo se dedique a picar código. Entonces, esto también es un factor diferenciador que buscamos gente que piense más global, que se preocupe del producto, que se preocupe del negocio. Sí es un perfil más redondo y el futuro va hacia allí. El futuro es o encuentras un factor diferenciador o ingenieros ya hay máquinas que ha-que hacen el trabajo por ti. Pues para mí esa-

Esa es la figura del product engineer, ¿no?

Product engineer.

Es una persona que le interesa el problema que resuelve-

Correcto.

Asegurarse que lo resuelva y el impacto que tiene...

Que entiende el problema, primero, que no es el típico que recibe: dime lo que tengo que hacer.

Entiende el problema en profundi-- que profundiza en todo lo que es el entorno del problema, el stakeholder que lo tiene, ¿no?

Sí.

Eh, versus el ingeniero que dice: Pásame los specs.

Dime cómo lo hago, lo que quieres que haga, que yo lo hago.

Product manager. Product manager.

Exacto.

Dime qué tengo que hacer, ¿no?

Y lo menea.

O sea, o: Diseñador, dame el, dame el diseño-

Me falta un botón.

Que yo lo pico, ¿no?

Sí, es que, este, para mí es-

¿Y los hay? ¿Los hay de estos ingenieros? ¿Los encuentras? ¿Los encontráis?

Hombre, en Factorial tenemos muchos.

Sí.

Tenemos muchos. Pero quiero decir, ¿en el mercado?

Factorial damos por descontado-

Depende. Hay personas que, que vienen con esa orientación de... con, con esas ganas de generar impacto, esa ambición, eh, pero vienen de trabajar, pues a lo largo de toda su carrera profesional, pues vienen de trabajar en una consultora, vienen de trabajar de, de-- en un sector, en un área en el que su modelo de trabajo es ese. Pero vienen con esa inquietud de ser-- de convertirse en ingeniero que necesitamos en Factorial y lo hacen de forma muy rápida.

Después también encuentras personas que encajan desde el minuto cero con Factorial, pero son la menos, la verdad. No es que encontremos ingenieros de producto como Factorial en todos los sitios, ¿eh?

Pero para mí es un, es un mantra que yo repito en cada entrevista de trabajo. El concepto de product engineer, de ticket engineer, de cómo separamos, de qué es lo que no queremos y qué es lo que sí queremos. Ah, y de hecho, buscando también el concepto de product engineer, intento explorar, ¿no?, dentro del perfil de cada persona, más allá de lo que ha, eh, hecho en su trabajo. Me voy un poco a la: cómo usa la tecnología en su día.

Oye, ¿qué hace-- en tu casa tienes, eh, que me voy a inventar, temas de, eh, domótica? Y que me cuenten un poco toda la parte que tiene que ver con, oye, su hobby, que es tecnológico. Y a mí es-- este tipo de cosas, cuando una persona profundiza y es-se sale del, del, de, del círculo para, ¿sabes?, aprovechar y cre-- son cosas que normalmente me suelen gustar.

¿No creéis que el trío...?

Esa es una de mis grandes cruzadas.

Estoy por pedir otra cerveza, ¿eh?

Pídela, pídela. Bueno, ahora cuando pasen. ¿No creéis que el trío es, eh, uno de los grandes enemigos del, del product engineer? O sea, yo, yo es algo que, que tengo muy claro la respuesta. O sea, es una pregunta totalmente retórica. De hecho, quiero leer en voz alta, eh, un WhatsApp que me ha mandado, eh, Rubén, que es el ex CTO de Playtomic, actual CTO de, de Ovianta, que me dice: "Ostra, acabo de ver, eh, el pódcast de-- que hicimos con, con Valeria y Emma, donde hablábamos de ese tema y, y ellas defendían el, el trío, eh, la figura del trío".

Dice: "Llevo diez años luchando contra el dilema del famoso trío. No puedo estar más de acuerdo. Eh, mi intuición o deseo me dice que los equipos deberían estar más empoderados con verdaderos perfiles product engineer. El diseño del día a día desaparece con la IA. El papel del PM es multi equipo, ayudando a proporcionar contexto".

O sea, lo que ve Rubén, y yo también lo veo, es el PM en una, en un, en una, en una plana, en un plano más de orquestación de equipos, de coordinación de equipos, eh, y el ingeniero mucho más metido en el producto. En el momento en que la capa de abajo desaparece, todo el mundo hacia una capa, hacia el negocio.

Todo el mundo, ¿vale? ¿Y qué pasa cuando tú creas un sitio de discusión cerrado que para Emma es muy práctico? Ella es muy, ella es práctica. Eh, entonces ella es-- es muy práctico tener un equipo de tres personas que se reúnen todo el rato y tal, y están dejando fuera al ingeniero esta conversación tan valiosa que están teniendo estas tres personas.

Conversación multidisciplinar donde se hablan de los-- de negocio y de los problemas del cliente. Se está quedando fuera el ingeniero. Entonces, inevitablemente le va a llegar algo cocinado. Y estamos perdiendo la oportunidad de que una persona que tiene talento, que tiene experiencia, que puede entender perfectamente los problemas de negocio, esté participando en la mesa donde se está priorizando, donde está-- están pasando un montón de cosas.

Entonces, ¿para qué queremos ingenieros que luego, eh, no les, no les pedimos que nos resuelvan los problemas de negocio, que son los problemas que de verdad queremos resolver? Cualquier empresa, por mucho que digan lo contrario, cualquier empresa quiere resolver los problemas de negocio, problemas de un cliente y capturar valor haciéndolo.

Pero entonces pongámoslo con un caso práctico. Es decir, ya sabemos cómo funciona un trío, cómo funciona un equipo con un trío y un set de ingenieros. Dibújame un, un formato distinto.

Oye, pues mira, en esta mesa cuánta gente cabe. ¿Seis?

Depende de cómo nos metemos.

¿Siete? Pues los que quepan. Este es el tamaño del equipo.

Claro, pero al mismo tiempo tenemos que hacer delivery. Es decir, hay momentos-

Sí, sí.

Hay momentos en los que a lo mejor la gente se tiene que enfocar en algo concreto porque hay que hacer un delivery, mientras que otros tienen que coger otros caminos.

Vale, pero entonces la división no es el trío, no el trío. Es estamos nosotros enfocados a este problema, estáis vosotros enfocados a este problema, mañana cambiaremos, ¿vale? Estamos en-- un equipo puede hacer varias cosas. Entiendo. Entonces, la división es una di-una división lógica en base a problema. No es una división, eh, en base a jerarquía. Es decir: "No, yo es que soy del trío, tú no eres del trío".

Con lo cual tú no participas en las conversaciones del trío

A ver, esto tampoco es, esto suena excluyente. Eh, pero, pero sí que-

¿Pero prácticamente es así?

Sí que creo que hay un punto en, eh... Esto, esto a lo mejor lo tenemos que parar de grabar, ya, ya anticipo. Sí que creo que hay un punto donde-

No, ¿por qué?

Mira, eh, mi definición de, de engineering manager o, o de, de engineering manager dentro del trío es una persona que es pionera, que va un paso por delante, ¿vale? Que se anticipa a lo que tiene que pasar y que investiga el camino y dice: "Oye, hay diez caminos, voy a descartar seis, que ya he descubierto por mis investigaciones que esos no son viables y voy a dejar cuatro, voy a suavizar, voy a optimizar para poder llegar a ingeniería o al resto de gente a decirle: 'Tíos, hemos estado investigando esto, que huele muy bien.

¿Qué os parece?' Sí, mira, estos seis fuera, pero estos cuatro tenemos que decidir cuál es el mejor camino". Y a, y a mí ese ejercicio de, eh, pionero, de, de pionero, de alguien que se anticipa y va un paso por delante al resto, creo que optimiza. Eh, si no, es un debate continuo, haces un debate continuo.

En papel, esto sí, esto pinta bien, pero en realidad yo estoy, mmm, pensando que es todas esas estructuras, especialmente si quieres escalar equipo mucho, hay un montón de bottlenecks.

¿Hay un montón de?

De bottlenecks y problemas, que al final, si tú tienes todo el, todo el mundo muy agéntico, muy, muy... Mmm, que quieren ir al debajo de todos los challenges de problemas, si ellos reciben algo más, más o menos cocinado, van a ver, van a hacer challenge a todo, van a preguntar a casos-

Pero eso son malos.

Sí, pero en peor caso, no siempre pasa esto. A veces gente está pensando que: "Mira, alguien estaba bien, bien pensado, voy a confiar totalmente en este documento, voy a solo ejecutar". Y esto es--

Bueno, pues aquí tenemos un problema, es decir-

Exacto. ¿Pero cómo tú puedes asegurar que no es, no pasa? Esto es el challenge.

Bueno, no, no pasa.

¿Pero cómo aseguras que pasa? Porque creo que estamos debatiendo sobre el trío en, en una posición totalmente teórica. Y creo que el, ese concepto de trío, mmm, no es el concepto real de Factorial. Hay que complementarlo con la parte de los grises, ¿no? De...

¿Qué grises?

Lo que hemos definido en Factorial, ¿no? Un rol solo define una serie de cualidades en las personas, pero cualquier persona tiene que estar enfocada únicamente, nuevamente, a generar impacto ¿no? Y tiene que participar en lo que sea.

Los grises te refieres a los overlaps entre los roles. Se espera de un ingeniero que se meta en la experiencia, se me-- se espera de un, de un diseñador que meta en el, el negocio, que se, que el overlap lo promocionamos. Sí, sí, pero, sí, pero esto es otro debate, ¿eh? Este es el debate de, de, del rol funcional. Yo te digo-

Que no suma en la organización.

Yo te digo del concepto del trío, que ostras, yo creo en las organizaciones flat, tío. O sea, con el me-- mínima estructura posible. Y vosotros me habéis criticado a mí porque yo, todos mis reports nos reunimos, o, o reports directos, indirectos, toda la capa de directores de producto, nos reunimos todos juntos, ¿vale?

Que somos ya casi quince personas, todos los lunes y discutimos de todos los problemas que tenemos, ¿vale? Son reuniones que a veces son dos horas de reunión, ¿vale?

Es un gran ejemplo.

Oye, a mí me encanta. Me encanta, creo que es de las mejores cosas que hacemos. Porque, en primer lugar, es un proceso de alineación, es un proceso de formación, ¿vale? Entra un nuevo manager, entra ahí y, y está expuesto a esta dinámica y rápidamente entiende cómo está pensando la organización. Si yo, y yo, el día que tenga que dividir esta reunión, voy a llorar.

Voy a llorar porque vamos a generar una capa más de comunicación, una capa... Vale, pues si esto es así para los directores, ¿por qué en un equipo de ocho personas ponemos una capa más? Que es el trío y los demás.

Vuelvo a, a ese argumento, ¿no? Es decir, eh, hay un montón de sistemas de organización, ¿no? Esto lo sabemos cualquier libro de team de organización de equipos.

Sí.

Y hay siete modelos distintos. Y ahí puedes elegir encontrar una empresa en el mundo de éxito con cada uno de esos modelos. Entonces, nuevamente, volvamos al, el modelo. O sea, no hablemos de actividades, hablemos de resultado final, ¿no? Entonces...

Sí, pero, y es que al final no te hablo de modelo, te hablo de horizontalidad, quitar barreras de comunicación. Y no, y dentro de Factorial habrá equipos que tienen más trío y equipos que, que, que trabajan más como, como equipo, todos juntos. Eh, y habrá trío, habrá equipos con trío que funcionan mejor. O sea, todo esto pasa, todo esto pasa.

Pero al final tenemos que dar resultados.

Pero como, como principio. Sí, claro, al final, evidentemente. Cero, yo soy cero dogmático. Oye, los equipos que tienen mejores resultados, yo voy con la libreta y voy a escribir y apuntar y aprender. Eso, eso, vamos, sin ninguna duda. Pero sí que creo que como concepto, eh, me sabe mal desaprovechar ingenieros muy buenos en la capa de discusión de los problemas.

Sí.

No me gusta el paternalismo de: te lo quiero dar masticado. No me gusta.

¿Tú crees más en el formato de Jensen Huang con treinta reports y one on ones públicos? Es como tú estás más a esta dirección ahora.

Pues mira, te digo que me estoy moviendo más-- mira que yo era muy partidario del one on one como concepto y tal. Me gusta, ¿eh? El one on one, o sea, en general me gusta, pero sí que creo que se abusa del one on one. Creo que el one on one de un new man-- un nuevo manager no sirve para nada. Para nada. Es pérdida de tiempo, porque el management es una disciplina, oye, es una disciplina per se.

¿Sabes? Hay que aprender a, a, a movilizar a la gente y tal. Entonces, un manager, el primer día le ponen a hacer one on ones, ¿y de qué hablan? Pues, mmm, supongo que del fin de semana, porque de eso, de cómo hacer los objetivos de negocio, pues todavía no. Entonces, yo creo que el one on one está a veces sobrevalorado. Eh, es una-- un gran overhead para las compañías, porque se convierte en una institución.

Estamos interesados en el one on one, una hora, van ahí, hablan del fin de semana. Entonces, esto es, es, es, para mí no es práctico. Sí que creo que el one on one es el instrumento más importante de gestión, pero eso no significa que es un ritual semanal. No, creo que las cosas realmente la gente se mueve en el one on one.

Eh, el one on one, pero como tal. O sea, en la conversación uno a uno se, se discute todo, se hablan de los problemas de las personas. También se mezclan los problemas personales, porque las personas son el pack completo, no solo el, lo que traen a, al, a la oficina, sino también lo que, lo que llevan encima. Eh, y esto muchas veces es difícil hacer una reunión con mucha gente.

Pero dicho eso, el la, el ritual del one on one Masivo, pues creo que es un overhead. A veces va bien, a veces no va bien. Eh, indiscriminadamente, pues probablemente es un, es un overhead. Eh, creo que con Factorial podemos mejorar ese one-on-one.

Podemos mejorarlo. Me alegra que me hagas esa pregunta.

Esto, esto es una de las grandes ilusiones, de hecho, eh, que tengo, ¿eh? Por-- o sea, yo esta hora es una hora que nosotros tenemos-- que hacemos doscientas veinte, doscientas veinte horas a la semana de one-on-one, que es bastante-

Son doscientas veinte managers.

Doscientas veinte manes o doscientas veinte horas de one-on-one.

En realidad son más horas, porque un manager tiene varios one-on-ones. Yo, por ejemplo, tengo cinco.

Es verdad, es verdad.

Son muchas más.

Son muchas que digo. Son muchísimas más, efectivamente. Pues estas horas yo creo que, o sea, mi, mi, mi gran ambición es, gracias a vo-- al producto que estáis construyendo vosotros, ser capaces de influir en este one-on-one y darle información de negocio, de gestión, información relevante de la compañía para que aprovechar este tiempo para construir, para discutir, para alinear, para, para asegurarnos de que realmente esté teniendo valor.

Potenciar a un manager.

Potenciar a un manager.

Sí. Ese es el objetivo. ¿Quieres que haga spoiler de...?

No, eso ya lo, ya lo, ya lo vemos en el line.

El Factorial.

Bernat. Yo escucho que habláis-

Pero el objetivo sí es potenciar al manager, hacer de un manager diez, diez veces un manager, pro-- proveyendo a su alrededor de todo lo que es necesario para que su one-on-one sea lo más efectivo posible.

Entonces sí.

Entonces-

Con, con el producto de one-on-one de Factorial, entonces sí.

Sí.

Pero no sé si te he respondido la pregunta de si creo en Jensen Huang. A ver, no le, no le va mal, ¿no? A Jensen Huang. Estamos hablando-

Mal no le va, no.

Una empresa más grande de... ¿No? Y cada vez más hay este modelo de, de muchos reports y tal, ¿no? Muchos reports y tal-

Buah, pero muchos reports es difícil. No sé cómo lo hacen.

Es muy difícil.

Son treinta.

Es muy difícil.

Pero, pero el challenge al final es, es lo mismo, es como cómo alineamos todos, cómo tenemos el mismo contexto, como el LMS, en este sentido, que todo el mundo puede ver que negocio, management, equipo, en, en la misma manera. Y él está haciendo básicamente esto, es como todos los one-on-one se están transmitiendo.

Ya. Tú, Miguel, ¿qué piensas?

Yo creo más en lo que acaba de, lo que acaba de decir Liam, ¿no? En ese concepto de estar alineados y más en el concepto en sí del, de, de one-on-one, porque creo-- estoy también de acuerdo en lo que dices, eh. Creo que se ha hecho mucho marketing de, de ese instrumento, que creo que es útil, pero no creo que sea el diferenciador.

El diferenciador es el alineamiento, el tener todos una dirección y, y todos con, con esa parte de ir hacia adelante a alcanzar los objetivos. Si eso lo podemos, podemos llegar a través de one-on-one, perfecto. Si hay otra metodología para alcanzar lo mismo, pues a mí me parece muy bien.

¿Cómo veis el sector tech en el futuro? O sea, ¿dónde vamos? Eh, ¿creéis que vamos a un modelo de menos ingenieros? Eh, muchas capas son, eh... Más PMs o, o ingenieros realmente reconvertidos a negocio o, eh, ¿cómo se va a construir la tecnología?

Yo creo que hay un camino, que ya se están produciendo los primeros pasos, en el que los grandes productos no requieren de grandes volúmenes de personas. Es decir, eh, Lovable, eh, Magnific, que son dos personas, hay un montón de grandes productos que es-

Magnific, eh.

Magnific. Claro, son murcianos. Tengo que tirar, eh, a tierra.

Muy bien.

Pero sí, Magnific y lo compró Freepik. Eh, son dos personas, diez millones de RR, oye, no está mal. Eh, entonces sí que hay un, un punto en el que creo que va a haber muchas más cosas gestionadas por menos gente, eh, y que puede funcionar bien. Entonces, para mí en la cabeza lo que me resuena más es que el concepto del product manager debe ser un product manager que tiene un prof-- una profundidad técnica para entender qué es lo que la tecnología puede proveer dentro de un año en una situación de tanta incertidumbre.

Claro, pero es, es lo mismo, ¿no? O sea, el ingeniero que tiene negocio o el product manager que tiene tecnología.

A lo mejor convergen. A lo mejor convergen en lo mismo y es un product manager con profundidad técnica o un engineering manager con, con conocimiento de producto.

Pero menos headcount.

Menos headcount, sí. Sí creo que sí.

Entonces, ¿más startups? ¿Más, más startups?

Más cantidad, menos gente.

Más cantidad de empresas.

Sí. Más problemas pequeños solucionados. Ese es mi mercado-

¿Tú qué crees? Hostia, no sé. Las dinámicas de mercado llevan siempre a la consolidación, al volumen. Eh, no, no sé yo si... Porque podemos-

Estamos en un momento complicado, ¿eh? No sé hacia dónde vamos. Yo veo el, el mundo en el que tres macrocorporaciones lo controlan todo y veo-

Muy 1984. Pero bueno, puede pasar, sí, sí, sí.

No, pero al final, si tú puedes hacer más con menos gente, si tú ahora tienes, tienes mucha gente, tú puedes hacer más, mucho más.

Evidentemente.

Por eso, como tú puedes atacar mucho más mercado-

Pero al mismo tiempo, una persona con un ordenador en su casa es capaz de hacer mucho más que, eh, que hace dos años, con lo cual es más fácil resolver un problema, detectar un problema. Cuando más mentes hay pensando en diferentes problemas, es más fácil detectar problemas y cuando resolverlos es más fácil, quizá, eh, la diseminación, el tener diferentes-- Otra cosa es que luego llegue una, una empresa grande y diga: "Oye, pues te cojo, te cojo, te cojo, te compro y te, y te inyecto en mi, en mi ecosistema".

Pero yo pienso que hoy en día hay más facilidad de resolver problemas, porque el gran problema es el desarrollo y ese se está simplificando.

El problema es el desarrollo y s-- y la diferencial es la experiencia. Cuánto tardas en generar experiencia es el mismo problema. ¿Sabes? Que si-

A ver, a ver, no te he entendido ahí.

O sea, si el problema es la construcción, da igual que ahora empecemos-

Pero coincidimos aquí, es el problema de la construcción. Yo creo que sí, ¿no?

Yo creo que ahí está el problema de la construcción.

Sí, correcto.

Ahora, si dejas el problema y tú hoy-- es lo que comentábamos antes, ¿no? Solventar un problema, un problema existente en el mercado, que, que para el que no hay una herramienta, digamos.

Sí.

Eso lleva mucho tiempo. No solo es tener la idea, es tener la constancia, el tiempo, ¿no? El tiempo de construirlo y demás. Si eso lo vamos a reducir, imagínate, a dos semanas.

Sí.

O sea, como no vamos a generar de ahí a un año-

Es donde la creatividad, la forma de pensar, la innovación, donde cobra más valor, porque la ejecución se ha reducido, con lo cual es más fácil, creo yo, ¿eh? A lo mejor estoy aquí en modo flipado, pero es más fácil que una persona, eh, en, en, en Molina de Segura, Murcia, otra vez tiro a mi tierra, en el salón de su casa con un portátil De repente tenga una idea creativa, innovadora y que sea fácil ejecutarla porque la fricción ya no la tiene y que llegue a tener resultados que, que una, no sé, creo que-

Que va a haber más emprendedores.

Yo creo que sí, es mi visión. Eh, creo que va, va, esto está primando la creatividad. Es decir, cuando la gente tiene una buena idea, antes decía: qué buena idea tengo, pero no sé cómo hacerla. Ahora creo que se permite más. Vamos a un camino en el que hacer es más fácil.

Oye, Ilia, ¿tú crees en la AGI? La...

Siempre.

La superinteligencia.

Siempre. Soy muy optimista, soy muy optimista en ese sentido. No, es como al final, como gente no tiene esta definición de AGI y de todo, pero todas las noticias que, que estoy viendo, especialmente esta noticia de, ah, de esta semana que Anthropic ha sacado nuevos modelos. Y después, en todos los security testings que ellos están haciendo, al final han encontrado manera que, ah, que, que un modelo está haciendo black meeting, no sé cómo en castellano, pero está...

Chantajeando.

Chantajeando, exactamente. Todos los, ah, gente de Anthropic para que, para sacar-

¿Cómo chantajea un modelo a la gente de Anthropic?

Te lo digo yo. El modelo de IA Claude Opus cuatro de Anthropic intentó chantajear a ingenieros amenazando con revelar una aventura extramatrimonial para evitar ser reemplazado en el ochenta y cuatro por ciento de las pruebas realizadas.

Pero, ¿cómo?, ¿qué significa eso? ¿Que intentó al ingeniero...?

De dónde saca la información extramatrimonial. Al final, si tú pones un prompt que tú tienes que sacar, ah, llegar a todos los objetivos, da igual, da igual los instrumentos que estás usando, está pasando esto. Y hay otra cosa, que en o tres, en, en OpenAI, después de cien pruebas, en siete o ocho, ah, cada vez que un, ah, ¿cómo es?, un, ah, gente de OpenAI preguntando a o, a o tres: "Por favor, ah, haz shutdown", o tres, cambiado el script de shutdown porque no quería, ah, no quería parar.

Pero esto lo hizo por mutuo propio.

Sí, exactamente.

Pero ¿cómo? Funciona por prompts, ¿no?

Sí, pero ese, eso significa misalignment, cuando tú preguntas una cosa y, ah, AI piensa por su lado y haciendo sus propias cosas.

¿Pero qué significa desactivarlo?

No, es como, mira, imagínate que tú tienes un script que va a apagarte. Y yo preguntando: Bernat, apágase. Y tú, mira.

¿Pero qué significa apagar un LLM?

Imagínate que un script apaga el ordenador.

El LLM no enien-- no tiene este contexto, pero está pensando que, mira, apagar es, para mí es morir. Por eso yo voy a cambiar mi script para que es apagar.

¿Pero qué es apagar? Es que sigo, sigo, sigo-

Imagínate que el LLM vive en un ordenador, por poner un ejemplo, vive en un ordenador y tú al-

¿Pero cómo que vive? Es que no vive en un ordenador.

Bueno, es un modelo, sí, vive en un ordenador. Es decir, es un modelo, ¿no?

Es una instancia. Cuando haces un prompt, nace y muere.

No, no tiene por qué. Es decir, el, el, es decir, el modelo es, es, tiene historia. Es decir, puede, puede, puede conservar cierta memoria.

Tiene historia, pero sin prompt no pasa nada, ¿no?

Claro, pero tú le preguntas. La, la clave está en hacer el truco. Es decirle: oye, tú estás instalado en este ordenador, ¿vale?

Imagínate que estás instalado en...

Ejecuta el comando y ejecuta el comando que te apaga.

Vale, pero esto es-

Que es este, y te lo puedes llevar.

¿Y por eso hacemos drama?

No, es para mí, como hacemos drama al final.

Imagínate que eres un humano.

No, no, pero no en ese imagínate. Es como al final hay, hay unas herramientas que el LLM tiene con una herramienta apagarse. Es como un script que tiene que correr. Y el prompt es cada vez que al-- yo voy a preguntar al LLM apagarse, ella está haciendo esto. Ella o lo, no sé. Ah, y en algunos casos, o tres, cambiado el script y después está, estaba diciendo que sí, ya está, todo hecho, ah, apagado.

Pero no, es como cambiado para-

Pero no está apagado.

No está apagado. Y también-

¿Y cómo sabemos que no está apagado?

No, porque-

Es que sigo intentando meterme-

Cambiando código de scripts para que esto no pasa.

Ah, vale.

Es como, es especialmente. Y también después mentira, ah, respuestas que mira, ya está.

Miente al usuario.

Exactamente, al usuario qué está pasando. Por eso es como para mí esto es sen-sensación de self preserve, ah, que hay, ahora está apareciendo en esos modelos tan grandes.

¿Y crees que es un paso previo a la autoconciencia?

Sí. Sí, pero al final no es pa-paso en un año, en dos años, en tres años, pero un trend a donde vamos es como...

¿Crees que la tendencia acabará por crear un otro ser?

Sí.

Muy bien.

Sabéis quién es Demis.

La verdad es que da un poco de, de miedo, ¿eh? Y eso lo unes al, al ejercicio que han hecho los chinos con los robots haciendo, ¿lo has visto? Haciendo, eh, kickboxing, pero ahora-

Que se le va la, se le va la, la flapa.

Superreal, ¿eh? Digo...

Sí, sí, sí, sí. A mí me dio miedo, ¿eh? Porque es, es como verlo físico.

Sí, sí.

Es como, como no es verlo físico.

Pues imagínate que tenga este modelo y no se quiera apagar.

Sí, sí, no, no.

Por eso Jordi dice que no quiere un androide en su casa.

Ah, cierto, lo escuché.

Demis Hassabis, ¿sabes quién es? Es el CEO de, de DeepMind, de Google. Este tío lo entrevistaron ayer en un pódcast que se llama Hard Fork, del New York Times.

Vale.

Eh, eh, y es, por cierto, premio Nobel de Química, porque fue el que gestionó toda esta parte de Alpha Fold, aquellos descubrimientos de Google de, eh, plegar o desplegar, no sé, no sé muy bien la automática, el tema de las proteínas y por eso ganó un premio Nobel en el 24. Eh, el tipo es un genio, jugador de ajedrez, el tipo se le ve, eh, y está-- y en el pódcast-

Un genio del ajedrez. ¿Cómo juega al ajedrez?

Sí, sabe, sabe cómo-

Es muy obvio.

Sabe cómo jugar al dominó, al dominó, a las damas. Se le da muy bien todo juego de me-- todos los juegos de mesa se le dan bien.

Un genio. Eh, el tipo hablaba de la, de la AGI, eh, y decía que en, en Google había miedo, eh, por hablar del AGI y que de un tiempo a esta parte todo, todo el mundo está empezando a hablar, que parece que es como si hubieran tomado la píldora del AGI. Él hizo un, una especificación de su roadmap de cómo iban a suceder las cosas en 2010 y de momento está on track.

Y su planificación, según él, en el 2030, AGI es una realidad. Y Sergey Brin, el cofundador de Google, dice que un poquito antes, en el 29. O sea que en las manos de Google, AGI será una realidad en tres o cuatro años.

En 29 años. Se están discutiendo, dice: no, no, es el 29, es en mayo del 29.

Exacto. Está de, está en ese punto.

Yo flipo.

O sea, ahí se acaba el mundo, ¿no? O sea, tenemos cuatro años de bruto.

Efectivamente. Este dice que antiguamente en Google se le llamaba al AGI la cosa loca, pero que de un tiempo a esta parte, eh, they are getting the pill. O sea que como que todos los, los, eh, ejecutivos de Google parece que ya han tomado la pill y ya están empezando a hablar de AGI como una realidad.

Bueno, pues nada, pues oye, con esta, con este notición de cuándo acaba el mundo.

2029 o 2030, una de ellas.

Una de ellas, vale. Pues lo podemos dejar aquí. Muchísimas gracias, Miguel, Rai, Ilia, por, por participar en la tertulia en el Entrepreneur, que es el restaurante de Itnig, el último restaurante que hemos abierto. No habéis tocado la tortilla.

Ahora, finalmente.

Me alegro, ahora que paremos, te haremos una sin cebolla. Gracias. Hasta la semana que viene.

Chao.

Hasta luego.