Hay una escena que cualquier developer conoce de memoria. Una empresa lanza una herramienta impecable, con presupuesto, equipo y buena intención, y aun así los desarrolladores no la adoptan. Al mismo tiempo, un proyecto que arranca como un repositorio personal termina en el stack de medio mundo, empujado solo por una comunidad que lo prueba, lo recomienda y le da soporte gratis en un issue de GitHub a las tres de la mañana.
Esa tensión entre producto y adopción tiene un nombre que todavía suena raro para bastante gente: developer relations, o simplemente devrel. Darío Macchi, developer advocate en Howdy, lo explicó como invitado del podcast Dynamic Devs, y vale la pena desarmar esa charla porque toca algo que cualquier developer senior termina viviendo tarde o temprano: por qué usamos las herramientas que usamos.
Un paraguas con varios roles debajo
Darío lleva más de 25 años en la industria, y hace tres años y medio empezó a construir este rol dentro de Howdy, donde ya trabajaba desde antes. Developer relations, según lo describe, es un paraguas que engloba distintas posiciones. Está el developer advocate, que se para del lado del desarrollador y usa el producto desde ahí. Y está el evangelist, un rol más cercano al marketing tradicional que tuvo su auge entre 2010 y 2015 y hoy quedó bastante en desuso.
La diferencia, en el fondo, es de qué lado de la mesa te sientas. Un advocate defiende al desarrollador frente a la empresa. Un evangelist defiende al producto frente al desarrollador.
El feedback incómodo también se transmite
Lo más interesante de la charla es cómo Darío describe la parte menos vistosa del rol: recibir quejas, filtrarlas y llevarlas de vuelta a la empresa sin maquillarlas. Si un desarrollador le plantea un problema real, no puede jugar a dos puntas: prometer que algo se va a solucionar y después no comunicarlo, o comunicarlo tibio. La confianza del desarrollador es la única moneda que tiene, y perderla significa perder también la información honesta que necesita para hacer bien su trabajo.
Esa honestidad, más que cualquier técnica de comunicación, es lo que separa el devrel bien hecho del marketing disfrazado de conversación entre pares.
Cómo se elige una herramienta (y por qué la calidad técnica no alcanza)
Darío marcó una diferencia clara entre dos mundos. En el software tradicional, elegir una herramienta pasa por señales concretas: documentación sólida, ejemplos claros, actividad real en el repositorio, issues que se responden. Si el último commit fue hace un año y nadie contesta si el proyecto sigue vivo, esa señal pesa más que cualquier feature nueva.
En las herramientas de IA la lógica cambia. La industria todavía no logra estabilizar patrones de trabajo (nada parecido al catálogo de patrones de diseño que se armó estudiando proyectos Java hace dos décadas), así que las comunidades terminan formando tribus alrededor de metodologías propias, cada una validando su forma de usar una herramienta que cambia demasiado rápido como para consolidarse.
Un detalle que Darío subraya: los desarrolladores confían más en herramientas con una cara humana detrás. Alguien real y visible, no solo un equipo técnico anónimo.
Los fundamentos, no la velocidad
Sobre el impacto de la IA en el trabajo del developer, Darío fue directo: no está reemplazando a nadie, y lo vive todos los días trabajando con sus propios agentes. Lo que sí cambia es qué separa a quien saca ventaja real de la IA de quien solo sigue el ritmo del resto, y ahí la respuesta no tiene nada de exótico: los fundamentos de ingeniería de software.
Puso un ejemplo concreto. Generar código nuevo con IA es rápido y barato, casi al punto de tentarte a no revisarlo. La pregunta que importa entonces no es cuánto código generas, sino cómo te aseguras de que cada cambio no rompa lo que ya funcionaba. Y ahí la solución no es nueva: automatizar pruebas funcionales con especificaciones claras, algo que hace 30 o 40 años era carísimo de mantener y que hoy, con specs mucho más accesibles, se volvió una práctica barata de aplicar.
Un rol que se construye con años, no con un curso
Sobre qué hace falta para trabajar en devrel, Darío fue honesto: no alcanza con ganas. Hacen falta años de experiencia real en la industria, conocimiento técnico del producto o del rubro donde vas a pararte, y una parte más difícil de entrenar: la voluntad de exponerte en público, sostener una postura y bancarte la reacción cuando algo no cae bien.
Sobre cómo convencer a una empresa de invertir en esto, admitió lo más difícil: traducir el esfuerzo a números. Contó el caso de alguien que conoció en un evento hace un año y medio y recién ahora se postuló a una posición, después de varios puntos de contacto en el medio. El devrel bien hecho casi nunca se mide en el trimestre en el que ocurre.
Por fuera del stack
Fuera del podcast, de las conferencias y del feedback, Darío tiene una colección de bonsáis nativos de Uruguay y una biblioteca de libros de botánica de hace un siglo, que va rastreando en librerías de usados. Un detalle que, sin proponérselo, resume bastante bien de qué se trata este trabajo: cultivar algo despacio, con cuidado, sabiendo que el resultado recién se ve con el tiempo.
