DEV Community: Lucas Fogaça

Generative UI: o modelo decide a resposta; o produto decide os limites

Lucas Fogaça — Fri, 07 Aug 2026 13:35:47 +0000

Uma interface generativa não começa quando um modelo produz HTML. Ela começa antes: quando decidimos que parte da experiência pode mudar conforme a intenção de quem usa o produto e que parte precisa continuar sob controle explícito da aplicação.

Essa distinção parece sutil, mas separa uma demonstração visual de uma arquitetura que pode sobreviver a produção. Um chat pode responder “encontrei três restaurantes”. Uma interface pode mostrar os três no mapa, explicar os filtros aplicados, indicar quais estão abertos, oferecer rotas e permitir que a pessoa refine a busca sem recomeçar a conversa. O salto não é cosmético. Ele muda como dados, regras, componentes e estados circulam pelo sistema.

O artigo Generative UI, publicado pela Boda, organiza bem esse espaço: a IA pode reduzir a “parede de texto” das respostas e transformar intenção em elementos de interface temporários. Mas há mais em jogo do que trocar texto por cards. A pergunta prática é: quanto de liberdade o modelo recebe para decidir a interface?

Generative UI é uma decisão de fronteira

Em produtos tradicionais, a maior parte da UI é decidida em tempo de desenvolvimento. A equipe define telas, fluxos, componentes, estados de erro e regras de navegação. A IA pode entrar como uma busca mais tolerante, uma camada de recomendação ou um assistente dentro de uma tela já conhecida.

Com Generative UI, a entrada passa a ser frequentemente aberta: uma frase, um objetivo, uma solicitação incompleta. “Monte um roteiro para o fim de semana.” “Compare os planos que cabem no meu orçamento.” “Mostre o que mudou neste incidente.” A aplicação precisa traduzir essa intenção em algo que seja útil de olhar e de operar.

Isso cria um problema de engenharia. A mesma abertura que torna a experiência flexível pode produzir uma interface inconsistente, inacessível, difícil de testar ou, no pior caso, exposta à execução de código arbitrário. Por isso, a questão não é se a IA consegue gerar uma tela. É quem continua tendo autoridade sobre:

quais dados podem ser consultados e exibidos;
quais ações uma pessoa pode executar a partir daquela tela;
quais componentes são permitidos;
como entradas e saídas são validadas;
o que acontece quando o modelo erra, demora ou não sabe responder.

Uma arquitetura de Generative UI madura não entrega essas decisões ao modelo. Ela dá ao modelo uma área de decisão clara e constrói contratos ao redor dela.

Os três graus de liberdade

Uma classificação útil separa três abordagens: controlada, declarativa e aberta. Elas não são rivais obrigatórias. Podem coexistir no mesmo produto. A diferença é o formato que atravessa a fronteira entre o modelo e a interface.

1. UI controlada: o modelo pede, a aplicação monta

Esse é o caminho mais direto para a maioria dos times. A pessoa descreve o que precisa em linguagem natural; o modelo interpreta o pedido e escolhe argumentos para ferramentas tipadas; a aplicação executa as regras de domínio; o front-end renderiza componentes que já existem.

Imagine uma busca por lugares. O modelo não precisa gerar um mapa, uma lista ou um botão. Ele pode chamar uma ferramenta como recommendPlaces com filtros estruturados: localização, orçamento, horário, categoria e preferência. A ferramenta consulta fontes confiáveis, aplica restrições determinísticas e devolve um resultado validado. O front-end decide se usa cards, mapa, estado vazio ou lista de comparação.

O ganho vem de aceitar uma entrada aberta sem abrir mão do design system. A IA interpreta a intenção; o produto preserva o repertório visual, os critérios de acessibilidade e o comportamento já testado.

Essa abordagem costuma ser a melhor primeira entrega porque mantém o modelo longe de decisões que não precisam ser generativas. Ela também facilita observabilidade: é possível registrar a intenção interpretada, os argumentos escolhidos, a ferramenta chamada, os filtros realmente aplicados e o componente renderizado.

2. UI declarativa: o modelo compõe, o catálogo garante

Há casos em que escolher entre componentes prontos não basta. Um planejador de viagem, por exemplo, pode precisar montar uma introdução, uma previsão do tempo, uma estimativa de voo, uma agenda por dia e uma lista de itens. A combinação e a ordem podem variar com o objetivo da pessoa.

Na abordagem declarativa, o modelo não produz código executável. Ele produz uma descrição estruturada da interface: uma árvore de componentes permitidos, suas propriedades e suas relações. O cliente interpreta essa descrição por meio de um catálogo. Cada item do catálogo possui um schema que define o que aceita e um renderer que a equipe controla.

É aqui que a palavra contrato ganha importância. O catálogo informa ao modelo o que existe; os schemas recusam estruturas inválidas; os renderers garantem que o resultado final seja feito com componentes conhecidos. A interface pode variar bastante, mas não vira um campo aberto para qualquer HTML, CSS ou JavaScript.

O texto da Boda usa uma separação que ajuda a evitar confusão: há o transporte dos eventos entre servidor e cliente e há a forma como a interface é descrita. Protocolos de eventos, como AG-UI, cuidam de sinais de execução, texto, ferramentas, estado e atividades. Especificações de interface, como A2UI, descrevem os componentes e a composição. São camadas diferentes e vale mantê-las diferentes no desenho do sistema.

A vantagem é a flexibilidade com portabilidade. O custo é real: é preciso manter schemas, catálogo, renderers, política de uso, versão de componentes e bons testes. A flexibilidade não desaparece; ela é deslocada para um conjunto de regras que a equipe consegue revisar.

3. UI aberta: o modelo gera código, o sandbox limita o dano

A terceira opção deixa o modelo emitir código de interface: HTML, CSS e JavaScript. Ela é sedutora porque parece eliminar o trabalho de definir catálogo e schemas. Se o pedido é novo, a IA cria algo novo.

O problema é que “algo novo” também pode ser código que lê o que não deveria, se comporta de forma inesperada, quebra em navegadores diferentes, ignora acessibilidade ou cria uma tela impossível de auditar. A execução de código arbitrário no navegador não é um detalhe de implementação.

Por isso, interfaces abertas tendem a usar isolamento, frequentemente em iframes com sandbox. Mesmo com isolamento, continuam existindo decisões sobre permissões, comunicação com o host, cache, latência, limite de recursos, registro de versões e reversão. A ausência de um catálogo não remove a necessidade de governança; ela apenas torna essa governança mais cara.

Essa abordagem pode fazer sentido para widgets efêmeros, protótipos internos, superfícies descartáveis ou tarefas muito específicas que não justificam um catálogo completo. Para fluxos centrais, transacionais ou que manipulam dados sensíveis, ela pede cuidado redobrado.

Não escolha uma única abordagem para o produto inteiro

O cenário mais plausível não é um aplicativo 100% controlado, declarativo ou aberto. É uma composição.

