¿Seguirá teniendo sentido escribir código a mano? | Tertulia de itnig

En el punto donde estamos ahora es en construir AI as a service, es decir, en facilitar la AI y llevarla cerca de nuestros clientes. ¿No sentís que lleváis la neurona al máximo en estos momentos? O sea, que estamos viendo la capacidad del ser humano ahí al límite, límite. Tú ves que el cuello de botella es producción.

Porque todos sabemos que en el largo plazo hay AGI. La pregunta es: ¿qué va a pasar mañana? Entonces, en este debate de cuál es el perfil, eh, que funciona en Factorial, junior, senior, staff, mid, eh, no sé qué. ¿Qué, qué ves tú? ¿Qué piensas ahí?

La característica principal para una persona que rinde es .

Pedimos a la gente que se ubicara en más o menos believers de la IA. La mayor parte de la gente estaba en no believers, pero ahora unos meses más tarde, pues yo creo que ya no quedaría nadie que se ubicaba como no cree en la IA. ¿Tú, tú en qué fase estás?

Eh, no escribo código directamente.

¿Ni una línea?

Ni una línea, ni una línea.

¿Desde hace meses?

Desde hace meses.

El problema nunca había sido generar código. El problema es saber qué código escribir y precisamente detectar esos patrones, o sea, pensar en sistemas. Ese es el problema.

Pero claro, escribir código es escribir código, ¿no? No lo tecleo, pero el código que se genera yo lo tengo en la cabeza. Me gusta todavía tener el control de cómo la gente está pensando y entonces sé qué código va a generar.

Nunca me había pasado hacer una demo y yo ser el que más flipa. Y de golpe Juan le pinta un dashboard exactamente como si le, le leyera el cerebro todo lo que está pidiendo. La gente flipa. Yo pr-- yo primero.

Esta semana tenemos una tertulia un tanto especial. Estamos en la oficina de Factorial. Por fin, por fin la oficina de Factorial, eh, funciona, existe, eh, de ingeniería, de ingeniería y de producto. Y hoy tengo a varios ingenieros, eh, de Factorial que pasaban por aquí y os he liado, ¿no? Eh, y vamos a hablar de IA, obviamente, y de en qué etapas estamos ahora mismo en Factorial y vosotros personalmente, ¿vale?

Se ha colado un PM. Se ha colado un PM, porque dado que ha hecho un montón de pull requests últimamente...

Te he colado como ingen-- como neoingeniero, ¿vale? Y aquí habrá un poco la discusión de, eh, cuál es el rol del PM y hasta qué punto hay un solapamiento en el ingeniero se vuelve PM y el PM se vuelve ingeniero, ¿vale? Pero antes de esto vamos a, a repasar un poco las fases del cambio de mindset que hace seis meses o hace un año la mayoría de gente...

De hecho, hicimos una, una, un ejercicio en Factorial donde pedimos que la gente se ubicara en una sala grande, eh, en la Costa Brava, que estábamos haciendo un offsite. Eh, pedimos a la gente que se ubicara en más o menos believers de la IA, ¿no?

Y, y la gente, pues se ubicó, ¿no? Y yo creo que había la mayor parte de la gente estaba en no believers del, de la IA, ¿no?

Sí. La mayor parte de la gente.

Hace tiempo, hace tiempo, ¿vale? Entonces los, los frikis tal, que esta-- estábamos ahí como believers sin tener ni puta idea lo que significaba todavía, ¿vale? Pero ahora unos meses más tarde, eh, pues, pues yo creo que ya si hiciéramos el mismo ejercicio no quedaría nada, nadie.

Pero, pero no quedaría nadie en el, en el que se ubicaba como no cree en, en la IA. Aunque Edu Seco lo estoy viendo aquí y es, es bastante reticente, no a la IA, pero tú eres el que dijiste lo de... que lo más relevante no era el noventa por ciento automatizable, sino el diez por ciento no automatizable.

Claro. O sea, yo más que eso, lo que perdí es el interés en lo que se puede hacer con la parte de vibe coding, ¿no? O sea, yo me estoy inter-- me interesa qué es lo que no puedo hacer, en, en qué se atasca, en qué problema se está atascando.

Pero, pero primero hay que hacer, o sea...

Sí, pero a mí me-

Este noventa por ciento hay alguien, o sea, hay que hacerlo.

Sí, pero a mí personalmente me interesa menos eso, ¿no? O sea, es un problema que no está resuelto, pero alguien, o sea...

Alguien lo va a resolver.

El, el tooling madurará. Cada vez la barrera de entrada para usar estas herramientas cada vez es más bajo, eh, y, y creo que el problema no estará ahí. O sea, hoy sí que está ahí, pero no, no estará ahí de aquí a un año, dos años.

O sea, a ti lo que te preocupa es lo que es-- no es computable.

Sí, sí. No, no, no, no, porque al final es computable, pero son problemas, eh, no sé, difíciles de entender, de elegir la solución también. No es solo entender el problema, hay una serie de soluciones que todas son válidas, pero elegir la buena, mmm, esto no te lo hace un, un LLM, ¿no? Te, te, te da una o te da opciones, pero ¿cuál es la buena?

¿Cuál es la que te convence a ti? ¿Qué, qué criterio sigues para elegir cuál sí y cuál no, no?

Por cierto, interrumpiros, ¿eh? Por favor, no, no me hagáis hacer de moderador todo el rato.

O sea, al final es lo que a mí me convence o no me convence. Si a mí el output no me convence, digo: pues no estás eligiendo bien. Entonces, eh, vuelves-- mue-mueves el problema a cómo le doy el contexto para que haga la solución que a mí me parece la correcta. Eh, y, y eso de el tema de ingeniería de contexto y to-- qué contexto hay, la memoria.

E-en base a qué yo tomo decisiones. En base a qué para mí la solución esta es correcta y la otra es incorrecta. ¿Cuál es la razón?

Espera, es que has hablado de staff developer.

¿Qué es un staff developer? Para la gente que nos escucha igual, que tiene que entender.

Que no es fácil de responder. ¿Qué es? ¿Qué es un staff developer?

Yo resumiré con más años de experiencia. De momento, hay impacto más horizontal y no solo enfocado en un solo producto, en un, una cosa, sino impacto en, en toda la empresa.

O sea, staff implica años de experiencia.

Es-- bueno-

Implica impacto, ¿no?

Sí, implica impacto, pero normalme-- es difícil poder hacer este impacto sin tener años de experiencia, por-- como a todo. Es ne-- para hacer-- ser experto en algo necesitas, pues eso, las 10.000 horas, ¿no son? O no sé cuántas para-

Bueno, yo creo que, que aquí, en este pódcast, tenemos un candidato a no tener que tener toda esa experiencia para ser staff, ¿eh?

Bueno, pues-

O sea, siempre hay alguien que- ...que, que, que rompe un poco ese molde. Pero yo creo que a ti, Edu, lo que te motiva, porque tú eres ingeniero, o sea, llevas la médula, ¿no? Lo que te mola es ese 5 % que todavía no es capaz de resolver la IA y que tú te ves con esa capa-- es lo que te motiva, ¿no? Ese reto a resolver lo que la- Sí, sí

...IA todavía no es capaz de hacerlo correctamente. No es tanto el-

Sí, lo otro lo veo ya como problemas solucionados. O sea, yo sé que no están solucionados, pero se-- estarán solucionados en-

Pero la pre-la pregunta es: ¿qué es lo que es este-- qué es el 90 y qué es el 10?

Claro, sí, sí, sí.

Por ejemplo, co-cosas que me doy cuenta y que al final es solo porque le falta contexto o le faltan instrucciones, pero la capacidad para hacer las cosas las tiene. Pero por ejemplo, yo muchas-- reviso muchos pull requests, ah, por ejemplo, en One, y me doy cuenta de que hay 10 equipos que están haciendo la misma cosa de maneras muy similares.

