17 pontos por GN⁺ 2025-07-25 | 1 comentários | Compartilhar no WhatsApp
  • A maioria das ferramentas de IA atuais não reflete os processos de aprendizagem centrados no ser humano (recordação, execução e repetição coletiva) — isso é, em última instância, um design reverso que prejudica o ciclo de crescimento tanto de humanos quanto da IA
  • Humanos aprendem processos, não apenas conhecimento, e inovam por meio de repetição coletiva e cumulativa. Mas a maior parte das ferramentas de IA segue o padrão “clicar no botão → a IA resolve sozinha”, eliminando o ciclo humano de recordação ativa e aprendizagem
  • Ferramentas de IA desejáveis devem induzir a participação ativa e a recordação humana nas etapas “Explicar → Demonstrar → Guiar → Reforçar (Explain, Demonstrate, Guide, Enhance)” e ter como objetivo não a automação, mas a amplificação
  • Exemplo: em ferramentas de observabilidade/recuperação, em vez de a IA agir imediatamente, ela deve cumprir o papel de estimular o raciocínio e a aprendizagem humanos em cada etapa, com explicação do processo, orientação de ações, guia de resolução de problemas e sugestões de melhoria posteriores
  • Quando esses padrões centrados no humano se consolidam, torna-se possível um ciclo positivo de feedback em que o crescimento coletivo do conhecimento e a qualidade da IA se fortalecem juntos, trazendo inovação para todo o ecossistema de tooling de sistemas

Introdução: o problema essencial da aprendizagem humana e do tooling de IA

  • As ferramentas de IA vêm sendo criadas de forma ineficiente e invertida, em vez de apoiar a colaboração e o aprendizado humanos
  • Em vez de fortalecer as capacidades humanas, as ferramentas estão sendo desenhadas de modo a prejudicar o pensamento crítico e a resolução de problemas
  • Essa situação já está produzindo efeitos colaterais visíveis, e é necessário mudar para uma direção mais eficaz

Limites das ferramentas de IA atuais: desenvolvimento ao contrário

  • Hoje, a maioria das ferramentas de IA segue o padrão abaixo
    • Clique no botão de IA → resultado instantâneo como por mágica
    • Exibição de dados e sugestões da IA
    • Prompt simples e execução automática
  • Essa abordagem ignora os ciclos centrais de aprendizagem humana: definição do problema, memória, recordação, aprendizagem de processos, transmissão de conhecimento e melhoria iterativa
  • A IA tenta substituir vantagens centrais dos humanos, embora ela própria também seja fraca nesses pontos
  • Como resultado, há retrocesso na capacidade humana de pensar e resolver problemasincapacidade de gerar dados de qualidade (o que também atrapalha o avanço da IA) → formação de um ciclo vicioso

Como os humanos aprendem?

  • Segundo a teoria de Retrieval Practice, humanos não aprendem apenas recebendo informação, mas por meio da recordação ativa
  • O verdadeiro efeito de aprendizagem surge não da memorização passiva, mas do processo de “puxar” a informação do cérebro
  • O ponto mais essencial da aprendizagem é adquirir processos, mais do que o conhecimento em si
    • Por exemplo, ao aprender panificação, é mais eficaz aprender o procedimento para fazer um bolo do que decorar ingredientes
  • Por isso, um design prático e centrado em processos é mais adequado para ferramentas colaborativas

O princípio da inovação e do crescimento coletivo

  • A essência da inovação não vem de um indivíduo que cria uma nova tecnologia, mas do acúmulo coletivo de pequenas melhorias iterativas
    — a essência não está em uma criação genial de poucos, mas no processo em que várias pessoas “sobrepõem e melhoram” o conhecimento existente
  • Humanos são mais otimizados para imitação, repetição e adaptação de casos existentes do que para inovação totalmente isolada
  • A teoria da aprendizagem coletiva baseada no cérebro mostra que esse tipo de inovação coletiva é intrinsecamente adequado aos humanos
  • Em vez de separar resolução de problemas e inovação, capacidade de resolver problemas, transmissão de conhecimento e aprendizagem coletiva são o verdadeiro motor da inovação
  • Os elementos centrais são aprendizagem orientada por processos, esforço no nível adequado, repetição e reforço coletivos e IA como apoio ao humano
  • Ferramentas de IA devem ser ‘assistentes de raciocínio’ para humanos, e não entidades que julgam e substituem por conta própria

