Blog / Engenharia

A Cartesia está contratando uma pessoa de engenharia para formar um exército de Claudes

Kabir Goel 
Quatro cópias do mesmo símbolo de linha em laço, lado a lado, em verde-claro, verde médio, cinza e verde-escuro

Recentemente, encontrei uma publicação da Ramp sobre a criação de seu próprio agente de programação em segundo plano, chamado Inspect. O texto é ótimo e chegou em boa hora para nossa equipe de engenharia, que está pensando em como ampliar os ganhos de produtividade dos agentes de programação com IA em toda a Cartesia.

Na Cartesia, adotamos esses agentes com vontade. A equipe usa Claude Code, Cursor, Codex, Copilot, Zed, Conductor e outros. Nos nossos monorepositórios, você pode esperar revisões de Claude Code, Cursor BugBot, Vercel Agent e Codex. Elas trazem opiniões variadas, às vezes complementares, às vezes contraditórias, que melhoram de forma concreta a qualidade do código entregue. O favorito no momento é o BugBot:

Revisão do BugBot em um pull request

Isso não veio de uma ordem da liderança para adotar agentes. Surgiu do interesse espontâneo em fazer um trabalho melhor, mais rápido, e automatizar ao máximo as partes tediosas, junto com a disposição de gastar o necessário para experimentar.

Experimentar bastante facilita comparar os agentes e acompanhar os avanços mais recentes. As práticas mudam a cada poucos meses.

Mas parece que ainda falta alguma coisa.

Escrever código parece um problema resolvido. Fazer engenharia, ainda não.

Os modelos mais avançados conseguem fazer refatorações complexas e integrar código a endpoints de alto tráfego. Muitas vezes, parecem antecipar problemas. Descobrimos que mudanças simples, como colocar o código em um monorepositório, trazem ganhos enormes. Os agentes passam a raciocinar sobre os componentes do sistema e a evitar bugs sutis. Agentes de revisão ajudam a cobrir lacunas no código. Escrever o código já não é o gargalo.

Mas programar e fazer engenharia não são a mesma coisa. Uma ótima pessoa de engenharia pensa além da integração de código em um monorepositório. Ela pensa no impacto, avalia se um recurso está funcionando, melhora o resultado com base no uso real e continua até que os objetivos da empresa sejam alcançados.

É aí que os agentes ficam aquém. Usamos o Opus 4.5 para remover com segurança um recurso com mais de 10 mil linhas:

Uso do Opus 4.5 para remover um recurso grande

Mas ainda não conseguimos pedir que ele descubra se um recurso está ganhando adoção em produção e faça melhorias, ou que relacione um pico na latência da API a uma linha do nosso código.

O verdadeiro gargalo são ciclos de feedback interrompidos

Os agentes não falham por serem incapazes de escrever código. Eles falham porque esbarram em limites práticos. O Opus 4.5 pode escrever o código de um teste A/B, mas não consultar o PostHog para saber se o experimento funcionou, então para ali. Pode implantar uma correção de interface, mas não acessar o preview da Vercel para verificar a aparência. Pode otimizar uma consulta SQL, mas não ver as métricas de produção para confirmar a melhora.

É aí que vemos a oportunidade. Dar aos agentes, com segurança, a infraestrutura certa para iterar de ponta a ponta. Acesso a repositórios, CI, previews, painéis internos, dados do PostHog e tudo de que precisam para avaliar sucesso e fracasso como uma pessoa de engenharia faria.

Isso também traz benefícios concretos para as pessoas. Se o CI fica mais rápido ou a stack completa fica mais fácil de iniciar, engenheiros entram no projeto mais rápido e trabalham melhor.

Aumentar a produtividade com agentes de programação é uma função estratégica

É comum que engenheiros estejam tão concentrados no problema imediato que não consigam pensar na experiência de desenvolvimento como um todo. Acompanhar os avanços, experimentar as ferramentas mais recentes e transformar o aprendizado em soluções internas é um trabalho de tempo integral.

A oportunidade vai além da engenharia. Acreditamos que os mesmos princípios de infraestrutura pensada para IA que aumentam a produtividade dos agentes na engenharia podem transformar fluxos internos de toda a empresa. Equipes de go-to-market, negócios e vendas têm muito trabalho repetitivo que, quando bem automatizado, pode gerar ganhos enormes.

A distância entre as capacidades dos agentes e a infraestrutura não vai desaparecer sozinha. Alguém precisa projetar ativamente a experiência de desenvolvimento para humanos e IA.

Estamos trabalhando para resolver esse problema e contratando uma pessoa de engenharia de aceleração de IA e desenvolvimento, ou seja, alguém que acelere o trabalho tanto das IAs quanto dos desenvolvedores. Se você vier trabalhar conosco, vai definir as práticas que permitem a pessoas de engenharia e de outras áreas ir do problema à solução com o mínimo de intervenção humana. E também poderá falar publicamente sobre isso. Entre em contato!