Jeremy Freeman, Co-Fundador y CTO de Allstacks – Serie de Entrevistas

Jeremy Freeman, Co-Fundador y CTO de Allstacks, es un ingeniero de software, arquitecto de tecnología y empresario con una carrera que abarca el desarrollo de software, la ingeniería de hardware, el aprendizaje automático y la innovación de productos. Desde que co-fundó Allstacks en 2017, ha liderado la arquitectura y el desarrollo de la plataforma central de la empresa, ayudando a transformar la gestión de la entrega de software a través de análisis predictivos y pronósticos impulsados por inteligencia artificial. Antes de Allstacks, Freeman ocupó puestos de liderazgo en Ravioli Labs y CertiRx, donde trabajó en ingeniería de software, investigación, tecnologías anti-falsificación y desarrollo de productos. Al comienzo de su carrera, ganó experiencia en startups, empresas de tecnología y academia, incluyendo la enseñanza de desarrollo web en Wake Technical Community College. Su experiencia técnica abarca sistemas embebidos, diseño de hardware, plataformas de software a gran escala, aprendizaje automático y liderazgo de ingeniería, lo que le da una perspectiva única sobre la creación de productos impulsados por datos que ayudan a las organizaciones a mejorar los resultados de la entrega de software.

Allstacks es una plataforma de inteligencia de ingeniería de software y gestión de flujo de valor que ayuda a las organizaciones a mejorar la previsibilidad y la eficiencia del desarrollo de software. La plataforma integra datos de las herramientas utilizadas en todo el ciclo de vida del desarrollo de software, incluyendo sistemas de gestión de proyectos, control de código fuente y sistemas de implementación, y luego aplica inteligencia artificial y aprendizaje automático para identificar riesgos, predecir resultados de entrega y proporcionar información valiosa. Al proporcionar a los líderes de ingeniería y productos una visión clara de la salud del proyecto, el rendimiento del equipo y las tendencias de desarrollo, Allstacks permite a las organizaciones tomar decisiones más informadas, reducir la incertidumbre de la entrega y alinear mejor los esfuerzos de ingeniería con los objetivos comerciales. Su tecnología está diseñada para ayudar a las empresas a ir más allá de la planificación basada en la intuición al aprovechar los datos operativos en tiempo real para mejorar el rendimiento de la entrega de software y la ejecución estratégica.

Ha tenido un viaje único desde liderar equipos de investigación e ingeniería que aplican aprendizaje automático a datos de desarrollo de software hasta co-fundar Allstacks en 2017. ¿Qué brechas o problemas recurrentes observó que finalmente lo llevaron a construir la empresa?

Cuando empezamos Allstacks, pasamos mucho tiempo al principio haciendo descubrimiento de clientes, y el patrón que surgió fue consistente: empresa tras empresa tenían enormes cantidades de datos y aún no tenían idea de lo que realmente estaba sucediendo. La entrega de software era impredecible a pesar de tener a algunas de las personas más inteligentes en la sala. Ese problema no se había resuelto.

Lo que se hizo evidente bastante rápido fue que esto no era un problema de informes ni de integración. Era un problema de relación. Para saber si algo está en riesgo, necesitas saber cómo un elemento de trabajo se conecta a una rama, la rama se conecta a una solicitud de extracción, la solicitud de extracción se conecta a un objetivo de sprint y el objetivo de sprint se conecta a una iniciativa empresarial. Ese gráfico no existe por defecto en ninguna parte de la cadena de herramientas estándar. Tienes que construirlo. Y construirlo bien es fundamentalmente un problema de inferencia, lo que es donde se vuelve útil el fondo en aprendizaje automático.

Nuestro objetivo desde el principio no fue hacer que un desarrollador individual fuera más rápido en la característica X. Fue hacer que toda la organización fuera mejor. ¿Cómo alineas el esfuerzo de ingeniería con los resultados comerciales? ¿Cómo haces que la ingeniería sirva genuinamente al negocio en lugar de simplemente existir junto a él? Necesitas una mejor comprensión de las relaciones de datos para responder a esas preguntas. Son esas preguntas las que han impulsado casi todas las decisiones de producto que hemos tomado.

