Jeremy Freeman, Co-Fundador e CTO da Allstacks – Série de Entrevistas

Jeremy Freeman, Co-Fundador e CTO da Allstacks, é um engenheiro de software, arquiteto de tecnologia e empreendedor com uma carreira que abrange desenvolvimento de software, engenharia de hardware, aprendizado de máquina e inovação de produtos. Desde a co-fundação da Allstacks em 2017, ele liderou a arquitetura e o desenvolvimento da plataforma central da empresa, ajudando a transformar a gestão de entrega de software por meio de análise preditiva e previsão impulsionada por IA. Antes da Allstacks, Freeman ocupou cargos de liderança na Ravioli Labs e CertiRx, onde trabalhou em engenharia de software, pesquisa, tecnologias anti-counterfeiting e desenvolvimento de produtos. No início de sua carreira, ele ganhou experiência em startups, empresas de tecnologia de grande porte e academia, incluindo o ensino de desenvolvimento web na Wake Technical Community College. Seu background técnico abrange sistemas embarcados, design de hardware, plataformas de software de grande escala, aprendizado de máquina e liderança de engenharia, o que lhe dá uma perspectiva única sobre a construção de produtos orientados por dados que ajudam as organizações a melhorar os resultados de entrega de software.

Allstacks é uma plataforma de inteligência de engenharia de software e gestão de fluxo de valor que ajuda as organizações a melhorar a previsibilidade e a eficiência do desenvolvimento de software. A plataforma integra dados de ferramentas utilizadas em todo o ciclo de vida do desenvolvimento de software, incluindo sistemas de gerenciamento de projetos, controle de fontes e sistemas de implantação, e então aplica IA e aprendizado de máquina para identificar riscos, prever resultados de entrega e fornecer insights ação. Ao fornecer visibilidade para líderes de engenharia e produto sobre a saúde do projeto, o desempenho da equipe e as tendências de desenvolvimento, a Allstacks permite que as organizações tomem decisões mais informadas, reduzam a incerteza de entrega e alinhem melhor os esforços de engenharia com os objetivos comerciais. Sua tecnologia é projetada para ajudar as empresas a ir além da planejamento baseado em intuição, aproveitando dados operacionais em tempo real para melhorar o desempenho de entrega de software e a execução estratégica.

Você teve uma jornada única, liderando equipes de pesquisa e engenharia que aplicam aprendizado de máquina a dados de desenvolvimento de software, para co-fundar a Allstacks em 2017. Quais lacunas ou problemas recorrentes você observou que finalmente o levaram a construir a empresa?

Quando começamos a Allstacks, passamos muito tempo fazendo descoberta de clientes, e o padrão que surgiu foi consistente: empresa após empresa tinha enormes quantidades de dados e ainda não sabia o que estava acontecendo. A entrega de software era imprevisível, apesar de ter algumas das pessoas mais inteligentes na sala. Esse problema não havia sido resolvido.

O que se tornou claro rapidamente foi que isso não era um problema de relatórios ou integração. Era um problema de relacionamento. Para saber se algo está em risco, você precisa saber como um item de trabalho se conecta a um branch, o branch se conecta a um PR, o PR se conecta a um objetivo de sprint e o objetivo de sprint se conecta a uma iniciativa de negócios. Esse gráfico não existe por padrão em nenhum lugar da cadeia de ferramentas padrão. Você precisa construí-lo. E construí-lo bem é fundamentalmente um problema de inferência, o que é onde o background em ML se torna diretamente útil.

Nosso objetivo desde o início não era tornar um desenvolvedor individual mais rápido em recurso X. Era tornar a organização inteira melhor. Como você alinha o esforço de engenharia para os resultados de negócios? Como você faz com que a engenharia sirva genuinamente ao negócio, em vez de apenas existir ao lado dele? Você precisa de uma melhor compreensão das relações de dados para responder a essas perguntas. São essas perguntas que impulsionaram quase todas as decisões de produto que tomamos.

A Allstacks se concentra em analisar dados em todo o ciclo de vida do desenvolvimento de software. Quais tipos de sinais ou padrões são mais previsíveis quando se trata de identificar riscos de entrega precocemente?

Não acho que haja um conjunto único de métricas que preveja o bom e o ruim, mas sim padrões para diferentes fases e tipos de organizações. O que encontrei mais útil é reconhecer que as organizações de engenharia passam por temporadas de melhoria. Este mês, é o desempenho do banco de dados. No mês seguinte, é a comunicação entre equipes. Então é “por que não podemos fechar nenhum PR?” Então, observabilidade. Como líder de engenharia, você está nadando em sinais: alguns diagnósticos, alguns de monitoramento e muitos que são apenas ruído.