Controlado para os fluxos que precisam de previsibilidade: pagamentos, permissões, ações destrutivas, dados regulados e tarefas repetidas.
Declarativo para experiências em que o arranjo da informação muda conforme a intenção, mas os blocos de construção continuam sendo do produto.
Aberto e isolado para uma necessidade temporária, específica ou experimental em que o custo de criar um componente dedicado ainda não se justifica.

O ponto não é escolher a categoria mais sofisticada. É usar o menor grau de liberdade que resolve o problema de experiência. Dar liberdade demais ao modelo cria uma nova superfície de falha. Dar liberdade de menos pode reduzir a IA a um campo de busca caro. O trabalho de arquitetura está em encontrar o meio-termo que vale a pena.

Um roteiro de adoção que evita atalhos frágeis

Para quem quer experimentar Generative UI sem reconstruir o produto, eu seguiria uma sequência simples:

Escolha uma intenção recorrente. Comece onde as pessoas já escrevem consultas difíceis de expressar em filtros: busca, planejamento, comparação, suporte operacional ou exploração de dados.
Modele ferramentas antes da interface. A primeira camada de confiança está em ferramentas com entradas e saídas tipadas, autorização e regras de domínio fora do prompt.
Reutilize componentes existentes. Faça o modelo escolher dados e variações, não recriar o design system. Meça se a interpretação melhorou a tarefa.
Registre a decisão inteira. Intenção, chamada de ferramenta, resultado validado, componente mostrado e feedback da pessoa formam uma trilha melhor para depuração do que apenas guardar o texto do chat.
Crie um catálogo quando a composição se repetir. Quando diferentes intenções começarem a pedir os mesmos blocos em arranjos variados, vale investir na camada declarativa.
Isole o que for realmente aberto. Se gerar código for inevitável, trate a execução como conteúdo não confiável desde o primeiro dia.

O modelo sugere; o produto responde por isso

Generative UI desloca parte da autoria da interface para o tempo de execução. Isso pode tornar um produto mais útil porque a tela passa a se adaptar ao objetivo, e não apenas ao menu disponível. Mas adaptação não dispensa responsabilidade.

O modelo pode priorizar informação, compor blocos e explicar uma decisão. A aplicação continua responsável por acesso a dados, efeitos no mundo real, transições de estado, validação, acessibilidade, telemetria e fallback. Essa divisão não diminui a IA. Ela é o que permite usá-la sem transformar cada nova interface em uma aposta.

Em vez de perguntar “como fazer a IA gerar toda a tela?”, talvez a pergunta melhor seja: qual interface esta intenção precisa, e qual contrato impede que a flexibilidade vire risco?

Fonte e leitura recomendada: Generative UI — Boda. O artigo discute a redução da “parede de texto”, as categorias controlada, declarativa e aberta, e exemplos de composição com especificações e componentes.

Como estruturar um harness avançado para agentes de IA

Lucas Fogaça — Thu, 06 Aug 2026 13:38:27 +0000

Um agente parece simples até precisar explicar como chegou a uma resposta, controlar custo e se recuperar de uma falha.

O artigo Building an Advanced Agentic Harness, da Data For Science, usa uma boa metáfora: há diferença entre um piloto isolado e uma operação aérea. O modelo continua tomando decisões em cada passo; o harness é a estrutura que torna o sistema observável e controlável.

A proposta combina alguns blocos que merecem atenção:

Ferramentas tipadas para validar argumentos antes de chamadas caras ou com efeitos externos.
Um plano em DAG para explicitar dependências e liberar tarefas independentes para execução paralela.
Memória em camadas com recuperação seletiva e limite claro de contexto.
Orçamento e rastreamento para enxergar custo, concorrência, falhas e decisões.
Verificação para não tratar uma resposta plausível como tarefa concluída.

O ponto não é montar a maior arquitetura possível. É fazer o agente parar, checar, registrar evidências e voltar a um caminho seguro quando algo sai do esperado.

Para quem está saindo de um loop de ferramenta e resposta, esse fluxograma ajuda a separar o que é raciocínio do modelo do que deve ser responsabilidade da engenharia ao redor dele.

Leitura que inspirou esta análise: Data For Science — Building an Advanced Agentic Harness.

Arquitetura de grafos para agentes de IA: do loop ao sistema confiável

Lucas Fogaça — Wed, 05 Aug 2026 10:33:14 +0000

Uma aplicação de IA não fica confiável porque ganhou mais agentes. Ela fica confiável quando cada etapa tem uma responsabilidade clara, critérios de saída e um caminho definido para falhas.

O artigo “How to Become a Graph Architect With Zero Experience”, publicado por Khairallah AL-Awady no X, organiza essa ideia em um roteiro de 20 passos. A proposta central é boa: antes de desenhar uma rede de agentes, é preciso dominar um loop simples e saber verificar se ele realmente funcionou.

Comece pelo loop, não pelo diagrama

Um loop agente-executor pode ser reduzido a quatro partes: uma ação, um resultado, uma verificação e uma condição de repetição. Parece elementar, mas é aí que muitos sistemas já falham. Sem um critério objetivo de qualidade, o agente apenas produz saídas com aparência de conclusão.

O verificador merece atenção especial. Em tarefas de extração, por exemplo, ele pode checar campos obrigatórios e consistência de formato. Em código, pode executar testes. Em uma publicação, pode exigir revisão humana antes do envio. Quando a checagem é fraca, repetir o loop só multiplica erros.

O que muda quando o problema vira um grafo

Há problemas que um único loop resolve bem. Outros exigem ramificações, tarefas paralelas, pontos de controle e rotas específicas de recuperação. Nesse momento, pensar em grafo ajuda: nós executam trabalho; arestas determinam o próximo passo; estado transporta a informação necessária entre as etapas.

Nem todo nó precisa ser um modelo de linguagem. Essa é uma distinção prática: uma validação determinística, uma chamada de API ou uma regra de autorização normalmente deve ser código comum. Reservar o LLM para interpretação, geração e decisões que realmente dependem de linguagem reduz custo, latência e variabilidade.

Padrões que resolvem problemas recorrentes

Roteador: escolhe o fluxo ou especialista adequado a partir da entrada.
Orquestrador e trabalhadores: divide uma tarefa em subtarefas e reúne os resultados.
Fan-out e fan-in: executa partes independentes em paralelo e consolida a resposta.
Gerador e avaliador: revisa uma saída contra um padrão e devolve feedback específico.
Portão humano: interrompe o processo antes de uma ação irreversível, como publicar, gastar ou apagar.

Esses padrões não são um convite para criar arquiteturas complexas por reflexo. São opções para usar quando a tarefa pede separação de responsabilidades ou controle explícito do fluxo.

Confiabilidade não é um detalhe de pós-produção

Um grafo que funcionou em uma demonstração ainda não está pronto para uso contínuo. Ele precisa de portas de validação, recuperação para falhas previsíveis, persistência de estado para retomada e rastreabilidade para explicar o que aconteceu em cada execução.

