Farox

Hay una idea que atraviesa todo lo que hacemos: ya sea para escribir código, resolver problemas o construir un espacio de trabajo, creemos que las mejores cosas pasan cuando se hacen con otras personas. En Farox estamos distribuidos geográficamente. Nuestras vidas nos fueron llevando a distintos lugares del país y del mundo, y de esa experiencia aprendimos que para sostener un proyecto cooperativo esa distancia no se debe traducir en desconexión. Por eso nos encontramos, para definir estrategias por supuesto, pero también para seguir creando juntos, para compartir ideas, proyectos personales, novedades de nuestras vidas y seguir consolidando las bases de nuestra cooperativa sobre las historias de personas reales. Siempre decimos que cooperar es mejor que competir y no se trata de un slogan o una simple convicción, es el pilar sobre el que venimos desarrollando nuestro propio sistema de trabajo desde hace más de 13 años. Un nuevo encuentro que nos deja nuevos desafíos y nos abre nuevos horizontes. #Farox #Cooperar #Encuentro #DesarrolloDeSoftware #Consultoría #Equipo

Meter Notion, Slack o Zendesk en una organización parece una buena decisión.   Muchas veces no lo es. Hablemos de la integración de SaaS. Un SaaS (Software as Service) es básicamente software que se alquila como servicio en lugar de desarrollarse internamente. Resuelve rápido. La infraestructura ya existe. No hace falta desarrollar nada. Sólo pagar. Y muchas veces eso funciona. El problema aparece cuando el sistema empieza a depender completamente de herramientas externas para procesos que se vuelven críticos. Porque en muchos casos las organizaciones terminan: ➤ Usando apenas una parte mínima de las funcionalidades ➤ Adaptando sus procesos internos a la lógica del SaaS ➤ Acumulando integraciones difíciles de sostener ➤ Pagando todos los meses por capacidades que nunca terminan de controlar realmente Pasa mucho, por ejemplo, con Notion, Slack o Zendesk: equipos que adoptan una herramienta para resolver un problema específico terminan gestionando procesos enteros dentro de la plataforma, aunque muchas veces usan apenas una pequeña parte de todo lo que la herramienta ofrece. El costo económico y la dependencia técnica, operativa y estratégica se está acelerando con la explosión de las herramientas de IA. La pregunta no es solamente qué herramientas usar, sino cuánto de la infraestructura crítica conviene seguir delegando y qué capacidades empieza a tener sentido desarrollar dentro de los propios sistemas de una organización. No necesariamente para construir todo desde cero. Sino para reducir dependencia, ordenar procesos y desarrollar soluciones que realmente respondan a las necesidades del equipo y del negocio. En Farox trabajamos acompañando a organizaciones en ese proceso: entender qué conviene integrar, qué conviene construir y cómo sostenerlo en el tiempo. #SoftwareArchitecture #IA #SaaS #Infraestructura #ArquitecturaDeSoftware #Farox

Hay personas que trabajan sobre sistemas. Y hay personas que entienden cómo esos sistemas reaccionan cuando empiezan a crecer. Agustin Recouso trabaja hace más de 13 años en soluciones de software, procesando datos, y construyendo sistemas backend de alto rendimiento. Python, Rust, Spark, AWS, machine learning, tiempo real, procesamiento de datos. Pero lo interesante no es solamente la tecnología, es la forma de pensar los problemas. Entender qué información importa, cómo fluye, qué decisiones permite tomar y cómo sostener sistemas que tienen que seguir funcionando mientras todo cambia alrededor. En Farox, Agustin trabaja principalmente sobre proyectos vinculados a data engineering, analítica y sistemas escalables, integrando criterio técnico con una mirada muy fuerte sobre arquitectura y sostenibilidad. Estos son algunos de sus proyectos ➤ https://lnkd.in/ew8qNnmU   ➤ https://lnkd.in/ea9kiDkD Cada vez más equipos necesitan perfiles capaces de integrarse rápido, entender sistemas complejos y tomar decisiones técnicas con impacto real. #DataEngineering #BackendDevelopment #Python #Rust #MachineLearning #ArquitecturaDeSoftware #Farox