O que ajuda é começar com o problema que você está vendo, não com uma métrica que você deseja melhorar. Se você está perguntando “por que parece que estamos entregando menos do que no ano passado”, essa é a partida certa. A partir daí, acho que você precisa de três tipos de métricas: primeiro, como você sabe que o problema é real (talvez a contagem de PR por desenvolvedor ao longo do tempo); segundo, quais mudanças você está fazendo e como você está acompanhando-as ao longo do caminho (dizer, adoção de um revisor de PR de IA, se essa for a intervenção); e terceiro, quão significativo é esse problema para o negócio. Sua intuição pode estar certa de que você está enviando 20 por cento menos de código, mas a história real pode ser que a QA agora está levando três vezes mais tempo. Você precisa de todas as três lentes para saber se está resolvendo a coisa certa.

Você trabalhou em indústrias como saúde, energia e tecnologia. Como os desafios na entrega de software diferem entre esses setores, e como isso moldou a plataforma da Allstacks?

Eu realmente valorizo minha experiência em setores não puramente tecnológicos. Em empresas de SaaS, é fácil se perder na ideia de que o software em si é o objetivo. Quando você está em um negócio onde você não vende o software diretamente, seu papel se torna muito mais claro: a tecnologia está lá para apoiar o negócio. Eu costumo brincar que, se o negócio pudesse realizar tudo no mesmo ritmo sem ter que lidar comigo, eles escolheriam essa opção sem piscar.

Essa perspectiva é útil. Ela contextualiza o que todos estamos fazendo nessa indústria e coloca muitos debates de tecnologia de volta em seu lugar. O negócio não se importa se você usa Python ou Go. Gastar ciclos nessa reescrita provavelmente não é onde o retorno real está.

O que permanece consistente em todos os setores, no entanto, é o problema de fragmentação. Independentemente do setor, cada organização de engenharia tem dados espalhados por uma dúzia de ferramentas com tecido conjuntivo limitado entre elas. Os detalhes variam: indústrias regulamentadas têm ciclos de planejamento mais longos e menor tolerância à ambiguidade nos requisitos, porque o custo de construir a coisa errada é mais alto. Lojas de tecnologia de alta velocidade acumulam dívida oculta mais rapidamente. Mas o modo de falha central é o mesmo. As equipes podem dizer o que foi enviado. Eles não podem rastrear por que algo escorregou, o que custou ou onde o risco era visível antes de se tornar um problema. É isso que moldou como construímos a plataforma.

Há uma narrativa crescente de que a IA está acelerando a codificação em si, enquanto expõe fraquezas em outros lugares. Por que os requisitos, planejamento e prontidão de especificação estão se tornando os principais gargalos?

Estamos vendo isso diariamente. Com um agente bom e uma sólida armadura ao redor, você pode ir de ideia, às vezes diretamente da boca do cliente, para produção em horas literais.

Parte do que torna essa mudança tão significativa é a alteração no loop de feedback. Com ferramentas de estilo copilot, o humano está no loop em cada sugestão. O agente oferece uma conclusão; você aceita ou rejeita imediatamente. Quando está errado, você pega rápido. O raio de ação de uma sugestão ruim é uma linha de código. A codificação agente funciona de forma diferente: você dá ao agente um objetivo, ele decompõe o trabalho, executa um plano de múltiplos passos e entrega um módulo funcionando. O humano revisa a saída, não cada passo. Quando a especificação está errada, o agente constrói toda a implementação para essa especificação errada e você descobre na revisão.

Isso soa como puro lado positivo até que você reconheça o que o tempo de lag anterior estava realmente fazendo. O lag servia a um propósito real. Múltiplas rodadas de pessoas inteligentes revisando, planejando, testando e trabalhando em ideias para produzir um sistema melhor.

A tentação agora é contornar tudo isso. Mas os agentes e as armaduras não estão prontos para o ciclo de vida de desenvolvimento de software completo. A velocidade é real. A porta de qualidade que costumava acontecer em todas essas etapas mais lentas não foi substituída. É a lacuna.

Muitas organizações ainda medem a produtividade usando métricas desatualizadas. O que os líderes estão entendendo fundamentalmente errado sobre a produtividade em um ambiente de desenvolvimento impulsionado por IA?

As pessoas amadureceram muito nesse tópico desde que começamos a Allstacks. A medição mudou para coisas que realmente importam, e os quadros se tornaram mais sofisticados. A IA derruba tudo isso.

O desenvolvimento de software tradicional foi fundamentalmente limitado por quão rápido um desenvolvedor podia escrever código que atendesse aos requisitos do negócio e à tecnologia subjacente. Esse custo está se aproximando de zero. O que estamos nos aproximando é algo mais próximo de um desenvolvedor individual como um gerente de agentes. Esse modelo exige uma abordagem completamente diferente para medir a produtividade, uma que está enraizada em algo além de tokens gerados ou horas de desenvolvedor gasto.