Vale definir, antes de rodar o sistema, o que ocorre quando uma ferramenta não responde, quando o resultado não passa na validação ou quando é necessária uma aprovação humana. “Tentar novamente” pode ser uma rota válida; não deveria ser a única.

A decisão mais madura: não usar um grafo

O ponto mais útil do roteiro é também o menos chamativo: muitas tarefas não precisam de um grafo. Se há uma única operação, um único verificador e pouca dependência entre etapas, um script ou um loop simples será mais fácil de manter e depurar.

Arquitetar sistemas de agentes é escolher a menor estrutura capaz de resolver o problema com segurança. Grafos entram quando a complexidade foi conquistada — não porque o diagrama ficou bonito.

Um plano de prática

Construa um loop para uma tarefa real e crie um verificador rigoroso.
Desenhe a mesma tarefa como nós, arestas e estado.
Marque quais nós exigem LLM e quais devem ser determinísticos.
Implemente um padrão por vez: roteamento, paralelismo ou avaliação.
Adicione logs, checkpoints e uma rota de falha antes de aumentar a arquitetura.
Compare o resultado com uma versão simples e mantenha o grafo apenas se ele trouxer ganho mensurável.

O nome “graph architect” pode variar com a moda do momento. A habilidade permanece: transformar um processo incerto em uma sequência observável, verificável e sustentável.

Fonte e inspiração: Khairallah AL-Awady, “How to Become a Graph Architect With Zero Experience (Full Course)”, publicado no X em 31 de julho de 2026. Este texto é uma síntese independente do roteiro original.

Mais arquitetura, menos tokens caros ao orquestrar agentes de código

Lucas Fogaça — Tue, 04 Aug 2026 12:00:46 +0000

Mais arquitetura, menos tokens caros ao orquestrar agentes de código

Este artigo é uma leitura do fluxo compartilhado em r/codex. Os nomes de modelos e os preços citados são os informados na publicação original e podem mudar; confira a tabela vigente antes de usar o cálculo em produção.

Quando uma tarefa de código é grande, a decisão mais cara nem sempre é qual modelo usar. Muitas vezes é deixar o modelo mais caro descobrir o problema, desenhar a solução, implementar, testar e revisar tudo no mesmo contexto.

O fluxo proposto no r/codex separa essas responsabilidades: um modelo forte organiza o trabalho; um agente mais barato executa a maior parte; o primeiro volta para revisar e decidir se vale uma nova rodada de delegação. A ideia não elimina o custo de tokens. Ela tenta colocá-lo onde ele muda o resultado.

1. Planeje antes de abrir o terminal

O primeiro passo usa SOL xhigh para transformar a tarefa em um plano de implementação detalhado. Isso força uma resposta para perguntas que normalmente aparecem tarde demais: quais arquivos mudam, qual é o comportamento esperado, quais riscos existem, como testar e o que não deve ser alterado.

Se a tarefa ainda estiver vaga, a publicação sugere uma etapa opcional de perguntas dirigidas — uma habilidade no estilo “Grill Me”. Em vez de adivinhar requisitos, o agente pergunta até ter confiança suficiente para propor a implementação.

O ganho não vem de produzir um documento bonito. Vem de reduzir retrabalho. Um plano que aponta dependências, critérios de aceite e casos de falha dá ao agente executor um alvo verificável.

2. Comprima o contexto que não será usado

Depois do planejamento, a recomendação é compactar a conversa. O orquestrador não precisa carregar cada tentativa, cada saída de comando e cada raciocínio intermediário para a etapa seguinte. Ele precisa preservar decisões, restrições, arquivos relevantes e o plano.

Contexto grande tem dois custos: aumenta a conta e torna mais fácil o agente se prender a detalhes que já não importam. A compactação não deve apagar informação crítica; ela deve trocar um histórico longo por um estado de trabalho claro.

3. Use o modelo caro como orquestrador

Na execução, SOL recebe a tarefa e o plano, mas não precisa escrever todo o código. Seu papel é iniciar Luna em modo de raciocínio máximo, revisar o resultado e escolher entre duas ações: delegar uma correção com o contexto necessário ou corrigir localmente quando isso for mais barato e simples.

codex exec \
  -m gpt-5.6-luna \
  -c 'model_reasoning_effort="max"' \
  --ephemeral \
  -s workspace-write \
  -a never \
  'PLANO'

A revisão deve testar se a implementação respeitou o plano, se os testes cobrem falhas reais e se a solução ficou mais complexa do que a tarefa exige. Sem esse filtro, a divisão de trabalho só distribui erro entre dois agentes.

Meça o custo por papel, não só o total

A publicação usa como referência US$ 0,20 por milhão de tokens de entrada e US$ 1,20 por milhão de tokens de saída para a API da Luna. Com esses valores, dá para pedir ao orquestrador um relatório separado: custo da Luna, custo do próprio SOL e uma estimativa de quanto custaria se SOL xhigh resolvesse tudo sozinho.

Essa comparação evita uma armadilha comum: considerar a delegação barata só porque um agente tem preço menor. Se o executor recebe um plano ruim, precisa de muitas idas e voltas ou devolve código que exige reescrita, a economia desaparece. O número útil é o custo para entregar uma mudança correta, testada e compreensível.

O que vale testar no seu projeto

Comece com uma tarefa que tenha critérios de aceite claros e alguns testes existentes.
Registre tokens e tempo por etapa: planejamento, execução, revisão e correção.
Peça ao orquestrador para manter o resumo de estado após cada ciclo.
Compare a taxa de retrabalho com uma execução de modelo único.
Trate preços e disponibilidade de modelos como dados variáveis, não como premissas permanentes.

O ponto central do fluxo não é prometer tokens infinitos. É reservar raciocínio caro para decisões, desenho e revisão; deixar a implementação repetível para um agente mais econômico; e medir se a divisão realmente reduz o custo de entrega.

Fonte: “Never run out of tokens again?” — r/codex. Publicação original fornecida pelo solicitante.

Entrevistas .NET em 2026 pedem raciocínio, não definições

Lucas Fogaça — Mon, 03 Aug 2026 15:00:07 +0000

Entrevistas .NET em 2026 pedem raciocínio, não definições

Saber definir async/await, injeção de dependência ou tracking do EF Core continua sendo necessário. Mas a pergunta que separa memorização de experiência costuma ser outra: o que acontece quando isso falha em produção?

O guia “.NET Interview Questions: The 2026 Guide”, de Mukesh Murugan, reúne mais de 300 perguntas e organiza o estudo por C#, ASP.NET Core, EF Core, LINQ, APIs e system design. A edição atual foi atualizada para .NET 10 e C# 14.

Uma dependência scoped dentro de um singleton

Dizer apenas que “não pode” não basta. O problema é a captive dependency: o singleton dura toda a vida da aplicação e pode reter uma instância que deveria durar apenas uma requisição. Quando isso envolve um DbContext, surgem riscos de estado indevido, concorrência e erros difíceis de reproduzir.

