Passei a vida aprendendo a escrever código. Agora estou aprendendo quando não escrever.

IA, a história da programação e o que significa ser desenvolvedor na próxima era da computação.

Tenho pensado muito sobre o futuro do desenvolvimento de software. Durante a maior parte da minha vida, fui programador. Escrever código, depurar sistemas, entender como as coisas funcionam e resolver problemas sempre foram mais do que apenas um trabalho para mim. Eu amo programar. Amo o terminal do Linux. Amo descobrir por que algo não está funcionando e a satisfação de finalmente resolver um problema técnico complicado.

E agora, com a IA se tornando cada vez mais capaz de escrever software, às vezes me pego pensando: estou vendo a profissão à qual dediquei minha vida se tornar obsoleta?

É uma sensação estranha. Sei o quanto a IA é capaz de fazer porque eu mesmo a uso. Estou construindo coisas mais rápido, experimentando mais e passando menos tempo escrevendo código. Estou animado com as possibilidades. Mas também há algo desconfortável em ver uma máquina realizar um trabalho que levei anos para dominar.

Quanto mais penso nisso, porém, mais percebo que já passamos por transformações como esta antes. Talvez estejamos olhando para esta pela perspectiva errada.

Já programamos computadores com cabos

Na década de 1940, programar computadores como o ENIAC envolvia conectar cabos fisicamente e configurar chaves. Imagine isso. Mudar um programa podia significar reconfigurar fisicamente a máquina.

Depois vieram os computadores com programa armazenado e as linguagens assembly. Em vez de configurar o hardware manualmente, os programadores podiam escrever instruções simbólicas que representavam operações da máquina. Foi uma abstração revolucionária.

Depois vieram as linguagens de programação de alto nível e os compiladores. Os programadores não precisavam mais expressar tudo em termos de registradores, endereços de memória e instruções de máquina. Podiam descrever algoritmos usando linguagens como FORTRAN e, mais tarde, C.

Os compiladores mataram os programadores? Não. Eles mudaram o que os programadores precisavam saber. O assembly não desapareceu. Tornou-se uma habilidade mais especializada. E os programadores que entendiam o hardware subjacente frequentemente mantinham uma vantagem quando desempenho, confiabilidade ou problemas incomuns exigiam um conhecimento mais profundo.

Depois vieram mais linguagens, runtimes gerenciados, garbage collection, frameworks e ferramentas de desenvolvimento cada vez mais sofisticadas. Cada nova abstração permitiu que mais pessoas criassem software sem dominar todas as camadas abaixo dela. Algumas habilidades se tornaram menos comuns. Alguns tipos de trabalho desapareceram. Especialidades inteiramente novas surgiram. E o número de coisas que podíamos realizar com computadores se expandiu enormemente.

Não paramos de programar. Mudamos a forma como programamos.

Entender o que está por baixo ainda importa

Lembro de um dos meus primeiros empregos, quando me deparei com um sério problema de desempenho envolvendo concatenação de strings. O código parecia perfeitamente razoável. Mas, por baixo dos panos, a concatenação repetida criava novas strings, copiava memória e deixava objetos antigos para serem recolhidos. O que parecia uma operação simples se tornava cada vez mais cara.

A solução não era particularmente complicada depois que entendi o que realmente estava acontecendo. O importante não era conhecer a sintaxe. Era entender o sistema. E isso é algo que carreguei ao longo de toda a minha carreira.

Uma abstração pode esconder a complexidade, mas não a elimina.

Um programador não precisa necessariamente entender todas as camadas de um computador. Mas saber o que está por baixo pode fazer uma diferença enorme quando algo não funciona como esperado. Hoje, um desenvolvedor pode construir uma aplicação inteira sem saber muito sobre alocação de memória, arquitetura de CPU, internals do sistema operacional ou redes. E isso é uma conquista incrível. Mas, quando algo dá errado, esse entendimento mais profundo pode ser a diferença entre aplicar mais um workaround e realmente resolver o problema.

Acredito que o mesmo valerá para a IA. A IA consegue gerar código, mas ele será eficiente? Seguro? Escalável? Fácil de manter? Vai se comportar corretamente diante de falhas? Às vezes, sim. Às vezes, ela vai produzir algo que parece absolutamente convincente e está fundamentalmente errado.

A experiência nos ajuda a reconhecer a diferença. Não porque programadores experientes sejam necessariamente melhores em escrever prompts, mas porque têm um entendimento mais profundo de como uma boa solução deve ser.

Talvez a IA seja a próxima grande abstração

Vejo a IA como algo comparável à transição da linguagem assembly para as linguagens de programação de alto nível, embora potencialmente muito mais disruptiva. Estamos caminhando para um mundo em que descrever o que queremos pode se tornar mais importante do que especificar cada detalhe de como implementar.

Isso não significa que a implementação se torna irrelevante. Significa que a interface entre a intenção humana e a execução da máquina está mudando de novo. Ontem, traduzíamos ideias em linguagens de programação. Hoje, a IA pode cada vez mais fazer essa tradução por nós. Amanhã, talvez muitas pessoas que criam software nem saibam escrever código tradicional.

