Software tem valor apenas quando entregue aos clientes, e cadência de release mais rápida é quase sempre melhor do que as organizações reconhecem. Essa é a premissa central apresentada por Titus Winters na Craft Conference, onde discutiu a otimização de fluxo de trabalho em engenharia de software.
Segundo Winters, desenvolvimento, deployment e operações requerem thinking, métricas e investimentos fundamentalmente diferentes. O desenvolvimento é um processo criativo, onde se deseja que humanos gastem tempo. O deployment funciona como um processo de fábrica, enquanto operações é um processo de automação. Cada um demanda abordagens distintas.
Winters identificou quatro impactos fundamentais que toda organização tecnológica deve considerar: sucesso do produto (receita, adoção, satisfação do cliente), capacidade computacional (custos de cloud, armazenamento, rede), capacidade de engenharia (produtividade e eficiência humana) e inovação estratégica (tornar coisas boas mais baratas ou possíveis, tornar coisas ruins raras ou impossíveis). O equilíbrio entre esses quatro é crucial.
A maior despesa em engenharia de software é pessoas, não computação. Contudo, enquanto custos de tokens e cloud são facilmente rastreáveis, gastos com pessoas raramente são medidos diretamente. Winters argumentou que essa lacuna de medição é problemática: "Temos medido tudo exceto o maior item de linha, o que dificilmente parece rigoroso."
Quando bugs ocorrem em produção, riscos reais de perdas financeiras surgem. Por isso, há valor em corrigir problemas através de atualizações bem-testadas e confiáveis que podem ser entregues rapidamente. Reduzir testes pode economizar custos computacionais, mas os problemas de qualidade resultantes podem causar perdas reais no resultado final ou burnout de engenharia ao tentar estabilizar o produto.
Sobre a inteligência artificial, Winters esclareceu um ponto crítico: AI não reduzirá o número de engenheiros. Em vez disso, deslocará engenheiros para compreensão mais profunda de problemas. Os desenvolvedores permanecerão no loop, mas dentro de um sistema que codifica conhecimento especializado e políticas organizacionais, permitindo que se concentrem no problema único em questão, em vez de internalizar todos os detalhes.
Winters referenciou o artigo "Develop, Deploy, Operate" (escrito com Leah Rivers e Salim Virji), que fornece orientação para raciocinar sobre impacto e eficiência no processo de software, com ou sem assistência de IA.
Em entrevista com InfoQ após sua apresentação, Winters abordou desafios práticos. Rastrear onde o tempo de engenharia vai é significativamente mais difícil que rastrear custos de tokens ou gastos em cloud. Requer compreensão suficiente do processo de engenharia para determinar se uma tarefa específica é desperdiçadora. Embora o discurso em torno de IA tenha se intensificado, as lições fundamentais permanecem válidas e aceleradas: processos claros, código limpo, boas ferramentas, sinais de feedback rápido e bons testes continuam essenciais.
Winters propôs uma abordagem experimental inovadora: usar consumo de tokens como proxy tolerável para esforço humano em tarefas de software. Essa estratégia permitiria construir suites de avaliação robustas para agentes de software, cobrindo múltiplas tarefas (novas funcionalidades, correções de bugs, refatoração), plataformas (frontend, backend, mobile) e linguagens, em vários níveis de dificuldade.
Cada tarefa na suite de avaliação precisaria ter critérios de aceitação funcional e qualidade ocultados da IA. Assim, poderiam executar testes empíricos com grupos de controle e experimentais. Por exemplo, comparar agentes que seguem todas as práticas de teste unitário robustas com agentes que ativamente não escrevem testes, executando a suite de avaliação e medindo consumo de tokens. Práticas importantes deveriam reduzir custos de tokens em geral.
O mesmo princípio aplica-se a ferramentas. Seria possível medir quantitativamente se um índice semântico ajuda na navegação de codebase grande e se compensa em custos líquidos de tokens. Se uma ferramenta pagar em custos líquidos de tokens reduzidos, o investimento nela seria justificado. Essa abordagem oferece rigor quantitativo para decisões sobre investimentos em infraestrutura e práticas de engenharia.