Ah, esto normalmente pide de: vale, igual necesitamos una abstracción, unificar todo para que no todo el mundo repita. Ya no es, ya no es tanto por repetir código, sino para tener, pues una, una respuesta estructurada. No tenemos ahora mismo, porque-- algo, un agent que vaya detectando todos estos patrones y proponga una nueva abstracción.

Yo creo que la capacidad la tiene. Si yo le do-- le digo: "Eh, mira todos estos pull requests e intenta encontrar una abstracción", lo hará. Pero se lo tengo que decir yo. ¿Cómo, cómo hacemos para que sea reactivo sin, ah, sin intervención humana?

Tú tienes que encontrar el problema. Tú dices esto, ¿no?

Exacto. O sea, nosotros creo aún somos mejores encontrando estos problemas o detectando esas cosas que de momento, bueno, no, no lo hemos probado simplemente en poner un agent y ve haciendo lo que quieras con todos los pull requests. Lo podríamos probar, pero no sé.

Y, y esto, y esto antes, como eras, decía, hace cinco años, ¿revisabas tantas PRs que eran muy parecidas entre sí? ¿O es que ahora, como hay tanto músculo y tanta capacidad-

No

...de repente tenemos muchísimas más PRs?

O sea, mi capacidad de revisar pull requests es la misma ahora que hace un tiempo. Simplemente-

Pero hay otras más

...hay otras que se quedan sin revisar, porque hay mucho, hay mucho más código que revisar que antes. Ahora creo que el, el cuello de botella que tenemos es eso, porque aún hablando del nivel en que estamos de AI, a, al menos nosotros, aún revisamos el código y no confiamos ciegamente en todo lo que se genera.

Voy a hacerte un poco de más de challenge. Es, ah, aquí yo revisando pull requests veo que estamos enfocándonos más a nivel de abstracción mucho más alta comparado con antes, porque todos los cosas básicos que mira todos esos, no sé, scopes o problemas o algunas cosas de sintaxis, da igual. Esto, Copilot u otros co-- otras-

Sí

...IA, mmm, sí, cogen muy bien. Y por eso tú ves ahora solo oportunidades ma-ma-- de, o de otro nivel.

Sí, sí, te lo comp-- sí que puedo centrarme en cosas más importantes que nimiedades.

Oriol, ¿tú en qué fase estás? ¿Tú revisas el código?

Sí, sí, aún, aún y, y voy intentando guiar al, al-- o sea, antes que decíamos que es stack, para mí-

¿Pero no escribes?

Mucho-- muy poco. O sea, últimamente estoy-- esta semana toca OpenCode y es con el que uso. Y también estoy jugando con una app que se llama, ah, Handy, diría, que es similar a WhisperFlow, pero gratuita, que me la pasó Nacho. Básicamente, le hablo al ordenador y le digo: "Haz esto".

Y, y lo hace, mágicamente.

O sea, tú hablas, vas por la casa.

Bueno, de momento-

Hablando

...no estoy paseando, pero sí, sería el, el, el siguiente paso.

El next level, sí, sí.

Hay, hay otra app que se llama Paseo, que directamente, o sea, te, te expone tus propios coding agents en tu ordenador, tienes acceso en el móvil y supongo que el nombre viene de eso. Mientras vas paseando, vas mirando qué van haciendo y le hablas y le dices: "Eh, no, esto está mal", y sigues paseando.

Sí.

Y ya está.

Vale. Tú, Edu, ¿en qué, en qué?

No sé cómo lo ves tú lo que vayamos paseando mientras trabajamos, pero...

Yo, yo lo veo fantástico. O sea, mientras generemos ARR, que es mi monotema. Ehm...

Yo en Factorial reviso más código que nunca, seguramente, ¿no? Porque soy el-- noto que soy el bottleneck. Eh, hay PRs, o sea-

¿Tú eres el bottleneck de Factorial?

Sí. Bu-- o sea, uno, uno de los bottlenecks, ¿no?

Ah, vale. Sí, sí.

Eh, hay, hay más PRs que nunca y hay gente que crea estas PRs y que ya no solo que no esté seguro de mergear, quieren que alguien la revise, ¿no? Alguien que, bah, no es tanto para decir está correcto o no, es otra persona además de yo vio este código y entonces lo puedo mergear, ¿no? Eso no soy solo yo, ¿no? Es como más el check que la revisión.

Lo-

Pero, o sea, lees código, pero ¿tú escribes código?

No, no. O sea, ca-casi no. O sea, llevo, llevo meses que no. O sea, desde diciembre no escribo código. Pero claro, escribir código, ¿qué es escribir código, no? O sea, eh, no, no lo tecleo, pero el código que se genera yo lo tengo en la cabeza. O sea, es-- me gusta todavía tener el control de cómo la gente está pensando. Y entonces, como entiendo cómo está pensando, sé qué código va a generar.

No me hace falta leerlo para saber que es el código correcto.

Pero seguramente no en la literalidad, ¿no?

No, pero las ideas están ahí.

Las ideas sí.

Es que cuando reviso una PR tampoco voy mirando línea por línea. Yo miro en diagonal y veo las ideas y digo: "Vale, esto me cuadra, esto no me cuadra". No soy más: "Buah, esta línea no, no está correcta". No, es, es más raro eso.

Pero me interesa también vuestra opinión en general, tuyo también, en ese sentido. ¿Qué tú revisas exactamente? Po-por-porque A mí, en, en mi caso personal, yo estoy enfocándome mucho más en interfaces, en conexiones entre módulos.

Sí.

Y también o-otros como, mmm, en maneras como verificar que todo funciona.

Sí.

Que todos los tests, end to end, no sé qué. Pero ¿qué pasa dentro de este módulo? A mí me da un poco igual.

Sí, igual que tú. O sea, yo vi-- mira, eso es la e-- lo que yo llamo la idea, ¿no?

Mhm.

Que el modelo del mundo que la gente o la persona hizo del problema, eh, cómo lo expresó en, en términos, no, no en líneas de código, y, eh, que dicen exactamente cómo se resuelve el problema, ¿no? Qué lenguaje creó el LLM para describir el problema y resolverlo en código, ¿no?

Mhm.

Me voy a la sección, eh -- Miguel, ¿tú, tú en qué fase estás?

Ni una línea, ¿eh?

Ni una línea.

Desde hace meses.

Míratelo bien, míratelo bien.

¿Y por qué?

A ver, de aquí, ¿quién utiliza Cursor?

Yo, yo utilizo VS Code a veces en lugar de Cursor, porque una-- o sea, si me espero a ver el código en GitHub, para mí un feedback loop es demás-- es, es muy largo. O sea, a mí me gusta par-- más ver lo que está haciendo para poder dar instrucciones de cómo corregir, ah, más rápidamente.

Si ya veo que está yendo por un lugar que no me gusta, se lo puedo indicar. Lo tengo que probar. En teoría, lo quería probar esta semana, pero no he probado. Una cosa que se llama Crit, que en teoría, ah, te permite hacer esto de ir viendo en tu browser los cambios que va haciendo. Vas poniendo-- puedes hacer como un, un pull request review, pero en live, y se lo vas poniendo ahí y, y eso le pasa los comentarios al agent y hace steering, y en te-en teoría lo va haciendo, y es compatible con O-OpenCode y todas las cosas, y no hace falta algo tipo Cursor.

Pero a mí la-las herramientas que son solo de terminal me faltan a veces de, de quiero ver por dónde se está yendo.

Vale. ¿Y quién utiliza Claude?

Aquí no, ¿eh? Codex.

Yo también.

¿GPT-4?

Ah, 5.4. Vale. No jodas. Vale, vale, vale, vale. Vale, y, y a nivel de, de créditos, eh, ¿cuánto consumís?

Yo no, mmm-- estoy usando el Claude Max, no soy capaz de gastarlo. Yo me quedo-- en el Max me quedo al setenta, 75 % compartiendo la suscripción entre personas.

