Programador Jr. na era da IA
Trabalhei por muitos anos com suporte técnico. Agora, trabalho como desenvolvedor Full Stack.
O início não foi fácil. Havia muita informação para aprender, um novo modelo mental de trabalho, sem os POPs (procedimento operacional padrão) que fizeram parte de tantos anos no suporte, além de uma liberdade que vinha acompanhada de responsabilidade para criar soluções.
O que eu posso dizer, estou sendo absolutamente feliz nesse trabalho.
Na era da IA, tenho a impressão de que as oportunidades para desenvolvedores juniores diminuíram consideravelmente. Parece que essa posição foi, em parte, obliterada pelas IAs. Mesmo assim, quando a oportunidade apareceu, tudo o que eu havia feito até ali me ajudou a ser o melhor candidato para agarrar essa chance.
Cheguei com as inseguranças típicas de quem está começando uma nova carreira: o medo de errar, de não conseguir entregar o que é esperado e de, mesmo entregando, não estar fazendo o suficiente.
Também achei que meu maior desafio seria não conhecer profundamente a stack utilizada. Porém, eu não estava considerando justamente o que me motivou a escrever este artigo: eu sou um desenvolvedor na era da IA.
Eu já programava. Havia criado projetos robustos, com vários repositórios, arquivos, funções, bugs. Também havia experimentado a ótima sensação de resolver um problema que levei horas para entender.
Mas nada disso me preparou para encarar um sistema real, com clientes em produção e milhares de pedidos processados diariamente.
Nos primeiros dias, segui o caminho mais difícil: trabalhei praticamente sem IA, recorrendo a ela apenas para tirar dúvidas sobre assuntos muito específicos.
Porém, percebi que não usar IA hoje me parece semelhante a alguém que, nos anos 2000, se recusasse a usar o Google e continuasse procurando informações página por página em livros e revistas. Ou então, alguém que tivesse um carro à disposição mas preferisse fazer uma viagem a pé, porque "não seria eu quem estaria em movimento, mas sim o carro". Como se utilizar uma ferramenta diminuísse o mérito de chegar ao destino.
Pensando na analogia do carro, a resistência à nova tecnologia começou a fazer cada vez menos sentido. Por isso, a partir do meu terceiro dia, comecei a usar a IA no trabalho.
E, bom, ela codifica, depura, investiga, identifica relações entre funções e arquivos, conecta-se a ferramentas e interage com serviços locais e externos, etc... muito melhor que eu. Em várias dessas tarefas, ela faz rapidamente o que eu conseguiria fazer em muito mais tempo.
Foi obviamente mais fácil trabalhar com a IA me ajudando a entender as relações entre partes do sistema, identificar erros de sintaxe na minha escrita, investigar problemas de lógica e explorar possíveis soluções.
Com ela, consegui avançar em coisas que provavelmente levaria semanas para descobrir sozinho. Gosto de pensar nela como um "super buscador": uma ferramenta que não apenas encontra informações, mas também analisa o que peço e apresenta diferentes caminhos para resolver um problema.
Depois de algum tempo observando toda essa capacidade, comecei a perceber onde estão seus limites.
A IA pode ajudar a interpretar regras de negócio, analisar interfaces e sugerir melhorias de usabilidade. Mas ter acesso ao código e às informações do sistema não significa conhecer automaticamente as necessidades reais dos clientes, as regras que nunca foram documentadas, os hábitos de uso ou as dificuldades que aparecem nos mais variados hardwares que os clientes têm.
E é aí que entra minha experiência.
Não faz sentido competir com as máquinas na escrita de código. Nem o Magnus Carlsen (um alienígena do xadrez) consegue vencer as máquinas na especialidade dele, imagine se eu, um desenvolvedor jr, consigo competir com uma IA justamente naquilo em que ela é tão boa.
Mas escrever código é apenas parte do trabalho. Eu entro onde a IA não consegue entrar, ou entra com muita dificuldade.
Na necessidade do cliente, na especificidade de uma nova função em uma tela, na necessidade de duas ou três formas de fazer uma ação porque existem vários tipos de dispositivos e clientes e claro, a entrega precisa atender a todos.
Depois de algum tempo me sentindo um impostor — afinal, a IA parece saber milhares de vezes mais sobre código do que eu — e não, esse travessão não é de uma IA — comecei a entender algo importante: toda a minha trajetória profissional contribuiu para que eu chegasse até aqui com o entendimento de negócio que faz a diferença.
Por mais que a IA escreva boa parte do código, meu papel não se resume a revisar o que ela escreve. Preciso compreender o problema, definir o que esperamos da solução, fornecer o contexto necessário, avaliar as alternativas e verificar se o resultado realmente atende ao objetivo, se os testes fazem sentido, se o QA consegue reproduzir o que ela propõe, etc.
Em outras palavras, para que a ideia de um card se transforme em software, não basta gerar o código, é preciso entender o propósito da funcionalidade, as regras, o resultado esperado e principalmente, as limitações.
A IA já está aqui, mas alguém precisa transformar uma necessidade real em orientação, decisão e critério para que ela ajude a construir a solução certa.
Ainda tenho muito a aprender sobre programação, arquitetura e engenharia de software, a IA não é uma desculpa para deixar de aprender sobre linguagem ou lógica ou qualquer outro fundamento, mas também não vou ignorar o potencial de uma ferramenta que pode acelerar tanto o processo do software.
Espero que a IA fique cada vez melhor. Eu vou continuar fazendo o meu melhor para descobrir onde está o limite do que podemos construir, por enquanto, o limite parece estar no horizonte, ou como diria na aula de cálculo (alerta de gatilho), tende ao infinito.