Allstacks se centra en analizar datos en todo el ciclo de vida del desarrollo de software. ¿Qué tipos de señales o patrones son más predictivos cuando se trata de identificar el riesgo de entrega temprano?

No creo que haya un conjunto único de métricas que prediga lo bueno y lo malo, sino más bien patrones para diferentes fases y tipos de organizaciones. Lo que he encontrado más útil es reconocer que las organizaciones de ingeniería pasan por temporadas de mejora. Este mes, es el rendimiento de la base de datos. El próximo mes, es la comunicación entre equipos. Luego es “¿por qué no podemos cerrar ninguna solicitud de extracción?” Luego es la observabilidad. Como líder de ingeniería, estás nadando en señales: algunas diagnósticas, algunas de monitoreo y muchas que son simplemente ruido.

Lo que ayuda es empezar con el problema que realmente estás viendo, no con una métrica que quieras mejorar. Si estás preguntando “¿por qué se siente como si estuviéramos entregando menos que el año pasado”, esa es la buena punto de partida. Desde allí, creo que necesitas tres tipos de métricas: primero, ¿cómo sabes que el problema es real (quizás el recuento de solicitudes de extracción por desarrollador con el tiempo); segundo, ¿qué cambios estás haciendo y cómo los estás rastreando en el camino (digamos, la adopción de un revisor de solicitudes de extracción de inteligencia artificial si esa es tu intervención); y tercero, ¿cuán significativo es este problema para el negocio. Tu instinto puede ser correcto de que estás enviando un 20 por ciento menos de código, pero la historia real puede ser que la QA ahora lleva tres veces más. Necesitas los tres lentes para saber si estás resolviendo lo correcto.

Ha trabajado en industrias como la atención médica, la energía y la tecnología. ¿Cómo difieren los desafíos en la entrega de software en estos sectores, y cómo ha moldeado la plataforma de Allstacks?

Realmente valoro mi experiencia en sectores no puramente tecnológicos. En las empresas de software como servicio, es fácil perderse en la idea de que el software en sí es el objetivo. Cuando estás en un negocio donde no estás vendiendo directamente el software, tu papel se vuelve mucho más claro: la tecnología está allí para apoyar al negocio. A menudo bromeo que si el negocio pudiera lograr todo al mismo ritmo sin tener que lidiar conmigo, lo elegirían sin parpadear.

Esa perspectiva es en realidad útil. Pone en contexto lo que todos estamos haciendo en esta industria, y pone muchos debates tecnológicos de vuelta en su lugar. El negocio no se preocupa por si usas Python o Go. Gastar ciclos en esa reescritura probablemente no es donde está el retorno real.

Lo que permanece constante en todas las industrias, sin embargo, es el problema de fragmentación. Independientemente del sector, cada organización de ingeniería tiene datos dispersos en una docena de herramientas con tejido conectivo limitado entre ellas. Los detalles varían: las industrias reguladas tienen ciclos de planificación más largos y una menor tolerancia a la ambigüedad en los requisitos porque el costo de construir lo incorrecto es más alto. Las tiendas de tecnología de alta velocidad acumulan deuda oculta más rápido. Pero el modo de fallo fundamental es el mismo. Los equipos pueden decirte qué se envió. No pueden rastrear por qué algo se deslizó, cuánto costó o dónde el riesgo era visible antes de convertirse en un problema. Es eso lo que ha moldeado cómo construimos la plataforma.

Hay una narrativa creciente de que la inteligencia artificial está acelerando la codificación en sí mientras expone debilidades en otros lugares. ¿Por qué los requisitos, la planificación y la preparación de especificaciones están convirtiéndose en los verdaderos cuellos de botella?

Estamos viendo esto a diario. Con un buen agente y un sólido arnés alrededor de él, puedes moverte desde una idea, a veces directamente desde la boca de un cliente, hasta la producción en literalmente horas.