Sí, eso. Pero en esa no soy capaz de gastarla. Entre varias personas no soy capaz. Con teams of subagents en múltiples terminales a la vez, no soy capaz.

¿Y tú?

¿Por qué el personal? Pues...

Bueno, pero aquí no podemos tener más tokens.

No, tenemos tokens, pero Cursor, por ejemplo, hemos parado de pagar. O sea, ahora usamos Copilot para todo.

Pero tokens no podemos tener más.

Tenemos to-- no, tenemos, no tenemos límite. No tenemos límite.

Ah, pues entonces... No entiendo.

Cortamos, cortamos aquí. No, para eso, para eso está la tertulia.

Después va negativo y es muy rojo.

Mil quinientos por cien y tal.

Tú, Adrià, ¿cuánto quemas?

Se ha discutido mucho y no tengo claro que al final la conclusión sea que se subsidia.

¿Sí?

Tres, 3X, sí.

¿13X?

Uno tres, sí. Por eso, como te comparas, si tú compras Max y si tú comparas con el precio que tú vas a pagar por el token, por API, tú tienes 3X-

Pero no respecto a su coste.

Claro, coste no sabemos.

Respecto del coste de desarrollo.

API versus sí, versus sí.

Vale, ¿pero tú cuánto quemas?

Al nuevo.

Sí.

Durante un tiempo.

Joan, tú eres PM.

¿Y qué haces aquí?

No, no, mi pregunta es, mi pregunta es: ¿tú programas?

O sea, tú ves que el cuello de botella es producción.

Y que tú puedes ayudar.

O sea, las dos cosas. Ves que es esto y que tú puedes ayudar.

Vale. Y Jacob-

Pequeñas, pequeñas entre comillas. En plan, tú en concreto eres un PM techie, ¿sabes? Te tienes PRs de setenta, setenta y cinco archivos. O sea, no son, no son-- no estamos hablando de PRs de tres archivos, estoy tocando aquí un al-- ¿sabes? Son PRs-

Introducen.

Sí.

Eso es lo que iba a preguntar. ¿Aquí hay alguien que esté en contra de que el PM saque pull request? Aquí no se, no se va a ofender nadie, es un debate.

O sea, yo lo único que estoy en contra es de, de que hagamos deploy a producción de código que nos va a traer problemas.

Hombre, pero y a ver, ¿quién no está en contra de eso?

Ya, pero, o sea, el, el otro día había un artículo, no me acuerdo cómo se llama, que el bottleneck ahora era la-- toda la revisión y realmente es eso, porque a veces tengo la sensación de que los-- quien produce ahora el código tiene que pensar menos o trabajar menos que la persona que lo está revisando.

Porque como aún no tenemos un flujo de revisión-

Eso es muy interesante

...tan auto-tan automático y tan-

Ese tema es muy interesante, porque ¿qué es pensar? ¿Pensar en qué? Porque hay muchas cosas a pensar cuando haces un, una pull request. Una, una es el problema a solucionar, que igual Joan tiene más conocimiento porque tiene más contacto con el problema que algunos de los ingenieros. Y la otra es cómo la-- esta solución que estás planteando encaja en el ecosistema de un producto más grande, ¿no?

Y esto son dos, dos cosas a pensar.

Pero también token de responsabilidad. Es como-

Sí, exacto.

Si tú generas un montón de código y después mira, alguien va a revisar esto y va a poner su sello, sello de calidad y después deployamos. Pero claro, porque esta primera parte ahora es casi gratis. Pero revisar no. Sí, porque hay más stakes, hay más responsabilidad ahí. Por eso, ¿cómo, cómo hacemos este equilibrio?

Y que el problema es saber cuál es el cinco, 10 %, ¿eh?

Si mi trabajo esta semana, se lo decía a Iria, ha sido básicamente escribir todo lo que yo tengo en la cabeza cada vez que re-reviso las cosas en un documento y así no lo tengo que hacer yo y lo hace Copilot, en nuestro caso, revisando pull request, porque si no, se lo decía al equipo el otro día, en, en nuestro caso de One, normalmente teníamos pues unos 30 pull requests pendientes de revisar.

Esta semana, ahora no-- igual tenemos 150, algo así, porque no damos abasto.

¿Y esos son los PMs haciendo pull request?

Bueno, son 20 equipos de producto haciendo, ah, PRs como locos.

Pero para mí es un parte de-- no es partes, es un trabajo de staff developer ahora. Es como-

Sí, sí, sí

...no podemos permitir más que es contexto tan importante con toda experiencia y con toda la-- esto, ángulo muy ancho de, de revisión de, de todo el ecosistema, vive solo en sus cabezas. Tenemos que extraer esto y poner en un agente y que después podemos multiplicar por todos los equipos.

Yo soy un poco escéptico, ¿eh? De esto, que exista la capacidad de crear un revisor de-- para cualquier cosa.

Para cualquier cosa no, pero tú puedes llegar a esa capacidad.

Pero y eso no es lo que ya es. O sea, tú pones varios agentes a revisar distintos, sin contexto, con contexto, con-- ¿no? Y los pones a, a revisar el, el pull request, ¿no encontrarán problemas? Con un conocimiento mucho más universal, ¿no? Y mucho más completo

Pero universal. Tiene que ser el contexto de Factorial, ¿no?

Claro, el agent empieza con un pull request y acaba, y, eh, por eso me refería antes de que no hemos... nos falta este tooling de tener este contexto, esta memoria. El agent no se acuerda que ya ha revisado otro pull request que era casi igual, pero yo sí.

Bueno, sí se puede acordar, ¿eh?

Pero claro, esa es la cuestión. No hemos, no, lo que dice Miguel, no tenemos el tooling aún, aún de que haya una memoria de revisión de pull request, de un historial de-

O sea, el tema es el conte-- o sea, no solo es el contexto de la memoria, es el contexto de Factorial, porque aquí tenemos un equipo de staff, tenemos que darle esa capacidad a los agentes a que tengan el conocimiento que tiene actualmente nuestro equipo. Y ese cinco, 10 %, ese es ese conocimiento que ellos no tienen realmente, que se enfrentan en la siguiente pull request.

Y eso saldrá, eso es lo, lo que tenemos que revisar manualmente. Vale, o sea, ¿veis imposible la automatización total?

Yo no la veo imposible para nada. Yo creo que, que no conocemos los límites. Es decir, que ahora mismo estamos probando cosas y toda la industria está probando cosas. Y, y estamos muy lejos de saber dónde está ese... lo que decía Edu, de ese 10 % que, que la AI no puede hacer. Yo no sé dónde está ese, ese porcentaje.

Es decir, yo creo que muchas veces cuando pones la lupa, te das cuenta de que lo ha hecho mal porque tenía mal contexto, porque le faltaban cosas, pero es muy difícil de poner la lupa y que te encuentres un caso en el que fundamentalmente no podría haberlo resuelto. Entonces, en ese sentido, es lo que decían ellos de que falta tooling, faltan muchas cosas y está todo muy verde, pero...

¿No pensáis que el humano le pasa un poco igual cuando hace un bug, cuando hace algún fallo? ¿Es porque le falta contexto también?

No todo el mundo es staff cuando empieza, porque no tienes el contexto de, de años de experiencia de ir acumulando y ir aprendiendo, que es la parte que creo que les falta a los agents, este feedback de he revisado diez pull requests que he aprendido en este tiempo. Nuestros... No, digo que nuestros agents no aprenden nada.

Simplemente, van haciendo y ya está.

Pero eso es lo que estamos intentando solucionar. Esa parte ya la tengo bastante avanzada, ¿no? Con todo el tema de, de, de las guidelines, con la parte del agent MD, skills, más cerca del código, también la parte de los dominios, que vamos enriqueciendo. Eh, no es perfecto, ¿no? Eh, pero ahí hemos invertido bastante tiempo y la idea es que tú, una vez defines esa especificación, esa definición funcional del producto, pues a partir de ahí, hasta pull request, sea algo más o menos estándar en Factorial, ¿no?