E isso não é necessariamente ruim. Não paramos de criar software quando os compiladores chegaram. Criamos mais software, para mais pessoas, resolvendo problemas que antes seriam caros ou difíceis demais de enfrentar.

Mas há uma diferença importante. Um compilador traduz instruções de acordo com regras formalmente definidas. A IA interpreta intenções, toma decisões e gera implementações possíveis. Não se espera que um compilador entenda errado o que significa um operador de adição. A IA, por outro lado, pode entender errado o que estamos tentando realizar. Ela também pode produzir uma implementação tecnicamente correta de uma ideia fundamentalmente errada. Isso torna esta transição diferente de tudo o que já vivemos.

E isso levanta uma pergunta que acho que ninguém consegue responder com confiança ainda: a IA vai criar mais oportunidades para programadores, como as abstrações anteriores fizeram, ou vai acabar reduzindo a necessidade deles?

Eu não sei. Alguns empregos de programação podem desaparecer. Algumas habilidades certamente vão perder valor. E é possível que a IA transforme o mercado de trabalho de forma muito mais dramática do que as mudanças tecnológicas anteriores.

Mas não acredito que a necessidade de entender problemas, projetar sistemas confiáveis, avaliar soluções e tomar decisões técnicas vá desaparecer simplesmente porque escrever código ficou mais fácil. A economia do desenvolvimento de software pode mudar completamente. A complexidade dos problemas que estamos tentando resolver vai continuar.

O desconforto de não escrever mais o código

Há também um lado pessoal nessa transformação. Passei anos aprendendo linguagens de programação, entendendo sistemas, melhorando minha capacidade de resolver problemas e descobrindo formas mais eficientes de construir software. Sempre gostei de colocar a mão na massa. Mesmo depois de assumir cargos de liderança, nunca deixei completamente de ser desenvolvedor.

Então há algo estranhamente desconfortável em pedir à IA para implementar algo que sei que eu mesmo poderia escrever. Às vezes, parece que não estou mais fazendo o trabalho.

Mas então me lembro de outra transição na minha carreira. Quando me tornei CTO, inicialmente lutei com uma sensação parecida. Eu não escrevia mais tanto código. Outras pessoas implementavam as soluções enquanto eu passava mais tempo discutindo arquitetura, removendo obstáculos, tomando decisões e ajudando os times a andar mais rápido. No começo, isso nem sempre parecia produtivo. Eu estava acostumado a medir minha contribuição pelo que eu mesmo construía. Se eu não estava escrevendo código, com o que exatamente eu estava contribuindo?

Com o tempo, percebi que minha experiência tinha se tornado útil de outra forma. Eu conseguia reconhecer problemas antes que acontecessem. Conseguia sugerir uma abordagem que evitava semanas de trabalho desnecessário. Conseguia enxergar consequências arquiteturais que não eram imediatamente óbvias. Conseguia ajudar as pessoas a tomar decisões melhores, não porque digitava mais rápido ou conhecia mais sintaxe, mas porque já tinha enfrentado problemas parecidos.

Eu não estava resolvendo menos problemas. Estava resolvendo-os em outro nível.

E hoje a IA está trazendo de volta essa mesma sensação. Só que, desta vez, em vez de orientar outros desenvolvedores, muitas vezes estou orientando um sistema de IA. Descrevo o objetivo. Estabeleço restrições. Reviso a solução proposta. Questiono decisões. Identifico riscos. Às vezes mudo toda a abordagem. E a implementação pode acontecer a uma velocidade que seria inimaginável poucos anos atrás.

Nem sempre estou escrevendo o código. Mas ainda estou usando tudo o que aprendi sobre escrever código. E estou começando a perceber que talvez eu não devesse medir minha contribuição pela quantidade de código que eu mesmo produzo.

"Talk is cheap. Show me the code."

Existe uma frase famosa no desenvolvimento de software: "Talk is cheap. Show me the code." ("Falar é fácil. Me mostre o código.") Por anos, ela capturou algo fundamental sobre a nossa profissão. Ideias são fáceis. Fazê-las funcionar é difícil. Qualquer um pode descrever uma aplicação. Construir uma que realmente funcione é outra história.

Mas o que acontece quando a IA consegue transformar uma descrição em software funcionando? Isso torna o falar mais valioso?

Não exatamente. Uma ideia vaga continua sendo uma ideia vaga. Um requisito incompleto ainda leva a uma solução incompleta. E um software que parece funcionar não é necessariamente um software que funciona de forma correta, confiável ou segura.

O que muda é o custo de produzir uma implementação. Quando escrever código fica dramaticamente mais barato, a capacidade de decidir o que construir, por que construir e se o resultado está realmente correto se torna cada vez mais importante. É aí que a experiência continua a fazer diferença.