Parte de lo que hace que ese cambio sea tan significativo es el cambio en el bucle de retroalimentación. Con herramientas de estilo copiloto, el humano está en el bucle en cada sugerencia. El agente ofrece una finalización; lo aceptas o rechazas inmediatamente. Cuando está mal, lo detectas rápidamente. El radio de explosión de una mala sugerencia es una línea de código. La codificación agente funciona de manera diferente: le das al agente un objetivo, descompone el trabajo, ejecuta un plan de múltiples pasos y entrega un módulo de trabajo. El humano revisa la salida, no cada paso. Cuando la especificación es incorrecta, el agente construye toda la implementación hasta la especificación incorrecta y lo descubres en la revisión.

Eso suena como un beneficio puro hasta que reconoces qué estaba haciendo realmente el tiempo de retardo anterior. El retraso servía un propósito real. Múltiples rondas de personas inteligentes revisando, planeando, probando y trabajando a través de ideas para producir un mejor sistema.

La tentación ahora es vibrar algo y omitir todo eso. Pero los agentes y los arneses no están listos para el ciclo de vida de desarrollo de software completo todavía. La velocidad es real. La puerta de calidad que solía ocurrir en todos esos pasos más lentos no ha sido reemplazada. Esa es la brecha.

Muchas organizaciones todavía miden la productividad utilizando métricas obsoletas. ¿Qué es lo que los líderes están entendiendo fundamentalmente mal sobre la productividad en un entorno de desarrollo impulsado por inteligencia artificial?

La gente ha madurado considerablemente sobre este tema desde que empezamos Allstacks. La medición ha avanzado hacia cosas que realmente importan, y los marcos se han vuelto más sofisticados. La inteligencia artificial lo revoluciona todo.

El desarrollo de software tradicional estaba fundamentalmente limitado por la velocidad a la que un desarrollador podía escribir código que cumpliera con los requisitos del negocio y la tecnología subyacente. Ese costo se acerca a cero. Lo que nos estamos acercando es algo más cercano a un desarrollador individual como gerente de agentes. Ese modelo requiere un enfoque completamente diferente para medir la productividad, uno que se basa en algo más que tokens generados o horas de desarrollador gastadas.

Parte del peligro con las métricas actuales es que ocultan lo que realmente está sucediendo a nivel de equipo. Los ingenieros senior con herramientas de inteligencia artificial están compounding su ventaja: tienen el contexto de la base de código y el juicio para dirigir la salida del agente y detectar sus fallos. Los ingenieros de carrera temprana a menudo generan el mismo volumen de código pero pasan más tiempo auditando la salida que no pueden evaluar completamente. La velocidad agregada parece bien, quizás incluso mejorada. La brecha entre esos dos grupos no se muestra en ningún lugar de un panel de instrumentos estándar. La pregunta correcta para empezar a hacer es no “¿cuánto más rápido vamos” sino “¿cuánto de lo que enviamos fue correcto desde el principio”.

No tenemos un consenso de la industria sobre el modelo de medición correcto todavía, pero los equipos que comienzan a rastrear la calidad de la salida y la tasa de rework, no solo la producción y la adopción, estarán mejor posicionados que los equipos que esperan a que alguien más lo figure out.

Su plataforma conecta datos de herramientas como sistemas de gestión de proyectos y repositorios de código. ¿Cuán importante es unificar estas fuentes de datos fragmentadas, y qué sucede cuando las organizaciones no lo hacen?

Allstacks ha tenido éxito en este espacio porque hemos estado construyendo gráficos de contexto desde antes de que eso fuera un término. Reconocimos temprano que conectar todos los datos juntos era necesario para responder a las preguntas que los clientes realmente estaban haciendo.