Parte do perigo com as métricas atuais é que elas escondem o que realmente está acontecendo no nível da equipe. Engenheiros seniores com ferramentas de IA estão ampliando sua vantagem: eles têm o contexto do código-fonte e o julgamento para direcionar a saída do agente e pegar seus fracassos. Engenheiros de carreira mais precoce geram o mesmo volume de código, mas gastam mais tempo auditando a saída que não podem avaliar completamente. A velocidade agregada parece boa, talvez até melhorada. A lacuna entre esses dois grupos não aparece em nenhum painel padrão. A pergunta certa para começar a fazer é não “quão mais rápido estamos indo”, mas “quanto do que enviamos foi certo da primeira vez”.

Nós não temos consenso da indústria sobre o modelo de medição correto ainda, mas as equipes que começam a rastrear a qualidade da saída e a taxa de retrabalho, e não apenas a produção e adoção, estarão melhor posicionadas do que as equipes que esperam que alguém mais resolva.

Sua plataforma conecta dados de ferramentas como sistemas de gerenciamento de projetos e repositórios de código. Quão importante é unificar essas fontes de dados fragmentadas, e o que acontece quando as organizações falham em fazê-lo?

A Allstacks teve sucesso nesse espaço porque construímos gráficos de contexto desde antes que isso fosse um termo. Reconhecemos cedo que conectar todos os dados juntos era necessário para responder às perguntas que os clientes estavam realmente fazendo.

Quando essa conexão não existe, a IA operando nos dados de engenharia só pode ver parte da imagem. Pode analisar o que está no sistema de gerenciamento de projetos. Pode analisar o que está no repositório de código. O que não pode fazer é rastrear um atraso de entrega de volta a uma dependência bloqueada em três ferramentas, porque a relação entre esses sinais não existe na camada de dados. Você obtém análise superficial, no melhor dos casos, e recomendações confiantes e erradas, no pior. A qualidade do modelo não resolve isso. Você pode colocar o modelo mais capaz disponível em cima de integrações de API brutos e ainda perder a causa real de um problema, porque os dados não codificam a relação entre os sinais. Lixo para dentro, lixo para fora, independentemente de quão inteligente o modelo seja.

Essa conexão é a fundação. É o que nos permitiu ser o primeiro a mercado com capacidades que ainda não foram replicadas.

À medida que os agentes de IA se tornam mais incorporados aos fluxos de trabalho de desenvolvimento, como uma organização de engenharia bem preparada se parece em comparação com uma que não está preparada?

Ironicamente, não é muito diferente de estar preparado para trazer uma turma de estagiários de verão. Você precisa de conjuntos de testes automatizados fortes, documentação sólida, um pipeline de CI/CD maduro e os guardrails que você colocaria no lugar quando está adicionando um desenvolvedor confiável, mas não treinado, à equipe.

O que também é importante, e as pessoas tendem a subestimar, é voltar regularmente para revisar os básicos: suas regras de agente, seus arquivos AGENTS.MD. Você pode fazer uma boa primeira passagem, mas é fácil entrar em um ritmo de envio na nova maneira e esquecer que você pode realmente treinar muitos padrões ruins. Coisas como ensinar o agente a executar testes antes de cada confirmação não devem exigir um lembrete humano a cada vez.

Uma pergunta de diagnóstico que eu colocaria para qualquer líder de engenharia: você pode me dizer o que seus agentes produziram na última sprint, qual daquela saída foi aceita como está versus revisada, e onde o esforço de revisão foi concentrado? Se você pode responder a isso, você tem a instrumentação para melhorar. Se você não pode, está voando por instinto.

Você enfatizou a importância de alinhar o trabalho de engenharia com os resultados de negócios. Como as organizações podem pontuar essa lacuna de forma prática e mensurável?

Eu vi dois principais modos de falha. O primeiro são empresas que não emparelham equipes de engenharia com produtos. Muitas estruturas de equipe são legado e estiveram em vigor por um longo tempo. Uma equipe pode possuir uma parte de três produtos diferentes, enquanto outra equipe possui quatro inteiramente. O investimento de engenharia vem principalmente de contagem de cabeça, e quando as equipes não estão alinhadas com os produtos, torna-se muito difícil ver onde as expectativas de negócios divergem da realidade.

O segundo modo de falha é não contabilizar todo o trabalho que vai para construir e manter software. Há uma grande categoria de trabalho de engenharia invisível para os negócios. Meu exemplo favorito é manter pacotes atualizados. Líderes de negócios não técnicos muitas vezes lutam para entender o valor ou por que é contínuo e imprevisível. Mas eles podem entender categorias de investimento. Se você o quadra como “atualizações críticas de segurança” e mostra em média quanto capacidade consome, você está falando uma linguagem com a qual eles podem trabalhar.