El Vibe Coding funciona Hasta que el proyecto empieza a crecer. El Vibe Coding está permitiendo que muchas personas construyan cosas que antes parecían imposibles. Baja barreras, acelera ideas y abre nuevas posibilidades para equipos, emprendedores y organizaciones. El problema aparece después. Cuando el proyecto empieza a crecer y ya no está del todo claro qué se construyó, cómo funciona realmente el sistema o qué puede romperse cuando alguien cambia algo. El prototipo funciona pero mantenerlo, escalarlo o integrarlo se vuelve cada vez más difícil. Porque generar código no es lo mismo que construir software sostenible. Ahí es donde empieza a importar la arquitectura y las decisiones técnicas que permiten entender y sostener el sistema completo. En Farox solemos integrarnos al proceso en ese momento. Muchas veces el problema no es arrancar, sino entender cómo seguir construyendo sobre lo que ya existe para que una idea se convierta en un producto que pueda sostenerse en el tiempo. 🟣 Si estás en ese punto, hablemos. #VibeCoding #SoftwareDevelopment #ArquitecturaDeSoftware #IA #ProductDevelopment #Farox

Hace unos días publicamos una nota sobre deuda técnica. Pero hay otro tipo de deuda que empieza a aparecer cada vez más en equipos que trabajan con IA generativa: la deuda cognitiva. Y probablemente sea bastante más difícil de medir. Uno de los problemas más interesantes que empiezan a aparecer con el uso intensivo de LLMs no tiene que ver con reemplazar trabajo humano, sino con reemplazar demasiado temprano el proceso de exploración intelectual que lleva a encontrar soluciones nuevas. Porque existe una diferencia enorme entre: resolver un problema y explicarle a un sistema qué problema necesitás resolver. Pueden parecer equivalentes, pero cognitivamente no lo son. En muchos workflows actuales, los modelos empiezan a intervenir en reemplazo de una comprensión profunda del problema, de que aparezcan hipótesis propias, de la exploración inicial. Y eso comienza a modificar la forma en que pensamos. No solo cómo producimos. Algunos estudios recientes empiezan a mostrar señales interesantes en esa dirección: ➤ Menor persistencia frente a problemas cuando desaparece la asistencia de IA ➤ Menor diversidad conceptual ➤ Menor sensación de ownership sobre las ideas ➤ Menor profundidad de procesamiento cognitivo ➤ Tendencia a converger rápidamente sobre soluciones plausibles pero superficiales El riesgo no parece ser solamente “automatizar tareas”, sino optimizar tanto la velocidad de respuesta que terminemos reduciendo el espacio necesario para que aparezca el pensamiento original. Paradójicamente, una de las discusiones más importantes alrededor de AI tooling quizás no sea qué tan inteligentes son los modelos, sino cómo diseñamos su integración en procesos creativos, técnicos y organizacionales sin reemplazar completamente el esfuerzo cognitivo que produce comprensión real. Especialmente en trabajos donde el diferencial no es ejecutar una solución conocida, sino encontrar una solución que todavía no existe. Dos papers interesantes sobre esto: 🟣“AI Assistance Reduces Persistence and Hurts Independent Performance”  https://lnkd.in/eTVjycJw 🟣“Your Brain on ChatGPT: Accumulation of Cognitive Debt” https://lnkd.in/gyywrcdc ¿Dónde sienten que la IA amplifica el pensamiento y dónde empieza a reemplazarlo demasiado temprano? #InteligenciaArtificial #DeudaCognitiva #CognitiveDebt #PensamientoCritico #Aprendizaje #Farox

OSAI: tooling para integrar IA con tecnologías libres en entornos productivos Trabajar con modelos libres en producción sigue teniendo más fricción de la necesaria. Elegir un modelo adecuado suele ser la primera apuesta. ¿Cómo defino su eficacia respecto a las tareas que necesito realizar? ¿Qué trade-offs tiene frente a  los modelos cerrados de las big tech? ¿Cómo hago para utilizarlo dentro de una infraestructura libre lo suficientemente confiable para un entorno productivo? Ahí es donde hoy sigue existiendo una de las principales barreras para adoptar IA libre en empresas. 🟣 OSAI es una herramienta libre que desarrollamos junto a Patio Network después de una reunión inicial con el CTO de Mozilla y varias reuniones internas posteriores de co creación junto con ingenieros de cooperativas de Bulgaria, Estados Unidos y Argentina. ⚡️ La idea es simple: Abrís una terminal en tu proyecto y corrés: npx osaikit --repo OSAI analiza tu stack para generar: ➤ Recomendaciones de tecnologías abiertas de IA compatibles con tu stack ➤ Orientación sobre licencias ➤ Sugerencias de integración ➤ Comandos de setup ➤ Un enterprise-readiness score orientativo para evaluar qué tan preparado está ese entorno para trabajar con los modelos libres disponibles Si estás experimentando con inferencia local, modelos open-weight o alternativas a vendors cerrados, nos interesa mucho escuchar tu feedback. Repo: https://lnkd.in/eU_xqFDX