Cuando esa conexión no existe, la inteligencia artificial que opera en tus datos de ingeniería solo puede ver parte de la imagen. Puede analizar lo que está en tu sistema de gestión de proyectos. Puede analizar lo que está en tu repositorio de código. Lo que no puede hacer es rastrear un retraso en la entrega hasta una dependencia bloqueada en tres herramientas, porque la relación entre esas señales no existe en la capa de datos. Obtienes un análisis superficial como máximo, y recomendaciones confiadas y equivocadas en el peor de los casos. La calidad del modelo no soluciona esto. Puedes poner el modelo más capaz disponible sobre integraciones de API brutos y aún así perder la causa real del problema porque los datos no codifican la relación entre las señales. Basura dentro, basura fuera, independientemente de lo inteligente que sea el modelo.

Esa conexión es la base. Es lo que nos permitió ser los primeros en llegar al mercado con capacidades que aún no han sido replicadas.

¿Cómo se ve un equipo de ingeniería bien preparado en comparación con uno que no está listo a medida que los agentes de inteligencia artificial se integran más en los flujos de trabajo de desarrollo?

Irónicamente, no es muy diferente a estar preparado para traer a un grupo de internos de verano. Necesitas suites de pruebas automatizadas sólidas, documentación sólida, una tubería de CI/CD madura y los guardrails que pondrías en su lugar cuando estás agregando a un desarrollador de confianza pero no capacitado al equipo.

Lo que también es importante, y la gente tiende a subestimar, es regresar regularmente a revisar los básicos: tus reglas de agente, tus archivos AGENTS.MD. Puedes hacer un buen primer paso, pero es fácil caer en un ritmo de envío en la nueva forma y olvidar que puedes entrenar lejos muchos defaults malos. Cosas como enseñar al agente a ejecutar pruebas antes de cada confirmación no deberían requerir un recordatorio humano cada vez.

Una pregunta de diagnóstico que pondría a cualquier líder de ingeniería: ¿puedes decirme qué produjeron tus agentes en el último sprint, qué salida se aceptó tal como estaba versus revisada, y dónde se concentró el esfuerzo de revisión? Si puedes responder eso, tienes la instrumentación para mejorar. Si no puedes, estás volando por instinto.

Ha enfatizado la importancia de alinear el trabajo de ingeniería con los resultados comerciales. ¿Cómo pueden las organizaciones tender ese puente de manera práctica y medible?

He visto dos modos de fallo principales. El primero es las empresas que no emparejan a los equipos de ingeniería con productos. Muchas estructuras de equipo son legado y han estado en su lugar durante mucho tiempo. Un equipo puede poseer una parte de tres productos diferentes mientras que otro posee cuatro enteros. La inversión en ingeniería se reduce en gran medida a contar cabezas, y cuando los equipos no están alineados con los productos, se vuelve muy difícil ver dónde las expectativas comerciales divergen de la realidad.

El segundo modo de fallo es no contabilizar todo el trabajo que va en la construcción y el mantenimiento de software. Hay una gran categoría de trabajo de ingeniería invisible para el negocio. Mi ejemplo favorito es mantener los paquetes actualizados. Los líderes comerciales no técnicos a menudo luchan por entender el valor o por qué es continuo y impredecible. Pero pueden entender categorías de inversión. Si lo enmarcas como “mejoras de seguridad críticas” y muestras en promedio cuánta capacidad consume, estás hablando un lenguaje con el que pueden trabajar.

Si le pides a un líder de ventas que elija entre algunas actualizaciones de paquetes npm y la característica que necesita para cerrar un trato, la característica gana cada vez. Pero si lo enmarcas como “nos salimos de la conformidad con SOC o enviamos esta característica”, ahora les estás mostrando dos compensaciones que pueden evaluar realmente. Esa reencuadernación es el juego completo. Hemos visto a los clientes reducir su tiempo de informe de capitalización de I+D en más de dos tercios solo haciendo que la clasificación de trabajo sea automática en lugar de manual. El mecanismo es el mismo ya sea que el objetivo sea informes de capitalización, justificación de personal, o demostrar el retorno de la inversión en inteligencia artificial: los datos conectados reemplazan las hojas de cálculo correlacionadas.

