Estou preocupado com a IA.
Não estou preocupado com isso tirando meu emprego. Acredito que a IA é uma ferramenta genuína de produtividade. Com isso quero dizer que pode fazer com que os desenvolvedores produzam mais.
Aprenda mais rápido. Vá mais fundo. Veja mais longe.
A questão é se esses desenvolvedores estão produzindo algo bom ou não.
A diferença entre um desenvolvedor experiente e um desenvolvedor júnior é que um desenvolvedor experiente sabe:
- Há mais de uma boa solução para cada problema.
- A resposta para “qual é a solução” é “depende”.
- Do que “depende”, ou pelo menos tem como descobrir do que depende.
A forma como treinamos os juniores, seja na universidade ou num boot camp ou se eles se treinam a partir dos materiais que lhes disponibilizamos (Viva a Web), sugerimos desde o início que existe uma resposta correta. “Esta é a solução para imprimir a sequência de Fibonacci usando recursão.” Os desenvolvedores juniores são treinados para pensar que se o código resolver o problema, o trabalho estará concluído.
No entanto, o que fazemos no desenvolvimento de software program geralmente não tem foi feito antes. Se tiver, geralmente é codificado em uma linguagem, estrutura ou biblioteca.
O que isso tem a ver com IA? Atualmente, a IA generativa lhe dá a resposta. À medida que a IA melhora, provavelmente até lhe dará uma resposta que funcione. Isso é ótimo! Não precisamos mais gastar muito tempo treinando desenvolvedores; podemos treiná-los para serem “engenheiros rápidos” (o que me faz pensar em desenvolvedores que chegam na hora certa), e eles pedirão o código à IA, e ele entregará.
Mas é mais complicado do que isso. Supondo que a primeira resposta que a IA nos dá compila e funciona, ela pode não corresponder ao nosso estilo de código; não pode utilizar as bibliotecas e frameworks que a equipe tem à sua disposição; poderá não levar em conta as peculiaridades do domínio de negócio da nossa aplicação específica; pode não atender aos nossos requisitos de desempenho. Um desenvolvedor experiente identificaria tudo isso e pediria à IA para moldar a resposta na forma correta ou faria isso sozinho. Um desenvolvedor júnior pode ficar tentado a inserir esse código no aplicativo da maneira que funcionar.
Quero ser muito claro aqui. Não culpo os desenvolvedores juniores por isso. Isso faz parte do aprendizado. Fazemos isso há décadas. Quando me formei em ciência da computação, eu estava usando o AltaVista (sim, sou tão velho) para encontrar soluções para meus problemas e cutucar o código até que ele fizesse o que eu queria, muitas vezes apesar de quaisquer ferramentas, estruturas ou padrões de design estávamos usando. Mais tarde, os juniores estavam usando o código do Stack Overflow como inspiração, sem saber quais linhas coladas na base de código não faziam nada e quais eram realmente relevantes. Hoje em dia, essas linhas de código coladas serão códigos criados por IA generativa.
Nossa responsabilidade como indústria sempre foi orientar os desenvolvedores recém-formados na direção certa. Sempre foi importante que engenheiros experientes apontassem as desvantagens de uma abordagem e mostrassem aos juniores maneiras melhores ou mais novas de fazer as coisas. Ainda me lembro claramente de um desenvolvedor, apenas dois anos mais velho, me explicando por que eu deveria usar ArrayList e não Vector. Crescer como engenheiro não significa aprender a escrever mais códigos; trata-se de aprender quais perguntas fazer, quais são os compromissos e as questões “depende”, e quais soluções podem ser corretas para um determinado problema.
Então, vamos voltar ao motivo pelo qual estou preocupado com a IA. Estou preocupado que desenvolvedores experientes o adicionem ao seu arsenal de ferramentas para realizar o trabalho, assim como o preenchimento de código IDE, Stack Overflow e Google. Eles aprenderão como (e quando) usá-lo para lhes dar ideias, direcioná-los em uma direção e fazer o trabalho pesado de criar clichês ou pedaços de código comum. Eles aprenderão como treinar a IA para fornecer um código “melhor” (para alguma definição de melhor) ao longo do tempo. Todo esse tempo, eles estão treinando a IA, não treinando desenvolvedores juniores. Na verdade, engenheiros experientes estão sendo incentivados a treinar IA generativa da maneira que faziam. nunca incentivados a investir tempo no treinamento de juniores.
E os juniores – bem, os juniores presumirão que o código gerado pela IA funciona. Os engenheiros experientes estarão tão ocupados treinando a IA que não ajudarão os juniores a subir de nível. Os juniores não terão as ferramentas para melhorar, e os desenvolvedores seniores podem gastar tanto tempo corrigindo bugs em códigos mal implementados dos juniores que a organização pode decidir que os juniores não apenas não são necessários, mas na verdade são um dreno indesejável de produtividade.
Qual é o problema? Certamente, quer estejamos treinando juniores ou treinando IA, o resultado last é o mesmo? Código que funciona para o nosso problema. Claro, e à medida que a IA melhorar, talvez contemos ainda mais com ela. E digamos, para fins de argumentação, que a IA melhore o suficiente para substituir os desenvolvedores juniores. Será bom o suficiente para substituir desenvolvedores experientes? Talvez, mas definitivamente ainda não chegamos lá. Se não for suficiente substituir desenvolvedores e arquitetos experientes, e se não investirmos nos juniores de hoje, não teremos seniores amanhã. Precisaremos de desenvolvedores experientes no futuro próximo, mesmo que seja “apenas” para treinar a IA ou ajudar a criar a próxima geração de ferramentas de IA.
Além do problema do pipeline, quero abordar algo que considero muitas vezes esquecido em nossa indústria. Os desenvolvedores não são máquinas de produção de código. Nosso trabalho não é digitar código. Não me refiro apenas a desenvolvedores experientes; Eu incluo os juniores nisso também. Quando trabalhei em uma equipe que formava pares regularmente, quando period um desenvolvedor com mais de 10 anos de experiência, as pessoas que mais me desafiaram foram os juniores. Sim, aprendi um ótimo acordo com pessoas inteligentes e experientes como Dave Farley e Martin Thompson. O que aprendi com eles muitas vezes foram coisas novas que eu ainda não conhecia ou que confirmaram crenças e ideias que eu já tinha. Mas foram os juniores que realmente me ajudaram a entender o que me importava e por que fiz as coisas que fiz. Os juniores realmente desafiam você como desenvolvedor. Os juniores fazem ótimas perguntas: Por que você fez assim? Por que você rejeitou essa ideia? Em que você está pensando quando está tentando decidir qual dessas abordagens adotar? Por que é difícil fazer esse teste passar?
Essas questões nos ajudam a crescer como desenvolvedores de nível médio e sênior. Por que fez fazemos assim? Será porque uma vez alguém nos mostrou como fazer as coisas dessa maneira e nós apenas seguimos cegamente essa abordagem? Ou descobrimos, após extensa pesquisa no Google e pesquisas no Stack Overflow, após muitas tentativas e erros e eventuais refinamentos, que esta é a melhor maneira de fazer isso? A resposta a isto dir-nos-á muito sobre o quanto compreendemos esta questão e se compreendemos as compensações que estamos a fazer quando seguimos esse caminho. Deve também fazer-nos pensar se precisamos de fazer mais investigação sobre esta abordagem ou ferramenta – Foi actualizada desde que aprendemos esta abordagem? Existe uma maneira mais nova/melhor/mais rápida/mais limpa de fazer a mesma coisa?
É claro que poderíamos simplesmente ficar sentados ponderando sobre essas questões em silêncio e depois continuar fazendo o que estávamos fazendo (ou decidir fazer as coisas de maneira diferente). Mas verbalizar a conversa inside, as dúvidas ou certezas que temos sobre as respostas, não só dará ao júnior alguma visão sobre os nossos processos de pensamento, mas também os ajudará a criar o seu próprio processo para tomar decisões. É perfeitamente aceitável dizer: “Na verdade, não tenho certeza. Eu sempre fiz assim. Deveríamos fazer um pouco de pesquisa para saber se existe uma maneira melhor?” Ou “Bem, no meu último trabalho, tínhamos um limite no número de conexões abertas, então sempre as fecho quando posso. Isso não se aplica muito aqui, mas parece um bom hábito de qualquer maneira. Você consegue pensar em uma razão para não fazer isso? É bom fazer perguntas aos juniores para fazê-los pensar, e é ótimo ter uma conversa bidirecional sobre compensações e decisões de implementação. Deus sabe que todos nós ficamos presos pensando em círculos sobre um problema, apenas para resolvê-lo apenas fazendo uma pergunta. (Muitas vezes nem precisamos da resposta!)
Os idosos sabem que a resposta para tudo é “depende”. Crescer como desenvolvedor significa descobrir cada vez mais coisas das quais “depende”, ser capaz de identificar essas coisas no código, na infraestrutura ou na organização e fazer perguntas para descobrir incógnitas conhecidas. Responder às perguntas de um júnior, ou orientá-lo para a sua própria resposta, ajuda-o na sua própria jornada para descobrir do que “depende” e onde encontrar o equilíbrio nas compensações. Também nos ajuda a compreender melhor os nossos próprios processos e atualizá-los quando necessário.
Uma IA não faz perguntas. Dá respostas. Com confiança. Isso não desafia você. Ele se curva à sua sabedoria quando você expressa uma opinião e ainda assim faz o que quer.
Precisamos da tensão entre idosos e juniores. É isso que nos ajuda a crescer. Como juniores, podemos fazer perguntas, aprendendo por nós mesmos e ajudando os seniores a desafiar as suas suposições. Como idosos, temos muito mais experiência com as sutilezas de por que escolheríamos uma solução específica e quais preferências nós, ou nossa equipe, podemos ter em nossa solução. Mas embora possamos moldar uma IA para nos dar o tipo de resposta que poderíamos ter escrito, a IA não nos vai perguntar: “Mas porque é que queres fazer assim?” ou “Quais são os problemas que o preocupam com esta solução?” Essas questões são as que precisamos para crescer como indivíduos, para criar um código melhor que não apenas funciona, mas atende aos requisitos da empresa, do usuário e da equipe que mantém o código. Criar um bom software program é um esporte de equipe.
(Fiz um vídeo sobre esse assunto também: https://youtu.be/AK9pFlLJwbQ?function=shared.)