Uma resposta sólida identifica os ciclos de vida, explica a consequência e propõe uma alternativa que respeite o fluxo da aplicação.

Quando uma tela vira dezenas de consultas

O padrão N+1 aparece quando uma consulta carrega as entidades principais e o código dispara uma nova consulta por item para acessar uma relação. Aumentar o pool de conexões não corrige a origem do problema.

O caminho é observar o SQL, medir o custo e decidir se a tela precisa de projeção, Include, carregamento explícito ou outra estratégia. Em entrevista, explicar essa investigação é tão importante quanto citar o nome do padrão.

Um rate limiter que não acompanha o deploy

Um limitador local pode resolver o caso de uma única instância. Em várias réplicas, cada processo conta requisições de forma independente. Antes de escolher uma ferramenta, vale declarar a premissa: o limite é local ou global? O estado precisa ser compartilhado? Qual consistência e custo são aceitáveis?

Como treinar respostas melhores

Para cada cenário, experimente responder nesta ordem:

Qual é a decisão padrão?
Qual trade-off ou risco precisa ser considerado?
Em que condição a decisão mudaria?
Como você validaria a hipótese em produção?

Essa sequência mostra capacidade de decisão, comunicação e revisão de hipóteses. É mais próxima do trabalho real do que uma lista decorada de conceitos.

Este artigo é uma síntese original baseada em “.NET Interview Questions: The 2026 Guide”, de Mukesh Murugan. Consulte o material original para a lista completa de perguntas, respostas, alertas e aprofundamentos.

A lacuna de produtividade da IA: acelerar código não acelera todo o trabalho

Lucas Fogaça — Sun, 02 Aug 2026 18:16:51 +0000

Este texto parte de “The AI productivity gap”, de Bjorn Roche. Os percentuais citados abaixo são um modelo ilustrativo do autor, não uma medição universal.

A IA acelera uma etapa — não o trabalho inteiro

Há uma expectativa recorrente em empresas de tecnologia: se a IA escreve código muito mais rápido, entregas completas também deveriam surgir numa velocidade parecida. A premissa parece intuitiva, mas esbarra na composição real de um dia de engenharia.

Escrever código novo é só uma parte do trabalho. Antes disso, alguém precisa entender requisitos incompletos, investigar o comportamento do sistema, decidir limites de uma solução e negociar escolhas com outras pessoas. Depois, vêm leitura, depuração, revisão, testes, integração, deploy, documentação e reuniões. A IA já ajuda em várias dessas etapas, mas sua vantagem é mais clara justamente onde o tempo total costuma ser menor: transformar uma intenção relativamente definida em código.

Essa diferença entre acelerar uma atividade e acelerar o fluxo inteiro é a lacuna de produtividade da IA.

O modelo de Roche: 15% para sêniores, 25% para juniores

Roche propõe um exercício simples. Para um desenvolvedor sênior, ele estima 1,5 hora diária escrevendo código novo antes da IA. Mesmo supondo que a ferramenta reduza esse trecho para meia hora — um ganho agressivo de velocidade — o total diário cai de 8 para 6,75 horas. A economia é de 1,25 hora, cerca de 15%.

No cenário ilustrativo para uma pessoa júnior, mais tempo está concentrado na escrita de código: 2,75 horas antes da IA e 1 hora depois. O dia passaria de 8 para 6 horas, um ganho de 25%.

Os números não devem ser tratados como benchmark. A força do exemplo está na conta: o impacto global é limitado pela fatia do processo que a ferramenta realmente acelera. Se 70% do ciclo continua exigindo interpretação, decisão, coordenação e verificação, nenhuma melhoria local de geração de código vira automaticamente uma fábrica três vezes mais rápida.

O gargalo é raciocínio compartilhado

Em trabalho mais experiente, o tempo não some porque a pessoa digita depressa. Ele vai para perguntas que ainda não têm resposta pronta: qual problema vale resolver, quais dados são confiáveis, que mudança pode quebrar outra área, o que simplificar, o que explicar ao time e como validar o resultado em produção.

Essas tarefas têm contexto local, consequências distribuídas e, muitas vezes, requisitos ambíguos. Uma IA pode ajudar a explorar alternativas, resumir sinais e gerar rascunhos. Ainda assim, alguém precisa reconhecer se o resumo perdeu uma condição importante, se o plano cabe na arquitetura e se a alteração é segura para os usuários.

Há também um custo que costuma ficar fora dos relatórios de produtividade: conteúdo ruim produzido com IA. Uma especificação excessivamente longa, uma tarefa pouco objetiva ou uma documentação que parece completa mas esconde decisões pode transferir tempo de quem escreveu para quem precisa ler e executar. Ganho individual que aumenta o trabalho de outra pessoa não é ganho do sistema.

Por que isso muda a conversa sobre contratação

Se a IA ajuda mais justamente a etapa em que profissionais juniores passam proporcionalmente mais tempo, a conclusão “não precisamos mais contratar juniores” merece cuidado. O argumento de Roche é o oposto: essas pessoas podem se beneficiar bastante quando usam a IA como ferramenta de aprendizado, revisão e experimentação — não como substituta do entendimento.

Uma equipe saudável continua precisando formar gente capaz de decompor problemas, pedir ajuda com precisão, revisar saídas e construir repertório. Cortar a entrada de novos profissionais pode parecer eficiente no trimestre e criar escassez de experiência no futuro.

Como medir produtividade sem cair na contagem de código

Em vez de transformar velocidade de geração em meta, lideranças podem observar o fluxo:

Onde o trabalho espera? Requisitos, aprovações, ambientes, revisões e incidentes mostram gargalos diferentes de “falta código”.
O tempo poupado voltou como qualidade? Mais testes úteis, revisão melhor e documentação mais clara são resultados concretos.
A ferramenta reduziu ou redistribuiu trabalho? Compare quem gera o material com quem precisa interpretar, revisar e corrigir depois.
O time aprendeu? Entregas rápidas que ninguém consegue manter cobram juros na próxima mudança.

A IA tende a melhorar mais partes do trabalho com o tempo. Até lá, a expectativa mais útil não é um salto mágico de produtividade. É usar a velocidade adicional para encurtar ciclos de aprendizado, reduzir tarefas mecânicas e dar mais espaço ao que ainda depende de julgamento técnico e colaboração.

Fonte: Bjorn Roche — The AI productivity gap.

Refatorar para gastar menos tokens

Lucas Fogaça — Sat, 01 Aug 2026 16:51:36 +0000

Refatorar para gastar menos tokens

Quando agentes escrevem software em grande escala, a dívida de design não desaparece. Ela muda de forma: além de tornar o código mais difícil de entender, aumenta a quantidade de contexto que o agente precisa consumir a cada alteração.

