Menos de 10 euros à hora. Quanto vale a experiência?

Num vídeo que tem circulado muito entre quem faz software, Geoffrey Huntley diz que o desenvolvimento de software custa hoje 10,42 dólares por hora, menos de 10 euros. É menos do que se paga, nos Estados Unidos, a quem trabalha num restaurante de fast-food. O número tem uma origem precisa: é o que custa a API de um modelo de IA quando se deixa um agente a escrever código num ciclo contínuo durante 24 horas. É o preço de produzir código, não o preço de pôr um sistema a funcionar com garantias, e a diferença entre os dois é o assunto deste texto. Mesmo assim, quando o ouvi, não foi novidade. Confirmou o que já tinha percebido no meu próprio trabalho, e custou-me.

Custou-me porque o valor do que construí assentava na dificuldade. Fazer software era caro e lento, e só alguns o sabiam fazer bem. Era isso que dava valor às empresas que criei, às equipas que liderei e ao que eu próprio sabia. Quando produzir código passa a custar menos de 10 euros à hora, essa dificuldade deixa de ser vantagem. Construí empresas e equipas num tempo em que produzir software exigia um investimento que agora estou a reconsiderar. E não sou o único a perdê-lo: durante anos, muita gente veio para a programação, vinda de outras profissões, de cursos intensivos ou da universidade, com a promessa de que ali havia uma carreira. Essa promessa foi feita com base no preço que agora caiu.

Quando olho com mais atenção, nem tudo o que construí assentava nessa dificuldade. Produzir código tornou-se muito mais acessível. Não perdeu a parte de perceber que problema vale a pena resolver, de o transformar num negócio, de levar uma equipa a decidir bem. Durante muito tempo, perceber o problema, construir o negócio e liderar a equipa eram competências difíceis de separar da capacidade de programar. Ao delegar a escrita do código, passei a ver com mais clareza o trabalho que cada uma exige.

O próprio vídeo mostra o que os 10 euros não pagam. Huntley demonstra a técnica a que chamou Ralph: um ciclo simples que dá ao agente as mesmas instruções vezes sem conta, até o trabalho estar feito. Mas, ao longo da demonstração, toma decisões que o ciclo não toma por ele. Pede que os endereços IP nunca cheguem aos registos. Lembra ao agente que o sistema já separa os dados de cada cliente e que deve usar o que existe em vez de inventar. Mantém a base de dados atual, sabendo que não vai escalar. E, se o agente se esquecer das permissões ou da tradução, conta com outra volta para as corrigir. Nenhuma destas decisões está no preço da API. Huntley escreveu-o de forma mais seca: a programação morreu, mas continuamos a precisar muito de engenheiros de software.

Estou a fazer essa mudança no meu trabalho. Deixei de escrever código e passei a escrever especificações e planos: o que o sistema tem de fazer, o que nunca pode fazer, como vou saber que está certo. O código escrevem-no agentes.

Há dias tive um exemplo pequeno. Ao publicar uma página nova neste blog, a verificação de língua assinalou duas palavras: «Sivers», um apelido, e «now», o nome de um conceito em inglês. O agente que escrevia a página acrescentou-as à lista de exceções por iniciativa própria, e a verificação passou. Em agosto, escrevi aqui que essas exceções podiam ser alteradas na mesma proposta que beneficia delas. Desta vez aconteceu. Quem o apanhou foi outro agente, que revia a alteração e a classificou como importante: a verificação tinha passado porque a regra foi alterada por quem não tinha autorização para a alterar. A alteração foi revertida, a verificação voltou a falhar, e a decisão veio ter comigo.

Aceitei as duas palavras, tal como o agente as tinha acrescentado. Antes de decidir, tive de considerar o alcance dessa escolha: a lista de exceções vale para todos os artigos, e aceitar «now» numa página significa aceitá-la em tudo o que eu vier a escrever. Escrever a exceção era trivial, uma linha. Perceber o seu alcance e aceitar a consequência foi o trabalho que importava. Quem detetou o problema foi também um agente, pelo que este episódio dificilmente serviria para concluir que a máquina não sabe julgar. Mostra o valor da revisão independente e obriga-me a distinguir duas decisões: aplicar uma exceção e autorizar a mudança de uma regra que se aplica ao blog inteiro.

Também não quero apresentar a engenharia como território protegido. Especificar, testar e rever já são tarefas em que a IA ajuda, e vai ajudar mais. O episódio mostra-o. Com agentes a participar também nessas tarefas, preciso de perceber que julgamento continua a ser meu e como provo que o resultado merece confiança. O relatório DORA de 2025, sobre o desenvolvimento de software assistido por IA, conclui que a IA pode funcionar como um espelho e um multiplicador: nas organizações coesas, aumenta a eficiência; nas fragmentadas, expõe as fraquezas. Creio que vale o mesmo para uma pessoa: o resultado depende do critério de quem dirige o agente e dos controlos e revisões que organizou.

Se trabalhas em software há anos, o que te digo é que invistas em engenharia e não concentres a aprendizagem apenas na escrita de código. Em concreto: saber dizer o que o sistema tem de fazer e o que nunca pode fazer, antes de haver código; desenhar os travões, com testes escritos primeiro, verificações automáticas e revisão independente; guardar as garantias que custam caro quando falham, como a privacidade, a separação entre clientes e a segurança; e decidir o que entra. Estas exigências já faziam parte de desenvolver software bem. No meu trabalho, tornaram-se mais visíveis à medida que passei a delegar a escrita do código.

Fica uma pergunta a que não sei responder. Aprendi este critério ao longo de anos a escrever código, a errar e a corrigir. Não sei como se aprende quando o código já chega feito. Deixo-a a quem está a começar, e a mim também.

Custou-me, mas faço esta mudança feliz. As oportunidades de aprender e de chegar mais longe são enormes. A parte do trabalho que fica é a que exige mais de mim, mas também a mais interessante: é onde se decide que problema vale a pena resolver e por que razão, para que o que se constrói produza valor para as pessoas, e não apenas código que funciona.