OSAI: tooling para integrar IA con tecnologías libres en entornos productivos Trabajar con modelos libres en producción sigue teniendo más fricción de la necesaria. Elegir un modelo adecuado suele ser la primera apuesta. ¿Cómo defino su eficacia respecto a las tareas que necesito realizar? ¿Qué trade-offs tiene frente a  los modelos cerrados de las big tech? ¿Cómo hago para utilizarlo dentro de una infraestructura libre lo suficientemente confiable para un entorno productivo? Ahí es donde hoy sigue existiendo una de las principales barreras para adoptar IA libre en empresas. 🟣 OSAI es una herramienta libre que desarrollamos junto a Patio Network después de una reunión inicial con el CTO de Mozilla y varias reuniones internas posteriores de co creación junto con ingenieros de cooperativas de Bulgaria, Estados Unidos y Argentina. ⚡️ La idea es simple: Abrís una terminal en tu proyecto y corrés: npx osaikit --repo OSAI analiza tu stack para generar: ➤ Recomendaciones de tecnologías abiertas de IA compatibles con tu stack ➤ Orientación sobre licencias ➤ Sugerencias de integración ➤ Comandos de setup ➤ Un enterprise-readiness score orientativo para evaluar qué tan preparado está ese entorno para trabajar con los modelos libres disponibles Si estás experimentando con inferencia local, modelos open-weight o alternativas a vendors cerrados, nos interesa mucho escuchar tu feedback. Repo: https://lnkd.in/eU_xqFDX

¿Qué es la deuda técnica?  Y por qué, en muchos equipos, termina siendo un problema incómodo. No suele aparecer como un error. Aparece de otra forma: Cambios que tardan más. Partes del sistema que nadie quiere tocar. Decisiones que se empiezan a postergar. El sistema sigue funcionando. Pero cada vez cuesta más sostenerlo. En nuestro blog, Jonathan Cavia, escribió sobre este tema: https://lnkd.in/eQSVx9fH Qué es realmente la deuda técnica, cómo se acumula y en qué momento deja de ser un problema técnico para pasar a afectar al negocio. #SoftwareDevelopment #TechDebt #SoftwareArchitecture #Engineering #Farox

OSAI: una herramienta para identificar qué modelos de IA abierta son realmente compatibles con tu proyecto Hace algunos meses participamos con Patio Network de una reunión junto al CTO de Mozilla, Raffi Krikorian, donde apareció un diagnóstico que resonó mucho con problemas que veníamos viendo hace tiempo: el ecosistema de IA abierta está creciendo muy rápido, con modelos cada vez más potentes, lo que hace cada vez más difícil decidir cuál implementar. ➤ Licencias difíciles de comparar ➤ Infraestructura fragmentada ➤ Poca claridad sobre qué herramientas están realmente preparadas para producción De esa discusión nació OSAI, una herramienta de software libre que analiza un repositorio y ayuda a identificar qué modelos abiertos pueden integrarse mejor según el stack y las necesidades del proyecto. Entre otras cosas, OSAI entrega: ➤ Recomendaciones de modelos ➤ Información de compatibilidad ➤ Setup inicial ➤ Ejemplos de integración ➤ Señales iniciales para evaluar readiness en entornos enterprise 🟣 La idea no es sumar “otro modelo más” al ecosistema, sino ayudar a que la IA basada en tecnologías abiertas pueda ser más fácil de adoptar, mantener y gobernar en proyectos reales. Podés probarlo acá: https://lnkd.in/eU_xqFDX

No todos los problemas se resuelven sumando herramientas. Algunos necesitan ser pensados desde el inicio. En Farox trabajamos en Desarrollo de Producto, acompañando todo el proceso: desde la definición del problema hasta la implementación de la solución. No se trata solo de escribir código. Se trata de tomar decisiones técnicas que tengan sentido para el negocio, ordenar los flujos de trabajo y construir soluciones que puedan sostenerse en el tiempo. 🟣 Trabajamos sobre: ➤ Definición técnica de producto ➤ Arquitectura y diseño de sistemas ➤ Desarrollo e implementación ➤ Optimización de procesos y flujos ➤ Coordinación con equipos internos Construimos soluciones que responden a problemas reales. Porque un producto no es solo lo que hace, es cómo se piensa, cómo se construye y cómo evoluciona. 👉 En nuestra web te contamos cómo abordamos este tipo de desafíos: https://lnkd.in/e623yqsP #DesarrolloDeProducto #ArquitecturaDeSoftware #EstrategiaTécnica #ProductDevelopment #Farox