Giles Edwards-Alexander descreve um caso particularmente útil para pensar nisso. Ele construiu, com Claude Code e Cursor, uma aplicação de cerca de 150 mil linhas — sobretudo em Rust — sem revisar sistematicamente o código produzido. A camada de acesso a dados acabou concentrada em um único arquivo de 17.155 linhas, com repetição de montagem de requisições HTTP e serialização de JSON.

A hipótese do experimento: investir tokens agora em refatoração pode reduzir os tokens necessários para implementar as próximas mudanças.

O que foi medido

O autor definiu uma mudança representativa e a executou, com um agente novo a cada rodada, antes e depois de etapas de refatoração. Assim, evitou que um agente acumulasse conhecimento do código ao longo do caminho. Em cada ponto, registrou linhas de código, tokens de entrada e saída e tempo de execução.

O resultado mais expressivo não veio de apagar código em massa. A camada de acesso a dados terminou praticamente do mesmo tamanho: 16.608 linhas. O que caiu foi o maior arquivo, de 17.155 para 3.695 linhas, depois de extrair duplicações e separar responsabilidades em arquivos menores.

Métrica	Resultado
Tokens de entrada para a mesma mudança	159.564 → 27.360
Redução aproximada do contexto consumido	83%
Linhas no maior arquivo	17.155 → 3.695

O mecanismo importa mais que o corte

Dividir um arquivo arbitrariamente não garante economia. Se a divisão espalhar uma responsabilidade por muitos lugares, o agente ainda precisará abrir e atravessar todos eles. O ganho observado parece depender de duas coisas: limites mais claros e um conjunto menor de arquivos relevantes para cada mudança.

Essa distinção é importante. A arquitetura não reduz apenas a dificuldade humana de navegar pelo sistema; ela orienta a recuperação de contexto do agente. Em termos práticos, a refatoração ajuda quando torna mais fácil identificar onde a alteração realmente deve acontecer.

O que isso muda no trabalho diário

Use arquivos gigantes como sinal. Não por uma regra estética de tamanho, mas porque eles forçam o agente a ler muito contexto irrelevante.
Refatore antes de delegar uma sequência de mudanças. O custo inicial pode ser compensado se a área continuar recebendo trabalho.
Meça uma mudança recorrente. Escolha uma tarefa representativa e compare tokens, tempo e arquivos lidos antes e depois.
Não espere autonomia arquitetural. No relato, os agentes precisaram de direção humana tanto para escolher quanto para aplicar várias refatorações.

Há limites para a conclusão

Trata-se de um experimento único, em uma aplicação ainda greenfield e mantida por uma pessoa. A contagem de tokens também foi aproximada a partir de caracteres, porque a ferramenta não oferecia uma medição confiável ao vivo. E o custo total da própria refatoração não foi isolado: o autor estima apenas um teto de cinco milhões de tokens para todo o trabalho de planejamento e execução.

Mesmo com essas ressalvas, o experimento oferece uma tese concreta: em desenvolvimento assistido por IA, uma boa refatoração não é só uma aposta em manutenção futura. Ela pode diminuir, já na próxima tarefa, o contexto que o agente precisa carregar para trabalhar bem.

Fonte: adaptação e comentário a partir de “The Economic Benefit of Refactoring”, de Giles Edwards-Alexander, publicado em MartinFowler.com em 30 de julho de 2026.

Como encontrar problemas que valem resolver como staff engineer

Lucas Fogaça — Thu, 30 Jul 2026 18:38:34 +0000

Este texto foi inspirado em “How I Find Problems to Solve as a Staff Engineer”, de Lalit Maganti. Não é uma tradução: é uma leitura aplicada do método descrito pelo autor.

A transição para staff engineer não acontece quando alguém recebe problemas maiores. Ela começa quando a pessoa passa a perceber problemas antes que eles virem demandas formalizadas.

Isso não significa reservar uma hora na agenda, encarar uma página em branco e tentar “pensar estrategicamente”. A prática descrita por Lalit Maganti é mais concreta: prestar atenção ao ruído cotidiano da organização, guardar os atritos e esperar até que apareça evidência suficiente para saber se existe algo relevante ali.

Escute problemas, não pedidos

Times costumam chegar com uma solução já embutida: “precisamos de um botão”, “precisamos de uma integração”, “precisamos de mais um painel”. O pedido é útil como pista, mas raramente é a definição completa do problema.

Uma conversa melhor começa por perguntas que expõem o contexto: o que a pessoa tenta fazer? Onde o fluxo trava? O que ela já tentou? Por que a ferramenta atual não resolve? Se uma alternativa existisse, ela realmente eliminaria o atrito?

Esse tipo de escuta acontece nas reuniões normais, nas mensagens de chat, nas apresentações e nos incidentes. Quando o assunto toca a sua área, vale acompanhar um pouco mais de perto: observar o fluxo real, revisar o bug com quem o investiga ou tentar reproduzir a situação. Isso separa a necessidade do usuário da primeira solução que ele imaginou.

Também ajuda conversar com quem enxerga mais longe: responsáveis por sistemas críticos, pessoas que circulam por vários times e quem recebe as consequências do seu produto. São essas pessoas que costumam notar a repetição antes de ela aparecer no roadmap.

Não transforme o primeiro sinal em projeto

Uma solicitação urgente para um time pode ser irrelevante para o produto inteiro. A prioridade daquele grupo pode mudar na semana seguinte; o pedido pode ter surgido de uma investigação pontual; ou a solução pode atender apenas um caso muito particular.

Por isso, deixar problemas em espera não é indecisão. É uma forma de coletar evidência.

O mesmo obstáculo reaparece de forma independente em outros times?
Pedidos diferentes apontam para a mesma limitação?
As pessoas improvisam planilhas, scripts ou atalhos para contornar o produto?
O custo aparece no trabalho diário, e não só na opinião de quem pediu a mudança?

Não há um único mecanismo correto para isso. Pode ser uma nota, uma lista de hipóteses, tickets marcados ou uma rotina curta de revisão. O importante é não apagar problemas não resolvidos antes que eles possam se repetir, mudar de forma ou se revelar parte de algo maior.

Procure a forma comum

O caso contado por Maganti no Perfetto ilustra bem a diferença entre acumular pedidos e entender o problema. Vários times pediam pequenos ajustes na interface: manter itens fixos, abrir uma visualização já ampliada, criar agregações próprias. À primeira vista, eram funcionalidades distintas.

O padrão por trás delas era outro: cada time queria adaptar a ferramenta ao próprio fluxo sem impor essa adaptação a todos os demais. A resposta não precisava ser uma lista de recursos sob medida; podia ser uma forma de extensão.

Essa etapa exige cuidado. Uma explicação elegante para vários pedidos ainda é uma hipótese, não uma confirmação. Em outro exemplo do autor, uma proposta de cache parecia conectar dois problemas, mas o protótipo mostrou que eles precisavam de soluções diferentes. A hipótese foi dividida antes de virar uma arquitetura difícil de sustentar.