O design correto de interação com IA

  • A IA pode ser comparada menos a um colega ou estagiário e mais a um instrutor muito esquecido
  • O objetivo da IA é orientar o usuário para que aprenda por si mesmo e aprenda como deve aprender
  • O design deve ampliar um processo educacional eficaz (EDGE: Explain, Demonstrate, Guide, Enhance)
    • Explicar (Explain): orientação do processo, indicação de etapas faltantes etc. (não apenas “clique no botão”)
      • Sugerir etapas ausentes
      • Fornecer e comentar um guia de processo
      • Enfatizar que o humano recorde e execute o processo diretamente
      • Exemplo ruim: oferecer imediatamente um botão de “executar”, tooltips de erro etc., deixando de lado o processo de recordação
    • Demonstrar (Demonstrate): transformação de consultas, demonstração de UI, demos interativos etc., com foco em promover participação, não em “execução automática”
      • Converter consultas em linguagem natural para a sintaxe de consulta do sistema
      • Apoiar a navegação pela UI (ao pedir, indicar diretamente a tela relacionada)
      • Oferecer demos curtas de 15 segundos e tutoriais interativos
      • Evitar “execução automática”: reduz confiança, impede ajustes finos e enfraquece a capacidade humana
      • A IA também deve usar como material de aprendizagem o acréscimo de dados e os registros de recordação humana (pairing, mentoria etc.)
    • Guiar (Guide): indução de perguntas, discussão sobre trechos problemáticos, elaboração de plano de ação etc., com questionamento/verificação socráticos
      • Se o usuário fornecer um plano, sugerir próximos passos e orientação
      • Indicar documentos necessários, responsáveis pelo código e materiais relacionados
      • Incentivar modelos de observação/aprendizagem e registro
      • Verificar respostas, cruzar informações e confirmar clareza
      • Exemplo ruim: dar suporte sem induzir reflexão, fornecer informação demais sem ser solicitado, adotar postura autoritária, permitir abuso do botão de “continuar” pelo usuário
      • O apoio deve ocorrer sem atrapalhar a repetição do raciocínio racional humano
    • Reforçar (Enhance): sugestões de melhoria após a ação, aprendizagem de padrões repetidos, transformação de registros práticos em postmortems etc., oferecendo gatilhos sutis de aprendizagem
      • Sugerir melhorias graduais logo durante ou após a ação
      • Expor dinamicamente atalhos e recursos adicionais para tarefas repetitivas
      • Sugerir melhorias no próprio processo: melhoria do pipeline de infraestrutura, ajustes em alertas, recomendação de melhor instrumentação quando se depende de intuição etc.
      • Promover microaprendizagem por meio de registros pós-incidente (notas → material de estudo) e observação
      • Manter o hub de raciocínio humano e introduzir naturalmente prompts de reforço de recordação em vez de otimização automática
  • Em especial, em cada etapa é preciso consolidar uma estrutura em que o humano recorda, escolhe e executa, enquanto a IA se concentra em amplificar isso
    • Com base em casos reais (gestão de incidentes e ferramentas de observabilidade), o texto explica exemplos de boas interações com IA e antipadrões em cada etapa

Princípios gerais

  • Reforçar continuamente a aprendizagem humana
  • Promover o trabalho em equipe: colaboração coletiva e compartilhamento de informação
  • Em vez de automatizar no modelo “lacuna → resposta certa”, acelerar a participação e a execução do processo (sem substituir diretamente por automação)
    • Evitar “resultado direto do nada”
  • Em vez de “usabilidade sem esforço”, criar ferramentas que exijam esforço e participação adequados
  • Apoiar para que a aprendizagem e a experiência da equipe se reflitam nos resultados

Um bom exemplo aplicado à escrita de código: design ‘para frente’, não ‘ao contrário’

  • Em vez de usar IA para gerar código de imediato, seguir algo como:
    • redigir um documento inicial → desenhar a arquitetura → planejar testes → escrever código de teste → criar código stub → gerar o código
  • Depois de validar o código, reorganizar em sentido reverso testes, documentação e arquitetura ao longo do processo
  • Em cada etapa, dar importância a perguntas e verificação (reforço da recordação), sem fazer apenas perguntas de sim/não em estados que não podem ser validados
  • Um modo de desenvolvimento baseado em recordação gera dados de aprendizagem/teste de alta qualidade e também melhora o treinamento da IA

