Nas últimas duas décadas, governos e outros atores vêm gastando bilhões ensinando pessoas a programar. Acreditava-se que essa seria uma das poucas profissões seguras em um mundo em transformação, mas, como se vê, escrever e manipular código é uma das atividades para as quais os modelos de IA são mais adequados. Empresas de tecnologia demitiram mais de 1 milhão de funcionários nos últimos anos, e a Microsoft ofereceu 60.000 acordos de demissão voluntária só na semana passada. É um momento assustador e completamente desorientador para as pessoas da indústria de software.

Há cerca de um mês, escrevi um memorando interno no qual detalhei o caminho de adoção de IA que a Proton precisa seguir para continuar competitiva e segura, e o que deixamos passar até agora como organização e que precisamos corrigir para que essa transição inevitável seja bem-sucedida. Há pouca dúvida de que as organizações que não se transformarem rápido o suficiente acabarão decepcionando suas equipes e aqueles que dependem delas.

O memorando também tinha outro propósito: convencer meus colegas de que não somos atores passivos nessa mudança, de que a empresa precisa dos talentos e da expertise deles para concretizá-la e de que essa transição oferece oportunidades a quem escolher se preparar e se engajar nela.

O memorando não é um documento de engenharia aprofundado. Ele não entra nos detalhes específicos de segurança, confiabilidade ou infraestrutura. Em vez disso, aponta a direção a seguir para nossa indústria como um todo.

O memorando completo pode ser encontrado abaixo.

Baixar um PDF do manifesto de IA(nova janela)

IA @ Proton, manifesto de engenharia

Não deve ser surpresa para ninguém na Proton, muito menos na engenharia, que a engenharia de software mudou irrevogavelmente este ano, se não antes. Os LLMs e as ferramentas associadas ganharam a capacidade de escrever código a ponto de um engenheiro sênior da Proton me dizer alguns dias atrás, e cito: “Ninguém mais escreve código em {business unit name}.” Assim como memorizar números de telefone no século 20 ou andar a cavalo no século 19, escrever um ótimo código manualmente é uma habilidade essencial cujo tempo já passou.

Isso, em geral, é algo fantástico. Boa parte da escrita de código era e é uma tarefa árdua e demorada, pelo menos em produção e em escala. Documentação e testes são ambos necessários, mas poucos gostam de fazê-los e, historicamente, muitas vezes foram negligenciados em detrimento da comunicação, da eficiência e da confiabilidade. O boilerplate é o símbolo máximo da rotina desgastante da engenharia de software, e pode nunca mais ser algo com que uma pessoa precise se preocupar. Os modelos agora podem aconselhar e propor arquiteturas e designs de sistema que, embora muitas vezes imperfeitos, contribuem de forma significativa para discussões, tomadas de decisão e aprendizado.

Fora da Proton, a revolução da IA está conquistando o mundo. Muito disso é conversa fiada e superficial, campanhas cosméticas feitas mais para parecer inovadoras do que para realmente serem inovadoras. Mas boa parte disso é muito real, e os investimentos que essas empresas (incluindo a concorrência) estão fazendo agora vão determinar o ambiente de negócios em que atuaremos no futuro. Não se trata de seguir tendências. Estamos ficando para trás aqui, e isso é uma ameaça existencial ao sucesso da própria missão.

Então por que, na Proton, não parece que a revolução chegou? Por que a produtividade não aumentou drasticamente se todo mundo já usa LLMs o tempo todo? Acredito que isso se resume a três coisas, e todas precisaremos corrigir se quisermos ter sucesso na nova era que já está aqui hoje, e não a caminho.

O primeiro é uma mudança na cultura de engenharia e na mentalidade dos engenheiros. Seu trabalho mudou fundamentalmente. Ele não é mais escrever código, e os LLMs não estão aqui para ajudar você a escrever código melhor e mais rápido. Seu trabalho é ajudar o LLM a escrever código melhor e mais rápido. Cada pessoa na engenharia agora é líder de equipe e gestora, e seus subordinados diretos são os modelos e agentes que você usa. Orientá-los diretamente e corrigi-los quando estiverem errados faz parte, sem dúvida. Mas uma equipe de duas pessoas que sempre fizeram pair programming juntas não seria grande coisa como equipe, nem uma equipe em que ninguém trabalhasse enquanto o líder estivesse em uma reunião. A IA precisa ser capaz de trabalhar de forma autônoma e contínua, com cada vez menos supervisão humana. Seu trabalho é identificar problemas que o LLM não consegue resolver sozinho e ajudar não apenas a resolvê-los desta vez, mas a conseguir resolvê-los melhor na próxima, não só para você, mas para todo mundo: arquivos de contexto no nível do repositório, habilidades e prompts compartilhados e o hábito de garantir que falhas repetidas disparem uma investigação e uma correção. Seu trabalho é ampliar os limites do que o LLM consegue fazer de forma autônoma, intervir nas coisas que ele não consegue e sempre pensar em como melhorar o status quo.

