--- title: "A Solidão do Dev AI-Native: Onde termina o engenheiro e começa o curador de heurísticas?" author: "Ricardo Pupo Larguesa" date: "2026-04-22 08:00:00-03" category: "Opinião" url: "http://aintuicao.scale.press/portal/aintuicao/post/2026/04/22/a-solidao-do-dev-ai-native-onde-termina-o-engenheiro-e-comeca-o-curador-de-heuristicas/md" --- Na semana passada, um aluno me apresentou um algoritmo de roteamento perfeitamente otimizado em Python. Mas então eu pedi que ele alterasse uma regra de negócio específica no laço principal e ele travou. O código inteiro havia sido gerado pelo Claude. Funcionava muito bem na máquina dele, mas o aluno havia se tornado um espectador do próprio projeto. Essa cena na sala de aula ilustra uma transição estrutural pesada que estamos vivendo nas trincheiras da engenharia de software. O desenvolvedor moderno, armado com ferramentas como Cursor, Copilot e OpenCode, está deixando de ser um digitador de lógica para se tornar um curador de heurísticas. É uma mudança solitária. Você passa horas revisando blocos de código que não escreveu, [acumulando uma dívida epistêmica perigosa](https://scale.press/portal/aintuicao/post/2026/02/25/o-perigo-da-divida-epistemica-por-que-o-copilot-esta-criando-programadores-frageis) caso não entenda as entrelinhas da arquitetura gerada. ## Sintaxe contra Entropia Muitos me perguntam se ainda faz sentido ensinar sintaxe básica ou se deveríamos migrar direto para a análise de provas de conceito. A resposta é que ensinar sintaxe hoje atende a um propósito diferente. Nós não aprendemos a linguagem para escrever mais rápido. Aprendemos para conseguir frear a entropia gerada pela máquina. Modelos de linguagem operam por predição. Eles não são responsáveis por segurança corporativa, não sentem o impacto de um vazamento de memória em produção e não têm contexto implícito da arquitetura legada da sua empresa. Um desenvolvedor sênior que aprende a orquestrar IAs multiplica sua produtividade de forma inquestionável. Mas ele só consegue fazer isso porque usa sua experiência em sintaxe e padrões de projeto para auditar o que a IA cospe. Sem essa revisão crítica, o código gerado injeta vulnerabilidades no sistema. Você perde o controle da entropia. ## A obsessão pelo modelo perfeito Essa ilusão de que a ferramenta fará todo o trabalho afeta também a própria engenharia de Machine Learning. Estamos vendo uma corrida desenfreada por métodos de fine-tuning cada vez mais exóticos. Desenvolvedores perdem semanas tentando implementar novidades enquanto ignoram fundamentos básicos. Um preprint recente submetido ao arXiv em janeiro de 2026, intitulado *[A Unified Study of LoRA Variants](https://arxiv.org/abs/2601.22708)* (He et al.), expõe essa falha de raciocínio com clareza matemática. Os pesquisadores avaliaram empiricamente diversas variações arquiteturais do LoRA. A conclusão é um balde de água fria no hype: o LoRA padrão, quando você simplesmente ajusta a taxa de aprendizado (learning rate) com competência, empata ou supera as variantes complexas. Existem ferramentas específicas muito úteis, como o LoRA-FA (apresentado no paper *[Efficient and Effective Low Rank Representation Fine-tuning](https://arxiv.org/abs/2308.03303)*), que congela a matriz A para poupar memória computacional, o que tem um valor enorme. Mas a lição maior permanece. O papel do engenheiro de ML não é colecionar algoritmos novos, é curar os hiperparâmetros certos para o problema real. ## A necessidade do atrito Para que o desenvolvedor AI-Native consiga delegar 99% da lógica padrão e focar no produto, a relação com a IA precisa mudar. Nós não precisamos de IAs mais submissas, [precisamos de sistemas que ofereçam resistência](https://scale.press/portal/aintuicao/post/2026/03/19/multi-agentes-na-engenharia-de-software-eficiencia-real-ou-apenas-mais-ruido). Isso é exatamente o que propõem Pustejovsky e Krishnaswamy no paper *[Frictive Policy Optimization for LLMs](https://arxiv.org/abs/2604.25136)*, de abril de 2026. Os autores estruturam o conceito de FPO (Frictive Policy Optimization), que formaliza o alinhamento de IAs através do controle sensível ao risco epistêmico (cognitivo / intelectual). Em vez de simplesmente gerar um código falho para não contrariar o usuário, um modelo treinado com FPO insere atrito: ele pede clarificação, desafia premissas erradas no prompt ou se recusa a aplicar lógicas inseguras. O modelo se torna um auditor colaborativo, forçando o programador a pensar no design da solução em vez de apenas apertar o botão de autocompletar. ## Da ferramenta para o produto Se a IA resolve o trabalho mecânico e a estruturação de código boilerplate, como mantemos a cultura de inovação em equipes de engenharia? A resposta é dolorosa para quem ama tecnologia: parando de focar na stack tecnológica. Na [T2S](http://t2s.com.br), quando atendemos um cliente corporativo, a primeira orientação é não falar de linguagem de programação na primeira semana. A inovação migrou do código para a modelagem do domínio e para a engenharia de prompts. É preciso traduzir a dor do negócio em instruções inequívocas que limitem a alucinação do modelo. O produto importa mais que o framework. Escrevi detalhadamente sobre essa mudança de mentalidade tática no meu livro [Engenharia de Prompt para Devs](https://www.casadocodigo.com.br/products/livro-engenharia-de-prompt), focado em como construir abstrações robustas antes de escrever uma linha de código. A profissão de desenvolvedor não acabou. Ela foi promovida. Um programador que usa ferramentas de geração sem critérios se torna um gerente de orquestra surdo, aceitando notas desafinadas em nome da velocidade de entrega. A máquina escala a produção, mas cabe apenas ao engenheiro segurar a responsabilidade sobre o impacto do que foi para o ar. Para continuar essa discussão sobre arquitetura, curadoria de IAs e liderança técnica na prática, conecte-se comigo nas minhas redes: [https://linktr.ee/ricardo.pupo](https://linktr.ee/ricardo.pupo).