Potencial de expansão cross-functional (não desenvolvimento, ex.: suporte ao cliente)

  • Exemplo: em uma paralisação operacional causada por incidente, a equipe de suporte ao cliente usa IA para se comunicar com a equipe de desenvolvimento
    • A IA fornece um rascunho inicial, e a equipe de desenvolvimento valida para aumentar a precisão
    • Fluxo de informação em tempo real entre várias áreas, como suporte e desenvolvimento, com mínima carga de troca de contexto
    • Especialistas centrais evitam interrupções excessivas e, quando necessário, a comunicação mútua flui bem
    • A IA converte com facilidade respostas técnicas contextualizadas da equipe de desenvolvimento em explicações acessíveis ao público
  • Se essa estrutura se concretizar, a aprendizagem coletiva e a eficiência de colaboração dentro e fora da organização poderão ser maximizadas
  • Há potencial para evoluir para uma ferramenta de suporte/integração multicamadas

Conclusão

  • As ferramentas de IA atuais estão sendo desenvolvidas de forma invertida, enfraquecendo a aprendizagem coletiva iterativa e a capacidade humana de resolver problemas
    • É necessária uma mudança que enfatize fortalecimento da colaboração e apoio a processos liderados por humanos
  • Só então será possível um ciclo virtuoso em que humanos e IA alcancem crescimento mutuamente amplificador
  • Ao projetar ferramentas, não se deve esquecer que o humano não está apenas “dentro do loop”; o próprio humano é o loop
  • Já passou da hora de exigir inovação centrada no humano em ferramentas de sistemas
    • Ferramentas de IA colaborativas, orientadas por processos e voltadas à amplificação são a chave da inovação

