Eu assisti ao vídeo do Henrique Bastos sobre o impacto da inteligência artificial no trabalho de quem desenvolve software e me identifiquei bastante com o que ele falou.

Só depois entendi que o vídeo é uma reação ao excelente Não Me Importo Mais Com IA, do Lucas Montano. Os dois vídeos partem de uma inquietação parecida: o que acontece com a motivação de quem gosta de programar quando a IA faz, em um prompt, uma parte do trabalho que antes exigia estudo, pesquisa e várias tentativas?

O vídeo do Henrique se chama Reflexão sobre “Não me importo mais com IA”. Ele reage aos argumentos do Lucas sem simplesmente discordar. Na verdade, os dois acabam formando uma conversa muito boa: Lucas dá nome à perda de satisfação técnica e Henrique mostra como essa mudança também pode abrir espaço para curiosidade, experimentação e problemas mais interessantes.

Eles não ignoram as mudanças no mercado nem fingem que nada está acontecendo. A ideia é outra: talvez este seja justamente um bom momento para lembrar por que começamos a programar.

O medo de perder o sentido

É fácil entender a preocupação. Se uma IA consegue escrever um programa a partir de uma descrição, o que sobra para a pessoa que passou anos aprendendo a programar?

Essa pergunta aparece de várias formas:

• ainda vale a pena estudar uma linguagem nova?
• ainda precisamos aprender algoritmos?
• se a IA escreve o código, o desenvolvedor não virou apenas alguém que escreve prompts?
• o que acontece com a satisfação de resolver um problema?

A resposta do Henrique me pareceu muito honesta: o trabalho do programador nunca foi apenas digitar código. Existe alguém com um problema, uma necessidade ou uma ideia. O código é uma forma de organizar uma solução para essa situação.

Isso parece uma distinção pequena, mas muda bastante a conversa. O código é importante, porém é um meio. O objetivo continua sendo entender o problema, pensar em uma solução, experimentar, descobrir o que funciona e entregar algo útil.

O código sempre foi um custo

Uma das partes de que mais gostei foi a ideia de que o código é um custo do processo. Antes da IA, uma boa parte do nosso tempo era gasta escrevendo código, pesquisando documentação, tentando fazer uma biblioteca funcionar e descobrindo por que uma solução aparentemente simples não funcionava.

Esse trabalho ainda pode ser prazeroso. Para muita gente, é justamente a parte divertida. Mas ele também pode ser um obstáculo entre uma ideia e um experimento.

Quantas ideias deixamos de testar porque não tínhamos tempo? Quantos projetos foram reduzidos a uma prova de conceito pequena porque a vida estava corrida? Quantas vezes escolhemos a solução mais familiar não porque era a melhor, mas porque era a única que conseguiríamos terminar dentro do prazo?

A IA diminui esse custo inicial. Uma ideia que antes exigia dias de pesquisa pode virar um protótipo em algumas horas. Uma pessoa que conhece Python pode explorar Rust, Go ou outra linguagem com ajuda para entender a sintaxe e os padrões básicos.

Isso não significa que a IA constrói automaticamente um software confiável. Significa que ficou mais barato descobrir se uma ideia merece nossa atenção.

Lucas descreve uma sensação que achei muito familiar: antigamente, aprender uma tecnologia nova tinha uma recompensa própria. A pessoa lia a documentação, baixava um SDK, implementava uma funcionalidade e via aquilo aparecer na tela. Havia uma satisfação técnica em dominar algo que não era fácil para todo mundo.

Quando uma IA resolve a mesma tarefa com um prompt, essa recompensa pode desaparecer. Não necessariamente porque deixamos de gostar de tecnologia, mas porque deixamos de encontrar problemas difíceis o bastante para nos desafiar.

A saída proposta pelos dois vídeos não é abandonar a programação. É procurar problemas melhores. Se a ferramenta resolve o exercício simples, posso tentar construir algo mais completo, pensar em automações, investigar limitações ou criar um sistema que precise de várias etapas e validações.

A IA como ferramenta de aprendizagem

O ponto que mais conversa com a minha experiência é usar a IA não apenas para produzir código, mas para aprender.

Em vez de passar por uma sequência longa de aulas antes de experimentar alguma coisa, posso pedir uma explicação, fazer perguntas, solicitar um exemplo pequeno e testar uma variação. Depois, posso comparar a resposta com o que já sei e investigar o que ainda não entendi.

Esse ciclo é muito poderoso:

1. escolho um assunto que quero compreender;
2. peço uma explicação adequada ao meu nível;
3. faço perguntas sobre o que ficou confuso;
4. crio um exemplo pequeno;
5. modifico o exemplo e observo o resultado;
6. verifico as respostas em fontes confiáveis;
7. registro o que aprendi.

A IA funciona quase como um tutor disponível para uma conversa. Ela não substitui livros, documentação, cursos ou a prática deliberada. Mas pode reduzir bastante o tempo entre uma dúvida e o primeiro experimento.

Também pode revelar lacunas no nosso conhecimento. Quando pedimos para a IA explicar uma solução e não conseguimos avaliar se a explicação está correta, descobrimos um assunto que precisamos estudar melhor.

Não é apenas escrever um prompt

Existe uma tentação de resumir a nova forma de programar a “saber escrever bons prompts”. Para mim, isso reduz demais a questão.

Um prompt não substitui a compreensão do problema. Não escolhe sozinho uma arquitetura adequada. Não define o que significa uma resposta correta. Também não sabe, por conta própria, quais riscos são aceitáveis em um sistema que outras pessoas vão usar.