Que importe un poco, un poco menos quién hace, eh, ese primer paso.

Porque otra cosa que estamos trabajando, y creo que también toda la industria está, está trabajando, es en la in, en la estandarización del prompt a través de specs, ¿no? O sea, crear un, un lenguaje de specs que igual pueda, pueda hablar Joan, ¿no? Y que, y que tú puedes directamente definir qué es lo que esperas que se construya de un, con un lenguaje concreto y que le aplicarán luego unas skills de desarrollo concretas que han hecho los-- la gente más senior de, de la empresa y que es capaz de trasladar la spec en código.

Pero y esa es la historia de la humanidad.

O sea, no creo que sea... Se está acelerando un cambio muy concreto ahora, muy, muy heavy, pero siempre nos ha ido pasando esto.

Hoy el, el cuello de botella, aparte de Edu, de Factorial, ¿qué es? O sea, es porque si todo el mundo puede estar haciendo pull request, ¿no? O sea, entiendo que el hacer el merge, o sea, la revisión de la pull request y llevarse este código a producción, esto es lo que es el cuello de botella, ¿no?

Poder revisar todo este código.

¿No?

No es tanto el revisar, es asegurarse de que funciona. O sea, yo...

Eso es revisar, ¿no?

No, porque tú puedes revisar algo y que luego no funcione.

No es un análisis sintáctico y ya está.

No, pero al final es un sello de: yo, si algo falla, voy a ser yo el que lo va a arreglar, ¿no? No es solo revisar. Si tú cuando creas una PR, si lo crea, eh, un PM, cuando eso falla en producción

Va a tener que arreglarlo una persona. Si el PM no tiene las skills para arreglarlo

Por eso, para mí un cuello de botella no e-- co-- no es revisión per se, es un síntoma. Pero el problema es que no tenemos a veces tan claro qué es bueno, qué es malo. Estas definiciones de standards, que un par de tocaría Miguel, es, es así, pero no es solo skills, no es solo agents. Es también todos los abstracciones, todos los infraestructura, todos los, ah, estas cosas de framework que normalmente gente está haciendo, porque agents está aprendiendo de datos de contexto de texto, pero también de otro código que está por ahí, por ahí.

Y si ven un montón de, de cosas no tan estructuradas, van a repetir estas cosas no tan estructuradas. Por eso voy a repetir: trabajo de un ingeniero ahora es ver esos patrones y después hacer esto más fácil para una gente encontrar un camino correcto.

Y tam-

Sí, claro, revisión es una parte como tú sacas esto

Pero también el PM es como el nuevo junior, ¿no? Es decir, hace hasta do-- hace, hace hasta donde... No, es que era mi sensación, ¿eh? Eh, el PM hace hasta donde le llega la comprensión de lo que puede hacer, tanto del problema como del-- el código en el que se materializa. Lo lee y dice: "High level, esto está guay". ¿Sabes?

El junior igual. Y luego tú lo revisas y, y haces un back and forth. Pero nuestro lo-- nuestra responsabilidad es un acompañamiento para que la siguiente PR que meta el PM, igual que si fuera un junior, sea mejor, sea más atómica, sea más semántica, sea- Yo eso es lo que creo, que es que últimamente, eh, todos volvemos a ser juniors.

Sí, totalmente

O sea, no es solo el PM. Es que se dice, por ejemplo, que los LLM son como junior programmers.

No

Se dice que, que los PM son juniors, pero que nosotros también somos juniors porque estamos en esta transición de software tradicional a software 2.0, donde son prompts.

Exacto.

Y nosotros no llevamos diez años haciendo prompts, llevamos diez años haciendo, eh, software, eh-

Sí

...con código. Entonces, eh, nosotros tampoco somos tan buenos necesariamente haciendo prompts. Entonces, también, eh, está la pregunta de quién nos revisa a nosotros. Es decir, al final también somos juniors nosotros.

Sí, sí, totalmente

Sí, sí, totalmente.

Depende del junior, ¿eh? Pero sí, sí, el, el, el bueno.

Eso es.

Este para mí es el ma-- el mayor challenge que le haría a Oriol y a Edu, ¿no? Que, mmm, vosotros valoráis mucho los años de experiencia, y lo entiendo, porque al final hay una serie de, de conceptos que hay que entender, cómo funciona Internet, cómo funcionan los protocolos HTTP, cómo funcionan las di-diferentes capas de una aplicación, la base de datos. O sea, son cosas que requiere tiempo.

Sin embargo, lo que dice Miguel, ha cambiado tanto el mundo que una persona que nace ya en este mundo y se mueve de forma natural en este mundo, igual no tiene todos los strings attached, ¿no? De esa sensación de control, esa... Es como, como una persona que era muy senior en assembler. Dices: "Está muy bien que seas muy, muy, muy bueno en assembler, tío, pero es que estamos haciendo Ruby aquí", ¿sabes?

Entonces, dónde colocar el puntero o la memoria o no sé qué, igual no es tan importante como, como l-- diseñar patrones de software a un nivel mucho más alto. Entonces, la experiencia tan buena y tantos años en alguna cosa, igual no, no te sirve en otra cosa. Y la persona que nace ya directamente en este o-- este nuevo patrón...

Fernan

Espera, ahora le pasaré los micrófonos. Este nuevo patrón, pues igual esto no le sirve. Es, es un challenge que os dejo aquí.

Sí, pero-

El junior con AI. El junior proactivo, motivado, autodidacta, que lleva programando también desde los catorce años, como todos los de aquí, pero que no tiene vuestra experiencia.

O sea, lo-- y bueno, se ha repetido muchas veces, el problema nunca había sido generar código. El problema es saber qué código escribir y precisamente detectar esos patrones, ver abstracciones, ver proble-- o sea, pensar en sistemas. Ese es el problema. El generar código, pues ahora tenemos una manera increíblemente rápida de s-- de generar código y no tenemos que escribirlo nosotros.

La velocidad de iteración. Dices: "El problema no era generar código", pero la capacidad de te-- de, de iteración que tienes ahora, el chip and look, ¿cuándo ha parado? ¿Cuántas veces eres capaz de iterar en una semana? ¿Y cuántas eras capaz de, de hacerlo hace tres años?

Te lo compro, pero lo que me refiero es, o sea, lo que valora los años de experiencia es no saber que el Standard Library de Ruby, pues vale, felicidades Ah, irás más rápido antes, pero lo interesante es, es pensar en sistemas y eso es más-- seguramente ahora se aprende mucho más rápido.

O sea, lo que antes igual tardabas diez años, pues ahora en dos quizá o tres lo puedes aprender. Es la, la diferencia.

Sí, pero lo que te quiero decir es que los sistemas ahora son igual otro tipo de sistemas, son ecosistemas, digamos, ¿no? Más que cada módulo, cada clase que hacen, ¿no? O sea, te preocupa más cuáles son las lógicas de negocio, cómo se comunican entre ellas.

Eso ya era así antes. O sea-

Sí.

Yo nunca reviso p-- línea por-- o sea, ya antes de la AI no revisaba línea por línea. O sea, tú revisas módulos, abstracciones, eh, ideas, eh-

Es que i-idea decía de cómo-- de explicar cómo revisamos por request. No lo-- o sea, no sé explicar. Yo lo leo así en diagonal y, y a veces leyendo ves, y ves algo raro, y cuando ves algo raro sí que te pones a leer exactamente qué es eso. Pero es eso, no-nunca hemos... Si tuviéramos que revisar todo línea por línea, bueno, estaríamos-

Y ahora esa, esa intuición de leer en diagonal y tal conviértela en skill. Good luck.

No, no es good luck. Al final, si tú piensas bien y si tú-- pero tienes que gastar tokens mentales, tokens menta-

Sacar un consejo

...exactamente para extraer esto a un skill. ¿Por qué es para ti es un raro? ¿Qué tú desencuen-- estás encontrando? Ah, un-

