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.

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 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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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 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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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'.

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ó 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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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 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.

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'.

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'.

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.

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.

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ó.

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.

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.

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ó 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.

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.

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.

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.

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.

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ó 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.

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.

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.

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).

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.