A multitarefa focada: como a IA está reconfigurando a forma como os engenheiros pensam
Existe uma contradição com a qual me deparo continuamente. Cada pesquisa em ciência cognitiva que li diz a mesma coisa: concentre-se em uma tarefa de cada vez. A multitarefa é um mito. Seu cérebro não consegue fazer duas coisas exigentes simultaneamente sem pagar um alto custo de desempenho.
E, no entanto, todos os dias me encontro revisando um pull request que o agente na nuvem do GitHub Copilot abriu, enquanto um pipeline de CI/CD roda em uma segunda branch com código gerado por IA. Mais fluxos de trabalho em paralelo do que jamais gerenciei antes da IA entrar no meu fluxo de trabalho, e de alguma forma parece menos caótico do que antes.
Algo não bate. Ou a ciência está errada, ou o que estou fazendo não é realmente multitarefa. Acho que é o segundo, e a distinção importa para todo engenheiro que se adapta a fluxos de trabalho agênticos.
O que a ciência diz sobre a multitarefa
A pesquisa sobre multitarefa não é ambígua. É uma das descobertas mais replicadas em psicologia cognitiva.
Em 2001, Joshua Rubinstein, David Meyer e Jeffrey Evans publicaram um estudo marcante no Journal of Experimental Psychology: Human Perception and Performance que quantificou o que acontece quando as pessoas alternam entre tarefas. Seus experimentos mostraram que cada troca de tarefa impõe dois custos distintos: o tempo que seu cérebro gasta desativando as regras e o contexto da tarefa anterior, e o tempo que gasta carregando as regras e o contexto da nova. Esses "custos de troca" se acumulam. Quanto mais complexas as tarefas, maior a penalização. Seus dados mostraram perdas de tempo mensuráveis em cada troca, perdas que escalavam com a complexidade da tarefa, mesmo quando os participantes sabiam que a troca estava por vir. Você pode ler o estudo completo aqui: Rubinstein, J. S., Meyer, D. E. & Evans, J. E. (2001). Executive control of cognitive processes in task switching. Journal of Experimental Psychology: Human Perception and Performance, 27(4), 763–797.
O trabalho anterior de Meyer e David Kieras construiu a base teórica para essa descoberta. Seu modelo computacional do controle cognitivo executivo explicou por que o cérebro humano tem dificuldade com tarefas exigentes concorrentes: os processos executivos que gerenciam prioridades de tarefas, alocação de memória de trabalho e rastreamento de objetivos operam como um gargalo. Você só tem um conjunto de processos de controle executivo, e eles só podem ser configurados para uma tarefa de cada vez. Os artigos originais são: Meyer, D. E. & Kieras, D. E. (1997a). A computational theory of executive cognitive processes and multiple-task performance: Part 1. Basic mechanisms. Psychological Review, 104(1), 3–65 e Part 2. Accounts of psychological refractory-period phenomena. Psychological Review, 104(4), 749–791.
Os números práticos são impressionantes. A Associação Americana de Psicologia documentou que alternar entre tarefas pode custar até 40% do tempo produtivo, e que recuperar o foco total após uma interrupção leva entre 15 e 23 minutos. Isso significa que um desenvolvedor que muda de contexto quatro vezes em uma manhã pode ter perdido mais de uma hora de trabalho profundo antes do almoço, apenas pela sobrecarga neurológica da troca em si.
Uma síntese mais recente vem de Tambun, Yudoko e Aldianto (2024), cuja revisão arquivística no The International Journal of Business and Management examinou como a multitarefa afeta a aprendizagem, a estrutura cerebral e a função cognitiva de longo prazo. Suas descobertas reforçam o que a literatura experimental anterior estabeleceu: os custos não são apenas imediatos, mas cumulativos, com a troca habitual de tarefas afetando a capacidade de atenção e a memória de trabalho ao longo do tempo.
Isso não é ciência controversa. É bem estabelecida e bem replicada. A questão é o que isso significa para uma profissão que cada vez mais envolve supervisionar múltiplos agentes de IA trabalhando em paralelo.
A multitarefa antiga vs. a nova orquestração
Pense em um técnico de futebol observando múltiplas jogadas se desenvolverem no campo, não correndo entre posições ele mesmo, mas avaliando cada jogada e tomando decisões sobre cada uma. Isso se aproxima mais do que a engenharia assistida por IA parece do que a imagem de um desenvolvedor trocando freneticamente entre abas abertas do editor.
A multitarefa tradicional, o tipo contra o qual a pesquisa alerta, envolve uma única pessoa tentando executar múltiplas tarefas cognitivamente exigentes simultaneamente: escrever código enquanto revisa um documento de design enquanto responde mensagens no Slack. Cada atividade requer seu próprio modelo mental, sua própria carga de memória de trabalho, seu próprio conjunto de regras ativas. Cada troca entre elas desencadeia o custo total que Rubinstein e Meyer mediram.
O que está acontecendo com a engenharia assistida por IA é estruturalmente diferente. O engenheiro não está executando múltiplas tarefas. O engenheiro está delegando múltiplas tarefas e depois avaliando os resultados. A carga cognitiva muda da execução para a supervisão, da produção para o julgamento. Considere a diferença:
| Multitarefa tradicional | Orquestração assistida por IA |
|---|---|
| Você escreve uma funcionalidade, depois muda para corrigir um bug, depois muda para revisar um PR | Um agente escreve a funcionalidade, um segundo agente corrige o bug, você revisa ambos os PRs sequencialmente |
| Cada troca requer carregar um novo contexto de código na sua memória de trabalho | Cada revisão usa o mesmo modo cognitivo: ler, avaliar, decidir |
| Você alterna entre produzir e produzir outra coisa | Você mantém uma postura única: avaliar o que foi produzido |
| O custo de troca é alto porque os contextos de execução diferem radicalmente | O custo de troca é reduzido porque o framework de avaliação se mantém consistente entre revisões |
A síntese de Tambun et al. mencionada acima também é relevante aqui: quando os trabalhadores passam da execução direta para a supervisão avaliativa, a arquitetura cognitiva muda de maneiras que reduzem a penalização clássica do custo de troca. O papel supervisório envolve um modo cognitivo diferente e mais consistente do que a execução.
Como isso se parece na engenharia de software
Esse padrão é mais fácil de ver em exemplos concretos.
Revisão paralela de PRs
Atribuo uma GitHub Issue ao agente na nuvem do GitHub Copilot. Enquanto o agente trabalha, criando independentemente uma branch, escrevendo código e rodando testes, abro um pull request completado de um segundo agente de uma tarefa anterior. Reviso o diff, verifico a cobertura de testes, confirmo que a implementação corresponde à especificação e deixo comentários ou aprovo.
No modelo antigo, eu teria escrito ambas as implementações sozinho. Cada troca entre elas teria exigido reconstruir o contexto mental do zero. No novo modelo, ambas as implementações acontecem em paralelo, e eu as reviso em sequência usando a mesma mentalidade avaliativa. O framework cognitivo que levo de um PR para o próximo é o mesmo: está correto, bem testado e alinhado com o que foi pedido?
Refatoração delegada com pontos de verificação intermediários
Peço a um agente para refatorar um módulo, dividindo um arquivo grande em preocupações menores e bem separadas. Enquanto o agente trabalha, não fico parado. Analiso os commits à medida que aparecem. Mas não estou escrevendo código. Estou julgando código. A separação está limpa? O agente moveu as dependências corretamente? Os imports apontam para os arquivos certos?
Julgar código e escrever código são tarefas cognitivas diferentes. Julgar utiliza reconhecimento de padrões, conhecimento do domínio e raciocínio avaliativo. Escrever requer isso mais a sobrecarga adicional de gerenciamento de sintaxe, lembrança de APIs e depuração incremental. O modo apenas de avaliação é cognitivamente mais leve, o que significa que mover-se entre avaliações carrega um custo de troca menor.
Monitoramento de pipelines entre branches
Três branches estão passando por pipelines de CI/CD, cada uma contendo código gerado por IA. Observo os dashboards do pipeline. Uma build falha. Olho o erro, identifico como um teste instável não relacionado à mudança e re-disparo. Outro pipeline passa. Faço merge. O terceiro ainda está rodando. Sigo em frente.
O controle de tráfego aéreo é uma comparação pertinente aqui, não pelo que está em jogo, mas pela estrutura atencional. Os controladores não pilotam aviões. Mantêm consciência situacional através de muitas trajetórias simultâneas e intervêm apenas quando uma decisão é necessária. A habilidade cognitiva não é execução; é reconhecimento de padrões em escala. Engenheiros monitorando pipelines agênticos estão desenvolvendo algo similar: a capacidade de manter múltiplos estados de processo na consciência periférica e saber quais precisam de atenção agora. Nada disso requer engajamento cognitivo profundo com qualquer tarefa individual. É atenção supervisora: escanear anomalias, tomar decisões binárias (passa/falha, merge/investigar) e direcionar trabalho adiante.
As tarefas cotidianas seguem o mesmo padrão
Essa mudança não se limita ao código. A mesma dinâmica se desenrola no trabalho profissional cotidiano.
Uma IA redige três respostas de e-mail. Leio cada uma, ajusto o tom em uma, aprovo as outras duas. Não estou escrevendo três e-mails. Estou editando e validando três propostas. Um agente prepara notas de reunião a partir de uma transcrição. Escaneio o resumo, corrijo uma atribuição e passo a um documento que outra ferramenta de IA resumiu. Novamente, a tarefa é avaliação, não produção.
O fio comum merece seu próprio enquadramento. A IA move os humanos da camada de produção para a camada de validação. Não são apenas tarefas diferentes. São modos cognitivos diferentes. A produção requer execução específica da tarefa: lembrar sintaxe, gerenciar estado, gerar algo do nada. A validação requer julgamento que se transfere entre tarefas: comparar o que existe contra um padrão, identificar o que está faltando ou errado, decidir se aceita ou redireciona. E o julgamento, diferente da execução, carrega muito menos sobrecarga de troca de contexto porque a lente avaliativa permanece constante mesmo quando o conteúdo muda.
Essa é a mudança subjacente que faz o trabalho assistido por IA parecer diferente da multitarefa tradicional. Você não está fazendo mais coisas. Está fazendo um tipo diferente de coisa, um que seu cérebro lida com muito menos fricção ao se mover entre instâncias dele.
A mudança de modelo mental: meta-foco
Se o trabalho do engenheiro não é mais executar tarefas individuais, mas supervisionar múltiplos agentes que executam em seu nome, a habilidade cognitiva central muda. Penso nessa nova habilidade como meta-foco: a capacidade de manter atenção sustentada na qualidade da supervisão em si, em vez de em qualquer tarefa individual sendo supervisionada.
O meta-foco é fazer uma única tarefa em um nível superior de abstração. Você não está focado em escrever uma função ou depurar um teste. Está focado em garantir que os agentes escrevendo funções e depurando testes o façam corretamente, com segurança e alinhados com os objetivos do sistema.
Isso se conecta com a pesquisa de Anthony Sali na Universidade de Wake Forest, cujo trabalho usando fMRI e EEG examina como o cérebro gerencia a flexibilidade cognitiva durante a troca de tarefas. A pesquisa de Sali sugere que a gestão da flexibilidade cognitiva pelo cérebro é mais matizada do que um simples modelo de gargalo, e que a natureza da tarefa entre a qual se troca importa tanto quanto a troca em si. Um cérebro se movendo entre instâncias do mesmo modo avaliativo se comporta de maneira diferente de um cérebro alternando entre dois contextos de execução não relacionados. O modo supervisório parece impor menos interferência precisamente porque não exige que o cérebro mantenha contextos de execução concorrentes na memória de trabalho.
A implicação prática é esta: os engenheiros que terão sucesso em fluxos de trabalho agênticos não são aqueles que aprendem a fazer multitarefa mais rápido. São aqueles que aprendem a parar de fazer multitarefa de execução por completo e desenvolvem sua capacidade de atenção avaliativa sustentada.
Implicações práticas para engenheiros adotando fluxos de trabalho agênticos
Entender a ciência cognitiva é útil, mas o que você faz com isso? Aqui estão quatro recomendações concretas.
Delimite sessões de revisão, não sessões de execução
No modelo antigo, você delimitava quanto tempo passaria escrevendo código para uma tarefa. No modelo agêntico, delimite quanto tempo você passa revisando a saída do agente. Dê a si mesmo blocos de revisão de 20 minutos e depois se afaste. Isso previne que a fadiga de revisão degrade a qualidade da sua supervisão, que agora é sua contribuição principal.
Use execuções assíncronas de agentes para criar janelas naturais de avaliação
Atribua tarefas aos agentes antes de começar um bloco de foco profundo em outra coisa. Quando você terminar, o agente tem resultados prontos para revisão. Isso cria um ritmo natural, similar a um padrão Pomodoro mas estruturado em torno da delegação em vez da pressão do tempo: atribuir, focar em outra coisa, retornar e avaliar. Você não está se interrompendo. O trabalho do agente se completa em sua própria agenda, e você integra a revisão nos intervalos entre suas sessões focadas.
Pratique a troca de contexto deliberada com uma lente avaliativa consistente
Ao revisar múltiplas saídas de agentes em sequência, use uma checklist consistente: correção, cobertura de testes, implicações de segurança, alinhamento com as especificações. Essa lente padronizada reduz o custo cognitivo de trocar entre diferentes bases de código ou funcionalidades. Seu framework de avaliação permanece estável mesmo quando o conteúdo muda, e essa estabilidade é o que mantém baixo o custo de troca.
Resista ao impulso de executar
O hábito mais perigoso nos fluxos de trabalho agênticos é cair no modo de execução quando você deveria permanecer no modo de avaliação. Você vê o código de um agente e pensa: eu teria feito diferente, deixa eu reescrever esta parte. Esse instinto não é má disciplina. É experiência no domínio se expressando. Engenheiros que são bons em programar vão querer corrigir o código que veem, e esse impulso vem da competência, não da impaciência. Mas agir com base nele te puxa para fora do papel supervisório e de volta para a zona de penalização por troca de contexto. A menos que a saída do agente esteja fundamentalmente errada, forneça feedback através de comentários ou especificações atualizadas e deixe o agente iterar. Fique na faixa de avaliação.
O engenheiro que melhor se concentra
O paradoxo do início deste artigo se resolve sozinho uma vez que você vê a diferença estrutural entre a multitarefa cognitiva e a delegação orquestrada.
A multitarefa tradicional, tentar executar múltiplas tarefas exigentes simultaneamente, continua tão destrutiva quanto Rubinstein, Meyer e cada pesquisador subsequente demonstraram. Isso não mudou. Seu cérebro ainda tem um gargalo de controle executivo. Trocar entre contextos de execução ainda custa de 15 a 23 minutos de tempo de recuperação. A produtividade ainda cai até 40% quando você fragmenta sua atenção entre tarefas concorrentes.
O que mudou é o tipo de trabalho que os engenheiros fazem. Quando agentes de IA lidam com a execução, a tarefa cognitiva do engenheiro se reduz à supervisão, avaliação e julgamento. Essas atividades compartilham um framework mental comum. Mover-se entre elas não desencadeia os mesmos custos catastróficos de troca que mover-se entre diferentes tarefas de execução.
Os engenheiros que prosperarão nesta era não serão aqueles que aprendem a fazer multitarefa melhor. Serão aqueles que aprendem a focar com precisão no que realmente requer sua atenção e deixar todo o resto rodar em segundo plano.
Isso não é multitarefa. É o tipo mais profundo de foco que existe.