Sí, esto concretamente, pero luego la otra cosa y luego otra cosa.

Pero, vale, pero es que cómo tú estás explicando.

Al final tu cerebro es un LLM que está infiriendo.

Sí, sí. Pero al final valor de esta experiencia es tu contexto. Exacto. Contexto. Es el valor de tu experiencia. Cómo tú puedes-

Es un contexto para el ejemplo.

De toda tu vida, ¿eh? Escribe una-- un markdown con tu vida.

Bueno, hacemos mucho compaction.

Entonces igual tengo que cobrar.

A lo largo de los años hacemos mucho compaction.

Igual hay que cobrar comisión en las skills entonces.

Propiedad intelectual. Hay gente que habla de eso.

Y luego no es tu vida. Yo a veces veo una PR y digo: "Vale, esta que la revise Oriol también". Porque hay cosas-

Ah, y así cómo desbloqueas.

Hay cosas que yo sé que no s-- no, no llego hasta ahí. O sea, quiero que la ve Oriol, ¿no? Eh, con la gente no, o sea, la gente todos son iguales. No, no, no hacen este handover de: "Vale, quiero que la revise un humano". No.

Les ponemos un soul MD, les ponemos un soul MD y llegas hasta aquí tú y ya está también.

Por favor

Pero ahí hay un, una base, ¿no? O sea, ¿por qué un niño de ocho años no puede escribir una feature hoy en Factorial? Es, o sea...

Espera, espera.

Va a escribir un prompt y va, y va a generar un código que va a tener sentido y seguramente funcione. O sea, ¿qué, qué es lo que aporta un senior, un PM, un designer?

Pero voy a hacer también un challenge que no es solo es de caso de rol, que tú tienes juniors, eh, disruptores, staffs haciendo mu-mucho pensamiento. Yo he visto personas por todos los lados diferentes.

He visto juniors generando un valor brutal y staffs, bueno, no tanto.

Pero por otra parte hay staffs que han generado un valor brutal. O sea, es decir, el fundador de-- el fundador no, el creador de Cloud Code, ¿no? Que es, eh, es, es-- no es staff, es más que staff. Y, y fue él el que creó, no fue un junior.

Sí, distinguished engineer. Y no fue, no fue, no fue un junior el que lo hizo. ¿Por qué no fue un junior?

Bueno, a ver, por eso estamos diciendo que depende del personal, que no puedes poner solo por rol esta persona.

Claro, pero es que yo creo que si tú sumas motivación, energía, que a veces la gente de veinte años quieres que al menos sea una ge-- sea gente apasionada, energía, motivación, actitud a tope, ¿no? No siempre es así, ¿eh? Entonces esto es un problema.

Pero un niño también tiene eso.

Joder. Que te vas al otro extremo.

Claro, pero para entender lo que he dicho, ¿no?

Veinte años he dicho, de los veinte a los treinta.

Está demostrado que conforme vas madurando vas perdiendo creatividad, ¿no? O sea, la lógica te lleva a que un niño de ocho años va a pensar así.

Pues ahí voy, ¿no? ¿Por qué no?

No es legal.

Más allá de la legalidad, vamos.

Temas menores.

¿Y era staff el niño de diez años?

Ni en Factorial, ¿eh?

Te he puesto el ejemplo, ¿eh? El ejemplo extremo.

No, lo puse, lo puse exactamente por esto, porque lo, lo que aporta, o sea, tienes que ver cuál es el valor diferencial que aporta. Si es creatividad, entonces un niño aporta creatividad.

A ver, pero es que hay, hay grandes escritores, grandes científicos, grandes todo Que han creado su obra mayor con veinte años.

Sí.

Y luego no han hecho nada. O sea, que, que una cosa no implica la otra.

Sí, pero en general que, o sea-

En, en general

...en general, vamos-

La experiencia sirve, sí, claro que sí

Pero al mismo tiempo te va generando una serie de restricciones, ¿no? Por, por el contexto-

Bueno, te va volviendo más conservador, igual menos creativo, ¿no? Sabes más lo que no funciona, tienes más miedo, ¿no? Todo esto puede ser, ¿no?

Totalmente. Sí, pero también-- o sea, me refiero a que es, es en general comportamiento humano.

Claro.

Más faltaría si los jóvenes no están haciendo disrupción y liándola parda, es su función. Si no, no sé, no sé-

Y tu función es revisarles las misiones.

No, mi función es, es quedarme mirando y decir: "Bueno, pues ya se me entera la hostia". No pasa nada. Así se, se aprende a-- como todos, pero al final también lo de ser disruptivo, ¿no? Yo creo que es más una actitud que una cosa de edad. Obviamente, afecta la edad y-- pero creo que va más con la energía. Sí, igual cuando eres joven puedes ser disruptivo en diez cosas a la vez y yo ahora, pues con dos ya me estoy contento.

Hombre, aquí hay mucha gente disruptiva-

Ah, eso es una, es una parte interesante

...que no es junior, ¿no? Exacto. Sí, sí. En, en este, en estos momentos aquí, ¿no?

¿El qué, qué, qué?

Que mucha gente es disruptiva aquí que no son juniors.

No, claro.

Pues me-- creo que es más una actitud-

En estas mesas concretamente también, por ejemplo. Tú ibas a decir algo.

Ah, esto es interesante. O sea, hemos hablado del cuello de botella, el-- revisión del código, aunque vamos automatizándolo y cada día vamos mejorando en eso. Otro es la capacidad de paralelizar.

Totalmente.

¿No? Hacer varias-- la pantalla esa de, del Steve-- Steinbergers, no, del de Cloud Code. Ay, el de Cloud Code, del de...

Open Cloud

...Open Cloud, eh, que tiene como cincuenta pantallas ahí, ¿no? Y está haciendo como un millón de cosas a la vez, que dices: "Y yo sería incapaz". O sea, con un cuarto de estas pantallas ya me perdería, ¿no?

Entonces, la capacidad de paralelizar y lo otro es la-- el tiempo que, que tarda el modelo en darte una respuesta.

Eso es-- porque hay muchas veces que estamos así, ¿no?

Bueno, aprovechas para lanzar otra cosa mientras- O para caminar.

Es el momento, es el momento para paralizar.

Es una oportunidad.

O sea, es una feature, el tiempo. El tiempo que tardes es una feature, es algo bueno.

¿Y no sentís que lleváis la neurona al máximo-

Sí

...en estos momentos?

O sea, que estamos viendo la capacidad del ser humano ahí al límite, límite, mientras tenemos todos estos procesos en paralelo.

Porque te haces mucho, mucho focus shift, que siempre si estamos hablando de paralelizar agentes, significa que hay N features o N ideas que tú estás atacando en paralelo. Por eso, si quieres hacer esto bien, tú tienes que como mínimo tener este imagen en tu cabeza. A dónde vamos, cuál es la idea, cómo-- cuáles son límites.

Si multiplicas por tres o cuatro, mira, tú vas al límite. Y después tú tienes esto en tu móvil, tú también estás paseando y es que tienes-

¿Quién tiene el móvil aquí, el despacho este? ¿Sí?

No despacho. Pringado. Otra cosa, pero no.

O sea, yo eso ya con Ilia normalmente lo ves distraído y cuando hablo con Ilia, pues está como mil cosas, está pensando mucho. Pero es que ahora está con el puto móvil, con varias pantallas en paralelo, si es que no puede tener una conversación con foco, ¿no? O sea, a todos nos pasa un poco lo mismo.

Es genial eso. E-esto del foco- Es genial ...seguro la, la cosa esta mística de, de programador, de que estás en el flow y estás ultra concentrado y no te das cuenta que han pasado tres horas, diría que ha desaparecido. Porque-

¿Sí?

Sí.

Bueno, a mí me desaparecen las seis horas. Lo que pasa que en lugar de estar, o sea, mi f-flow es paralelizar.

Sí, exacto. Pero no estás, eh-

No estás en una cosa

...concentrado en un problema-

