Este texto foi desenvolvido a partir de uma conversa com uma LLM. As reflexões, exemplos e conclusões surgiram durante o diálogo, e o texto final foi revisado e adaptado pelo autor.

Tenho pensado bastante sobre esse momento que estamos vivendo com agentes de IA e LLMs.

Nos últimos meses apareceu uma quantidade enorme de discussões sobre substituição de programadores, fim do desenvolvimento de software, prompt engineering, agentes autônomos e outras previsões apocalípticas ou messiânicas que parecem surgir toda vez que alguma tecnologia nova aparece.

Mas quanto mais observo o que está acontecendo, mais tenho a impressão de que algumas figuras antigas da computação estão voltando a fazer sentido.

Durante muitos anos me enxerguei como um “programador cowboy”. Não no sentido romantizado do sujeito genial que programa sozinho em uma garagem, mas naquele perfil de quem aprende a lidar com sistemas reais, monta a própria infraestrutura, resolve problemas com os recursos disponíveis e acaba transitando por áreas diferentes porque alguém precisa fazer o trabalho.

A pessoa que configura o servidor, organiza os backups, analisa os logs, automatiza processos, cria ferramentas internas e, eventualmente, escreve software.

Por muito tempo achei que esse perfil estava desaparecendo. O mercado parecia caminhar para uma especialização cada vez maior. Surgiam especialistas em frameworks específicos, plataformas específicas e nuvens específicas.

Durante os anos 1990 e o início dos anos 2000 era comum encontrar o webmaster.

Era uma figura curiosa. Cuidava do servidor, escrevia HTML, mexia no banco de dados, configurava o correio eletrônico, ajustava DNS, escrevia scripts e, quando necessário, ainda produzia conteúdo para o site.

Com o crescimento da indústria de software veio a especialização.

Primeiro surgiram separações mais claras entre infraestrutura e desenvolvimento. Depois vieram os desenvolvedores backend e frontend, cada vez mais focados em partes específicas do sistema. Em algum momento surgiu a figura do full-stack, tentando reunir novamente conhecimentos que haviam sido separados.

Pouco depois apareceu o movimento DevOps, que talvez tenha sido o primeiro sinal de que a fragmentação excessiva tinha seus custos. Não porque desenvolvimento e operações deixassem de existir como especialidades, mas porque alguém precisava entender a interação entre elas.

Durante algum tempo parecia que o caminho natural seria uma especialização cada vez maior. Cada profissional responsável por uma parte menor do sistema, mas com um conhecimento mais profundo daquele domínio específico.

As LLMs produzem um efeito curioso sobre essa tendência.

Elas não eliminam a necessidade de especialistas. Continuamos precisando de pessoas que entendam profundamente bancos de dados, redes, segurança ou sistemas distribuídos.

Mas elas reduzem o custo de transitar entre áreas.

Um desenvolvedor backend consegue explorar uma tarefa de frontend. Um administrador de sistemas consegue produzir automações complexas. Um analista consegue construir ferramentas que antes exigiriam uma equipe inteira.

De certa forma, parece que estamos assistindo ao retorno do generalista. Não o generalista que sabe um pouco de tudo e muito de nada, mas aquele que consegue circular entre diferentes territórios porque conta com ferramentas capazes de reduzir o atrito da jornada.

Talvez o tropeiro digital seja uma evolução moderna do velho webmaster, incorporando também parte da visão que o movimento DevOps tentou resgatar. Menos preocupado em dominar cada detalhe técnico e mais preocupado em conectar conhecimentos, sistemas e pessoas para resolver problemas concretos.

Agora tenho dúvidas.

Talvez esse perfil não esteja desaparecendo. Talvez esteja apenas mudando de forma.

A imagem que me veio não foi a do cowboy americano, mas a do tropeiro dos pampas.

O tropeiro era alguém que conhecia caminhos, fronteiras, distâncias e riscos. Não necessariamente construía as cidades, mas fazia a ligação entre elas. Transportava coisas, conectava lugares e acumulava um conhecimento que dificilmente aparecia em mapas.

Acho que existe algo parecido acontecendo na tecnologia.

As LLMs conseguem produzir código numa velocidade impressionante. Conseguem explicar conceitos, resumir documentação, sugerir arquiteturas e até gerar aplicações inteiras.

Isso muda bastante coisa.

Mas existe uma diferença entre conhecer algo e já ter vivido suas consequências.

A IA consegue explicar como fazer backup.

Ela não descobriu às três da manhã que o backup estava corrompido.

Ela consegue explicar observabilidade.

Ela não passou horas tentando descobrir por que um sistema inteiro ficou lento por causa de uma consulta esquecida.

Ela consegue sugerir arquiteturas distribuídas.

Ela não precisou operar uma delas durante anos.

Talvez por isso eu ache que o conhecimento está deixando de ser o principal diferencial.

O conhecimento continua importante. Muito importante.

Mas ele deixou de ser escasso.

O que continua escasso é experiência.

Mais especificamente: julgamento.

Saber quando algo é uma boa ideia.

Saber quando uma solução está complicada demais.

Saber quando um problema técnico é, na verdade, um problema organizacional.

Saber quando uma tecnologia nova resolve algo e quando apenas adiciona camadas de complexidade.

Boa parte do trabalho começa a migrar para esse espaço.

Curiosamente, isso também muda um pouco a forma como vejo programação.

Muita gente trata programação como produção de código.

Nunca achei que fosse.

Programar sempre me pareceu mais próximo de desenvolver uma forma de pensar.

Uma forma de enxergar sistemas, dependências, limitações e possibilidades.

O código era apenas a consequência.

E talvez seja justamente por isso que ainda fico cético quando vejo afirmações de que a IA irá inovar da mesma forma que seres humanos inovam.

Porque existe uma diferença importante entre produzir respostas e produzir perguntas.

As LLMs são extraordinárias para reorganizar conhecimento existente.

Mas muitas das melhores ideias que encontrei ao longo dos anos não surgiram porque alguém tinha uma resposta melhor.

Surgiram porque alguém olhou para uma prática considerada normal e perguntou:

“Por que fazemos isso desse jeito?”

Ou pior:

“Será que precisamos fazer isso?”

Boa parte das melhores soluções que encontrei não veio de adicionar algo.

Veio de remover.

Remover uma dependência.

Remover uma camada.

Remover uma abstração.

Remover uma complexidade que todo mundo já aceitava como inevitável.

Existe um momento curioso que qualquer pessoa que trabalha há bastante tempo com tecnologia provavelmente conhece.

Você está olhando um problema, andando na rua, tomando café, lendo logs ou revisitando algum código antigo.

De repente acontece aquele momento.

“Aha!”

Não exatamente uma resposta.

Uma mudança de perspectiva.

Uma reorganização do problema.

A sensação de que alguma premissa que parecia sólida talvez nunca tenha sido necessária.

Tenho a impressão de que esse tipo de coisa continua vindo da experiência acumulada em contato com problemas reais.

Talvez seja justamente aí que o tropeiro digital encontre seu espaço.

Não como alguém que compete com máquinas para escrever código mais rápido.

Nem como alguém que tenta decorar mais informação do que uma base de treinamento inteira.

Mas como alguém que circula entre sistemas, organizações, ferramentas e ideias diferentes.

Alguém que acumula contexto.

Alguém que conhece os caminhos.

Alguém que sabe quando confiar no mapa e quando ignorá-lo.

Porque se há algo que a experiência ensina é que o território quase nunca é exatamente igual ao desenho.