Dado su trasfondo en ingeniería práctica y enseñanza de desarrollo web, ¿cómo ve el papel de los desarrolladores evolucionando a medida que la inteligencia artificial asume más de la carga de codificación?

Francamente, estoy un poco preocupado, aunque confío en que las personas inteligentes lo resolverán.

Mis preocupaciones son reales. Los graduados recientes pronto entrarán en la fuerza laboral sin haber codificado en un mundo sin agentes de codificación. ¿La educación ha alcanzado a eso? Las herramientas se mueven rápidamente; la educación superior no siempre se mueve junto a ellas. El otro cambio que estoy observando es el desdibujamiento de los ingenieros senior y los productores senior. Los practicantes más exitosos en el nuevo modelo son ingenieros que están profundamente invertidos en el pensamiento de producto.

Lo que se vuelve más valioso es el juicio: la capacidad de definir un problema con precisión suficiente para que un agente lo resuelva, evaluar si la solución es correcta y detectar los fallos sutiles que pasan la CI pero crean problemas arquitectónicos más tarde. Los ingenieros senior compounding su ventaja porque pueden dirigir la salida del agente y saber qué salidas confiar. La preocupación es por la trayectoria de carrera temprana. La forma tradicional de construir ese juicio era escribir mucho código y aprender de los errores. Ese bucle de retroalimentación está cambiando de maneras que la industria aún no ha trabajado completamente.

Eso dicho, la historia ofrece algo de tranquilidad. Hubo un contingente significativo de personas que creían que los compiladores pondrían a los desarrolladores de ensamblaje fuera de trabajo. El cambio tecnológico sucedió como lo predijeron. ¿Qué les sucedió a los desarrolladores que no siguieron el mismo guión? En la década siguiente, el número total de desarrolladores creció. Muchos de esos programadores de ensamblaje aprendieron un nuevo lenguaje y sobresalieron debido a su conocimiento fundamental. Creo que una versión de ese patrón se reproduce de nuevo.

Mirando hacia adelante, ¿cómo ve la inteligencia artificial cambiando el ciclo de vida del desarrollo de software en los próximos tres a cinco años, y dónde las empresas ganarán la mayor ventaja competitiva?

Vamos a ver una carrera de armamento de características sin precedentes. A medida que el costo de construir se acerca a cero, las empresas, incluso las grandes, enfrentan una nueva restricción: recopilar y validar suficiente retroalimentación del cliente para seguir construyendo cosas de calidad a escala.

El cambio que tiene que ocurrir es que la barra para lo que se construye necesita subir. La restricción actual en la mayoría de las organizaciones de ingeniería es simple: cinco prioridades principales, quizás dos entregadas. Con los agentes, la proporción se invierte. Puedes tener cinco principales, diez siguientes y veinte quizás en la lista, y enviar cien. La pregunta que nadie ha respondido completamente todavía es cómo mantener que los últimos sesenta y cinco no sean concebidos y ejecutados deficientemente.

Dos cosas de las que estoy bastante seguro para la ventana de tres a cinco años. Primero, la ventaja competitiva en la ingeniería de inteligencia artificial provendrá de la profundidad y amplitud del contexto, no de la calidad del modelo. Los modelos se están convirtiendo en algo común; cada herramienta tendrá modelos capaces. Lo que diferenciará a las plataformas líderes es cuán profundamente entienden su organización específica: sus repositorios, su estructura de equipo, su historial de entrega, sus patrones de implementación. Las herramientas que conocen su sistema producirán respuestas fundamentalmente diferentes a las que no lo hacen. Segundo, el cambio de reactivo a proactivo. Hoy en día, las herramientas responden a preguntas cuando se les hace. En unos años, las herramientas líderes observarán continuamente y surfacearán el riesgo antes de que se les pregunte. Las organizaciones que construyan esa capa de contexto ahora están compounding una ventaja. La próxima generación de herramientas tiene que resolver el problema de calidad a escala, y las organizaciones que lo resuelvan primero tendrán una verdadera ventaja.

Gracias por la gran entrevista, los lectores que deseen aprender más pueden visitar Allstacks.