No

...durante mucho rato. Es constantemente ir saltando de problema en problema.

Sí, sí. Por eso es como a ve-- a veces me-- a mí, yo, yo saqué ideas cuando, pues estoy paseando. Es como en el background, tú estás pensando de cosa y tu agente está verificando este-- tu idea. Sí, sí. Normalmente, las mejores ideas no son cuando estás en el ordenador, es cuando estás paseando o haciendo otras cosas.

Sí, totalmente.

Bueno, de hecho, de hecho existe esa, esa vista, ¿no? De poder jugar como al StarCraft si estás controlando a agentes.

No lo he probado todavía, pero ya-

Es la leche.

Pero Gastown no es un poco de eso.

No. Es lo contrario.

No mistakes

Gracias, gracias. Porque vosotros os descojonáis mucho de, de mi, de mi visión de la RR, que, que yo lo entiendo, lo entiendo. Pero claro-

...aquí-- no, no, no, pero, pero es que aquí el tema de cuando pensáis en pen-- en pensar el problema, eh, lo que muchas veces no le dais tanta importancia vosotros es, es que es: de dónde viene esta tarea, el porqué Estamos haciendo todo lo que estamos-- o sea, eh, eh, todo este motion de trabajo, este dominio, este producto, ¿no? O sea, de-- ¿por qué lo estamos haciendo?

Y al final es: alguien tiene que hacer esto, ¿no? Que es lo que hace Joan, ¿eh? O sea, Joan va a ver gente, va a ver a clientes, en-- se genera una hipótesis. Hace un poco pareci-- un proceso parecido en otro dominio de, de problemática, ¿no? De-- que, y que al final tiene que acabar en solucionar un problema. ¿Y cómo lo medimos? ¿Cuál es el heurístico? En ARR. Pero lo importante realmente no es el ARR.

Lo, lo importante es que estamos solucionando problemas a peña y que no estamos en nuestra cueva ahí, pues, mmm, creyéndonos nuestras tecnologías y estar todo el día jugando sin que sirva para algo. El concepto de servir es tan importante como el concepto de que no rompa el abstracción o que no duplique no sé qué o que no, no sé, ¿sabes? O sea, y, y a veces no le damos tanta importancia a esto.

No, pero aquí estamos de acuerdo todos contigo, ¿no?

Bueno, no lo sé, no lo sé. Mucha coña me, me metéis con el tema de la ARR.

Bueno, pero es fácil, pero al final yo creo que-

Ya lo sé.

...todos los ingenieros lo que te gusta es resolver problemas.

Claro.

Es-

Claro, pero ¿en qué tipo de problema? ¿Qué tipo de problema? O sea, porque el problema, ¿cuál es? ¿El problema es construir algo? Pero, ¿ya, ya alguien ha decidido que hay que construir algo? ¿O el problema es-

No, o sea-

...previo a construir algo?

Para mí la, la mejor manera-- o sea, yo siempre lo que quiero es no trabajar. Con lo cual- ...no trabajar me refiero cómo poder solucionar este problema con el mínimo esfuerzo, ¿no? Y ya está.

Vale, pero-

Exacto. ¿Dónde está el problema?

Pero la gran diferencia-

Una cosa no, no cambia la otra. O sea, el, el-- por ejemplo, en, en Expense, es que a Bernat o Elio o a Miguel les pasa. El-- o sea, el-- hay-- el problema es: hay como-- hay que controlar cuántas cosas, ah, se gastan y que la gente no se pase. La solución mala es decir: "Pues que lo aprueben", porque ya, ya he solucionado.

Ahora ellos van en el inbox, tienen chorrocientas mil cosas ahí pendientes de aprobar y no le has solucionado el problema.

A eso me refiero con no trabajar. O sea, yo que qui-- y, y hacer la-

Pero es más complicado que eso, Uri. O sea, es más complicado. Pues dices: "Que lo aprueben". Vale, igual está de acuerdo el CFO, eh, de la empresa, porque dice: "Fricción, fricción. Van a pa-- van a gastar menos", ¿sabes? O igual es diferente si hablas con el mánager o con el CEO o con el... ¿sabes? Al final es, es un sistema también la empresa y tú tienes que mirártelo desde arriba y pensar: "A ver, ¿cómo generamos valor en todo este sistema, eh, que más o menos deje contentos a todo el mundo y que al final sea un net positive, no?

Y eso es lo que hace Joan. ¿Eh? O sea, y, y, y co-- y al final tiene que ser un net positive, porque si no es un net positive nadie va a pagar por ello, ¿no?

Pero a lo que me refiero es que un ingeniero que no tiene esta vista, para mí no es un buen ingeniero.

Pero no está expuesto, ¿eh? El ingeniero a, a, a este tipo de problema. O sea, el ingeniero parte de que alguien le ha dicho: "Hay que construir esto". Y entonces dice: "Vale, vale, hay que construir esto, vamos a ver cómo lo construyo".

Yo espero-

Exacto, al fin y al cabo.

Y eso en el mundo ideal, es el mundo ideal y es el-- la realidad de muchos equipos de Factorial, pero también hay equipos que no. Y en cualquier caso, siempre pasa que el ingeniero está menos expuesto. De una forma obvia y natural va a estar menos expuesto al problema. Entonces, va a pasar un momento que el PM o quien sea, que está cerca del mercado y se da cuenta que, ostras, esto ya no es una solución, y va a volver y va a decir: "¿Sabes qué?

Esto no", ¿no? Y el ingeniero, algún ingeniero, no digo los de esta mesa, ¿vale? Pero algún ingeniero va a decir: "Joder, pero me ha-- me han vuelto a cambiar lo que tengo que hacer otra vez, me han vuelto a cambiar la-- el mundo otra vez", ¿no? Y, y esta frustración de ir encontrando el problema, construir lo mínimo para validar, ¿sabes? Este proceso iterativo, pues es la magia.

O va, va, va a pasar otra cosa, que PM va a en-- ahora a tener claro que mira, si esto genera tanta frustración, porque yo no puedo generar lo mismo con Cod code o con otra, otra herramienta.

Claro.

Sí, y en algún momento la pregunta es: ¿y por qué necesito entonces este ingeniero si no me aporta nada excepto tocar código?

En el mercado

Totalmente.

El, el Spiderman, ¿no? Donde el designer, el PM y el engineer están en plan: «I don't need you anymore» . Pues, pues sí, pues un poco sí. Y a, y a la par de que quien para mí el perfil que emerge de aquí es un perfil mucho más polivalente, un perfil de, no sé, le podemos llamar builder, me da igual, ¿no?

Product maker que teníamos antes.

Product maker. Sí, ¿no? Un perfil mucho más polivalente, que son los, son los, los teams interesantes siempre han sido estos, en realidad. Para qué nos vamos a engañar.

A lo que iba antes es: ahora hemos aplicado AI mucho en la parte de generar código, pero es lo que dice Miguel: ¿por qué no le pasamos las transcripciones de todos los account managers con varios clientes de la misma industry?

Estamos en esto.

Y a partir de aquí podemos facilitar el trabajo de Joan, porque en lugar de tener que estar mirando ir a diez reuniones con todos los account managers o leer los transcripts-

Esto me encanta, me encanta. Claro que sí

...hago que un agent especializado en encontrar-

Esta Valeria, esta Valeria haciendo esto.

Pues mira, ahora está.

Esto lo tengo yo hecho.

Lo tengo enfocado mucho a la parte de, de programación, pero es, es que aplica a todo.

Y una, una reflexión que me gustaría haceros, porque aquí estamos hablando de construir código con agentes. Hasta ahora casi todo lo que hemos estado hablando es construir código con agentes. Pero claro, construir código sigue siendo el paradigma antiguo, desde mi punto de vista, ¿vale? Que esto me diréis: «¡Ah!» Pero bueno, dentro de un año igual, eh.