Se você perguntar a um líder de vendas para escolher entre algumas atualizações de pacotes npm e o recurso de que precisam para fechar um negócio, o recurso vence todas as vezes. Mas se você o quadra como “caímos da conformidade SOC ou enviamos esse recurso”, agora você está mostrando duas compensações que eles podem realmente avaliar. Essa reestruturação é o jogo todo. Vimos clientes cortar o tempo de relatórios de capitalização de P&D por mais de dois terços, apenas tornando o trabalho de classificação automático em vez de manual. O mecanismo é o mesmo, seja o objetivo relatórios de capitalização, justificativa de headcount, ou comprovação de ROI de IA: dados conectados substituem planilhas correlacionadas.

Considerando seu background em engenharia prática e ensino de desenvolvimento web, como você vê o papel dos desenvolvedores evoluindo à medida que a IA assume mais da carga de trabalho de codificação?

Francamente, estou um pouco preocupado, embora confie que pessoas inteligentes figurem isso.

Minhas preocupações são reais. Recém-graduados logo estarão entrando no mercado de trabalho, nunca tendo codificado em um mundo sem agentes de codificação. A educação acompanhou isso? As ferramentas se movem rapidamente; a educação superior não sempre se move ao lado delas. A outra mudança que estou assistindo é o desfoque de engenheiros seniores e pessoas de produto seniores. Os praticantes mais bem-sucedidos no novo modelo são engenheiros que estão profundamente investidos no pensamento de produto.

O que se torna mais valioso é o julgamento: a capacidade de definir um problema com precisão suficiente para que um agente o resolva, avaliar se a solução está correta e pegar os fracassos sutis que passam no CI, mas criam problemas arquitetônicos mais tarde. Engenheiros seniores ampliam sua vantagem, porque podem direcionar a saída do agente e saber quais saídas confiar. A preocupação é para o caminho de carreira mais precoce. O caminho tradicional de construir esse julgamento era escrever muito código e aprender com os erros. Esse loop de feedback está mudando de maneiras que a indústria ainda não trabalhou completamente.

Isso dito, a história oferece alguma garantia. Havia um contingente significativo de pessoas que acreditavam que os compiladores colocariam os desenvolvedores de assembly fora do trabalho. A mudança tecnológica aconteceu como eles previram. O que aconteceu com os desenvolvedores que não seguiram o mesmo roteiro? Ao longo da década seguinte, o número total de desenvolvedores cresceu. Muitos daqueles programadores de assembly aprenderam uma nova linguagem e se destacaram por causa de seu conhecimento fundamental. Acho que uma versão desse padrão se reproduz novamente.

Olhando para o futuro, como você vê a IA redefinindo o ciclo de vida do desenvolvimento de software nos próximos três a cinco anos, e onde as empresas ganharão a maior vantagem competitiva?

Vamos ver uma corrida armamentista de recursos como nunca vimos antes. À medida que o custo para construir se aproxima de zero, as empresas, mesmo as grandes, enfrentam um novo constrangimento: coletar e validar feedback suficiente do cliente para continuar construindo coisas de qualidade em escala.

A mudança que tem que acontecer é que a barra para o que é construído precisa subir. O constrangimento atual na maioria das organizações de engenharia é simples: cinco prioridades principais, talvez dois entregues. Com os agentes, a proporção muda. Você pode ter cinco principais, dez próximos e vinte talvez na lista, e enviar cem. A pergunta que ninguém respondeu completamente ainda é como manter esses últimos sessenta e cinco de serem mal concebidos e mal executados.

Duas coisas das quais estou bastante confiante para a janela de três a cinco anos. Primeiro, a vantagem competitiva em engenharia de IA virá da profundidade e amplitude do contexto, não da qualidade do modelo. Os modelos estão se tornando um padrão; cada ferramenta terá capazes. O que diferenciará as principais plataformas é quão profundamente elas entendem sua organização específica: seus repositórios, sua estrutura de equipe, seu histórico de entrega, seus padrões de implantação. As ferramentas que conhecem seu sistema produzirão respostas fundamentalmente diferentes das que não o conhecem. Segundo, a mudança de reativa para proativa. Hoje, as ferramentas respondem a perguntas quando solicitadas. Em alguns anos, as principais ferramentas observarão continuamente e superfície risco antes de você perguntar. As organizações que constroem essa camada de contexto agora estão ampliando uma vantagem. A próxima geração de ferramentas precisa resolver o problema de qualidade em escala, e as organizações que resolvem primeiro terão uma vantagem real.

Obrigado pela grande entrevista, leitores que desejam aprender mais devem visitar Allstacks.