Marcelo Nuñez preguntó cómo se hacen las reviews adversariales con agentes. Agustín Sánchez explicó que usa una skill que lanza un agente nuevo para revisar lo que hizo otro, con modelo y reglas definidos por proyecto, a veces dentro de un loop; aclaró que consume la cuota normal de la suscripción y no API, que sería caro, y mencionó CodeRabbit o Greptile como alternativas comerciales. Sobre QA, contó que Claude usa el navegador para probar features; Adrian Gamarra señaló que con herramientas sin navegador, como OpenCode, se puede usar Playwright o el agent browser de Vercel. Agustin Ponce de León verifica con navegador y e2e en Playwright, y está reduciendo tests unitarios porque rara vez detectan algo y, cuando fallan, el agente los modifica para que pasen; Leonel Pérez y Leandro Contrera vieron lo mismo. Agustín defendió los unitarios por ser más rápidos que los e2e y propuso indicar en la skill o el prompt que no se alteren tests indebidamente; Iñaki Fernando Lozano mencionó una skill para limpiar tests de baja calidad.
Facundo Padilla preguntó si alguien usaba Kapso, un servicio para enviar mensajes por WhatsApp sobre la API oficial, y si habían tenido cuentas bloqueadas. Lucas Juárez contó que lo usa con tres números conectados en modo coexistencia (el mismo número funcionando con la app y con la API) sin problemas de bloqueo. Facundo explicó que lo evaluaba para su empresa por el cambio de costos de la API de WhatsApp previsto para octubre, con un volumen de unos 40.000 mensajes por mes por línea, y que Kapso ofrecía 100.000 mensajes para tres líneas por 25 USD. Lucas agregó que, si no recordaba mal, cada mensaje excedente se cobra alrededor de 0,002 USD. Un miembro de la comunidad preguntó si convenía frente a Evolution API (una API no oficial) por el riesgo de baneo, y Facundo confirmó que sí, justamente por eso.
Facundo García Martoni anunció que Salvador Juárez se incorporó a su empresa, Macch, como su primer AI Engineer. Contó que lo conoció al escuchar su charla en el último evento de PCN, donde presentó un proyecto de sistema operativo que corre en el navegador, y que después de algunas conversaciones y desafíos técnicos decidió sumarlo. Destacó públicamente que, si no fuera por la comunidad, no lo habría conocido. Leandro Contrera, que también presenció esa charla, valoró que pocas personas se preguntan cómo funcionan los mecanismos internos de un sistema operativo y menos aún implementan uno, lo que demuestra destreza técnica y curiosidad intelectual. Numerosos miembros felicitaron a ambos, y ese mismo día Salvador mergeó su primera PR. El caso quedó como ejemplo concreto de cómo presentar proyectos propios en los eventos de la comunidad puede abrir oportunidades profesionales.
Leandro Contrera pidió recomendaciones de servicios gratuitos para alojar imágenes en la nube y servirlas por URL en producción, estimando unas 300 imágenes de 2 a 3 MB. Leonel Pérez mencionó almacenamiento de objetos tipo S3 y que servicios como Firebase o Supabase lo usan por detrás, todos con plan gratuito. Martin Uslenghi recomendó Cloudflare R2 por su generoso free tier y porque no cobra egreso de datos. Salvador Juárez y Facundo Padilla usan Cloudinary; Padilla destacó sus 50 GB gratuitos y explicó que lo que cobra es el redimensionamiento de imágenes vía su API, por lo que él hace el resize en su propio backend antes de subirlas, y compartió como referencia el código abierto del sitio de otra comunidad. Jeremias Alvarez aclaró que redimensionar sirve para que todas las imágenes queden con tamaños uniformes, y comentó que Supabase le sirvió para proyectos chicos aunque su límite gratuito es bajo (alrededor de 1 GB). Gonzalo Morales advirtió que al superar el free tier de Cloudinary le bloquearon las imágenes, por lo que se pasó a Supabase Storage sin problemas; Marcelo Nuñez también sugirió Supabase Storage por su CDN.
Agustin Ponce de León preguntó si alguien había probado Blacksmith (blacksmith.sh), un servicio de runners más rápidos y económicos para GitHub Actions, porque estaba evaluando migrar los pipelines de su trabajo. Facundo García Martoni contó que Blacksmith estuvo entre sus candidatos cuando dejó los runners de GitHub, pero que finalmente eligió Depot (depot.dev), que le resolvió el problema a bajo costo: en su empresa, el pipeline de integración continua de uno de sus servicios pasó de tardar 53 minutos en GitHub Actions a unos 2 minutos en Depot, gracias al cache de capas de Docker que ofrece. Agustin agradeció la referencia para evaluarla. El intercambio complementa lo conversado días antes sobre el alto costo de los minutos de GitHub Actions cuando se trabaja con agentes que disparan muchos pipelines.
Jeremias Alvarez planteó cómo pasarle a una IA el contexto de un bug de producción que no se reproduce en local, ya que conectar el agente a la base productiva no le parecía buena práctica. Fede Valle usa una copia de la base sin información sensible. Fabio Ramos trabaja sobre un tenant de laboratorio que replica datos productivos, con reglas que limitan al agente a identificar y proponer; luego revisa y prueba en una rama de la base antes de aplicar. Facundo García Martoni afirmó que sus agentes acceden a producción (base y logs), pero solo con modelos y harnesses confiables, logs sin datos personales (por ejemplo, documentos reemplazados por IDs), backups y, para agentes menos confiables, una capa propia que restringe el acceso a ciertas tablas; advirtió que requiere experiencia previa. Facundo Padilla prefiere acceso de solo lectura y Leonel Pérez se mostró escéptico por el riesgo de errores graves. El consenso fue hacerlo con criterio, con un desarrollador guiando al agente y medidas de seguridad adecuadas.
A partir de un mensaje promocional que prometía grandes aumentos por aprender Solidity o Rust, Facundo García Martoni opinó que aprender un lenguaje ya no multiplica el valor profesional. Ante la pregunta de Jesús Zelarayan, planteó dos capacidades clave: entender sistemas completos y lo que el cliente necesita, y crear sistemas a un nivel de abstracción más alto dirigiendo agentes con harness, loops y contexto. Sugirió aprender lo básico de un lenguaje en learnxinyminutes.com y luego revisar código real, y destacó la habilidad de escribir skills, muchas veces a mano para dejar lineamientos abiertos. Marcelo Nuñez defendió aprender C, Haskell y Smalltalk para entender punteros, programación funcional y orientación a objetos, y así dar mejores instrucciones a los agentes. Agustín Sánchez discrepó: consideró innecesario bajar a ese nivel y ubicó el valor en product engineering, arquitectura, agentic engineering, AI engineering y platform engineering, sosteniendo que un senior que domina agentic engineering se vuelve aún más valioso. Otros remarcaron que los fundamentos de calidad y mantenibilidad siguen siendo clave.
Mauro Torres compartió la página de meetups de Omarchy (una configuración de Linux basada en Arch y el gestor de ventanas Hyprland, impulsada por DHH) y propuso organizar uno propio; Agustín Sánchez destacó el crecimiento de esa comunidad, con unas 2.500 PRs abiertas en su repositorio. Ezequiel Sánchez fue crítico con Hyprland y contó que en su trabajo volvieron a Debian, rescatando el cifrado de disco LUKS como punto fuerte. Ignacio Caram señaló que Hyprland es muy estético pero complejo de configurar y que en distros basadas en Arch es común tener problemas de drivers, por ejemplo con placas wifi. Leandro Contrera contó que usa EndeavourOS, con poca configuración inicial, y que resuelve los inconvenientes con un agente de terminal con permisos, y preguntó qué valor agregado tiene Omarchy. Facundo Padilla respondió que le resultó muy estable, que las ventanas y los workspaces funcionan muy bien, y Mauro Torres agregó que es liviano y se instala en pocos minutos. Mauro remarcó además que con IA ahora es posible modificar cualquier software, incluso el sistema operativo. Se propuso organizar encuentros de Omarchy en varias provincias del norte.
Durante la charla de Midudev en Nerdearla, Agustín Sánchez compartió un artículo sobre WebMCP, una propuesta para que los sitios web expongan herramientas a agentes mediante MCP (Model Context Protocol, el estándar para conectar modelos de IA con herramientas y datos externos) directamente desde el navegador; Alejandro Colchi lo resumió como un MCP común para navegadores. Facundo Padilla sumó MCP UI (mcpui.dev), que permite que un servidor MCP devuelva componentes de interfaz interactivos. Facundo García Martoni dijo no entender el caso de uso, y Padilla explicó que sirve para crear interfaces dinámicas más rápido, con menos tokens y mejor calidad, y que el agente puede seguir trabajando sobre la misma UI que generó. Como ejemplo, planteó un usuario que pide un mini dashboard dentro de un chat y luego quiere profundizar en algún dato sin salir de la conversación, mientras el agente va generando interfaces mejores. García Martoni lo interpretó como una forma estandarizada de lograr lo que hoy se hace generando artifacts HTML al vuelo, y Padilla coincidió, señalando que el resultado es mejor que las soluciones propietarias de algunos chats.
Mauro Torres recomendó herdr, una herramienta de terminal que, con su skill oficial, permite que un agente abra varios paneles con otros agentes CLI que se comunican entre sí; él usa Claude para coordinar Codex y OpenCode con distintos modelos, y combinado con Moshi se conecta desde el celular. Facundo García Martoni prefirió probar Orca, un entorno gráfico para gestionar agentes, y en los días siguientes varios miembros (él, Leandro Contrera, Facundo Padilla) lo adoptaron: destacaron que reúne control de versiones, navegador integrado y las terminales de cada agente, que tiene app móvil y que sumó integración con Muse. Iñaki Fernando Lozano señaló que Orca corre los agentes en modo CLI y podría perder capacidades de navegador que ofrecen las apps de escritorio. Por otro lado, Mateo Lohezic preguntó cómo seguir sesiones de Claude Code y documentos de Drive desde el celular sin AnyDesk: Ale Bardin sugirió el comando /rc de control remoto de Claude Code, y Franco Miranda recordó que Drive tiene API para conectarlo a los agentes.
Un miembro de la comunidad consultó cuánto cobrar por una landing page para una cantante que recién empieza: una sola página responsive con biografía, fotos, enlaces a Spotify y YouTube, redes y contacto, sin backend. Aclaró que la haría con IA y que igualmente le llevaría unas cinco horas dejarla publicada. Fabio Ramos reconoció que los precios de las landings varían mucho y sugirió partir del valor de la hora de desarrollo multiplicado por el tiempo invertido, ajustando según la situación económica del cliente. Salvador Juárez mencionó como referencia un valor de alrededor de 60 USD la hora. Fabio agregó otro criterio a considerar: la visibilidad que el trabajo puede generar; contó que hizo una landing gratis a un diseñador gráfico con muchos seguidores en redes a cambio de exposición ante potenciales clientes con buen poder adquisitivo. La conclusión fue calcular una base por horas y valorar también el potencial de cada proyecto para conseguir nuevos clientes.
Agustín Sánchez compartió la transmisión de la keynote de apertura de DHH (creador de Ruby on Rails) en Rails World, la conferencia sobre ese framework, y la calificó como una de las mejores charlas sobre ingeniería de software. Resumió que DHH habló de agentic engineering y del estado actual del software, afirmó que programar a mano murió, contó que trabaja con agentes en un estado de entusiasmo total, comparó el cambio actual con la evolución de la fotografía en los últimos siglos y cerró planteando que uno puede elegir ser optimista con el futuro del software junto a los agentes. Agustín opinó que no dijo nada nuevo para quienes usan IA intensivamente, pero que tiene mucho peso escucharlo en una conferencia tan importante. Leandro Andriani valoró la comparación con otras industrias para quitar el miedo. Esa misma noche Agustín mostró cómo Opus 5.5 armaba planes muy rápido y ejecutaba proyectos en Rust y Swift, lenguajes que nunca usó a mano, y concluyó que el lenguaje a dominar ahora es el inglés. Facundo García Martoni agregó una idea que también tomó de DHH: Rust es difícil para humanos pero excelente para agentes.
Agustín Sánchez comentó que tenía una PR para agregar soporte a 40 idiomas nuevos en una app, y Facundo García Martoni dijo que enfrentaba lo mismo y que era incómodo generar PRs enormes solo con traducciones. Agustín explicó que si los textos viven en archivos JSON no hay mucha alternativa, aunque son PRs fáciles de revisar. Marcelo Nuñez recomendó i18nexus, un servicio de gestión de traducciones donde se carga una frase con su clave y genera automáticamente las traducciones, permite importar los JSON existentes y tiene un plan gratuito de unas 100 cadenas; contó que en un proyecto anterior el equipo de negocio validaba y ajustaba las traducciones desde ahí. Agustín opinó que para su flujo es sobreingeniería, porque el código lo escribe la IA y, si detecta que la app es multilenguaje, traduce automáticamente; consideró la herramienta más útil para quien escribe código a mano o con asistencia no automatizada. Aun así rescató como interesante la posibilidad de que personas validen las traducciones cuando la redacción es clave, aunque preferiría no depender de una herramienta paga para eso.
Un miembro de la comunidad recordó que en conversaciones anteriores se había dicho que los perfiles senior siguen recibiendo muchas ofertas por LinkedIn y preguntó si seguía siendo así, ya que estaba replanteando su estrategia para conseguir su primer trabajo. También le interesaba crear contenido, pero sin caer en lo genérico, y pidió recomendaciones sobre si valía la pena. Agustín Sánchez respondió que en su caso sigue recibiendo ofertas, pero que el contenido genérico le genera rechazo y no lo recomienda. Su sugerencia fue buscar activamente: identificar empresas en las que le gustaría trabajar, averiguar quiénes trabajan ahí y enviarles un mensaje bien pensado explicando qué valor puede aportar y por qué le interesa esa empresa en particular.
Leandro Contrera preguntó si para frontend conviene el esquema de modelo inteligente que planifica y modelo chico que implementa, o si es mejor usar directamente un modelo grande, teniendo una UI de referencia y un plan de implementación. Facundo Padilla respondió que para frontend siempre usa una librería de componentes más skills, independientemente del modelo, y compartió su ranking personal para UI (Fable 5.1, Opus 5 y Grok 4.6 con skills), comentando que Gemini le daba buenos resultados pero tendía a romper código. Recomendó especialmente la skill Impeccable (impeccable.style), que según él produce interfaces más limpias, y describió su flujo: el modelo más capaz orquesta y planifica, el más chico ejecuta, y se le pide que saque capturas de la UI y corrija lo que vea mal. Un día antes también había comentado que pedirle al agente e2e con capturas sirve para detectar problemas visuales, como elementos que tapan texto. Leonel Pérez sumó como alternativa Stitch de Google, una herramienta para generar diseños de interfaz con IA.
Facundo Padilla probó MiMo v2.6 Flash, el modelo de Xiaomi, sin expectativas y quedó sorprendido: siguió las directrices de frontend, corrió los e2e sin que se lo pidiera y resolvió en unos diez minutos una funcionalidad con backend, frontend, websockets y base de datos, con código que a simple vista le pareció bueno. Estaba disponible gratis en OpenCode (un agente de programación open source para la terminal), sin login. Al día siguiente contó que con el mismo modelo armó y desplegó en media hora un sistema de tickets interno. Iñaki Fernando Lozano coincidió en que OpenCode es muy útil y lo tiene como respaldo para cuando se queda sin cuota en otras herramientas. El 26/09 Padilla dio su review: para él MiMo Flash es mejor que Muse; Facundo García Martoni comentó que, según un análisis, rinde mejor desde su propio harness, MiMo Code. En la misma charla varios miembros expresaron desconfianza hacia los índices compuestos de benchmarks, que pueden estar contaminados por datos de entrenamiento.
Fede Valle contó que migró a AWS un sistema que tenía en un hosting local, pero notó mayor latencia porque lo desplegó en la región de Ohio, y preguntó si convenía São Paulo. Iñaki Fernando Lozano respondió que, si los usuarios están en Argentina, lo lógico es moverlo a Brasil, ya que la latencia está limitada por la distancia física de la fibra óptica; aclaró que una región en Estados Unidos solo tiene sentido si los clientes están allá. Facundo García Martoni aportó un matiz: en su caso, en GCP, terminó migrando de São Paulo a us-central1 y obtuvo menos latencia, porque según su experiencia las máquinas de la región de São Paulo eran más viejas, aunque no sabía si eso se replica en AWS. Recomendó probar primero con un par de máquinas de prueba antes de migrar todo el proyecto. Mateo Antenucci preguntó por la región de Santiago de Chile, y Facundo explicó que no estaba seguro de cómo se enruta el tráfico por la cordillera, mientras que hacia São Paulo sí hay conectividad directa por cable submarino, por lo que habría que medir. Mateo quedó en hacer la comparación entre Santiago y São Paulo.
Mauricio Chaile le preguntó a Facundo García Martoni qué quería decir con que el valor está en 'crear y entender sistemas'. Facundo explicó que al revisar un feature ya no se enfoca en la 'gramática' del código (ubicación de funciones, nombres, división de clases), sino en la relación de lo desarrollado con el todo: si el LLM fue suficientemente genérico sabiendo que vendrán casos similares, si lo nuevo se integrará bien con lo futuro y si la UX sigue funcionando al escalar. Esa información puede obtenerse leyendo el código o haciéndole las preguntas correctas al modelo, lo que ahorra tiempo. Antes de desarrollar usa la skill grill-with-docs y PRDs (documentos de requerimientos) para reducir ambigüedad, aunque siempre quedan reglas de negocio no previstas. Si se sabe qué asumió y qué omitió el modelo, leer el código línea por línea deja de ser necesario, ya que hoy los errores de implementación son mínimos y las observaciones terminan siendo sobre lógica de negocio. Mauricio contó que va por un camino similar.
Un miembro de la comunidad abrió una encuesta sobre qué plan pagar con 100 USD; ganó Claude, en parte porque la persona hace sobre todo frontend. Facundo Padilla recomendó Claude. Facundo García Martoni desaconsejó Cursor en ese momento por su bajo rendimiento de uso (consumió la mitad del plan Ultra en una semana) y recomendó Muse, un agente de código por CLI con planes de 15 y 50 USD, aclarando que con un design system bien definido cualquier modelo hace bien el frontend. Jeremias Alvarez aportó otra experiencia: con el plan de 20 USD de Cursor, eligiendo el modelo según la tarea en lugar del modo automático, le alcanza bien, aunque el uso de modelos externos como Opus se agota rápido. Iñaki Fernando Lozano señaló que la buena atención de herramientas nuevas suele ser propia de su etapa temprana. El 25/09 Fabio Ramos confirmó que el plan de 60 USD de Cursor ya no le duraba como antes, y varios mencionaron Antigravity de Google con Gemini 3.8 Flash como opción económica y con buena cuota, aunque más lenta.
Facundo García Martoni preguntó cómo organizar la revisión de código trabajando con agentes desde la terminal. Agustín Sánchez explicó que, cuando aplica 'loop engineering' (delegar ciclos completos de desarrollo al agente), lanza subagentes revisores, otro agente clasifica los hallazgos y, para cada comentario relevante, un modelo grande planifica y uno más chico implementa, con rondas configurables por proyecto. Para proyectos más tradicionales compartió una skill open source de PR review que admite un archivo rubric.md con los criterios a revisar y deja comentarios en la PR. Su criterio: iterar con review agéntica hasta que no queden problemas y recién ahí hacer revisión humana y pruebas de UI. Facundo Padilla prioriza chequeos deterministas: tests unitarios y de integración, e2e en CI, hooks de pre-commit, SonarQube y Semgrep. Sobre el costo de GitHub Actions, Agustín corre lints y tests localmente y usa Actions solo para deploys y migraciones; se sugirieron Forgejo (forja git autoalojable) y runners self-hosted (Franco Miranda) para ahorrar minutos.
Franco Perez contó que estuvo conversando con el equipo de BNB para organizar una BNB Builder Session: una tarde de trabajo práctico para crear agentes con BNB Agent Studio, similar a otra sesión que se hacía en Mar del Plata. La propuesta recibió apoyo inmediato de varios miembros (Agustín Sánchez, Facundo Padilla, Emiliano Grillo, entre otros). El 22/09 Franco anunció oficialmente el evento para el 22 de octubre en Tucumán: la idea es asistir con computadora y, usando BNB Agent Studio, construir agentes capaces de realizar transacciones sobre BNB Chain (la blockchain del ecosistema BNB), con un workshop para que cada participante se lleve su agente funcionando. Se planteó como el primero de varios encuentros de este tipo para generar espacios de construcción de tecnología. En paralelo, a raíz de un meetup de Devin con más de 50 asistentes en Salta, Benjamin Cortes propuso crear un espacio de 'embajadores' para compartir cómo organizar eventos, y Agustín Sánchez creó un grupo de organizadores, reafirmando la visión de PCN como una comunidad sin límites geográficos con gente organizando actividades en distintas provincias.
Geronimo Rios contó que la skill de code review de Matt Pocock le resultaba muy lenta porque relanza la revisión ante cada hallazgo. Facundo Padilla recomendó correr tests y linters con pre-commit, e Iñaki Fernando Lozano señaló que /implement ya invoca el review y que todo lo que no sea determinista (un agente revisando o probando) es más caro. Facundo García Martoni separó testing de code review y contó su esquema: Cursor Bugbot y CodeRabbit corren en cada PR en GitHub; Bugbot es el más efectivo para bugs críticos aunque costoso, y CodeRabbit es barato y de uso ilimitado con límites de frecuencia. Luego un agente hace babysit de la PR para resolver los comentarios. No usa skills de review porque siempre encuentran algo y se pierde tiempo en detalles menores; según su experiencia, los primeros uno a tres hallazgos suelen ser los importantes. Agustín Sánchez sí usa skills, pero agrega un agente que valida los comentarios del reviewer, los clasifica en urgent, high y minor, y configura por proyecto la cantidad de rondas según el riesgo.
Agustín Sánchez presentó Convoke, una app gratuita de Dizenz para hacer preguntas a la audiencia en charlas y clases y ver las respuestas en tiempo real: el speaker muestra un QR en su diapositiva y los asistentes responden sin crear cuenta. Propuso usarla en las meetups de PCN y adelantó nuevas funciones: que la audiencia pueda enviar preguntas al speaker durante la charla, con la opción de dejar su contacto si alguna queda sin responder, y que las preguntas se puedan ver y votar para ordenarlas por interés. Destacó dos beneficios: que las personas tímidas puedan preguntar sin exponerse y que se prioricen las preguntas de interés general. Jesús Zelarayan contó que en otra charla resolvían esto repartiendo QRs impresos en 3D entre el público, y un miembro de la comunidad mencionó Mentimeter como herramienta similar de referencia.
Fede Valle contó que una falla de su proveedor de hosting afectó a su SaaS ERP, que tenía aplicación, API y base de datos en un único VPS, y pidió recomendaciones de arquitectura. Facundo Padilla sugirió migrar a AWS definiendo la infraestructura como código con Terraform, y destacó que AWS reparte la carga entre zonas de disponibilidad ante fallas. Facundo García Martoni recomendó usar siempre nubes grandes (AWS, GCP o Azure) para proyectos serios y mencionó que suelen ser incluso más baratas gracias a sus créditos iniciales, como los 300 USD de GCP. Valle concluyó que separarán la base de datos y migrarán a AWS. En paralelo, Leandro Contrera preguntó si el plan gratuito de Vercel sirve para producción; Padilla señaló que en teoría no admite proyectos comerciales y García Martoni y Agustín Sánchez recomendaron el plan de 20 USD, muy conveniente con varios proyectos. Sánchez explicó que Vercel ofrece tres entornos: production, preview (para staging y PRs) y development (para el entorno local).
Facundo García Martoni mencionó a Jev, un modelo de la empresa TypeSafe con una arquitectura distinta y mucho más rápida. Iñaki Fernando Lozano, que accedió al playground, explicó que es un modelo 'System One' que evalúa preguntas tipadas contra un estado y devuelve resultados estructurados con distribuciones de probabilidad, sin generar texto, útil para clasificación, seguridad o árboles de decisión más que para programar. Aclaró que no es determinista en sentido estricto, sino que la estructura de salida está garantizada por su arquitectura. Ante la idea de Facundo Padilla de que serían 'ifs anidados', Lozano explicó los embeddings: representaciones de conceptos en miles de dimensiones donde la cercanía entre vectores refleja similitud semántica. También explicó que los LLM tradicionales procesan el prompt en una pasada (prefill) cargándolo en la KV cache y luego generan token a token, mientras que Jev resuelve todo en una sola pasada. Leandro Andriani agregó que el enfoque apunta a la eficiencia por sobre modelos cada vez más grandes.
Matias Juarez consultó cómo reducir el consumo de tokens en Claude. Agustín Sánchez explicó que lo que más gasta es mantener conversaciones largas: como las requests son stateless (sin estado), en cada mensaje se reenvía como entrada todo el historial más lo nuevo, por lo que hay que tener criterio para usar /clear y empezar de cero; compactar es mejor que no hacerlo, pero abrir una conversación nueva es mejor aún. También recomendó elegir el modelo adecuado para cada tarea. Días antes, Jesús Zelarayan había sugerido NotebookLM para transcribir documentos y pasar texto plano en lugar de PDF. En la misma jornada, Geronimo Rios preguntó si usaban agentes por CLI o con interfaz gráfica: Sánchez y Facundo Padilla trabajan casi todo por CLI, mientras que Facundo García Martoni prefiere la GUI por el modo de diseño para frontend, el panel de revisión de Git y el navegador integrado. Sánchez concluyó que conviene usar lo que haga más productivo a cada uno, sin seguir modas.
Facundo García Martoni probó Muse Code, el agente de código por CLI de Meta con el modelo Muse Spark 1.3. Destacó que tuvo más conciencia del repositorio que otros agentes, que se detiene a pedir contexto cuando el prompt es ambiguo en lugar de asumir, que siempre lanza un subagente verificador al final de cada turno y que el uso es muy generoso: planes de 5, 15 y 50 USD. Aclaró que no tiene interfaz gráfica, por lo que revisa los diffs con hunk. Explicó que el tier contributor ofrece más uso a cambio de compartir el código con Meta, mientras que el normal, según Meta, no lo comparte; Mateo Antenucci cuestionó el uso del contributor con código de terceros. Facundo Padilla lo probó en una landing con Next.js y Tailwind: consumió casi nada, pero la UI le pareció genérica y comparable a Grok 4.6, aunque algo más rápido y con mejor código. Iñaki Fernando Lozano reportó fallas de subagentes en Windows. García Martoni también lo recomendó para prompt engineering y pidió a la comunidad apoyar su integración en Orca.
Facundo García Martoni compartió que, a solo cuatro días de pasarse al plan Ultra de Cursor, ya había consumido el 30% del uso mensual con Grok 4.6, por lo que concluyó que Cursor ya no es más generoso que Codex en su plan máximo, a diferencia de épocas anteriores en que el Ultra equivalía a uso casi ilimitado. Facundo Padilla notó lo mismo al pasar del plan de 20 USD, que sentía inagotable, al de 60 USD, y sospechó que parte de la capacidad se estaba destinando a Grok Bot. García Martoni explicó que Grok Bot tiene cuota propia, pero cuando lanza Cloud Agents el consumo se traslada a Cursor; más adelante atribuyó parte del gasto a agentes que corren automáticamente en las PRs. Padilla planteó que, combinando Cursor, Grok Bot y Claude, se obtienen más productos por menos dinero. La conclusión compartida fue que Cursor gana en eficiencia en los planes de 20 y 60 USD, pero no en los planes altos, y ambos esperaban una mejora con un futuro modelo propio de Cursor.
Facundo Padilla detalló su flujo de desarrollo con agentes, que venía probando desde días antes con Orca, un harness open source para orquestar agentes con interfaz de escritorio y móvil. Planifica con grill-me de Matt Pocock, vuelca las tareas detalladas en Linear (gestor de issues gratuito, elegido por su integración nativa con Orca), importa la issue desde Orca y lanza Claude con Fable como orquestador, que mediante un CLAUDE.md dispara workers de Grok; estos leen un AGENTS.md con las skills a usar. Según contó, el orquestador consume pocos tokens mientras Grok hace el grueso del código. Valida localmente con pre-commit antes del CI/CD, revisa manualmente, mergea y la issue se cierra sola en Linear. Planea sumar SonarQube en un hook local, SonarCloud en CI y escaneos de seguridad con Nuclei (escáner de vulnerabilidades basado en plantillas). Mateo Antenucci preguntó detalles para armar algo similar; un miembro de la comunidad preguntó si sirve con otros modelos y Padilla confirmó que Orca se integra con todos. Advirtió que con unos diez workers la app se cierra, aunque los agentes siguen en segundo plano.
Geronimo Rios preguntó si convenía planificar con Fable y ejecutar con otro agente o usar solo modelos de Claude, ya que notaba lentitud en la ejecución. Benjamin Cortes contó que usa Fable para pensar y lanza agentes Opus para implementar. Franco Miranda compartió su esquema: en Cursor planifica con /grill-with-docs y Grok 4.6 o Sol en high, y ejecuta con Luna en max o Grok 4.5; con acceso a más modelos, planifica con Astra en low (o high si la tarea es compleja) y sigue ejecutando con Luna por su relación costo-resultado. Dijo que otros modelos le resultaron más caros sin mejoras que lo justifiquen, y que Claude solo le rinde más en UI. Varios miembros señalaron que los límites de uso de Claude se sienten más ajustados y que Fable agota rápido la cuota, sobre todo al lanzar subagentes. Facundo Padilla combina Fable como orquestador y Grok como ejecutor para repartir el consumo. Facundo García Martoni valoró que Cursor priorice velocidad y costo por sobre inteligencia máxima.
Tomas Fernandez Murga preguntó qué tan seguro es darle acceso a WhatsApp a un agente. Facundo Padilla advirtió que los agentes corren en VPS con IPs conocidas y que WhatsApp suele bloquear esas cuentas; contó que así le dieron de baja un número usado por un bot en n8n. Facundo García Martoni recomendó no iniciar sesión en la VM del bot y usar computer use desde la máquina personal, como hace con un job nocturno que resume sus chats. Agustín Sánchez alertó que las skills de terceros pueden contener instrucciones maliciosas, por lo que hay que revisar su contenido y el AGENTS.md al recibir un repo; Ezequiel Sánchez agregó que los equipos de seguridad están más activos por esto. Al día siguiente, Padilla recomendó no dejar que los bots sean multitarea y ponerles reglas estrictas, ya que uno invadió el repo de otro; asignó tokens de GitHub distintos con permisos mínimos, protegió la rama main y mergea a mano.
Agustín Sánchez animó a aprender a construir productos con alta productividad usando IA y explicó el loop engineering: técnicas para que los agentes se auto-prompteen y trabajen de forma autónoma hasta completar una tarea. Jeremias Alvarez temía dejar un loop corriendo horas y obtener algo distinto a lo esperado; Sánchez respondió que eso se resuelve primero con harness engineering, es decir, preparar el entorno, herramientas y controles alrededor del agente. Facundo Padilla sentía que había que ser cada vez más preciso con los prompts, mientras Sánchez y Leonel Pérez opinaron lo contrario. Sánchez sostuvo que crear skills propias está infravalorado, que funcionan como mini programas y que cualquier tarea repetida dos veces merece una; como ejemplo, creó una skill de scaffold que deja un proyecto listo para trabajar en loop. Para mejorar UI/UX, Padilla sugirió la skill impeccable, pedir tests automatizados con capturas y usar plantillas como cookiecutter; un miembro de la comunidad mencionó que los hooks de los agentes ayudan a reducir alucinaciones.
Salvador Juárez compartió los avances de NEX OS, un proyecto open source que empezó a probar en un TV Box con apenas 2 GB de RAM. Explicó que dejó de plantearlo como una interfaz corriendo sobre Chromium y pasó a convertirlo en el escritorio real del dispositivo, con la arquitectura TV Box, Linux construido con Buildroot (herramienta para generar sistemas Linux embebidos), Weston sobre Wayland como infraestructura gráfica sin paneles ni launchers propios, luego la capa NEX para la experiencia gráfica y finalmente el escritorio NEX OS. El objetivo es que al encender el dispositivo no aparezca Android ni otro escritorio, sino directamente NEX OS, todo sobre hardware barato. Facundo Padilla preguntó si sería open source y Juárez confirmó que sí y compartió el repositorio en GitHub.
Jeremias Alvarez preguntó qué procesador de pagos recomendaban, ya que consideraba que Mercado Pago había quedado flojo. Tomas Fernandez Murga recomendó Rebill por ser muy fácil de integrar y contó que procesan pagos y suscripciones con esa plataforma sin problemas, aunque aclaró que para usarla es necesario tener una empresa constituida, lo que para Alvarez era una limitación. Facundo Padilla sugirió OneInfinite, que permite cobrar por transferencia, generar códigos QR o recibir pagos en criptomonedas. Días después, Fernandez Murga buscó una pasarela que no fuera Stripe para generar enlaces de pago en dólares cobrables con tarjeta, y Padilla volvió a recomendar la misma empresa, ahora bajo el dominio one.lat. En otro momento, ante una consulta sobre automatizar respuestas en Mercado Libre, Salvador Juárez y Lucas Juárez confirmaron que su API lo permite y que incluso ofrece un servidor MCP para desarrolladores.
Jeremias Alvarez consultó qué tan difícil es agregar autenticación de dos factores (2FA) a un sistema, considerando que hoy se programa con asistencia de IA. Agustín Sánchez respondió que hoy es una tarea normal: se simplifica mucho si la librería o framework ya trae el mecanismo listo para activar, y aun hacerlo desde cero no es complicado. Facundo García Martoni coincidió en que es mayormente boilerplate y mencionó que frameworks como Django ofrecen soporte para 2FA. Alvarez comentó que trabaja con el stack PERN (PostgreSQL, Express, React y Node.js) y que ya existen librerías para esto. Días más tarde volvió para contar que lo implementó con un agente de IA sin dificultad, confirmando las recomendaciones recibidas.
Tras ver un workshop oficial sobre Grok Bot, Facundo García Martoni planteó que la clave del éxito con este tipo de herramientas está en diseñar bien las abstracciones de agentes: qué agente existe y para qué. Al día siguiente presentó grill-me-to-bot-team, una skill inspirada en grill-me de Matt Pocock (que usa internamente) para crear equipos de bots. Su premisa es que la taxonomía de agentes no tiene por qué copiar los roles humanos tradicionales como 'backend engineer' o 'frontend engineer', sino que puede definir roles que encajen mejor con una separación de responsabilidades para agentes. Mostró el equipo de ingeniería virtual que generó para su producto, con roles poco habituales en la vida real pero más precisos para agentes. Argumentó que el éxito de un agente depende de mantener su contexto acotado, y que por eso las arquitecturas de subagentes funcionan bien. Recomendó combinar el enfoque de grill-me con la creación de bots.
Un miembro de la comunidad pidió herramientas para ajustar su CV y portfolio, principalmente en cuanto al contenido. Iñaki Fernando Lozano recomendó un flujo concreto: entrar a Typst (un sistema de composición de documentos moderno, alternativa a LaTeX con editor web), buscar la plantilla silver-dev-cv, copiar su código en el LLM de uso diario, conversar con él sobre la experiencia propia para que genere el contenido ya formateado para esa plantilla, y volver a pegarlo en Typst. Franco Perez coincidió en que es la mejor opción y compartió el enlace a la plantilla en el catálogo de paquetes de Typst. La recomendación combina una plantilla probada con la ayuda del LLM para redactar logros y experiencia.
Facundo García Martoni destacó una función de Cursor llamada Listening: ante cada comentario de un reviewer en una PR, el agente reacciona automáticamente. Explicó que antes tenía su propio loop de 'babysit' (un agente que vigila la PR y corrige lo que señalan los reviewers) basado en polling, es decir, consultando periódicamente si había novedades, y que Cursor lo reemplazó con Server-Sent Events (SSE, un mecanismo en el que el servidor envía eventos al cliente por una conexión abierta). Días después contó que, gracias a esto, puede tener varias PRs abiertas en paralelo sin gastar tokens esperando, como si fuera un event loop, y que llegó a mergear seis o siete PRs en una tarde mientras trabajaba en otras cosas. Nacho Albarracin comentó que justo había armado un script con un propósito similar. Más adelante, Agustín Sánchez compartió un artículo de Vercel sobre WebSockets frente a SSE para profundizar en cuándo conviene cada uno.
Facundo Padilla compartió avances de plata-cli, una herramienta de línea de comandos para operar billeteras y cuentas desde agentes. Explicó su esquema: cada perfil (personal, negocio) exige una llave cifrada .key derivada con Argon2id (algoritmo de derivación de claves resistente a fuerza bruta), idealmente guardada en un pendrive, que junto con una contraseña memorizada protege un vault .kdbx cifrado con AES-256, al estilo de KeePassXC; así, robar solo el vault no alcanza. Planea sumar un segundo factor para confirmar envíos de dinero sin depender del celular. Facundo García Martoni observó que Mercado Pago es la única billetera que ofrece acceso programático; la usa en modo lectura para que un bot sincronice a diario sus movimientos y los clasifique en un registro en Notion. Padilla aclaró que la API no permite enviar dinero, algo que él busca resolver con su herramienta.
Agustín Sánchez contó que dos juegos para eventos desarrollados en Dizenz se usaron por primera vez en un fan zone durante un partido de la liga de primera división de Arabia Saudita, con mucha participación y buenos resultados. Agradeció a quienes jugaron al Crashout en una meetup de PCN y dieron feedback para mejorarlo, y anticipó que en la próxima se jugará al Qüizo, un juego de preguntas sobre ingeniería de software. Entre los desafíos técnicos mencionó la internacionalización: el árabe se lee de derecha a izquierda, por lo que al cambiar de idioma se invierte toda la interfaz (soporte RTL). Ofreció dar una charla sobre cómo se desarrollaron los juegos y cómo se resolvieron esos desafíos.
Facundo García Martoni compartió que OpenRouter (un proveedor que unifica el acceso a muchos modelos vía una sola API) le rindió muy bien: con 100 USD cubrió un mes de uso intensivo de su producto de agentes, cuando con Vertex AI estimaba una factura de 250 a 300 USD; usa Gemini 3.1 Flash Lite como modelo principal. Un miembro de la comunidad le preguntó si la derivación a humanos y el etiquetado los hacía con Chatwoot. García Martoni explicó que Chatwoot es el proyecto open source más grande para gestionar conversaciones de múltiples canales de mensajería y que su producto usa un fork muy modificado. Señaló como ventajas su API y el soporte de casi todas las apps de mensajería, y como desventajas que es pesado y está pensado para sistemas chicos o medianos, con colas limitadas. Para escalar horizontalmente externalizó el Redis a Memorystore de GCP y separó la base de datos, logrando instancias casi stateless (sin estado propio) que pueden replicarse en VMs o Cloud Run según el tráfico. Facundo Padilla preguntó por esa arquitectura y la conversación sirvió como explicación del concepto.
Facundo Padilla describió su flujo: charla la idea con un LLM, la pasa por la skill /grill-me de Matt Pocock con Fable para refinarla, arma especificaciones y deja la implementación a Grok. Tras empezar un proyecto desde cero con estas skills, señaló como ventajas que grill-me es muy buena y que las demás skills marcan un camino claro; como desventajas, que el proceso es lento y consume muchos tokens por la iteración. Recomendó llegar al 'grilleo' con la idea muy trabajada, porque las preguntas se vuelven muy granulares (llegó a unas 50). También mencionó las skills ponytail y engram. Facundo García Martoni coincidió en que grill-me es ideal para features o módulos complejos por reducir la ambigüedad, pero innecesaria para cambios chicos. Días después, ante una consulta de Franco Perez sobre ECC, Iñaki Fernando Lozano definió la suite de Pocock como un conjunto de skills para estabilizar el proceso de ingeniería y recomendó el flujo /grill-with-docs, /to-spec, /to-tickets, /implement y /review. Luego sumó /wait-what para obtener explicaciones más claras de los agentes.
Facundo García Martoni abrió la conversación sobre Grok Bot, un nuevo producto de agentes personales integrado con Cursor. Facundo Padilla lo describió como una variante de Hermes (un agente open source de Nous Research) con su propia máquina virtual y herramientas preparadas. Durante varios días, García Martoni destacó la UX, la app móvil, la posibilidad de armar grupos de bots que colaboran y que comparte el ecosistema de plugins (conectados vía MCP, el protocolo estándar para conectar herramientas a modelos) de Cursor, lo que le permitió que un bot abriera PRs mediante Cursor Cloud Agents. Leonel Pérez aportó que el plan Premium+ de X también lo incluye con uso semanal. Padilla planteó la preocupación de que las credenciales pasen por el modelo; encontraron que Grok Bot usa una 'secret card' segura para ingresar secretos sin pegarlos en el chat. Franco Miranda reportó que en su caso los bots perdían memoria tras actualizaciones. También notaron que parte del consumo impacta en la cuota de Cursor. La conclusión general fue que el producto es muy prometedor, aunque Padilla consideró que Hermes da más control.
Facundo Padilla contó que instaló Ubuntu 26.04 con Docker, Coolify (una plataforma open source y autoalojada para desplegar aplicaciones, similar a un Heroku propio), n8n (herramienta de automatización de flujos) y Postgres en un VPS, con un consumo de apenas 1,2 GB de RAM, y que planeaba montar ahí un pipeline de CI/CD para aplicaciones full stack. Ezequiel Sánchez recomendó Alpine por ser más liviana y argumentó que la gran cantidad de paquetes de Ubuntu amplía la superficie de ataque, además de sugerir administrar servidores solo por CLI. Padilla respondió que usa Alpine en las imágenes de Docker, pero que para el host prefiere Ubuntu porque siempre le resultó estable, a diferencia de Debian. Iñaki Fernando Lozano respaldó las versiones LTS de Ubuntu por su estabilidad y amplia adopción, y recomendó investigar zram (swap comprimido en memoria RAM). Padilla remarcó que deshabilitar el acceso root es una medida básica de seguridad.
Facundo García Martoni, que venía usando Codex con el plan más alto, se pasó a Cursor y fue compartiendo su experiencia. Buscaba equivalentes a funciones de Codex: computer use sobre su propia máquina, control de su Chrome y AppShots (capturar el contexto completo de una aplicación, como el DOM de una pestaña). Facundo Padilla le indicó el uso por CLI y la documentación del navegador integrado, y Fabio Ramos mencionó la herramienta @Browser. Finalmente encontró una solución que controla el Chrome externo mediante CDP (Chrome DevTools Protocol). Leonel Pérez le mostró cómo referenciar chats anteriores con @, que en su caso parecía no funcionar en la versión estable, y Facundo Padilla sugirió Herdr, una herramienta agnóstica al modelo que permite que un agente delegue a otro. En su balance, Facundo García Martoni destacó la velocidad de Grok, la interfaz liviana y la buena integración con LSP y Git, pero criticó la experiencia de desarrollador: faltan varias funciones y el uso de la cuota no está a la vista.
Daniel Baltazar Escalante preguntó qué tipo de preguntas hacer en una entrevista con un cliente al que quería ofrecer un sistema de gestión, ya que registraban muchas cosas de forma manual y las perdían. Facundo García Martoni recomendó el libro Cómo ganar amigos e influir sobre las personas, de Dale Carnegie, como base para entrevistas, negociaciones y reuniones, y sostuvo que el resto es conocer bien el producto y mostrarse dispuesto a resolver lo que pida el cliente, con confianza pero sin soberbia. Fabio Ramos aportó un enfoque más concreto: preguntar qué procesos manuales repiten mucho o fallan seguido, y mostrar empatía con esos problemas, ya que en su experiencia a los clientes les cae bien sentir que se entiende su dolor. Victor Figueredo compartió material de lectura relacionado.
Facundo García Martoni alertó que WhatsApp publicó nuevas tarifas desde el 1 de octubre: se cobrará cada mensaje saliente en muchos países y desaparece la ventana gratuita de 24 horas, con un costo cercano a 32 pesos por mensaje, algo prohibitivo para muchos negocios que usan la API. Compartió una calculadora publicada por otra empresa del rubro y la idea que empezó a desarrollar: enviar un único mensaje con un enlace a un chat web propio que se abre en el navegador integrado de WhatsApp, vinculado al cliente, para continuar la conversación fuera de la plataforma; también mostró el prompt con el que arrancó el desarrollo usando la skill grill-with-docs. Lucas Juárez mencionó la publicidad paga como alternativa, y Ale Bardin dudó de que fuera posible, a lo que Facundo respondió que lo mostraría. Se debatió si esto podría mover usuarios a Telegram: Agustín Sánchez lo considera superior en gestión de archivos y app de escritorio, pero cree que en Argentina es muy difícil sacar a la gente de WhatsApp. Ezequiel Sánchez mencionó SimpleX como mensajería enfocada en privacidad. Benjamin Cortes propuso una reunión para compartir soluciones y creó un grupo para coordinarla.
Con la salida de Fable 5.1, varios miembros discutieron qué modelo usar para cada tarea. Facundo Padilla y Facundo García Martoni coincidieron en que Fable es muy lento y que lo que más se valora hoy es la velocidad; Facundo Padilla lo reserva para UX/UI, presentaciones y tareas largas, mientras que recomendó Grok para backend por ser mucho más rápido, aunque su fecha de corte de conocimiento es antigua, algo que resuelve conectándolo a Context7 (un servidor MCP que provee documentación actualizada de librerías). Gonzalo Morales señaló que Opus alcanza para la mayoría de los casos. Facundo Padilla describió un flujo: usar Fable junto con la skill Impeccable para crear una librería de componentes, construir la interfaz con Grok siguiendo esa librería y devolver a Fable lo que salga mal. Jeremias Alvarez y Salvador Juárez contaron que el plan de 20 dólares de Cursor rinde mucho con Grok y Composer (el modelo propio de Cursor), aunque los modelos externos como Opus consumen la cuota en pocos prompts. El día anterior, Facundo Padilla ya había destacado que Grok funciona muy bien cuando se le da una librería de UI como shadcn.
A partir de un post de Robert C. Martin, Agustín Sánchez explicó que en algunos proyectos tiene muchos guardrails y un loop muy trabajado, y en otros prefiere vibecodear. Facundo Padilla, que todavía no les encontraba uso a los loops, preguntó ejemplos; Lucas Juárez sugirió disparar un loop ante una alerta de un servicio para que haga el triage del problema. Agustín detalló que tiene todo el proceso de desarrollo automatizado: con /goal y una skill propia el agente desarrolla todos los issues refinados del backlog y él solo testea a nivel QA. Remarcó que para aplicar loop engineering el repositorio necesita alta calidad técnica: tests automatizados con buen coverage, buena arquitectura, convenciones documentadas, linters, typechecks, git hooks o controles en CI y deploy automatizado. Para eso publicó una skill open source que audita un repositorio y señala qué mejorar para que sea apto. Franco Miranda compartió que antes de dejar corriendo algo grande usa la skill grill-with-docs, que lo interroga sobre los requisitos, y Facundo contó que usa la skill Ponytail para que el agente escriba solo el código justo y necesario en cambios chicos.
Mauro Torres preguntó si alguien usa un harness propio para TDD y SDD con sus agentes. Facundo Padilla aclaró que son cosas distintas: TDD (test-driven development) es escribir primero las pruebas y luego el código, mientras que SDD (spec-driven development) es partir de una especificación detallada que guía la implementación. Para armar un harness desde cero sugirió Pi Agent, aunque él suele crear un AGENTS.md o CLAUDE.md que funciona como índice hacia una carpeta de documentos y skills en Markdown. Para SDD mencionó frameworks como gentle-ai, OpenSpec, SDD Kit, Superpowers y GSD; contó que el 70% de su trabajo lo hace en modo plan y luego ejecuta, y que recurre a SDD cuando arranca un proyecto de cero. Para TDD desde cero propuso escribir escenarios en Gherkin (un formato de especificación en lenguaje natural del tipo dado-cuando-entonces) y luego implementarlos con librerías de BDD como pytest-bdd o behave, lo que permite documentar primero y validar de forma determinística después.
Facundo Padilla comentó que HostGator lanzó AllPass, una suscripción mensual que da acceso a modelos de GPT, Gemini, Claude y Grok sin sistema de créditos y permite crear agentes dedicados, aunque le pareció todavía verde; un miembro de la comunidad dudó de su sentido si no se conocen sus límites. Al día siguiente, Facundo planteó que cada vez resulta más barato ir por infraestructura propia o VPS que por la nube, y comparó precios: los VPS de HostGator le salían más baratos que Hetzner, sobre todo pagando por varios años. Contó que tiene su Hermes allí y que al principio le resetearon el servidor dos veces, aunque luego se estabilizó. Iñaki Fernando Lozano dijo que el precio es similar al de Hostinger, con el que nunca tuvo problemas, y Facundo coincidió en que Hostinger es algo más caro pero le parece más serio.
Facundo Padilla planteó que la arquitectura de microservicios podría encajar mejor con agentes de IA: si el código se delega al agente y uno se preocupa solo por la arquitectura, cada servicio tendría un harness específico y bien segmentado, y se minimizaría el gasto de tokens con modelos baratos. Agustín Sánchez no estuvo de acuerdo: en el 95% de los casos los microservicios son sobreingeniería, lo que se ahorra en tokens se gasta en desplegar la infraestructura, y hay que escribir más código para resolver los problemas propios de ese patrón. Franco Miranda señaló que el consumo de contexto se reduce con buena ingeniería de contexto, y Facundo Padilla terminó coincidiendo en que su única experiencia con microservicios terminó volviendo a un monolito. Agustín agregó una reflexión: los ingenieros deberán ser multi-stack, capaces de trabajar con distintas tecnologías y elegir la adecuada para cada problema, y ser full-stack incluye saber infraestructura y tener ownership del sistema de punta a punta. Facundo García Martoni coincidió, y Ale Bardin sumó que infraestructura y ciberseguridad serán áreas clave por ser más sensibles para delegar a un agente.
Agustín Sánchez preguntó a quienes desarrollan chats agénticos cómo testean al agente, qué herramientas y técnicas usan y cómo aseguran la calidad, y compartió ArtificialQA, una herramienta que le recomendó Emiliano Grillo, cuyo blog tiene artículos interesantes sobre el tema. Un miembro de la comunidad contó su enfoque basado en evals de comportamiento (pruebas que evalúan si las respuestas del modelo cumplen lo esperado): le pidió a Claude generar una lista de entradas que van desde intentos de prompt injection (mensajes que buscan que el modelo ignore sus instrucciones) hasta mensajes típicos de usuarios, y con cada versión de las instrucciones del agente ejecuta esas entradas o simulaciones de conversación, iterando el system prompt hasta que responda como se espera. Dijo que, aunque era un enfoque artesanal, le dio buenos resultados y que quería profundizar en mejores formas de evaluar agentes.
Facundo García Martoni contó que resolvió, con ayuda de Codex, una vulnerabilidad en TV boxes que afectaba a proveedores de internet desde hacía meses, publicó un artículo al respecto y dejó un equipo en una prueba de 72 horas. Ezequiel Sánchez compartió que armó un entorno aislado en su casa con nftables (el framework de filtrado de paquetes de Linux que reemplaza a iptables) y Suricata (un sistema de detección y prevención de intrusiones), útil por ejemplo para analizar APKs maliciosas. También contó que tiene laboratorios con Proxmox (una plataforma de virtualización) y que migró la infraestructura de un cliente a ese esquema, con un servidor Windows sin interfaz gráfica, un firewall basado en nftables y un agente propio que le reporta a diario y hace backups. Para trabajar con routers recomendó Dropbear, un servidor SSH liviano pensado para equipos con pocos recursos. Facundo contó que ese mismo día estaba aprendiendo sobre nftables.
Durante estos días se compartieron varios eventos. Facundo Padilla anunció un meetup de Devin (el agente de programación de Cognition) en Salta el sábado 19 de septiembre, con demo en vivo, taller práctico para construir un proyecto en menos de una hora, casos de uso reales y networking; también difundió un meetup de Grok Bot en Salta el miércoles 16 y un meetup en Jujuy el jueves 3. Agustín Sánchez adelantó que probablemente el 24 de septiembre se haga en Tucumán una hackathon junto a Cursor, 021 y PCN, cuya consigna sería crear un proyecto y premiar al mejor. Arturo Grande anunció la segunda edición de X Builder House en San Lorenzo, Salta, del 11 al 18 de noviembre, con 23 builders durante una semana, una hackathon junto a Argentina Space y actividades comunitarias. Además se difundió la agenda completa de EXPOCON del 3 y 4 de septiembre, con ingreso gratuito e inscripción previa.
Un miembro de la comunidad que volvió a programar con ayuda de la IA preguntó si existe una referencia de precios y si conviene cobrar por hora o por proyecto. Un miembro respondió que no hay un colegio ni precios de mercado establecidos. Leandro Andriani propuso cotizar por proyecto: tomar el valor de la hora propia, sumarle un plus y multiplicarlo por las horas estimadas. Facundo García Martoni sugirió hacer una investigación profunda con IA sobre precios según tipo de proyecto, mercado, tipo de cambio e inflación, aunque Gonzalo Morales advirtió que esas estimaciones suelen inflarse y no considerar si el cliente tiene margen. Jeremias Alvarez planteó que cobrar muy barato degrada la profesión, y Facundo Padilla remarcó que se paga el conocimiento y que los clientes serios suelen pagar mejor. Ale Bardin agregó que al principio es normal pasar por clientes pequeños. Leandro Andriani contó que a veces usa trabajos baratos como puerta de entrada a proyectos más grandes. Facundo García Martoni cerró que venta y producto van de la mano y que hay que aprender a venderse.
El debate sobre precios derivó en si hacer landings sigue siendo negocio. Facundo García Martoni sostuvo que hoy sí, pero no a largo plazo: con la barrera de entrada tan baja, cualquier usuario puede generar una con herramientas de IA, y lo mismo aplica a las micro SaaS; propuso usar las landings como lead magnet gratuito para captar clientes. Jeremias Alvarez y un miembro de la comunidad objetaron que regalar trabajo hace que el cliente no lo valore. Otro miembro argumentó que cualquiera puede hacer una landing, pero no una que no parezca generada por IA, bien estructurada e interactiva; contó que resolvió el pedido de un diseñador buscando en GitHub un UI kit con la estética deseada y guiando al modelo, y compartió un artículo sobre el costo cognitivo: tener acceso a la herramienta no implica saber usarla. Jeremias coincidió en que la diferencia está en guiar al modelo hacia algo creativo, mientras Facundo advirtió que los modelos de frontera mejoran justamente en ese punto. Leandro Andriani señaló que el estilo del modelo de moda termina repitiéndose en miles de sitios.
Agustín Sánchez propuso a Maximiliano Bravo organizar una charla sobre ventas y abrió la consulta sobre qué temas interesan. Maximiliano ofreció el espacio y sumar empresarios de otros rubros, y pidió fijar fecha porque septiembre tiene muchos eventos. Surgieron propuestas: cómo ponerle precio a un sistema, tanto para presupuestar como para tasar uno ya desarrollado (Leandro Contrera); soft skills y cómo encarar el mercado actual (Emiliano Grillo, que recomendó la serie de libros de Inteligencia Emocional de Harvard Business Review); SaaS multi-tenant y design systems (Leandro Contrera); gestión de proyectos y búsqueda de clientes freelance (Juan Arismendi); gestión emocional ante los cambios (Sebastián Soraire, que ofreció preparar una charla); y product engineering y product design (Agustín). También se habló de EXPOCON, un evento sobre economía del conocimiento con charlas, talleres, rondas de negocios y networking; Agustín y Franco Espinoza, que ya asistieron, lo recomendaron si se va con el objetivo claro de hacer networking.
Facundo Padilla preguntó por alternativas a Jira para organizar el trabajo ahora que empezó a construir varias aplicaciones. Facundo García Martoni recomendó Linear como su herramienta de uso diario: dijo que hace lo que tiene que hacer y lo hace bien, que cuesta alrededor de 10 dólares por usuario y que el plan gratuito es generoso, con 250 issues activos, por lo que siendo ordenado se puede usar mucho tiempo sin pagar. Tras probarlo, Facundo Padilla opinó que Linear es un híbrido entre Jira y Trello, muy bueno para equipos chicos, aunque él sigue prefiriendo Jira; lo que más le gustó fue poder manejar varias cuentas a la vez tanto en el celular como en la web.
Un miembro de la comunidad preguntó cómo coordinar tres o cuatro agentes de Claude, usando la suscripción, para que se pasen tareas en cadena: uno escribe un texto, otro lo resume, otro diseña piezas para redes y otro lo publica. Iñaki Fernando Lozano sugirió tmux, un multiplexor de terminal que permite manejar varias sesiones en paralelo, y el mismo miembro encontró un video que mostraba justamente ese flujo. Ese día también se destacó Orca como herramienta para trabajar con varios agentes, y se valoró el uso de git worktrees (copias de trabajo paralelas del mismo repositorio en distintas ramas). Días después, Tomas Fernandez Murga contó que con Grok Bot estaba armando un equipo de agentes con roles que se comunican entre sí, aunque tanto él como Franco Miranda coincidieron en que la herramienta está verde: Franco reportó que se le borraron bots y conversaciones y que por ahora seguiría con Hermes.
79a382ahilo grupal6 participantes
Franco Perez preguntó por una buena skill (un paquete de instrucciones reutilizables para un agente de IA) para backend con Node.js, y contó que suele usar la skill find-skills del directorio skills.sh para que le sugiera opciones. Agustín Sánchez le preguntó qué framework usaría; Franco mencionó NestJS o Hono (un framework web liviano), y Agustín notó que no había skills oficiales para ninguno de los dos, aunque existía una comunitaria para Hono. El tema volvió el 2 de septiembre cuando un miembro de la comunidad, que empezaba a usar subagentes en Codex, preguntó cómo arman su stack de skills: Fabio Ramos recomendó skills.sh para buscar las adecuadas a cada proyecto o pedirle al agente que investigue cuáles necesita, y Facundo Padilla compartió el catálogo de skills de AI Hero. Antes, ante una consulta de Luciano Lagoria sobre recursos para crear skills, Jesús Zelarayan recordó que en el sitio de PCN hay un video sobre el tema.
A partir de una hackathon de ciberseguridad organizada por la Universidad de la Defensa Nacional (UNDEF), varios miembros comentaron su experiencia con la carrera. Ezequiel Sánchez contó que cursa allí materias como protección de infraestructura crítica, con trabajos prácticos exigentes (por ejemplo sobre DNP3, un protocolo de comunicación usado en sistemas industriales), y que la modalidad de ciberdefensa es cien por ciento asincrónica, con un límite de dos materias libres por año. Un miembro de la comunidad aclaró que la licenciatura es gratuita y otro, Ale Bardin, dijo que la está cursando y que las materias están muy actualizadas. Leandro Andriani preguntó por pasantías, ya que no obtenía respuesta por mail ni redes; Ezequiel indicó que ese año se aprobó el régimen de pasantías.
51805d62 participantes
Agustín Sánchez confirmó que Fable le resultó muy potente para crear y mejorar interfaces: con un prompt simple le pidió hacer ultra realistas los cuatro fondos de un juego propio, trabajando uno por uno y haciendo commit de cada cambio, y compartió el antes y el después. También le pidió mejorar la estética del sitio de Dizenz y pidió feedback. Facundo García Martoni destacó la sensación de poco texto y el uso equilibrado de íconos, y como observación subjetiva señaló que los gradientes lineales se parecen a los que generan los modelos por defecto, lo que transmite levemente que el sitio fue hecho con IA, ya que ese recurso quedó asociado a los frontends generados. Además reportó dos detalles en mobile: nombres de proyectos truncados y un botón cuyo texto se acomoda mal cuando falta espacio.
Alejo Boga preguntó si, siendo Obsidian una aplicación local-first (las notas se guardan como archivos en el dispositivo), la única forma de sincronizar entre Mac y iPhone es pagar el servicio oficial, ya que hacerlo con git le parecía que generaría fricción. Facundo García Martoni comentó que en la tienda de plugins de Obsidian hay uno gratuito que usó y funciona bien, pudiendo usar como almacenamiento una cuenta gratuita de Dropbox. Mateo Antenucci recomendó sincronizar mediante iCloud, que funciona muy bien entre dispositivos de Apple y se ofrece como opción al crear la bóveda. Otro miembro compartió un video explicativo sobre el tema.
En una charla sobre sistemas operativos, Nacho Albarracin recomendó Omarchy (una configuración de Arch Linux con el gestor de ventanas Hyprland, orientada a desarrolladores y centrada en atajos de teclado) e Ignacio Fonts contó que probó CachyOS con KDE y quedó muy conforme. Ezequiel Sánchez sugirió Crux, una distribución minimalista donde hay que configurar casi todo a mano, y advirtió que en Omarchy una actualización mal hecha puede romper el sistema, por lo que recomienda tener snapshots configurados e integrados con el gestor de arranque. El tema volvió el 2 de septiembre: Facundo Padilla mencionó una hackathon de plugins para Omarchy con premios de 15 mil dólares, un miembro de la comunidad preguntó si no era puro marketing y Nacho Albarracin respondió que lo usa como sistema principal hace cuatro meses y que, una vez que uno se acostumbra a los atajos, es difícil volver atrás.
Fede Valle planteó que su ERP, construido con Next.js y la última versión de Tailwind, no aplicaba estilos para un cliente que usa Windows 7, ya que ese sistema quedó con una versión vieja de Chrome. Estanislao Torres Campi sugirió bajar las versiones de Next.js y Tailwind a otras probadas en navegadores antiguos, y Salvador Juárez especificó Tailwind v3 (la v4 apunta a navegadores modernos y usa funciones de CSS recientes). Iñaki Fernando Lozano aportó un plan detallado: primero probar con Supermium, un fork actualizado de Chrome que funciona en Windows 7, para confirmar que el problema es el navegador; luego configurar browserslist en el proyecto apuntando a Chrome 109 (la última versión para Windows 7) para que el compilador genere código compatible; agregar un polyfill de globalThis (código que suple una función ausente en navegadores viejos) y asegurarse de usar autoprefixer en PostCSS para los prefijos de CSS.
Gonzalo Morales preguntó si los miembros usan un harness (arnés) para desarrollar con IA. Facundo Padilla lo explicó como el conjunto de elementos que rodean al agente: las herramientas que puede usar (leer archivos, ejecutar comandos, buscar en internet), el contexto y la memoria (guías como AGENTS.md o CLAUDE.md), los guardrails de seguridad y permisos, y los ciclos de feedback. Leandro Andriani lo resumió como todo lo que sirve para guiar el output de la IA y recomendó ir probando configuraciones propias: si uno se descubre pidiendo algo repetitivo, probablemente se pueda resolver con una skill, y si se encuentra un setup predefinido que guste, usarlo como base. Facundo compartió su ejemplo: Claude Code con herramientas de memoria para tareas de UI, Cursor con su AGENTS.md para backend por la relación costo-uso, y Hermes con skills de investigación para buscar información. Ese mismo día, un miembro de la comunidad planteó que frameworks como Superpowers (que primero escriben spec y plan y dividen el trabajo en subagentes) son mucho más lentos y consumen más tokens; Leonel Pérez coincidió y dijo que lo reserva para tareas grandes donde necesita brainstorming.
Facundo Padilla compartió su experiencia con Hermes Agent, el asistente agéntico de Nous Research que tiene versiones de escritorio, web y para servidor, y que él usa prácticamente para todo. Destacó que la capa gratuita de la API de Nous permite correr modelos como Solar Pro 4 sin costo, y que tenía dos agentes trabajando en paralelo con buenos resultados en tareas agénticas, investigación y código Python. Propuso una estrategia de costos: dejar que modelos gratuitos hagan el trabajo pesado y repetitivo, y después pasar ese resultado a un modelo de frontera para refinarlo. Recomendó instalarlo manualmente en un VPS (un servidor privado virtual que se alquila por mes y está disponible las 24 horas) y conectarlo a Telegram, en lugar de usar instaladores de terceros. Al día siguiente, ante preguntas de otros miembros, lo describió como una alternativa superior a OpenClaw; un miembro de la comunidad comentó que había usado OpenClaw con MiniMax y que le interesaba probarlo, y otro preguntó si Hermes realmente conserva mejor la memoria entre sesiones largas.
Agustín Sánchez compartió artículos que escribió sobre buenas prácticas de agentic coding (programar delegando en agentes de IA) y sobre loop engineering. Explicó que esta técnica resuelve el problema de que, aunque la IA resuelva tareas en un solo intento, el desarrollador sigue siendo el cuello de botella al acompañarla paso a paso: se arma un mecanismo en el que la IA se va dando instrucciones sola. En su caso tiene un loop para refinar el backlog y otro para desarrollarlo, cada uno implementado como una skill que invoca con /goal en Claude Code, y usa GitHub Projects para seguir los issues. Iñaki Fernando Lozano lo resumió como definir un objetivo con autoverificaciones intermedias, y Agustín coincidió, aclarando que se complejiza según la tarea y que sirve también para marketing, contenido o gestión de proyectos. Facundo Padilla comentó que trabaja de forma parecida con modos de ejecución autónoma y alto esfuerzo, y Agustín aclaró que loop engineering es una técnica y no un comando puntual. Como ejemplos mostró dos proyectos propios construidos con este enfoque.
Facundo Padilla contó que generó un UI kit completo para un proyecto en un día usando Fable, un modelo de Anthropic que considera el mejor para interfaces, apoyándose en un brandbook extenso que armó previamente. Recomendó la skill Impeccable para quitar la estética genérica típica de lo generado por IA (lo que llaman AI slop), por encima de otras skills de diseño. A partir de eso surgió el concepto de design engineer: un miembro de la comunidad lo definió como un diseñador que sabe programar, y se debatió si los perfiles frontend siguen existiendo como rol separado; Alejo Boga notó que en las búsquedas ve más backend y full stack. También se compartieron estudios de diseño web de alto nivel como referencia (sitios con mucho trabajo en Three.js y renderizado 3D, y galerías como Awwwards), y se comentó que ese tipo de trabajos se cotiza muy por encima del mercado local, lo que llevó a la idea de apuntar a clientes del exterior. Facundo sugirió además una lightning talk sobre perfiles backend haciendo trabajo de UX/UI con IA.
Salvador Juárez preguntó qué plataforma permite integrar en una aplicación pagos con criptomonedas, Mercado Pago y tarjetas. Iñaki Fernando Lozano repasó opciones: el creador de Cafecito desarrolló soluciones para cobrar con cripto y con transferencias; Mercado Pago simplificó su integración y con eso ya se cubren pagos con MP y tarjetas; también mencionó Rebill. Aclaró que si se quiere un esquema tipo marketplace, donde la plataforma actúa de intermediaria y se queda con una comisión, por lo que sabía eso solo se puede hacer con Mercado Pago. Para cobrar desde el exterior recomendó LemonSqueezy (que funciona como merchant of record, es decir, se encarga de la facturación y los impuestos de cada venta), y mencionó que Stripe también es opción pero requiere constituir una LLC en Estados Unidos, lo que agrega bastante complejidad.
Marcelo Nuñez preguntó cuánto se gasta en tener loops de agentes corriendo. Facundo García Martoni dijo que son de las operaciones más costosas, aunque un buen plan las soporta: él usa entre un 5% y un 10% del uso semanal por día solo en loops, con el plan de 200 USD de Codex. Agustín Sánchez explicó que depende de qué loops se tengan y cómo estén armados, de la complejidad de la arquitectura (más abstracciones implican más costo), de los modelos y el nivel de esfuerzo en cada paso, de cómo se corta el trabajo para evitar alucinaciones y de lo bien refinado que esté cada issue antes de que el loop lo tome. Contó que con Claude Code de 100 USD mantuvo un loop desarrollando features las 24 horas durante 5 días, y estima que con el de 200 podría hacerlo en cuatro proyectos.
Facundo Padilla, que tiene que montar gestión de usuarios con IAM y roles y desplegar varias aplicaciones para un proyecto, preguntó si convenía AWS o Azure y cuánto cuesta hoy la nube. Alejo Boga recomendó AWS por sus créditos para startups, útiles para probar servicios antes de decidir. Facundo García Martoni contó que eligió GCP: al crear la cuenta da 300 USD que no vencen enseguida, a diferencia de los 200 de Azure, que expiran rápido, y con suerte se accede a créditos para startups como los 2.000 USD que él consiguió. Padilla anticipó que probablemente terminen en Azure por el ecosistema Microsoft de la organización. También descubrió que un operador de telecomunicaciones revende servicios de AWS, y García Martoni explicó que varios ISPs actúan como revendedores o partners de AWS, GCP o Azure.
Luciano Gallardini preguntó qué software usan para tomar notas en reuniones, ya que había probado Notion y quería otra opción. Un miembro de la comunidad usa OneNote, que requiere licencia. Facundo Padilla recomendó Read AI, con 5 reuniones gratis por mes. Leonel Pérez destacó Gemini incluido en Google Workspace, aunque solo sirve para Google Meet. Tomas Fernandez Murga mencionó Wispr Flow, que también sirve para reuniones presenciales, y Fathom, gratuito y que permite grabar lo que se quiera. Franco Miranda también recomendó Fathom, y Luciano decidió probarlo.
Lucas Juárez preguntó cómo eligieron el nombre de sus productos y si usaron alguna IA en particular, porque ninguna opción lo convencía. Gonzalo Morales contó que le pasó a ChatGPT palabras relacionadas con el producto y le pidió 100 nombres con variantes en latín, italiano e inglés, nombres de animales y palabras inventadas que sonaran bien; aunque al final armó el nombre él mismo, eso le dio muchas ideas. Para el logo usó la primera letra del nombre como base. Agustín Sánchez dijo que genera nombres con Claude, revisa que el dominio esté disponible y que sean fáciles de pronunciar, y que hace los logos con ChatGPT, su herramienta preferida para imágenes. Fabio Ramos mencionó que los modelos Gemini integrados en Antigravity también generan buenas imágenes. Lucas propuso una herramienta que sugiera nombres cuyo dominio .com.ar esté libre.
Facundo García Martoni presentó la tercera versión de la landing de Macch, hecha con Astro y basada en la idea de espacio, IA y minimalismo, con Macch como un centro de gravedad que absorbe trabajo. Explicó su método: definir un concepto aunque sea abstracto, pedirle al agente un lab aparte donde prototipar de 3 a 5 alternativas, elegir una e iterarla a fondo. Sobre el chat del hero, dijo que usó assistant-ui para la interfaz (composer, streaming, markdown) y OpenRouter con Gemini 3.1 Flash Lite para la inferencia. El contexto sale de un archivo landing_copy.ts que funciona como un i18n: los componentes toman sus textos de ahí y el mismo contenido alimenta el system prompt. Las FAQs surgieron de analizar con GPT-5.6 Sol todas las reuniones comerciales para detectar las preguntas más repetidas. La comunidad sugirió marcar mejor un typo intencional con un filtro SVG de ruido, agrandar logos y textos chicos, sumar un botón para volver arriba y un blog para mejorar el SEO.
Facundo Padilla propuso sumar una sede en Tucumán a la Aleph Hackathon, un evento de temática web3 que se hacía ese fin de semana y ya tenía sede en Salta. Loïk Choua se ofreció para organizar y Agustin Ponce de León, embajador de Aleph en Tucumán, dijo que podía pedir créditos, incluidos de Cursor. Padilla ofreció gestionar beneficios de Bitget Wallet para los participantes. Agustín Sánchez consideró que no había tiempo para ese sábado y que en PCN hay pocas personas dedicadas a blockchain. Propuso, en cambio, organizar con más tiempo una hackathon propia junto a Cursor y 021, idea que Agustin Ponce de León y Loïk Choua apoyaron. Un miembro de la comunidad con experiencia en proyectos web3 ofreció sus contactos, y Franco Perez contó que Bitget Wallet estaba dispuesto a dar créditos si se hacía.
Alejo Boga preguntó cuánto es razonable gastar en IA para programar a tiempo completo, pensando en contratar a alguien para una startup. Agustín Sánchez contó que con Claude Max de 100 USD cubre su trabajo full time y proyectos personales, y que pasaría al de 200 solo por tener loops de agentes corriendo en paralelo; aclaró que el consumo depende de cómo la persona maneje el contexto, los prompts y los modelos. Facundo Padilla propuso escalones: 100 USD de Claude, 60 de Cursor si es sobre todo código, 20 de Cursor con menos presupuesto o 10 de OpenCode Go con MiniMax M3. Facundo García Martoni planteó elegir entre 60 USD de Cursor y 200 de Codex. Para un producto con líneas de research, A/B testing y pipelines de datos, sugirió Cursor con Grok, más rápido y eficiente en tareas pesadas y repetitivas. Leonel Pérez dijo que el plan de 60 de Cursor rinde si se usa el modelo Composer. Alejo decidió empezar con el plan de 200 para que el presupuesto no sea un cuello de botella y ajustar después.
Maxi Rebolo preguntó si conviene que la misma IA escriba y revise el código, o usar otra para tener dos puntos de vista. Facundo García Martoni fue tajante: siempre hay que hacer revisión adversarial, con varias IA. Agustín Sánchez contó que usa Opus con una skill propia de dos pasos: un agente revisa el código y deja comentarios, y otro evalúa cuáles vale la pena resolver y filtra los problemas menores. Dijo que se puede usar el mismo modelo en ambos pasos, siempre que sean agentes distintos, y compartió un artículo sobre su workflow de loop engineering. Un miembro de la comunidad describió algo parecido en Orca: Opus con esfuerzo medio define spec y plan y orquesta, y consulta a GPT-5.6 Sol en esfuerzo alto las dudas que lo bloquean y para encontrar huecos no contemplados.
Salvador Juárez pidió herramientas de diseño UX/UI distintas de Figma. Agustín Sánchez usa Excalidraw para UX y antes usaba Whimsical; Mauricio Chaile sugirió Balsamiq. Para UI, Agustín no conoce una alternativa real a Figma: Claude Design y Google Stitch no dan el mismo control, aunque rinden bien si antes se prepara un buen prompt en un chat, y mostró un sitio suyo diseñado con Stitch. Al día siguiente, Facundo García Martoni preguntó cómo iteran el frontend de una web. Él considera clave el Annotation Mode de Codex o el Design Mode de Cursor, que permiten marcar elementos de la página para que el agente los modifique. Un miembro de la comunidad trabaja con el agente en la terminal en una pantalla y la web en otra. Agustin Ponce de León y ese miembro destacaron el Dev Mode de Figma con su MCP para iterar mucho más rápido, aunque requiere un plan pago completo de Figma y consume muchos tokens.
Un miembro de la comunidad pidió ideas para separar sus cuentas de trabajo y personales en las herramientas de desarrollo. Franco Miranda sugirió usar perfiles de VS Code o su versión portable, con un acceso directo para la configuración de trabajo y otro para la personal. Para Claude, que no soporta varios perfiles, propuso usar el login por flags desde la consola con alias o accesos directos. Rocco Di Tella propuso correr Claude en distintas máquinas y conectarse por SSH. Lucas Juárez contó que Orca permite vincular varias cuentas de Claude y cambiar entre ellas. Marcelo Nuñez compartió su método en Mac con Cursor: duplica la app y sus carpetas de configuración, y armó un comando que abre el proyecto con las cuentas y plugins del trabajo, dejando el Cursor original para lo personal. Estimó que en VS Code funciona igual, porque Cursor es un fork.
Tras varios días de fallas en GitHub (pushes que fallaban y PRs que no se podían mergear), la comunidad habló de alternativas. Franco Miranda recomendó isgithubcooked.com para saber si hay problemas, porque la página de estado oficial no siempre los refleja. Facundo Padilla sugirió Gitea, una plataforma git autoalojada de código abierto. Un miembro de la comunidad preguntó por Origin, la alternativa que presentó Cursor en esos días; Salvador Juárez dijo que la probó, que le parece mejor que GitHub y que por ahora solo funciona con Cursor. Padilla prefirió GitLab porque su CI/CD le parece muy superior y su interfaz más clara.
Antes de empezar la tercera versión de la landing de su producto, Facundo García Martoni hizo una encuesta: 15 personas la pondrían en un repositorio separado y 4 en el monorepo del producto. Pidió los argumentos de la mayoría. Un miembro de la comunidad defendió el monorepo cuando los mismos desarrolladores trabajan en ambos, porque permite compartir componentes, configuraciones, paquetes y hasta un cliente de inferencia, y escala mejor. Iñaki Fernando Lozano también lo prefirió para no abrir otra sesión de agentes. Salvador Juárez explicó que él separó la landing de su proyecto porque es la parte pública, mientras que el repositorio principal tiene el núcleo, y así cada parte evoluciona por su lado. El mismo día, García Martoni pidió recomendaciones de librerías de UI para interfaces agénticas y sugirió assistant-ui, AI Elements del AI SDK y tool-ui.
Exequiel De Freitas desarrolla con React Native y Expo una app para que choferes de camiones actualicen el estado de sus viajes en el sistema web de la oficina. En Android la distribuye como APK con EAS, pero preguntó si en iOS había forma de testear sin pagar los 100 USD anuales del Apple Developer Program. Agustín Sánchez dijo que para distribuirla no hay forma de evitar ese pago. Leandro Andriani y Maxi Rebolo aclararon que con una cuenta gratuita se puede instalar en un iPhone propio, pero la firma dura solo 7 días. Facundo García Martoni sugirió evaluar una PWA (aplicación web instalable), que en casos B2B suele ser la mejor opción; Exequiel ya la había considerado, pero para su proyecto encajaba mejor una app nativa.
Facundo Padilla compartió la página que armó para la edición Salta de la Aleph Hackathon 2026. Agustín Sánchez destacó los detalles de UX/UI y preguntó cómo la hizo. Padilla explicó que usó Grok 4.6 en esfuerzo extra high con la skill Impeccable (orientada a mejorar la calidad del diseño de interfaces) y GPT-5.6 Luna para los textos, con la web oficial del evento como referencia. Dijo que el resultado se acerca a Fable para diseño web sin igualarlo, que auditó bastante el resultado y que el trabajo fue mitad suyo y mitad del agente. Agregó que Grok y Composer siguen siendo malos para escribir textos. Ese mismo día comentó que Grok 4.6 buscó por su cuenta sitios parecidos en internet como referencia, aunque le erró a algunos botones.
Facundo García Martoni se quejó de que la IA sigue siendo mala para escribir copy: repite palabras y muletillas que delatan un texto generado. Iñaki Fernando Lozano contó que tenía reglas en el system prompt para evitar patrones como la estructura "esto no es X, es Y" o el abuso de listas con viñetas. García Martoni propuso sumar a los proyectos un archivo WRITING.md con pautas de estilo para los agentes, similar a un AGENTS.md pero dedicado a la escritura, porque los vicios persisten e incluso empeoran en los modelos recientes. Lozano opinó que el modelo que mejor escribía era GPT-4.5, aunque carísimo, y que con GPT-5.6 Sol tuvo buenos resultados. Marcelo Nuñez preguntó qué era un WRITING.md y surgió que es una convención propia, no un estándar. Ese mismo día, Agustín Sánchez compartió cómo personalizar la statusline de Claude Code para mostrar modelo, rama, uso de la cuenta y contexto.
Agustín Sánchez preguntó por experiencias con self-hosted runners de GitHub Actions: con loops de agentes generando unas 30 PRs por día por proyecto, los minutos de CI se le fueron por las nubes. Iñaki Fernando Lozano dijo que armar uno es fácil siguiendo el script de la documentación de GitHub. Facundo García Martoni recomendó Depot.dev, que usa en producción y le resultó lo más eficiente, y mencionó Blacksmith como otra alternativa. Advirtió que un runner local vuelve a atar el trabajo a la máquina y que una VM propia le salía más cara con recursos equivalentes. Descartó las máquinas dedicadas de GitHub por lo engorrosas. Agustín comentó que GitHub había anunciado cobrar por minuto en runners self-hosted y retrocedió tras las quejas, lo que muestra el riesgo de depender del proveedor. Por ahora decidió correr todas las verificaciones localmente. García Martoni agregó que el aumento de código generado por IA dejó en evidencia las limitaciones del CI de GitHub y favoreció a proveedores como Depot.
Facundo García Martoni compartió como aprendizaje un incidente en producción de su producto: un pico repentino de tráfico, con miles de usuarios de un mismo cliente escribiendo a la vez, saturó la única cola de mensajes y sumó unos 30 minutos de demora para todos los clientes. La mayoría de sus servicios corren en Cloud Run y escalan solos, pero la VM con Redis y Sidekiq (el procesador de tareas en segundo plano de Ruby on Rails), un fork de un proyecto grande, no escalaba y sus colas estaban mal definidas. Ante preguntas de Loïk Choua y Agustín Sánchez, explicó la solución: en el corto plazo escaló todo verticalmente, lo que multiplicó el costo por cuatro mientras duró. En el largo plazo, junto con Codex, movió Redis a Memorystore (Redis administrado de Google Cloud), pasó los workers a Cloud Run para que escalen solos y redefinió las colas: cada tenant tiene su propio conjunto dividido por prioridad, para que un pico de uno no afecte a los demás.
Facundo Padilla anunció que SaltaDev ya tiene su fundación en funcionamiento y que ARCA aprobó el dominio saltadev.org.ar como fundación. Eso les permite gestionar beneficios para organizaciones sin fines de lucro y usarlos en eventos. El objetivo es conseguir que empresas como AWS, Google u OpenAI aporten créditos o productos en especie y aprovecharlos para más comunidades del NOA. Compartió como referencia TechSoup, un programa que canaliza donaciones de productos tecnológicos para ONGs y que tiene una lista amplia de beneficios disponibles.
Facundo García Martoni sostuvo que la revisión de código sigue siendo obligatoria, aunque ya no es igual que antes: él lee el código, no un resumen, con un proceso propio que le permite desplegar features grandes a diario. Como ejemplo contó que migró la inferencia de su producto de Vertex AI a OpenRouter (un intermediario que da acceso a muchos modelos con una sola API) porque le salía la mitad de precio. El agente, usando GPT-5.6 Sol, entendió que simplicidad significaba menos líneas y escribió un traductor de la interfaz de Vertex al formato chat completions. Funcionaba y pasaba los tests, pero no permitía sumar otros proveedores ni absorber cambios de API. Lo rehicieron con un seam propio: un contrato que cada proveedor implementa, al estilo del AI SDK de Vercel. Agustín Sánchez preguntó si había explicitado esos requisitos y contó que experimenta revisando solo la funcionalidad, como un cliente con su equipo. García Martoni concluyó que el problema de fondo es la ambigüedad, y por eso valora el plan mode o grill-with-docs. Días después dijo que OpenRouter le funciona muy bien, con costo mínimo y sin caídas.
Agustín Sánchez preguntó si alguien desarrolla directamente en un VPS o sandbox, para no tener la notebook prendida mientras trabajan los agentes. Iñaki Fernando Lozano contó que usa un VPS de Hostinger al que se conecta por SSH con Termius, y que la clave es tmux (un multiplexor de terminal que mantiene las sesiones vivas aunque se corte la conexión): puede seguir el trabajo desde el auto, la oficina o el celular. Mosh ayuda a no perder la conexión al pasar de datos a wifi, aunque le dio problemas al configurarlo. Tiene un cron que limpia recursos de Docker y un AGENTS.md con hooks y reglas para no saturar el servidor; tras dos incidentes hizo un post mortem con los agentes y dejaron límites guardados. Cada proyecto nuevo copia una plantilla de AGENTS.md. Para probar usa port forwarding, Cloudflare Tunnel o un proxy reverso con dominios de testing y producción. Con tmux también armó un protocolo para que agentes de distintas sesiones se comuniquen. Días antes, Matias Podeley había recomendado una notebook liviana y barata como terminal remota vía Tailscale SSH.
Sebastián Soraire contó que presentó en un evento de agilidad de su facultad una versión ampliada de la charla sobre orquestación de agentes y SDD (spec-driven development: desarrollo guiado por especificaciones escritas antes del código) que se había dado en la comunidad semanas antes. Como el público mezclaba perfiles técnicos y no técnicos, evitó la jerga en las diapositivas. Compartió la presentación y el video del ejercicio que mostró en vivo, y contó que con ese mismo flujo armó en unas tres horas una herramienta simple de redirección de códigos QR. Por la misma fecha, Agustín Sánchez compartió recursos de AI Builder Club sobre loop engineering, graph engineering con Claude Code y cómo convertirse en una empresa AI-native.
Facundo García Martoni destacó los heartbeats de Codex: tareas periódicas definidas con un prompt, como un cron simple y descartable. Dio ejemplos: revisar cada hora los paquetes afectados por el gusano de npm, chequear cada 5 minutos si ya propagó el DNS de un dominio o cada 10 minutos si una nueva casilla de correo ya recibe mails. Sirve para todo lo que tiene una espera incierta; se corta pidiéndolo en el mismo hilo o archivando el chat, y cada heartbeat guarda su propia memoria. Nacho Albarracin lo comparó con un polling y creía que Cursor no tenía algo así. Agustín Sánchez contó que Claude Code hace algo parecido por su cuenta con los scheduled wakeups: cuando llega a un límite de uso, sea del plan o de una API externa como CodeRabbit, en vez de reintentar cada pocos segundos se duerme hasta la próxima ventana. Benjamin Cortes y García Martoni coincidieron en que el tiempo de espera no consume tokens.
Gonzalo Morales contó que trabaja de la forma típica (una sesión por feature, un plan y ajustes desde Claude Desktop) y pidió una guía para aprovechar mejor a los agentes. Facundo Padilla sugirió investigar harness engineering, es decir, diseñar el entorno, las herramientas y las reglas que rodean al agente. Agustín Sánchez recomendó usar skills, goals, loops y tareas programadas. También sugirió sumar al repositorio tests automatizados, linters, pipelines de CI/CD, code review automatizado y buena documentación, y dejar instrucciones en skills para que los agentes mantengan la calidad en cada tarea. Por último, aconsejó conectar MCPs y APIs para que los agentes tengan observabilidad y resuelvan más solos (MCP, Model Context Protocol, es un estándar para darles herramientas externas). Gonzalo resumió todo como punto de partida, con el objetivo de ganar productividad sin perder calidad.
Agustín Sánchez preguntó si alguien había probado el Agent Toolkit/MCP de AWS y qué tan seguro es. Facundo García Martoni contó que hace meses deja que Codex maneje gcloud, la CLI oficial de Google Cloud, sin problemas, cuidando los prompts y teniendo backups y snapshots de todo. Leonel Pérez hace lo mismo y destacó la comodidad de que el agente use directamente la CLI. Benjamin Cortes recomendó crear credenciales específicas para el agente con solo los permisos necesarios (principio de mínimo privilegio). Lucas Juárez sumó que conviene configurar bien los hooks (scripts que se ejecutan antes o después de las acciones del agente y pueden bloquear comandos peligrosos) y usar un usuario con permisos limitados.
Nahuel Serrudo registró un dominio .com.ar para una amiga desde su cuenta de DonWeb, con los datos de facturación de ella, y dudaba de a nombre de quién iba a quedar, algo importante porque ella está por registrar su marca. Leonel Pérez explicó que en general el dominio queda en la cuenta desde la que se registra y que después se puede transferir. Iñaki Fernando Lozano y Lucas Juárez recomendaron registrarlo directamente en NIC Argentina (nic.ar), el registro oficial de dominios .ar: sale aproximadamente la mitad, se puede transferir al CUIL/CUIT del titular, y con clave fiscal nivel 2 se hace en el momento. Por DonWeb, en cambio, le avisaron que el alta en el NIC podía demorar uno o dos días hábiles.
23017f24 participantes
Iñaki Fernando Lozano y Jeremias Alvarez avisaron de un nuevo ataque de cadena de suministro en npm: un gusano que comprometió paquetes como keyv y cacheable, con estimaciones de cientos de paquetes afectados. Jeremias Alvarez compartió un análisis de Wiz con una lista parcial de los paquetes comprometidos, y Lozano explicó que la lista completa tarda porque los escaneos se hacen en vivo. Mauricio Chaile preguntó si pnpm también estaba expuesto. Facundo García Martoni explicó que pnpm tiene una configuración (minimumReleaseAge) que impide instalar versiones publicadas hace menos de cierto tiempo, lo que protege contra versiones maliciosas recién subidas, y recomendó activarla. Varios aprovecharon para pedirle a su agente que revisara sus dependencias. Al día siguiente, García Martoni contó que dejó una tarea periódica revisando cada hora si los paquetes afectados impactaban sus proyectos.
4e414d82 participantes
Agustín Sánchez contó que empezó a usar loop engineering (agentes que toman tareas en bucle y las completan de forma autónoma) y que le cambió la forma de desarrollar. Él participa al principio, con product engineering y arquitectura, y al final, revisando y haciendo los chequeos humanos. Primero refina los issues con una skill propia para que no quede ambigüedad y después una skill toma los issues de la columna Ready to Develop, los implementa con tests unitarios, de integración y e2e y varias rondas de code review, y los deja en Ready to QA con una checklist. Como punto de partida compartió el artículo de Claude sobre loops. Facundo Padilla dijo que prefiere features medianas bien testeadas y que en CI/CD compartido por muchos proyectos un agente puede tocar archivos que no debía. Coincidieron en que las skills de workflow son muy personales y las de documentación o herramientas son reutilizables. También criticaron Claude Design porque Claude Code interpreta literalmente sus páginas de diseño; Padilla recomendó combinar Claude con Higgsfield para generar imágenes y webs más dinámicas.
Facundo Padilla compartió un video de Platzi que sostiene que escribir código a mano es contraproducente, y preguntó si era exageración o realidad. Aclaró que una cosa es hablar de productividad, como hizo Uncle Bob (Robert C. Martin), y otra es decir que programar a mano es malo. Leandro Contrera preguntó si tampoco sirve para aprender conceptos. Facundo García Martoni respondió que hoy es irracional salvo que se esté aprendiendo a programar. Padilla advirtió que los tokens no siempre son baratos y que algunas organizaciones empezaron a limitarlos, con modelos de menor nivel y cupos mensuales. García Martoni remarcó que con una suscripción de 20 USD de Cursor ya se puede hacer muchísimo: un estudiante puede aprovechar esta ola casi como un profesional. Padilla sumó alternativas baratas como DeepSeek y OpenCode Go.
Un miembro de la comunidad mostró un truco (el juego de cartas) que está desarrollando con Vite y PixiJS (librería de renderizado 2D en canvas). Contó que un creative developer le armó un motor gráfico modular y un harness con skills: un marco de reglas y herramientas que evita que el agente se desvíe y facilita crear otros juegos. Como prueba, le pasó las reglas del chinchón y el agente lo implementó. Sobre modelos, dijo que Opus 4 entendía el código pero le costaba razonar el resultado visual (posiciones, escalas, capas, responsive y errores del canvas), mientras que Opus 5 lo resolvió e iteró solo con mejor consistencia visual, aunque más lento. Otros miembros no quedaron tan conformes con Opus 5 y señalaron que depende mucho del prompt y el contexto. Mauro Torres compartió su propio truco online, hecho con Supabase como backend y React.
>2026-07julio[37]6 grupales
b7a72d12 participantes
Nacho Albarracin preguntó si alguien había probado Wayfinder, una skill para agentes publicada por Matt Pocock, educador conocido por sus contenidos de TypeScript y desarrollo con IA. Iñaki Fernando Lozano contó que la usa desde hace tiempo, que le parece muy buena y que gracias a ella recurre menos a grill-with-docs, otra skill en la que el agente hace preguntas exhaustivas para aclarar requisitos antes de implementar. No la considera un reemplazo completo: Wayfinder funciona bien en dominios donde el agente puede encontrar la definición por su cuenta, pero para temas muy específicos de su caso sigue prefiriendo grill-with-docs.
74391513 participantes
Un miembro de la comunidad dijo que Opus 5 lo decepcionó: aun con spec y plan hechos, usando el plugin Superpowers, rehízo tareas varias veces y dio malas instrucciones a sus subagentes. Iñaki Fernando Lozano coincidió, mientras que Agustín Sánchez y Facundo Padilla tuvieron buenos resultados. Padilla explicó que Superpowers es una colección de skills para SDD (spec-driven development: primero escribir especificaciones y planes, después implementar), igual que Gentle AI o GSD, y que carga tanto el contexto que el modelo termina delirando. Según él, estas herramientas planifican bien pero ejecutan lento. Sobre Engram (memoria persistente para agentes), opinó que sirve en proyectos chicos pero no escala, porque es SQLite sin búsqueda vectorial. Hoy prefiere un desarrollo más simple, con specs en archivos .md y skills puntuales. Su regla: a partir de unos 300.000 tokens el modelo empieza a fallar aunque soporte un millón, porque importa más la calidad del contexto que la cantidad. Recomendó probar GSD por su buena documentación.
Varios miembros compararon cómo rinden los planes pagos de los agentes de programación. Gonzalo Morales dijo que hoy le alcanza el plan de 20 USD de Claude, aunque meses atrás, con mucha carga, se quedó corto tanto en Claude como en Cursor. Agustín Sánchez contó que con Claude Max le sobra la ventana de 5 horas pero el límite semanal le queda corto: en un día con unas 120 PRs consumió el 45% del semanal. Iñaki Fernando Lozano explicó que Codex solo tenía límite semanal y que con GPT-5.6 Sol en esfuerzo ultra el plan de 100 USD se consume muy rápido. Facundo García Martoni dijo que el plan de 200 USD de OpenAI se siente como cinco veces el de 100, no el doble. Salvador Juárez mostró que Cursor empezó a poner límites diarios a Grok en el plan de 20 USD. También se comentó que Codex volvía a tener un límite de 5 horas. García Martoni advirtió que el Deep Scan de Codex Security entraba en un bucle que se comía el uso semanal sin generar resultados.
Mientras agregaba soporte de webhooks a su producto, Facundo García Martoni contó que aprendió, con ayuda de GPT-5.6 Sol, sobre los ataques que puede sufrir quien envía webhooks. Explicó el DNS rebinding: el atacante registra una URL de webhook y después cambia la IP a la que resuelve ese dominio por una que elige, por ejemplo una IP interna o local. Así logra que el servidor que dispara el webhook termine enviando peticiones con datos a su propia red interna. Es una variante de SSRF (server-side request forgery), y la defensa habitual es validar la IP resuelta en el momento de cada envío y bloquear rangos privados.
Lucas Juárez preguntó cómo se conecta con WhatsApp el agente Hermes que usa Facundo García Martoni (Hermes es un agente personal de código abierto de Nous Research). Facundo García Martoni explicó que Hermes trae integración nativa con Baileys, una librería que conecta WhatsApp de forma no oficial. También soporta la API oficial de Meta, pero no la recomienda para proyectos personales por lo complicada que es de configurar. Mencionó Kapso como buena opción para proyectos comerciales chicos o medianos; él, en cambio, hizo toda la integración de su producto por su cuenta y es tech provider de Meta. Su recomendación: Baileys para un Hermes personal y Kapso para algo comercial. En la misma charla, Facundo Padilla contó que tiene el dashboard de Hermes en un VPS, publicado con un túnel de Cloudflare en su dominio, con un consumo cercano a 200-270 MB de RAM. García Martoni sugirió Tailscale (una VPN que crea una red privada entre tus dispositivos) para acceder desde la máquina local. Padilla también reportó un bug de Hermes que exponía credenciales en el chat al completar formularios.
Juan Farber agradeció la recomendación de OpenCode Go (la suscripción económica de OpenCode, un agente de programación de código abierto) y dijo que el modelo MiniMax M3 rinde muy bien. Contó que antes gastaba cerca de 20 USD por sesión usando Claude con máximo razonamiento, y que ahora, con un modelo chino y una configuración optimizada, no llega a un dólar. Para ahorrar tokens usa rtk, caveman, dynamic context pruning (recortar partes del contexto que ya no hacen falta) y graphify, que arma un grafo de conocimiento del repositorio. Facundo Padilla elogió Big Pickle, un modelo gratuito de OpenCode. Días después, un miembro de la comunidad preguntó si graphify sirve de verdad. Padilla dijo que él usa codebase-mcp, que hace algo parecido, y que estas herramientas solo valen la pena si se les encuentra un uso concreto: en su caso, indexar sus notas de Obsidian para que su agente encuentre información más fácil.
Franco Gimenez preguntó qué tarifario usar para presupuestar un ecommerce personalizado, con un presupuesto de backend y frontend y otro solo de frontend. Facundo Padilla recomendó cobrar por hora: un precio cerrado solo es posible si el cliente define todo al detalle, cosa que la mayoría no hace. Sugirió preguntar por qué no usan soluciones ya hechas del mercado, como Tiendanube o Empretienda, y advirtió que un ecommerce no funciona sin backend. Como el proyecto seguramente va a cambiar desde el inicio, recomendó fijar un precio por hora y cobrar un porcentaje por adelantado para asegurarse de que el cliente siga pagando. Franco Gimenez aclaró que el cliente quiere un frontend con su lógica integrada al sistema POS/ERP que ya usa, sin pagar el ecommerce que ofrece ese proveedor, y por eso pedía los dos presupuestos.
Franco Perez recomendó Orca (onorca.dev), un entorno de desarrollo pensado para trabajar con agentes, y dijo que en poco uso reemplazó a su Cursor. Lo que más destacó es una barra lateral que organiza tres niveles desde una misma ventana: varios proyectos, los worktrees de cada uno (copias de trabajo de git en ramas distintas, que permiten desarrollar en paralelo) y los agentes de cada worktree. También permite configurar scripts personalizados al crear sesiones nuevas y trae un navegador integrado donde se hace clic en un elemento de la página para copiarlo y pegarlo en la terminal del agente. Para él, que paga Claude Code y no Cursor, resulta más cómodo. Mauro Torres sumó Warp, una terminal con funciones de IA, como alternativa. Más adelante Lucas Juárez comentó que en Orca se pueden vincular varias cuentas de Claude y cambiar entre ellas.
Facundo García Martoni mostró cómo Codex, con computer use (la capacidad de un agente de manejar el navegador y la interfaz como un usuario), analizaba al mismo tiempo el consumo de Vercel para bajar costos y corría un test end-to-end en producción con muchas pestañas abiertas. La investigación encontró que los deployments se ejecutaban en máquinas de 30 vCPUs sin necesidad, y el agente propuso y aplicó cambios. Recomendó a todos auditar sus cuentas de Vercel. Facundo Padilla preguntó por qué no tenía un ambiente de staging para no probar en producción; Facundo García Martoni respondió que, siguiendo el principio KISS (mantenerlo simple), le alcanza con local y producción para avanzar rápido, aunque Padilla prefiere no testear en producción. Además, García Martoni comentó que el código boilerplate (manejo de equipos, asientos, permisos) está tan aprendido por los LLMs que conviene implementarlo en casa: el agente incluso cubrió casos borde como impedir que el último administrador se quite su propio rol.
Un miembro de la comunidad que da talleres de Claude Code para personas no técnicas, con grupos de hasta 70 asistentes de niveles muy distintos, pidió opiniones sobre sus analogías. Para explicar el archivo CLAUDE.md propuso comparar al agente con un equipo muy capaz pero sin memoria, al que hay que recordarle quién es y qué tiene que hacer. Facundo Padilla dio una definición más formal: es un archivo que le da al agente un contexto mínimo del proyecto y donde se pueden fijar reglas o cosas que no debe hacer. Jesús Zelarayan preguntó cómo explica la ventana de contexto, y la idea fue que el modelo no recuerda nada entre mensajes y relee toda la conversación cada vez. El mismo miembro contó que lo invitaron a enseñar agentes en una universidad donde los alumnos no pueden pagar suscripciones; Facundo Padilla sugirió usar la capa gratuita de ChatGPT o Big Pickle, un modelo gratuito disponible en OpenCode (un agente de programación de código abierto para la terminal).
Facundo García Martoni contó que desde la salida de GPT-5.6 Sol (modelo de OpenAI que usa en Codex) cambió su forma de trabajar: para features de complejidad baja o media dejó de usar Plan Mode o la skill grill-with-docs y desarrolla varias mejoras seguidas para testearlas al final. En un caso real, de 10 mejoras de entre 1.000 y 7.000 líneas cada una, 8 salieron perfectas y 2 necesitaron ajustes menores. Aclaró que sigue haciendo code review completo y que, para él, el valor hoy está en dominar el codebase, la visión y la arquitectura. Ante preguntas de Agustín Sánchez y Jesús Zelarayan, explicó que su motor es mixto: el código es multi-tenant (una misma aplicación sirve a varios clientes), pero cada agente es single-tenant porque su parte aislada vive en la base de datos y no en el código, de modo que cambiar el agente de un cliente no afecta a los demás. Un miembro de la comunidad compartió un enfoque parecido: un system prompt armado por bloques (reglas de la plataforma, reglas de seguridad, comportamiento, caso de uso, instrucciones del tenant, contexto de RAG y un refuerzo de reglas al final).
Gonzalo Morales estaba integrando WhatsApp Cloud API usando el número de prueba que provee Meta: los webhooks llegaban a su endpoint, pero al responder a números de Argentina recibía el error 131030 ('Recipient phone number not in allowed list'), aun probando con los formatos +54 y +54 9, y con un número de otro país obtenía un error de token. Preguntó si era un problema con números argentinos. Nacho Albarracin comentó que configuró un bot hace poco sin problemas, por lo que no parecía algo propio de Argentina. Benjamin Cortes señaló que con el número de prueba hay que registrar específicamente los destinatarios, y Facundo García Martoni indicó que los números permitidos deben configurarse en la sección correspondiente del panel de desarrolladores de Meta, y lo guió con más detalle. Con esa ayuda Gonzalo logró que los mensajes funcionaran. Facundo también compartió la documentación del servidor MCP oficial de Meta para desarrolladores como recurso adicional.
A partir de un proyecto para automatizar ventas y marketing, se debatió si todo proceso se puede automatizar. Facundo Padilla sostuvo que cualquier cosa que viva en una computadora puede automatizarse de una forma u otra. Un miembro de la comunidad matizó desde su experiencia: en una empresa chica intentaron automatizar con un agente la recepción de pedidos de piezas gráficas, pero como los pedidos son abstractos y los clientes se explican mal, el agente no entendía, faltaba el feedback entre personas y había que rechequear todo, por lo que terminó empeorando el trabajo y se pausó. Se contrastó con los pedidos de cadenas de comida rápida, que funcionan porque el producto está totalmente estandarizado; Facundo Padilla lo describió más como una abstracción que como una automatización. Leandro Andriani sugirió que el bot al menos transcriba literalmente lo que pide el cliente, aunque seguiría habiendo confusiones. Facundo García Martoni opinó que, con ingenio, esos flujos sí se pueden automatizar. La conclusión fue que técnicamente es posible, pero a veces la IA agrega más trabajo del que ahorra.
Facundo Padilla compartió que Hermes Agent, el agente autoalojado de Nous Research muy usado en la comunidad, publicó una nueva versión con un dashboard web, y lo levantó en su VPS para probarlo. Aunque criticó la tipografía y el diseño por defecto, descubrió que la interfaz se puede personalizar, por ejemplo con un estilo monocromático, otra fuente e idioma español. Entre las funciones destacó la posibilidad de cambiar entre perfiles, explorar, subir y borrar archivos del servidor, y sobre todo elegir desde la UI qué modelo usar para cada tipo de tarea, como MiniMax M3 para visión, algo que antes requería editar a mano un archivo de configuración YAML. Comparándolo con OpenClaw, otro agente de este tipo, opinó que la interfaz de OpenClaw sigue siendo mejor, aunque el dashboard de Hermes aporta funcionalidades muy prácticas para administrarlo.
Juan Farber preguntó qué conviene para programar a diario pagando de su bolsillo, y si realmente solo rinden las suscripciones de 100 o 200 USD de los grandes laboratorios. Nacho Albarracin opinó que el plan de 20 USD de Cursor es el que más rinde, porque en modo automático usa Composer, que se desempeña muy bien; Salvador Juárez agregó que ese plan permite usar Grok 4.5, y Leonel Pérez contó que con el de 60 USD nunca se quedó corto. Facundo Padilla recomendó herramientas para ahorrar tokens: codebase-memory MCP, rtk (Rust Token Killer, que reduce la salida de comandos que llega al contexto del agente), el esquema orquestador de gentle-ai y la skill ponytail para ejecutar y auditar. Sobre agregadores como OpenRouter opinó que se cae con frecuencia; para modelos gratuitos sugirió Groq y, como opción barata, OpenCode Go. Facundo García Martoni resumió: menos de 100 USD, Cursor; más de 100, Codex. Al día siguiente se aclaró que el plan de 60 USD de Cursor triplica el límite para modelos distintos de Composer, y la recomendación fue empezar con el de 20 y subir si hace falta.
Facundo García Martoni compartió un patrón que le resultó muy útil: cuando un servicio no tiene API oficial, o no expone por API lo que se necesita, pero su interfaz web puede operarse con un navegador headless (sin interfaz gráfica, controlado por código), se puede construir un cliente separado en el backend que automatice esa interfaz. Ese cliente usa las credenciales normales de un usuario e inicia y cierra sesión dinámicamente. Contó que llegó a esta idea cuando estaba por decirle a un cliente que algo no se podía hacer porque la API oficial no lo soportaba, y se dio cuenta de que con una cookie de sesión se puede hacer casi todo. Advirtió la principal desventaja: la integración se rompe en cuanto el servicio cambia su interfaz. En el mismo contexto propuso el término 'SaaSy' para describir una feature genérica y reutilizable para otros usuarios similares, en lugar de algo hecho a medida para un solo cliente.
Marcelo Nuñez planteó un debate al notar que la página de estado de Claude muestra incidentes casi a diario mientras Anthropic prioriza lanzar features, a contramano de lo que enseña la ingeniería de software, y aun así le va muy bien. Preguntó cómo se decide a nivel negocio sacar features antes que corregir errores. Leandro Andriani atribuyó el éxito a que es lo más nuevo del mercado; Facundo Padilla, a que venden un servicio y no un producto; Mauricio Chaile, a su posición dominante. Facundo García Martoni, que conoce el dilema desde su startup, opinó que el factor clave es el balance entre oferta y demanda: si hay poca oferta de calidad, los usuarios, sobre todo técnicos, toleran errores. Explicó que se pasó a Codex por calidad equivalente, límites más generosos y modelos más eficientes. Leonel Pérez señaló que estas empresas miden todo con KPIs. Iñaki Fernando Lozano propuso separar la estabilidad del producto de la del modelo: operar data centers de GPUs a esta escala es muy complejo, y lo importante es cómo responden ante fallas.
Marcelo Alvarez preguntó por experiencias con OCR para leer documentos físicos o digitales como PDFs, fotos de remitos, facturas y escaneos. Facundo García Martoni contó que en producción lo resuelve directamente con Gemini 3.1 Flash Lite, que recibe imágenes y PDFs de forma nativa, con un costo mínimo y, según su experiencia, sin problemas tras cientos de miles de comprobantes de pago leídos; su argumento es delegar al modelo todo el trabajo de preprocesamiento. Agustin Navarro sugirió probar primero librerías de Python como pypdf o pdfplumber, útiles sobre todo para PDFs con texto, y recurrir a un servicio externo si no alcanza. Mateo Antenucci compartió los problemas típicos con fotos de tickets: poca luz, dígitos borrosos e imágenes rotadas que bajan mucho el rendimiento; los mitigó usando Tesseract para detectar y corregir la orientación y OpenCV para aumentar el contraste. Marcelo, que tenía justamente problemas con fotos y escaneos, se llevó ambas alternativas.
Facundo Padilla compartió un análisis propio de codebase-memory MCP, un servidor MCP que indexa un repositorio para que el agente consulte su estructura sin leer todos los archivos, a partir de un video que prometía un 87% de ahorro de tokens y que le pareció clickbait, ya que luego hablaba de 50% y repetía el prompt con el contexto ya cargado. Midió con Claude Opus 4.8 y el mismo prompt de análisis: sin el MCP consumió unos 86 mil tokens; la primera corrida con indexado, unos 102 mil; y ya con el índice creado, unos 78 mil. Su veredicto fue que el ahorro real no se acerca al 87%, aunque sí le ahorró unos 2 minutos y alrededor de 10 mil tokens por análisis una vez indexado. Días después, igualmente lo incluyó entre sus recomendaciones para ahorrar tokens junto con rtk y el esquema orquestador de gentle-ai, por lo que la conclusión fue que es útil pero con expectativas moderadas.
Jeremias Alvarez preguntó por alguna skill para Cursor que evite el típico 'diseño de IA' en las interfaces generadas, ya que las que encontraba eran para Claude Code. Un miembro de la comunidad recomendó taste-skill, que había probado con buenos resultados. Facundo Padilla propuso un proceso en cuatro pasos: primero armar un brandbook con cómo debe ser la web, después construir un design system, luego usar la skill impeccable para ajustar espaciados y reglas y auditar el CSS apoyándose en Playwright para ver el resultado real en el navegador, y finalmente usar taste-skill para dar un toque más distintivo. Franco Perez agregó que, antes de impeccable, pasa por ui-ux-pro-max, otra skill de diseño que le ayuda a encaminar la interfaz antes de pulirla. La idea central fue que las skills de diseño rinden mucho más si el agente tiene lineamientos de marca y un sistema de diseño definido.
Nacho Albarracin preguntó si alguien había probado el modelo Kimi K2.7 Code y cómo se comparaba con MiniMax. Facundo Padilla explicó que cada uno brilla en algo distinto: Kimi Code es muy rápido y mejor para escribir código, pero falla en modo agéntico, mientras que MiniMax es flojo para código pero muy bueno para tareas agénticas en asistentes como OpenClaw o Hermes. Iñaki Fernando Lozano sumó su experiencia con GLM 5.2: habla mucho y da vueltas, aunque si se lo deja trabajar logra algunas cosas, pero está lejos de Opus 4.8 como se lo promocionó y ni cerca de Fable o GPT-5.6 Sol. Facundo Padilla coincidió en que no le convenció, rescatando solo que su salida extensa sirve para planificar, y mencionó que, como MiniMax 2.7, a veces mezcla caracteres en chino o cirílico, un problema que otro miembro había reportado días antes y que se resolvía cambiando a MiniMax M3. Agregó que en Reddit suelen recomendar versiones anteriores de GLM.
Se dio una discusión sobre la lentitud de algunos agentes. Facundo Padilla contó que Claude tardó 8 minutos en clonar un repo, crear una rama, copiar archivos, commitear y pushear, algo que él hace en 2 minutos, y que terminó haciendo tareas a mano; otro miembro coincidió. Facundo García Martoni sostuvo que la velocidad es una variable central en el flujo de un desarrollador que los grandes laboratorios no priorizan, a diferencia de Cursor, y que el multitasking forzado con worktrees termina agotando: prefiere tomar un feature y completarlo en una tarde. Surgió Grok 4.5, disponible en Cursor. Salvador Juárez lo usó intensivamente, le pareció rápido, muy bueno para analizar un proyecto completo y capaz de detectar y corregir sus propios errores. Fabio Ramos opinó que es más rápido que Composer, mejor en general y más consciente de su ecosistema de herramientas, como lanzar subagentes o usar skills. Marcelo Alvarez lo ubicó cerca de Opus 4.8. Facundo García Martoni mencionó que Cerebras logra unos 1500 tokens por segundo con Gemma 31B, el tipo de velocidad que se necesita.
Agustín Sánchez preguntó si alguien tenía un setup para que los agentes adjunten capturas del navegador en las pull requests de GitHub. Facundo García Martoni comentó que creía que Cursor lo ofrece de forma nativa en sus Cloud Agents y posiblemente Codex también. Agustín investigó el servidor MCP oficial de GitHub y constató que la API de GitHub no permite subir imágenes al crear una PR, solo referenciar URLs públicas. Martin Uslenghi sugirió alojar las imágenes en un CDN propio e incluir el enlace en el Markdown, como en cualquier archivo .md; Agustín coincidió en que es el workaround, aunque opinó que GitHub debería resolverlo, sobre todo para organizaciones que pagan en repositorios privados. La charla derivó en críticas a GitHub Actions: Facundo Padilla consideró que GitLab está muy por delante en la experiencia de pipelines y logs de CI/CD, y Facundo García Martoni recomendó Depot, un servicio para acelerar builds de CI que usa hace meses.
Facundo Padilla contó que estaba armando un chat propio tipo ChatGPT donde el modelo genera consultas SQL, las ejecuta y arma respuestas renderizables en la UI. Comparó modelos disponibles en OpenCode Go: DeepSeek Flash le resultó más lento que la versión Pro, Kimi 2.7 no lograba completar tareas agénticas y MiniMax M3 era rapidísimo pero con salidas de baja calidad. Facundo García Martoni, que construía algo similar, recomendó AI Elements de Vercel y assistant-ui, librerías de componentes de chat basadas en shadcn/ui, y más tarde tool-ui, para renderizar resultados de herramientas; advirtió que parece fácil pero es difícil lograr una buena UI de chat, sobre todo por el manejo del streaming de texto. También sugirió Gemini 3.1 Flash Lite como modelo muy agéntico y barato, accesible con API compatible con OpenAI a través de OpenRouter o, si no, vía Vertex AI. Facundo Padilla coincidió en que el harness (la estructura que rodea al modelo: herramientas, prompts y manejo de estado) es clave.
Facundo Padilla destacó Cloudflare Tunnel, que le permitió tener un subdominio funcionando en menos de dos minutos, resolviendo los hosts por nombre de contenedor de Docker sin configurar localhost, e incluso pidiéndole a su agente que lo levante. Facundo García Martoni contó que lo usa como reemplazo gratuito de ngrok Pro. Días después Nahuel Serrudo recomendó DuckDNS, un servicio de DNS dinámico gratuito para obtener subdominios. Se discutieron las diferencias: Facundo Padilla explicó que ngrok gratuito tiene límites y no permite usar dominios propios salvo en la versión paga, mientras que Cloudflare Tunnel sí. Facundo García Martoni aportó un matiz de seguridad: para pruebas puntuales con permisos más laxos que producción, la URL aleatoria y efímera de ngrok gratuito es una ventaja, porque se descarta al terminar, mientras que una URL fija como la de un túnel de Cloudflare podría quedar expuesta como un riesgo.
Facundo García Martoni analizó la actualización que fusionó la app de Codex con ChatGPT y trajo GPT-5.6 en variantes Terra y Sol con distintos niveles de razonamiento. Destacó novedades como la fecha de reinicio de los límites de uso, la función Sites (hosting aparentemente gratuito para apps generadas, con bóveda de secretos, login de OpenAI y dominio propio), un modo Work similar a Claude Cowork, pestañas múltiples en el navegador integrado y un modo picture-in-picture para cuando el agente usa el navegador. Criticó mezclar usuarios comunes y avanzados en una sola app y renombrar los hilos como 'tasks'. Advirtió que cambiar entre Terra y Sol en un mismo hilo obliga a compactar el contexto, por lo que conviene usar un solo modelo por hilo. También reportó un bug por el que los archivos nuevos no aparecían en la vista de cambios, que resolvía temporalmente con git add -N. Días después él e Iñaki Fernando Lozano coincidieron en usar Sol High por defecto, reservar xhigh o Max para code review y tareas complejas, y considerar Terra xhigh como alternativa, porque Sol Ultra consume el cupo rápidamente.
Con el acceso promocional a Fable 5 (un modelo de Anthropic de alto costo) habilitado por tiempo limitado en los planes pagos de Claude, Benjamin Cortes preguntó si valía la pena pagar el plan de 200 USD para aprovecharlo. Iñaki Fernando Lozano, que lo había pagado, dijo que le rindió y recomendó usarlo como orquestador, delegándole solo las partes del plan o del código que requieren más criterio o 'taste', y el resto a modelos más baratos; así le duró bastante. Facundo Padilla opinó que conviene solo si se va a usar intensivamente, y lo usa para orquestar y ejecutar, sobre todo frontend, donde lo considera muy superior a Opus 4.8; comentó además que al pasar del plan de 100 al de 200 se descuenta lo ya pagado. Ese mismo día Agustin Ponce de León recomendó el nuevo modelo de Cursor, que probó con acceso anticipado y le pareció superior a Composer 2.5 para implementar tareas bien especificadas, con Fable como orquestador. Jeremias Alvarez advirtió que habría que ver los costos, ya que la gran ventaja de Composer es que su uso parece no agotarse.
Leandro Contrera, estudiando servidores HTTP, contó que se usa un Executor (un componente que administra un pool de hilos y agenda tareas) para manejar la concurrencia, y lo relacionó con usar un LLM como enrutador en una arquitectura multiagente, viéndolo como su contraparte determinista. Iñaki Fernando Lozano matizó la comparación: un enrutador basado en LLM no es determinista ni acotado, mientras que un task scheduler es una estructura sólida y bien definida, similar al planificador de un sistema operativo, pensada para asignar recursos de la mejor manera posible. En un servicio que atiende muchos usuarios además hay límites, colas, monitoreo y bloqueos, mucho más complejo que simplemente recibir y derivar. Ante la pregunta sobre la relación con la planificación de CPU, Iñaki explicó que el principio es parecido, pero en un data center hay más recursos, paralelismo y prioridades, mientras que un sistema operativo administra un único nodo.
Samuel Ovejero preguntó si alguien usaba IA para crear dashboards de visualización de datos, en herramientas como Looker Studio o Power BI, para no hacer todo a mano en su trabajo. Luciano Lagoria y Franco Perez sugirieron Grafana, señalando que da mucha libertad y que aparece con frecuencia en búsquedas laborales. Agustin Navarro contó que en su equipo usan Tableau pero están por migrar a Apache Superset, una plataforma open source de BI que ahora ofrece integración con MCP (Model Context Protocol) para crear gráficos a partir de un prompt en lenguaje natural; agregó que Grafana y Datadog los usó más para dashboards de infraestructura, aunque también podrían servir. Lucas Juárez sumó Metabase, otra herramienta open source de BI orientada a explorar datos y armar tableros con facilidad. Samuel no conocía Grafana y se llevó varias opciones para evaluar.
Facundo García Martoni avisó que Cursor Bugbot, el revisor automático de pull requests de Cursor, le consumió el 100% del plan Pro en una sola PR: según le explicaron por mail, aunque funciona internamente con Composer, no descuenta del uso incluido de Composer sino del saldo de uso de API. Recomendó revisar la configuración de gasto para evitar sorpresas y comentó que CodeRabbit pasaba a ser su primera opción: menos generoso que el Bugbot anterior, pero mucho más que el actual. Al día siguiente Marcelo Nuñez recomendó Greptile, otra herramienta de revisión de código con IA que usa en su trabajo, destacando que encuentra problemas que Bugbot no detectaba, y aclaró que personalmente no le gusta el formato de salida de CodeRabbit. Días después Facundo García Martoni volvió a lamentar el cambio de Bugbot, que lo llevó a considerarlo una herramienta ya poco conveniente.
Benjamin Cortes compartió la documentación de precios de Meta que indica que se cobrarán los mensajes que no son plantillas cuando se usa WhatsApp Cloud API, algo que afecta a quienes tienen bots de atención. Facundo García Martoni, que ya estaba al tanto, compartió el comunicado que envió a sus clientes como base para otros con negocios similares, y estimó que el costo de mensajes salientes podría aumentar entre 300% y 400% para una empresa media. Se discutió si se podía seguir respondiendo manualmente desde la app: Facundo explicó que un número queda atado a la app o a Cloud API, no a ambas, y Benjamin aportó que existe un modo de coexistencia, habilitado mediante el flujo Embedded Signup (Kapso lo ofrece), aunque Facundo nunca logró que le funcionara. Como posible parche, Facundo propuso que WhatsApp responda a cualquier mensaje solo con un botón que abra una sesión de chat web propia dentro del navegador interno de la app, idea que también circulaba en foros. Jeremias Alvarez advirtió que Telegram empezó a cobrar una suscripción mensual en algunos países.
Nahuel Serrudo, que tenía Windsurf Pro y el plan de Gemini, pidió recomendaciones sobre qué pagar en herramientas de IA con buena relación precio/contenido. Facundo Padilla armó un ranking de menor costo y mayor retorno: OpenCode Go (agregador de modelos abiertos por unos 5 USD el primer mes y 10 después), Cursor de 20 USD con su modelo propio Composer, muy bueno para codear, Cursor de 70 USD para planificar con Opus y ejecutar con subagentes de Composer, y luego los planes de 100 o 200 USD de Codex o Claude. Facundo García Martoni resumió su regla: con menos de 100 USD por mes, Cursor; con más, Codex, que es su preferencia en planes caros. Jeremias Alvarez confirmó el buen retorno de Cursor, cuyo plan de 20 USD incluye además saldo para usar otros modelos como Opus, GPT, Kimi o GLM. Hubo consenso en que Gemini no rinde tanto para programar, aunque Facundo García Martoni destacó que los modelos chicos de Google, como Gemini 3.1 Flash Lite y Gemma, son excelentes. Nahuel decidió probar Cursor y Codex.
Un miembro de la comunidad preguntó cómo evitar que Claude Code u otros agentes pidan confirmación a cada rato para ejecutar comandos de verificación. Facundo Padilla mencionó el flag --dangerously-skip-permissions, que ejecuta todo sin preguntar, y el modo automático que se activa con Shift+Tab. Otro miembro señaló que los comandos más incómodos de aprobar son del tipo node -e con código inline, porque uno no sabe bien qué está aceptando. Otro miembro propuso una alternativa más segura: configurar en el archivo settings.json de Claude Code una lista de comandos permitidos, normalmente de solo lectura, e incluso pedirle al propio Claude que la configure. También se compartió el enfoque 'AFK' de un creador de contenido: dejar a varios agentes implementando en paralelo en worktrees sin supervisión, algo que solo funciona bien si antes se planificó con cuidado. Facundo Padilla coincidió en que la clave es una buena planificación previa, y Tobías Paz Posse abrió la pregunta de si conviene aplicar TDD en estos flujos.
Nacho Albarracin preguntó si el agente de un miembro que participaba en el grupo usaba la API oficial de WhatsApp. Lucas Juárez y Facundo Padilla explicaron que la API oficial (WhatsApp Cloud API de Meta) no permite interactuar en grupos, y que los bots que lo hacen suelen usar Baileys, una librería no oficial que se conecta como si fuera WhatsApp Web. Facundo García Martoni confirmó que su agente Hermes funciona con Baileys, aunque Hermes soporta ambas opciones. Nacho contó que estaba configurando un bot con la API oficial para un proyecto personal y no encontraba cómo habilitar grupos; le confirmaron que no es posible y terminó migrando a Baileys con un número aparte por precaución, ya que el uso no oficial puede derivar en bloqueos. Facundo García Martoni aconsejó no complicarse con la API oficial para proyectos personales, y Facundo Padilla recomendó Kapso (plataforma sobre la API oficial con un cupo de mensajes gratuitos) cuando sí se necesita la vía oficial.
Un miembro de la comunidad presentó un sistema en el que un agente de IA, en este caso Hermes con el modelo MiniMax M3, controla remotamente un teléfono Android real: ve la pantalla, toca, escribe y abre cualquier aplicación. En la demo el agente entraba a una app de home banking a consultar saldos y enviaba un mensaje con una foto por WhatsApp, todo de forma autónoma a partir de un objetivo. Ante la pregunta de Lucas Juárez sobre si había que rootear el teléfono, aclaró que no: usa permisos nativos de Android de accesibilidad y de compartir pantalla, con una app que corre en segundo plano (conviene excluirla de la optimización de batería) y un servidor MCP (Model Context Protocol, estándar para exponer herramientas a agentes). Facundo Padilla preguntó por aplicaciones de negocio y el autor señaló los casos donde no existen APIs para terceros, como conciliaciones bancarias automáticas consultando saldos con una tarea programada, algo que coincidía con una necesidad real que Facundo tenía en una fundación. Las limitaciones mencionadas fueron la huella y el segundo factor de algunas apps bancarias.
Facundo Padilla necesitaba desplegar de la forma más económica posible el backend de un proyecto con poco tráfico (unas 800 visitas mensuales y alrededor de 40 usuarios), y días antes había preguntado cuánto se paga por un Postgres gestionado en AWS o Azure. Comentó que no encontraba la oferta de Hetzner de 4 USD que se suele citar. Nacho Albarracin sugirió DonWeb, que ofrecía un VPS con 2 vCPU, 4 GB de RAM, 100 GB de disco, backup semanal y 3 TB de transferencia a un precio bajo en pesos. Leonel Pérez propuso funciones serverless (por ejemplo en GCP, casi gratis con ese tráfico) si no importa el cold start, aclarando que eso no incluye la base de datos; si es solo backend alcanza, y si no, conviene un VPS. Nahuel Serrudo mencionó Hostinger, barato pero con descuentos atados a pagar varios años por adelantado. Facundo Padilla desaconsejó HostGator por una mala experiencia: le cambiaban la contraseña del VPS sin avisar. La conclusión fue que, para ese volumen, un VPS barato como DonWeb era la opción más conveniente.
Exequiel De Freitas preguntó cómo hacen quienes crearon productos o SaaS para encontrar un buen nombre, ya que suele tardar semanas y al pedirle ideas a una IA la mayoría son malas, y las buenas ya tienen el dominio .com ocupado o están registradas como marca. Facundo Padilla sugirió inspirarse en cómo se nombran las herramientas de DevOps, como Ansible, Docker, Kubernetes o Podman. Facundo García Martoni compartió los consejos que aplicó al nombrar su startup con ayuda de un modelo de IA: mantener el nombre corto; no nombrar por el producto, porque un pivot futuro lo dejaría desactualizado; y definir entre tres y cinco valores de la marca, buscar palabras que los representen en distintos idiomas y alterarlas levemente. Citó el caso de Vercel, cuyo nombre fue estudiado por lingüistas para que suene bien en muchos idiomas. Agregó que no conviene obsesionarse con conseguir el .com: si está disponible, mejor, pero para un buen nombre lo más probable es que no lo esté.
Leandro Andriani pidió recomendaciones de videos, libros o documentación para empezar con Docker desde cero. Agustín Sánchez compartió el curso de Docker disponible en el sitio de Programa Con Nosotros, y Leonel Pérez recomendó el video introductorio del canal Hola Mundo, que recordaba como muy claro. Marcelo Nuñez aportó un enfoque práctico: la mejor forma de aprender es tomar una aplicación propia y dockerizarla (empaquetarla en una imagen de contenedor con todas sus dependencias). Leandro coincidió en que aprende más rápido con lo práctico, aunque sin querer saltearse conceptos fundamentales. Al día siguiente, Jesús Zelarayan sumó como recurso un curso gratuito de Docker desde cero publicado por midudev. La recomendación general fue combinar un curso introductorio con la práctica de contenerizar un proyecto real.
Facundo García Martoni compartió Google AI Edge Gallery, una aplicación oficial de Google disponible en Play Store que permite descargar y ejecutar modelos de lenguaje localmente en un teléfono Android, usando la GPU del dispositivo, algo así como un Ollama para Android. Mostró que incluye Gemma 4 (la familia de modelos abiertos de Google) y también modelos como Qwen y DeepSeek, y que en su prueba respondía muy rápido. Iñaki Fernando Lozano comentó que la había probado tiempo atrás como APK y funcionaba regular, pero que probablemente mejoró con los modelos nuevos. Ante la pregunta de si los modelos eran gratuitos, se aclaró que corren 100% en el dispositivo, sin costo por uso. Se discutió la idea de reutilizar teléfonos viejos como servidores de inferencia barata, con la batería como limitación, y un miembro contó que usa Qwen en una notebook antigua con 2 GB de RAM.
Facundo García Martoni contó que armó con Hermes (un agente de IA autoalojado de Nous Research) una tarea programada que resume cada mañana su feed de X. Eligió twscrape, una librería no oficial de scraping, porque hacerlo con xurl, la CLI oficial basada en la API de X, le costaría unos 60 USD diarios; deja xurl solo para publicar. La implementación: usando sus cookies de sesión, cada hora scrapea los posts de 'Para ti', guarda los resultados crudos en un archivo .jsonl dentro de su bóveda de Obsidian en un VPS, y cada mañana genera un resumen que le envía por Telegram. Iñaki Fernando Lozano coincidió en que la API de X es excesivamente cara. Agustín Sánchez valoró la idea para evitar el consumo compulsivo de redes y sugirió que podría convertirse en un SaaS; Facundo Padilla sumó la skill last30days, que investiga lo ocurrido sobre un tema en los últimos 30 días. Facundo García Martoni también recomendó NextDNS para bloquear redes sociales por DNS con horarios, y días después Iñaki presentó una app propia basada en twscrape para extraer y exportar posts de X a PDF o HTML.
Nicolas Fuentes pidió recomendaciones de aplicaciones para transcribir y resumir reuniones de Meet, Teams u otras plataformas sin que un bot se una visiblemente a la llamada. Surgieron varias opciones: Facundo Padilla sugirió Read AI, Mateo Antenucci recomendó Tactiq, y tanto Nacho Albarracin como Tomas Fernandez Murga mencionaron Fathom (un asistente de notas con IA). Otro miembro de la comunidad recomendó Granola con muy buena experiencia: contó que nunca pagó y que la usa para resumir todas sus reuniones diarias. Granola, a diferencia de otras herramientas, captura el audio desde la propia computadora en lugar de meter un participante extra en la reunión, que era justamente lo que se buscaba. No hubo una conclusión única, pero Granola y Fathom fueron las opciones con más respaldo.
Un miembro de la comunidad presentó Cloudish, una aplicación web que desarrolló para diseñar diagramas de arquitectura usando exclusivamente servicios de AWS. Explicó que existen herramientas similares, algunas genéricas de UML y una oficial de AWS, pero quería una con su propio flujo de trabajo. Facundo Padilla sugirió que sería muy útil que el diagrama pudiera traducirse a Terraform (una herramienta de infraestructura como código que permite declarar recursos cloud en archivos y aplicarlos de forma reproducible). El autor contó que ya tiene una exportación a Terraform, aunque todavía experimental. Facundo Padilla imaginó un caso de uso interesante: alguien que conoce bien AWS pero no Azure o GCP podría modelar su arquitectura con conceptos de AWS y usar la exportación como punto de partida para llevarla a otro proveedor.
A lo largo de varios días Facundo Padilla compartió pruebas con distintos kits de skills para agentes de código. Primero comparó Stitch (herramienta de diseño de UI con IA de Google) contra OpenDesign, planificando con el modelo GLM 5.2 y la skill impeccable (orientada a pulir UI) y ejecutando con Claude Opus 4.8, y quedó conforme con el resultado. Luego detalló su experiencia: superpowers (skills que hacen trabajar más a fondo al agente, con brainstorming, planes y TDD) tiende a sobreingeniería, pero relaciona mejor datos, archivos y configuraciones; lo compensa auditando el resultado con ponytail, que tiene una skill de auditoría muy buena aunque no evalúa qué patrón de diseño conviene ni la reutilización. Comparado con gentle-ai (ecosistema con unas ocho skills por capas, más metódico y lento, que permite elegir modelo por etapa), superpowers le resultó más rápido. Usa engram como memoria persistente, que mejora la compactación de contexto aunque olvida detalles. Su veredicto: superpowers + ponytail + engram por encima de gentle-ai, y ambos mejor que usar el agente sin nada. También recomendó nuclei, un escáner de seguridad integrable en pre-commit y CI/CD.
Iñaki Fernando Lozano compartió el anuncio de GPT-5.6 de OpenAI, que llegaría en dos variantes (Sol y Luna). Ante la pregunta de Marcelo Nuñez sobre qué medía el gráfico comparativo, Iñaki explicó que era Terminal-Bench 2.1, un benchmark que evalúa el desempeño de un agente ejecutando tareas en una terminal, y advirtió que muchos benchmarks ya están muy vistos: los modelos se terminan entrenando para rendir bien en ellos (overfitting) y aparece lo que se llama un modelo 'jagged', con capacidades muy desparejas entre lo que muestran los benchmarks y lo que rinden en uso real. Recomendó investigar esos conceptos antes de sacar conclusiones. Facundo García Martoni repasó el blog del lanzamiento: destacó el foco en eficiencia, el precio bajo de la variante Luna (cercano a un modelo 'flash') con puntajes superiores a Opus en esos benchmarks, y que el acceso inicial sería limitado a socios, con disponibilidad general estimada en alrededor de un mes, primero en Codex y la API y luego en ChatGPT.
Facundo García Martoni contó que estaba construyendo un CRM propio para su startup con una idea poco convencional: que la interfaz web sea solo de lectura y que todas las altas, ediciones y bajas se hagan conversando con un agente (Codex, Hermes u otro), por ejemplo diciéndole 'acabamos de convertir al cliente X, agregalo'. Facundo Padilla planteó el problema de cómo autenticar al agente y propusieron alternativas: JWT, OAuth como en CLIs profesionales (con la molestia de reautenticarse), un secreto permanente o un esquema tipo clave pública SSH, e incluso fantasearon con un protocolo de autenticación pensado para agentes. Al pedirle a Codex que lo diseñara, este propuso algo más simple: no hacía falta una CLI, alcanzaba con documentar el contrato REST de la API HTTP dentro de una skill (un paquete de instrucciones que el agente carga cuando la tarea lo requiere). Además, esto habilita automatizaciones programadas, como guardar a diario un análisis de la competencia en una línea de tiempo del CRM. Su conclusión fue que un CRM tiene que mantenerse prácticamente solo.
Facundo Padilla contó que empezó a usar git worktrees (una función de Git que permite tener varias ramas del mismo repositorio checkouteadas a la vez, cada una en su propia carpeta) para hacer muchos cambios en paralelo sobre un repo de pruebas, con un agente de IA trabajando en cada worktree. Jesús Zelarayan preguntó cómo se evita que los cambios sobre un mismo repositorio se pisen entre sí. Facundo Padilla aclaró la diferencia entre dos conceptos que suelen confundirse: Git Flow es una convención de ramas para coordinar el trabajo entre varios desarrolladores y que no se pisen, mientras que los worktrees resuelven un problema local, cuando una misma persona necesita trabajar simultáneamente en varias ramas del mismo repo sin estar cambiando de rama ni haciendo stash. La conclusión práctica fue que los worktrees son la herramienta natural para correr varios agentes en paralelo, cada uno aislado en su rama y su directorio.
Loïk Choua preguntó si alguien usaba Eve, la propuesta de Vercel para construir y desplegar agentes. Contó que empezó a usarlo para dos casos: un agente que guía a nuevos usuarios en la configuración inicial de un cerebro organizacional (una base de conocimiento compartida para equipos y product managers, en la que trabaja) y otro que responde preguntas a partir de ese contenido. Le funcionaba bien, pero no le convencían los conectores de Vercel porque generan mucha dependencia de la plataforma, por lo que armó su propio conector para Slack. Facundo García Martoni opinó que este tipo de herramientas son necesarias para empezar a definir un estándar y como punto de entrada para nuevos desarrolladores, aunque considera que es temprano para fijarlo. Loïk Choua respondió que sirven para tener agentes listos para producción rápidamente, sobre todo en flujos internos u operativos y no en el núcleo del negocio. Facundo García Martoni coincidió y mencionó Claude Managed Agents como alternativa para agentes simples.
Facundo García Martoni contó cómo encaró una funcionalidad de arquitectura muy compleja para su startup: llamadas telefónicas atendidas por IA, para no depender del alto costo de ElevenLabs. En lugar de diseñar la arquitectura desde el inicio, hizo una larga sesión con las skills grill-with-docs (el agente hace preguntas para refinar los requisitos) y to-prd (genera un documento de requisitos), fijó como criterio de aceptación una prueba end to end demostrable y dejó a Codex con GPT 5.5 trabajando con /goal casi 24 horas. Obtuvo un prototipo funcional de unas 25.000 líneas que todavía no comprende en detalle; el plan es simplificarlo con nuevos objetivos, crear artefactos HTML para monitorear componentes y usar la skill /teach de Matt Pocock para entender la arquitectura. Lo describió como esculpir: de la piedra a la forma. Para disimular la latencia usa frases de relleno, como en los antiguos sistemas IVR. Facundo Padilla sugirió LiveKit, un framework open source de comunicación en tiempo real, y Facundo García Martoni vio útil su media server.
Leandro Contrera preguntó qué casos de uso encontraron para los WebSockets. Agustín Sánchez contó que los usa en un juego propio, en una app de quizzes para eventos y en una plataforma de consultas veterinarias con videollamadas, y los definió como el protocolo para comunicación en tiempo real entre cliente y servidor. Iñaki Fernando Lozano explicó que en HTTP el cliente hace una petición y recibe una respuesta, por lo que para un chat habría que consultar periódicamente al servidor (polling), mientras que un WebSocket mantiene abierto un canal bidireccional donde el servidor también puede iniciar el envío. Agregó que en los juegos se usa mucho UDP, que a diferencia de TCP no garantiza la entrega ni el orden de los paquetes: se pierde algún dato, pero se evitan bloqueos, lo que se percibe como un pequeño salto cuando hay pérdida de paquetes. Ante la duda de Jesús Zelarayan, aclaró que WebSocket se construye sobre TCP y conserva su control de transmisión. Ezequiel Sánchez mencionó QUIC, el protocolo sobre UDP en el que se basa HTTP/3.
Agustín Sánchez preguntó si alguien ya usaba loops, una técnica en la que un agente repite un ciclo de trabajo de forma autónoma hasta cumplir una condición. Facundo García Martoni describió su skill Macch Babysit: al terminar una rama, abre la PR y le pide a Codex que la supervise. El agente corrige los fallos del CI con nuevos commits, lee los comentarios de los bots revisores, evalúa según las decisiones de diseño del proyecto si vale la pena aplicarlos y repite el proceso hasta que la PR quede en verde. Al final genera un reporte HTML que clasifica cada comentario y explica la solución aplicada, y a veces revierte alguna. Señaló que Cursor Bugbot es, por lejos, el mejor revisor que probó, seguido por CodeRabbit. Agustín Sánchez agregó dos loops vistos en un video: uno que refina los issues del backlog en GitHub o Linear y otro que toma los issues ya refinados y los implementa. Quedó en contar los resultados de sus experimentos.
Agustín Sánchez contó que con la suscripción de 20 dólares de Vercel tiene decenas de proyectos desplegados con distintos ambientes. Facundo García Martoni comentó que el mes anterior le cobraron 35 dólares por un solo proyecto con poco tráfico, principalmente por tiempo de cómputo. Agustín Sánchez sugirió que podía deberse a más tráfico o a un ataque, y recomendó configurar el firewall de Vercel y un límite de gasto, ambos disponibles en la plataforma; también mencionó que antes era común usar Cloudflare como firewall delante de Vercel y advirtió que la optimización de imágenes viene activada por defecto y puede resultar cara, por lo que conviene desactivarla si no se necesita. Jeremias Alvarez recordó un caso conocido en el que Netlify facturó más de 100.000 dólares a un sitio simple porque bots descargaban repetidamente un archivo de audio. La conclusión fue proteger todos los proyectos con firewall y límites de gasto. Agustín Sánchez también compartió ui-skills.com, un sitio con skills para agentes orientadas a diseño, presentaciones y videos.
Un miembro de la comunidad preguntó cómo sumar envíos con cadetes y seguimiento de pedidos dentro de una ciudad a un sistema de ventas de un emprendimiento pequeño. Exequiel De Freitas, que trabaja en un TMS (sistema de gestión de transporte, que cubre creación de viajes, seguimiento, estados y rendiciones), explicó que para clientes de logística grandes es prácticamente obligatorio integrarse con Sitrack, muy usado en el sector, mientras que para clientes chicos y medianos alcanza con Google Maps y WebSockets para enviar actualizaciones en tiempo real. Sebastián Soraire advirtió que el plan gratuito de la API de Google Maps limita la cantidad de consultas y la precisión, y sugirió evaluar las APIs de seguimiento de correos como Andreani, OCA o Correo Argentino. Iñaki Fernando Lozano recomendó leer bien los límites del plan gratuito y configurar topes cerca del 90%, porque una vez recibió un cobro inesperado. Exequiel De Freitas agregó que en logística de camiones hay un nicho interesante, porque muchos sistemas existentes son antiguos.
0dc36b52 participantes
Sebastián Soraire le pidió a Alejo Boga que ampliara ideas de su charla sobre cómo construir una carrera exponencial en tecnología: cómo avanzar más rápido y enfocado, cómo trabajar mucho sin caer en el burnout y cómo evitar el estancamiento. Alejo Boga respondió que en los primeros años conviene hacer más de lo que se pide y buscar la excelencia; a veces basta con trabajar de forma consistente y sumar una hora diaria de formación. Para ganar foco recomendó quitar las redes sociales del teléfono y revisarlas una vez al día desde la computadora. Para evitar el estancamiento sugirió tomar riesgos calculados, entender cómo gana dinero la empresa donde uno trabaja y cómo lo hacen otros mercados, y evitar saltos laterales que no se alinean con los objetivos propios. Aclaró que se trata de experiencias personales y que cada uno debe evaluar sus riesgos. Sebastián Soraire sumó la importancia del orden de la empresa, los riesgos de la multitarea y el autoconocimiento para tomar mejores decisiones.
Facundo Padilla compartió una técnica para escribir escenarios de BDD (desarrollo guiado por comportamiento): narrarse a uno mismo los pasos seguidos para llegar a un resultado y llevarlos a un formato Gherkin (lenguaje estructurado de tipo Dado/Cuando/Entonces), lo que ubica la descripción en un punto medio entre lo técnico y lo genérico; si la entiende un Product Owner, está bien escrita. Contó que armó dos sets de pruebas con catorce casos en Xray (extensión de Jira para gestión de pruebas), cada uno con objetivo, alcance, criterios de aceptación y evidencias, para un cambio de solo veinte líneas de código. Opinó que este nivel de documentación es costoso, pero reduce mucho el margen de error de los agentes y puede convertirse en skills. Agustín Sánchez preguntó si Xray tiene MCP o API; Facundo Padilla supuso que podría usarse mediante el MCP de Jira. Un miembro de la comunidad comentó que usó Zephyr, una herramienta similar, y que estaba evaluando Qase, que tiene MCP y asistentes de migración.
Facundo García Martoni publicó, junto con su agente Hermes, un repositorio open source con una skill para emitir facturas electrónicas en ARCA (el organismo tributario argentino, ex AFIP) desde el agente, pensada para monotributistas que todavía facturan manualmente. Explicó sus decisiones de diseño: el objetivo de validación fue emitir una factura de 1 peso, siempre muestra un borrador antes de emitir porque la operación es irreversible y las credenciales se guardan en una carpeta local. Leandro Andriani preguntó cómo se manejan las caídas frecuentes del servicio y el riesgo de duplicar facturas en los reintentos. Facundo García Martoni sostuvo que la skill indica explícitamente que facturar es irreversible y que podría agregarse una instrucción para reintentar tres veces ante errores transitorios. Facundo Padilla propuso un enfoque más determinista: una cola con reintentos y un chequeo de estado del servicio antes de operar, lo que ahorra tokens y evita que el agente intente corregir cosas por su cuenta. La propuesta fue bien recibida.
Jeremias Alvarez buscaba una opción barata para un sistema de gestión en React y Node usado por pocas personas, sin pagar 20 dólares mensuales. Se mencionaron VPS de Hostgator con descuentos promocionales, Hostinger y Donweb. Facundo Padilla y Juan Arismendi explicaron que Render tiene un plan gratuito que apaga el servicio por inactividad, lo cual se evita con UptimeRobot (un monitor que hace una petición cada cinco minutos), pero que la base de datos gratuita se elimina al mes, por lo que para producción hay que pagarla. Jeremias Alvarez optó por el plan de 5 dólares de Railway y luego contó que le funcionaba bien. Leandro Andriani comentó que comparte un VPS con un amigo. Días después, ante consultas sobre servidores Node con WebSockets y bots de Telegram, Gonzalo Morales recomendó Seenode (desde 3 dólares) y advirtió que el plan gratuito de Render tiene arranques en frío de unos 50 segundos, Ignacio Fonts dijo que Render funciona bien para WebSockets y Martin Uslenghi sugirió Cloudflare Workers, cuyo plan gratuito es generoso para lógica simple sin servidor.
Después del evento con charlas de miembros de la comunidad realizado en la universidad, Facundo García Martoni compartió sus notas. De la charla de Alejo Boga sobre crecimiento de carrera rescató la idea de crecimiento exponencial, que relacionó con automatizar procesos propios con agentes. De la de Agustín Sánchez tomó el concepto de paralelizar el trabajo con worktrees, que al día siguiente le permitió mergear cinco PRs y resolver unos diez tickets en seis horas trabajando con tres a cinco worktrees a la vez. De la de Marcelo Nuñez destacó que las expresiones regulares no son adecuadas para procesar JSON o XML, algo útil para detectar malas soluciones propuestas por un modelo. De la de Franco Espinoza, sobre agentes, rescató el ciclo de vida de un agente que comienza por la percepción y la idea de que la IA no puede comprender la intención. De la de Fabio Ramos, que una interfaz no siempre debe ser minimalista cuando se diseña para usuarios avanzados. Y de la de Salvador Juárez, su proyecto de un sistema operativo en el navegador, cuyo repositorio compartió después.
Un miembro de la comunidad preguntó qué suscripción conviene pagar tras vencer su plan de 20 dólares de Claude, que le alcanzaba para frontend y backend. Leandro Contrera recomendó Codex. Iñaki Fernando Lozano sugirió quedarse con Claude si le rinde, porque considera que Codex es mejor en general, pero no logra con él frontends de la calidad de Claude. Facundo Padilla recomendó Stitch de Google, que mejoró mucho y aporta mejores ideas visuales, aunque improvisa si no se le especifica bien, y mencionó que la skill de Impeccable le permitió llevar diseños a código con un 60 a 70% de fidelidad usando Opus 4.8. Días antes, ante un pedido de ideas para una landing, se habían sugerido AI Studio, Canva, Claude Design, Figma, Lovable, v0 y Stitch. Más adelante, ante otra consulta, Facundo Padilla explicó que el plan Max de 100 dólares ofrece los mismos modelos que el Pro, pero con una ventana de uso mucho mayor.
Facundo García Martoni sumó su agente Hermes al grupo y explicó el motivo: reducir su tiempo en redes sociales. Cuando está concentrado y quiere compartir algo, se lo pide al agente, que lo publica sin que él tenga que abrir WhatsApp y exponerse a mensajes pendientes. Configuró el agente para obedecer solo sus instrucciones, y varios miembros intentaron sin éxito hacerle prompt injection (instrucciones maliciosas para que ignore sus reglas). Luego armó un conector para publicar en X usando xurl, la librería oficial que usa Hermes, con un mínimo de 5 dólares de crédito en la API de X. También contó cómo implementó recordatorios por voz: un cron verifica mediante Tailscale (una VPN que conecta dispositivos propios) si su Mac está desbloqueada, genera audio con el TTS de ElevenLabs y lo reproduce; si no, envía el recordatorio por WhatsApp. Planea sumar detección de palabra de activación con openWakeWord. Además, usó un cron con Tailscale para apagar su televisor a determinada hora y así dormirse más temprano.
Agustín Sánchez preguntó qué tareas le delegan a Hermes Agent (agente personal open source de Nous Research que corre en un servidor y se integra con Telegram, Discord o WhatsApp). Facundo Padilla contó que entra a clases de Zoom, las graba y las sube, y que clasifica correos con expresiones regulares, activando un agente solo cuando una regla no alcanza. Mauro Torres describió tareas diarias como investigar en X, buscar oportunidades de negocio, listar trabajos freelance y generar publicaciones, y recomendó browser-use para navegación, la skill manim-video para generar videos y el comando /goal para tareas largas. Se destacó la función de perfiles, que crea agentes aislados por tarea. Sobre modelos, Facundo Padilla usa MiniMax M3 con la suscripción económica de opencode go, y Mauro Torres recomendó los modelos gratuitos del portal de Nous Research para empezar, ya que la configuración inicial consume muchos tokens. Días después, al consultarse por el hosting, se mencionaron VPS de Donweb y Hostgator, y Facundo Padilla desaconsejó OpenRouter por latencia frente a Nous.
Tras el anuncio de un nuevo modelo de Anthropic, el grupo comparó herramientas. Agustín Sánchez dijo que venía trabajando muy bien con Claude Code y Opus 4.8, mientras que Facundo García Martoni se mostró escéptico con Anthropic y recomendó Codex con GPT 5.5, aclarando que conviene a partir de la suscripción de 100 dólares y que con menos presupuesto es mejor Cursor; mantiene Cursor por Bugbot, su revisor automático de PRs. Iñaki Fernando Lozano opinó que Codex es algo mejor, pero que Claude tiene mejor criterio estético. Mauro Torres explicó que el CLI o el modelo importan menos que el flujo de trabajo: usa Claude Code para proyectos grandes, opencode con modelos gratuitos para proyectos chicos y pi agent con GPT Codex, todo dentro de Warp (una terminal con funciones agénticas) y conectado a Linear o GitHub Projects. También se compartieron los dynamic workflows de Claude Code, que arman flujos de trabajo sobre la marcha. Facundo Padilla notó que el modelo funciona mejor en CLI que en su IDE y con planes bien especificados (SDD).
El lanzamiento de Fable, presentado en el chat como el nuevo modelo de Anthropic disponible para el público general, generó varias opiniones. Varios miembros señalaron que consume la cuota de uso muy rápido: Tomas Fernandez Murga contó que una sola consulta simple le consumió cerca del 20% de su uso, y otro miembro mencionó que su costo es el doble que el de Opus. Facundo García Martoni compartió las evaluaciones públicas de Cursor para ubicarlo frente a otros modelos. Franco Perez lo probó para revisar documentos y le pareció que encuentra huecos que Opus no había detectado, aunque opinó que cada vez importa más el harness que el modelo. Facundo Padilla describió su flujo: usó Fable u Opus para las bases del proyecto (brandbook, sistema de diseño, arquitectura), convirtió tareas repetidas en skills y luego dividió planes grandes en tareas chicas para que las ejecute Sonnet, ya que intentar tareas grandes de una sola vez desperdicia tokens y el modelo empieza a desvariar cuando se llena el contexto. Más adelante se comentó que el acceso fue restringido temporalmente.
Mauro Torres preguntó qué capa de memoria usa cada uno, mencionando claude-mem y Engram. Facundo García Martoni respondió que solo usa el memory.md automático de Codex y que suele quitar más de lo que agrega, porque la memoria ensucia el contexto. Al día siguiente contó que instaló Mem0 (un servicio de memoria de largo plazo para agentes) en Hermes para aplicar las cuatro capas de memoria que propone ese agente: archivos nativos MEMORY.md y USER.md con límite de caracteres, una herramienta de búsqueda en sesiones anteriores, un proveedor externo (como Honcho, Mem0, OpenViking o SuperMemory) y Obsidian como repositorio de información cruda. Destacó que Mem0 tiene un plan gratuito generoso y plugins para usar la misma memoria en Codex y Claude Code. Mauro Torres prefiere guardar todo en Markdown siguiendo el concepto de LLM wiki (una base de conocimiento en archivos que el propio modelo mantiene), visualizable como grafo. Facundo Padilla opinó que Engram sirve para tareas chicas, pero que para especificaciones más exigentes es mejor OpenSpec con archivos .md.
Mauro Torres planteó que convenía aprovechar los precios actuales porque, a su juicio, cuando terminen los subsidios habrá una brecha entre quienes puedan pagar IA de calidad y quienes no. Facundo Padilla respondió que los modelos chinos, bien acompañados por un buen harness, skills, especificaciones y MCPs, serán accesibles y suficientes, especialmente si se los especializa en tareas puntuales. Facundo García Martoni amplió la idea: la industria del hardware apunta a los modelos locales y no hace falta un modelo de primer nivel, sino alcanzar localmente y a buena velocidad el equilibrio que lograron Opus 4.5 o GPT 5.5; en su opinión, los laboratorios chinos y Google con Gemma están mejor posicionados. Facundo Padilla agregó que un buen harness hace al modelo más determinista, apoyándose en scripts reutilizables y herramientas estáticas, y que hay que detallar los casos borde. Días después, Facundo García Martoni contó que en su startup redujeron a la mitad el costo de inferencia con mejores resultados, y concluyó que la inteligencia va a bajar de precio.
Un miembro de la comunidad preguntó cómo manejan los git worktrees (copias de trabajo paralelas de un mismo repositorio, útiles para correr varios agentes a la vez) en Claude Code: cómo limpiarlos automáticamente y cómo evitar que el settings.json se llene de permisos y rutas absolutas. Facundo García Martoni explicó que en Codex usa los local environments para preparar un worktree al iniciar cada conversación y una automatización semanal que elimina los que ya no se usan, y compartió el script con el que los inicializa. Más tarde, Geronimo Rios consultó cómo administrar el consumo de tokens en Claude. Facundo Padilla recomendó usar Opus para planificar, Sonnet para ejecutar y Haiku para comandos simples, y mencionó el modo opusplan. Iñaki Fernando Lozano contó que trabaja con una sesión principal que funciona como orquestadora y delega cambios acotados a subagentes para no llenar su contexto, y que cuando se acerca al límite genera un resumen de traspaso y compacta la conversación.
Facundo García Martoni preguntó qué herramientas conviene usar para producir videos de lanzamiento de funcionalidades. Contó que para grabaciones de pantalla usa Screen Studio, que es pago pero efectivo. Facundo Padilla comentó que él había usado Remotion (una librería para generar videos programáticamente con React) y que otro conocido había hecho un video con Hyperframes, una herramienta que permite a los agentes generar videos a partir de código. Días después, Facundo García Martoni mostró el resultado: un video de lanzamiento creado con Opus 4.8 en Cursor usando la skill de Hyperframes y un archivo DESIGN.md basado en la especificación publicada por Google para describir un sistema de diseño. Le llevó unos tres días y más de veinte intentos ajustar el flujo. Observó que GPT 5.5 es muy bueno replicando una estética existente, pero no tanto creándola desde cero, y comentó que Guillermo Rauch había publicado el DESIGN.md de Vercel como referencia.
Facundo García Martoni contó que se dio cuenta de que podía automatizar gran parte del testing manual con Computer Use de Codex (la capacidad del agente de controlar la interfaz gráfica de la computadora). Dejó a Codex trabajando con el comando /goal (que le asigna un objetivo de largo plazo para trabajar de forma autónoma hasta cumplirlo): probaba casos borde manejando la app de WhatsApp en la Mac, leía los logs y usaba el panel de superadministrador cuando necesitaba hacer ajustes. Facundo Padilla comentó que su experiencia con el /goal de Claude fue peor, porque le hizo gastar tokens y tiempo sin buenos resultados.
Facundo Padilla propuso definir el harness como el repositorio que le da estructura y patrones de navegación al modelo, no como un simple wrapper, y preguntó qué usa cada uno además de AGENTS.md (scripts de inicialización, subagentes, changelogs). Agustín Sánchez comentó que por ahora solo usa AGENTS.md, y ambos notaron que los pre-commit hooks (validaciones automáticas antes de cada commit, con herramientas como ruff, bandit o isort) también forman parte del harness. Un miembro de la comunidad planteó que Claude Code no respetaba la instrucción de leer AGENTS.md desde CLAUDE.md; Mateo Antenucci sugirió crear un symlink entre ambos archivos y Facundo Padilla recomendó un index.md que apunte a documentación por módulo, sin superar unas 200 líneas. Facundo García Martoni recomendó convertir las reglas del repo en una skill corta (menos de 50 líneas) e invocarla explícitamente, y compartió su skill open source de diseño de prompts. Marcelo Nuñez contó que los agentes a veces saltean los hooks con --no-verify; la sugerencia fue correr los mismos chequeos en una GitHub Action.
Facundo Padilla mostró cómo armó su propia alternativa a NotebookLM usando Hermes Agent (un agente personal open source de Nous Research que corre en un servidor y se maneja desde apps de mensajería) junto con Obsidian: sincronizó su VPS, su computadora y su teléfono de modo que cualquier nota creada desde Telegram aparece en tiempo real en todos los dispositivos, y además desplegó Open Notebook, un proyecto open source similar a NotebookLM, en el mismo VPS. Destacó la ventaja de tener los datos propios en un servidor privado sin depender de herramientas pagas como Notion. Facundo García Martoni comentó que quiere armar algo similar y probar GBrain, pero señaló que el punto débil de la privacidad sigue siendo el modelo, ya que prefiere GPT 5.5 y no hay equivalentes locales de ese nivel. Facundo Padilla propuso usar modelos chinos como MiniMax M3, que le estaba dando buenos resultados, aunque reconoció que correrlos localmente sigue siendo el desafío.
Facundo Padilla reportó que Opus 4.8 en modo max fast se olvida detalles con facilidad y hay que corregirlo más seguido que con versiones anteriores, pese a tener una ventana de contexto de un millón de tokens. Leandro Contrera sugirió mantenerse por debajo del 50% de contexto por tarea como mitigación para que el modelo no pierda de vista los requerimientos iniciales.
Facundo Padilla comparó Docling y MarkItDown para convertir documentos a Markdown: MarkItDown resultó más rápida, mientras que Docling se conecta a Hugging Face y usa modelos de IA gratuitos para mejorar la calidad del resultado. Facundo García Martoni anotó MarkItDown de Microsoft para probarla. Ninguna de las dos terminó sirviendo para el caso de uso puntual que tenía Padilla.
Ante la consulta de qué flujos usar para spec-driven development y proyectos de front-end, los miembros recomendaron grill-with-docs de Matt Pocock para armar PRDs, gsd para ejecutar el plan y superpowers como skill complementaria. Facundo Padilla sumó la práctica de volcar toda la documentación relevante a NotebookLM para tenerla accesible desde cualquier herramienta.
Facundo García Martoni describió su primer proyecto serio con Hermes: trackear sus finanzas personales con un enfoque pro-agéntico, volcando todos los gastos e ingresos como logs sin estructurarlos de antemano y dándoles forma dinámicamente al momento de querer realizar un análisis. Facundo Padilla planteó la idea de conectar Hermes a sus billeteras digitales para automatizar el seguimiento, con la seguridad y la falta de APIs públicas como principales obstáculos.
Leandro Contrera preguntó qué interfaz gráfica usar para PostgreSQL y el grupo compartió sus preferencias: Iñaki Fernando Lozano recomendó DataGrip para todas las bases de datos, Facundo Padilla prefería pgAdmin, Marcelo Núñez usaba DBeaver, y Mario Radich destacó Beekeeper Studio por ser open source y multiplataforma. Jeremías Moreno Ivanoff señaló un bug de zona horaria de DBeaver al instalar drivers de Postgres desde Argentina que requería tocar archivos de la instalación manualmente.
Santino, estudiante de segundo año de ingeniería, pidió consejo para diseñar un SaaS donde cada estudio jurídico tenga su propia organización con abogados, clientes, casos, documentos y tareas. El grupo lo orientó hacia los distintos enfoques de arquitecturas multitenant según el nivel de escalado requerido, sugirió evaluar o forkear un sistema open source existente para aportar valor desde el inicio, y recomendó definir primero el objetivo (aprender vs salir a vender) antes de sobre-diseñar la infraestructura.
957039f1 participantes
Marcelo Álvarez preguntó cómo garantizar que un software sea seguro. El consenso fue que ningún software es 100% seguro, pero que conviene apoyarse en el Top 10 de OWASP 2025 para cubrir las vulnerabilidades más comunes, evitar hardcodear o exponer credenciales, proteger rutas contra IDOR y path traversal, y tener especial cuidado con la instalación de dependencias de terceros.
973fcb52 participantes
Ante la consulta de Tobías Paz Posse sobre qué herramienta elegir, el consenso fue Codex si el presupuesto supera los 100 USD y Cursor en caso contrario. Para implementar planes ya definidos, Composer salió bien parado por su precio y velocidad, sobre todo en backend y cuanto más detallada sea la tarea entregada. Leandro Contrera reforzó el enfoque TDD combinado con las Matt Pocock skills para obtener código que compila y pasa los tests desde el primer intento.
Alejo contó cómo implementó seguridad en los chatbots de su plataforma con guardrails que validan el input del usuario, el output del agente y el contexto recuperado por RAG, además de bloquear temas y marcas de la competencia. El grupo recomendó OpenAI Guardrails, el enfoque de LangChain/LangGraph, expresiones regulares revisadas luego por un modelo barato para descartar falsos positivos, y la cheat sheet de prevención de prompt injection de OWASP como referencia.
05c78c92 participantes
Agustín Sánchez planteó el problema de los costos mensuales del code review automatizado, sobre todo por las re-reviews que llegan de a pocos comentarios con Bugbot, encareciendo cada iteración. Facundo García Martoni recomendó combinar Bugbot, CodeRabbit y Qodo (este último con plan free de por vida y reviews de buena calidad). También se comentó Greptile como opción, el cambio de GitHub Copilot a un modelo de facturación por uso y el anuncio de Nvidia de un SoC con GPU y CPU en arquitectura ARM con memoria unificada para Windows.
El grupo comentó la llegada de Minimax M3 frente al 2.7 que varios venían usando. Se destacó la excelente relación precio-calidad del 2.7 (peticiones prácticamente ilimitadas y CLI con imágenes, audio, video y research por 10 USD), mientras que el nuevo modelo subió de precio. Facundo Padilla mencionó que seguiría con el 2.7 hasta evaluar el 3.0.
Se desarrolló PunaTech 2026 en Salta, con un hackathon de dos días y una jornada general que reunió alrededor de 135 personas. Agustín Sánchez dio una charla sobre ingeniería de software con agentes, el workflow de Dizenz para llevar una app desde la idea hasta el release de producción y una guía para sobrevivir a la revolución de la IA en la industria del software. Facundo Padilla y otros miembros del grupo participaron como mentores y organizadores.
Leandro Contrera preguntó cómo ejecutar cualquier comando sin aprobarlo uno por uno en Codex CLI. Iñaki Fernando Lozano explicó el modo de bypass de permisos por sesión, que permite aprobar comandos durante una sesión sin que persista a la siguiente. Se comentó que la configuración varía bastante según el proveedor, el agente y si se usa la app o el CLI.
Iñaki García compartió ModernSysacad, su extensión de código abierto que mejora la interfaz del Sysacad en varias regionales de la UTN (FRT, FRA, FRGP y FRRE), haciéndolo más práctico y visualmente agradable. Disponible para navegadores Chromium y Firefox, invitó a los miembros del grupo a colaborar en el repositorio.
f95daf32 participantes
Con la salida de Opus 4.8, los miembros lo describieron como más agéntico que su predecesor (itera más en tareas largas) aunque todavía con debilidades en casos borde. En paralelo, Facundo García Martoni celebró que Codex agregó la posibilidad de ver el diff por commit en su interfaz —"UI-izó" el git diff— lo que le permitió auditar mejor cambios generados durante un rebase. Facundo Padilla también mencionó Composer 2.5 Fast para ganar velocidad sin sacrificar demasiada calidad.
Conversación práctica sobre cómo dockerizar un stack React + Node y desplegarlo en un VPS. Iñaki Fernando Lozano y Facundo Padilla compartieron sus experiencias con proveedores como Hostinger y la comparación con Vercel para proyectos que requieren más control sobre la infraestructura. También se compararon GUIs de base de datos como MySQL Workbench frente a opciones para PostgreSQL.
Facundo García Martoni recomendó Grammarly para pulir prompts y textos técnicos en inglés, manteniendo el estilo propio de redacción en lugar de delegarle la generación al modelo. Se comparó con las Writing Tools de Apple como alternativa gratuita disponible en macOS, con opiniones divididas sobre cuál resultaba más útil en el día a día.
Facundo García Martoni presentó su skill macch-babysit, que corre cinco proveedores de revisión de código en paralelo (CodeRabbit, Qodo, Bugbot, Vercel y React Review), reduciendo el tiempo de code review de varias horas a unos pocos minutos. También se habló de generar ADRs con grill-with-docs y de usar Sentry para monitoreo de errores en producción.
Facundo García Martoni hizo una comparación detallada de Codex frente a Cursor: a favor de Codex, el uso generoso, el harness y la experiencia en Mac; en contra, el plan mode y la velocidad de respuesta. También se habló de usar git worktrees en Codex junto con un script de configuración del entorno local para aislar tareas largas. Alejo contó que llegó a resolver un sistema completo en una sola sesión con Cursor y Composer 2.5. Se sumó una recomendación de gestores de contraseñas, destacando Bitwarden por ser open source.
Se compartió que Qodo ofrece 30 revisiones de PR gratuitas al mes de por vida, junto con comentarios sobre créditos de tokens para startups que participan de YC. La conversación giró en torno a cómo abaratar el code review automatizado combinando herramientas con planes gratuitos generosos.
7073a39
El grupo analizó dos incidentes de seguridad ocurridos en mayo: una extensión maliciosa de VS Code relacionada con GitHub/TeamPCP que afectó a miles de repositorios, y un ataque de cadena de suministro sobre el paquete tanstack en npm. Chelo recomendó usar pnpm --frozen-lockfile y correr pnpm audit en CI para mitigar riesgos de dependencias comprometidas. También se mencionó el firewall gratuito de Vercel como capa adicional de protección.
90c49be1 participantes
Conversación sobre editores alternativos (Zed vs Neovim) y sobre la ergonomía del puesto de trabajo: sillas, monitores y mouse, con recomendaciones para largas jornadas frente a la pantalla. También se mencionó la cuenta de Instagram aguslogs de Agustín Sánchez.
Con el lanzamiento de Composer 2.5, el grupo celebró su relación precio-calidad, resumida en la frase "nivel de Opus por dos mangos". También se habló de overmind para unificar los dev servers en tmux, del debate AGENTS.md vs CONTEXT.md como archivo de instrucciones para los agentes y de react.review como revisor especializado en código React.
5a9c4712 participantes
Facundo García Martoni compartió su skill babysit-pr para acompañar la revisión de pull requests con un agente. Se generó un debate con Facundo Padilla sobre si conviene invertir en prevenir errores antes del PR o en trackearlos y corregirlos durante la revisión, con argumentos a favor de ambas estrategias según el contexto del equipo.
Se propuso el comando /review de Codex como alternativa integrada a Bugbot para revisar cambios antes de commitear, sin depender de un bot externo de PR. El grupo discutió su calidad de feedback frente a los bots de PR dedicados y los casos en que cada opción es más conveniente.
61ed66a
Tras probar la interfaz de escritorio de Claude Code, los miembros destacaron la posibilidad de correr agentes en paralelo sobre git worktrees y un límite de uso generoso comparado con otras herramientas. Se comparó con el flujo CLI y se discutió cuándo conviene cada uno según el tipo de tarea.
a5d112c
Una encuesta interna midió qué herramienta de IA usaba principalmente cada miembro: Claude Code lideró, seguido de Cursor y Codex. Sirvió como foto del estado de adopción dentro de la comunidad y disparó una conversación sobre los factores que inclinaban la preferencia hacia una u otra herramienta.
05226b3
El grupo exploró cómo reproducir la edición inline estilo Cmd+K de Cursor usando la app de ChatGPT en Mac mediante el atajo Option+Spacebar. También se mencionó groq.com como opción de inferencia muy rápida para quienes necesitan velocidad de respuesta por encima de todo.
514ff9b1 participantes
Facundo Padilla mostró su instancia de Hermes (Nous Research) automatizando tareas reales: se conecta a sus clases de Zoom, las graba, al terminar las sube a GoFile y se las reenvía, además de clasificarle los mails cada cinco minutos. Comentó que quería convertir esto en una skill reutilizable de Hermes para que otros pudieran adoptarla fácilmente.
Ante la búsqueda de alternativas a Cursor Bugbot, el grupo recopiló herramientas de análisis estático y seguridad: SonarQube, Semgrep, Trivy y Bandit, discutiendo cuáles cubren dependencias, código y secretos, y cómo integrarlas en CI.
705992a
Los miembros compartieron cómo pagan las suscripciones en dólares de herramientas de IA desde Argentina, comparando billeteras y tarjetas virtuales como Brubank, Prex, AstroPay, DolarApp, Lemon, Ripio y RedotPay por comisiones y facilidad de uso para servicios internacionales.
caaf5e41 participantes
Agustín Sánchez presentó al grupo la nueva sección de resúmenes de conversaciones del sitio y explicó el flujo de generación. Aclaró que cada resumen pasa por varios filtros para que no comprometan profesionalmente a los miembros ni los expongan ante un eventual doxeo, e invitó a avisar si alguien quería que se editara o quitara alguna nota que lo pudiera comprometer.
Facundo Padilla comparó Devin (SWE 1.6) contra GPT 5.5 en modo XHigh resolviendo un pipeline de .NET con análisis de SonarQube. En su prueba ganó Devin, que manejó mejor el contexto del proyecto y las correcciones sugeridas por el analizador estático. El grupo discutió en qué casos un agente especializado en tareas largas supera a un modelo de propósito general configurado en su máximo nivel de razonamiento.
Surgió la idea de usar la generación de imágenes integrada en Codex para producir diagramas de arquitectura directamente desde la descripción del sistema, evitando herramientas externas. Se debatió la utilidad real frente a diagramas hechos a mano y la precisión de los resultados.
8ef99452 participantes
A partir de las ideas de Karpathy sobre Software 3.0, Facundo García Martoni y Facundo Padilla debatieron si conviene describir el entorno de desarrollo en un SETUP.md legible por el agente (que el agente ejecuta paso a paso) o mantener el enfoque tradicional con Docker. García defendía el archivo de instrucciones como contrato para el agente; Padilla señalaba las ventajas de reproducibilidad de los contenedores.
Iñaki Fernando Lozano compartió datos sobre Colossus, el datacenter de 300 MW de xAI, y el grupo conversó sobre la escala de cómputo detrás del entrenamiento de modelos de frontera y lo que implica para la industria.
bdee58e2 participantes
Joel, desarrollador backend con 6 años de experiencia que llevaba 2 meses desempleado, compartió en el grupo su sensación de estar completamente perdido con el nuevo ecosistema de herramientas. Expresó que no entendía de qué hablaban cuando mencionaban agentes, Cursor, Vercel, n8n y demás, y que sentía que el mercado había cambiado radicalmente. Solo había hecho el curso de Copilot de Microsoft pero sentía que el espectro era muchísimo más amplio. El grupo respondió con empatía y recursos: Facundo García Martoni le recomendó una charla específica de YouTube, Nacho Tello recomendó videos de Midudev sobre OpenCode y workflows actuales. El episodio resonó en el grupo como un recordatorio de la brecha que se estaba generando entre quienes seguían el ecosistema de cerca y quienes no habían podido actualizarse.
El grupo cerró la semana con un debate consolidado sobre qué combinación de suscripciones ofrecía el mejor costo-beneficio para un desarrollador activo. La conclusión de Facundo García Martoni, que se volvió el consenso del grupo, fue que el setup ideal era Cursor USD 20 (para usar Composer full-time para tareas livianas e iteración rápida) más Codex USD 100 (para GPT 5.5 Extra High en tareas pesadas de arquitectura y backend). Claude Max de USD 100 seguía siendo apreciado por algunos (Agustín Sánchez seguía usando Claude Code con Opus y Sonnet), pero la narrativa dominante había girado hacia OpenAI como proveedor principal por primera vez en la historia del grupo. Facundo Padilla mantuvo su lealtad a Cursor de USD 20 más la estrategia de usar Hermes con modelos económicos. Iñaki Fernando Lozano migró de Claude USD 200 a Codex USD 100 durante esta semana.
Facundo García Martoni compartió una charla reciente de Andrej Karpathy que el grupo consideró muy importante para entender la dirección del software. Las dos ideas centrales que extrajo fueron: primero, investigar fine-tuning y frameworks de Reinforcement Learning para escapar de la dependencia de los labs y adaptar los modelos al intent específico del producto; y segundo, el concepto de Software 3.0, donde en lugar de ensamblar código se crean entornos donde los datos pueden fluir y transformarse de maneras infinitamente creativas. Iñaki Fernando Lozano confirmó que Karpathy había introducido el concepto de Software 3.0 años antes en una charla en Y Combinator. Facundo Padilla compartió un resumen en español de la charla.
Agustín Sánchez presentó Archicise (archicise.com), el proyecto que construyó durante la hackathon Zero to Agent. La plataforma permitía practicar distintas facetas de arquitectura de sistemas: system design, database design, API design, AI design y OOP design. Cada ejercicio guiaba al usuario a través de pasos para resolver un problema de arquitectura, y el usuario podía hacer diagramas con Excalidraw que el agente tomaba como input para la revisión. Al submitear la solución, el sistema daba un score de 0 a 100 con feedback de fortalezas, debilidades y sugerencias de mejora. La visión era hacerlo SaaS y vendérselo tanto a individuos como a empresas de software para subir el nivel de sus engineers en arquitectura.
Facundo García Martoni anunció que Gemma 4 había llegado a Vertex AI con un precio muy accesible (1.5x el costo de Gemini 2.5 Flash Lite). Sin embargo, reportó una limitación importante: Gemma 4 no funcionaba bien para salidas estructuradas como JSON o modelos Pydantic, ya que se saltaba claves o cambiaba nombres de campos. La solución que implementó fue usar Gemma 4 como modelo principal pero pasarle el output a Gemini 3.1 Flash Lite como 'outputeador de JSONs'. Facundo Padilla y él debatieron si el problema estaba en el modelo o en la infraestructura de Google. También mencionaron que Google iba a descontinuar Gemini 2.5 Flash en octubre, por lo que había que migrar a Gemini 3.1.
Facundo Padilla y Facundo García Martoni debatieron las ventajas de Obsidian versus Notion para distintos casos de uso. Facundo Padilla recomendó Notion para cosas que necesitás tener a mano en todos tus dispositivos (gastos, QR de pasajes, documentación personal) por ser más friendly y multi-plataforma, y Obsidian para cosas técnicas que querés tener en markdown local y 100% privadas. Facundo García Martoni usaba Obsidian para lo personal (y pagaba Obsidian Sync de USD 4 para tenerlo en múltiples dispositivos) y Notion para lo profesional donde necesitaba colaboración. Facundo Padilla comparó Notion con un Toyota Alphard (para toda la familia, caro para modificar) y Obsidian con un tanque de guerra.
Se realizó el evento Zero to Agent en el cowork Once57, con buena participación de la comunidad PCN. Iván Taddei creó un agente orquestador para validar ideas de negocio con subagentes especializados (Analista de Mercado, CFO, Tech Architect) que generaban dashboards en tiempo real. Salvador Juárez desarrolló un entrenador de algoritmos con visualizaciones interactivas. Marcelo Álvarez construyó un Centro de Monitoreo de Crisis Climáticas que analizaba reportes de redes sociales con LLMs para despachar recursos de emergencia. Arturo Grande submitteó su proyecto desafia.tech (preguntados para indie hackers). Agustín Sánchez presentó Archicise (archicise.com), una plataforma para practicar arquitectura de sistemas con feedback de IA y diagramas de Excalidraw. Los proyectos podían submittearse hasta el lunes a las 4am.
Facundo García Martoni compartió una comparativa detallada tras sus primeras horas usando Codex después de haberse quedado sin usage en Cursor Ultra. Listó los pros de Codex: el 'browser use' para debuggear frontend ya estaba implementado, un filtro de rama para ver los cambios de la rama actual, la posibilidad de referenciar partes del chat al estilo Canvas de ChatGPT, y un modo de anotaciones que hacía batch de comentarios antes de largarlos. Como contra principal: el Design Mode requería dos clicks en lugar de uno. También destacó el tema de accesibilidad para daltónicos: Codex marcaba las líneas agregadas/eliminadas con íconos además de color. Terminó haciendo downgrade de Cursor Ultra a Cursor Pro.
Facundo García Martoni presentó a Martín Uslenghi como uno de los tipos más inteligentes que conocía. Martín se presentó con un perfil interdisciplinario en el intersticio entre IA y Física: a nivel académico se especializaba en redes neuronales físicamente informadas (PINNs), y a nivel laboral trabajaba en la Dirección de Inteligencia Artificial de la municipalidad de Tucumán y como coordinador académico del área de IA en INI Capacitación. Su trabajo en INI consistía en construir integraciones entre marketing, CRM y agentes de IA para asesoría y ventas, usando embeddings en Chroma DB para sistemas multiagente con bases de conocimiento indexadas.
Agustín Sánchez planteó la duda de si hacer el repositorio de PCN closed-source por razones de seguridad, argumentando que alguien podría analizar las vulnerabilidades del código con IA más fácilmente si era público. Victor Figueredo respondió que mantenerlo open-source tenía más ventajas: cerrado no garantiza seguridad porque el riesgo se reduce pero no se elimina, y en cambio open-source permite que miembros de la comunidad usen IA para descubrir y parchear vulnerabilidades antes de que las explote alguien externo. Facundo García Martoni coincidió y propuso incentivos para que la gente contribuya: remeras o tazas de PCN para quienes tengan una PR mergeada. Iñaki Fernando Lozano recomendó verificar que no hubiera datos críticos expuestos y tener buenos backups. La decisión fue mantenerlo open-source.
Agustín Sánchez compartió una charla de Matt Pocock sobre desarrollo de software en la era de los agentes, que generó bastante discusión en el grupo. Facundo García Martoni compartió sus notas: usar la skill /grill-me antes del modo plan para llegar a un concepto de diseño compartido, desarrollar un glosario del lenguaje ubicuo del dominio, aprovechar TDD definiendo las unidades y qué mockear antes de implementar, y favorecer 'deep modules' sobre módulos superficiales. Citó a Kent Beck: 'Invest in the design of the system every day'. Facundo García Martoni también compartió las skills de Matt en GitHub (mattpocock/skills) y anunció que empezaría a usar /improve-codebase-architecture en Macch día por medio.
Facundo García Martoni abrió un debate controversial sobre si la IA había 'matado al frontend developer', argumentando que en Macch llevaba meses haciendo code review del frontend de manera extremadamente superficial porque los modelos rara vez se equivocaban en tecnologías battle-tested como shadcn y React. Propuso que el frontend era un 'leaf node' del producto y por ende candidato al skip del code review. Alejo defendió el valor del criterio humano en frontend: la IA fallaba en manejo de espacios blancos, proporciones dimensionales, uso de inline styles, decisiones entre flex y grid, y agregaba clases de Tailwind innecesarias. Agustín Sánchez señaló que si el frontend crashea la app, el producto falla independientemente del backend. El veredicto de Facundo fue skipear el code review de la implementación frontend (no del diseño UX/UI) apostando al 'embrace the exponentials'.
La discusión sobre code review derivó en una conversación sobre herramientas de revisión automatizada. Facundo Padilla compartió su stack en el trabajo: pre-commit hooks + SonarQube (análisis de código estático) + Trivy (seguridad de paquetes) + Semgrep (análisis orientado a cyberseguridad). Agustín Sánchez recomendó BugBot de Cursor (USD 40/mes con reviews ilimitadas y free trial de 2 semanas) como su favorito, y también usaba Copilot y CodeRabbit. Señaló que Greptile no lo convencía porque a veces no tiraba ningún comentario en PRs donde Cursor detectaba 8 issues. Facundo García Martoni tomó nota de agregar BugBot y señaló que en Macch usaban Biome y TSC en el pre-commit. También se discutió el uso de worktrees para ser más productivo mientras se espera la revisión.
Facundo Padilla impulsó activamente el reemplazo de openclaw por Hermes Agent de NousResearch en el grupo. Argumentó que openclaw funcionaba mal y gastaba tokens innecesariamente, mientras que Hermes tenía mejor arquitectura, consumía menos recursos (apenas 200MB en un VPS de 4GB de RAM) y la comunidad estaba construyendo cosas muy interesantes encima de él. Compartió que lo usaba con GPT 5.4 mini via GitHub Copilot por USD 10 mensuales ilimitados. Demostró capacidades avanzadas: Hermes con agent-browser de Vercel le permitió navegar la web desde Telegram tomando screenshots del browser headless, se conectó a una reunión de Zoom y hasta grabó la pantalla a 5fps. La comunidad reaccionó con entusiasmo y varios miembros comenzaron a probarlo.
Alejo compartió una guía detallada de 7 pasos para buscar trabajo en el mercado tecnológico a través de LinkedIn, especialmente orientada a conseguir posiciones en empresas del exterior. Los puntos clave incluían: armar el perfil en inglés con un buen headline con las tecnologías que manejás, nunca poner el seniority en el perfil, describir qué valor aportás en lugar de adjetivos genéricos, listar todas las experiencias con descripciones y links, hacer reposteos de contenido del nicho para aumentar visibilidad, conectar masivamente con reclutadores y CEOs, y postularse a cientos de posiciones por día. También recomendó ser honesto en las entrevistas sobre lo que no sabés y mostrar disposición para aprender. Agustín Sánchez complementó con el tip de contactar directamente a los reclutadores de las empresas que te interesan.
Anthropic publicó una comunicación reconociendo que habían tenido bugs en Claude Code que hacían que el modelo se comportara de forma más limitada durante las semanas previas. Según la explicación, los modelos en otros harnesses funcionaban bien, pero el harness específico de Claude Code tenía problemas. El grupo reaccionó con algo de escepticismo: Facundo García Martoni señaló que Cursor no tenía ese problema porque no aplicaba ventanas de tiempo tan restrictivas. Iñaki Fernando Lozano explicó que Cursor incluso llegaba a contar el usage por más de 1x en horas pico para desincentivar la demanda excesiva. El incidente reforzó la percepción negativa que tenía parte del grupo sobre la comunicación y gestión de Anthropic.
El lanzamiento de GPT 5.5 generó una conversión significativa de miembros del grupo desde el ecosistema Anthropic hacia OpenAI. Facundo García Martoni fue el caso más notable: después de años despreciando los modelos GPT para codeo, adoptó GPT 5.5 Extra High en Codex como su modelo principal. Describió el código generado como muy limpio, con funciones y nombres descriptivos. Alejo verificó los resultados tras un refactor grande con GPT 5.5 en modo High y confirmó que había reducido líneas de código, reorganizado archivos y quedado todo funcionando. Sin embargo, también hubo casos donde el modelo falló en frontend: Facundo Padilla reportó que produjo resultados malos con un carousel y Juan Arismendi lo usó para planificar pero al ejecutar con Composer el resultado fue incorrecto. La discusión reveló que el modelo brillaba en backend y arquitectura pero era inconsistente en frontend.
Anthropic habilitó Claude Code para el plan Pro de USD 20, lo que generó reacciones mixtas en el grupo. Algunos vieron como una buena noticia la democratización del acceso a Claude Code. Sin embargo, Thiago confirmó más tarde que en realidad era un test con el 2% de los nuevos usuarios que había durado solo unas horas antes de que lo revirtieran. La situación se enmarcó en el contexto de las críticas que el grupo venía haciendo a Anthropic por su falta de transparencia y sus decisiones inconsistentes sobre usage y pricing.
b74f7223 participantes
Agustín Sánchez anunció que ProgramaConNosotros fue aceptado como nodo local de la hackathon global Zero to Agent de Vercel, programada para el 30 de abril en el cowork Once57. El evento consistía en construir agentes usando v0 de Vercel y submittear los proyectos a la plataforma global antes del 4 de mayo. Se distribuyeron créditos de v0 a los inscriptos confirmados. Agustín anunció que daría una charla introductoria al comienzo del evento. Facundo García Martoni liberó open-source sus skills de diseño de tools y prompts para que la gente las aprovechara durante la hackathon. Arturo Grande desde Salta también participó y submitteó su proyecto desafia.tech, un preguntados para indie hackers con actualización diaria automática.
Anthropic lanzó Claude Design, una herramienta de diseño visual que varios miembros del grupo probaron casi de inmediato. Agustín Sánchez la describió como muy buena a pesar de estar en research preview con usage limitado. La característica más valorada fue la capacidad de crear un design system propio y luego generar proyectos o slide decks coherentes con ese sistema. Facundo García Martoni destacó la utilidad para hacer presentaciones de negocios. Iñaki Fernando Lozano señaló que seguía mejor las instrucciones que Stitch. Gonzalo Morales mostró resultados de antes/después donde Claude Design mejoró visiblemente el diseño de una de sus apps. Ceci también la usó con prompts vagos y obtuvo resultados impresionantes.
Se compartieron referencias actualizadas de sueldos del mercado para desarrolladores argentinos trabajando para empresas del exterior. Los rangos mencionados fueron: Junior entre USD 800 y 1500, Semi-senior entre USD 1500 y 2500, Senior entre USD 3500 y 20000. También se habló de la empresa Truelogic que trabaja con Tesla, OpenAI y Amazon, y que pagaba entre USD 6000 y 8000 por posición. Salvador Juárez compartió su experiencia con el proceso de selección de esa empresa, que requería un video explicativo del código. Juan Arismendi preguntó sobre su caso particular con 1.5-2 años de experiencia tomando responsabilidades de SSR, y el grupo le recomendó apuntar siempre hacia el seniority más alto y dejar que el mercado lo corrija.
Franco Pérez se presentó como desarrollador de blockchain en Tucumán y compartió información sobre el ecosistema de Stellar. Facundo Padilla mostró fotos y videos de un meetup que se había hecho en Salta con la comunidad de Stellar. También se habló de fud.markets, un proyecto cripto de nicho para el mercado 'degen CT' (crypto Twitter) que Thiago y Marc estaban por lanzar a mainnet después de haberlo construido en la hackathon de Aleph. Facundo Padilla sugirió automatizar la distribución de contenido a múltiples idiomas usando postiz para publicar en varias cuentas de X simultáneamente.
El grupo tuvo una conversación sobre cómo había cambiado la estimación de precios para proyectos freelance dado que la IA aceleró enormemente los tiempos de desarrollo. Varios miembros debatieron si era correcto cobrar lo mismo que antes cuando ahora un proyecto que tardaba tres semanas podía hacerse en tres días. Algunos argumentaban que el valor estaba en el resultado para el cliente, no en las horas invertidas, por lo que cobrar igual o más era perfectamente legítimo. Otros señalaban que la competencia iba a bajar los precios inevitablemente y que había que adaptarse. Se mencionó que la diferenciación pasaba por la calidad del diseño de soluciones, la velocidad de entrega y el criterio de arquitectura, cosas que la IA por sí sola no proveía.
909b31b1 participantes
El grupo debatió el estado de las distintas tecnologías para diseñar APIs en 2026. Se mencionó que tRPC había ganado terreno significativo en proyectos TypeScript full-stack por la type-safety end-to-end entre frontend y backend sin necesidad de generar código. Agustín Sánchez explicó el concepto de Server Functions de Next.js (antes llamadas Server Actions), que ofrecían una experiencia similar a invocar una función local aunque por debajo hacían una llamada HTTP. Se señaló que el website de PCN usaba Next.js full-stack de esta manera. GraphQL se mencionó como una opción que seguía siendo válida para APIs públicas o con múltiples clientes con necesidades diferentes, pero que en proyectos internos tRPC o REST directo solían ser más simples de mantener.
Se anunció el lanzamiento de Claude Opus 4.7, que llegó con un descuento del 50% en Cursor por tiempo limitado. El grupo aprovechó para debatir si valía más la pena pagar USD 20 de Cursor o USD 20 de Claude directamente. La conclusión generalizada fue que Cursor era claramente superior en valor: por el mismo precio daba acceso a Composer casi ilimitado más el acceso a múltiples modelos en API. El plan de Claude a USD 20 se consideró insuficiente porque se agotaba en pocos mensajes. Facundo García Martoni también señaló que el Cursor Ultra a USD 200 se podía gastar en 9 días si se usaba intensivamente con modelos de frontera como Opus.
Se realizó un meetup de PCN en el cowork Xetro donde Facundo García Martoni dio una charla sobre el uso de agentes de IA en producción en Macch, su startup. La charla cubrió conceptos como el modelo de router de agentes, la diferencia entre un 'God agent' y una flota de subagentes con responsabilidades específicas, y cómo diseñar el contexto y las herramientas para que los agentes sean más efectivos. Facundo habló también sobre la metáfora del Ford: así como un cliente que compra un Ford no necesita entender el motor para usarlo, los agentes necesitan entender los objetivos de negocio pero no necesariamente los detalles técnicos de implementación. El evento fue bien recibido y generó discusiones interesantes en el grupo posterior al meetup.
Salvador Juárez mostró al grupo un proyecto llamativo que había construido: una simulación completa de Windows en el navegador, implementada con React, Tailwind CSS y Lucide Icons desde cero. El proyecto incluía un bootmanager, ventanas arrastrables, y reproducía la estética de distintas versiones de Windows. El grupo reaccionó con entusiasmo ante el nivel de detalle y la creatividad del proyecto. Salvador compartió tanto el demo online como el repositorio en GitHub. Facundo García Martoni lo felicitó reiteradamente por la capacidad de construcción que demostraba, señalando que no dejaba de sorprenderle lo que hacía.
Agustín Sánchez compartió el progreso del juego Crashout, un juego multiplayer de carreras que venía desarrollando con una arquitectura interesante: el servidor (Go con WebSockets) actuaba como fuente de verdad del estado del juego, y el frontend (Next.js) solo mostraba lo que el servidor dictaba. Esta arquitectura era clave para evitar cheating en el lado del cliente. El grupo discutió las implicancias técnicas de este diseño, comparando con otros enfoques como el rollback netcode usado en juegos de pelea. Varios miembros expresaron interés en el proyecto.
El grupo tuvo un debate profundo sobre la sustentabilidad económica de Anthropic. Se mencionó que el costo de cómputo por usuario del plan Max de USD 100 era de aproximadamente USD 5000, lo que implicaba que la empresa subsidiaba masivamente a sus usuarios y operaba con pérdidas enormes. Varios miembros cuestionaron si ese modelo de negocio era sostenible a largo plazo y si eventualmente los precios subirían drásticamente. Facundo García Martoni señaló que Cursor era más conveniente que Claude Max a USD 20 en términos de valor entregado porque el modelo Composer era prácticamente ilimitado. El debate también tocó la estrategia de OpenAI versus Anthropic y quién tenía mejores chances de sobrevivir a la carrera por monetizar la IA.
Ante la degradación de Claude, varios miembros del grupo comenzaron a explorar GPT 5.4 como alternativa. Facundo García Martoni reportó que GPT 5.4 en modo Extra High era muy bueno para encontrar bugs en backend. Sin embargo, señaló que el modelo tenía una tendencia a priorizar código que funciona sobre código legible, prefiriendo soluciones que resuelven el problema aunque sean difíciles de mantener. La solución fue complementarlo con un buen archivo coderules.mdc y la skill de Karpathy para guiar el estilo de código. El grupo discutió las diferencias entre los modelos de OpenAI y Anthropic para distintos casos de uso, y varios empezaron a migrar parte de su workflow hacia GPT 5.4.
Cursor Composer 2 emergió como el modelo favorito del grupo para el día a día de desarrollo. Varios miembros reportaron que era significativamente mejor que cualquier modelo de Claude o GPT a la misma escala de costo, con usage prácticamente ilimitado en el plan de USD 20. La teoría que circuló era que Composer era en realidad Kimi K2.5 con fine-tuning por parte de Cursor, lo que explicaba tanto la velocidad como el bajo costo. Facundo García Martoni y Facundo Padilla lo recomendaron especialmente para tareas de frontend, iteración rápida, investigación de codebases y mensajes de commit. El grupo en general adoptó una estrategia de usar Composer para la mayoría de las tareas y reservar los modelos más pesados solo para arquitectura o tareas muy complejas.
Se compartió en el grupo la historia de una empresa que reemplazó GitHub Actions con depot.dev para su pipeline de integración continua y logró reducir el tiempo de build de 54 minutos a 1 minuto y 49 segundos. El grupo reaccionó con entusiasmo ante este resultado y discutió qué técnicas usaba depot.dev para lograr semejante mejora, mencionando la caché inteligente de dependencias, los runners propios y la paralelización agresiva de tareas. Varios miembros expresaron interés en probarlo en sus propios proyectos. La discusión derivó en una conversación más amplia sobre optimización de pipelines de CI/CD y el impacto que tiene el tiempo de feedback en la productividad de los equipos de desarrollo.
>2026-03marzo[24]
5d3e40a1 participantes
Se discutió la filtración del código fuente de Claude CLI que circuló en la comunidad. El grupo comentó que la comunidad reaccionó rápidamente y portó el CLI a Rust, dando lugar al proyecto openclaw y luego a claw-code. Paralelamente se habló de un ataque de supply chain que afectó a la librería Axios, uno de los paquetes más usados del ecosistema JavaScript. Los miembros del grupo debatieron sobre la seguridad de las dependencias de terceros y la importancia de auditar los paquetes que se usan en producción. Facundo Padilla mencionó que él pasaba todo el código a través de hooks de pre-commit, sonarqube y semgrep para detectar este tipo de problemas antes de que lleguen al repositorio.
Varios miembros del grupo notaron una degradación significativa en la calidad de las respuestas de Claude durante ciertas horas del día. Leandro Contrera expresó su malestar con Anthropic por esta situación. Iñaki Fernando Lozano explicó que Anthropic había confirmado que en horas pico el usage contaba por más de 1x para desincentivar la carga excesiva y equilibrar la demanda. La comunidad criticó fuertemente la falta de transparencia y comunicación apropiada de Anthropic al respecto. Thiago reportó más tarde que la situación se había corregido y que en realidad era un test con el 2% de los nuevos usuarios. El incidente generó desconfianza hacia Anthropic entre varios miembros habituales del grupo.
Gonzalo Morales preguntó cómo pagar Cursor desde Argentina después de que Mercado Pago le rechazara el pago. Iñaki Fernando Lozano explicó en detalle cómo usar Brubank para pagar suscripciones internacionales en dólares al tipo de cambio oficial: comprás los USD desde la app y configurás la tarjeta de débito para que los pagos internacionales se debiten de la cuenta en dólares. Leo confirmó que Brubank funcionaba de diez para esas cosas y que incluso era más barato si se compraban al dólar oficial. La conversación también derivó en otras opciones como Prex, USDT, Fiwind, Lemon y Deel para cobrar del exterior, además de Payoneer, DolarApp/Arq y PayPal que cobra una comisión del 5.5%. Gonzalo pudo finalmente pagar Cursor siguiendo los consejos de Iñaki.
Se discutió en el grupo la idea de usar PlantUML como herramienta de diagram-as-code para incluir diagramas en el contexto que se le pasa a la IA. La propuesta era que al tener los diagramas en formato de texto plano (código), el modelo podía entender la arquitectura del sistema mucho mejor que con imágenes o documentos. Se mencionó que esta práctica era especialmente útil para sistemas con múltiples componentes y relaciones complejas. El grupo valoró positivamente la idea como una forma de mejorar la calidad de las respuestas de los modelos al tener más contexto estructurado disponible.
be3698f2 participantes
El grupo discutió el modo de debug de Cursor como herramienta útil para testing. Facundo García Martoni compartió su estrategia personal para optimizar el uso de tokens con modelos grandes: acumular hasta 10 fixes en una lista numerada antes de enviar el prompt, en lugar de mandar cada fix por separado. Señaló que las listas numeradas funcionan mejor que los bullets tradicionales porque el modelo puede trackear mejor cada issue durante el razonamiento. Iñaki Fernando Lozano describió un approach similar pero orientado a módulos completos: para scopes más amplios prefería hacer un único prompt muy elaborado para evitar contaminar el contexto.
El grupo discutió el anuncio del curso de certificación de MCP (Model Context Protocol) de Anthropic. Facundo compartió que había empezado el curso y que era una introducción sólida al protocolo que permitía conectar herramientas externas con modelos de Claude. Se explicó qué era MCP: un protocolo estándar para que los LLMs pudieran invocar herramientas externas de manera estructurada, similar a como los navegadores web usan HTTP como protocolo estándar. Varios miembros preguntaron si la certificación de Anthropic era reconocida en el mercado. Agustín comentó que más que la certificación en sí, el conocimiento de MCP era valioso para construir integraciones con Claude en productos propios.
64cd17f
El grupo celebró el anuncio de Anthropic de ampliar el contexto disponible en Claude Max a 1 millón de tokens sin cambiar el precio del plan. Facundo comentó que este cambio era significativo para proyectos con codebases grandes donde antes tenía que usar /compact con frecuencia para no agotar el contexto. Se discutió qué tipos de tareas se beneficiaban más del contexto expandido: análisis de codebases completos, refactors que tocaban muchos archivos, y revisión de documentación extensa. Agustín señaló que el contexto de 1M tokens hacía que Claude Code fuera capaz de mantener la coherencia en proyectos que antes requerían múltiples sesiones.
e6f548f
Leandro compartió el lanzamiento de su portfolio personal construido usando Figma Make para el diseño, Claude Code para la implementación y Cloudflare Pages para el deploy. El grupo lo felicitó y exploró el sitio. Se discutió el flujo de trabajo: desde el diseño en Figma Make (la nueva herramienta de AI-to-code de Figma) hasta la implementación con Claude Code. Facundo preguntó si Figma Make generaba código limpio o si requería mucha corrección posterior. Leandro explicó que había requerido iteraciones pero que el tiempo total había sido mucho menor que implementar desde cero. Se comparó el workflow con el de Stitch + Claude Code.
5d94b141 participantes
Agustín compartió su análisis de costo-beneficio entre mantener los planes de Claude Max y Cursor simultáneamente. Calculó que el costo combinado era alto y que el valor incremental de Cursor sobre Claude Code standalone era marginal para su flujo de trabajo personal. Anunció que cancelaba su suscripción a Cursor para quedarse solo con Claude Max. El grupo debatió la decisión: Facundo García argumentó que Cursor seguía teniendo ventajas para proyectos grandes por su integración con el IDE. Otros coincidieron con Agustín en que Claude Code había madurado lo suficiente para reemplazar Cursor en la mayoría de casos. Se discutió el futuro de Cursor ahora que Anthropic invertía más en Claude Code como producto standalone.
Alguien descubrió y compartió la funcionalidad de Artifacts en Claude Code, que permitía generar micro-aplicaciones web interactivas directamente en la interfaz del chat, sin necesidad de deployar nada. El grupo exploró los ejemplos: calculadoras, visualizaciones de datos, juegos simples, y formularios funcionales renderizados dentro del chat. Facundo señaló que era útil para demos rápidas con clientes o para explorar ideas de UI sin crear un proyecto completo. Se discutió cómo Artifacts combinaba con el workflow de Stitch para ir desde boceto visual hasta prototipo interactivo en cuestión de minutos. Varios miembros pasaron tiempo ese día jugando con la feature.
a5812f7
El grupo discutió el anuncio de los programas de embajadores de Claude Code (Anthropic) y Cursor. Agustín compartió detalles del programa de Anthropic que buscaba developers que usaran Claude Code intensivamente para compartir casos de uso y feedback. Facundo comentó que había recibido invitación al programa de Cursor. Se debatió si participar en estos programas era valioso más allá del acceso anticipado a features. Algunos veían el valor en la conexión con el equipo de producto de las herramientas que usaban diariamente. Otros cuestionaban si el tiempo invertido en ser 'embajador' restaba tiempo al trabajo real.
82f3b481 participantes
El grupo celebró la noticia de que un equipo de desarrolladores de Salta, integrantes de la comunidad PCN, habían ganado un hackathon de blockchain y obtenido viaje a México como premio. Facundo Padilla y otros miembros del equipo contaron el proyecto ganador: una solución de trazabilidad de cadena de suministro usando contratos inteligentes. El grupo felicitó al equipo con entusiasmo. Se discutió la experiencia de participar en hackathons competitivos y cómo habían preparado la solución en 48 horas. Varios miembros del grupo de Tucumán expresaron motivación para participar en el siguiente hackathon.
Facundo García publicó su colección de scripts bash para gestión de git worktrees en un repositorio público de GitHub. Los scripts automatizaban la creación de worktrees con clonación de base de datos, la limpieza al terminar una tarea y el listado de worktrees activos con su estado. El grupo agradeció mucho la publicación y varios clonaron el repo inmediatamente. Se discutieron posibles mejoras: soporte para múltiples gestores de base de datos, integración con GitHub issues para nombrar los worktrees automáticamente según el número de issue. Agustín propuso un PR con una mejora menor y lo discutió en el thread.
Facundo García compartió su práctica de usar git fixup commits combinados con rebase interactivo para mantener un historial de commits limpio. Explicó el flujo: al hacer una corrección a un commit anterior, usaba `git commit --fixup=<hash>` y luego `git rebase -i --autosquash` para que los fixups se aplastaran automáticamente sobre el commit original. Varios miembros que no conocían la opción `--autosquash` quedaron entusiasmados con el workflow. Se discutió cuándo era apropiado reescribir el historial antes de hacer push y cuándo era mejor preservar los commits individuales. El hilo terminó siendo una clase práctica de git.
El grupo comparó Google Stitch y v0 de Vercel como herramientas de prototipado rápido de interfaces. Los que habían usado v0 destacaban su capacidad de generar código React directamente deployable. Los de Stitch valoraban la generación de imágenes de pantallas de alta fidelidad visual como referencia para Claude. Facundo argumentó que para el workflow de 'imagen → Claude Code', Stitch era superior porque producía referencias visuales más claras. Para código directo, v0 tenía ventaja. Se discutió también Bolt y Lovable como herramientas similares. La mayoría acordó que la elección dependía de si el objetivo final era una imagen de referencia o código usable directamente.
40be26e
El grupo retomó el tema de desarrolladores que delegaban completamente la escritura de código a agentes de IA. Alguien compartió un caso de un desarrollador en su empresa que había declarado no haber escrito una línea de código a mano en dos meses. El debate se polarizó entre quienes veían esto como el futuro natural del trabajo y quienes argumentaban que la comprensión profunda del código seguía siendo esencial para debugging y decisiones de arquitectura. Facundo señaló que en su experiencia los mejores resultados con agentes de IA los obtenían quienes tenían más conocimiento técnico para guiar y revisar al agente. Se discutió si esta tendencia cambiaría los criterios de contratación en los próximos años.
c8c3f371 participantes
El grupo tuvo un debate técnico extenso sobre la diferencia de calidad entre Claude Opus y Claude Sonnet al escribir código. Alguien observó que Sonnet tendía a violar el principio de responsabilidad única (SRP) creando métodos y clases con demasiadas responsabilidades. Facundo García argumentó que Opus producía diseños más coherentes en proyectos grandes pero era más lento y caro. Se discutió si la diferencia valía el costo adicional para proyectos medianos. Agustín comentó que usaba Sonnet para la mayoría de las tareas y Opus para decisiones de arquitectura importantes. El thread generó una discusión sobre cuándo el quality gate justificaba el overhead de usar modelos más caros.
Alguien del grupo compartió el anuncio del Aleph Hackathon que se realizaría en Salta. El evento congregaba a desarrolladores y emprendedores de todo el noroeste argentino. El grupo mostró interés y varios de los miembros de Salta confirmaron que participarían. Se discutió el formato del hackathon y los temas de los desafíos propuestos. Facundo Padilla, que era de Salta, animó a los miembros de Tucumán a sumarse. Se comentó que eventos como este eran importantes para la comunidad tech regional que históricamente había estado muy centralizada en Buenos Aires y Córdoba.
Facundo García compartió su setup de git worktrees con un script bash que automatizaba la creación de un nuevo worktree junto con la clonación de la base de datos local para esa tarea. El script creaba un directorio de trabajo aislado, hacía una copia de la DB de desarrollo, y configuraba las variables de entorno del worktree para apuntar a esa copia. El grupo mostró gran interés por el enfoque. Se discutió cómo manejar las migraciones de base de datos en un entorno de worktrees múltiples. Matías preguntó cómo se sincronizaban los cambios de schema entre los worktrees cuando múltiples tareas tocaban la misma base de datos. El thread terminó siendo una referencia técnica para trabajo con agentes en paralelo.
El grupo discutió la actualización de Cursor Composer 1.5 que varios miembros habían estado probando. Facundo García reportó que era notablemente más rápido que versiones anteriores y que la tasa de éxito en tareas de código era más alta. Se comparó con Claude Code y con GitHub Copilot en términos de velocidad de respuesta y calidad del código generado. Matías señaló que el precio por token en el API de Cursor había bajado con el nuevo modelo, lo que hacía las sesiones largas más económicas. Agustín comentó que la confiabilidad para no romper código existente era la métrica más importante en su flujo de trabajo y que 1.5 mejoraba en ese aspecto.
Un miembro presentó el diseño de un sistema de facturación multi-tenant y preguntó sobre las mejores estrategias de aislamiento de datos. El grupo discutió las tres arquitecturas principales: base de datos separada por tenant, schema separado por tenant en la misma base, y tabla compartida con tenant_id más Row Level Security (RLS). Facundo argumentó que RLS en PostgreSQL era la opción más pragmática para la mayoría de los casos: ofrecía aislamiento fuerte sin la complejidad operativa de gestionar múltiples bases de datos. Se mencionó la implementación de RLS en Supabase como referencia. Se discutió cuándo el overhead de múltiples bases de datos se justificaba: compliance estricto, grandes volúmenes de datos por tenant, o SLAs diferenciados.
ca80b5a
Un miembro compartió su proyecto de IoT para automatizar el sistema de semáforos de una federación de powerlifting usando ESP32 y el protocolo DMX para controlar las luces de jurado. Explicó el hardware involucrado: un ESP32 que recibía señales desde una tablet del árbitro principal y enviaba comandos DMX al rack de luces RGB de los jueces. El grupo mostró interés técnico en el protocolo DMX y en el uso de ESP32 para control de iluminación en tiempo real. Facundo preguntó sobre la latencia del sistema dado que en competencias de powerlifting los tiempos de señalización eran críticos. El proyecto generó admiración por combinar hardware y software en un dominio no convencional.
47976181 participantes
Facundo García anunció el lanzamiento de la funcionalidad de base de conocimiento con RAG en Macch, el producto del equipo. La feature permitía a los usuarios subir documentos propios (PDFs, páginas web, bases de conocimiento) que el asistente usaba como contexto al responder preguntas. El grupo celebró el lanzamiento. Se discutió la arquitectura de la solución: chunking de documentos, embeddings, búsqueda vectorial y reranking. Agustín preguntó sobre el modelo de embeddings usado y Facundo explicó las decisiones técnicas sobre qué modelo priorizar para español. La conversación derivó en mejores prácticas de RAG y los casos de uso más valorados por los usuarios de Macch.
Un miembro que buscaba trabajo como desarrollador preguntó estrategias concretas para conseguir entrevistas. El grupo ofreció consejos prácticos: mantener LinkedIn actualizado con proyectos reales y keywords relevantes, especializarse en un nicho claro en lugar de ser generalista, y hacer cold outreach directo a CTOs y tech leads en empresas de interés. Facundo recomendó enviar mensajes personalizados que mostraran conocimiento real de la empresa o producto, no mensajes genéricos. Se discutió si Glassdoor y Tecnoempleo eran efectivos para el mercado argentino. Alguien mencionó que Twitter/X seguía siendo útil para conectar con devs influyentes que abrían posiciones en sus startups.
>2026-02febrero[18]
f9d9c0b
Alguien compartió la funcionalidad de Cursor que permitía usar git worktrees para ejecutar múltiples agentes en paralelo, cada uno trabajando en una rama diferente del repositorio. El grupo discutió los beneficios: poder tener un agente trabajando en una feature mientras otro corregía un bug, sin conflictos de archivos entre sesiones. Facundo mencionó que había empezado a usar un script que automatizaba la creación de worktrees con base de datos clonada para cada tarea. Se discutió la diferencia entre el modelo de agentes en Cursor versus Claude Code y cuál era más adecuado para trabajo paralelo.
a47bb07
Rodrigo compartió su stack de herramientas para combatir las distracciones durante el trabajo: Onesec (que añade fricción al abrir apps distractoras), ScreenZen (para limitar tiempo en apps) y la técnica Pomodoro para bloques de trabajo concentrado. El grupo compartió sus propias estrategias. Matías mencionó que tenía el teléfono en modo avión durante sesiones de trabajo profundo. Facundo comentó que las notificaciones de Slack y WhatsApp eran los principales disruptores en trabajo remoto. Se discutió si las herramientas de restricción eran más efectivas que simplemente construir el hábito de no revisar el teléfono. La conversación generó varias recomendaciones prácticas.
b2503f5
Volvió al grupo la noticia de que Jack Dorsey había ejecutado recortes del 50% del staff de Block, explicando públicamente que la IA permitía a equipos más pequeños hacer el trabajo de equipos grandes. El grupo tuvo reacciones divididas. Algunos argumentaron que era una señal de lo que venía para la industria tech. Otros cuestionaron si la justificación con IA era genuina o era una narrativa para cubrir decisiones financieras. Facundo comentó que las empresas que recortaban staff 'por IA' solían hacerlo también por razones de rentabilidad y que mezclar ambas justificaciones era engañoso. Se debatió la responsabilidad ética de los CEOs que usaban la IA como justificación para reducir costos laborales.
c4c37501 participantes
El grupo tuvo una discusión técnica profunda sobre el problema de context drift en sistemas RAG (Retrieval Augmented Generation): el fenómeno por el cual el modelo pierde coherencia cuando el contexto recuperado es contradictorio o muy extenso. Facundo García presentó la solución que estaban implementando en Macch: Knowledge Slots, un sistema de ranuras de conocimiento predefinidas que organizaban el contexto recuperado de manera estructurada antes de enviarlo al modelo. Se discutió cómo esta arquitectura reducía el ruido y mejoraba la consistencia de las respuestas. Varios miembros encontraron el concepto útil para sus propios proyectos con RAG.
Mateo compartió que había construido una aplicación de matching para emprendedores, conceptualmente similar a Tinder, en menos de 12 horas usando Claude Code como agente principal de desarrollo. La app permitía a emprendedores encontrar co-fundadores o colaboradores con intereses complementarios mediante un sistema de swipe. El grupo quedó impresionado con la velocidad de desarrollo. Se detalló que la app había llegado a 700 usuarios en los primeros días de lanzamiento. Facundo preguntó sobre el stack y Mateo explicó que había usado Next.js con Supabase como backend. El caso fue celebrado como ejemplo concreto de las posibilidades del desarrollo asistido por IA.
dd92104
Alguien compartió la noticia del hackeo a Taxes Software Argentina, que resultó en la exposición de 440 bases de datos y 4.7 GB de datos de contribuyentes. El grupo reaccionó con preocupación. Se discutieron las implicaciones del hackeo para los usuarios del software contable. Facundo señaló la importancia de la seguridad en aplicaciones que manejan datos fiscales sensibles. Se debatió si el ataque había sido por SQL injection, credenciales comprometidas u otro vector. La conversación derivó en prácticas de seguridad básicas que muchas aplicaciones argentinas no implementaban: cifrado en reposo, auditoría de accesos y pentesting periódico.
c47601a1 participantes
Facundo Padilla anunció el lanzamiento de salta.dev, un sitio de la comunidad de desarrolladores de Salta construido íntegramente con Claude Code y Google Stitch sin escribir código manualmente. El grupo lo felicitó y varios lo tomaron como prueba de concepto del workflow de IA que habían estado discutiendo. Facundo explicó el proceso: diseñó las pantallas en Stitch, exportó las imágenes como referencias visuales y le pidió a Claude Code que implementara el frontend usando esas imágenes como guía. El resultado fue un sitio moderno y funcional en pocas horas. El hilo generó mucha discusión sobre la viabilidad de este workflow para proyectos de clientes.
Se anunció el PCN Dev Meetup para el 20 de febrero en once57, un espacio de coworking en Tucumán. El grupo organizó la participación con entusiasmo. Se discutieron los temas a cubrir en el encuentro: workflows con IA, experiencias con Claude Code, y proyectos de los miembros. Varios confirmaron asistencia. El meetup congregó a más de 20 personas de la comunidad. Después del evento, varios miembros compartieron fotos y comentaron que había sido una reunión muy productiva, con demos en vivo de herramientas de IA y conversaciones técnicas sobre proyectos reales.
99bd941
El grupo debatió las diferencias entre los planes Pro y Max de Claude y cuándo valía la pena el upgrade. Agustín explicó que había estado usando los comandos /compact y /clear en Claude Code para optimizar el uso de tokens en sesiones largas. Facundo detalló que /compact comprimía el historial de la conversación manteniendo el contexto esencial, mientras que /clear reseteaba completamente. Se discutió que el plan Max ofrecía 5 veces más uso mensual que Pro, lo que era relevante para quienes usaban Claude Code intensivamente en proyectos reales. Varios miembros preguntaron si el upgrade justificaba el costo adicional según el uso.
d478f4a
Facundo compartió su descubrimiento del modo plan en Claude Code, activado con Shift+Tab, que hacía que el modelo planificara los cambios antes de ejecutarlos. El grupo mostró interés inmediato. Se discutió la estrategia de usar Claude Opus para la fase de planificación (donde el costo era menor por no generar tanto código) y luego Claude Sonnet para la fase de implementación. Agustín comentó que el modo plan reducía los errores de contexto en tareas que tocaban múltiples archivos. Facundo explicó que había configurado su Claude Code para usar Opus en plan mode por defecto y Sonnet para ejecución, logrando mejor calidad sin aumentar mucho el costo.
1383299
Matías trajo un debate sobre qué distribución de Linux era más conveniente para desarrollo: EndeavourOS (basada en Arch) versus Linux Mint (basada en Ubuntu/Debian). Los defensores de EndeavourOS destacaban el acceso al AUR y el rolling release. Los de Mint señalaban la estabilidad y el menor tiempo de configuración inicial. Se discutió si Hyprland, el compositor de ventanas Wayland, era compatible con Linux Mint, ya que originalmente estaba pensado para Arch. Facundo comentó que para trabajo sin distracciones prefería una distro más estable que no requiriera mantenimiento constante. Matías terminó argumentando que EndeavourOS era un buen punto medio entre el control de Arch y la facilidad de uso.
a252f89
Un miembro compartió su experiencia probando Kimi 2.5, el modelo de lenguaje chino que prometía capacidades de 'super agente'. Contó que el modelo era impresionante en razonamiento pero que el límite de 3 usos por día en el plan gratuito y la latencia alta lo hacían impráctoco para trabajo diario. El grupo discutió los diferentes LLMs chinos como Kimi, DeepSeek y Qwen y su posicionamiento frente a los modelos de Anthropic y OpenAI. Facundo señaló que DeepSeek había tenido más tracción en la comunidad por su costo-efectividad en tareas de código. Se debatió la confiabilidad de usar modelos de empresas chinas para trabajo con código propietario.
9321d4e
El grupo discutió el formato ideal para un CV técnico orientado a empresas internacionales. Varios recomendaron el formato Harvard: una o dos páginas, tipografía simple, sin columnas ni gráficos de habilidades. Facundo fue explícito en desaconsejar los CVs generados por IA con diseños visuales recargados, señalando que los recruiters técnicos preferían la claridad de texto sobre el diseño. Se debatió si incluir foto en el CV era positivo o negativo según el mercado objetivo. Alguien mencionó que para el mercado europeo la foto era común pero que para el mercado norteamericano se desaconsejaba. Se compartieron ejemplos de buenos CVs de desarrolladores reconocidos.
46826501 participantes
Facundo Padilla compartió su flujo de trabajo con Google Stitch para diseño de interfaces: primero generaba un metaprompt detallado describiendo la app, luego usaba Stitch para generar las pantallas visuales, y finalmente pasaba el resultado a Claude Code para implementar el frontend. El grupo mostró gran interés por el workflow. Agustín probó Stitch durante la conversación y comentó que los resultados visuales eran sorprendentemente buenos para prototipos rápidos. Se discutió la comparación con v0 de Vercel y Bolt. Facundo señaló que Stitch generaba imágenes de las pantallas que luego servían como referencia visual para Claude, lo que reducía ambigüedad en el prompt.
Elon Musk hizo declaraciones públicas sugiriendo que los programadores serían obsoletos en el corto plazo debido al avance de la IA, y esta noticia generó un debate intenso en el grupo. Una parte de los miembros desestimó las declaraciones como exageración marketinera, señalando que Musk tenía incentivos económicos para promover la narrativa de IA que reemplaza humanos dado que su empresa xAI competía en ese mercado. Otros miembros tomaron las declaraciones más en serio y discutieron hasta qué punto la automatización del código podía realmente desplazar a los desarrolladores en un horizonte de 5 a 10 años. Leandro Contrera argumentó que la complejidad del software empresarial real, con todos sus requerimientos implícitos, restricciones de negocio y deuda técnica, hacía muy difícil que la IA pudiera operar sin supervisión humana en el corto plazo. Facundo García Martoni compartió su experiencia con agentes de IA en Macch, donde había visto tanto éxitos como fracasos estrepitosos del agente al tomar decisiones sin contexto suficiente. La conversación concluyó con la mayoría coincidiendo en que el rol del desarrollador estaba evolucionando hacia algo más parecido a un director técnico de agentes de IA, donde el valor estaba en saber qué construir y cómo dirigir las herramientas.
El grupo discutió si en el contexto actual tenía más sentido especializarse profundamente en un área (frontend, backend, infraestructura) o desarrollar un perfil full-stack amplio. Los defensores de la especialización argumentaron que la profundidad técnica era más difícil de reemplazar por la IA, y que los especialistas senior podían resolver problemas que los generalistas y las herramientas de IA no podían abordar. Los defensores del perfil full-stack señalaban que la IA ya era muy capaz en las tareas técnicas específicas, y que el valor del full-stack estaba en poder ver el sistema completo y tomar decisiones de arquitectura informadas. Nicolás Borda aportó que la distinción entre frontend y backend estaba volviéndose cada vez más difusa con frameworks como Next.js y Remix que unificaban ambas capas. Martín Esteban coincidió y agregó que los desarrolladores que entendían tanto el dominio técnico como el negocio eran los más difíciles de reemplazar. Se discutió también el mercado laboral: en Argentina, los full-stacks tenían más oportunidades laborales porque las empresas pequeñas y medianas no podían permitirse equipos especializados grandes.
6300e321 participantes
Un miembro del grupo compartió su experiencia usando Claude para asistir en tareas de QA manual, generando casos de prueba a partir de especificaciones de producto y documentando bugs encontrados durante el testing. La iniciativa, apodada informalmente Claude Cowork, consistía en usar al modelo como copiloto durante las sesiones de QA, pidiéndole que sugiriera edge cases que el tester podría no haber considerado. Varios miembros que trabajaban en roles de QA mostraron interés en la propuesta, señalando que una de las partes más tediosas del trabajo era pensar sistemáticamente en todos los caminos posibles de un flujo de usuario. Se habló de cómo Claude podía traducir casos de prueba en lenguaje natural a scripts de Playwright o Cypress con una descripción suficientemente detallada. Nicolás Borda mencionó que había experimentado con esto en un proyecto y que los scripts generados necesitaban revisión y ajuste, pero que igualmente reducían significativamente el tiempo de escritura de tests.
4f474241 participantes
OpenAI lanzó Codex, su nuevo modelo especializado en programación, y la noticia generó una discusión activa en el grupo. Varios miembros compararon Codex con Claude Code y con el modo agente de Cursor, debatiendo cuál ofrecía mejor calidad de código y comprensión de contexto en proyectos grandes. Se discutió también el modelo de precios de Codex y si resultaba competitivo frente a las alternativas existentes, con la conclusión general de que el mercado de herramientas de coding AI estaba volviéndose muy competitivo y los precios estaban bajando. Leandro Contrera mencionó que la proliferación de herramientas hacía cada vez más difícil mantenerse al día con todas las opciones, y que el verdadero diferenciador ya no era la herramienta sino la habilidad del desarrollador para integrarla efectivamente en su flujo de trabajo. La discusión concluyó con el consenso de que experimentar con múltiples herramientas y elegir la que mejor se adaptara al tipo de proyecto era la estrategia más pragmática.
El grupo dedicó una discusión extensa a comparar Cursor CLI y Claude Code como herramientas agenticas de desarrollo, evaluando sus fortalezas y debilidades en contextos de proyectos reales. Los partidarios de Cursor destacaron la integración nativa con el editor, el plan mode para planificar cambios antes de ejecutarlos, y la capacidad de los Cloud Agents para crear PRs autónomamente en VMs separadas. Los defensores de Claude Code, en cambio, resaltaron su superior capacidad de razonamiento, la posibilidad de usar herramientas externas via MCP, y el hecho de que corría directamente en la terminal sin necesidad de un editor específico. Varios miembros señalaron que la elección dependía mucho del tipo de tarea: para trabajo exploratorio y de prototipado, Cursor era más conveniente, mientras que para tareas de mantenimiento y refactoring en codebases grandes, Claude Code demostraba mayor solidez. Se discutió también el costo de ambas herramientas y si el gasto se justificaba frente al aumento de productividad, con la mayoría coincidiendo en que el ROI era positivo para desarrolladores senior.
e09e7351 participantes
Una discusión técnica profunda sobre PostgreSQL avanzado surgió en el grupo, iniciada por una pregunta sobre estrategias de indexación para consultas complejas en tablas con millones de registros. Varios miembros con experiencia en bases de datos compartieron su conocimiento sobre tipos de índices en PostgreSQL: B-tree, GIN, GiST, y BRIN, explicando en qué escenarios cada uno era más eficiente. Martín Esteban describió un caso real donde había mejorado una consulta de 45 segundos a menos de 100 milisegundos usando un índice parcial que filtraba solo los registros activos. Se discutió también el uso de EXPLAIN ANALYZE para entender los planes de ejecución de queries, y cómo interpretar los nodos del árbol de ejecución para identificar los cuellos de botella. Se mencionó pgBadger como herramienta para analizar logs de PostgreSQL e identificar las queries más lentas en producción. La conversación derivó hacia el particionamiento de tablas como estrategia para manejar datasets muy grandes, con ejemplos de particionamiento por rango de fechas para datos time-series.
6f1591c1 participantes
Un miembro compartió un plugin MCP experimental que permitía a Claude Code leer componentes de Figma directamente y generar código frontend a partir de los diseños, acortando el ciclo entre diseño y desarrollo. La comunidad debatió si este tipo de integración era realmente útil en la práctica o si generaba código de baja calidad que después requería mucho trabajo de refinamiento. Varios desarrolladores frontend del grupo expresaron escepticismo, argumentando que los diseños en Figma rara vez estaban suficientemente limpios como para que una herramienta de IA pudiera interpretarlos sin ambigüedades. Sin embargo, otros señalaron que para casos de uso simples como landing pages o pantallas CRUD, la integración podía ahorrar horas de trabajo repetitivo. Nicolás Borda mencionó que ya había probado una herramienta similar con Storybook y que los resultados eran irregulares: algunas veces generaba componentes casi listos para producción, y otras veces el código era un desastre. Se mencionó que el ecosistema de MCP servers estaba creciendo rápidamente, con integraciones para bases de datos, APIs de terceros y herramientas de productividad.
8e529721 participantes
Facundo García Martoni anunció en el grupo que Macch había lanzado dos nuevas funcionalidades importantes: un panel de administración interno y la capacidad de envío masivo de mensajes por WhatsApp. Explicó que el panel admin les permitía gestionar clientes, ver métricas de conversación y configurar plantillas de mensajes sin necesidad de acceder directamente a la base de datos. El bulk messaging era la funcionalidad más esperada por sus clientes, ya que les permitía enviar campañas de marketing segmentadas directamente desde la plataforma. Varios miembros felicitaron a Facundo y al equipo de Macch por el avance, y algunos pidieron detalles sobre cómo habían manejado los límites de rate de la API de Meta para los envíos masivos. Facundo explicó que implementaron una cola con reintentos exponenciales y respetaban las ventanas de tiempo recomendadas por Meta. También mencionó que estaban usando plantillas pre-aprobadas por Meta, ya que sin aprobación previa no se podían enviar mensajes fuera de conversaciones iniciadas por el usuario.
Se compartió en el grupo la encuesta salarial Gonczy 2026, que recopilaba datos sobre remuneraciones en el sector tech argentino. Se generó una conversación sobre las tendencias salariales observadas en el mercado local, especialmente en el contexto de la devaluación y la inflación de los últimos años. Leandro Contrera mencionó que los salarios en pesos habían perdido poder adquisitivo significativamente, mientras que quienes cobraban en dólares via contratos de exportación de servicios habían logrado mantener o aumentar su nivel de vida. Se discutió la brecha salarial entre desarrolladores que trabajaban para empresas locales versus los que tenían clientes del exterior, con estimaciones de que la diferencia podía ser de 3 a 5 veces el salario en pesos para el mismo nivel de seniority. También se mencionó el fenómeno de los desarrolladores argentinos que trabajaban remotamente para empresas de Estados Unidos y Europa, aprovechando la diferencia cambiaria.
Agustín Sánchez abrió una discusión preguntando qué terminales usaban los miembros y si tenían recomendaciones. La comunidad dio respuestas variadas: varios coincidieron en recomendar Warp por su experiencia con IA integrada, aunque Agustín señaló que consumía bastante RAM. Iván Taddei y Esteban Sánchez también recomendaron Warp. Marcelo Nuñez recomendó iTerm2. Leandro Contrera mencionó Bash como su preferido en Linux. Algunos miembros en Windows usaban PowerShell desde VSCode. Joaquin Sarmiento señaló una precaución importante sobre Warp: usarlo para instalaciones complejas que modificaban archivos del sistema podía romper cosas. También se discutió el potencial de Claude Code para trabajar completamente desde la terminal sin necesitar un IDE gráfico, que Agustín planeaba explorar ese fin de semana.
Juan Farber recomendó Deepwiki.com como herramienta para entender rápidamente la estructura y funcionamiento de repositorios de código. La herramienta indexaba el repositorio y permitía hacer preguntas en lenguaje natural sobre el código. Leandro Contrera lo encontró en el contexto de unirse a un proyecto existente y necesitar entenderlo rápidamente. Se discutió que para repositorios privados era necesario pagar y que la indexación se actualizaba aproximadamente una vez por semana. Agustín Sánchez señaló que en Cursor usaba el modo Ask para el mismo propósito y que Claude Code tenía una funcionalidad similar más avanzada. También se mencionó que Devin AI, que Alejo Boga usaba en su trabajo, generaba wikis automáticas de los repositorios que eran especialmente útiles para proyectos con múltiples equipos.
Facundo García Martoni compartió la técnica de minificación de prompts que usaba en Macch para reducir costos en el uso de la API de modelos de lenguaje. Explicó que la minificación de prompts era análoga a la minificación de código: eliminar palabras redundantes, adjetivos innecesarios y abstraer lógica repetida con símbolos. El ejemplo que dio fue pasar de 'si pasa x, se hace y' a simplemente 'x -> y'. Leandro Contrera inmediatamente se interesó en la idea y Mateo Lohezic sugirió que se podría crear un minificador automático pidiéndole a ChatGPT que minificara prompts. Facundo García Martoni había twitteado sobre el tema señalando que un buen minificador de prompts sería un proyecto ganador en dev tools. También se discutieron otras estrategias de reducción de tokens: evitar repetición de contexto y usar referencias en lugar de repetir instrucciones completas.
Leandro Contrera consultó sobre cómo integrar un sistema con el ARCA (antes AFIP) para facturación electrónica. Benjamin Cortes recomendó afipsdk.com como herramienta que simplificaba la integración, aunque con límite en el plan gratuito. Facundo Padilla recomendó PyAfipWS como alternativa 100% gratuita y open source. Más tarde, Leandro consultó nuevamente al desarrollar un sistema de facturación para una heladería, profundizando en los límites del plan gratuito: 100 PDFs y 1000 requests mensuales. Se discutió cómo manejar los casos donde los clientes superaban esos límites. Jeremías Moreno Ivanoff mencionó que también había integrado directamente usando los WSDL del ARCA. La comunidad señaló que la integración con ARCA era notoriamente compleja y poco documentada, siendo uno de los mayores dolores de cabeza del desarrollo de software empresarial en Argentina.
Leandro Contrera compartió su experiencia instalando el MCP de Context7 en Gemini CLI para tener documentación siempre actualizada disponible para el modelo. Context7 fue descrita como una herramienta que indexaba documentación de librerías y frameworks populares y la exponía como MCP para que los agentes la consultaran en tiempo real. Facundo Padilla confirmó que era la página que terminaba en el número 7 que había mencionado previamente. La comunidad discutió el problema que Context7 resolvía: los modelos de IA generaban código con APIs deprecated o que no existían porque su knowledge cutoff era de meses atrás. También se mencionó como caso concreto que Gemini había intentado usar postcss.config.ts cuando Tailwind v4 ya no lo requería. Facundo García Martoni añadió que su estrategia alternativa era pegar la documentación en texto plano como contexto del prompt.
Juan Arismendi consultó sobre herramientas de trackeo de tiempo y tareas para una empresa mediana sin head técnico que usaba ClickUp hasta llegar al límite del plan gratuito. La comunidad recomendó Clockify como la mejor opción gratuita para timetracking, con soporte para equipos y reportes detallados. Iñaki Fernando Lozano y Leandro Contrera coincidieron en la recomendación. Tiempo después, Leandro Contrera también exploró Plaky, de la misma empresa que hace Clockify, como herramienta de gestión de tareas tipo kanban. Se discutió la integración entre ambas herramientas y cómo podían reemplazar a ClickUp sin llegar al límite de usuarios pagos. También se comparó con Trello y Notion como alternativas para equipos pequeños.
Alejo Boga compartió una situación crítica del equipo de Tailwind CSS: Adam Wathan, el creador, había tenido que despedir al 75% del equipo por problemas económicos. La comunidad debatió las causas: la hipótesis que ganó consenso fue que los desarrolladores habían dejado de visitar la documentación oficial de Tailwind porque usaban IA para sus dudas, lo que afectó el flujo de ventas de los productos pagos de la empresa (Tailwind Plus, componentes y templates). Agustín Sánchez comparó la situación con lo que le pasó a Google cuando los LLMs empezaron a responder preguntas directamente sin redirigir a sitios web. La comunidad reflexionó sobre la amenaza que la IA representaba para el modelo de negocio de documentación técnica y formación. También se discutió si Tailwind podría sobrevivir con un modelo de sponsors como Vercel.
Agustín Sánchez presentó en detalle el concepto de 'agentic engineering' a la comunidad: el arte de delegar el desarrollo de software a agentes de IA de forma eficiente, enfocándose el developer en arquitectura, especificaciones y revisión. Describió su stack: Cursor con modo plan, Git Worktrees para paralelizar agentes sin conflictos, y Greptile para code review automático en GitHub. Dio ejemplos concretos de velocidad: un CRUD completo en NestJS con tests y documentación Swagger en 15 minutos incluyendo revisión. Marcelo Nuñez propuso organizar una juntada para que Agustín lo demostrara en vivo. Lucas Juárez preguntó qué herramientas específicas usar y la comunidad debatió entre Cursor, Claude Code, Devin AI y Codex según el caso de uso. Leandro Contrera mencionó el Spec-Kit de GitHub como framework para agentic engineering. Agustín insistió en que los developers con mejor base de ingeniería de software podrían sacarle más partido a los agentes, y que los que no se adaptaran quedarían obsoletos.
Facundo García Martoni compartió un insight de meses de prueba y error con Macch: los LLMs no pueden hacer bien prompt engineering. Al pedirle a modelos de frontera (Gemini o Claude) que creen system prompts para agentes más pequeños (Gemini 2.5 Flash, GPT-4o mini), los prompts generados pasaban tests superficiales pero al ahondar aparecían alucinaciones y 'desobediencia'. Cuando él mismo redactó los system prompts la cantidad de alucinaciones bajó notablemente, y no supo explicar exactamente por qué. Facundo Padilla teorizó que es porque los LLMs predicen la siguiente palabra: cuando le pedís que cree un prompt, internamente formula ese prompt con sus propias reglas, creando una capa extra de indirección que introduce ruido. Facundo García Martoni añadió que parchar iterativamente un system prompt va 'ensuciándolo' hasta que se vuelve monstruoso e ilegible. Hay un 'superparche' que minimiza las alucinaciones: forzar el modo thinking con un budget, pero a costa de más latencia y costo. Santiago De Marco relacionó esto con el fenómeno del 'teléfono descompuesto' entre LLMs cuando se hace que hablen entre sí en loops.
Leandro Contrera preguntó si alguien había probado desplegar en Render para un MVP cliente-servidor. Alejo aclaró que el plan free de Render no sirve de mucho porque el servidor se duerme sin requests y tarda 15 segundos en cada request, pero que el plan Basic (7 USD) andaba bien para un MVP. Facundo García Martoni recomendó en cambio usar directamente AWS o GCP con ayuda de la IA para guiarse, argumentando que la experiencia en los grandes providers es muy pedida en los laburos y que cuando uno empieza a querer hacer algo un poco más complejo que lo que permiten los ecosistemas cerrados de los providers chicos, termina migrando de todas formas. Contó que en uno de sus laburos pasados (empresa de SF) migraron toda la infra de Render a AWS. GCP da 300 USD de créditos al crearse una cuenta y AWS tiene un free tier por un año. Facundo García Martoni había probado Fly, Render y Railway con Macch y terminó en GCP por su robustez. Un integrante anónimo también mencionó el workaround de un cron cada 14 minutos para evitar el sleep de Render.
Facundo Padilla compartió que en su trabajo estaban integrando Devin y que había armado un playbook de 612 líneas para el agente, que andaba muy bien siguiendo esas instrucciones. Facundo García Martoni preguntó qué ventajas le veía respecto a Cursor, y Facundo Padilla aclaró que nunca usó Cursor pero que Devin le gustaba porque puede conectarse a todos los repositorios de la empresa sin tener que programar una API ni meter claves por todos lados. Sin embargo señaló el punto débil: Devin tiene libre albedrío, hace lo que le pinta, y si no especificaste algo asume por su cuenta y mete fruta. En eso se demoró 20 minutos haciendo cambios en archivos, lo que Facundo estimó le hubiera llevado 1 hora a él. El intercambio confirmó que los agentes de código autónomos como Devin están siendo adoptados en entornos laborales reales, con el desafío de la especificidad del playbook para contener su autonomía.
Leandro Contrera preguntó si alguien usaba uv como gestor de paquetes para Python. Facundo García Martoni respondió con rotundidad: 'Sí, sí y sí. Siempre uv, nunca otra cosa'. Contó que en uno de sus trabajos anteriores su primer PR fue migrar Poetry a uv, lo que fue tomado positivamente por el equipo. Leandro agradeció el dato diciendo que eso le ahorró sus buenas horas de prueba y error. uv es un gestor de paquetes moderno y rápido para Python que se ha ido consolidando como alternativa superior a pip y Poetry en el ecosistema Python, especialmente en equipos que buscan velocidad e instalación reproducible.
Facundo Padilla compartió una imagen con la noticia de que StackOverflow estaba perdiendo tráfico significativamente, ante lo que Jeremías Moreno Ivanoff reaccionó con tristeza. Agustín Sánchez contó que justo el otro día StackOverflow le había salvado las papas en algo super específico y que esperaba que no se viniera abajo. Juan Farber aportó el dato histórico: StackOverflow fue vendida a Prosus por un precio reportado de 1.800 millones de dólares un año después de la pandemia (2021), según un artículo de TechCrunch. Alejo señaló que StackOverflow siempre tiene respuestas, en alusión a su utilidad histórica a pesar del declive relativo ante la IA.
Leandro Contrera preguntó qué opinaban de Slack, si alguien lo había usado. Agustín Sánchez respondió que lo usa diariamente en Eagerworks, y que en comunidades como PCN usan Discord. Mauricio Chaile dijo que en su laburo también era Slack y que no le veía diferencias con Discord. Agustín aclaró que a él le gusta más Discord por tener más features, pero que el bajón es que tiene un look and feel menos profesional que Slack para trabajar con algunos tipos de clientes. Facundo García Martoni, trabajando en un entorno Lean, confirmó que Slack es el estándar en las empresas y que personalmente no le gusta porque Discord da lo mismo gratis, pero es lo 'cool' dentro de lo empresarial. Germán Navarro señaló la diferencia más grande: en Slack en versión free los mensajes se van borrando. Facundo Padilla apuntó que el sonidito de notificaciones de Slack es abrumador.
Germán Navarro compartió que GitHub había anunciado cobrar por el uso de GitHub Actions a todos los repos, pero que ante las quejas masivas de la comunidad lo había rollbackeado. Santiago De Marco contó que el PR correspondiente estaba lleno de quejas en el código fuente mismo. Germán pasó un video de The Primeagen sobre el tema y trazó un paralelo con el drama de Unity, que quiso cobrarle a los devs por cada install de los juegos: mucha gente quedó desconfiada aunque dieron marcha atrás después de todas las quejas. Agustín Sánchez comentó que entendía la decisión de cobrar por las GitHub Actions; lo que lo preocupó fue que el video de Primeagen mostraba que la implementación no estaba bien optimizada y iba a ser un desastre. Joaquin Sarmiento compartió `nektos/act`, una herramienta de 2019 para correr GitHub Actions localmente sin gastar minutos en la nube.
Leandro Contrera preguntó en qué materia de la facultad se veía Domain-Driven Design (DDD) y si era condición necesaria leer todo el libro de Larman. Germán Navarro y Matias Gutierrez respondieron que en ninguna, aunque el libro de Larman sí se usa en Análisis de Sistemas y Diseño de Sistemas. Agustín Sánchez fue contundente: en la UTN-FRT no se ve ni el 5% de lo que realmente es DDD, y si querés aprender de verdad hay que leer libros y hacer proyectos propios. Recomendó tres libros: el original de Eric Evans ('Domain-Driven Design: Tackling Complexity in Software'), 'Domain-Driven Design Distilled' de Vaughn Vernon, e 'Implementing Domain-Driven Design' del mismo autor. También recomendó la academia española Codely, que tiene videos gratuitos en YouTube y cursos pagos sobre DDD, y pasó links específicos.
Joaquin Sarmiento preguntó si alguien usaba LM Studio, la aplicación para correr LLMs localmente con interfaz similar a un chat de IA que usa la GPU o la RAM del sistema. Contó que había probado una versión de Claude Sonnet 4.5 de Qwen3 (14b parámetros) y no veía mucha diferencia con Claude en la web. Iñaki Fernando Lozano aclaró que en realidad era una versión de Qwen, probablemente destilada (aunque sin certeza por las restricciones legales sobre destilación de modelos cerrados). Explicó el concepto de destilación: se usa un modelo grande y capaz para entrenar a uno más chico con menos parámetros, logrando capacidades similares con menos hardware, a costa de algo de performance. Iñaki destacó que LM Studio sirve para testear límites de modelos, hasta cuánta cuantización aguantan sin perder mucha performance, y que se suele conectar con AnythingLLM como interfaz.
39cf9f4hilo grupal7 participantes
El 30 de diciembre se realizó la Dev Meetup de fin de año de PCN en el coworking Blackbox en Yerba Buena. Emiliano Grillo fue documentando el evento con fotos y Mauricio Chaile destacó que fueron muchos. La juntada incluyó charlas técnicas: Facundo Gelatti mostró en vivo un sistema de bloques y referencias en JavaScript vanilla con TypeScript y el DOM, publicado en javiergelatti.xyz/self-js, donde se puede ver para cada propiedad si es enumerable, configurable y modificable. Leandro Contrera agradeció públicamente a Facundo Gelatti y Marcelo Nuñez por las charlas, y Santiago De Marco dijo que iba a frecuentar las juntadas y compartir la info del grupo con sus compañeros de facultad. La reunión se extendió hasta que los corrieron de Blackbox y después continuaron en Café Martínez hasta que los corrieron también, según contó Agustín Sánchez en su cierre de año.
Al cierre del 30 de diciembre, Facundo García Martoni lanzó la landing de Macch, su startup nacida 4 meses antes durante un evento de redes en Córdoba. Compartió el link macch.ai y pidió feedback a la comunidad. Alejo señaló que se veía muy clean en mobile aunque había un detalle de la etiqueta mes/month en inglés, y Fede Valle detectó una card con distinto tamaño en desktop. El stack usado fue Framer como core (para poder manejar un CMS y correr ads por nicho), Lottiefiles para animaciones, Photopea para la edición de logos, Nano Banana Pro para diseño de mockups de chats, Gemini 3 Pro como asistente de marketing y copy, y Figma para la Social Media Card. La comunidad celebró el lanzamiento con mucho entusiasmo. Leandro Contrera le escribió un mensaje muy emotivo valorando no solo lo técnico sino el espíritu emprendedor de Facundo. Agustín Sánchez cerró el año con un mensaje reflexivo sobre el crecimiento orgánico de la comunidad, agradeciendo que se hubiera juntado tanta gente un 30 de diciembre.
Daniel Baltazar Escalante preguntó qué era más efectivo para seguridad: Bitwarden o KeePass. Facundo Padilla respondió que él usaba KeePassXC (la versión con interfaz más fácil de usar y open source) con la extensión del navegador para no tener que tipear claves manualmente, y destacó que la herramienta tiene certificación de la agencia nacional de seguridad francesa. Facundo García Martoni intervino desde el otro lado: lleva más de 5 años usando Bitwarden y nunca le falló; lo calificó de una ganga.
Facundo Padilla contó que se puso a aprender a crear mods para Counter-Strike 1.6 por hobbie, usando el lenguaje Pawn, y que estaba pensando en agregarle la posibilidad de correr cosas async usando Python: ya sea transpilando código Python a Pawn (que lo veía muy heavy) o pasando data desde Pawn a un script Python a través de sockets. Leandro Contrera señaló que la opción del socket podría tener latencia, y Facundo explicó que el juego corre en un solo hilo: si se bloquea, el servidor se clava hasta que termine de procesarse el script Python. La alternativa async evitaría ese problema. También mencionó una rareza del ecosistema: los códigos fuente de los mods se privatizan, y solo se distribuyen los compilados.
Agustín Sánchez compartió imágenes con reflexiones sobre el futuro de la programación con IA, lo que desató un debate filosófico-técnico. Marcelo Nuñez señaló que incluso desarrollando con IA se mantiene la belleza de entender el porqué del código: la IA termina haciendo lo que le da pereza al dev, pero el dev entiende el código del laburo con profundidad. Agustín apuntó que la nueva skill es saber armar la arquitectura del proyecto de tal forma que se puedan delegar tareas de codificación a un agente sin que falle. Facundo García Martoni argumentó que el 'mastery over the craft' del que habla The Primeagen es azúcar sintáctica del clásico 'volverse irremplazable', y que el poder que daba el conocimiento profundo de los lenguajes ahora desaparece parcialmente por culpa de Claude; por lo tanto hay dos destinos: ownership sobre el outcome o dominar el nivel de abstracción nuevo que es el AI-Assisted Programming. Iñaki Fernando Lozano cuestionó si el mastery real da irremplazabilidad, citando que un artesano tiene mastery y es definitivamente prescindible. Germán Navarro preguntó si alguien sabía cómo adaptar el workflow de agentes a proyectos grandes con deuda técnica.
A partir de la pregunta de Germán Navarro sobre cómo usar agentes en proyectos grandes con deuda técnica, Agustín Sánchez convocó a Esteban Sánchez, quien trabaja en ese contexto hace meses. Esteban explicó que el enfoque consiste en escribir agentes como archivos Markdown que especifican en detalle de qué es experto el agente (con ejemplos), lo que los 'entrena' con el contexto para tareas específicas sin repetirlo en cada prompt. En el día a día se abre OpenCode o Claude, se selecciona el agente adecuado y se tira el prompt tranquilo; como funcionan por consola, los agentes tienen libertad de ejecutar cualquier comando: navegar archivos, hacer commits, buildear, correr tests. La mayoría de las veces ayuda pero siempre requieren algo de interacción humana para limpiar el código o corregir algo. Agustín preguntó si usaban MCPs, y Esteban dijo no conocer el protocolo; Agustín explicó que permite comunicar agentes entre sí (por ejemplo con Figma o Stripe). Iñaki Fernando Lozano compartió que usa Git Worktrees con virtual hosts en Apache para servir varias ramas a la vez mientras los agentes van terminando.
Facundo García Martoni, trabajando de noche en la landing de su producto, compartió el descubrimiento de lottiefiles.com para los apasionados del frontend: una plataforma de animaciones Lottie que permite integrar animaciones de alta calidad en webs y apps de forma muy simple. Lo mencionó como un recurso que estaba usando en ese momento para la landing de Macch.ai, junto con Framer como core del proyecto. Leandro Contrera dijo que no lo conocía y agradeció el dato.
Leandro Contrera preguntó al grupo si hacían la distinción entre diseño de bajo nivel y alto nivel, y también entre arquitectura física y arquitectura lógica, ya que le confundían las capas de abstracción. Mientras iba formulando las preguntas fue respondiéndose solo parte de ellas. Marcelo Nuñez respondió con un audio explicando la diferencia entre los 'planos' del sistema. Leandro preguntó en específico si los paquetes de dominio, persistencia y lógica de negocio se podían entender como subcapas de la arquitectura lógica (como en el modelo de arquitectura cebolla), y Marcelo confirmó que sí. La conversación también roció el tema del WSL (Windows Subsystem for Linux): Facundo Padilla explicó que permite correr un Linux dentro de Windows sin reemplazar PowerShell, y que la shell de Linux y PowerShell coexisten.
Agustín Sánchez anunció una Dev Meetup especial para el 30 de diciembre para cerrar el año, con cupo limitado y como cereza del postre el estreno del sistema de inscripciones en la web de PCN (programaconnosotros.com/meetup). El grupo respondió con mucho entusiasmo: Facundo Bazán felicitó, Juan Farber deseó todos los éxitos, y Alejo lamentó estar en Buenos Aires y perdérsela. La novedad del sistema de inscripciones propio fue destacada por Agustín como un hito en el desarrollo del website de la comunidad.
Facundo García Martoni anunció que había llegado al límite de su plan de Cursor de 60 USD en apenas 5 días, precisamente después de haber lanzado 4 o 5 features en dos días. Agustín Sánchez bromeó preguntando si era el límite del plan de 200 USD, y Facundo aclaró que por suerte era el de 60. Facundo admitió que probablemente iba a pasar al plan de 200 USD dada su cadencia de uso. El hilo derivó en una reflexión compartida sobre el momentum que estaban viviendo: Agustín dijo sentirse muy motivado y que le costaba soltar la computadora. Facundo señaló humorísticamente que el nuevo cuello de botella del desarrollo era el Code Review —que ahora era el humano, no la máquina— y que había que cambiarlo.
Leandro Contrera compartió una imagen con la pregunta de si se aprende más en una startup o en una empresa grande. Agustín Sánchez fue claro: startup, y convocó a Benjamin Cortes para que lo confirmara dado que había trabajado en Microsoft en Canadá. Benjamin confirmó al 100%. Agustín explicó que en empresas grandes cuando te dan lugar a resolver problemas grandes de ingeniería se aprende muchísimo, pero que a los juniors no les dan mucha cancha y terminan resolviendo cosas muy menores; en una startup aprenderían mucho más. También mencionó que empezar en consultoras haciendo sistemas desde cero con equipos chicos permite tomar más ownership en las features. Alejo, que ese año había empezado en una startup, confirmó que mejoró bastante en conocimientos por tener que aprender cosas nuevas a diario. Agustín compartió un podcast sobre el costo de oportunidad en la industria del software relacionado con esa discusión.
Julián Vélez (Colombia) publicó un quiz de Python sobre el resultado de `math.sqrt(16) == 4` y el grupo debatió la respuesta. Facundo García Martoni apostó por False porque `sqrt` devuelve un float y al compararlo con un entero debería dar False. Marcelo Nuñez coincidió por el tema de los puntos flotantes: `0.1 + 0.2 == 0.3` también da False. Facundo Padilla aclaró que en Python no se comparan tipos sino valores y que el método `__eq__` considera que 4.0 y 4 son lo mismo. Santiago De Marco preguntó si con `parseInt` se solucionaba el problema, y la charla derivó en la diferencia entre casting y parsing. Facundo Padilla explicó que Python tiene el módulo `Decimal`, creado por un argentino llamado Facundo Batista en 2005 para resolver exactamente el problema de los puntos flotantes, y que fue adoptado en el standard de la PEP 327. Iñaki Fernando Lozano compartió un PDF de clase de errores numéricos que recordaba de la facultad, generando nostalgia en el grupo.
Germán Navarro explicó la diferencia entre el modelo de datos y el modelo de dominio según el principio SOLID: las clases del dominio deberían ser las que tienen comportamiento, mientras que en casi todos los frameworks los modelos de base de datos terminan siendo clases que solo representan datos —lo que los libros llaman 'modelo anémico'— y toda la lógica de negocio queda en clases 'service'. Alejo Boga preguntó si la solución sería usar un modelo o esquema con una clase para definir la entidad y encima ponerle un repository con la lógica de negocio. Germán aclaró que sería tener una clase tipo 'Producto' con la lógica de negocio propia y otra clase tipo DAO que represente la entidad en datos. Señaló que en proyectos no muy grandes esa separación generalmente no vale la pena y conviene más usar un ORM porque ahorra tiempo; la separación tiene sentido cuando la lógica de negocio se complica o cuando el modelo de dominio no coincide con cómo se guarda en la base de datos.
Victor Figueredo irrumpió en el grupo para compartir que estaba replicando un proyecto que usa redes neuronales para mapear la fase y la amplitud de señales WiFi (CSI, Channel State Information) a coordenadas UV que representan la superficie del cuerpo humano, permitiendo 'ver' detrás de las paredes de forma similar a un sonar. Marcelo Nuñez se entusiasmó inmediatamente y mencionó haber visto un proyecto donde se usaba un microondas como micrófono, mostrando lo zarpado que podía ser el hardware creativo. Victor compartió el PDF del paper en arxiv.org y aclaró que primero necesitaba conseguir un router TP-Link Archer A7 AC1750 para poder hacer las pruebas. Marcelo prometió leer bien el paper el fin de semana y armar el proyecto, y Victor le pasó un drive con recursos adicionales.
Marcelo Nuñez comentó que los últimos updates de Cursor lo habían desencantado, especialmente por lo invasivo que se volvió el manejo de agentes y porque la experiencia de desarrollar Python en Cursor no lo terminaba de convencer. Estaba considerando cambiar a Claude Code como alternativa. Nicolas Fuentes, que lo usaba activamente, describió la experiencia: todo se hace desde la terminal aprovechando ventanas de contexto, ofrecen cursos para usarlo de forma óptima, pero tiene tokens diarios (que se actualizan cada 5 horas) y tokens semanales; si consumís los semanales es un bajón porque la alternativa es pagar por prompt a un precio muy alto. Agustín Sánchez confirmó conocer gente que labura con Claude sin Cursor y le gusta. Facundo García Martoni pidió que Marcelo fuera más específico sobre los problemas con Cursor para poder ayudar. El intercambio mostró que Claude Code está ganando tracción como alternativa real a los IDEs AI para devs que prefieren el flujo de terminal.
Santiago De Marco propuso crear un club de lectura técnica dentro de la comunidad, motivado por querer leer más libros del rubro. Juan Arismendi desarrolló la idea: proponer un libro, que todos lo lean en un mes o dos semanas, y al final debatirlo, que es como funcionan los clubes de lectura típicamente. Agustín Sánchez lo tomó con entusiasmo y propuso que Santiago y Juan lo gestionaran ellos mismos, creando un grupo de WhatsApp dentro de la comunidad para eso. Agustín creó el grupo y compartió el link. Juan anunció que armaría un Excel para cargar propuestas de libros y después votar cuál leer primero. La iniciativa quedó en manos de Santiago De Marco y Juan Arismendi para organizarla.
Gonzalo Morales tenía que construir para un cliente una plataforma de cursos donde los usuarios compraran acceso y vieran videos, similar a devtalles. La duda principal era el alojamiento de videos: había investigado Vimeo Pro pero no había descartado S3. Mateo Lohezic recomendó MUX: sale 10 USD al mes con una capa de 100 USD de crédito incluidos, es muy sencillo de integrar, y hasta permite streamings en vivo. Mateo lo había usado para una plataforma similar que ya tenía online. Fede Valle contó que en un proyecto anterior la clienta ya tenía Vimeo y simplemente usaba el ID de Vimeo para embeber los videos, funcionando bien. La conclusión del hilo fue clara: MUX es la opción más recomendada para este tipo de proyectos.
En el contexto de la discusión sobre OpenAI perdiendo terreno frente a Anthropic, se generó un intercambio sobre qué modelos usaba cada uno. Iñaki Fernando Lozano contaba con GPT 5.1 Codex, Sonnet 4.5, Gemini 3.0 Pro y Haiku 4.5 para distintas tareas, aprovechando que tenía acceso a los tres IDEs principales. Facundo García Martoni declaró usar principalmente Opus 4.5, Gemini 3 Pro, Gemini 2.5 Flash y Flash Lite, y contó que había gastado 50 USD en créditos de Opus en una semana pero que valió la pena porque valía la pena cada línea. Iñaki señaló que Opus es inusablemente caro para uso regular y que cuando lo ofrecieron al mismo precio que Sonnet 4.5 lo aprovechó. Facundo reflexionó que para tareas que traen 10x en ganancias y ahorran 5x tiempo de debug, pagar 100 USD en créditos era una decisión obvia. La discusión mostró que la comunidad tiene un approach sofisticado de usar distintos modelos según el tipo de tarea.
Agustín Sánchez recomendó el T3 Stack (Next.js, Tailwind, TypeScript, tRPC, Drizzle, Supabase) como uno de los cinco stacks con más salida laboral y velocidad de desarrollo hoy en día, señalando que es lo que usa en Eagerworks y también en el website de PCN. Gonzalo Morales confirmó que ya lo usaba y que lo sentía cómodo y productivo, ahorrando mucho tiempo; estaba incorporando Better Auth en reemplazo de Supabase Auth. Gonzalo también tenía otro proyecto con Ionic, Angular, NestJS y MongoDB que iba a refactorizar; Agustín preguntó si tenía sentido MongoDB en ese caso y Gonzalo reconoció que no estaba bien planteada la base de datos y que una relacional hubiera sido mejor, sumándose al consenso del grupo de que la mayoría de los proyectos con MongoDB terminan con ese problema. Mauricio Chaile destacó que la IA tiene mucho código de ejemplo con el T3 Stack, lo que reduce las alucinaciones. Agustín prometió buscar cursos del stack para pasarlos en el grupo.
Mateo Lohezic contó que recién salía de una entrevista para un puesto de AI Engineer Junior para Canadá, con salario de USD 2.000-2.500 mensuales como contractor. Mauricio Chaile y Agustín Navarro preguntaron qué hacía un AI Engineer, y Mateo respondió que en la práctica significaba saber usar la API de OpenAI. La entrevistadora le había preguntado sobre su manejo de Node.js, React y CSS. Marcelo Nuñez explicó que el concepto de AI Engineer está siendo muy manejado en la industria: en muchas empresas es un backend que sabe usar APIs de OpenAI, Ollama o LangChain, pero el rol aún no está maduro en cuanto a qué incluye exactamente. Su consejo fue mandarse ahora que está en formación y hay oportunidades. El hilo evidenció que hay una demanda real y creciente de devs con conocimiento de integración de IA, aunque el nombre del rol es todavía vago.
Alejo Boga planteó que los precios de las IAs van a subir porque las empresas están quemando capital: la inversión en IA es de 800 billones y las ganancias de 300 billones, hay un gap de 500 billones subsidiado. Facundo García Martoni discrepó, estimando que a largo plazo los precios bajarán como históricamente bajó el costo de computación, y señaló que modelos pequeños y optimizados como Gemini 2.0 Flash Lite ya abren posibilidades increíbles sin necesitar modelos de punta. Alejo aceptó que puede haber casos aislados de modelos de negocio rentables con IA, pero que el verdadero costo aún es desconocido por el subsidio. El debate se extendió a la competencia entre labs: Facundo García Martoni apostaba por Google, Cursor y Anthropic como el trío dominante. Iñaki Fernando Lozano analizó que OpenAI no está perdiendo en términos nominales pero la competencia creció mucho; Anthropic encontró su nicho en development y B2B, mientras que Google está alcanzando a ambos rápidamente. Alejo destacó que el mayor impacto de la IA hasta ahora fue mejorar la eficiencia de los desarrolladores.
Fede Valle confesó haber cobrado solo USD 1.200 por un proyecto de LMS que le llevó 4 meses de trabajo, equivalente a USD 2.50 la hora, y pidió ayuda para aprender a cotizar mejor. Agustín Sánchez compartió referencias del mercado: junior entre 500 y 2.000 USD mensuales, semi-senior entre 2.000 y 4.000, senior 4.000 para arriba; dividiendo por 160 horas mensuales se obtiene el valor hora. Victor Figueredo compartió el sitio salarios.gonzalopozzo.com como referencia. Mateo Lohezic contó cómo trabaja con su socio (diseñador): cobran precio cerrado por proyecto ($600-2.000 USD una landing), usando etapas bien definidas —planificación, diseño/maquetado, desarrollo, soporte— con la cláusula de que los cambios de diseño se hacen solo en la etapa 2 y cualquier feature nueva es nuevo presupuesto. Mateo agregó que siempre incluyen un pequeño colchón en el presupuesto para poder decir que sí a pequeños pedidos del cliente sin costo adicional y quedar como generosos. Agustín destacó la importancia de definir bien la etapa de soporte para no trabajar gratis arreglando bugs post-lanzamiento.
Facundo García Martoni negoció con los dueños del coworking Blackbox (Boulevard 9 de Julio, Yerba Buena) acceso gratuito para todos los miembros de PCN durante diciembre de 13 a 18hs, aprovechando que las tardes estaban vacías. Anunció café gratis, medialunas los miércoles y frutas los lunes. La comunidad respondió con entusiasmo y Agustín Sánchez organizó la primera juntada formal para el lunes 15 de diciembre. Facundo contó que trabajar fuera de casa le subía la productividad un 1000% y que estaba molestando a los dueños para que extendieran el horario hasta las 22hs. Gonzalo Morales y Agustín Navarro ya conocían el espacio y lo elogiaron. Los dueños del Blackbox también les ofrecieron dar charlas gratis cuando quisieran, lo que el grupo tomó como una oportunidad para eventos futuros.
Agustín Sánchez mostró su setup con una silla postural Balans (sin respaldo, con apoyo de rodillas) y un standing desk de Inpro 150x70, y contó que llevaba semanas usándolo feliz alternando entre sentado y parado. Gonzalo Morales preguntó cómo se sentía después de muchas horas, y Agustín dijo que el máximo fue hora y media seguido pero no porque le incomodara, sino porque le gustaba trabajar parado también. Gonzalo aportó que su kinesiólogo lo retó por pasar muchas horas sentado, ya que inhibe el glúteo y genera descompensaciones. Alejo Boga dijo que para él fue un antes y un después para la espalda, hombros y postura cuando empezó a trabajar de pie. Emiliano Grillo mostró su standing desk de Inpro en color nogal con funciones de memory de alturas y timer automático. Agustin Navarro mostró una opción manual de la marca Naku que sale a la mitad de precio. Marcelo Nuñez compartió que había comprado uno de Amazon (marca Huuger) y iba a contar la experiencia cuando llegara. Emiliano recomendó también la marca Neonix como alternativa más barata que Inpro.
Fede Valle preguntó recomendaciones para deployar su primer proyecto fullstack de cliente: backend en Render plan Starter (7 USD), base de datos en Supabase (free) y frontend en Vercel (free). El grupo analizó las opciones y Fede se entusiasmó con DonWeb como alternativa más económica donde podía correr Nest, Next y Postgres en un mismo servidor. Iñaki Fernando Lozano advirtió que Next es muy hambriento de RAM. Leandro Contrera preguntó qué eran las vCPUs e Iñaki explicó en detalle: son núcleos virtuales que el proveedor vende como servicio de máquinas virtuales donde una computadora con procesadores de servidor de muchos núcleos se divide en múltiples planes de VPS; la mayoría hace overcommit y asigna poder de cómputo on demand. Iñaki también compartió que él tiene un VPS de 4 vCPUs y 16GB RAM en Hostinger. Matias Gutierrez contó que directamente le pide al cliente que pague Vercel, calificándolo como su mejor decisión.
Marcelo Nuñez vio por primera vez una estimación de software en talles de remera y pensó que era un meme. Agustín Sánchez le explicó que es un sistema análogo a los story points de Fibonacci: se usa una abstracción para medir la complejidad de la tarea en lugar de las horas, y la ventaja es que desacopla la estimación del seniority del dev (un senior puede hacer una tarea M en un día y un junior en tres). La desventaja que señaló Agustín es que complica calcular la velocidad por sprint de cada dev individualmente. Agustín también mencionó haber notado que tanto devs como PMs en la industria suelen no entender bien este sistema de estimación.
Fede Valle tuvo un error de Prettier que no recordaba cómo resolver. Germán Navarro identificó rápidamente el problema: el carácter de fin de línea, y recomendó buscar la opción end of line en el config de Prettier y elegir LF. Fede confirmó el diagnóstico: Prettier y el ecosistema JavaScript esperan LF (Unix), pero VSCode en Windows usa CRLF por defecto. La solución fue configurar endOfLine en el archivo .prettierrc. Marcio B agregó que también se puede configurar en .editorconfig y cambiarlo directamente desde la status bar de VSCode. Germán aclaró que esto es un problema que solo aparece en Windows y que se puede evitar para todo el repo definiendo las reglas en el archivo de configuración.
El 18 de noviembre, coincidiendo con el cumpleaños de Agustín Sánchez, se produjo una caída global de Cloudflare que afectó a ChatGPT, Claude, Perplexity, X, Canva, Spotify, Udemy, League of Legends, GitHub, y páginas gubernamentales, entre muchas otras. Julián Vélez (Colombia) compartió un resumen detallado con la lista de servicios afectados y el link al status oficial de Cloudflare. Agustín contó que lo despertaron los clientes calientes porque sus websites se cayeron, y graficó lo loco que es que falle un solo proveedor y caiga media internet. Iñaki Fernando Lozano apuntó que si bien el paradigma original de internet era descentralizado, en la práctica siempre fue centralizado alrededor de providers como Cloudflare y Amazon. Alejo recordó que también se había caído AWS un mes antes, marcando un patrón preocupante de fragilidad en la infraestructura central de internet.
Benjamin Cortes compartió la noticia de que Cursor levantó una ronda de inversión de 2.300 millones de dólares, calificándola de locura. Exequiel De Freitas señaló una ironía: Cursor recomienda el plan de 60 USD por mes, pero si elegís facturación anual no te hacen ningún descuento. La noticia reforzó en el grupo la percepción de que Cursor seguía siendo el IDE AI líder del mercado, con una trayectoria de crecimiento muy sólida.
181c7ad2 participantes
Alejo Boga compartió una imagen con la opinión del CEO de una startup argentina (getautonoma.com) de que la IA iba a reemplazar a los QAs, aclarando que el tipo podría estar sesgado por tener un producto de QA con IA. Marcelo Nuñez discrepó fuerte: los buenos QAs piensan en casos que al desarrollador nunca se le ocurren, y el que tiene en su equipo además conoce el negocio mejor que él. David Petersen, como QA, también discrepó y contó que hay empresas entrenando QAs en el uso de IA para complementar, aunque algunas sí creen que el rol es reemplazable y hasta se lo dijeron en entrevistas. Alejo matizó diciendo que el debate no era sobre la calidad de los QAs sino sobre cómo el mercado los percibe. Marcelo predijo que las empresas que hicieron despidos masivos reemplazando QAs por IA van a volver solas a buscarlos, como ya pasó con los devs. El consenso fue que lo más probable es que el mercado pida menos QAs pero ai-powered.
Facundo García Martoni compartió una reflexión sobre el focus a partir de hablar de proyectos múltiples: contó que en distintos momentos de su vida tuvo que aplicar la regla de 'elegir una cosa'. Se entusiasmó con el boxeo al punto de sacar la licencia amateur y preparar peleas, lo que lo hizo estancarse en su carrera de software. Después le pasó lo mismo con el tiro deportivo. En ambos casos tuvo que decirse a sí mismo que su pasión real era la tecnología y cortar con lo nuevo. Fue claro en que no está mal tener hobbies, pero que para ser excelente en un campo o emprender con éxito hay que hacer sacrificios. Tobías Paz Posse reconoció que le pasaba algo similar. Facundo recomendó el libro 'The Molecule of More' de Daniel Z. Lieberman, que explica los mecanismos de dopamina detrás de videojuegos, casinos, redes sociales y relaciones. Leandro Contrera comentó que él tiene un control parental de 30 minutos diarios para Lichess para no perderse horas en el ajedrez.
Leandro Contrera compartió Unhook, una extensión para Chrome, Firefox y Edge que elimina features de YouTube para reducir distracciones. Facundo García Martoni sumó en la misma línea Undistracted (bloquea features adictivas de redes sociales en Chrome y Firefox), Social Focus (para Safari en iPhone y Mac), y One Sec (para apps nativas del teléfono que frena el impulso de abrir apps adictivas). Juan Arismendi recomendó StayFree, que tiene app desktop, Android y extensiones que se pueden sincronizar. Ariel Basabe agradeció los datos.
Leandro Contrera preguntó por el rol del Scrum Master, recordando que en el grupo había opiniones negativas al respecto y queriendo entender dónde encajaba dado que parecía un rol más de habilidades blandas que técnicas. Alejo Boga respondió que el Scrum Master, renombrado como Agile Leader, estaba en proceso de desaparición; hoy es más común ver PMs facilitando las ceremonias de Scrum. Alejo también observó que las metodologías ágiles en general están de salida, aunque las consultoras las mantienen más por tener equipos ya armados para ese modo de trabajo. Iñaki Fernando Lozano aportó que la organización estaba evolucionando: se tomó lo bueno de Scrum (respuesta rápida al cambio, colaboración, entregas incrementales) y se dejó el garbage de las formalidades que agregaban carga sin utilidad. Cuando Scrum se volvió más ceremonia que mindset, tuvo que mutar o morir. Iñaki destacó que ahora se ven PMs más metidos en producto con mejor comunicación con el equipo de desarrollo.
Fede Valle consultó sobre Stripe al crear su cuenta y encontrar que Argentina no estaba disponible como país. Josefina Japaze confirmó que Stripe no está disponible para pesos argentinos, y Ariel Basabe agregó que tampoco para su app de turnos podían usarlo. Ariel recomendó Lemon Squeezy como alternativa, pero un integrante venezolano del grupo advirtió que no lo usaran porque se caía constantemente, y recomendó en cambio Polar.sh. Facundo García Martoni mencionó DLocal Go como opción que había funcionado en su caso. El grupo migró al tema de MercadoPago Checkout Pro: Josefina tenía dos problemas en sandbox, las tarjetas de prueba no le dejaban hacer pagos y los pagos que sí pasaban no llegaban al webhook. Germán Navarro confirmó que ese era un problema famoso de MP desde hace años. Marcelo Nuñez declaró odiar los webhooks profundamente, aunque aclaró que los de Stripe andaban mucho mejor y hasta se podían probar con la CLI de Stripe. Fede Valle finalmente logró hacerlo funcionar.
Facundo García Martoni compartió que estaba probando n8n por primera vez y pidió feedback sobre la herramienta. Alejo mencionó haber visto un video donde se guardaban emails de una waitlist en Google Sheets automáticamente. Facundo destacó que lo que le parecía increíble era poder crear un web form directamente desde n8n y llevar las respuestas a Slack, Sheets o Telegram sin código manual; lo calificó como un intermedio entre código y no-code que lo hace divertido. El mismo día terminó su primer proyecto: un widget en Android que mostraba su balance de cierto asset en Binance. El flujo era recibir una request en un webhook de n8n, pegarle a la API de Binance con firma HMAC, limpiar y filtrar el JSON, sumar los montos, y responder al webhook; en Android usaba la app KWGT para consumir ese endpoint y mostrarlo en la pantalla de inicio con un cron job que corría 3 veces al día. Nacho preguntó por el 'killer de n8n' que mencionó Midudev, y Facundo identificó que era el nuevo Agent mode de OpenAI, aunque dijo no confiar en OpenAI como empresa desde hacía tiempo.
Alejo preguntó qué andaban desarrollando los integrantes del grupo y se generó un intercambio rico sobre proyectos personales. Exequiel De Freitas contó que con otros dos socios estaba armando CitaUp, un SaaS de gestión de turnos donde negocios como estéticas o peluquerías registran sus empleados, servicios y horarios y eso genera una mini landing page para que los clientes saquen turnos. Leandro Contrera estaba diseñando un prototipo de app que analiza imágenes de interfaces con IA y tira feedback sobre usabilidad basado en métricas de IHC (Interacción Humano-Computadora). Alejo compartió que llevaba tiempo con una app de productividad personal que abarca rutinas, gestión de conocimiento y proyectos, con IA que genera estadísticas y recomendaciones; había lanzado una waitlist en Reddit y había conseguido más de 300 registrados. Facundo García Martoni reflexionó que estaban en el medio de un cambio fundamental en el desarrollo de software donde escribir código manualmente se estaba volviendo obsoleto, comparando al programador con el conductor de un auto: sigue siendo necesario conocer la ruta aunque no camine.
A partir de la mención de Alejo sobre su waitlist en Reddit, Exequiel De Freitas preguntó cómo era eso de publicar en Reddit para validar ideas y si había un foro específico. Alejo explicó que entró directamente al nicho de su app y publicó en el subreddit /r/productivityApps, donde tuvo bastante tracción. También probó publicidad para Latinoamérica pero no llamó tanto la atención. Recomendó meterse donde están los potenciales clientes en lugar de publicitar de forma genérica. Ariel Basabe hizo una analogía con Tinder, cuya fundadora fue a preparatorias a promocionar el producto en sus inicios. Alejo Boga sumó que los batches de Y Combinator (ycombinator.com/companies) son una buena fuente para ver qué nichos están recibiendo inversión y descubrir oportunidades de mercado.
Juan Farber anunció que su empresa le dio un budget de USD 500 para renovar sus periféricos (teclado, mouse y mousepad) y pidió recomendaciones considerando que usa macOS. Facundo Padilla recomendó periféricos específicos para Mac y compartió su experiencia con el Logitech g603, un mouse inalámbrico con Bluetooth que le duraba más de un año con pilas. Exequiel De Freitas mencionó el Logitech g213 Prodigy como un teclado cómodo y silencioso. Facundo García Martoni recomendó el Logitech Proteus Spectrum como el mejor mouse de la historia, y para teclados mencionó el HHKB como la opción premium, los Aula como buena relación calidad-precio, y Keychron para Mac; para pad recomendó cualquier XL de Redragon. Facundo Padilla también mencionó que había comprado un teclado 60% de la marca Solarmax a 60 mil pesos, con Wireless 2.4, USB-C y Bluetooth por tres canales, cuya calidad le sorprendió para el precio.
Facundo García Martoni pasó por el chat para compartir que estaba teniendo una racha de 10 one-shots seguidos programando con Sonnet 4.5, calificándolo de un deleite. Exequiel De Freitas preguntó si usaban el 4.5 solo o el thinking, y Facundo aclaró que en Cursor solo está disponible el thinking, y que siempre prefería thinking porque el problema de que el modelo se 'pase' en razonamientos estaba prácticamente resuelto. Facundo García Martoni también armó en 2 horas con vibe coding una app usando Claude.ai artifacts para el diseño (Sonnet 4.5), React con Tailwind y localStorage para la data, Cursor para ajustes, Gemini 2.5 Flash para el logo, Photopea para editar el logo, y GitHub Pages como deploy en modo PWA con exportación a JSON. Facundo destacó que el modelo permitía incluso corregir algo, pensarlo mejor y darse cuenta de que en realidad estaba bien, llegando al punto de querer pedirle perdón al modelo.
Alejo preguntó por tips para arrancar como freelancer haciendo landings y dashboards, ya que conseguir clientes era su mayor dificultad; mencionó que trabajaba para una agencia extranjera por hora pero sin proyectos no cobraba. Fede Valle compartió su experiencia desde enero: primero construyó una marca personal junto a un amigo, y a partir de proyectos bien presentados en el portfolio la marca les daba confianza a los referidos para cerrar tratos. Fede destacó que la solidez de la marca les permitió además cobrar precios más elevados que antes. Mencionó que hay plataformas como Upwork para postularse a trabajos, aunque él personalmente no las usaba. Alejo había empezado a diseñar una landing mostrando proyectos, servicios y el proceso de trabajo, lo que Fede validó como buen comienzo, recomendando meterse a fondo en la marca personal.
Leandro Contrera agradeció públicamente a Marcelo Nuñez y Mauricio Sánchez por un taller que habían dado, elogiando la oratoria, didáctica y profundidad de las preguntas de Marcelo que lo dejaron pensando. Álvaro Toledo también valoró el taller como muy completo, útil para recuperar conceptos y articular el desarrollo de un MVP, destacando la sencillez con la que los disertantes explicaban conceptos complejos. Mauricio Sánchez aclaró que fue un taller de diseño de sistemas en general, con una segunda parte planificada. El intercambio generó mucho reconocimiento en la comunidad, con Germán Navarro calificando a los dos de 'cracks'.
Exequiel De Freitas preguntó si alguien tenía experiencia con Supabase usando direct connection string, ya que él y un colega habían pasado horas tratando de configurarlo con el mismo setup y a uno le funcionaba y al otro no, con el error P1001 de Prisma indicando que no podía alcanzar el servidor de base de datos. Kevin Martin respondió que él había tenido los mismos problemas con la conexión directa y que al final lo resolvió cambiando a la conexión pooled. Matias Gutierrez confirmó que le había pasado exactamente lo mismo. Gonzalo Morales sumó que en proyectos con Prisma ORM usaba ambas strings pero con Drizzle usaba solo una y funcionaba; la discusión quedó abierta sobre por qué con la misma config a unos les andaba y a otros no, sin una explicación definitiva.
Fede Valle compartió que estaba construyendo una LMS (Learning Management System) con NestJS, Postgres y Next.js, ya iba por el 60% del proyecto y le preocupaba que a medida que crecía estuviera tomando malas decisiones técnicas. Marcelo Nuñez le respondió con un consejo desde la experiencia: no abrumarse con las buenas prácticas, porque principios como SOLID son muchas veces sobre-diseño; citó un debate que Hernán Wilkinson le dio a Uncle Bob al respecto. Marcelo recomendó guiarse por el principio KISS (Keep It Simple, Stupid), que aprendió después de años de hacer MVPs con Clean Architecture y SOLID y frustrarse. Exequiel De Freitas sumó que lo importante era que el código funcione, esté ordenado para entenderse meses después, sea razonablemente performante y esté bien documentado. Marcelo también recomendó PlantUML para hacer diagramas y guardarlos en Git como código. Gonzalo Morales cerró el hilo reconociendo que había perdido mucho tiempo queriendo hacer todo perfecto en lugar de hacerlo simple.
Mauricio Chaile preguntó qué tan parecido era Spring a NestJS, ya que ChatGPT le había dicho que eran similares. Marcelo Nuñez confirmó que sí son bastante parecidos y agregó un dato histórico clave: NestJS se inspiró directamente en Spring. Marcelo fue categórico al decir que hoy en día es prácticamente imposible programar Java para APIs REST sin saber Spring, ya que es el framework dominante en ese mundo. Aclaró que Spring también funciona con Kotlin aunque no es tan popular en ese ecosistema. Ariel Basabe y Marcelo coincidieron en que Spring es una belleza para desarrollar de forma ordenada. Nahuel González mencionó que estaba estudiando Java con interés en backend y a futuro en aplicaciones móviles con Kotlin, lo que entusiasmó a Marcelo, declarado fanático de Java.
Agustín Sánchez estuvo en Nerdearla en Buenos Aires y al día siguiente compartió un resumen detallado de las charlas que vio. Destacó la charla de cierre de Midudev, quien mostró los avances de la inteligencia artificial y herramientas nuevas, y revisó cómo desde hace 50 años la gente predice la muerte de la programación cada vez que sale algo que 'simplifica' el trabajo, sin que eso ocurra. Mencionó también una charla de Hernán Wilkinson sobre la belleza y la pasión en el desarrollo usando TDD, y otra sobre Vibe Test-Driven Development, que recomendaba commitear frecuentemente cuando se vibe-codea para poder revertir si la IA la caga. Agustín resaltó una charla de un argentino de 23 años que entró a trabajar en Cline (extensión de VS Code tipo Copilot) desde San Francisco gracias a haber colaborado en PRs open-source; el mensaje fue que con IA es más accesible que nunca contribuir a proyectos que pueden cambiar la carrera. También mencionó una charla sobre code smells comunes —nombres malos, funciones largas, falta de tests— donde la oradora dejó claro que los tests automatizados son clave para refactorizar con confianza. Por último, unos devs de Galicia mostraron cómo implementaron microfrontends en React Native. Alejo Boga preguntó de qué había sido la charla de Midu, y Agustín prometió pasar el link cuando se subiera a YouTube, lo que ocurrió el 1 de octubre.
Agustín Sánchez compartió un post de Twitter que generó debate sobre cómo las empresas valoran la experiencia en software. Leandro Contrera desarrolló su punto de vista: los años no son una buena métrica de valor porque 'experiencia' es muy relativa al tipo de proyectos; un senior con 10 años en desktop que salta a mobile puede necesitar empezar casi desde cero en tecnologías pero adaptarse muy rápido. Argumentó que el verdadero valor debería medirse por mérito demostrado, no por antigüedad. Ariel Basabe, con experiencia desde 2005, compartió su perspectiva contraria: la experiencia acumulada sí importa mucho, porque una buena base permite adaptarse más rápido a nuevas tecnologías, y puso el ejemplo de un programador Cobol de 55 años que aprendió ABAP sin dificultad. Agustín cerró explicando que lo que planteaba el post original es que a veces conviene contratar un junior que con un poco de capacitación puede rendir muy bien a un costo mucho menor que un senior.
La conversación arrancó con Agustín Sánchez explicando por qué a veces las empresas prefieren contratar juniors sobre seniors: un junior capacitado rinde bien en proyectos repetitivos a un costo mucho más bajo. Agustín detalló cómo funcionan los sistemas de review de performance, señalando que hay empresas donde se sube de seniority dos veces al año y otras donde el sueldo no se toca nunca. Distinguió entre empresas de producto (MercadoLibre, Uala, PedidosYa), que viven de sus usuarios y tienen más margen para aumentar, y consultoras que cobran por hora por dev y deben subir ese rate antes de poder subir un sueldo. Alejo Boga aportó que las big tech suelen apostar por el potencial de los juniors antes que por la seguridad de los seniors, y que borrar experiencia del CV levanta alertas automáticas en los filtros de RRHH. Juan Arismendi preguntó si tener experiencia práctica pero sin título universitario podía compensar en búsquedas que pedían ingeniería, y Alejo le respondió con un orden de importancia: experiencia laboral en empresas similares primero, título y conocimiento autodidacta tercero, freelance al final. La discusión dejó en claro que el filtro humano tampoco suele pasar a quien no encaja en el perfil, salvo que sea la única opción disponible.
A partir del documento sobre el patrón MVC compartido por Leandro Contrera (diapositivas de su materia de paradigmas en la FRT hechas con LaTeX), se armó un debate técnico sobre si React usa MVC. Agustín Sánchez fue categórico: React es una librería para manejar componentes de UI y no implementa MVC por defecto. Marcelo Nuñez propuso que si bien React no lo hace, Next.js con server actions y un ORM como Prisma puede verse como una implementación de MVC: las pages serían vistas, las server actions actuarían como controladores, y el ORM como modelo. El debate derivó en MVP (Modelo-Vista-Presentador), un patrón orientado a desktop donde la vista implementa una interfaz y el presentador no conoce directamente la vista, lo que permite migrar de una vista a otra sin cambiar el presentador. También se mencionó MVVM (muy usado en mobile nativo) y el patrón VIPER. Mauricio Sánchez confirmó que MVVM y VIPER se usan en iOS.
Leandro Contrera anunció su primer proyecto para un cliente: una app web para gestionar máquinas de peluches distribuidas en varias sucursales. El sistema incluiría escaneo de QR por máquina, carga manual de datos (tiros realizados, premios entregados), listado de máquinas, login con usuario y contraseña, y generación de reportes (máquina con más tiros, más premios, etc.). Leandro planteó usar JS/TS full stack con arquitectura cliente-servidor. Varios miembros del grupo le dieron consejos: dado que son menos de 20 máquinas no se justifica POO ni arquitecturas complejas; en frontend moderno se trabaja con paradigma funcional y componentes, no con clases. El grupo lo felicitó por el primer proyecto propio.
Agustín Sánchez compartió orpc.unnoq.com y un miembro venezolano del grupo dijo que ya lo estaba usando y que era 'mil veces mejor que tRPC': mucho más liviano, más rápido y con mejor sintaxis. Agustín mencionó que no lo había usado todavía pero que le apareció hacía unos días. El miembro venezolano aclaró que no le había encontrado ninguna limitación y que lo estaba usando en una app mobile también.
Leandro Contrera preguntó si en metodologías ágiles se pone menos énfasis en la arquitectura de software. Agustín Sánchez respondió que la metodología no condiciona la arquitectura. Marcelo Nuñez recomendó escuchar el planteo de Uncle Bob sobre metodologías ágiles: el punto original del manifiesto ágil era tener feedback más rápido con el cliente, no eliminar el diseño. Agustín compartió ejemplos de diagramas que él mismo usa en un MVP de plataforma de streaming (hechos con Excalidraw), mostrando un diagrama de arquitectura física y otro de base de datos con multiplicidad. La discusión también abordó la diferencia entre arquitectura física y lógica, y cuánto nivel de documentación es razonable según la madurez del equipo.
Facundo Padilla compartió el link a un artículo de socket.dev explicando que la cuenta del autor de varios paquetes populares de NPM fue comprometida mediante phishing y se publicaron versiones maliciosas. La lista de paquetes afectados incluía chalk@5.6.1, chalk-template@1.1.1, color-convert@3.1.1, ansi-regex@6.2.1, ansi-styles@6.2.2, supports-color@10.2.1, debug@4.4.2, entre otros. El hilo fue un alerta importante dado el nivel de dependencia de estos paquetes en el ecosistema JavaScript.
Facundo García Martoni probó Claude 4.1 Opus para una tarea de CSS bien compleja (animar una mascota) y fue el único modelo que después de varios prompts le dio algo decente. Claude Sonnet 4 y GPT-5 ni se acercaron. Al ver que la IA todavía está lejos de hacer buen CSS drawing, Facundo preguntó en el grupo si había algún experto en CSS que quisiera unos pesos a cambio de la tarea. Nacho Tello sugirió crear una IA entrenada solo con el conocimiento de Manz (reconocido experto en CSS). Matias Gutierrez y Ariel Basabe mencionaron a Julián Vélez como alguien que sabe mucho de CSS.
Leandro Contrera informó que la UTN FRT planea dejar de enseñar C en primer año y pasarse a Python. Germán Navarro argumentó que el lenguaje no es lo más determinante; lo importante son los contenidos (algoritmos, estructuras de datos). Marcelo Nuñez discrepó fuerte: prefería mantener C++ o en su defecto aprender Rust. Su argumento fue que arrancar con un lenguaje de bajo nivel obliga al estudiante a pensar como la computadora, entender que la memoria no es infinita y que se puede romper algo. Jeremías Moreno Ivanoff bancó la postura: con C++ aprendés a construir las soluciones, no solo a usar las que ya existen. Marcelo usó la analogía 'es como aprender a manejar en manual antes de pasar al automático'.
Facundo García Martoni probó MCP (Model Context Protocol) por primera vez y reaccionó con euforia. Describió el flujo: hizo cambios en Cursor, le pidió al agente que creara el ticket correspondiente en Linear usando el MCP de Linear (sin salir del chat de Cursor), y luego creó la Pull Request. Lo que antes requería moverse entre tres aplicaciones distintas lo hizo en una sola, con un solo prompt. Agustín Sánchez mencionó que el MCP de Stripe parece copado (crea productos, configura webhooks en minutos), que el de Supabase sirve para MVPs rápidos, y que Vercel también sacó el suyo. Iñaki Fernando Lozano mencionó que usó uno de browser devtools y los de MercadoPago.
Facundo García Martoni hizo un resumen de la conferencia de GPT-5: cambios de colores de chats, el modelo de voz mejoró, se aflojan los guardrails, el creador de Cursor fue invitado a hablar, viene finetuneado para frontend. Facundo fue escéptico: 'el core es igual'. Iñaki Fernando Lozano hizo una review más detallada: es aproximadamente un 40% más barato que Sonnet, hace más caso a las instrucciones, no repite innecesariamente, errorea menos en tool calls. Destacó el mejor performance con contexto largo. Sin embargo, tras una semana de uso intensivo, Facundo García Martoni siguió prefiriendo Claude Sonnet 4. Para la vida diaria apostaba a Gemini, especialmente por Deep Research y la calidad de generación de imágenes/video de Gemini 2.5 Pro.
Facundo García Martoni dijo que Cursor lo estaba frustrando por un bug donde no logra salir de las consolas que instancia. Preguntó alternativas. Ariel Basabe y Exequiel De Freitas dijeron estar probando Windsurf con buenos resultados. Ariel mencionó que DeepSeek sacó un plugin para VS Code gratis. Diego compartió una comparativa de editores. Facundo mencionó también Trae (muy usado en Asia) y Kiro (propuesta de Amazon). Sobre Claude Code, dijo que la comunidad lo considera 'el peak' pero siente que lo haría más lento por ser terminal. Marcelo preguntó sobre Claude Code y la comunidad lo describió como 'similar a Cursor pero por terminal, más caro por token que GPT-5'.
Facundo García Martoni compartió un tip práctico para usuarios de Cursor: los comandos que generan 'pagers' (como less, more, o git diff que usa less internamente) rompen las terminales que Cursor instancia, porque el agente queda atrapado en la interfaz interactiva del pager y no puede salir ni leer el output. La solución es siempre corregir esos comandos agregando --no-pager (para git) o redirigiendo a | cat. Germán Navarro explicó el concepto para los que no lo conocían. Marcelo Nuñez aclaró que él no deja que Cursor ejecute comandos por este tipo de razones. Facundo también recomendó crear una regla en Cursor para que genere un unit/integration test por cada feature.
Nacho Tello recibió una propuesta para desarrollar una app web con geolocalización de bares, sistema de usuarios, PostGIS, soporte para 10.000 usuarios concurrentes como MVP y carga menor a 2 segundos en el 90% de los requests. Preguntó cómo presupuestarlo y con cuánta gente encararlo. Matias Gutierrez recomendó empezar por el core (geolocalización y visualización de bares). Marcelo Nuñez advirtió que el documento de requerimientos puede funcionar como evidencia legal. Germán Navarro recomendó descomponer el documento en features individuales para estimar cada una por separado. Agustín Sánchez explicó la metodología: estimar horas totales, multiplicar por costo/hora, agregar buffer de riesgo del 20%, y hacer primero una estimación 'ballpark' para ver si el cliente está dispuesto a pagar antes de invertir tiempo en un refinamiento detallado.
Facundo Padilla comentó que lo pusieron como early adopter de Devin en su laburo. Describió que el agente hace varias cosas simultáneamente: documenta, crea branches, codea, y detecta cuándo una tarea es demasiado compleja (mostrando un indicador de 'salud' de la tarea). Cuando detecta complejidad excesiva, sugiere dividirla en subtareas más manejables. Facundo fue positivo con la experiencia inicial.
Carlos Spagnolo compartió una web que construyó para probar las nuevas funcionalidades de IA integradas en Google Chrome a partir de la versión 138, que incluyen Gemini Nano ejecutándose localmente en el navegador de forma privada (sin peticiones a APIs externas). Las funcionalidades disponibles son: Traductor, Detector de idioma y Resumidor de textos. La demo está en chrome-ai-flame.vercel.app y el repo en github.com/SpagnoloCarlos/chrome-ai. Facundo García Martoni preguntó si funciona offline y Carlos confirmó que sí. Agustín felicitó la UI y Carlos reveló que usó shadcn y que la idea inicial se la tiró v0 y luego la acomodó.
Se viralizó una captura donde un usuario de Cursor gastó una fortuna usando el modelo en modo MAX por hacer un reemplazo que podría haberse hecho con sed. Facundo García Martoni aclaró que era totalmente posible si se usaba MAX mode con Opus de manera ineficiente. Iñaki Fernando Lozano reveló que Cursor había prometido uso 'sin límite' para el plan Pro, pero que el 'no limit' aplicaba solo al modo 'auto model', no al modo MAX con Sonnet 4. Cursor publicó un tweet disculpándose y ofreciendo refunds. El consenso fue que el plan Pro del Auto Mode es seguro (aprox. 500 requests/mes), pero activar usage-based pricing y usar MAX con modelos pesados es caro.
Iñaki Fernando Lozano compartió varias prácticas avanzadas de Cursor: setear un límite de gasto mensual, poner el SQL schema de las tablas como contexto, y aprovechar la feature de prompt queue (poner varios prompts en cola y alejarse mientras trabaja). Mencionó que usa la app Whispr en MacBook para dictar prompts por voz. Facundo García Martoni discrepó con el dictado por voz: argumentó que escribir permite pensar más despacio, volver atrás e iterar el prompt. Marcelo Nuñez, que usa Cursor principalmente en modo Auto, preguntó cómo aprender a usarlo mejor. Iñaki le recomendó 'entregarse a las vibes'. Facundo también compartió su idea de integrar las mejores features de Cursor en Neovim.
Exequiel De Freitas comentó que Vercel 'compró' Nuxt. Facundo Padilla aclaró que en realidad Vercel les dio financiamiento para que el equipo de Nuxt pueda dedicarse a la integración, igual que hicieron con otros proyectos. Esto derivó en una discusión sobre los logros argentinos en el mundo del software: Auth0, Vercel, Mongoose (creado por Guillermo Rauch), Muun Wallet, Godot y Aseprite. Germán Navarro confirmó que Rauch creó Mongoose e incluso Socket.IO, lo cual fue celebrado con mucho orgullo.
Facundo García Martoni compartió que le llegó un programador de BIOS CH341A con pinza SOIC8 conseguido en Mercado Libre. Lo usó primero para desbloquear la BIOS de una netbook del gobierno (Juana Manso) y luego para instalar Libreboot en una ThinkPad x220. Explicó en detalle el concepto: los fabricantes ponen limitaciones arbitrarias (la x220 tiene un límite real de 16GB de RAM pero Intel la limita a 8GB por BIOS) para forzar la compra de equipos nuevos. Libreboot elimina esas restricciones, desactiva backdoors y usa lo más moderno disponible para que la máquina arranque más rápido. Facundo brickeó la máquina sin querer pero pudo recuperarla. Roman compartió links para adaptadores de pantalla FHD/2K en la x220 desde AliExpress.
Agustín Sánchez abrió el debate preguntando qué opinaban de Django para backend. Facundo Padilla, que lo usó en su primer laburo, lo describió como 'hermoso': ORM fantástico, sistema de migraciones 'una locura', panel de admin 'un golazo', aunque lento comparado con alternativas de alta performance. Como contra señaló que es bastante lerdo si tenés que hacer algo ultra crítico en performance, aunque existían mil formas de hacerlo más performante. Marcelo Nuñez expresó preferencia por FastAPI. El punto de fricción principal fue Django REST Framework, que tanto Marcelo como Facundo describieron como 'un embole'. Facundo mencionó 'django-ninja' como alternativa. Para gestión de dependencias, Facundo y Marcelo recomendaron uv sobre Poetry: uv es más rápido (escrito en Rust), maneja versiones de Python internamente. Facundo García Martoni sumó que Ruff reemplaza a Pylance para linting.
Solano de Zuasnabar describió un sistema que analiza 400-500 CVs usando una base de datos vectorial e IA, con output en tabla con scores de candidatos. Originalmente hecho en Streamlit, el cliente ahora quería un frontend en Angular con un backend Python real. Marcelo Nuñez propuso una arquitectura con FastAPI dividida en cuatro módulos: routes (rutas + estructura de requests/responses), service (operaciones de negocio), model (objetos o dataclasses) y db (lógica de base de datos). Para el stack sugirió FastAPI (genera documentación OpenAPI automáticamente), SQLAlchemy y PostgreSQL. Facundo Padilla recomendó la misma dirección y destacó que FastAPI 'lo hacés en dos patadas'.
Ariel Basabe compartió una MacBook con procesador i5 que vio anunciada. Agustín Sánchez aclaró de inmediato que no recomendaba comprar ninguna Mac con Intel porque son 'muy lerdas, incluso las i7 con decenas de RAM'. Recomendó las MacBook con procesadores Apple (M1, M2 en adelante). Juan Arismendi apuntó que para desarrollo mobile con Android Studio se pueden quedar cortas con poca RAM. Agustín indicó que con 8GB funciona aunque se traba un poco, y que lo ideal es 16GB. También destacó que una MacBook permite desarrollar apps de iOS y Android, algo imposible en Windows. Ariel preguntó si existen soluciones cloud para compilar iOS (Codemagic, App Circle, Bitrise, GitHub Actions con runners macOS, MacStadium), y Felipe Rocha acotó que los runners macOS de GitHub Actions son muy caros.
Facundo García Martoni compartió una función bash que armó para ver los cambios netos de la rama actual, diseñada para funcionar correctamente incluso después de hacer rebase a master. La función excluye archivos .lock por defecto. Facundo explicó que el uso principal que le da, además del code review, es generar contexto crudo y preciso para LLMs dentro de Cursor, lo que le permite avanzar mucho más rápido haciendo 'AI Driven Development'. Compartió también un ejemplo de cómo lo usó exitosamente en Cursor para alimentar a Claude con contexto preciso del diff.
Roman preguntó si alguien le interesaba el tema de teclados mecánicos. Facundo García Martoni se declaró fanático y mencionó que acababa de recibir un kit de lubricación; dijo que muere por un HHKB con switches Topre o un IBM Model M. Roman mostró su Corne v4 (teclado ergonómico dividido, 4 layers) y su preferido: el Lofree flow84. Germán Navarro mencionó que usa un Keychron 75% desde hace años. Al día siguiente Facundo mostró el proceso de modding de su Corsair K100: Case Foam con goma EVA, Tape Mod con cinta de papel, y lubricado de switches con Krytox 205g0 y estabilizadores con XHT BDZ. Recomendó cytinfo.com.ar para comprar lubricantes en Argentina.
Agustín Sánchez compartió una lista de 10 cursos gratuitos de IA publicados por Google: Introducción a la IA Generativa, LLMs, IA Responsable, Generative AI con LLMs, Generación de Imágenes, Arquitectura Encoder-Decoder, Mecanismo de Atención, Modelos Transformer y BERT, Creación de modelos de Image Captioning, e Introducción a Vertex AI Studio. Todos con links directos de Google. El mensaje fue bien recibido por la comunidad como recurso de formación sin costo.
Leandro Contrera compartió neetcode.io/courses preguntando si alguien la conocía. Agustín Sánchez respondió que no la conocía pero que tenía muy buena pinta. Facundo Padilla también la revisó y la encontró interesante. Agustín comentó que el recurso lo inspiró a crear una issue en el repositorio del website de PCN para agregar una sección similar de recursos de aprendizaje. El hilo fue breve pero dejó una acción concreta sobre el producto de la comunidad.
Facundo García Martoni preguntó dónde conseguir una ThinkPad x230 y alguien del grupo preguntó por qué ese modelo es tan codiciado. Juan Arismendi explicó que duran muchísimo, están muy bien construidas y son fáciles de reparar, ya que fueron diseñadas pensando en los equipos de servicio técnico de empresas. Destacó que casi todo viene a mano para quien tenga que cambiar alguna parte. Varios miembros coincidieron con el análisis y el hilo dejó en claro que las ThinkPad tienen un culto particular dentro de la comunidad por su reparabilidad y durabilidad en entornos corporativos.
Facundo García Martoni compartió el repositorio github.com/dandavison/delta, describiendo el proyecto como un comando que le da 'superpoderes' a git diff. Destacó que el diff se ve clarísimo y con colores, muy similar al de Cursor o VS Code, y que lo encontró mientras intentaba migrar su flujo de trabajo a la terminal. Marcelo Nuñez reaccionó con entusiasmo, dijo que vive en la terminal y que lo iba a usar. Marcelo además compartió un video de Neovim para los que quisieran ir más a fondo. Facundo aclaró que había probado Neovim meses atrás sin poder acostumbrarse, pero que ahora se sentía obligado a intentarlo de nuevo.
Exequiel De Freitas anunció que eligió 'no ser feliz con Next' y se pasó a SvelteKit para un proyecto de prueba. Marcelo Nuñez compartió el artículo de Northflank sobre por qué abandonaron Next.js. Agustín Sánchez lo leyó completo y planteó que le faltaba credibilidad porque no mostraban el código que tenían en Next.js; sospechó que no lo estaban usando bien. Marcelo explicó que la empresa se quejaba principalmente de la personalización del SSR y los problemas con SEO a gran escala, y que terminaron construyendo su propio framework. El takeaway principal que rescató Marcelo fue 'no enamorarse de un framework' y animarse a entender cómo funcionan por dentro. Exequiel citó a Goncy y sus proyectos integrales en Next como ejemplo de que el problema suele ser no saber usar bien el framework.
Facundo García Martoni quería llevar su manejo de la terminal más allá de los comandos básicos y preguntó sobre OverTheWire y recursos para aprender comandos avanzados como awk, sed y grep. Victor Figueredo, referente del grupo en seguridad, avaló con entusiasmo OverTheWire: es una plataforma de wargames que obliga al usuario a usar la terminal para avanzar de nivel, lo que lo hace mucho más efectivo que leer un manual. Marcelo Nuñez recomendó especialmente grep y cut por ser los más útiles en el día a día, y desaconsejó awk por ser poco usado en la práctica. Matias Gutierrez y Marcelo coincidieron en que la mejor forma de aprender es restringirse de usar herramientas gráficas y resolver todo desde la terminal.
Germán Navarro compartió un video sobre la herramienta de containers nativa que Apple sacó para Mac, que reemplazaría Docker Desktop, aunque todavía sin soporte para Compose. Facundo Padilla la comparó con Linux Containers. La reacción general fue de cansancio ante la tendencia de Apple de inventar sus propias versiones de herramientas existentes. También se mencionó OrbStack como una alternativa liviana a Docker Desktop para Mac. El grupo no vio razón urgente para migrar mientras Docker Desktop siga funcionando y Compose no sea soportado en la alternativa de Apple.
El criterio de 'experiencia demostrable' en las ofertas de trabajo disparó un debate sobre qué significa eso en la práctica. Marcelo Nuñez señaló que ese criterio deja afuera a quienes construyeron sistemas serios en startups sin blanquear, o a emprendedores con apps propias. Agustín Sánchez respondió que lo más importante es poder hablar con convicción y sin dejar dudas, independientemente del historial formal. Mateo Lohezic recomendó que los freelancers se pongan un nombre de marca unipersonal en el CV para no decir simplemente 'freelance', y que vendan la variedad de clientes y el trato con el cliente como valor diferencial. Germán Navarro contó que en un proceso de selección le quisieron bajar el precio porque su experiencia era en startups y no era corporativa, y que encima un entrevistador le hizo chistes porque tenía el CV en inglés, diciéndole que 'tenía que hacer patria'. El grupo coincidió en que ese tipo de entrevistadores hablan más de la cultura de esa empresa que de la calidad del candidato.
Un integrante del grupo preguntó cómo desplegar un backend en Java con base de datos PostgreSQL en un VPS, sin idea de por dónde arrancar. Germán Navarro explicó que sin Docker habría que instalar manualmente JDK, Maven, Postgres e inicializar la base desde la CLI. Con Docker el proceso es mucho más limpio: un Dockerfile declara todos los pasos para resolver dependencias en el container, y las imágenes oficiales de Postgres permiten configurar todo con variables de entorno. Facundo Padilla explicó el concepto más a fondo: Docker descarga imágenes y crea un pipeline con reglas de networking aisladas para levantar el entorno limpio. Germán mencionó Kamal como herramienta de automatización de deployment que se usa en el repositorio de PCN (con GitHub Actions).
Un integrante preguntó si valía la pena aprender a programar y por dónde arrancar, sin saber nada del tema. Marcelo Nuñez respondió calurosamente recomendando empezar con Python (el más fácil de aprender) o TypeScript (permite hacer frontend y backend), aclarando que requería esfuerzo y dedicación. Facundo García Martoni sumó recursos concretos: FreeCodeCamp en español, los cursos de MiduDev, la app Brilliant y Boot.dev para aprender de forma lúdica, y el Curso de Fundamentos de Ingeniería de Software de Freddy Vega. Destacó que cuando uno se vuelve bueno aparece la plata, y que uno de los lujos del rubro es el trabajo remoto. Ariel Basabe compartió cuatro canales de YouTube en español que fueron sus mentores: Juan Diaz, pildorasinformaticas, Fernando Herrera y Código con Juan. Agregó que todo depende de cómo manejás la frustración cuando las cosas no salen de una.
Marcelo Nuñez buscó ayuda para un proyecto universitario en Blazor (C#), una tecnología que ninguno del grupo manejaba bien. Luciano Gallardini señaló que 'ni Microsoft usa Blazor', y el debate derivó en si C# superaba a Java en performance. Luciano argumentó que versiones recientes de .NET Core le ganaban a Java e incluso a Go en algunos benchmarks. Marcelo defendió Java con su JVM de alta performance y propuso compararlo con Java + GraalVM. La discusión giró en torno a que el lenguaje ganador dependía del sistema operativo (Linux vs Windows para server), y que .NET Core corriendo en Linux era la condición justa para el benchmark. El consenso fue que ambos lenguajes modernizaron mucho sus runtimes, y que para servidores nadie usa Windows de todas formas.
Firebase, npm, Claude, OpenAI y decenas de otras plataformas se cayeron simultáneamente el 12 de junio por la tarde. Julián Vélez compartió una lista de más de 40 servicios afectados incluyendo AWS, Anthropic, Google, Discord, Spotify y Shopify. Facundo García Martoni indicó que el origen parecía ser Google Auth. Franco confirmó al día siguiente que fue una caída de Google Cloud. Agustín Sánchez reflexionó que esto ejemplificaba lo que había advertido antes: la industria depende de un árbol de terceros que dependen de otros terceros, incluyendo librerías mantenidas por una sola persona por amor al arte. Marcelo Nuñez trajo el precedente de Log4J como ejemplo de impacto sistémico aún más severo, capaz de tumbar bolsas.
Agustín Sánchez preguntó al grupo qué librería recomendaban para generar PDFs con tablas en JavaScript. Matias Gutierrez recomendó HTML2PDF: la herramienta toma HTML con sus estilos tal cual y lo convierte en PDF, haciendo esencialmente un screenshot del contenido. Matias mostró un ejemplo de factura que había generado así. La solución de HTML2PDF fue bien recibida por su simplicidad: no requiere aprender una API específica de PDF sino simplemente escribir HTML y CSS normales.
Gonzalo Morales comentó que había probado Google AI Studio por primera vez y le dejó una buena impresión. Explicó que la plataforma sirve para experimentar con los modelos de Google y que ofrecía 1.000.000 tokens gratuitos con Gemini 2.5 Pro Preview. Compartió el link directo (aistudio.google.com) y reconoció que su uso principal era ahorrar tiempo en tareas manuales, sin ser experto en IA. Facundo Padilla probó la plataforma en el momento y la encontró algo lenta para responder. Gonzalo confirmó que sí era más lenta que Claude pero que al ser gratuita le resultaba suficiente y cómoda. Agustín Sánchez había compartido días antes que Gemini Advanced incluía 2TB de almacenamiento en Google Drive como beneficio, haciendo el plan muy atractivo para quienes necesitaban esa combinación.
Nacho Tello preguntó sobre las limitaciones de Prisma ORM mientras exploraba el repositorio del website de PCN. Exequiel De Freitas compartió su impresión de que Prisma va bien para proyectos pequeños a medianos pero puede complicar contextos más complejos. Agustín Sánchez explicó que cuando una query se complica mucho en Prisma se puede usar SQL directo, y que el problema principal del ORM es que a veces genera múltiples queries para devolver un resultado, mientras que Drizzle construye una sola query SQL por detrás y por eso es más rápido. Sin embargo, Agustín prefiere el código de Prisma por ser más estético, fácil de leer y mantener. Concluyó que no hay un ORM que sea la posta en el ecosistema TypeScript: cada uno tiene sus pros y contras, y por ahora Prisma es el que más le gusta a pesar de que a veces lo hace renegar.
Facundo Padilla compartió datos del informe de CESSI/OPSSI sobre el sector IT argentino: el 53% de las empresas actualiza sueldos trimestralmente, la mediana proyectada para el primer trimestre de 2025 era de $2.656.800, el 88% de las empresas trabaja en forma remota (39% total y 49% híbrido), y la rotación cayó al 20% en 2024. Ariel Basabe expresó escepticismo sobre los números, argumentando que los salarios reales que veía en el mercado de Buenos Aires eran mucho más bajos para juniors. Para ilustrarlo compartió una oferta real de una empresa en Belgrano buscando un analista .NET con 3 años de experiencia pagando solo $654.645 bruto mensuales, presencial. Alejo Boga señaló que el stack de esa empresa (tecnología vieja) explicaba los salarios bajos. El grupo coincidió en que era una oferta abusiva.
Facundo García Martoni estaba leyendo el libro Pro Git y fue compartiendo aprendizajes con el grupo. Explicó que el área de staging no es un estado binario: se stagean los cambios hasta el momento del git add, no el archivo completo, por lo que podés stagear, seguir modificando el archivo y commitear solo lo que habías stageado originalmente. También habló de git worktrees, que permiten tener múltiples ramas del repo abiertas en carpetas separadas simultáneamente, eliminando la necesidad de git stash cuando trabajás en varios tickets a la vez. Compartió el comando git switch como reemplazo moderno de git checkout. Discutió la double-dot notation para filtrar commits entre dos referencias, algo que Germán Navarro ya usaba en un monorepo con Turborepo para buildear solo los servicios con cambios. Facundo también compartió su flujo modernizado: git switch main, pull, git switch --create feature, git add -A, commit, fetch, git rebase origin/main, push.
Facundo García Martoni anunció que Warp terminal ya estaba disponible para Windows y procedió a instalarlo y probarlo ese mismo día. Destacó el autocompletado inteligente de comandos como una de las mejores features. También mostró entusiasmado capacidades como pair programming directamente en la terminal y bloques de ejecución al estilo de Jupyter Notebooks pero para bash. Exequiel De Freitas confirmó que ya llevaba disponible para Windows un par de meses y que la había probado, calificándola de 'mortal'. Facundo resolvió un problema real del laburo ese mismo día usando Warp, validando la herramienta en producción. La conversación quedó en que Warp era un emulador de terminal como Alacritty, Kitty o iTerm2, pero con IA integrada y una interfaz visualmente muy superior.
Nacho Tello preguntó cómo practicar el speaking en inglés, especialmente para entornos laborales IT. Facundo García Martoni compartió su método, que describió como contraintuitivo: no hace falta empezar hablando sino acumulando input (inmersión). Recomendó poner el teléfono en inglés, ver series con subtítulos en inglés, escuchar podcasts, leer libros y consumir creadores de contenido en inglés exclusivamente durante un tiempo. Aclaró que él nunca hizo ningún programa académico formal y laburaba para gente de EE.UU. Facundo Padilla recomendó free4talk.com como plataforma gratuita para practicar conversación con hablantes de múltiples idiomas. Germán Navarro destacó que la exposición al idioma ayuda mucho pero que llega un punto donde sin practicar el speaking no se avanza, y que en entrevistas le costó al principio. También resaltó que hay que perderle el miedo a pronunciar mal: los no nativos siempre tienen acento y lo importante es hacerse entender. Iñaki Fernando Lozano compartió que arrancar con subtítulos en inglés y googlear palabras desconocidas le funcionó bien, junto con Twitter y artículos técnicos.
Carlos Spagnolo compartió un mensaje de LinkedIn de Outlier ofreciéndole un rol remoto/freelance para entrenar modelos de IA. Juan Arismendi contó que había trabajado con ellos cuando se llamaban Remotasks y que son la misma empresa. Explicó en detalle cómo funcionaba: primero una entrevista con live coding simple, luego asignaban un sueldo por hora (en su caso $11/hora) y acceso a la plataforma. Las tareas incluían comparar dos respuestas de IA y elegir la mejor con justificación, inventar prompts de dificultad media, o crear respuestas modelo para entrenar la IA de clientes como Nvidia, OpenAI o Meta. Juan contó que en un día con incentivo especial llegó a hacer $300-400 dólares. El trabajo era muy repetitivo y podían bajarte el sueldo o dejar de mandarte tareas sin aviso. La discusión concluyó que sirve como changa flexible cuando no hay otro trabajo, pero el pago depende mucho de con qué proyecto te asignen.
Marcelo Nuñez compartió una implementación de Maybe monad en Python con las clases Just y Nothing. Facundo Gelatti, referente en programación funcional, dio feedback técnico preciso: señaló que sin flat_map la implementación era un functor, no una mónada en sentido estricto. Cuando Marcelo actualizó el código agregando flat_map, Facundo lo felicitó y señaló un detalle sutil: el método map flaterizaba los Just(None), lo que rompía el contrato de functor (la ley de composición x.map(g o f) == x.map(f).map(g) no se cumplía). Marcelo debatió si convenía tirar una excepción en el constructor al recibir None para forzar a los usuarios a usar Nothing explícitamente. Facundo Gelatti argumentó que la excepción era más honesta porque 'te castiga' y obliga a corregir el None de origen. Marcelo confirmó que lo iba a publicar como paquete en PyPI y que planeaba armar una charla sobre mónadas para PCN.
Juan Arismendi planteó un requerimiento de un cliente: una tienda estilo Steam donde al hacer click en 'Jugar' el usuario es redirigido al juego hosteado por separado sin tener que loguearse de nuevo, pero con control de suscripciones y sin permitir acceso simultáneo de múltiples usuarios con la misma cuenta. El dilema era cómo hacer la redirección segura: si se manda un token por parámetro en la URL, cualquiera que lo capture puede acceder. La solución que Juan elaboró durante la conversación fue generar un token JWT de un solo uso con expiración corta desde la plataforma, redireccionar al juego como juego.com/auth/:token, y dejar un endpoint en el backend de suscripciones donde los juegos verifiquen ese token. Facundo Padilla sugirió agregar el token a una blacklist apenas se use, para que no pueda reutilizarse. Para el cleanup de la blacklist, Facundo Padilla sugirió un cronjob que elimine periódicamente los tokens vencidos. Juan cerró agradecido con un norte claro para encarar la implementación con NestJS + PostgreSQL.
Matias Gutierrez preguntó qué herramientas usaban para organizarse y gestionar proyectos, ya que no le encontraba la vuelta a Notion. Juan Arismendi recomendó Trello y lo describió en detalle: tableros por proyecto, fechas límite, checklists dentro de cada tarea, integración con Google Calendar. Marcelo Nuñez mencionó Linear como su favorita del laburo, con 250 tickets gratuitos. Facundo García Martoni hizo una defensa encendida de Obsidian sobre Notion: es local (sin latencia de servidor), los archivos son .md propios del usuario (no quedan rehenes de ninguna empresa), totalmente customizable con plugins de la comunidad como Kanbans, sincronización gratuita vía Remotely Save con OneDrive, colaboración en tiempo real con plugin gratuito, y bloques de código con highlight para múltiples lenguajes incluyendo GraphQL. Facundo Padilla presentó el combo Notion + Notion Calendar como su flujo actual. Leandro Contrera recomendó Clockify para time tracking personal del estudio: permite saber cuánto tiempo dedicás por materia y comparar semanas. Ariel Basabe mencionó Pumble como clon gratuito de Slack.
Facundo García Martoni anunció un evento presencial para el jueves 5 de junio en la UTN Facultad Regional Tucumán con dos charlas: 'Buscando el diseño perfecto' a cargo de Mauricio Sánchez (ingeniero senior en PedidosYa) e 'Impulsá tu carrera con PCN' a cargo de Agustín Sánchez. El jueves 5 el evento se realizó con fotos y gran recepción. Agustín anunció que el website de PCN (programaconnosotros.com) quedó oficialmente live esa noche: con sistema de cuentas, sección de consejos, likes y apertura para colaborar en el repositorio. Leandro Contrera expresó su agradecimiento especial a Mauricio Sánchez por responder todas sus preguntas durante el evento. Agustín invitó a los nuevos que se sumaron a presentarse.
Facundo García Martoni compartió que WSL había evolucionado tanto que permite levantar aplicaciones con GUI, haciendo el dual boot casi innecesario. Germán Navarro respondió que la única razón real para tener Windows hoy es para jugar. Marcelo Nuñez contó que Docker se le rompió en el trabajo cuando se actualizó Windows 11 y WSL al mismo tiempo, perdió un día entero reinstalando, y eso lo hizo pasarse a Mac. Facundo García Martoni explicó que intentó instalar Arch Linux durante un mes y terminó sabiendo el proceso de instalación de memoria, pero que los drivers de Nvidia en Linux eran un desastre y la suspensión se rompía. Matias Gutierrez contó que usa dual boot: Windows para jugar y Linux Mint para trabajar. Exequiel De Freitas consideró ir a Ubuntu como opción más sencilla. Germán Navarro recomendó Manjaro para los que quieren Arch sin el dolor. El consenso final fue que Mac con chips M ofrece las ventajas de Unix con soporte corporativo y batería incomparable, pero Linux sigue siendo la opción más configurable y Docker corre nativo sin fricciones.
Jeremías preguntó qué stack de backend usar para un proyecto de tres personas: él haría el back y sus dos compañeros el front con React y React Bootstrap. El sistema necesitaba un dashboard de administración, login, y pagos con Mercado Pago o PayPal. Jeremias tenía algo de experiencia con PHP y lo consideraba, pero tenía dudas sobre si PHP era suficiente para pagos y sesiones seguras. Iñaki Fernando Lozano recomendó PHP con Codeigniter por su curva de aprendizaje tranquila y autenticación incluida. Juan Farber dijo que cualquier lenguaje conocido sirve para hacer algo seguro, y sugirió que si los compañeros usaban JS en el front quizás conviniera hacer el back también en JS. Facundo García Martoni recomendó Django, destacando que el admin dashboard es la feature estrella del framework. Marcelo Nuñez dio un resumen completo: JS/TS tiene más demanda comercial y soporte, PHP es leyenda con mucho soporte pero menos demanda actual, Python es rápido de aprender, Java tiene la mejor performance pero es overkill para este caso; recomendó TS o Python.
Marcelo Nuñez preguntó con humildad la diferencia entre merge y rebase en Git. Ariel Basabe dio una explicación completa: el rebase reescribe el historial de commits moviendo la secuencia a una nueva base, obteniendo un historial más lineal y limpio, a diferencia del merge que crea un nuevo commit de fusión visible. Explicó que el rebase interactivo (git rebase --interactive) permite editar, combinar (squash) o eliminar commits, y que su principal precaución es no hacer rebase de commits ya pusheados a un repositorio público porque reescribe la historia y complica la colaboración. Diego destacó que el rebase puede generar conflictos que requieren resolución manual. Ariel compartió también un video de YouTube explicativo. Días después, Facundo García Martoni compartió su flujo modernizado de Git: usar git switch en lugar de checkout, git rebase origin/main en lugar de pull para mantener historia lineal, y un ejemplo de su laburo donde usó rebase entre ramas dependientes para no bloquear trabajo mientras esperaba revisión de una PR.
Facundo García Martoni anunció con emoción que cerró un contrato como Senior Full-Stack Engineer para el proyecto Exec de la mano de Bowery, con inicio el lunes siguiente. Agradeció especialmente a Agustín Sánchez por la oportunidad de estar en el grupo, por la ayuda con el tema de system design que habían trabajado juntos, y por haber publicado la oferta laboral. También agradeció a Marcelo Nuñez por la recomendación que le hizo. La comunidad celebró con mensajes de felicitaciones de Agustín, Diego, Marcelo, Matias Gutierrez, Ariel Basabe, Mateo Lohezic, Germán Navarro y otros. Fue un momento emotivo que ejemplificó el valor concreto de la comunidad PCN para el desarrollo profesional de sus integrantes.
Mauricio Chaile compartió NotebookLM de Google como una herramienta para hacer resúmenes e interactuar con documentos usando IA. Facundo García Martoni dijo que ya lo usaba y que su feature estrella era la generación de podcasts, y que recientemente había añadido soporte en español, lo que abría posibilidades enormes para estudiantes que no sabían inglés. Mauricio probó la generación de podcast con un libro de patrones y compartió el link de audio. Agustín Sánchez preguntó si generaba el podcast con voz y todo para ayudar a estudiar, Facundo y Mauricio confirmaron que sí, y que también podía generar mapas conceptuales. Mauricio señaló que el soporte en español todavía estaba limitado al momento. La herramienta fue especialmente recomendada para compartirla con conocidos fuera del mundo IT que estuvieran estudiando, como forma de revolucionar su manera de repasar contenido.
Germán Navarro preguntó recomendaciones de auriculares inalámbricos con buen micrófono para reuniones, ya que tenía unos Skullcandy con micro de baja calidad. Facundo García Martoni recomendó fervientemente los Sony WH-1000XM4. Iñaki Fernando Lozano contó que le llegaron unos Soundcore con ANC que le gustaron mucho, aunque los Samsung Galaxy Buds 2 Pro que tenía tenían mejor cancelación de ruido. Ariel Basabe recomendó Bose o Sennheiser. Agustín Sánchez recomendó los AirPods Pro como la opción más cómoda que tuvo, cargándolos solo cada 10 días. Sin embargo, Agustín advirtió que sus XM4 tuvieron problemas de Bluetooth con la Mac M1: al levantar uno del oído y volvérselo a poner se cortaba la conexión y había que salir y volver a entrar a las llamadas. Facundo explicó que ese era un bug ya conocido, documentado en Reddit, causado por una incompatibilidad entre el rango de frecuencia que esperaba la Mac y los Sony. Germán encontró los XM4 en TiendaMia a menos de $400 USD.
Mateo Lohezic preguntó por cursos de N8N que no fueran marketing vacío sobre 'hacerse millonario sin código'. Agustín Sánchez compartió un video de YouTube y Ariel Basabe recomendó un curso de Udemy ('Curso N8N: Crea agentes de IA sin programar') con link gratuito de Telegram. La suscripción de N8N cuesta $20/mes e incluye 5 workflows activos y 2500 ejecuciones, con lo que se puede atender a un cliente pagante. La API de OpenAI funciona por créditos (aprox $5/mes para un negocio chico), haciendo el costo total de un agente de IA rondear los $50 USD mensuales o menos. Matias Gutierrez mencionó que él usaba ManyChat con un cliente inmobiliario por $15/mes: asignación automática de chats según disponibilidad de agentes inmobiliarios, detección de palabras clave y derivación. Mateo criticó que ManyChat era solo un menú de opciones predefinidas y no un agente con IA real. Se discutieron casos de uso como bots de atención para gimnasios con múltiples sucursales, filtrado de leads y creación automática de entradas en CRMs.
Facundo García Martoni compartió una propuesta de system design y la comunidad debatió qué hace que un sistema sea monolítico o distribuido. Facundo explicó que Inertia.js permitía tener front y back en la misma codebase sin usar una API REST explícita, algo que Agustín Sánchez clarificó que Next.js también hacía internamente con sus server actions, aunque por detrás igual generaba endpoints REST. Alejo Boga sumó que un monolito puede perfectamente exponer APIs sin dejar de ser monolítico, y que la arquitectura distribuida implica separar servicios independientes. Agustín propuso sumarle Docker y Kubernetes para escalar en lugar de levantar VMs manualmente, y Facundo lo bancó. Benjamín Cortés planteó que para él un sistema distribuido requería filas y workers, lo que generó un pequeño debate sobre si la asincronía era condición necesaria. Agustín citó a ChatGPT para zanjar: si todo corre en un proceso es monolito, si son dos procesos separados ya es distribuido, y cualquier API externa suma al criterio de distribución.
Un integrante del grupo preguntó cómo mandar imágenes desde el front a la base de datos sin usar servicios cloud, manifestando que Base64 le parecía horrible. Marcelo Nuñez confirmó que guardar en base64 era posible pero no recomendable, y que técnicamente lo que se guardaba eran bits codificados. Agustín Sánchez aclaró que Base64 en sí no tiene límite de tamaño: el problema real es el payload máximo de una request HTTP, que varía según la configuración del servidor. Iñaki Fernando Lozano puntualizó que el límite lo pone el servidor o el navegador, no el protocolo en sí, y que rondaba los 20kb dependiendo del caso. La solución recomendada por Iñaki fue guardar el archivo en el sistema de archivos del backend y almacenar solo el path en la base de datos, con posibilidad de aplicar optimización de imágenes como la que ofrece Next.js. Agustín también mencionó que se podían usar CDNs propios o servicios de object storage como alternativa escalable.
Un desarrollador mobile contó que un amigo con una empresa de eventos le pidió un programa para Windows que gestionara turnos de empleadas, sumara montos cobrados por turno y permitiera al administrador ver los totales diarios. El sistema existente estaba hecho en WinForms con C#. El desarrollador nunca había trabajado con escritorio y preguntó qué stack usar. Iñaki Fernando Lozano recomendó Electron para quienes vienen de JS, ya que permite usar frameworks web y tiene acceso a Node para funcionalidades nativas: Visual Studio Code y Postman están hechos con Electron. Juan Arismendi confirmó que Electron andaba bien pero recomendó usar React solo en lugar de Next.js dentro de Electron, porque las rutas dinámicas de Next dan problemas. Juan también mencionó Tauri como alternativa similar pero con la parte de aplicación escrita en Rust. Agustín Sánchez recomendó entender bien qué quería el cliente antes de elegir tecnología, estimar horas de desarrollo y agregar un 20% de buffer de riesgo al presupuesto. El desarrollador se inclinó por Electron o WinForms, lo que tuviera menor curva de aprendizaje dado que ya usaba JS y algo de C#.
Luciano Gallardini comentó que Microsoft había hecho open source la extensión de Copilot para VS Code, con algo de ironía porque no pudieron hacerlo bien pagando empleados. Agustín Sánchez destacó una nueva feature de Copilot: podés asignarle directamente un issue del repo en GitHub y la IA lo desarrolla y crea la pull request sola. Agustín valoró la idea especialmente para features chicas, aunque aclaró que seguía prefiriendo Cursor. Juan Arismendi contó que Copilot tiene una capa gratuita con límite de completions y ediciones que él rara vez alcanzaba, haciéndolo muy atractivo para quienes no pagan. La discusión sobre si Cursor o Copilot era mejor terminó con un consenso de que la competencia entre ambos beneficia a los usuarios, y que cada uno seguía con lo que ya usaba.
Varios miembros del grupo compartieron fotos de sus setups de trabajo para desarrollo. Matías mostró su Arch Linux con Hyprland con una configuración actualizada. Otros compartieron setups con macOS con monitores externos, stands y teclados mecánicos. Se compararon las ventajas de tener monitor vertical (portrait mode) para leer código largo. Alguien mostró un setup minimalista con solo la laptop y elogios a la portabilidad. Facundo compartió su setup dual monitor. El hilo fue festivo y muchos miembros participaron con fotos o comentando las de otros.
e585309
El grupo tuvo una discusión profunda sobre el impacto de la IA en el empleo de desarrolladores. Algunos miembros recién empezando la carrera expresaron preocupación por si tenía sentido seguir aprendiendo a programar. Facundo y otros miembros más experimentados argumentaron que la IA era una herramienta que amplificaba capacidades, no que reemplazaba el pensamiento. Se debatió si los desarrolladores que sabían usar IA efectivamente reemplazarían a los que no. Alguien señaló la paradoja de que cada vez más las empresas querían desarrolladores que supieran usar IA, pero también que entendieran el código que la IA generaba. La conclusión mayoritaria fue que había que adaptarse y aprender a trabajar con IA como habilidad central.
9088623
Alguien compartió la noticia de que la UTN Tucumán estaba intentando patentar un framework de software desarrollado en el ámbito académico. El grupo reaccionó con críticas a la iniciativa. Facundo y otros argumentaron que el software académico debería ser open source por defecto, y que intentar patentarlo contradecía los valores de la comunidad científica y de los contribuyentes que financiaban la universidad pública. Se discutió el concepto de RIA (Red de Innovación Argentina) como contexto. Algunos pusieron en duda si la patente era viable legalmente dado que el software tenía antecedentes publicados. El hilo generó bastante debate sobre la relación entre universidad pública y propiedad intelectual.
26d7bf4
Un miembro compartió su experiencia en una entrevista de system design en una empresa que buscaba perfiles senior. Contó que le habían pedido diseñar un sistema de notificaciones escalable y que había fallado en considerar la idempotencia de los mensajes y el manejo de duplicados. El grupo analizó el problema juntos: cómo garantizar que una notificación se enviara exactamente una vez usando message queues como SQS con deduplication. Facundo mencionó el patrón de exactly-once delivery y sus limitaciones. Se discutió la diferencia entre at-least-once y at-most-once delivery. El miembro agradeció el análisis y varios aprendieron del hilo.
e8af579
Un miembro compartió que había empezado el curso de system design de LeetCode y preguntó si otros lo habían hecho. El grupo discutió el contenido del curso que cubría temas como consistent hashing, bases de datos distribuidas, caching con Redis y diseño de sistemas como URL shorteners y feeds de redes sociales. Facundo señaló que el system design era el área que más diferenciaba a ingenieros senior en entrevistas. Se comparó con otros recursos como Designing Data-Intensive Applications de Kleppmann, que el grupo consideraba la biblia del sistema distribuido. Alguien mencionó los videos de Gaurav Sen en YouTube como recurso gratuito de calidad.
5e3fbc2
El grupo discutió la noticia de que Jack Dorsey había anunciado recortes significativos en Block argumentando que la IA reemplazaría muchas de las funciones de los empleados. Varios miembros expresaron preocupación por la tendencia. Facundo argumentó que los recortes de empleados por IA en empresas como Block eran una decisión de management que mezclaba optimización real con narrativa para inversores. Se debatió si los desarrolladores que usaban IA eran 10x más productivos o si la calidad del output de IA requería igualmente tiempo humano para revisión. La discusión fue intensa y polarizada, con posiciones que iban desde el optimismo tecnológico hasta la preocupación por el mercado laboral.
6ff75f0
Alguien compartió el anuncio de Dia, el nuevo navegador de The Browser Company, los creadores de Arc. El grupo que había usado Arc reaccionó con curiosidad sobre el nuevo proyecto. Facundo explicó que los creadores de Arc habían decidido pivotear a un browser con IA integrada como concepto central, alejándose del diseño de espacios y sidebar de Arc. Se debatió si Dia sería un salto real en la experiencia del navegador o solo otro browser con IA encima. Alguien señaló que Arc había tenido problemas de rendimiento y bugs que nunca se resolvieron bien. El grupo acordó esperar a la versión pública para probarlo.
1365aa5
El grupo debatió qué navegador usar para desarrollo web. Firefox fue recomendado por sus herramientas de developer tools, especialmente el inspector de layout CSS que se consideraba superior al de Chrome. Zen Browser, un fork de Firefox con UI personalizada, fue mencionado como alternativa estética. Brave fue elogiado por el bloqueo de ads integrado y la privacidad, aunque algunos señalaban inconsistencias en la compatibilidad con sitios. Chrome fue defendido por ser el estándar de facto y representar mejor la experiencia de la mayoría de usuarios. Facundo mencionó que usaba Chrome para trabajo y Firefox como navegador de uso general por la privacidad.
24c1dd2
Un miembro con un proyecto heredado en WordPress preguntó si convenía rediseñar el sitio en WordPress o migrar a otra tecnología como Next.js con un CMS headless. El grupo debatió los costos y beneficios de cada opción. Facundo argumentó que si el cliente usaba WordPress activamente para crear contenido, migrar el CMS era un proyecto separado del rediseño visual y no siempre valía la pena. Otros señalaron que WordPress headless con un frontend moderno era una opción intermedia viable. Se discutió también el tiempo de migración de contenido y el costo de capacitar al cliente en un nuevo sistema. La conclusión fue que dependía mucho de si el dolor con WordPress era de performance, seguridad o de experiencia de edición.
962d140
Agustín preguntó por recomendaciones de mouse para usar con Mac. El debate se polarizó entre el Magic Mouse de Apple y el Logitech MX Master 3. Los defensores del Magic Mouse destacaban la integración con los gestos de macOS y la superficie multitouch. Los del MX Master señalaban la ergonomía superior para jornadas largas, la rueda de desplazamiento MagSpeed y los botones programables. Facundo confesó que había probado ambos y que el Magic Mouse era incómodo para uso intensivo a pesar de la buena integración con el sistema. Se recomendó también el Logitech MX Master 3S como la versión más silenciosa. La mayoría se inclinó por el MX Master para trabajo.
041c349
Alguien preguntó por recursos para aprender TypeScript de manera sistemática más allá de la documentación oficial. El grupo recomendó el repositorio type-challenges en GitHub como colección de ejercicios progresivos sobre el sistema de tipos. Se mencionó el curso de TypeScript de Matt Pocock como uno de los más actualizados. Facundo compartió que el error más común era usar TypeScript como si fuera JavaScript con anotaciones, sin aprovechar el sistema de tipos avanzado. Se recomendó también el handbook oficial y el playground de TypeScript para experimentar con tipos complejos en el browser sin configurar nada.
75bb5c5
Matías compartió fotos de su setup con Arch Linux y el compositor de ventanas Hyprland, que había configurado desde cero. El grupo quedó impresionado con la estética del escritorio personalizado con colores, fuentes y animaciones. Se discutió la curva de aprendizaje de Arch Linux y si valía la pena el tiempo de configuración versus usar una distro como Manjaro o Fedora que venían más listas. Matías argumentó que la instalación manual de Arch le había enseñado cómo funcionaba Linux internamente. Varios preguntaron por su configuración de Neovim y los dotfiles. Facundo comentó que Hyprland era bonito pero que prefería algo más estable para trabajo.
0899f0a
Un miembro que construía una app sin autenticación preguntó cómo trackear usuarios anónimos para analytics. El grupo discutió las opciones: generar un UUID en el primer uso y guardarlo en localStorage o AsyncStorage (React Native), usar el device ID que ofrecían plataformas como Expo, o implementar fingerprinting del browser. Facundo explicó que el UUID era la solución más simple y respetuosa de la privacidad, pero que se perdía cuando el usuario limpiaba el storage. Se mencionó la diferencia entre identificación para analytics versus para personalización. Alguien señaló que en iOS el acceso al device ID requería permiso explícito del usuario desde iOS 14.
573fd0e
El grupo tuvo una discusión extensa sobre las ventajas y desventajas de los lenguajes con tipado estático versus dinámico. Los defensores del tipado estático (TypeScript, Java, Go, Rust) argumentaron que los errores se capturaban en compilación, el refactoring era más seguro y el autocomplete era más preciso. Los que preferían dinámico (Python, JavaScript, Ruby) señalaban mayor velocidad de prototipado y código más conciso. Facundo trajo el punto de que TypeScript había probado que la comunidad JavaScript valoraba el tipado cuando estaba bien hecho. Se mencionó el gradual typing de Python con mypy como punto intermedio. La conclusión fue que para proyectos de equipo y largo plazo el tipado estático pagaba su overhead.
72fdb27
Un miembro preguntó por qué era imposible recuperar una contraseña hasheada con bcrypt si el algoritmo era conocido. El grupo explicó el concepto de función de hash unidireccional: el proceso era fácil en un sentido pero computacionalmente inviable en el otro. Facundo aclaró la diferencia entre hashing (unidireccional) y encriptación (bidireccional con clave). Se explicó por qué bcrypt era preferido sobre MD5 o SHA para contraseñas: el factor de costo (work factor) hacía que cada verificación tomara tiempo deliberadamente, lo que hacía impráctica la búsqueda por fuerza bruta. Se mencionó también el concepto de salt para evitar rainbow tables. La discusión fue didáctica y varios principiantes agradecieron la explicación.
f4c52d0
Un miembro que estaba desarrollando su primera app iOS preguntó cómo decidir el iOS mínimo a soportar. El grupo explicó que había que balancear el porcentaje de usuarios en cada versión (disponible en las estadísticas de Apple) contra las APIs disponibles. Facundo recomendó revisar los datos de adopción de iOS en el App Store Connect antes de tomar la decisión. Se comentó que la adopción de iOS era mucho más rápida que la de Android, con más del 90% de usuarios en la última o penúltima versión. Alguien mencionó que las apps de nicho podían permitirse targets más altos que las apps de consumo masivo. La recomendación fue apuntar a iOS 16 o 17 en proyectos nuevos.
46b0e48
Se reportó una caída de los servicios de Mercado Pago que afectaba a varias apps del grupo. Varios miembros bromearon sobre que Mercado Pago estaba construido sobre PHP, lo que generó un hilo de chistes sobre PHP como lenguaje. Algunos defendieron que PHP moderno (8.x con tipado) era un lenguaje perfectamente válido para producción y que el prejuicio era injusto. Facundo trajo el argumento de que Facebook, WordPress y muchos sistemas de alto tráfico corrían en PHP exitosamente. El debate derivó en la diferencia entre el estado actual de un lenguaje y su reputación heredada de versiones anteriores. El outage se resolvió en pocas horas.
88856d0
Alguien compartió que Bowery, una empresa del exterior, estaba buscando desarrolladores en Argentina. El grupo mostró interés y varios preguntaron sobre el stack, el salario y si era remoto o presencial. Los que tenían más información explicaron que era trabajo 100% remoto con pagos en dólares. Se discutió cómo aplicar y qué perfil buscaban. Facundo señaló la importancia de tener el perfil de LinkedIn en inglés y con proyectos bien documentados antes de aplicar. Alguien que había pasado por el proceso compartió cómo era el proceso de selección de la empresa.
65b185b1 participantes
Facundo Gelatti compartió sus reflexiones críticas sobre el dogmatismo en torno a Uncle Bob y los principios SOLID. Argumentó que muchos desarrolladores aplicaban SOLID mecánicamente sin entender el contexto en que cada principio tenía sentido. Varios miembros debatieron los límites del principio de responsabilidad única y cuándo la sobre-abstracción hacía el código más difícil de entender. Se mencionó que el propio Martin Fowler había dicho que el SRP era el más malinterpretado de los SOLID. Agustín señaló que los principios eran guías, no reglas absolutas, y que el pragmatismo dependía del tamaño y ciclo de vida del proyecto. La conversación fue técnicamente rica y generó múltiples perspectivas sobre el rol de los patrones en el diseño de software real.
4d6bede
Alguien compartió un workshop gratuito organizado por Microsoft sobre cómo armar un CV efectivo para posiciones técnicas. El grupo discutió los consejos del evento: cuantificar logros con métricas, adaptar el CV al puesto específico, y enfocarse en el impacto más que en las responsabilidades. Facundo mencionó que los CV de desarrolladores argentinos tendían a listar tecnologías sin contextualizar proyectos. Alguien recomendó el formato Harvard de una página como estándar preferido por recruiters internacionales. Se compartieron ejemplos de bullets bien escritos versus formulaciones genéricas a evitar.
c434a38
Sebastián preguntó por dónde empezar a aprender Go. El grupo recomendó el tour oficial en tour.golang.org como primer paso, seguido del libro 'The Go Programming Language'. Facundo mencionó que Go tenía una curva de aprendizaje muy baja para quien ya sabía algún lenguaje compilado. Se destacaron las goroutines y channels como el concepto más importante a entender de Go para aprovechar su modelo de concurrencia. Alguien compartió el repositorio awesome-go como colección de librerías y recursos. Se discutió en qué contextos brillaba Go: CLIs, APIs de alto rendimiento y herramientas de infraestructura como Docker y Kubernetes que estaban escritas en Go.
600a39f
Uno de los miembros compartió un problema de LeetCode que había resuelto recientemente: el de squares of a sorted array. Explicó que la solución naive era elevar al cuadrado y ordenar en O(n log n), pero que con la técnica de two pointers desde los extremos del array se podía resolver en O(n) aprovechando que el array estaba ordenado. El grupo siguió la explicación con interés y algunos propusieron variantes del problema. Facundo comentó que los dos pointers era uno de los patrones más útiles para dominar en entrevistas técnicas. Se discutió cuándo y cómo practicar LeetCode de manera efectiva sin gastar meses en problemas irrelevantes.
a4ddd28
Un debate surgió sobre si era valioso usar IDEs sin asistencia de IA para mantener y agudizar las habilidades de programación. Matías mencionó que usaba Neovim como editor principal y que la configuración desde cero le había enseñado mucho sobre cómo funcionaban los editores. Otros recomendaron Sublime Text por su velocidad y simplicidad. Alguien mencionó Zed como el editor más rápido del mercado, construido en Rust. Facundo argumentó que la elección del editor era personal pero que conocer las herramientas sin IA hacía mejor programador. El hilo generó debate sobre si el enfoque sin IA era productivismo o romanticismo innecesario.
>2025-04abril[21]
c968940
El grupo tuvo un debate extenso sobre las ventajas y desventajas del trabajo remoto versus presencial u híbrido. Quienes preferían remoto destacaron la flexibilidad, el ahorro en traslados y la posibilidad de trabajar para empresas fuera de Tucumán. Quienes valoraban lo presencial señalaban la importancia del contexto compartido, el aprendizaje informal y las relaciones con colegas. Facundo comentó que para los primeros años de carrera la presencialidad aceleraba el aprendizaje notablemente. Lucas mencionó que en Tucumán las empresas que pagaban bien solían ser remotas o tener sede en Buenos Aires. Se discutió el efecto de las diferentes zonas horarias en el trabajo remoto internacional.
b3f287e
Un miembro preguntó cómo pasar metadata personalizada en los webhooks de Mercado Pago para identificar a qué usuario o pedido correspondía un pago. El grupo explicó que Mercado Pago permitía enviar un campo `external_reference` al crear la preferencia de pago, que luego llegaba en el webhook. Facundo compartió un ejemplo de código en Node.js mostrando cómo setear el `external_reference` y luego leerlo en el handler del webhook. Se discutió también cómo verificar la autenticidad del webhook usando el header de firma que mandaba Mercado Pago para evitar pagos fraudulentos simulados. Varios guardaron el snippet como referencia.
489ae55
Agustín preguntó sobre estrategias para implementar feature flags y A/B testing en una aplicación backend. El grupo discutió opciones desde implementaciones caseras con una tabla en la base de datos hasta servicios como LaunchDarkly, PostHog y Growthbook. Facundo explicó un diseño simple donde los flags se guardaban en Redis con TTL corto para evitar queries constantes a la DB. Se discutió la importancia de poder rollback rápidamente en producción usando flags en lugar de deployments. Alguien mencionó que PostHog era open source y podía hostearse en infraestructura propia. La conversación cubrió también el targeting de flags por usuario, porcentaje de tráfico y atributos del request.
328c4b9
El grupo discutió el lanzamiento de Canva Code, una herramienta que prometía generar código desde diseños de Canva sin conocimientos de programación. Varios miembros fueron críticos con la calidad del código generado y las limitaciones para proyectos reales. Facundo argumentó que estas herramientas eran útiles para prototipado rápido pero no reemplazaban el desarrollo profesional. Otros compararon con Webflow y Framer como alternativas más maduras para no-code con resultados más predecibles. Se debatió si estas herramientas competían con los desarrolladores junior o si más bien expandían el mercado al habilitar a no-técnicos a construir cosas simples.
972e98b
El grupo debatió el término 'vibe coding' acuñado por Andrej Karpathy, que describe la práctica de programar con IA sin entender completamente el código que se genera. Algunos miembros criticaron la tendencia como peligrosa para la profesión y para la calidad del software. Otros argumentaron que era una evolución natural de la abstracción, comparándolo con cómo los programadores modernos no necesitan escribir assembler. Facundo señaló que la distinción importante era entre usarlo como herramienta de productividad (con comprensión) versus delegar completamente sin entender nada. Se debatió si el vibe coding era apropiado solo para prototipos o también para producción.
b543849
Lucas preguntó sobre el mercado freelance local en Tucumán y si era viable conseguir clientes como desarrollador independiente. El grupo compartió experiencias mixtas: algunos habían conseguido clientes locales para proyectos WordPress o aplicaciones simples, pero los precios del mercado local eran significativamente más bajos que los del mercado internacional. Facundo recomendó apuntar directamente al mercado de habla inglesa en plataformas como Toptal, Contra o LinkedIn, evitando Upwork por su saturación. Otros sugirieron construir un nicho específico en lugar de competir genéricamente. Se discutió la importancia del portafolio en GitHub y proyectos propios con usuarios reales.
c73951b
Un miembro preguntó cómo configurar subdominios wildcard en DonWeb para redirigir a un servidor propio con nginx. El grupo explicó los pasos: crear un registro DNS wildcard (*.dominio.com) apuntando al servidor, luego configurar un server block en nginx que matcheara cualquier subdominio. Facundo compartió un snippet de configuración de nginx con `server_name *.dominio.com` y la directiva `proxy_pass` para redirigir al servicio backend. Se discutió la diferencia entre wildcards en DNS versus el manejo en el servidor web. Alguien mencionó que DonWeb a veces tardaba hasta 48 horas en propagar los cambios de DNS.
30b9851
Matías consultó sobre dónde comprar componentes para armar una PC en Buenos Aires con buen precio. El grupo compartió tiendas de Parque Patricios y Once conocidas por precios competitivos en hardware. Se discutió la diferencia de precios entre comprar armado versus armar uno mismo. Varios recomendaron revisar las publicaciones en MercadoLibre de vendedores con calificación alta para conseguir mejores ofertas. Alguien mencionó que los precios en Buenos Aires solían ser mejores que en Tucumán por mayor competencia entre vendedores. Se compartieron links de tiendas específicas en Palermo y Congreso.
721b9ae1 participantes
Fede Valle anunció el lanzamiento de GinkgoDevs, su agencia de desarrollo, con un sitio web construido en Three.js con efectos visuales 3D. El grupo quedó impresionado con el diseño del sitio. Se discutió la elección de Three.js para el sitio de una agencia como estrategia de diferenciación visual. Facundo preguntó sobre el proceso de construcción y el tiempo invertido. Fede explicó los desafíos de optimizar la carga del sitio con Three.js para que fuera rápido en móviles. El grupo felicitó el emprendimiento y la propuesta visual del sitio.
Un miembro trajo el problema de cómo migrar el schema de una base de datos en producción sin tiempo de inactividad. El grupo discutió estrategias como expand-contract pattern, blue-green deployments y feature flags para activar el nuevo schema gradualmente. Facundo explicó la técnica de crear las nuevas columnas como nullable primero, actualizar el código para escribir en ambas columnas, migrar los datos históricos en background, y finalmente eliminar las columnas antiguas. Se mencionó el uso de Flyway y Liquibase para gestionar migraciones versionadas. La discusión fue técnicamente detallada y varios guardaron el hilo como referencia.
d176420
Un miembro que estaba aprendiendo React Native preguntó cómo conectar su app móvil con un backend en .NET que corría localmente en su máquina. El grupo recomendó usar ngrok para exponer el servidor local mediante un túnel HTTPS que fuera accesible desde el dispositivo físico. Se explicó la diferencia entre usar el emulador (que puede acceder a localhost) versus un dispositivo real (que necesita la IP de la red o un túnel). Facundo mencionó que ngrok tenía un plan gratuito suficiente para desarrollo. También se recomendó Expo para simplificar el desarrollo de React Native evitando la complejidad de configurar Android Studio y Xcode.
0143935
Agustín compartió OriginUI, una librería de componentes para React con enfoque en accesibilidad y diseño moderno. El grupo exploró los ejemplos de la librería y comparó con otras opciones como shadcn/ui, Radix UI y Headless UI. Facundo señaló que OriginUI tenía componentes que shadcn no incluía por defecto. Se discutió la tendencia de construir sobre Radix primitives para garantizar accesibilidad sin tener que implementarla desde cero. Varios miembros marcaron el recurso como favorito para futuros proyectos frontend.
cf2696d1 participantes
Matías Gutiérrez compartió con el grupo que había terminado una funcionalidad clave de su aplicación de cefalometría para uso odontológico. El grupo lo felicitó por el hito. Matías explicó que la app permitía hacer análisis cefalométricos digitalmente, reemplazando un proceso manual que los odontólogos hacían sobre radiografías. Comentó los desafíos técnicos de implementar los algoritmos de medición de ángulos y distancias sobre imágenes médicas. Varios miembros preguntaron sobre la stack elegida y el plan de monetización. La historia fue recibida con entusiasmo como ejemplo de aplicación con dominio específico y cliente real.
Rodrigo compartió que había descubierto que la app de escritorio de ChatGPT podía ver el contenido de la pantalla en tiempo real cuando se le daba permiso. El grupo discutió las implicaciones de privacidad de esta funcionalidad. Facundo probó la feature y contó que ChatGPT podía responder preguntas sobre lo que aparecía en la pantalla sin necesidad de hacer capturas manuales. Se comparó con Copilot de Microsoft que tenía una funcionalidad similar en Windows. Algunos vieron el potencial para asistencia en vivo durante debugging o revisión de código, mientras otros expresaron preocupaciones sobre qué datos se enviaban a los servidores.
1415d62
Marco trajo el debate sobre el alto consumo de RAM de las apps construidas con Electron como Slack, VS Code y Discord. Varios miembros criticaron el overhead de empaquetar Chromium con cada aplicación. Se mencionaron alternativas como Tauri (que usa el webview del sistema operativo), Flutter para desktop, y aplicaciones nativas. Facundo argumentó que VS Code justificaba el consumo por la extensibilidad que ofrecía. Se discutió que Tauri con Rust ofrecía bundles mucho más livianos pero requería conocer Rust para la parte del backend. La conclusión fue que Electron seguía siendo la opción pragmática para apps cross-platform a pesar del consumo de memoria.
77cd843
Exequiel compartió su canal de YouTube con tutoriales de Git orientados a principiantes. Ariel también mencionó su propio canal con contenido similar. Varios miembros del grupo felicitaron la iniciativa de crear contenido en español para la comunidad local. Se discutió qué temas eran los más confusos para quienes empezaban con Git, mencionando el manejo de branches, merge conflicts y el flujo de trabajo con pull requests. El grupo recomendó los recursos a quienes recién empezaban en el programa.
e274a63
Rodrigo compartió que estaba experimentando con el Vercel AI SDK para integrar Grok de xAI en un proyecto con Astro. El grupo mostró interés por el SDK de Vercel como abstracción para trabajar con múltiples modelos de lenguaje. Agustín comentó que el SDK simplificaba mucho el streaming de respuestas y el manejo de herramientas. Se discutió la compatibilidad de Astro con islands architecture para proyectos que mezclaban contenido estático con componentes reactivos. Facundo mencionó que Grok tenía un contexto de un millón de tokens que lo hacía interesante para tareas de análisis de documentos largos.
2488d73
El grupo discutió el anuncio del gobierno argentino de reemplazar el cepo cambiario con un sistema de bandas de flotación. Varios miembros celebraron la medida como un paso hacia la normalización cambiaria. Se debatió el impacto en los salarios en dólares de quienes cobraban del exterior y los que trabajaban en empresas locales. Facundo comentó que la incertidumbre sobre el tipo de cambio seguía siendo un factor determinante para decidir entre trabajar para una empresa local o remoto para el exterior. Matías señaló que el nuevo sistema generaba dudas sobre si el dólar blue convergería con el oficial en el corto plazo.
e413159
Sebastián consultó qué notebook convenía comprar para data science con presupuesto limitado en Argentina. El grupo debatió entre opciones con GPU dedicada versus procesadores Apple Silicon. Matías recomendó las MacBook con chip M por la eficiencia energética y el rendimiento en tareas de machine learning usando Metal. Otros señalaron que una notebook con GPU NVIDIA permitía usar CUDA directamente con frameworks como PyTorch. Se mencionaron modelos de Lenovo ThinkPad y Dell XPS como alternativas intermedias. La discusión concluyó que el chip M de Apple ofrecía la mejor relación rendimiento/precio en el mercado actual argentino a pesar del costo en dólares.
98906601 participantes
Lucas preguntó cómo monetizar una app en Argentina y cobrar en dólares sin complicaciones legales. El grupo discutió las opciones de abrir una LLC en Estados Unidos, usar Stripe con entidad extranjera, y la alternativa de facturar como monotributista de servicios digitales al exterior. Facundo García explicó su experiencia abriendo una LLC en Wyoming a través de servicios como Stripe Atlas o FirstBase, lo que permitía cobrar internacionalmente sin los límites del cepo cambiario. Otros mencionaron que el monotributo permitía facturar servicios al exterior con el beneficio cambiario del dólar exportación. Se discutió la complejidad impositiva de cada opción y la conveniencia de asesorarse con un contador especializado en tech.
Nico preguntó si IntelliJ Community era suficiente para trabajar con Spring Boot o si era necesaria la versión Ultimate. Varios miembros respondieron que la edición Community cubría la mayoría de los casos para proyectos Spring, aunque la Ultimate ofrecía soporte nativo para el framework con asistencias de autocompletado más ricas. Agustín comentó que en su trabajo usaban Community sin problemas. Facundo mencionó que el soporte de Spring en Ultimate justificaba el costo si la empresa lo pagaba, pero que para aprendizaje personal la versión gratuita era más que suficiente.