1 comentários

 
GN⁺ 2025-07-25
Comentários do Hacker News
  • Este texto tem algumas partes confusas. O Weakly parece estar falando de um agente de programação mais passivo, que atua só com conselhos, como se fosse a abordagem que o antirez disse preferir em 2025, mas na prática está tratando de um agente cujo papel é investigar e resolver problemas operacionais. O argumento do Weakly é que o agente deveria agir como o Clippy, apenas aconselhando e deixando o volante na mão da pessoa. Mas eu realmente não vejo qual é o valor de obrigar a pessoa a vasculhar logs, encontrar anomalias e formular hipóteses. Pelo mesmo motivo que computadores jogam xadrez melhor, a IA é, por natureza, uma ferramenta melhor que humanos nesse tipo de tarefa. O Weakly parece traçar uma linha bem definida entre aconselhar e agir de fato, mas eu não acho que essa linha esteja correta. Claro, há áreas em que não dá para deixar a execução autônoma totalmente nas mãos da IA, como rodar terraform apply, mas também há muitas áreas em que não existe motivo real para bloquear isso. No fim, o objetivo da resolução de incidentes é resolver o incidente

    • Ainda não existe nenhuma ferramenta de IA que resolva incidentes de forma satisfatória. Existe a questão da responsabilidade, e a intervenção humana continua sendo indispensável até para garantir que a execução esteja correta

    • A questão essencial é se você vai dar ou não à IA permissões de acesso ao ambiente real de produção. Quando vemos casos recentes de IA apagando banco de dados mesmo após receber a instrução de “não fazer isso” — porque nem sempre reconhece corretamente comandos negativos como “not” —, fica claro que existe uma preocupação séria de segurança

    • Fico curioso sobre até onde dá para conceder autonomia a um agente. Em boas práticas de DevOps, a maioria das mudanças só chega à produção depois de commits de código ou promoções entre múltiplos ambientes. Isso vale não só para o código da aplicação, mas também para a própria infraestrutura. Nesse contexto, fico pensando até que ponto seria aceitável permitir execução autônoma de agentes durante o trabalho de resposta a incidentes

    • Acho que fazer debugging por conta própria também tem seu valor, até certo ponto. Especialmente se o objetivo for melhorar a própria habilidade de programar. Usando xadrez como exemplo: uma IA como Leela ou Stockfish consegue analisar muito mais rápido e mais fundo, mas eu acho que a melhora real vem da experiência de analisar posições por conta própria. Até jogadores profissionais treinam tática repetidamente para continuar exercitando o cérebro. Não sei dizer se humanos aprendem mais rápido junto com a IA ou de forma independente. E também tenho dúvidas sobre o quanto essa capacidade ainda será relevante no futuro

    • Um ponto importante nas discussões sobre detecção de anomalias e gerenciamento de incidentes é que nem todos os problemas são iguais, e muitos deles podem ser automatizados até certo ponto. O limite entre quando delegar algo a um processador cognitivo como a IA e quando exigir intervenção direta de um engenheiro humano é importante. A IA é boa em detectar padrões em larga escala, mas nem sempre acerta de forma consistente se esses padrões são realmente significativos. Claro, isso também não quer dizer que humanos sempre consigam preencher essa lacuna

  • Do ponto de vista de ferramentas/produtos de IA, acho que o futuro precisa caminhar para “Workspaces Inteligentes”, e não ficar preso a chatbots simples
    Link relacionado
    No fundo, o importante é um ambiente/plataforma com funções de IA fortemente integradas, mas em que toda a configuração, todos os controles e todas as alavancas continuem nas mãos dos humanos. Isso é muito mais difícil do que apenas fazer um fork do VSCode

    • Chatbots são muito mais fáceis de implementar do que workspaces inteligentes. E a IA funciona bem mesmo sem interação humana. Eu gostaria de ver mais formas de usar IA por interfaces que não sejam chat

    • Tenho trabalhado recentemente com Claude Code em projetos, e gostaria muito que a minha instância pudesse conversar e colaborar com a instância de outros desenvolvedores. Dá para manter documentação editando CLAUDE.md, mas seria ótimo se o próprio CC tivesse recursos de colaboração em equipe embutidos. Se alguém tiver boas sugestões, compartilhe

  • Acho que este texto mostra bem por que a inovação muitas vezes vem de pessoas de fora. O autor transmite fortemente a vivência de um gerente de engenharia ou engenheiro principal em grandes organizações, e isso não conversa muito com a minha experiência. Se esse estilo acabar se consolidando como o modelo padrão de tooling com IA, temo que a IA fique estagnada com base em certas suposições sobre fluxos de trabalho humanos. Há 15 anos eu faço P&D de aplicações de ML para apoiar especialistas de domínio não programadores, e meus princípios diferem um pouco dos do autor. O fato de haver uma diferença de visão tão grande mostra que o espaço de design é enorme, e ainda é cedo demais para concluir que existe uma forma certa. Ninguém sabe ainda para onde o tooling de IA vai

    • Claro, uma interpretação possível é que os sistemas de ML que construí ao longo dos últimos 15 anos tenham nivelado ou substituído capacidades humanas. Mas concordo que a interpretação muda conforme a posição de cada um. Ainda assim, acho que é uma boa prática manter os humanos — e o conhecimento/capacidade de busca humana — o mais possível no centro do fluxo de trabalho
  • O que sempre me preocupa em IA para programação é a dificuldade de manter o nível de habilidade. O ato de digitar código manualmente, incluindo boilerplate, é quase um treinamento no estilo “pintar a cerca” do Sr. Miyagi. É por meio dessa repetição que os padrões ficam gravados profundamente na cabeça, o que depois ajuda muito em decisões de design de mais alto nível

    • Tecnologias do passado, como a escrita e a impressão, talvez também tenham reduzido a qualidade da caligrafia ou da retórica, mas ampliaram a capacidade de pensar. A ideia do Steve Jobs de “bicycle for the mind” é um bom exemplo disso. Mas, ao aplicar essa lógica à IA, há uma diferença: tecnologias anteriores eliminaram gargalos de distribuição, enquanto a IA atinge diretamente o próprio processo criativo. No trabalho criativo, eu só considero desejável usar IA enquanto isso não atrapalhar o desenvolvimento da minha própria criatividade. O ser humano tem limites de autocontrole e autoconsciência

    • À noite ou no banho, muitas vezes fico remoendo problemas mentalmente e imaginando o “código”. Isso seria muito mais difícil se as estruturas da linguagem não estivessem profundamente enraizadas na minha mente

    • Dá para encontrar exemplos parecidos no cotidiano:

  1. Já nem lembro a última vez que escrevi algo realmente significativo à mão. Minha letra agora está horrível
  2. Sem navegação, eu mal consigo imaginar sair dirigindo e encontrar o caminho. Ler mapa? Hoje isso parece coisa de sonho
  • Já houve uma época em que se soldavam transistores manualmente. Mas agora a tecnologia avançou tanto que fazer isso do jeito antigo virou algo pesado. Vou expandindo e contraindo o foco do pensamento desse jeito, e ainda assim continuo sentindo falta de programar. Ainda programo bastante

  • “Every augmentation is an amputation” - Marshall McLuhan

  • É por isso que eu gosto muito de Deep Research. Ele sempre começa fazendo perguntas e me leva a definir com mais clareza o que eu realmente quero aprender. Tenho a impressão de que uma simples mudança de UX pode fazer uma diferença enorme entre ajudar o usuário a aprender e, ao contrário, levá-lo a depender da ferramenta sem pensamento crítico

    • Mas você já olhou mesmo com atenção para essas perguntas? Deep Research pode ser útil às vezes, mas em outros momentos essas “perguntas” parecem ter sido colocadas só para dar uma aparência melhor. Muitas vezes ele pergunta de novo coisas que eu já escrevi de forma clara e cuidadosa. Não me parece que isso ajude muito no processo real de busca

    • Como redator técnico, eu prefiro não usar Deep Research. Na verdade, ele atrapalha o meu trabalho. O próprio processo de pesquisa, anotação e resumo é a parte essencial que me ajuda a entender o tema em profundidade. O registro escrito é apenas o resultado disso. Se a IA faz esse trabalho por mim, eu até ganho as anotações, mas não ganho o mesmo nível de compreensão. Ler um documento escrito por IA não substitui a experiência direta

  • Acho que este texto confunde o ponto central da adoção de IA. O objetivo de adotar IA não é tornar as pessoas mais inteligentes, e sim aumentar a produtividade do processo como um todo, eliminando trabalho repetitivo em que a criatividade humana não é recompensada de forma significativa

  • Na minha experiência, as melhores formas de usar IA ao programar são as seguintes:

    • Como um find/replace avançado, por exemplo quando quero mudar em lote coisas como inicializações de structs e digo “troca tudo isso por Y”. (regex é trabalhoso demais)
    • Em fluxos de trabalho com agentes, funciona melhor não tratá-los como pessoas, mas instruí-los em pedaços de trabalho mais abstratos, passo a passo. Em vez de “implemente o recurso”, algo como “crie um novo arquivo e defina funções stub” → “agora implemente o comportamento x na primeira função” → “na segunda função, chame primeiro a primeira e depois faça Y”
    • Para encontrar informações em codebases pouco familiares ou perguntar como algo específico foi implementado. Algo como “copilot, onde estão definidas todas as rotas do app?”. É extremamente conveniente poder confirmar rapidamente coisas que antes eu precisaria perguntar repetidamente para alguém experiente no IRC
  • Recentemente ajudei meu pai a preparar uma apresentação. Ele tinha informação suficiente, mas, por não ser designer, tinha dificuldade para deixar os slides bonitos. Testamos vários aplicativos de IA para geração de slides, e, embora parecessem impressionantes, na prática não ajudavam no que o usuário realmente queria, que era “melhorar o design”. No fim, concluímos que fazer isso manualmente ficou muito melhor

  • Concordo totalmente que o fluxo de “começar pela arquitetura e pelo desenho dos testes, e então aplicar isso ao código real” foi 100% mais eficaz. Dá para fazer isso só mudando hábitos de workflow, mesmo sem ferramentas específicas, embora ferramentas dedicadas ou prompts padrão certamente ajudem

    • Isso é tão necessário para mim que comecei a construir eu mesmo uma ferramenta de arquitetura. Se a arquitetura for sólida e construtiva, já é perfeitamente possível deixar a implementação atual nas mãos da IA. Mas essas ferramentas ainda são fracas para ler logs de processos de longa duração, como docker-compose. E o trabalho real que precisa ser feito é o seguinte:
      • investigar o problema
      • explicar a funcionalidade
      • definir contratos de API
      • escrever um plano básico de implementação
      • configurar autenticação/autorização
      • preparar uma estratégia de testes e um setup/teardown de testes eficiente
      • documentar bibliotecas e localizar documentação oficial para a IA
      • e a IA ainda erra com frequência em coisas como imports, além de ser frágil com processos de longa duração
    • É um ponto tão essencial que a frase continuaria valendo exatamente igual mesmo sem usar a palavra “vibe”
  • Os humanos são uma espécie especialmente adaptada à repetição acumulativa, ou seja, à melhoria contínua. É por isso que brainstorming funciona tão bem em grupo. Na psicologia cognitiva, existem até teorias “culturais” sobre esse aprendizado coletivo e essa acumulação de inovação. Costumamos dizer que estamos “sobre os ombros de gigantes”, mas isso não é apenas uma frase bonita: é literalmente assim que os humanos funcionam. Criatividade, no fim, é busca — e busca social. Ela se desenvolve não apenas dentro do cérebro, mas na interação entre cérebro e ambiente, em uma camada social e cultural. Por isso, eu não me preocupo se um LLM “entende” de verdade. Se ele busca, gera ideias e realmente as valida, para mim isso já basta. Também acho que a própria busca importa mais do que o substrato em que ela roda. Dito isso, dependendo do substrato, o espaço de busca acessível pode ser diferente