Isto não é o fim da expertise. O LLM é rápido. Você é lento, mas carrega consigo uma vida inteira de experiência, julgamentos e compreensão. Você também tem (espero) muito menos propensão a alucinações e a se deixar enganar por entradas ruins ou maliciosas, e responde por si mesmo, por seus colegas de equipe e pela Proton de uma forma que um modelo nunca poderá. Juntos, vocês podem fazer muito mais e muito mais rápido do que qualquer um dos dois sozinho.

Também não é o fim das boas práticas de engenharia. A manutenibilidade e a velocidade são melhores em bases de código bem arquitetadas. Documentação e testes continuam cruciais. Dito isso, precisamos ter abertura para que as boas práticas mudem à medida que os custos e as capacidades mudam. Os testes são um bom exemplo disso. A antiga boa prática dizia que testes demais (especialmente testes de ponta a ponta) são uma troca ruim em um mundo onde escrever e manter testes é caro. Se escrever e manter testes se tornar barato, o ponto em que traçamos essa linha provavelmente também mudará.

O segundo motivo pelo qual não conseguimos aproveitar plenamente a revolução da IA é que ficamos quase completamente presos na fase 1: usar LLMs para acelerar tarefas como parte dos fluxos de trabalho existentes. Mas escrever código não é a única parte do ciclo de vida de desenvolvimento de software, e o que acontece quando você elimina um gargalo? Outro toma o seu lugar. Talvez seja a velocidade e a capacidade da CI. Talvez sejam design, aprovações, especificações e revisões de código (sim, precisamos e vamos chegar a um ponto em que a maior parte da revisão humana de código terminará). Talvez o fluxo de trabalho não mude muito, mas os LLMs nos permitam finalmente investir em automação que antes era inviável em termos de custo. Se não olharmos para todos os nossos processos de forma holística e não eliminarmos implacavelmente os gargalos, não alcançaremos nosso potencial máximo. Muitas vezes, eliminar esses gargalos envolverá não apenas otimizar partes dos nossos fluxos de trabalho existentes, mas reformulá-los e repensá-los por completo. Esta é a fase 2, e precisamos chegar lá agora.

O terceiro motivo é um problema de ação coletiva. Usar LLMs de forma eficaz para escrever código é algo que cada pessoa da engenharia pode fazer por conta própria. Reconstruir ou otimizar o processo de CI para uma equipe, unidade de negócios ou empresa inteira é uma tarefa muito mais pesada, e vem com custos de oportunidade e concessões. Não é impossível, e muitas pessoas na Proton fizeram coisas incríveis por conta própria, algumas das quais se espalharam amplamente. Mas reequipar a empresa como um todo exige um nível de organização e de recursos em que simplesmente ainda não investimos. Em relação à discussão sobre o ciclo de vida de desenvolvimento de software no parágrafo anterior, em muitos casos nem sabemos onde estão os gargalos porque não investimos nas ferramentas necessárias para descobrir. Alguma cautela pode ter sido justificada no passado. Levou algum tempo para descobrir como usar melhor essas novas ferramentas, e continuaremos a incentivar a experimentação. Mas já passou da hora de, como organização, nos comprometermos com a transformação que o momento exige.

Então o que isso significa para você, que atua na engenharia? Bem, sua autonomia e suas responsabilidades aumentaram. Você não é apenas responsável por garantir que o trabalho seja feito; agora também é responsável por como ele acontece e, portanto, pela otimização contínua e pela automação máxima (e por compartilhar essas melhorias com seus colegas: sucesso na Proton é um esporte de equipe). Também é sua responsabilidade sinalizar e escalar melhorias necessárias que você não consegue executar por conta própria. A Proton, por sua vez, vai organizar e alocar recursos para os investimentos críticos necessários para atravessar a fase 2 e alcançar plenamente o potencial da revolução da IA.

O ponto principal é que estamos em um novo mundo. A “programação” morreu. A engenharia não morreu, nem a expertise. Seu antigo trabalho acabou. Seu novo trabalho como construtor permitirá que você faça mais e tenha mais impacto do que nunca, se aproveitar a oportunidade. E a Proton vai criar as condições para você fazer isso, e você saberá mais sobre esses esforços nos próximos dias e semanas. A era da experimentação continua, mas o momento de agir é agora. O futuro chegou. Vamos fazer dele o nosso.

Imagem de capa por: Bernard Leonardo
Instagram: @dranreboel
Site: https://dranreboel.myportfolio.com/work