~/pcn $ iniciando_
tail -f comunidad.log
proyectoFabio RamosExpoLogic es una plataforma SaaS multi-tenant para organizadores de ferias culturales, mercados artesanales y eventos de emprendedores. Centraliza mapas interactivos de stands, reservas con lista de espera, landings públicas por evento, feria virtual (directorio de participantes y catálogos de productos) y un panel operativo con analytics.
setupAgustín SánchezEl setup que tenía cuando empecé a desarrollar el website de PCN. MacBook Air con chip M1 y 8GB de RAM, monitor Dell full-HD, magic keyboard y magic mouse.
changeloglecturaCon recomendar en /lectura, /cursos, /videos y las charlas externas de /charlas podés sumar lo que te sirvió. Un admin lo revisa antes de publicarlo y mientras tanto lo ves como pendiente de revisión.
changeloggaleríaCualquier miembro puede subir fotos de los eventos a la galería desde subir(). Se publican cuando un admin las revisa y las aprueba.
changeloggaleríaNueva pestaña "trabajando" en la galería con fotos de la comunidad en su escritorio, la oficina o una hackatón. Subí las tuyas desde la pestaña "trabajando" de tu perfil.
Cada proyecto de la comunidad tiene su propia página con la descripción completa, el stack, los links y el equipo. Los proyectos del feed, de PCN NEWS y de los perfiles abren directo en esa página.
changelogproyectosEl equipo de un proyecto puede subir capturas y videos de demo a su página. Los videos se optimizan en tu dispositivo antes de subirse, como en la galería.
changelogperfilLa pestaña de contribuciones de cada perfil lista lo que la persona construyó en la plataforma, con las mismas entradas que aparecen en este changelog.
galería3 fotos
proyectoLeandro Maximiliano ContreraExtensión de OpenLifter para torneos WRPF Argentina: organiza atletas y plataformas, gestiona pesajes e intentos en vivo, recoge votos de jueces y muestra resultados al público con iluminación DMX.
galería1 foto
galería15 fotos
proyectosalvador juarezshadownrx/code es una herramienta de build automation que transforma aplicaciones web en aplicaciones nativas mediante pipelines reproducibles.
proyectosalvador juarezNEX OS transforma el navegador en un entorno de computación. Un sistema operativo web que reúne aplicaciones, inteligencia artificial y herramientas de desarrollo en un escritorio interactivo y personalizable. Creado para trabajar, crear y explorar nuevas posibilidades desde la web.
changelogosSi iniciás sesión desde una ventana de PCN OS, la barra del escritorio se actualiza enseguida y deja de mostrar "Iniciar sesión".
changeloginfraEventos, charlas, galería, consejos, proyectos, miembros, perfiles, logros y la búsqueda se sirven desde un caché que se actualiza apenas cambia algo, así que la mayoría de las páginas ya no esperan a la base de datos.
MacBook Air con chip M1 y 8GB de RAM, monitor LG full-hd, y un magic mouse. Hay 2 MacBooks en la foto porque fue mi primer día en Eagerworks y me dieron una MacBook nueva, la otra era personal.
nuevo dev@luki1qqSu primera PR: “La barra del escritorio sigue mostrando 'Iniciar sesión' tras loguearse en una ventana”. Ya suma 1 PR mergeada.
changelogmetricasLa app Métricas ahora es pública: cualquiera puede ver el tráfico del sitio, los módulos y páginas más usados, el funnel de registro y el engagement de la comunidad. Los números se actualizan cada hora.
changelogentrevistasNuevo tipo de entrevista de seguridad informática (AppSec, pentesting y defensa) en el simulador, con preguntas para junior, semi-senior y senior y su guía de preparación. La guía recomienda los cursos de seguridad ofensiva y Blue Team de Endpoint Consulting, partner de la comunidad.
changelogentrevistasNueva sección de live coding en entrevistas: enunciados como los de una entrevista real para resolver por tu cuenta y problemas de LeetCode recomendados para cada tecnología y seniority, más una guía de cómo encarar un live coding. Marcá lo que ya resolviste para seguir tu progreso.
changelogentrevistasCada tipo de entrevista tiene su guía de estudio: cómo suele ser el proceso, los temas que más se preguntan de junior a senior y qué tenés que poder explicar. Marcá cada sección como leída para seguir tu progreso y, cuando termines, ponete a prueba en el simulador.
Su primera PR: “Lista de espera con promoción automática”. Ya suma 1 PR mergeada.
nuevo dev@shadownrxSu primera PR: “Instalar PCN como app (PWA) con pantalla offline”. Ya suma 1 PR mergeada.
eventoCafé VirtualSebastián Soraire abrió el PCN Café Virtual contando que la idea del encuentro surgió charlando con Agustín Sánchez sobre las nuevas tecnologías y sobre cómo se están dando hoy las entrevistas, y que en los últimos dos meses notó que empezaron a aparecer muchas propuestas laborales de todo tipo. Sebastián lo relacionó con métricas comentadas en una reunión del clúster tecnológico del que participa: hace un año las empresas empezaron a meter IA a fondo y a desplazar puestos, y hace unos dos meses empezaron a recular porque la IA no cumplía lo esperado en resultados o en costos, así que están recontratando de a poco a parte del personal que habían despedido, algo que también se refleja en LinkedIn. Agustín Sánchez dejó clara su postura: el problema no es la IA sino la gente. Según Agustín, muchas empresas tienen expectativas altísimas y creen que pagarle a un empleado una suscripción de 200 dólares y despedir a otros cinco alcanza, cuando en realidad todo depende de qué tan bueno es en agentic engineering (desarrollar delegando el trabajo a agentes de IA) quien queda: si no sabe hacer valer esa suscripción, entregando rápido y con calidad, el cambio no aparece. Para Agustín es una transformación que lleva tiempo y necesita ingenieros muy apasionados, que son pocos, porque la mayoría de los desarrolladores trabaja por trabajar; por eso, para él, si una empresa recontrata es porque tomó malas decisiones, no supo usar la IA ni capacitar a su gente, y no porque la herramienta falle. Agustín agregó que PCN es una burbuja chiquita, que habla todo el tiempo de agentes y tiene opiniones bastante radicales, mientras que la mayoría de los desarrolladores está muy atrasada y ni siquiera sabe lo que es posible: un tipo nuevo de ignorancia, la de no saber lo que uno no sabe, que limita el universo de cada uno. Contó que cuando alguien cuenta que dejó agentes trabajando de noche y a la mañana tenía 25 features, usando técnicas como loop engineering (dejar agentes iterando solos sobre un objetivo) o graph engineering, la reacción típica es tratarlo de loco o suponer que son MVPs sin importancia; Agustín aclaró que en su caso son proyectos productivos y que los agentes escriben mejor código que el 99% de los humanos, que muchas veces no le ponen cariño, hacen pull requests horribles y no escriben tests automatizados. Agustín citó una charla reciente de DHH (creador de Ruby on Rails) cuyas afirmaciones considera hechos y no locuras, aunque buena parte de la industria lo vea como alguien que se descarriló. Igual Agustín matizó que el mercado no se puede generalizar: hay empresas que no se adaptaron en nada, otras un poco y otras muy agénticas, así que no hay una sola forma de prepararse para una entrevista ni de conseguir trabajo; depende del tipo de empresa al que uno apunte, y las tradicionales siguen con los métodos de antes. Benjamin Cortes apoyó la idea de la burbuja: en el grupo está naturalizado hablar de AI engineering o de harness y compartir cada modelo nuevo, pero eso no es lo normal y vale remarcarlo para que se den cuenta de que se están adelantando. Benjamin contó que en una reunión con el responsable de sistemas de una empresa con 30 sucursales en el país, la charla empezó como una entrevista hacia él y terminó dándose vuelta: el responsable admitió que estaban atrasados con la IA, que estaba empujando a sus desarrolladores a usarla y presentaba Antigravity (el entorno de desarrollo con agentes de Google) como algo que hace todo, sin mencionar nunca Claude ni Codex. Agustín agregó que corren el riesgo de quedar como locos: en una charla de loop engineering que dio en la empresa donde trabaja lo miraban como a un demente mientras explicaba la teoría, hasta que mostró un proyecto entero hecho así y la terminal con los agentes avanzando solos; recién ahí entendieron. Agustín recomendó no caer en el prejuicio de que quien trabaja así no se toma en serio la calidad ni el producto, y dijo estar agradecido de estar en ese nicho porque les permite estar al día. Franco Perez retomó lo de Sebastián: si gente en puestos de decisión ni siquiera llegó al hype de la IA, hay mercado y demanda para todos, para quien quiera trabajar de una manera o de otra, y muchas oportunidades para quien tiene los conocimientos, al menos en este momento; Agustín coincidió en que por ahora es así.
eventoCafé VirtualSebastián Soraire sumó que detrás de lo que pasa tanto en las empresas como en las personas pesa mucho el autoconocimiento. Según Sebastián, en las empresas la tensión natural entre marketing, finanzas y producción genera fricción cuando falta conocimiento entre las partes: se lanza una idea porque va a generar plata, con análisis de mercado pero no de la tecnología, y a los diez minutos se cambia lo que el equipo venía construyendo hace días. En lo personal, Sebastián contó que pasó de trabajar por trabajar a disfrutar lo que hace, porque si pasa ocho, nueve o diez horas frente a la computadora sin disfrutarlo se le va la vida; eso lo llevó a hacer las cosas bien, informarse y mantenerse actualizado, y cree que la valoración de lo que uno hace y los hábitos se trasladan al trabajo en cualquier rol, sea programador, scrum master o QA. Agustín Sánchez coincidió y dijo que saber aprender y desbloquearse solo siempre fue importante en la industria del software, pero que ahora lo es más que nunca. Agustín contó que en muchas empresas, a quienes no están apasionados por el software hay que darles el espacio y todo servido (una guía, un artículo, un curso) y aun así, si no se los obliga, no aprenden. Agustín explicó cómo funcionan las evaluaciones semestrales por rúbrica: el manager califica áreas como especialización técnica, comunicación con el cliente o trabajo en equipo según la seniority, y lo más valioso es saber qué hacer para subir al siguiente nivel, no como castigo sino como guía. Pero, según Agustín, quien trabaja por trabajar se limita a cumplir la rúbrica y nada más, sin ninguna motivación personal para ir más lejos, así que si no se evalúa explícitamente el agentic engineering (desarrollar delegando el trabajo a agentes de IA), no se pone las pilas. Para Agustín hace falta cariño y pasión personal por el software para seguir aprendiendo por cuenta propia y no esperar que la empresa facilite las cosas: si la empresa no paga una suscripción de IA, la pregunta es si uno se la paga o se priva de actualizarse. Agustín aclaró que lo ideal es que la pague la empresa, pero que invertir plata propia en eso es invertir en uno mismo, y que esa diferencia separa mucho a la industria, porque quien trabaja por trabajar nunca pagaría ni un dólar de su bolsillo. Agustín cerró que la IA ya cambió muchísimo las cosas y que, aun sabiendo que PCN y Twitter son burbujas, hay que mantenerse en la cresta de la ola y lo más actualizado posible.
eventoCafé VirtualFabio Ramos llevó al café una pregunta que quería hacer en el grupo: por qué la IA genera tanto rechazo entre desarrolladores. Fabio recordó que cuando empezó a programar con HTML, CSS y algo de JavaScript, descubrir Bootstrap lo volvió loco por los componentes ya armados, y lo mismo le pasó con React y otras librerías; ahora aparece la herramienta por excelencia, que ya no solo simplifica la construcción sino también levantar, plantear y analizar un proyecto, y aun así hay rechazo. Agustín Sánchez respondió que es un problema humano: al ser humano le cuesta soltar lo que sabe y aceptar que la IA hace mejor lo que uno sabía hacer. Para Agustín, ese período de aceptación, de humildad y de dejar el ego de lado, como venía diciendo Benjamin, es la clave que permite crecer hoy, y ve mucha gente que no puede admitirlo. Fabio coincidió y dijo no entender cómo la pasión por hacer software no pesa más que el ego, cuando hoy se pueden levantar tres proyectos en una semana mientras antes un e-commerce llevaba varias semanas; además, notó que la entrada al software se volvió más complicada porque mucha gente se plantea no estudiar, pensando para qué aprender si la IA ya lo sabe, cuando en realidad igual hay que saber usar las herramientas. Leandro Andriani, de 25 años y estudiante de la Tecnicatura en Programación de la UTN, contó que la IA le cayó como un baldazo de agua fría y que pasó por todas las etapas: miedo, porque hacía literalmente aquello por lo que estaba estudiando; negación, pensando que lo hecho con IA estaba armado de cualquier manera y sin el cariño de hacerlo a mano; y aceptación, entendiendo que llegó para quedarse y que conviene usarla a favor. Leandro contó que hoy saca adelante proyectos que antes le hubieran llevado meses y aprende mucho más. Leandro señaló que en su provincia la gente todavía está transitando esas etapas y que hay mucho atraso tecnológico, con empresas e incluso instituciones educativas que usan planillas de Excel como base de datos. Más adelante, Benjamin Cortes conectó la pregunta de Fabio con la de Leandro: cuando apareció ChatGPT, en 2023 y 2024, para él fue una batalla de ego, la de haber estudiado cinco años y trabajado en una empresa para que algo le dijera qué hacer. Para Benjamin, con el uso se van desbloqueando etapas hasta encontrar el peso en la balanza del que hablaba Fabio, y con lo que avanzaron los modelos cree que quien hoy no usa IA es porque todavía no la usó de verdad: no armó un proyecto propio de cero, quizás por miedo a no conocer un lenguaje o a no saber de arquitectura, que es justamente donde la IA ayuda a seguir avanzando. Ya hacia el final de esa parte, Sebastián Soraire lo explicó desde la psicología y la neurociencia: el miedo nos mantenía alertas para sobrevivir hace miles de años, y hoy la batalla ya no es física sino psicológica; con tanto bombardeo sobre la IA, el cerebro interpreta que lo que funciona va a dejar de funcionar y que uno está en peligro, porque lo conocido es seguro y lo desconocido peligroso. Por eso, según Sebastián, hay resistencia al cambio y tantos entornos prefieren su zona de confort, como la organización que sigue con Excel porque le funciona.
eventoCafé VirtualLeandro Andriani preguntó si tiene sentido estudiar una tecnicatura en programación, de la que muchos dicen que murió hace dos años, y qué recomendarían estudiar de verdad. Sebastián Soraire defendió las bases: entender bucles, listas, funciones, algoritmos y cómo el hardware los soporta no cambia entre lenguajes y va a seguir vigente por unos años, y sirve para tener un panorama de qué puede estar fallando cuando lo que hizo la IA se rompe; sin eso, la IA es una caja negra que dejó de funcionar. Agustín Sánchez dio una opinión que él mismo calificó de medio loca: ya no tiene sentido aprender a codificar, porque la IA escribe código a una velocidad y con una calidad muchísimo más altas que cualquier humano, y en cualquier empresa, por más desactualizada que esté, el código se va a hacer como mínimo con IA. Aclaró que sí tiene sentido estudiar lógica, bucles o programación orientada a objetos para entrenar la inteligencia y la cabeza de software, que después ayuda a construir cosas más grandes y resolver problemas de arquitectura, pero no porque uno vaya a escribir esos loops en el trabajo, y que hace falta humildad para aceptar que la IA lo hace mejor. Para Agustín, saber codificar también ayuda a verificar lo que hizo la IA, aunque llega un punto en que ni siquiera se revisa: hay pull requests en las que no mira muchos archivos y, como había dicho Facundo García Martoni sobre el frontend, lo que más lee es el SQL de las migraciones, porque es el código que toca los datos de los usuarios y puede poner en riesgo el producto, siempre con backups y un harness (el entorno de herramientas, tests y reglas que rodea al agente) que permita revertir si algo sale mal. Agustín remarcó que llegar a ese nivel lleva tiempo, porque las técnicas de agentic engineering son compositivas y se incorporan paso a paso hasta poder delegar más y tomar más riesgo. Sebastián le preguntó si antes de eso no hacía falta entender lo que hacía la IA, recordando una demo de spec-driven development (desarrollo guiado por especificaciones escritas antes del código) que la comunidad mostró en su facultad y que falló al compilar. Agustín respondió que en un proyecto viejo uno ya tiene ese entendimiento por haber trabajado en las trincheras, pero que en uno nuevo lo normal es delegar mucho y quedarse en el nivel de arquitectura y producto: él define el stack, cuánto quiere gastar y qué performance necesita. Agustín contó que hizo un juego multijugador de autos para eventos masivos, en el que la gente usa el celular como joystick, en Go sin haberlo tocado nunca, porque con TypeScript, su lenguaje de siempre, no iba a alcanzar la performance y necesitaba que el tráfico de red fuera óptimo en lugares con mala conexión; funciona muy bien porque sabía qué tenía que tener el backend, como testing, algo transversal a cualquier tecnología, aunque no sabe cómo está hecho cada endpoint ni qué capas tiene. Agustín explicó que gracias al harness puede tratar a los agentes como un equipo tercerizado del que él es el cliente, y lo que lo diferencia de un vibe coder (alguien sin conocimientos técnicos que programa solo pidiéndole cosas a la IA) es saber qué hay abajo, lo que le da confianza aunque no lea cada línea. Para elegir lenguaje o framework, dijo Agustín, también se puede decidir junto con la IA; lo importante es ser lo suficientemente inteligente para discutirlo y tomar una buena decisión. Benjamin Cortes, docente en la UNT, citó a un profesor que repite que el conocimiento es poder: las bases dan velocidad y mejores decisiones, y la arquitectura ayuda a proyectar el sistema. Benjamin se preguntó cuánto falta para que una IA te haga un cuestionario y resuelva todo sola, contó que con Fable 5 sintió que ya estaba, y citó la charla de DHH, que hace aplicaciones nativas en Rust para Omarchy (su distribución de Linux) sin conocer el lenguaje. Benjamin dijo que a sus alumnos les diría que inviertan en una suscripción, quemen tokens y rompan cosas para aprender en el ida y vuelta, algo que favorece a los autodidactas, y recordó que lo que siempre le gustó de la tecnología fue romper cosas y arreglarlas, hoy mucho más rápido. Agustín coincidió: hay que hacer lo que divierte y quien disfruta escribir código puede hacerlo, pero el mercado exige velocidad y competitividad; antes se podía ser competitivo siendo un romántico del código, hoy eso pasó y hay que dejar el ego de lado para crear productos, porque el código siempre fue un medio para crear software. Franco Perez sumó que el trabajo del ingeniero siempre fue dar soluciones tecnológicas a problemas, que a veces uno se enamora de una forma de hacerlo y que ahora toca aprender la nueva, como mostraba un video que compartió sobre cómo alguien organiza su trabajo con agentes. Leandro llevó la pregunta más lejos: en proyectos grandes hay frameworks y librerías, y quería saber hasta dónde conocer por dentro esa caja y hasta dónde orquestar; contó que piensa ser experto en su stack, que nunca le atrajo tanto el código sino ser una parte importante que da soluciones, y que de ahí venía su miedo. Sebastián respondió con una analogía que usó con un scrum master no técnico: no hace falta conocer cada pieza para manejar un auto, pero sí si uno quiere poner un taller, por curiosidad o por especialización.
eventoCafé VirtualFacundo García Martoni armó un esquema con lo que se venía diciendo y respondió primero la pregunta de Benjamin Cortes: el momento en que la IA resuelve un sistema a partir de un cuestionario ya llegó, desde hace unos tres o cuatro meses, con modelos de frontera como Fable, Opus 5 y Grok 4.7, que funcionan como un genio de la lámpara para cualquier cosa de software. Para Facundo, la clave está justamente en ese cuestionario, en el comportamiento, y eso cambió el rol del desarrollador y el code review: antes se revisaba la implementación buscando errores de sintaxis, una variable que no se usa o una función que convenía dividir, y hoy un modelo de frontera no comete ese tipo de errores. Por eso Facundo ya no revisa el frontend, como había contado Agustín Sánchez, porque es mayormente implementación y se puede verificar probando la interfaz; en cambio lee el backend, las migraciones y los cambios de modelo de datos buscando que el comportamiento, la lógica de negocio, refleje lo que él y su usuario tenían en mente. Para eso, según Facundo, lo fundamental es reducir la ambigüedad entre lo que uno quiere y lo que se va a hacer, con skills que lo entrevistan antes de implementar, como las de Matt Pocock; aun con una buena entrevista o un buen plan mode, siempre aparece algo que en realidad debería pasar de otra manera, y eso es lo que termina corrigiendo antes de shipear. De ahí Facundo sacó dos habilidades: entender al usuario y pasar lo que quiere a palabras, verificando al final que el sistema cumpla esas reglas implícitas, porque lo del medio ya está resuelto; y pensar en sistemas, preguntándose si algo es lo suficientemente genérico, si le sirve a otros usuarios, cómo va a evolucionar en un año y cómo se relaciona con la visión del producto. Facundo comparó el momento con el paso del lenguaje máquina, en el que se escribían los videojuegos de la época de Atari, a los lenguajes de alto nivel: ahora se pasa a un nivel todavía más alto y los sistemas se describen en inglés o en español en lugar de Python, JavaScript, TypeScript o Ruby. Facundo lo hace con skills (instrucciones reutilizables para un agente): en una startup B2B, en vez de escribir un script de mil líneas para dar de alta a una empresa, escribe unas veinte líneas con los requisitos que cada empresa debe cumplir al entrar y lo invoca con una barra y el nombre de la skill, igual que antes modularizaba código. Fabio Ramos pidió que la potencia de las herramientas no mate la curiosidad, porque el criterio técnico que sale de saber cómo funcionan las cosas por detrás es lo que permite definir buenos requerimientos y flujos y darle una solución real al usuario, y hasta crear buenas herramientas y skills propias. Sobre lo que había dicho Benjamin de que quien no usa IA es porque no la probó, Fabio coincidió en parte, pero contó que trabajó en un entorno tan cerrado que no se podían usar Cursor ni Claude, y que hay proyectos con años de deuda técnica enorme que el equipo de turno no resuelve; quizás sea el mejor momento para encararla con estas herramientas, pero sigue siendo una tarea complicada que pocos se animan a tomar.
eventoCafé VirtualGonzalo Morales contó que construyó features antes de la IA que hoy nadie usa, y que muchas veces un cliente cree que su problema se resuelve de una manera cuando, mirándolo mejor, se resuelve de otra; el trabajo está en entender por qué una solución conviene más que otra, decisiones de arquitectura y de contexto que están fuera de la programación pero dentro de la ingeniería de software. Por eso Gonzalo considera irracional el miedo a que la IA haga todo: sí lo hace, pero hay que saber bien qué es ese todo, y muchas aplicaciones que parecen tremendas no resuelven un problema real ni aportan el valor que sus creadores creen. Fabio Ramos agregó que, como una feature ahora sale en un par de prompts, la falta de criterio al definir requerimientos lleva a sobretrabajar en cosas que el cliente nunca pidió, que no necesitaba o que pidió pero nunca va a usar, algo mucho más común que antes, cuando todo había que hacerlo a mano; definir bien el requerimiento sigue siendo tarea del desarrollador. Sebastián Soraire lo tomó como confirmación de lo que había dicho Agustín Sánchez: ejercitar el pensamiento es lo que permite llegar a soluciones adecuadas. Benjamin Cortes sumó otro costado: además del entendimiento técnico, la toma de requerimientos exige habilidades blandas para saber qué preguntar, cómo preguntarlo y descubrir para qué se quiere algo, en lugar de aceptar al pie de la letra el color y el botón que pide el cliente porque es quien paga. Para Benjamin, hoy que el código dejó de ser la mayor barrera, esas habilidades pesan más que nunca para coincidir en qué se necesita y para qué; reconoció que el cliente nunca sabe del todo lo que quiere, pero con práctica se aprende a distinguir un problema real de un capricho. Gonzalo lo ilustró con un posible cliente con una tienda online de equipamiento de gimnasio que pedía conexión con un CRM y muchas funcionalidades: armó el presupuesto pensando la mejor arquitectura, no se concretó, y tiempo después vio que el cliente había avanzado con un catálogo muy básico que no tenía ni la mitad de lo que había descrito. Leandro Andriani coincidió en que conocer al cliente y cómo se trabaja en su empresa es hoy el gran diferencial, porque los usuarios finales suelen ser personas de entre 30 y 60 años con poca familiaridad tecnológica: la mejor solución técnica no sirve si el empleado de 45 años que apenas conoce Excel no la quiere usar después del primer problema. Leandro contó que en un trabajo para una institución terminó volcando todo directamente a una planilla de Excel, como la gente había trabajado siempre, y lo usaron sin problemas: no era la mejor solución, sino la que necesitaban. Para Leandro, conocer el flujo de la organización de abajo hacia arriba, quién va a usar el sistema y quién decide, es la habilidad que hay que aprender ahora que desarrollar está automatizado. Sebastián cerró que, como también decía Facundo García Martoni, lo que va a primar son las habilidades blandas para descubrir el contexto, el trabajo y el modelo de negocio del cliente.
eventoCafé VirtualBenjamin Cortes le preguntó a Agustín Sánchez por algo que había leído en el grupo: que fue engineering manager y después volvió a ser contribuidor individual. Agustín contó que el año pasado trabajó como engineering manager, la última posición que había entonces en la escalera de crecimiento de la agencia de software donde trabaja; el rol terminó siendo muy distinto de lo que esperaba y, hablándolo con su jefe, volvió a una posición técnica de tech lead. Agustín explicó que el rol dice engineering y tiene mucho trabajo técnico, como planificar roadmaps, plantear arquitecturas en los proyectos, definir lineamientos técnicos en varios proyectos y resolver problemas avanzados, pero que gran parte del rol es gestión de personas, algo que no tiene nada que ver con esa parte técnica y es casi psicológico: lograr que la gente a cargo esté bien trabajando en la empresa, resolver problemas de desempeño, dar el toque de atención o despedir cuando hace falta, hacer entrevistas y evaluaciones, con habilidades más de recursos humanos que técnicas. Según Agustín, es un patrón muy común ascender a manager al tech lead que viene liderando un proyecto y hablando con el cliente, y para él la mayoría termina sufriendo el rol y queriendo volver atrás. Para Agustín, lo más difícil fueron los feedbacks semestrales o anuales, que son la oportunidad de ayudar a crecer a cada persona diciéndole qué hace bien, qué hace mal y qué le falta: dar un feedback negativo obliga a plantearlo distinto para cada persona, consume muchísima energía y requiere habilidades blandas avanzadas. Agustín dejó claro que ser manager no es un rol al que haya que aspirar por estar arriba del tech lead: está bien hacerlo por experiencia o porque gusta, pero quien prefiere lo técnico no está estancado por no subir ahí. Igual Agustín no se arrepiente, porque aprendió cómo funciona una agencia de desarrollo de software de forma end-to-end y al detalle: cómo se mueven los sueldos, cuánto se cobra a los clientes y qué es el margen bruto, la diferencia entre lo que se le cobra al cliente y lo que se paga a quienes trabajan en el proyecto. Agustín explicó que en una agencia, donde la plata entra por las horas facturables de desarrolladores, QA, project managers y tech leads, ese margen sostiene todo lo que no se factura: quienes venden proyectos, recursos humanos, oficinas, computadoras, licencias de software, beneficios como la obra social, comida o retiros anuales, y hasta el costo de que alguien se tome vacaciones; en una empresa de producto, que vive de suscripciones o licencias, la lógica es otra. Agustín también aprendió lo complejo de decidir cuándo se puede subir un sueldo, sabiendo que no hacerlo en el momento justo puede desmotivar a alguien y hacer que se vaya. Agustín contó que en su propia startup, aunque la fundó, es el CTO y no quiere ser CEO, y le preguntó a Facundo García Martoni dónde se imagina él. Facundo puso como ejemplo a Obsidian, que con seis o siete ingenieros vale cerca de mil millones de dólares, y citó a un exjefe suyo: una startup chica se parece más a un equipo SWAT que a un ejército, con menos jerarquía, mejor comunicación y sistemas que se transmiten más rápido. Facundo se imagina su empresa con tres o cuatro desarrolladores y no como una gran software factory, porque el agentic engineering lo permite, y contó que trabajando codo a codo con alguien que se sumó esa semana aprendieron cosas que no había pensado, como manejar permisos sobre los datos de los clientes de forma ágil pero revocable. Facundo sostuvo que CEO y CTO tienen que estar al día y hacer igual o más trabajo que los ingenieros, para conocer de primera mano las técnicas que aceleran 5 o 10 veces el trabajo. Agustín coincidió en que el líder tiene que tener siempre las manos en el código, que es muy difícil ser un excelente CTO si no se sabe qué pasa en la trinchera, y dijo que su startup, de cuatro personas, también es un equipo SWAT que quiere mantener así. Más tarde Benjamin, desde su experiencia en Microsoft, sumó que un engineering manager es un multiplicador: quita bloqueos y cuida el entorno para que un equipo de diez rinda diez veces más, y con agentes ese efecto crece todavía más. Benjamin agregó que en una organización gigante como Microsoft, con pirámides y miles de pequeñas empresas internas con su propio presupuesto, hace falta alguien que se ocupe de los números y de la parte humana; en una startup quizás no. Agustín cerró que, se llame como se llame el rol, cuando una empresa crece alguien tiene que asumir esas responsabilidades de reportar y hacer que las cosas pasen, que a la gente más técnica no le interesan tanto.
eventoCafé VirtualAgustín Sánchez abrió el tema con una postura clara: con agentes, los desarrolladores producen muchísimo más y todo eso hay que probarlo, así que para él los QA son más importantes que nunca para chequear lo que desarrollan los agentes. Agustín contó que en su startup, de cuatro personas, dos son QA justamente para probar todo lo que él produce con agentes, una tarea que a él no le gusta tanto pero que a otros sí, y agregó que además el desarrollador tiene que volverse en cierta forma experto en testing y tener gusto por la calidad y por el producto. Agustín le pidió su opinión a Leo Apaza, que trabaja como QA. Leo dijo que depende mucho de la cultura y de las prácticas de cada equipo, y contó su caso en un equipo chico de tres desarrolladores y una persona de producto y negocio. Leo contó que a los QA que le preguntan cómo crecer les aconseja aprender a automatizar, programar y entender código, algo que a él le sirvió para mantenerse al día y acompañar la era agéntica. Según Leo, los desarrolladores con los que trabaja usan todas las herramientas actuales, pero él también: corre los repositorios en su máquina y usa agentes con otra perspectiva y otras skills, con los que encuentra errores funcionales y de seguridad. Leo contó que en un sprint registró unos 20 errores de severidad alta, que podían hacerle perder plata a la empresa; sin agentes calcula que habría encontrado dos o tres, y dejando un agente corriendo dos o tres días detectó cosas que a él se le escapaban, porque bien guiado y con el contexto correcto puede imaginar más escenarios del usuario final, que es el lugar en el que un QA tiene que ponerse. Para Leo el rol inevitablemente tiene que evolucionar hacia lo agéntico y acompañar más de cerca al equipo de desarrollo, y también ve espacio para diferenciarse con habilidades blandas: a veces encuentra tickets con solo un título aunque quien los escribe tiene a Claude al lado. Leo señaló que esos errores se le habían pasado a desarrolladores que también usaban agentes, en un sistema legacy al que cuesta darle contexto y que de a poco están modularizando. Benjamin Cortes contó que nunca trabajó de cerca con QA, que en su experiencia estaban lejos y en otra zona horaria, y que en su producto, después de cada feature, hay agentes que corren evals (evaluaciones automáticas) de las conversaciones de sus agentes de cara al cliente y prueban la web con Playwright, rompen, avisan y arreglan; preguntó qué potencia hoy al QA y por qué el desarrollador no podría ser su propio QA con un agente. Leo respondió que muchas veces es una cuestión de tiempo: los desarrolladores tienen tantas tareas que probar lo propio les da pereza, y a él lo sumaron justamente para detectar antes problemas que se estaban escapando. Leo contó que empezó por los requerimientos, trabajando criterios de aceptación con la persona de negocio, que después de una capacitación en IA pasó a escribir documentos larguísimos con muchos criterios que nadie terminaba de revisar: se probaban dos o cuatro y, si funcionaba, pasaba. Por eso Leo insiste en que la calidad sea una responsabilidad compartida y no algo que se le deja al QA, y en que la feature tiene que cumplir lo que el usuario espera, porque si no, el usuario lo va a encontrar roto. Incluso a Leo le costó leer un reporte de cuatro páginas que le dejó un agente, donde aparecía un error que surgía recién al crear cinco usuarios simultáneos y duplicaba un índice en la base de datos. Fabio Ramos opinó que el criterio del desarrollador no reemplaza al QA, tampoco ahora: es cierto que probar el camino feliz es mucho más fácil, y uno de sus flujos es pedirle a un agente que use el navegador y verifique lo que acaba de implementar, pero un QA tiene el ojo entrenado y otro criterio, mientras que el desarrollador ve algo lindo que funciona y lo da por terminado. Justo en ese momento a Fabio se le acercó un cliente a pedirle cambios en algo que él creía perfecto, y Fabio lo puso como ejemplo de criterio humano: el trabajo del QA en las pruebas internas puede reducirse, pero a nivel producto e interfaz es donde más valor aporta.
eventoCafé VirtualJesús Zelarayan, estudiante de sistemas con dudas parecidas a las de Leandro Andriani, preguntó a quienes trabajan en empresas en qué debería enfocarse para conseguir un primer trabajo como desarrollador junior. Sebastián Soraire destacó las habilidades blandas para entender qué se requiere y comunicarse con el equipo y con gente de afuera, porque muchas veces toca presentar ante la gerencia o los clientes. Leandro Andriani, que está en la misma búsqueda de crecer, dijo que todos los que estudian o recién se reciben tienen la duda de cómo entrar a un mercado que parece necesitar menos desarrolladores, y propuso moverse como antes de la pandemia, de forma local: la ventaja es la cercanía con, por ejemplo, el gimnasio de la vuelta que no tiene nada hecho, al que se le puede llevar una web armada con un prompt y dejarlo maravillado. Leandro también sugirió entrar a una empresa por un puesto básico de sistemas o soporte y crecer desde adentro con curiosidad, preguntando cómo se registra cada cosa y proponiendo mejoras, como hace él metiendo proyectos donde está aunque todavía no exista el puesto; para él, el cara a cara con alguien que necesita una solución es lo más directo. Facundo García Martoni pidió la palabra porque, al estar al frente de una startup en la que acaba de sumar a alguien y piensa contratar más hacia fin de año, ve cosas que desde el otro lado no se ven. Facundo dijo que no busca expertos en JavaScript o Python ni títulos de posgrado, sino gente al día con las nuevas formas de hacer software, con interés genuino en el agentic engineering (desarrollar delegando el trabajo a agentes de IA) y en resolver problemas con las herramientas de hoy en lugar de repetir lo que dice un libro o un curso. Por la misma plata, Facundo dijo que entre un ingeniero muy senior que no sabe ni quiere aprender a desarrollar con agentes y un junior con fundamentos de computación, ganas y curiosidad, elegiría sin dudar al junior. Facundo agregó que hay que elegir en qué tipo de empresa trabajar: las tradicionales, que según él van a tener que evolucionar o van a morir, todavía piden pasar entrevistas de código, practicar LeetCode (problemas de algoritmos usados en entrevistas técnicas), system design y pulir el CV; el otro camino, el de las startups al día, muchos lo ven más difícil, pero a quien le gusta la tecnología y tiene curiosidad le resulta más fácil y tiene todo para ganar. Jesús bromeó con que después de esas declaraciones le iban a llegar muchos CV, y Facundo respondió que son bienvenidos. Sebastián sumó tener el CV y LinkedIn actualizados y personalizados para cada lugar, contando situaciones concretas y el valor que uno aportó en lugar de frases como soy proactivo, porque quien lo lee lo traduce a cuánto gana la empresa incorporándote; un perfil o portfolio descuidado es como un local con la vidriera sucia que nunca cambia. Leandro Andriani volvió más tarde con un consejo para quienes empiezan: si se da la chance de entrar a una empresa antigua o burocrática, no desaprovecharla, sabiendo que ahí a la gente no técnica le interesan los resultados y la plata y hay que hacerse valorar más con habilidades blandas que mostrando productos. Para eso Leandro recomendó un curso gratuito de Google Skills sobre liderazgo en inteligencia artificial, que da un certificado de cursado, y las becas que ofrecen algunas universidades para certificaciones, porque enseñan a hablar con ese tipo de personas y a aplicar la IA en una empresa, y ayudan a destacarse y saltar de puesto. A quienes ya trabajan en startups Leandro les dijo que van por el camino ideal.
eventoCafé VirtualLeandro Contrera contó lo que aprendió en un proyecto que hizo con Gonzalo Morales para una competencia, en el que había mucha contención del cliente, muchas reglas de negocio, feedback constante y coordinación con los equipos de streaming, luces, jueces y organización: eso lo curtió para comunicar ideas complejas en términos simples y le dio respaldo para mostrarse como alguien que propone soluciones y se involucra en el negocio, no como alguien que solo resuelve tickets. Leandro Contrera mencionó otro proyecto para empresas prestamistas, con muchas reglas de negocio e integraciones bancarias y de e-commerce, que lo hizo preguntarse cómo asegurar que los agentes hagan bien las partes críticas, y reconoció que las habilidades blandas no alcanzan solas y hace falta base de backend. Aun así, Leandro Contrera opinó que quien recién empieza no tiene que competir con alguien que lleva cinco años en backend, sino destacarse en otra parte: estar al día con los agentes, involucrarse en el negocio, saber comunicar y mostrar garra para aprender rápido, frente a perfiles técnicos cerrados a los que les cuesta recibir feedback. Leandro Contrera contó que hay procesos que como primer filtro piden contar tres proyectos en producción, y que el consejo que recibió hace tiempo de Agustín Sánchez y de otros miembros fue meterse de cabeza y aprender sobre la marcha, haciendo un producto de punta a punta con clientes reales en vez de esperar a dominar microservicios. Sebastián Soraire agregó que el networking influye mucho: puede cansar, pero a fuerza de ir a eventos y charlar con gente uno va dejando migas de pan, se cruza con las mismas personas y surgen cosas. Sebastián mismo llegó a la comunidad después de ver en su facultad las charlas de spec-driven development (desarrollo guiado por especificaciones escritas antes del código) que dio PCN: charló dos veces con Agustín, le propuso un café para hablar de esos temas y Agustín, con poco tiempo, propuso hacer un evento, que terminó siendo este encuentro. Leo Apaza le contó a Jesús Zelarayan el caso de alguien que, viendo tantas búsquedas de QA de automatización, se especializó unos meses en eso, entró a una empresa en ese puesto, rehízo el pipeline de pruebas y después saltó internamente a desarrollador, ya como semi senior: tenía claro adónde quería llegar y encontró un camino. Leo recomendó probar, conocerse, entender cómo aportar valor en cada empresa o proyecto, practicar entrevistas, incluso frente al espejo respondiendo preguntas como qué es un agente en un minuto, y seguir yendo a entrevistas aun teniendo trabajo para tantear el mercado, un consejo que le dio un profesor. Gonzalo destacó la predisposición de Leandro Contrera en el proyecto que compartieron: quizás no sabía todo técnicamente, pero un día apareció con un documento detallado analizando el problema parte por parte y con las preguntas preparadas, y si surge otro trabajo así sabe que puede contar con él. Gonzalo lo resumió con la frase para hacer primero hay que ser: importan con quién se junta una persona, como en PCN, donde todos tienen la cabeza abierta, sus hábitos, lo que lee y consume, cómo gestiona los problemas y los miedos y hacia dónde quiere llegar, más que ser muy bueno técnicamente, y prefiere trabajar con gente así. Sebastián lo vinculó con soltar el ego para cuestionarse y ver otras perspectivas, y Leandro Contrera le agradeció a Gonzalo por lo que aprendió trabajando con él. Agustín sumó su postura con énfasis: si quieren ser grandes ingenieros mañana, tienen que empezar hoy a ser la persona que merece cierto tipo de oportunidades. Para Agustín, quien no estudia, no hace proyectos, no socializa, no se rodea de gente que sabe más y no comparte lo que aprende tiene antipatrones que hacen que las oportunidades no aparezcan; hay que mirar cómo es la persona que logra esos objetivos, qué hábitos y qué actitud tiene ante los problemas, y trabajar en uno mismo para estar ahí cuando lleguen. Gonzalo completó que cuanto más claro se tiene hacia dónde se quiere ir, más obvio se vuelve qué hábitos incorporar, con quién juntarse y qué consumir, así que vale dedicarle tiempo a conocerse.
eventoCafé VirtualAntes de irse, Sebastián Soraire preguntó qué tecnologías conviene aprender de cara al presente y al futuro. Facundo García Martoni respondió que ninguna en particular: primero los fundamentos de programación y después los métodos para desarrollar, como loop engineering (dejar agentes iterando solos sobre un objetivo), graph engineering y harness (el entorno de herramientas, tests y reglas que rodea al agente), además de los cursos gratuitos de Anthropic para sacarle el jugo a Claude. Leandro Andriani matizó que depende de cuánto sepa cada uno: alguien que recién arranca puede abrumarse yendo directo a eso, y a él, por curioso, cada concepto nuevo lo termina llevando a las bases, sobre todo cuando se cruza con un archivo de código que no entiende. Facundo le recordó que DHH saca features en Rust para Omarchy sin saber Rust, y dijo entender ese miedo a ver algo desconocido; para perderlo recomendó, como ya había compartido en el grupo, la guía rápida de cada lenguaje en learnxinyminutes.com, con la que en tres o cuatro días pasó a hacer code review sobre un sistema escrito en Ruby sin conocer el lenguaje. Según Facundo, lo que más tiempo lleva son los fundamentos que se ven en el primer año de la facultad con algoritmos y estructuras de datos en C, como if, for y while, y algo de paradigmas como la programación orientada a objetos; ir más allá ya no rinde. Leandro Andriani reconoció que todavía tiene incorporada la idea de querer ser experto en algo, que es innegable que la IA hoy le pasa el trapo a todos y que viene cambiando de mentalidad: sigue programando a mano en su tiempo libre, pero lo que tiene que entregar lo hace con IA, y va a probar el recurso para perderle el miedo a otros lenguajes. Leandro Andriani sumó que lo ideal es aprender todo lo relacionado con la IA, sobre todo los loops y qué es un harness, y aprender a escribir skills propias en vez de usar las de otros, para no cargar skills que consumen demasiado o un AGENTS.md de 50.000 tokens sin saber qué tiene. Gonzalo Morales propuso pensar en habilidades más que en tecnologías, porque cualquier obstáculo, técnico, comercial o de carrera, exige aprender algo, y reformuló la pregunta: qué desafío tiene cada uno hoy y qué está intentando mejorar. Leandro Contrera respondió que, como Facundo, prefiere ser flexible y adaptarse a cada proyecto: en uno trabajaron sobre un fork de un sistema existente hecho con Redux y le sirvió practicar a mano qué es una action, un dispatcher y cómo cambia el estado global para entender qué problema resuelve; en otro, que toca datos delicados, necesitaba dominar Postgres, temas como joins o row level security (permisos por fila), que se pueden debatir con un agente o bajar a pseudocódigo hasta entenderlos. Leandro Contrera también compra en la fotocopiadora los apuntes de la carrera de programación, que en tres años compactan lo necesario para salir al mercado e incluso tocan agentes, y repasa principios como código limpio, SOLID, DRY, KISS, refactorización, integración continua y métricas técnicas o monitoreo para saber si un sistema es de calidad: tener ese panorama le parece más valioso que conocer cada detalle de React. Sebastián cerró contando en qué trabaja: mejoras de un e-commerce, donde vio en un evento del sector cómo la IA empieza a recomendar productos y desplaza los resultados orgánicos del SEO, consultando sobre todo Instagram y YouTube; RAGs (sistemas que le dan a la IA información de documentos propios) para trabajar con spec-driven development u OpenCode y su seguridad; y visualizaciones 3D para áreas no técnicas en las que se ve una oficinita con los agentes moviéndose y trabajando, que a Leandro Contrera le recordaron a los Sims. Al despedirse, Agustín Sánchez dijo que la charla estuvo muy buena, que la van a repetir y que el resumen iba a quedar en la web, y Leandro Andriani agradeció a la comunidad porque viene de entornos muy celosos y competitivos y valora encontrar gente que comparte sin miedo su experiencia.
changelogeventosSi un evento se llena, ahora podés sumarte a la lista de espera y ver en qué lugar de la fila estás. Cuando alguien cancela, la primera persona de la lista queda inscripta sola y le llega un email avisándole.
changelogsetupsNueva sección para mostrar dónde programás: subí una foto de tu escritorio con un título y una descripción, y mirá los setups del resto de la comunidad, ordenados por recientes o por los que tienen más me gusta.
changeloguiLa web se puede instalar en el celu o la compu y abre como una app, con accesos directos a eventos, conversaciones, cursos y lectura. Sin conexión muestra una pantalla propia con una trivia de programación y vuelve sola a la página cuando regresa la red.
Nuevo evento para el 2026-10-03. Sumate.
nuevo dev@facmartoniSu primera PR: “Abrir borrador en Google Calendar”. Ya suma 1 PR mergeada.
whatsappMarcelo Nuñez preguntó cómo se hacen las reviews adversariales con agentes. Agustín Sánchez explicó que usa una skill que lanza un agente nuevo para revisar lo que hizo otro, con modelo y reglas definidos por proyecto, a veces dentro de un loop; aclaró que consume la cuota normal de la suscripción y no API, que sería caro, y mencionó CodeRabbit o Greptile como alternativas comerciales. Sobre QA, contó que Claude usa el navegador para probar features; Adrian Gamarra señaló que con herramientas sin navegador, como OpenCode, se puede usar Playwright o el agent browser de Vercel. Agustin Ponce de León verifica con navegador y e2e en Playwright, y está reduciendo tests unitarios porque rara vez detectan algo y, cuando fallan, el agente los modifica para que pasen; Leonel Pérez y Leandro Contrera vieron lo mismo. Agustín defendió los unitarios por ser más rápidos que los e2e y propuso indicar en la skill o el prompt que no se alteren tests indebidamente; Iñaki Fernando Lozano mencionó una skill para limpiar tests de baja calidad.
whatsappFacundo Padilla preguntó si alguien usaba Kapso, un servicio para enviar mensajes por WhatsApp sobre la API oficial, y si habían tenido cuentas bloqueadas. Lucas Juárez contó que lo usa con tres números conectados en modo coexistencia (el mismo número funcionando con la app y con la API) sin problemas de bloqueo. Facundo explicó que lo evaluaba para su empresa por el cambio de costos de la API de WhatsApp previsto para octubre, con un volumen de unos 40.000 mensajes por mes por línea, y que Kapso ofrecía 100.000 mensajes para tres líneas por 25 USD. Lucas agregó que, si no recordaba mal, cada mensaje excedente se cobra alrededor de 0,002 USD. Un miembro de la comunidad preguntó si convenía frente a Evolution API (una API no oficial) por el riesgo de baneo, y Facundo confirmó que sí, justamente por eso.
whatsappFacundo García Martoni anunció que Salvador Juárez se incorporó a su empresa, Macch, como su primer AI Engineer. Contó que lo conoció al escuchar su charla en el último evento de PCN, donde presentó un proyecto de sistema operativo que corre en el navegador, y que después de algunas conversaciones y desafíos técnicos decidió sumarlo. Destacó públicamente que, si no fuera por la comunidad, no lo habría conocido. Leandro Contrera, que también presenció esa charla, valoró que pocas personas se preguntan cómo funcionan los mecanismos internos de un sistema operativo y menos aún implementan uno, lo que demuestra destreza técnica y curiosidad intelectual. Numerosos miembros felicitaron a ambos, y ese mismo día Salvador mergeó su primera PR. El caso quedó como ejemplo concreto de cómo presentar proyectos propios en los eventos de la comunidad puede abrir oportunidades profesionales.
Nuevo evento online para el 2026-10-02. Sumate.
whatsappLeandro Contrera pidió recomendaciones de servicios gratuitos para alojar imágenes en la nube y servirlas por URL en producción, estimando unas 300 imágenes de 2 a 3 MB. Leonel Pérez mencionó almacenamiento de objetos tipo S3 y que servicios como Firebase o Supabase lo usan por detrás, todos con plan gratuito. Martin Uslenghi recomendó Cloudflare R2 por su generoso free tier y porque no cobra egreso de datos. Salvador Juárez y Facundo Padilla usan Cloudinary; Padilla destacó sus 50 GB gratuitos y explicó que lo que cobra es el redimensionamiento de imágenes vía su API, por lo que él hace el resize en su propio backend antes de subirlas, y compartió como referencia el código abierto del sitio de otra comunidad. Jeremias Alvarez aclaró que redimensionar sirve para que todas las imágenes queden con tamaños uniformes, y comentó que Supabase le sirvió para proyectos chicos aunque su límite gratuito es bajo (alrededor de 1 GB). Gonzalo Morales advirtió que al superar el free tier de Cloudinary le bloquearon las imágenes, por lo que se pasó a Supabase Storage sin problemas; Marcelo Nuñez también sugirió Supabase Storage por su CDN.
Aplicación de productividad: podés gestionar tareas, hábitos, proyectos, notas, lecturas, estudio, gimnasio, finanzas y más.
proyectoJuego multi-jugador de carreras de autos optimizado para eventos y juntadas. La carrera se ve en una pantalla y los participantes utilizan su celular como joystick para manejar sus vehículos.
No hay eventos agendados. ver anteriores