Teste a hipótese antes de comprometer o roadmap

O próximo passo depende de risco, custo e grau de certeza. Uma melhoria pequena e reversível pode ser feita logo. Uma ideia ainda nebulosa pede um protótipo descartável, que revele limites técnicos e dê aos usuários algo concreto para contestar. Uma iniciativa maior pede RFC, conversas com os times afetados e tempo para refinar a proposta.

O ponto não é convencer os outros a qualquer custo. É tentar derrubar a própria ideia cedo. Se a demanda não se sustenta, se o custo técnico é alto demais ou se o momento da organização não é aquele, interromper ou estacionar o trabalho é um bom resultado.

Quando a hipótese resiste, quem a identificou não precisa necessariamente implementá-la. Encontrar, enquadrar e validar um problema já pode mudar a direção do time. Essa é uma das formas mais úteis de influência técnica: melhorar a qualidade das decisões antes que a implementação comece.

O efeito acumulado

Resolver problemas reais cria confiança. Pessoas que foram ouvidas voltam mais cedo na próxima vez; líderes passam a considerar sua avaliação com mais peso; conexões entre áreas ficam mais fáceis de perceber. O ciclo melhora tanto a capacidade de execução quanto a leitura do que merece ser executado.

Para quem mira uma atuação de staff, a prática pode começar de modo simples: em vez de responder imediatamente a cada pedido, registre o atrito, entenda o trabalho que ele interrompe e observe se ele reaparece. O problema certo quase nunca se anuncia com um ticket perfeito. Ele aparece aos poucos, em lugares diferentes, até que a forma comum fique difícil de ignorar.

Fonte: Lalit Maganti, “How I Find Problems to Solve as a Staff Engineer” (25 jul. 2026).

Como o ChatGPT reduz custo e latência no loop de agentes

Lucas Fogaça — Thu, 30 Jul 2026 12:08:17 +0000

Quando um agente demora ou fica caro, é tentador olhar apenas para o modelo. Só que uma tarefa como “encontre a regressão, corrija e rode os testes” depende de um sistema inteiro: contexto, execução de ferramentas, transporte de rede, tokenização, filtros de segurança, roteamento e GPUs.

O artigo da ByteByteGo, How ChatGPT Optimizes its Agent Loop, organiza esse sistema em três camadas — harness, API e inferência — e oferece uma ideia útil para quem constrói agentes: quase toda otimização relevante evita refazer trabalho que o sistema já fez.

O loop de um agente tem três camadas

Harness: mantém o histórico, monta o contexto, interpreta chamadas de ferramenta, aplica políticas de aprovação e devolve os resultados ao modelo.
API: recebe a conversa estruturada, autentica, aplica limites, tokeniza o conteúdo e encaminha a requisição.
Inferência: executa o modelo nos aceleradores, preserva o estado necessário para a geração e produz os próximos tokens.

Uma única tarefa pode repetir esse ciclo muitas vezes. Um segundo extra em cada chamada deixa de ser detalhe quando há dezenas de ferramentas, resultados longos e novas rodadas de raciocínio.

1. No harness, transmita apenas o que mudou

Em um fluxo HTTP sem estado, cada rodada tende a reenviar instruções, schemas de ferramentas e todo o histórico. A ByteByteGo descreve o uso de WebSockets persistentes e requisições incrementais: depois da primeira chamada, o cliente pode enviar o resultado novo de uma ferramenta e uma referência à resposta anterior. A conexão e o servidor já conhecem o resto.

O mesmo princípio vale para o cache de prompt. O cache só é reaproveitado quando o prefixo é idêntico token a token. Por isso, ordenar definições de ferramentas de forma determinística e tratar o histórico como uma sequência append-only é mais do que capricho de implementação: muda o custo de cada rodada.

2. Menos ferramentas no contexto, mais ferramentas sob demanda

Carregar centenas de schemas de integração em toda chamada consome contexto, mesmo quando quase nenhum será usado. Uma alternativa descrita no artigo é deixar no prompt apenas as ferramentas centrais e uma busca de ferramentas. Quando o agente precisa de algo específico, procura o catálogo e recebe a definição relevante.

Há um detalhe importante: nessa situação, simplicidade pode vencer sofisticação. O exemplo usa busca lexical BM25 para recuperar ferramentas a partir de suas descrições, em vez de acrescentar outra camada de embeddings ao caminho crítico.

Outra redução de rodadas é o Code Mode: em vez de emitir várias chamadas independentes e esperar o resultado de cada uma, o modelo escreve um pequeno programa que as executa, paraleliza o que puder e devolve ao contexto só o resultado consolidado. Isso reduz tanto latência quanto ruído acumulado na conversa.

3. Na API, não retokenize a conversa inteira

Tokenização é trabalho linear sobre o texto. Se a API retokeniza todo o histórico a cada resultado de ferramenta, ela relê milhares de tokens para acrescentar poucas linhas. Mantendo a conversa tokenizada em memória no lado do servidor, a API tokeniza o delta e o anexa ao estado existente.

O artigo também destaca uma forma pragmática de diminuir o tempo até o primeiro token: iniciar verificações de segurança em paralelo à inferência. Se os controles terminam antes de o resultado precisar ser liberado, o usuário não paga duas vezes pelo tempo de espera. O requisito, naturalmente, é preservar a política de bloqueio ou retenção caso a verificação falhe.

4. Na inferência, proteja o estado que já foi calculado

Na camada de GPUs, o roteamento não deve olhar apenas para a fila. Ele também deve tentar levar a próxima rodada de uma conversa para uma máquina que ainda guarda seu estado. Mandá-la para outra máquina pode obrigar o sistema a reconstruir um cache que já existia.

Esse estado é o KV cache, usado pelo transformer para não recalcular toda a atenção a cada token. Como ele cresce com o contexto e com o número de conversas concorrentes, políticas de retenção e transferência precisam ser guiadas por traços reais de uso, não por intuição.

O artigo cita ainda duas técnicas conhecidas:

Decodificação especulativa: um modelo menor propõe vários tokens; o modelo maior os verifica em paralelo e aceita os corretos, sem alterar a qualidade da saída.
Separação entre prefill e decode: processar o prompt inteiro e gerar token a token são cargas diferentes. Separá-las permite configurar recursos para o gargalo de cada fase.

A métrica certa é custo por tarefa concluída

O ponto mais útil não é uma técnica isolada. É observar a cadeia inteira: um prefixo estável ajuda o cache do prompt; o cache reduz trabalho na API e na GPU; uma ferramenta descoberta sob demanda evita contexto inútil; uma execução em lote corta voltas no loop.

Para quem opera agentes, a pergunta prática é: qual trabalho este loop está repetindo? Meça com tráfego parecido com o de produção, preserve estado quando for seguro e elimine recomputação antes de adicionar complexidade. A soma dessas pequenas decisões é que reduz latência e custo por tarefa que realmente chega ao fim.

