A especialização em domínio sempre foi o verdadeiro fosso
(brethorsting.com)- A parte difícil do software nunca foi digitar código, mas entender regras do mundo real, como folha de pagamento e transporte, para criar um modelo de domínio; o código era o resultado desse entendimento
- A IA agentic torna possível produzir software mesmo sem entendimento de domínio, deslocando o gargalo de “consegue construir?” para “consegue julgar se está certo?”
- Especialistas de domínio como despachantes de logística, codificadores clínicos e atuários de seguros conseguem determinar se a saída está de acordo com regras legais, de faturamento e operacionais mesmo sem conhecer código
- Engenheiros generalistas podem validar arquitetura e confiabilidade, mas em áreas como codificação clínica, onde a resposta correta está presa ao conhecimento de domínio, podem deixar passar erros plausíveis
- A capacidade mais valiosa passa a ser o julgamento de validar ao mesmo tempo a solidez do código gerado e a veracidade da saída; para engenheiros experientes, investir em especialização de domínio se torna ainda mais importante
O gargalo do software está mudando da implementação para a validação
- A parte difícil de escrever software não era o ato de digitar código em si, mas primeiro construir um modelo de domínio na cabeça
- Um sistema de folha de pagamento inclui penhora salarial, descontos antes de impostos e o tratamento de períodos de pagamento que atravessam mudanças salariais
- Um app de transporte incorpora feeds GTFS, a diferença entre trip e route, e por que um ônibus “no horário” ainda pode estar errado
- O código era o resultado de traduzir esse entendimento, e adquirir esse entendimento era o trabalho de verdade
- A IA agentic enfraquece a ligação entre entendimento de domínio e produção de software
- Agora é possível produzir software sem construir diretamente o modelo de domínio
- Isso abala a premissa da qual toda a profissão de software dependia
- Como no ponto de vista do ano passado, a explicação de que essas ferramentas amplificam desenvolvedores sêniores com bom julgamento está correta, mas não é suficiente
- A mudança mais específica é que o gargalo saiu de “consegue construir?” para “consegue julgar se está certo?”
Quem usa bem ferramentas agentic
-
Especialistas de domínio conseguem identificar a resposta certa mesmo sem saber código
- Pessoas como despachantes de logística, codificadores clínicos e atuários de seguros talvez não consigam ler um stack trace nem explicar a diferença entre hash map e list
- Mas, ao verem um cronograma criado por um agente, sabem imediatamente qual motorista legalmente não pode fazer aquele turno
- Também conseguem perceber que uma cobrança de seguro com determinada combinação de códigos não será paga
- Essas pessoas passaram 10 anos lidando com entradas e saídas, então conhecem a saída correta para uma determinada entrada
- O que o agente lhes fornece é a capacidade de produzir código que lhes faltava; o que elas trazem é o critério de verdade (ground truth) que falta ao agente
-
Engenheiros generalistas podem não distinguir software bem construído de software correto
- Um engenheiro generalista forte conhece arquitetura, confiabilidade, testes e como evitar que o sistema desabe às 2 da manhã
- Mas, em domínios como codificação clínica, pode não conseguir distinguir entre uma resposta plausível, porém errada, e a resposta certa
- O agente pode gerar algo que compila e passa nos testes imaginados pelo engenheiro, mas ainda assim introduzir erros sutis e caros nas regras de faturamento
- O engenheiro consegue validar se o software foi bem construído, mas, quando a correção é definida inteiramente por um domínio que ele não tem na cabeça, fica difícil validar a precisão
-
Antes dos agentes, havia um caminho de aprendizado favorável aos engenheiros
- Engenheiros podiam acompanhar especialistas, ler especificações e aprender o domínio aos poucos errando em ambientes operacionais
- Em muitos setores, esse processo era a essência da escada de carreira
- Não havia um caminho simétrico para os especialistas de domínio
- Aprender a construir software confiável leva anos, e era um caminho difícil de percorrer na prática para eles
-
Ferramentas agentic derrubaram apenas um dos lados desse caminho
- A capacidade dos engenheiros, que era sua vantagem, de traduzir um modelo de domínio em código funcional ficou barata
- A vantagem dos especialistas de domínio — saber o que está certo — não ficou barata
- Não dá para obter essa habilidade só com prompting, e não existe skill file que contenha o conhecimento tácito de quem acertou milhares de fechamentos de folha
-
A pessoa mais valiosa é quem consegue validar nas duas camadas
- Passa a ser mais importante quem sabe se o código gerado é sólido e também se as respostas produzidas por esse código são verdadeiras
- A razão pela qual alguém consegue escrever um teste como “um motorista não pode exceder 11 horas” é que conhece a regra
- E a razão pela qual também consegue julgar se esse teste faz sentido é que sabe o que está sendo testado
- O agente faz o trabalho de transcrição; o humano exerce julgamento nas duas camadas, a do código e a do domínio
- Para engenheiros experientes, o investimento importante é adquirir um modelo profundo e validado do domínio real
- O valor da habilidade mecânica de transformar uma ideia clara em código limpo caiu muito
- O que continua escasso é o entendimento profundo de indústrias reais, ferramentas, estruturas regulatórias e processos físicos
- É preciso escolher um domínio e aprendê-lo da mesma forma que antes se aprendia uma linguagem de programação ou framework
- A parte que o agente não pode substituir, e que agora ganhou ainda mais valor, é a especialização em domínio
Quer continuar recebendo tópicos de tecnologia selecionados?
Siga o canal no Telegram. @GeekNewsBrasil
1 comentários
Comentários do Hacker News
Não sei quantas análises prolixas ainda vão ser necessárias até admitirem que ninguém sabe como usar IA no nível individual
Primeiro diziam que bastava ser um bom desenvolvedor e aprender a usar IA; depois, que o importante era capacidade de projetar arquitetura; em seguida, que gosto era o que separava tudo; e agora dizem que só especialistas de domínio importam
Até que a melhora ou estagnação da IA entre num estado estável e previsível, essas interpretações vão continuar sendo inúteis e, em geral, provavelmente erradas
Fica mais difícil porque elas elevam muito o patamar do que é possível fazer. Desenvolvedores individuais agora conseguem assumir projetos muito mais difíceis, e no fim a limitação sempre foi tempo; a IA ajuda a fazer mais coisas dentro do tempo disponível
Só que o próprio conjunto de coisas que dá para fazer nesse tempo ficou muito mais difícil. É preciso entender muito mais coisa e sair bastante da zona de conforto familiar de antes da IA
Antes, era aceitável passar dias refatorando uma base de código ou preparando o lançamento de um recurso pequeno porque era uma área do sistema que você não conhecia bem ou porque precisava aprender uma biblioteca nova
Com agentes de código, dá para subir essa curva de aprendizado muito mais rápido, mas ainda assim você precisa subi-la por conta própria. E o volume de informação que entra é muito maior
Se você está preocupado em perder o emprego para um vibe coder não técnico, a resposta certa é fazer software muito melhor do que ele. Para isso, é preciso mais habilidade, mais ambição e mais experiência, e não é fácil
A analogia que até agora me pareceu mais adequada é a comparação entre uma parafusadeira/furadeira elétrica moderna e equipamentos antigos como chave de fenda e furadeira manual
Em comparação com ferramentas antigas, dá para conseguir resultados impressionantes em pouquíssimo tempo
Por exemplo, dá para contar histórias surpreendentes do tipo “prendi o piso em 1 hora, algo que levaria o dia inteiro, e ainda fiz várias pausas para fumar”. Com uma pistola de pregos talvez terminasse em metade do tempo, mas depois seria difícil levantar esse piso com facilidade, e o custo talvez tivesse sido o dobro
Como também uso vários LLMs on-premises e tenho acesso a outros modelos, acho que um dia vou acabar estendendo essa analogia até o nível de diferenças entre marcas
Mas não acho que isso vá arranjar um novo emprego. Uma parafusadeira elétrica não é um carpinteiro nem um operário de obra, e sem uma pessoa ela não serve para nada
Daqui a 20 anos, acho que vamos estar limpando lixo coescrito com o Claude
https://mastodon.gamedev.place/@JeremiahFieldhaven/116654345...
Em 2018, vi uma pessoa sem qualquer experiência em programação ganhar um dinheiro bem decente construindo, em um mês, uma ferramenta para um nicho específico só porque conhecia aquele mercado
Ela me mostrou parte do código, e era tão bagunçado quanto meu primeiro programa, mas resolvia um problema real
Por exemplo, dizem algo como “para ser bom em esportes, é preciso ter simetria perfeita, e isso tem forte correlação com estabilidade do desenvolvimento fetal. Quanto maior a simetria, mais perfeito o desenvolvimento”
Aí, alguns anos depois, aparece a notícia de que Bruce Lee tinha uma perna consideravelmente mais curta que a outra, e que Usain Bolt também tinha um desenvolvimento assimétrico parecido
Então dizem que esses são casos excepcionais e voltam atrás para proteger a regra geral inicial
É só criar algo interessante; pode ser que dê certo
Recentemente revisei um app quase todo feito com vibe coding. O dono disse que estava praticamente pronto para lançar e só precisava de uma checagem rápida
Quando fui olhar, o desenho do banco de dados estava um desastre. Algumas funcionalidades funcionavam e outras não. Expliquei o que faltava e por que estava quebrando. Como no texto original, a pessoa era especialista de domínio
Só no último mês ela gastou bilhões de tokens, e as ferramentas estão melhorando rápido. Mas dar IA a um especialista de domínio não significa que engenheiros de software deixem de ser necessários
O especialista de domínio pode criar software com IA, e o engenheiro de software pode aprender o domínio com IA. Os dois trazem tipos diferentes de especialização
É o trabalho de criar guardrails, validações, bibliotecas de prompts, agentes e revisão manual para proteger com segurança especialistas de domínio quando eles começarem a usar agentes de código
É um pouco parecido com atendimento interno T2/T3 ao cliente ou com engenheiros de suporte. Em vez de resolver 100% dos problemas do dia a dia diretamente, o papel é capturar pontos perigosos, casos de borda estranhos e confirmar que toda a configuração está correta
Claro, isso também envolve bastante trabalho transversal
Dito isso, são excelentes como ferramenta para testar ideias novas e se aprofundar rapidamente. Se houver curiosidade, também podem ser um grande acelerador de aprendizado
Eu uso Claude Code (Opus 4.6, configuração de esforço máximo) o dia inteiro e mesmo assim não entendo como isso seria possível. Também fico curioso se esse nível de uso realmente está gerando retorno
Talvez eu só não saiba direito como funciona, mas sinceramente não entendo como isso acontece
Passei recentemente por um ótimo exemplo disso
Eu estava em uma viagem de pesca e perguntei ao capitão se ele podia dar uma olhada no aplicativo gratuito em que estou trabalhando (https://oceanconnect.ca) para ver se poderia ajudar no trabalho dele
Eu não entendo muito bem como as pessoas usam dados oceânicos no mar. Não sei bem o que elas querem saber, nem por quê. Começaram a surgir perguntas e informações sobre como as pessoas usam os dados e sobre o que poderíamos fazer com eles, e eu não estava nada preparado; foi muito legal e interessante ganhar essa perspectiva
Isso me lembrou de novo que um modelo não é a mesma coisa que o sistema que ele abstrai, e que o conhecimento necessário para desenvolver um modelo quase não tem relação com o conhecimento necessário para usá-lo
Essa pessoa tinha um conhecimento enorme sobre como usar dados meteorológicos na água. Em certo sentido, conhecia os dados melhor do que eu e, mesmo que talvez não percebesse isso ou não entendesse sua representação digital, parecia que, se soubesse programar, conseguiria fazer um aplicativo muito melhor para pessoas como ela
Fiquei pensando que, se pessoas assim colocassem suas ideias na tela com um LLM à frente, poderiam criar coisas realmente incríveis. Se algum dia eu tiver financiamento, quero entrevistar pessoas que saem para o mar todos os dias para lapidar o produto. Esse conhecimento de domínio é muito específico, e pessoas que viveram décadas em domínios complexos sabem coisas que você jamais imaginaria
O generalista de software descrito neste texto também tem especialização de domínio. Esse domínio é software
Se você é um excelente engenheiro de software generalista hoje, não vai sair correndo para algum domínio aleatório só para fugir da IA. Software é o seu domínio, e você vai continuar nele enquanto esse domínio se expande e se transforma
Talvez a boa notícia seja que até o melhor contador artesão de planilhas do oeste ainda vai precisar de algum nível de experiência em programação para fazer validação
Você pode perguntar a um LLM “o que este código faz e X é sempre verdadeiro quando Y acontece?”, mas isso só aninha um problema de validação dentro de outro
O ponto central nunca foi o código
Depois de passar os últimos 5 anos criando software para venture capital e private equity, este texto fez muito sentido para mim. Escrever código é, de longe, a parte mais fácil do meu trabalho; a parte difícil é a engenharia financeira e o contexto sutil necessários para entender o que os clientes da empresa realmente precisam
Costumávamos brincar que, se possível, gostaríamos de contratar um contador sênior de fundos e ensiná-lo a programar. O problema é que quase não existem pessoas assim. Também é difícil fazer um engenheiro entender os detalhes da contabilidade de fundos a ponto de conseguir transformá-los em software
Na prática, cerca de metade da minha carreira foi gasta lidando com coisas feitas por gente que “tinha conhecimento de domínio suficiente para fechar tickets ou épicos, mas no fim deixava um monte de dívida técnica”
Por exemplo, mesmo com conhecimento de domínio, as pessoas erram, não conhecem formas melhores de fazer algo, não incorporam feedback ou, pior ainda, não conferem de novo o que um agente de código escreveu, então eu precisava revisar PRs com muito cuidado
Também já tive que refatorar muita coisa que era “tecnicamente correta, mas tão mal escrita que gerava timeout ou fazia gerente/DBA gritar”
Um engenheiro de software realmente bom tem capacidade e vontade de aprender o domínio, mas precisa existir uma forma de aprender. Já estive em empresas, times e com colegas que tornavam isso possível, e também em lugares que só diziam da boca para fora que isso era importante, mas no fim você tinha que deduzir tudo a partir do JIRA e de comentários soltos de pessoas de áreas não técnicas durante reuniões
Acho que a grande mudança de paradigma dos últimos 5 anos é que a maioria das empresas espera que as pessoas trabalhem até o limite e, com isso, acaba criando o efeito contrário ao impedir que aconteçam as conversas realmente importantes
Cultura é uma variável enorme. Já trabalhei em lugares onde dava para conversar rapidamente com a pessoa ao lado ou marcar uma reunião com facilidade, e em outros onde parecia que eu precisava abrir uma petição no change.org só para conseguir tempo para uma discussão adequada
Ainda assim, o ponto principal está certo. No fim, requisitos importam mais que código. Já vi lugares em que todos os requisitos tinham sido atendidos e o time havia aprovado as decisões de design, mas depois alguém que ficou ausente durante toda a implementação voltou e atrasou a funcionalidade porque não gostou da forma como ela tinha sido escrita
Aí, de repente, você percebe que o “processo em lote” está fazendo %numberOfRecord%*10 inserções, ainda adicionando consultas extras por causa de um modelo de dados mal projetado, e fazendo SQL upsert da pior forma possível — isto é, buscando primeiro no banco e depois adicionando os registros para inserir caso eles não existam. E, em vez de repensar os padrões de consulta da camada de dados, continuam fazendo coisas cada vez mais suspeitas em nome de “melhorar a performance”. Vi isso mais de uma vez na carreira
Sempre que leio um texto muito genérico que parece conselho sobre como reagir à IA, lembro que a indústria de software é parecida com a indústria da construção
Ela nunca fica realmente organizada, nunca fica totalmente otimizada e inevitavelmente sempre será customizada. Isso porque precisa se ajustar a uma realidade em que gostos, contexto e localidade variam de forma extrema
De vez em quando podem surgir boas ferramentas ou matérias-primas
Eu achava que o verdadeiro fosso competitivo do software estava em não exigir, na prática, um conhecimento ou experiência amplos tanto de sistemas quanto de domínio
Já gosto e efeitos de rede são muito mais difíceis de copiar. Na prática, mesmo antes do vibe coding, era raro que startups financiadas por VC, cheias de talento e recursos, conseguissem se firmar no mercado
Foi isso que permitiu que gente na casa dos 20 competisse com especialistas de várias áreas. Acho que a reação atual vem do surgimento de pessoas com “X anos de experiência no setor”, algo comum em outras indústrias mais maduras
Trabalho como analista, e no nosso grupo cerca de 20% dos analistas têm forte capacidade técnica, isto é, habilidade em engenharia de software, enquanto o restante são analistas tradicionais ou especialistas de domínio
No último ano, vi analistas não técnicos usarem modelos de IA na parte de desenvolvimento, aumentando a produtividade na criação de ferramentas internas
Antes, quase tudo era desenvolvido em Tableau. Era o jeito mais acessível para alguém que não é desenvolvedor criar uma ferramenta funcional
Ainda outro dia, um analista do nosso grupo apresentou uma ferramenta em que estava trabalhando e que basicamente portava um relatório do Tableau para um aplicativo mais flexível
Acho que essas empresas de BI vão entrar em sérios apuros. Principalmente empresas como a Tableau, que consegue tornar quase impossível até desenhar algo simples como um histograma
Meu amigo é engenheiro eletricista e recentemente passou de 2000 de rating FIDE no xadrez. Joga xadrez há 30 anos e até criou um clube de xadrez no ensino médio. Na faculdade, mexeu com microcontroladores e aprendeu um pouco de programação
Eu sou mais um faz-tudo de infraestrutura/administração com diploma em ciência da computação e programo por hobby há 30 anos
No Lichess, meu rating é 1000 em um dia bom
Nós fizemos uma competição de bots de xadrez. Era open book, podia programar com IA, e era um confronto livre em que valia usar qualquer coisa, como opening books ou endgame tablebases. Eu o esmaguei completamente, mas no xadrez de tabuleiro de verdade só consegui vencê-lo duas vezes em 20 anos
No mundo real, ele venceria 99% dos jogadores aleatórios, e eu provavelmente venceria só uns 20%
Não sei exatamente qual ponto estou tentando fazer, mas tenho a sensação de que agora conhecimento de domínio talvez não seja tudo. Ou talvez o próprio domínio tenha mudado
Você o desafiou para uma disputa de programação, e você, que é um programador muito mais experiente, venceu. Mesmo podendo usar IA, eu diria que, aqui, o seu conhecimento de domínio foi decisivo