O desenvolvedor continua precisando pensar em estados, regras, testes, segurança, desempenho, manutenção e experiência de quem usa o produto. A diferença é que agora pode contar com uma ferramenta para explorar mais caminhos em menos tempo.

A conversa com a IA precisa ser uma colaboração guiada por conhecimento. Quando a ferramenta apresenta uma solução, eu preciso conseguir perguntar:

• por que isso funciona?
• quais são as limitações?
• o que pode dar errado?
• como eu testo essa hipótese?
• existe uma alternativa mais simples?

Quanto mais fundamentos temos, melhores são as perguntas e mais fácil fica perceber uma resposta superficial.

Do prompt ao ciclo de validação

Lucas também chama atenção para uma diferença importante entre pedir um código e construir um processo. Em um problema mais difícil, não basta escrever um prompt e esperar. É preciso pensar nos exemplos de entrada, definir o que deve ser validado, criar testes e observar os resultados.

A IA pode trabalhar dentro de um ciclo mais longo:

1. formular uma hipótese;
2. pedir uma implementação inicial;
3. executar testes e avaliações;
4. analisar o que falhou;
5. ajustar o contexto, o pedido ou as ferramentas;
6. repetir até chegar a um resultado confiável.

Esse processo tem nomes técnicos, como harness e avaliação, mas a ideia é simples: não basta pedir para a IA fazer; precisamos criar um ambiente em que seja possível conferir se ela fez o que deveria.

Essa é uma tarefa que exige pensamento sistemático. Também é uma boa explicação para a importância contínua dos fundamentos: quem entende o problema consegue criar exemplos melhores, identificar casos extremos e decidir se o resultado realmente atende ao objetivo.

O ciclo de feedback ficou mais curto

Há alguns anos, muitas práticas importantes de engenharia de software pareciam difíceis de aplicar no dia a dia. Arquitetura, testes automatizados, TDD e ciclos rápidos de feedback eram ideias conhecidas, mas frequentemente acabavam sacrificadas pela falta de tempo.

Com a IA, alguns experimentos ficaram mais baratos. Posso criar uma pequena prova de conceito, comparar duas abordagens, testar uma biblioteca ou jogar fora uma tentativa sem transformar cada decisão em um compromisso enorme.

Isso combina muito com a maneira como gosto de aprender: fazendo perguntas, mexendo nas coisas e observando o resultado. A IA encurta o caminho entre “seria interessante descobrir como isso funciona” e “agora tenho um exemplo para estudar”.

O cuidado é não confundir velocidade com qualidade. Um protótipo rápido ainda precisa ser revisado. Código descartável deve ser reconhecido como descartável. E uma solução que vai para produção continua merecendo testes, documentação e manutenção.

Especialidade e visão ampla

Lucas recomenda que a pessoa continue especialista em alguma área, mas desenvolva também conhecimentos ao redor dela. É a ideia de uma carreira em T: uma especialidade profunda acompanhada de alguma familiaridade com as áreas que se conectam a ela.

Para um desenvolvedor mobile, isso pode significar entender melhor backend, APIs, bancos de dados, infraestrutura e produto. Para alguém de backend, pode ser útil conhecer a experiência de quem usa a aplicação, as limitações do frontend e as necessidades do negócio.

A IA torna essa ampliação mais acessível, mas não elimina a necessidade de profundidade. Pelo contrário: a especialidade ajuda a julgar as soluções e o conhecimento amplo ajuda a enxergar o sistema inteiro.

Também muda a relação com o produto. Talvez a pessoa não precise se identificar apenas com o código que escreveu, mas com o problema que o software resolve e com a experiência de quem usa aquilo. Essa conexão pode devolver significado ao trabalho.

Desidentificar-se do que fazemos

Talvez a parte mais profunda do vídeo seja a reflexão sobre identidade. Quando alguém passa muitos anos sendo reconhecido como programador, é compreensível sentir que uma ferramenta que escreve código ameaça uma parte importante de quem essa pessoa é.

Mas nós não somos apenas o trabalho que fazemos. Somos nossa história, nossas relações, nossas curiosidades e tudo o que aprendemos ao longo do caminho. Programar é uma prática, uma habilidade e uma forma de resolver problemas — não a totalidade de uma pessoa.

Essa separação pode ajudar a enxergar a mudança com mais tranquilidade. Se a IA assumir uma parte do trabalho repetitivo, talvez isso abra espaço para aprender assuntos novos, construir projetos que antes pareciam grandes demais e voltar a experimentar por curiosidade.

Olhar para o copo meio cheio

Não acho que seja necessário fingir que os riscos não existem. O mercado muda, algumas tarefas ficam menos valorizadas e novas habilidades passam a ser exigidas. Tudo isso pode ser difícil.

Ainda assim, prefiro olhar para a oportunidade concreta: hoje consigo testar mais ideias, estudar de forma mais personalizada e explorar partes do desenvolvimento que antes ficavam fora do meu alcance por falta de tempo.

A IA não tornou o aprendizado desnecessário. Ela tornou possível aprender fazendo mais cedo. Não eliminou a necessidade de pensar. Tornou mais importante saber o que perguntar, como verificar e qual problema realmente vale a pena resolver.

Começamos a programar, muitas vezes, pela curiosidade. Queríamos saber como as coisas funcionavam. Queríamos criar algo e ver uma ideia ganhar vida na tela. Talvez a melhor maneira de atravessar este momento seja recuperar um pouco desse olhar de criança: perguntar “como isso funciona?”, experimentar sem medo e continuar aprendendo.

Para mim, esse é o impacto mais interessante da IA no trabalho de desenvolvimento: ela não precisa tirar o sentido de programar. Pode devolver o tempo necessário para que a gente programe com mais curiosidade, mais qualidade e mais liberdade.