# Fui por las conversaciones, no por las charlas - Fecha: 1 de octubre de 2026 - Proyecto: talks - Tags: Eventos, Networking, IA > Fui a AI Lat principalmente a conversar sobre los proyectos. Sumamos un contacto para Gemm en Oil & Gas y me llevé ideas de la charla de Santiago Marro sobre contexto, tests y revisión al trabajar con agentes. El 1 de octubre fui a AI Lat, invitado por Axel Abulafia, mi profesor de la materia de Startup de ORT TIC, que también fue speaker y organizador del evento. Fui con Guido Jacofsky, Lucas Waisbaum, Jose Barcelo y Benyi Sagranichne. Llegamos temprano y nos quedamos hasta la tarde. Asistí a pocas charlas: había ido principalmente a conocer gente y conversar. Selfie de cuatro de nosotros entre los asistentes de AI Lat ## Del pitch a la conversación Dos días antes habíamos [presentado Gemm en el Parque de la Innovación](/es/notes/gemm-parque-innovacion). Restoman también venía de [su lanzamiento en Bibi’s](/es/notes/restoman-bibis-launch). Tenía dos proyectos para contar, pero también experiencias recientes que iban más allá de explicar qué hace cada producto. En el Parque de la Innovación habíamos tenido que resumir Gemm en unos minutos, con una presentación preparada y un tiempo acotado. En AI Lat no tenía que meter todo en un pitch. Una conversación permitía detenerse en una parte del proyecto, explicar el problema que queríamos resolver y escuchar qué hacía la otra persona. Me interesaba ese intercambio más que repetir una presentación. Salir del entorno en el que venimos desarrollando los proyectos también sirve para pensarlos desde otro contexto: no solo qué construimos, sino a quién le podría servir y por qué. ## Un contacto más para Gemm en Oil & Gas Gemm ya estaba orientado a Oil & Gas. Teníamos contacto con YPF y habíamos visitado la refinería para conocer las problemáticas del sector. En AI Lat hablé con unos chicos que estaban haciendo una pasantía en una empresa que busca implementar automatizaciones e IA en ese mercado. Les conté sobre Gemm y les interesó el proyecto. No fue un cambio de dirección para Gemm, sino un contacto más que nos sirve para el mercado al que ya apuntábamos. ## Lo que me llevé de la charla de Santiago Marro También asistí a “Cuando el código lo escriben los agentes”, de Santiago Marro. Me quedé con varias ideas sobre cómo organizar el trabajo con IA, más allá de pedirle que escriba código. Santiago Marro en el escenario, con el título Cuando el código lo escriben los agentes en la pantalla ### Resolver el contexto antes de implementar Una de las recomendaciones era dejar que el agente haga preguntas antes de arrancar y responder con el mayor contexto posible. No esperar a que termine para descubrir que entendió otra cosa. También propuso que, si hay que repetirle la misma aclaración tres veces o más, se convierta en una skill. La instrucción deja de depender de acordarse de escribirla en cada conversación. ### Tests primero, no código de más Otra idea fue pensar cómo se va a probar una feature antes de elegir su implementación: escribir primero los tests y pedir el código mínimo necesario para que pasen. Los tests tienen que cubrir el comportamiento y la lógica de negocio, no solamente que el código compile. Eso también exige revisar los propios tests. Que todo esté en verde no sirve si el agente borró una prueba que fallaba en vez de resolver el problema. ### Features completas y revisión separada Santiago planteó organizar el trabajo por features que funcionen de punta a punta, en lugar de construir capas enormes para integrarlas recién al final. No lo entendí como una prohibición de usar capas: dentro de una feature también puede haberlas. La diferencia está en cómo se divide y se entrega el trabajo. Para revisar, recomendó una sesión nueva, separada de la que generó el código, y PRs y commits pequeños. Cambiar de sesión no garantiza una revisión imparcial, pero evita que toda la revisión dependa del mismo contexto que produjo la implementación. La decisión final sigue siendo humana. ### Medir lo que pasa después de entregar También propuso mirar cuánto código hay que corregir o rehacer durante los 21 días siguientes a una entrega, en vez de medir productividad solo por líneas de código o cantidad de commits. Me llevé esas ideas como criterios para revisar cómo trabajo con agentes, no como un proceso que ya hubiera implementado completo. Generar código es una parte: definir qué tiene que hacer, comprobarlo y revisar lo que se entrega sigue siendo trabajo de ingeniería. ## Volver con algo para los proyectos Me fui con un contacto más para Gemm y varias ideas para revisar cómo trabajo con agentes. Las conversaciones me sirvieron para contar lo que estamos construyendo; la charla de Santiago, para pensar cómo lo construimos. Para Gemm, hablar con gente que busca aplicar automatizaciones e IA en Oil & Gas fue una forma de seguir acercándonos al mercado fuera de nuestro entorno habitual. No era solamente mostrar el robot: importaba también el contexto en el que podría servir. Y para el trabajo con agentes, me quedaron preguntas concretas: ¿está claro qué tiene que hacer una feature antes de pedir su implementación? ¿Los tests prueban ese comportamiento? ¿Estoy mirando cuánto hay que corregir después, o solamente qué tan rápido se generó el código? Eso es lo que fui a buscar a AI Lat: salir un rato del desarrollo, hablar con gente de otros proyectos y volver con algo que pueda llevar al mío. --- Página: https://eitanf.com/es/notes/ai-lat-conversations · English: https://eitanf.com/notes/ai-lat-conversations.md · llms.txt: https://eitanf.com/llms.txt