Saber quando usar um banco de dados em vez de um cache. Entender por que um sistema distribuído pode falhar. Reconhecer um problema de concorrência. Questionar uma dependência desnecessária. Antecipar o que acontece quando um serviço externo fica indisponível. Esses não são meros problemas de sintaxe. São problemas de engenharia.

Claro, a IA pode acabar se tornando cada vez mais capaz de lidar com essas decisões também. Não acho que devemos assumir que as limitações de hoje serão permanentes. Mas a capacidade de gerar uma solução e a responsabilidade de aceitar essa solução são duas coisas diferentes. Mesmo quando a IA faz a implementação, alguém — ou alguma organização responsável — precisa determinar se o sistema atende aos seus objetivos. E acho que essa distinção vai se tornar cada vez mais importante.

Se a IA escreve o código, eu ainda estou programando?

Esta é a pergunta à qual sempre volto. Se programar significa digitar instruções em uma linguagem específica, talvez uma parte substancial desse trabalho acabe sendo automatizada. Mas é isso mesmo que programar significa?

Quando eu programava em C, não pensava nas instruções de máquina individuais que o compilador iria gerar. Quando usei uma linguagem gerenciada, não alocava e liberava manualmente cada pedaço de memória. Quando fiz deploy de uma aplicação usando containers, não configurei pessoalmente cada recurso de baixo nível do sistema operacional. Eu dependia de abstrações. E continuava programando. Por que a IA deveria ser necessariamente diferente?

Se eu entendo um problema, projeto uma abordagem, estabeleço restrições, conduzo uma implementação, investigo seu comportamento e verifico que ela funciona, deixo de estar programando só porque não digitei o código-fonte? Acho que não.

Talvez estejamos confundindo a atividade de escrever código com a disciplina mais ampla de criar software. E talvez a IA finalmente nos force a separar as duas. Posso escrever menos linhas de código. Posso passar mais tempo explicando intenções, avaliando alternativas, revisando arquitetura e validando resultados. Mas essas atividades sempre fizeram parte da engenharia de software. A diferença é que elas podem se tornar uma parte muito maior do trabalho.

E preciso admitir uma coisa: estou começando a gostar. Porque as ideias não param de surgir. Os problemas não deixam de ser interessantes. E agora consigo explorar mais soluções sem passar dias ou semanas implementando cada detalhe sozinho.

Isso não significa que quero abandonar o terminal ou parar de escrever código. Ainda gosto dos dois. Significa simplesmente que estou descobrindo outra forma de usar o conhecimento que acumulei.

Talvez precisemos redefinir o que é um programador

Talvez um dos maiores erros que estamos cometendo seja assumir que programar significa escrever código. Escrever código é uma forma de comunicar instruções a uma máquina. Não é o objetivo final.

O objetivo é resolver problemas.

Já passamos de configurar hardware fisicamente para instruções de máquina, linguagens assembly, linguagens de alto nível, frameworks e abstrações cada vez mais sofisticadas. Agora estamos começando a expressar soluções em linguagem natural.

Isso abre uma oportunidade enorme. Pessoas que antes não conseguiam criar software agora podem ser capazes de construir aplicações úteis. Engenheiros experientes podem passar menos tempo em implementação repetitiva e mais tempo investigando problemas difíceis. Times menores podem conseguir realizar o que antes exigia organizações muito maiores. E tipos inteiramente novos de software podem se tornar viáveis.

Nada disso garante que a transição será fácil. Certamente não garante que todo programador vai manter seu emprego. E não significa que o conhecimento tradicional de programação continuará igualmente valioso em todos os contextos. Mas acho difícil acreditar que tornar o software mais fácil de produzir vá tornar irrelevantes a criatividade humana, a curiosidade, o entendimento técnico e a capacidade de resolver problemas.

Não sei como será a profissão de desenvolvimento de software daqui a dez anos. Não sei quantos programadores as empresas vão precisar, quais linguagens vamos usar ou quanto software a IA vai acabar produzindo de forma autônoma. E não vou fingir que essas incertezas não são preocupantes.

Mas acredito cada vez mais que minha experiência não está simplesmente se tornando obsoleta. Ela está se tornando útil de outra forma. Já vivi essa transformação uma vez, quando deixei de escrever a maior parte do código eu mesmo para ajudar outras pessoas a construir sistemas melhores. Agora estou vivendo isso de novo. Desta vez, a implementação é cada vez mais feita pela IA.

Talvez o programador do futuro não seja definido pela quantidade de código que escreve. Talvez seja definido pela eficácia com que consegue transformar uma ideia em um sistema confiável e funcionando. E talvez, depois de passar uma vida inteira aprendendo a dizer aos computadores como fazer as coisas, estejamos entrando em uma era em que podemos passar mais tempo pensando no que vale a pena fazer.

A sintaxe pode mudar. As ferramentas podem mudar. Até a profissão pode mudar a ponto de ficar irreconhecível. Mas os problemas ainda precisam ser resolvidos.

E essa é a parte da programação que eu sempre amei mais.