Que yo creo que lo que en el punto donde estamos ahora es en construir AI as a service, es decir, en facilitar la AI y llevarla cerca de nuestros clientes. De forma que, eh, ya no es tan relevante igual escribir código, sino crear un ecosistema donde el que escribe el código es nuestro cliente.

Al vuelo.

¿Y por qué quiere escribir código el cliente?

Bueno, normalmente los clientes lo que quieren es programar menos. Me voy a explicar mejor, porque no me estoy explicando. Eh, no es que quiera escribir código, es que quiere resolver su problema. Y su problema es una casuística del long tail infinito de problemas que existe en el mundo. Entonces, el problema del código en general que tiene es que como es determinístico, como, como llega al-- como es un if then else, tienes que tener el if, tienes que tener la casuística considerada a priori.

Reconocida.

Claro. Entonces, esto te limita, porque implica, como ingeniero, pensar en todos los problemas del mundo. Y ya no solo los problemas, sino cómo construirlos y cómo adaptarlos según las abstracciones. Pues todo lo que hemos dicho, ¿no? Vale, ahora imagínate que nosotros, que es lo que estamos haciendo en Factorial, eh, o sea, no sé por qué te sorprende. Hacemos una IaaS service de forma que el cliente, por ejemplo, escribe código, no en lenguaje de código, sino en policies, por ejemplo, ¿no?

Que es la abstracción que tenemos en Factorial. En un lenguaje pseudocódigo o directamente lenguaje, absolutamente lenguaje natural, con ciertas restricciones, donde, eh, esto se convierte al vuelo, al vuelo en tiempo de ejecución, en código, ¿no? Em, y esto es otro paradigma.

Esto es lo que estoy viendo en mi observación hablando con muchos ingenieros, es que cuesta mucho ceder esta, este control a un agente que va luego a escribir el código por nosotros. ¿Cómo lo veis esto? ¿O no? ¿O estoy diciendo tonterías?

No, yo creo que no, que, que tiene sentido y hace unos días o semanas que pienso que ahora lo importante que tenemos que invertir es, no es tanto en hacer features o cosas así, sino en cosas que sean building blocks, cosas core para que, para, para precisamente hacer esto. Que alguien, ah, bueno, alguien no, un a-- un agent puede componer una interfaz, una solución con todas-- es como: «Mira, aquí tienes todo un paquete de herramientas que te damos.

Espabílate para solucionar los problemas del, del usuario». O sea, que ya no tiene sentido muchas veces hacer una pantalla con: «Yo he decidido que aquí hay un listado de empleados, que cuando le das a este botón se te abre un side panel y te muestro esta información». Pero es muy difícil que un agent puede hacer una pantalla autogenerada sin unos componentes, por decir de alguna manera.

Y coherencia, porque no te vale que te vayas a una página y tenga una pinta, te vayas a la siguiente y sea una aplicación distinta, y entres mañana y sea una aplicación distinta otra vez, ¿no?

Coherencia visual de experiencia, ¿no? Design system de componentes, eh, pensados previamente. Miguel, ¿tú qué piensas de esto?

¿Pero cuál es el 2.0?

Pero y esto lo, lo hace una empresa para, para ellos mismos

Pero co-- pero software para otros o para ellos mismos. O sea, tú estás diciendo que las empresas van a solucionar sus propios problemas ¿haciendo prompts?

Vale. Bueno, sí

Yo estoy de acuerdo. Y, y ahí es donde el challenge del junior, ¿eh? O sea, el challenge del junior no es tanto en, eh, va a aprender a programar o con, con cod-- con agentes de código. Es va a nacer en un paradigma donde ya no hay código, digamos. O sea, hay prompts y hay muchas capas que para nosotros han sido muy importantes y que hoy se dan por sentadas.

¿Sabes? Y alguien que nace ya en este mundo se mueve más rápido en este mundo. O sea, no lo sé

¿Qué es Talos?

Adrià, ¿tú qué piensas?

Del, del debate de los juniors, por ejemplo. O de, o del, o del software hecho con prompts y no con código

Yo, yo te hago challenge a que sea más caro, ¿eh? Porque, o sea, depende cuándo se ejecuta el prompt. Si el prompt se ejecuta cada ejecución, cada instancia, es carísimo. Si el, si los prompts se ejecutan cada vez que se cambia la configuración, entonces no es tan caro, ¿no? Depende cuándo se, cuándo esté pensado ejecutar los prompts, ¿no?

No, no, no, no, porque puedes configurarlo con prompts

Pero luego se te genera un workflow. Eventualmente se genera. O sea, Claude lo que hace, Claude escribe código para responder

Es que vas concretando

30 años inventado y siguen guardando todo en papel, siguen guardando todo en tickets, eh, y estamos en 2026, ¿no? Entonces, estamos diciendo: en dos años, todas estas empresas que siguen guardando todo en papel-

Van a pasar a usar agentes, a, eh, confiar en un agente, a usar tooling en online o va a ser una transición más larga, ¿no?

El timing es lo más, mmm, jodido de saber, pero es lo más importante, porque todos sabemos que en el largo plazo hay AGI. La pregunta es: ¿qué va a pasar mañana?

Supongo somos nosotros los primeros.

Es AGI. Es esta misma.

No, dime eso.

Es lo que tiene estar en permanente fundraising, tío. Hay que estar diciendo muchas cosas. Oye, tú, déjame el micro un momento, que voy a preguntar a Ferran. Podemos girar aquí la cámara. No sé por qué he escondido aquí Ferran. Ferran, eh, una pregunta: tú llevas, eh, en Factorial, eres el empleado más antiguo de Factorial actualmente, ¿vale?

Eres el empleado más pionero de Factorial. Tú has visto centenares de desarrolladores pasar por Factorial.

Entonces, en este debate de, de, de cuál es el perfil, eh, que funciona en Factorial: junior, senior, staff, mid, eh, no sé qué, ¿qué, qué, qué ves tú? ¿Qué piensas ahí? Te he visto antes hacer caras, por eso digo: te voy a pasar el micro.

¿Crees que, eh, la arquitectura de Factorial-- tú llevas DX, que es developer experience. ¿Qué es developer experience? ¿Puedes explicarlo para la gente? Por favor, por favor, que la gente no entenderá. Y de paso me sirve a mí. Es broma.

Ferran, ¿tú crees que se va a poder automatizar, eh, tirar código?

De la assembler.

Oye, me gustaría tocar algunos temas más antes de irnos. Eh, futuro del open source. Miguel o Jacob.

Por decir nombres, ¿eh?

¿Qué es Pencil?

Pero al ser tan fácil escribir código, ¿no tiene más sentido trabajar en los agentes, en las capabilities de los agentes y que los agentes creen las librerías, las soluciones que necesites, en lugar de ir a una librería cada vez más grande de, de soluciones open source, que buena suerte encontrando lo que tú buscas?

Ya, pero cuando hay tanto, ¿es útil?

Eh, librerías que hace gente. Cuando puedes hacer una a un coste muy bajo.

Ya.

Ya, pero cuando hay tanta competencia desapare-- o sea, desaparecen los mercados hasta cierto punto, ¿no? Cuando se atomiza tanto.

Tú dirías es que no con la cabeza.

Ya, pero la gracia era tener un pool de, de desarrolladores que es todo el mundo, ¿no?

Bueno, es la gracia que, que luego como derivado-

...se convertía en canal de distribución

Eso es hasta hoy.

Pero la pregunta es a partir de hoy, ¿eh? O sea, ¿cómo se van a producir estas, estas concentraciones marginales de-

...de soluciones?

Vale. Eh, AutoResearch, quería preguntaros, ¿alguien, alguien ha utilizado AutoResearch?

AutoResearch es un, un repositorio que ha publicado Carpathe, ¿no?

Como que, como, como que ha inventado la piedra filosofal. Igual, igual no es tan piedra filosofal, pero...

Pero es una tarea como mejora la performance de este proceso. No le puedes-

No le puedes decir lo que he dicho antes, eh-