Fonte: ByteByteGo — How ChatGPT Optimizes its Agent Loop: Harness, API, and Inference (29 jul. 2026). Este texto é uma análise original baseada no artigo, não uma reprodução.

A melhor priorização é não priorizar

Lucas Fogaça — Thu, 30 Jul 2026 11:14:56 +0000

Há uma pergunta que consome uma quantidade desproporcional de energia em times de produto: qual é a próxima prioridade?

Ela parece inevitável quando entram em disputa pedidos de clientes, dívida técnica, confiabilidade, redução de custos e uma nova frente de receita. No artigo “The Best Prioritization Is No Prioritization”, o investidor e operador do Stay SaaSy propõe uma inversão útil: em muitos casos, o problema não é escolher melhor. É depender demais da escolha.

Priorizar não substitui capacidade de execução

Frameworks como RICE e Kano podem dar vocabulário para uma conversa, mas não eliminam as incertezas que importam. Alcance, esforço e impacto frequentemente são estimativas frágeis, especialmente em mercados que mudam rápido e em produtos com poucos clientes. Depois que o time segue uma direção, também não existe um experimento paralelo que prove que aquela foi a escolha ótima.

O custo menos visível é o da própria rotina de repriorização: reuniões, planilhas, alinhamentos e mudanças de contexto. Quando a organização consegue entregar pouco, cada decisão vira uma disputa de alto risco. Quando consegue entregar mais, ela pode testar mais hipóteses e aprender com o uso real.

Primeiro movimento: construir mais rápido

A tese não é abandonar o julgamento. É deslocar parte do esforço gasto discutindo o backlog para remover atritos da entrega. Ciclos de planejamento podem ser menores; o tempo liberado pode ir para melhorar ferramentas, reduzir bloqueios, dar autonomia aos times e colocar trabalho em produção.

Velocidade não torna qualquer ideia boa. Ela diminui o preço dos erros e aumenta a quantidade de sinais que o produto devolve. Um time que lança, mede e ajusta aprende mais sobre sua própria prioridade do que um time que prolonga a discussão antes de construir.

Segundo movimento: tirar comparações impossíveis da mesa

Outro ponto forte do texto é a defesa de equipes duráveis, com missões claras. Em vez de deslocar pessoas continuamente entre “o produto novo”, “o produto que mais gera suporte” e “a área com problema de escala”, cada grupo permanece responsável por um domínio.

Isso transforma comparações entre objetivos incompatíveis em escolhas dentro de um contexto. Um time de produto principal pode discutir se reduz chamados, melhora a confiabilidade, entrega uma funcionalidade pedida ou corta custo operacional. Ainda há trade-offs, mas eles são mais concretos e mais próximos de dados de clientes, operação e finanças.

A coordenação entre áreas não desaparece. Ela muda de forma: em vez de trocar prioridade toda semana, a empresa toma decisões de capacidade com mais cadência — ampliar, reduzir, dividir ou encerrar uma equipe. São decisões mais lentas, mas justamente por isso reduzem o vai-e-volta que corrói foco.

O que vale testar na prática

Meça o tempo gasto para decidir. Se o planejamento vira um projeto próprio, há um sinal de atrito organizacional.
Separe problemas de prioridade de problemas de fluxo. Atrasos podem vir de dependências, falta de clareza, ambientes instáveis ou excesso de trabalho em andamento.
Dê missões persistentes aos times. Contexto acumulado e responsabilidade contínua costumam valer mais do que realocações frequentes.
Use decisões de capacidade para mudanças maiores. Quando uma frente precisa crescer ou parar, trate isso como escolha explícita de recursos, não como um remendo semanal no backlog.

“Não priorizar” não é seguir uma lista ao acaso. É desenhar uma operação em que velocidade, foco e aprendizado reduzem a necessidade de arbitrar toda decisão como se fosse única. A pergunta deixa de ser “qual item vence agora?” e passa a ser “o que está impedindo cada time de avançar bem no seu domínio?”.

Fonte: The Best Prioritization Is No Prioritization, Stay SaaSy (16 jul. 2026).

Como pesquisar temas técnicos com IA sem terceirizar o entendimento

Lucas Fogaça — Wed, 29 Jul 2026 12:09:51 +0000

Uma resposta fluente não é o mesmo que entendimento. Em temas técnicos, a IA é mais útil quando ajuda a transformar uma dúvida vaga em uma investigação que você consegue refazer sem ela.

A ideia vem de “How to Research Technical Topics With AI”, de 0xkato. O artigo descreve um processo usado para estudar como LLMs funcionam: a IA sugere termos, dependências, fontes e críticas; a pessoa abre as referências, testa as explicações e escreve a síntese.

O ponto não é reduzir o uso de IA por princípio. É colocá-la no lugar certo do processo.

1. Comece por uma pergunta que caiba numa investigação

“Como LLMs funcionam?” abre assuntos demais: treinamento, tokenização, arquitetura, hardware, inferência, alinhamento e produto. Uma pergunta ampla costuma render uma visão geral convincente, mas pouco útil para explicar qualquer parte com precisão.

Em vez disso, recorte o mecanismo. Por exemplo: o que acontece entre a entrada de um prompt e a previsão do próximo token? O recorte cria limites e uma sequência de estudo. Também deixa explícito o que ficou de fora.

A IA pode ajudar aqui ao apontar ambiguidades, listar conceitos prévios e sugerir uma ordem de dependências. Isso é um mapa inicial, não uma resposta final.

2. Descubra os termos antes de buscar explicações

Muitas vezes sabemos descrever a confusão, mas não sabemos o nome técnico dela. Perguntas como “como o modelo sabe qual palavra veio antes?” levam a termos como codificações posicionais, posições relativas e RoPE. Com a terminologia certa, papers, documentação e código deixam de ser uma busca aleatória.

Também vale perguntar ao modelo o que esperar de cada referência antes de abri-la. Um paper pode mostrar como uma ideia foi formulada; a documentação pode mostrar uma implementação atual; o código pode esclarecer o detalhe que uma visão geral omite. Ainda assim, cada referência precisa ser lida no contexto.

3. Estude uma peça por vez

Depois de mapear dependências, resista à tentação de pedir que a IA explique o sistema inteiro. Escolha uma parte e só avance quando conseguir dizer o que entra nela, o que acontece e o que sai.

O artigo usa a atenção multi-head como exemplo. A imagem de que um vetor é “dividido em pedaços” para cada cabeça é memorável, mas pode induzir ao erro. A descrição mais precisa é que cada cabeça usa projeções aprendidas para Queries, Keys e Values. Implementações podem agrupar operações por eficiência; isso não transforma as cabeças em fatias semânticas predefinidas do vetor original.

Uma boa pergunta para a IA é: “o que está tecnicamente errado nesta explicação, o que é uma simplificação razoável e onde ela deixa de ser segura?” Peça crítica, não uma reescrita imediata. Se o modelo substitui seu texto antes de você entender o problema, fica fácil aceitar a frase nova sem reparar a lacuna.

