Muitas equipas de desenvolvimento já experimentaram assistentes de programação baseados em inteligência artificial. Algumas utilizam-nos para gerar código repetitivo, escrever testes, explicar componentes antigos ou acelerar a resolução de problemas. A questão já não é saber se a IA consegue gerar código.
A questão mais importante é saber se as equipas conseguem transformar essa capacidade num fluxo de desenvolvimento fiável, seguro e escalável ou se estão apenas a acrescentar IA à forma como sempre trabalharam.
Durante anos, o fluxo de trabalho do programador era fácil de descrever, pelo menos em teoria: compreender o requisito, escrever o código, testá-lo, corrigir o que não funcionava e colocá-lo em produção. Na prática, nunca foi assim tão linear. Os requisitos mudavam, os casos-limite surgiam tarde, a documentação estava incompleta e os utilizadores encontravam sempre formas inesperadas de interagir com o sistema.
A IA não criou essa complexidade. Tornou-a mais visível e fez com que tudo passasse a acontecer mais depressa.
É por isso que o novo fluxo de trabalho do programador que utiliza IA pode ser resumido em quatro palavras: Prompt, validar, iterar, compound.
No entanto, estas quatro palavras não devem ser entendidas como uma lista de tarefas a percorrer uma única vez, mas como um loop que a equipa concebe e coloca em funcionamento – um loop que torna o sistema um pouco mais inteligente de cada vez que é executado.
De uma lista linear para um loop que aprende
A interpretação tradicional destas etapas coloca o programador no centro de cada uma delas. Escrever um prompt, ler o resultado, ajustar, voltar a ler, testar e regressar ao início. Trata-se de uma conversa passo a passo, na qual o programador se encontra no meio do processo e acaba por se tornar o principal ponto de estrangulamento. O modelo funciona, mas só consegue escalar até ao limite da atenção humana.
O modelo mais eficaz é diferente. Em vez de orientar a IA passo a passo, o programador fornece ao sistema um objetivo, juntamente com o contexto necessário para o alcançar, e permite-lhe executar o loop.
O prompt corresponde ao momento em que o problema é enquadrado. A validação e a iteração tornam-se atividades realizadas pelo próprio sistema enquanto trabalha, verificando os seus resultados e explorando alternativas. E compound é aquilo que transforma um loop que apenas se repete num loop que melhora.
Neste modelo, o papel do programador não diminui. Concentra-se nas extremidades do loop. No início, o objetivo deve ser definido com contexto e restrições suficientes para que o sistema possa tomar decisões acertadas. Ao longo de todo o processo, é o julgamento humano que determina o que merece confiança e o que deve ser corrigido. A parte intermédia mais exigente – aquela que anteriormente consumia a maior parte do dia de trabalho – passa a ser executada pelo loop.
Prompt: o context passa a fazer parte da competência
O primeiro passo não é pedir à IA que escreva código. É fornecer-lhe contexto suficiente para produzir algo útil sem que esteja uma pessoa presente para a corrigir.
Um prompt fraco produz geralmente uma resposta plausível. Um Prompt forte fornece ao modelo um enquadramento: o problema, as restrições, o comportamento esperado e o nível de qualidade exigido.
Existe uma diferença significativa entre pedir “cria um endpoint de API” e pedir “cria um endpoint REST para este serviço existente, seguindo a estrutura atual do repositório, com validação dos dados de entrada, respostas de erro consistentes e testes unitários para os principais casos-limite”.
O segundo pedido não solicita apenas código. Enquadra o problema de engenharia.
Este aspeto torna-se ainda mais importante quando o sistema funciona de forma autónoma. Quando o programador corrige o resultado em cada interação, um Prompt vago é tolerável, porque qualquer desvio é detetado rapidamente. Quando o loop funciona com menos supervisão, a qualidade do objetivo definido no início determina, em grande medida, a qualidade do resultado final.
Validar: o resultado da IA é um rascunho até prova em contrário
O código gerado por IA pode parecer correto antes de ser verdadeiramente correto. Pode compilar e, ainda assim, resolver o problema errado. Pode passar num teste simples e falhar em produção. Pode utilizar padrões desatualizados, ignorar casos-limite ou introduzir vulnerabilidades de segurança que não são imediatamente evidentes.
Isto não significa que a IA não seja útil. Significa que a revisão é indispensável e que a verificação deve fazer parte do loop, em vez de ser tratada como uma reflexão posterior. A validação deve abranger diferentes dimensões:
- Funcional: o código faz aquilo que foi pedido
- Técnica: enquadra-se na arquitetura e na base de código existentes
- Segurança: trata corretamente os dados de entrada, as permissões e a informação sensível
- Qualidade: é legível, fácil de manter e simples de testar?
- Produto: responde à necessidade do utilizador ou ao objetivo do negócio?
O objetivo não é tornar o processo mais lento. É evitar confundir velocidade com progresso. A IA pode ajudar as equipas a avançar mais depressa, mas a velocidade sem validação apenas permite chegar mais rapidamente ao destino errado.
Iterar: utilizer a IA para questionar a primeira resposta
Um dos aspetos mais úteis da IA é a redução do custo associado à exploração de alternativas. Os programadores podem pedir uma implementação mais simples, uma opção mais escalável, um conjunto de testes, uma proposta de refatoração ou uma análise de possíveis pontos de falha.
Em vez de aceitar a primeira sugestão, a equipa pode utilizar a IA para testar a robustez da solução numa fase mais precoce. É neste momento que a IA se torna um verdadeiro parceiro de reflexão, desde que o programador mantenha o controlo da conversa.
Contudo, a iteração só produz valor quando cada passagem se baseia na anterior. Um loop que funciona sempre da mesma forma não passa da automatização do esforço. Um loop que melhora é algo completamente diferente – e é disso que trata a última etapa.
Compound: cada passage deve tornar o sistema mais inteligente
É aqui que o loop faz jus ao nome e demonstra claramente a sua superioridade em relação a uma lista de tarefas.
Uma lista de tarefas é executada uma vez e termina. Um loop é executado várias vezes e, quando é bem concebido, cada passagem não é uma mera repetição da anterior. Representa uma evolução. Cada iteração deve tornar o sistema um pouco mais capaz, porque aquilo que é aprendido numa passagem é registado e utilizado na seguinte. O sistema não está simplesmente a andar em círculos. Está a gerar um efeito compound.
Isto altera a finalidade do trabalho. O instinto herdado do antigo fluxo consiste em corrigir o resultado: resolver este erro, ajustar aquele padrão, seguir em frente e, na semana seguinte, voltar a corrigir o mesmo tipo de problema.
A abordagem mais valiosa consiste em melhorar o próprio sistema. Quando o loop comete um erro, a correção deve passar a fazer parte do conhecimento do sistema, para que o mesmo erro não se repita. Convenções, decisões anteriores, o raciocínio por detrás de uma escolha e o contexto que, de outro modo, teria de ser novamente explicado – tudo isso é transportado para o futuro.
Como afirma Kieran Klaassen, criador do conceito de Compound Engineering, o objetivo é dedicar aproximadamente metade do tempo à execução do trabalho e a outra metade a ensinar o sistema. Desta forma, a funcionalidade seguinte torna-se mais fácil porque a anterior foi concluída, em vez de se tornar mais difícil.
Se cada nova funcionalidade acrescentar obstáculos e o sistema nunca se tornar mais inteligente, a equipa terá automatizado a passadeira rolante, e não o trabalho. O objetivo é precisamente o contrário: criar um loop ligeiramente mais bem informado de cada vez que é executado, para que, ao longo das semanas e dos meses, se adapte à forma como a equipa realmente desenvolve software.
O programador que adotou a IA continua a ser programador
A IA não substitui os programadores. Aumenta a importância do julgamento humano, uma vez que os programadores continuam a definir os problemas, validar as soluções e garantir a qualidade, a segurança e o valor.
O programador que adota a IA utiliza-a para acelerar o trabalho, e não para substituir a responsabilidade. Compreende também que prompt, validar, iterar, compound reflete aquilo que a boa engenharia sempre exigiu: clareza, qualidade e responsabilização. A diferença é que estas quatro palavras descrevem agora um loop que aprende, em vez de uma linha que se percorre uma única vez.
Para as equipas que estão a adotar a IA, o desafio não consiste apenas em escolher ferramentas, mas também em conceber o fluxo de trabalho adequado à sua utilização. É por isso que, na Xpand IT, ajudamos as equipas a integrar a IA no ciclo de vida do desenvolvimento de software, mantendo o equilíbrio certo entre velocidade, qualidade e controlo.
A IA pode mudar a forma como desenvolvemos software, mas não muda a razão pela qual procuramos desenvolvê-lo bem.