Bueno, no está optimizado para nada. Simplemente va experimentando todo lo que hay en la-- en el mundo, ¿no?

No, pero cómo tú MRR, cómo tú puedes-- vas a medir MRR con el feedback loop. Necesitas esperar un poco.

Sí.

Igual consigue, pero igual tarda más que nosotros.

Sí.

Chao, Miguel.

Vale.

Que no es para que se revisen.

Vale. Oye, eh, Edu, espera, te devuelvo el micro. Em, he visto que has publicado en LinkedIn-

Oh, no.

Un orques- Un orquestrador. Eh, ¿por qué has hecho un orquestrador?

Para-

¿Qué hace?

Bueno, es básicamente correr agentes y lo que quería es entender cómo funcionan los agentes. O sea, este cinco por ciento, cuando yo le doy una tarea y sale mal, yo quiero que salga bien y quiero tener control sobre el-- las decisiones que va tomando el agente, ¿no? Ya decía Oriol antes: eh, yo no reviso el código en GitHub porque el feedback loop es demasiado, eh, largo, porque tengo que revisar el código.

Yo quiero no tener que revisar el código. Si yo, mientras va tomando decisiones, veo las decisiones que los agentes van tomando, no necesito que termine de generar el código para saber que va a generar algo bien o va a generar algo mal. Entonces, la idea de este orquestador es que me vaya diciendo todo el tiempo lo-- su proceso mental y yo poder ir guiándolo, eh, en esto.

Pero bueno, pues es, es un experimento para, sobre todo para aprender cómo, dónde están los límites, ¿no? La, la idea inicial era: con un agente muy tonto quiero poder llegar a hacer lo que un-- hace un agente más listo. Y aprendí que no, no es posible, porque hay un, un baseline, ¿no? Un mínimo que necesitas.

Eh, un agente muy tonto no hace tool calls con un ratio suficiente como para que cuando los corres durante un loop muy largo, va componiendo el error y acaba en cosas que, que no te puedes fiar, ¿no? Entonces, el, el mínimo ahora mismo es estos modelos nuevos, ¿no? El cuatro seis y el cinco cuatro, que puedes correr durante mucho tiempo y se van como autocorrigiendo cuando cometen errores en vez de irse estropeando cada vez más, más rápido, ¿no?

Vale. Oye, última pregunta para Miguel. Eh, ah, tienes micro, ¿no? Vale. Eh, no, te iba a preguntar, Miguel, s-- cuando está cambiando todo tanto, eh, cada equipo te viene con: "Hostia, he probado la última no sé qué". ¿Ves? ¿Cómo, cómo decidimos en Factorial de: "Mira, esto se va a convertir en el estándar a partir de ahora.

A partir de ahora todo el mundo va, o sea, va a ir subiendo la barra, ¿no? Esto se va a convertir en el mínimo". ¿Cuándo tomamos o tomas, eh, esta decisión de decir: "Esto, todos los equipos, ahora, venga, engineering managers, eh, directores, eh, a, a conseguir esto ahora"?

O sea, primero es que es una decisión conjunta, la tomamos. Em, siempre hay alguien que, que empieza punta de lanza, ¿no? O hacen de disruptor. Generalmente, es Iliá. Después tenemos ahí a Jacob y bueno, un conjunto de personas que van ahí, em, pues haciendo auto research.

Y dentro de todo eso-

Auto research o research sin auto.

Y dentro de todo eso, eh, uno, tenemos que mantener la calma, ¿no? Porque hay personas que avanzan muy rápido-

Claro, claro

...pero después estandarizar eso, eh, no es tan sencillo, porque yo, por ejemplo, veo a Iliá, pero Iliá muchas de las cosas que hace son instinto. Tira por aquí, por allá, hostia qué rápido hemos ido. Y claro, cuando queremos estandarizar tenemos que frenar un poco. Ahí entra el equipo de DX.

Eso es lo que quería aquí, eh, dis-- destilar tu skill, que también tienes que acabar poniendo en un markdown, de qué, qué, qué-- cuál es el momento o cuál es el, el signo que tú ves de decir: "Vale, esto, esto sí, está testeado. ¿Por qué ahora sí y por qué no?"

La verdad es que solo puedo explicarlo con ejemplos, porque, em, yo creo que siempre he tenido esa capacidad de ver el camino, ¿no? O sea, de, de ver el camino claro de cuáles son los pasos que tenemos que seguir, ¿no? No soy tan bueno haciendo ese research, que Iliá en eso es un, un crack, un fenómeno, pero sí veo las señales de hacia dónde tenemos que ir, ¿no?

Entonces, em, se hizo un trabajo mucho de research el año pasado. A principio de este año hicimos ese cambio cultural, eh, pues radical, ¿no? En el que trajimos al equipo, lo hemos contado varias veces, le pusimos a un objetivo de un día una serie de iniciativas, eh, que llevaban meses y cero código.

Nuestros mejores equipos lo hicieron en esa tarde. Ahí no estandarizamos nada. Ahí simple pusimos-- simplemente pusimos unas guías para que la gente empezara a experimentar. Eso, eh, abrió la mente y toda la gente empe-empezó a experimentar. Y durante las siguientes dos semanas, ahí encontramos el camino de: oye, cuáles son los puntos, porque hay siempre diferentes vectores de ataque, ¿no?

Cada equipo tiene, eh, tiene uno en particular. Encontramos el, el-- este punto común, ¿no? Donde convergía todo el mundo. Y ese fue el momento en el que podemos-- pudimos empezar a estandarizar. Y ahí es cuando llegó el equipo de, de DX, ¿no? Ahí vino, eh, Ferran y, y David y Ole, todo este equipo que, que tenemos, que es maravilloso, y, em

Pero una cosa que sí que es brutal es, eh, realmente ha habido una transformación como nunca he visto en los últimos meses en el equipo de Factorial. Eh, hemos cambiado la forma de pro-- de generar, eh, soluciones a problemas, ¿no? Y de trabajar conjuntamente. Creo que hay un momentum, eh, superinteresante y, y algo está pasando que muchas empresas nos están pidiendo que, que les hagamos workshops de cómo hemos hecho el, el cambio, ¿no?

Y cómo estamos, eh, construyendo producto a día de hoy, ¿no? Aunque realmente es algo que cambia, que como hemos visto en esa discusión, ¿no? Sigue cambiando, ¿no? Constantemente.

Es que no es obvio, ¿eh? O sea, el tema de pasar a confiar en otro agente externo a ti, externo a la empresa, que va a tomar las decisiones más críticas. Con human in the loop, sin human in the loop, es igual, eh, pero decisiones críticas por nosotros, pues como ingenieros, es un poco antiintuitivo.

Oriol, ¿quieres dar alguna última novedad de One?

Antes de cerrar. ¿Algún, algún highlight, algún breakthrough?

Ves, el vender.

Esto, hablando de ceder el control o aceptar el indeterminismo en tu vida, nunca me había pasado en la vida que voy a ver un cliente. Ayer fui a ver un cliente en Madrid, eh, y tal, eh, y claro, dicen: "Bueno, quiero probar mi prompt", ¿no? Y es aquí donde dices: "¿Seguro, seguro que no quieres el mío?" No, no, vamos a probar qué quieres, ¿no?

Y cuando tú ves que te pide lo más remoto que se te ocurra y de golpe One le pinta un dashboard exactamente como si le lle-- le leyera el cerebro, eh, con todo lo que está pe-- todo lo que está pidiendo, con el gráfico, con la evolución, con no sé, con las métricas principales, la gente flipa. Y yo pri-- yo primero.

Yo soy el primero que digo: "¿En serio?" Nunca me había pasado hacer una demo y yo ser el que más flipa mientras voy haciendo la demo. O sea que esto, brutal. Muy bien. Pues nada, chicos, eh, muchísimas gracias. ¿Alguien se ha dejado algo por decir? ¿No? Pues gracias a todos, eh, y con los demás, hasta la semana que viene.