4. Mantenha evidência e explicação separadas

Para cada parte estudada, registre duas coisas: a afirmação técnica e a fonte; depois, sua explicação mais simples para aquela ideia. Elas cumprem funções diferentes.

O modelo mental permite que alguém acompanhe a intuição. A fonte define o que essa intuição representa — e os seus limites. Essa separação evita transformar uma simplificação útil numa afirmação literal sobre todo modelo ou toda implementação.

5. O chat não é a fonte

Um modelo pode indicar um paper, uma documentação, um benchmark ou uma implementação. Não deve ocupar o lugar deles. Para uma afirmação importante, abra a referência, encontre a passagem, leia o entorno e confira se o autor está mesmo defendendo a tese que você pretende usar.

Verifique também idade e contexto. O transformer original, um LLM decoder-only atual e uma implementação específica são relacionados, mas não intercambiáveis. Uma explicação pode combinar gerações de arquitetura sem avisar. Suas notas precisam preservar essa diferença.

6. Tente derrubar a própria explicação

A primeira explicação que parece fazer sentido é justamente a que merece ser pressionada. Pergunte: onde esse modelo mental falha? Qual palavra está forte demais? Estou descrevendo algo que ocorre em todos os casos ou uma implementação comum?

Isso muda frases fáceis, como “as cabeças de atenção se especializam”, para formulações mais cautelosas quando a evidência pede. Alguns padrões de atenção podem ser reconhecíveis; isso não prova que cada cabeça tenha uma função limpa e fixa. A mesma cautela vale para expressões como “a rede feed-forward armazena conhecimento” ou “o modelo aprende a raciocinar”.

Para buscar objeções, não dependa da mesma conversa que produziu a explicação. Troque os termos de busca, procure trabalhos posteriores e críticas, consulte outra ferramenta ou peça leitura a alguém que não acompanhou o raciocínio inicial.

7. Feche o chat e reconstrua o assunto

O teste mais útil vem sem a interface aberta. Tente explicar o mecanismo numa página em branco. Se você consegue nomear dois componentes vizinhos, mas não consegue dizer o que mudou entre um e outro, encontrou uma lacuna específica. Volte à fonte naquele ponto.

Escrever com suas palavras não é apenas a etapa de divulgação. É parte da pesquisa. Uma explicação pode parecer óbvia enquanto está na tela e desaparecer quando você tenta reconstruí-la sem apoio.

Use a IA novamente na edição, quando já houver uma estrutura, notas verificadas, modelos mentais e limites claros. Um chat de pesquisa contém hipóteses, becos sem saída e fontes repetidas; transformar a conversa inteira em artigo pode fazer esse material aparecer como conclusão.

Uma regra simples

Use IA para recortar a pergunta, encontrar vocabulário, localizar fontes, testar explicações e expor pontos fracos. Use fontes para sustentar as afirmações. Use sua própria reconstrução para verificar se houve aprendizado.

O resultado pode ser menos imediato do que copiar uma resposta bem escrita. Em troca, você ganha uma explicação que sabe defender, adaptar e corrigir.

Leitura de referência: How to Research Technical Topics With AI, por 0xkato.

IA está ampliando o que cabe em cada função no trabalho

Lucas Fogaça — Tue, 28 Jul 2026 20:47:56 +0000

A IA não está apenas acelerando tarefas dentro de uma função. Ela está tornando mais comum que pessoas assumam partes do trabalho que antes eram encaminhadas a outra área.

Essa é a principal leitura de uma nova análise da OpenAI, baseada em mais de 800 mil mensagens de usuários do ChatGPT nos Estados Unidos. O estudo acompanha uso profissional em tempo real e procura responder a uma pergunta mais interessante do que “quais tarefas a IA executa?”: quem passa a executá-las?

O que os dados mostram

Entre todas as mensagens relacionadas ao trabalho, 16,8% tratavam de atividades associadas a outra ocupação. Quando a análise exclui tarefas genéricas — como escrever, resumir e agendar, presentes em muitas profissões — o número sobe para 43,5%.

Isso descreve um deslocamento prático. Um pequeno empresário pode redigir uma peça de divulgação, revisar um contrato ou fazer uma análise financeira básica. Um vendedor pode explorar dados de clientes sem esperar uma análise formal. Um profissional de marketing pode investigar um problema simples no site antes de acionar desenvolvimento.

Não significa que especialistas deixaram de ser necessários. Significa que a primeira resposta a um problema pode acontecer mais perto de onde ele apareceu.

Nem toda tarefa atravessa áreas do mesmo modo

Marketing e engenharia são os campos cujas tarefas aparecem com mais frequência nas mensagens de profissionais de outras áreas. Cálculos financeiros e solução de problemas tecnológicos ficaram entre as três tarefas externas mais comuns em todos os outros sete grupos ocupacionais observados.

O padrão também muda conforme a profissão. Designers recorrem bastante a tarefas de fora de sua ocupação: 35,2% de suas mensagens se enquadram nessa categoria. Já tarefas de design aparecem pouco em outras áreas, apenas 1,7% das mensagens. Engenharia apresenta quase o movimento inverso: 18,5% das mensagens de engenheiros envolvem tarefas externas, mas tarefas de engenharia representam 7,4% das mensagens de profissionais de outros campos.

Marketing se espalha nas duas direções: 24,3% das mensagens de profissionais de marketing são sobre tarefas de outras ocupações, e tarefas de marketing correspondem a 8,9% das mensagens de pessoas em outros campos, a maior parcela externa do recorte.

Empresas menores têm uma razão prática para usar IA assim

Em organizações grandes, há equipes especializadas, fluxos estabelecidos e mais opções para encaminhar uma demanda. Em negócios pequenos, quem está diante do problema tende a precisar resolvê-lo.

Entre usuários médios, a participação de tarefas de fora da ocupação caiu de 18,9% em espaços de trabalho com 2 a 5 assentos para 16,3% em organizações com mais de 100 assentos. A OpenAI ressalta que esse padrão não aparece da mesma forma entre os usuários mais intensivos, que podem já ter rotinas de IA mais estáveis.

O ponto não é transformar todos em generalistas

O ganho está em reduzir a espera e melhorar a qualidade da primeira tentativa. A pessoa que entende o contexto pode investigar, estruturar uma hipótese, preparar material e chegar ao especialista com uma demanda melhor definida.

Para as empresas, a consequência é menos sobre rebatizar cargos e mais sobre redesenhar o trabalho: definir quais decisões podem ser apoiadas por IA, quais exigem revisão especializada e como registrar o que funcionou. Descrições de cargo costumam mudar depois. Os hábitos de trabalho já estão mudando antes.

Fonte: OpenAI, “How AI is expanding what people do at work”. Os dados se referem a mensagens de usuários do ChatGPT nos Estados Unidos e descrevem padrões de uso, não uma medida direta de desempenho ou substituição de profissionais.