11 pontos por GN⁺ 5 시간 전 | 2 comentários | Compartilhar no WhatsApp
  • À medida que o código escrito por agentes continua se acumulando ao redor das pessoas, o fator que limita a velocidade de desenvolvimento está deixando de ser a capacidade de gerar código e passando a ser a velocidade de entendimento humano necessária para acompanhar o sistema e imaginar a próxima mudança
  • O objetivo de entender o código não se limita à verificação de aprovar ou rejeitar o resultado, mas a sugerir a próxima ideia e participar do processo criativo em vários ciclos sucessivos de trabalho do agente
  • Em vez de começar por diferenças brutas de código, ler primeiro um documento explicativo do código que reúne conhecimento de contexto, objetivo da mudança, diagramas interativos e diferenças narradas de código permite entender mais rápido a estrutura e a intenção da alteração
  • Os quizzes do documento explicativo e os micromundos que permitem manipular diretamente o processo de execução fazem com que a pessoa vivencie as mudanças de estado e o funcionamento interno do sistema, em vez de deixar o agente decidir por ela
  • Se a IA for usada não apenas como ferramenta de automação para tirar as pessoas do loop, mas também para criar ferramentas e simulações voltadas ao entendimento, pessoas e equipes podem participar ainda mais profundamente do loop

Humanos que não conseguem acompanhar a velocidade de geração de código

  • Como se uma pilha de código escrita por agentes continuasse crescendo ao redor de uma pessoa, a quantidade de código gerado aumenta, mas a velocidade com que humanos o entendem não cresce na mesma proporção
  • Só ler todas as diferenças de código linha por linha não basta para acompanhar a velocidade de trabalho dos agentes
  • Entender código pode assumir várias formas além do diff bruto
    • Documentos explicativos do código que ensinam o sistema e as mudanças
    • Quizzes que verificam se houve entendimento de fato
    • Micromundos para aprender manipulando diretamente o funcionamento interno
    • Espaços compartilhados onde o time inteiro forma o mesmo modelo mental

Entender não é verificar, é participar

  • Uma resposta comum para a pergunta de por que humanos precisam entender o código é que isso serviria para verificar o trabalho do agente
    • Confirmar se está de acordo com a especificação
    • Julgar se a estrutura é adequada
    • Decidir no fim pela aprovação/rejeição
  • Na apresentação, isso é representado como um julgamento binário de polegar para cima ou para baixo
    • Quando o papel humano é visto apenas como verificação, o entendimento se reduz a decidir se o resultado passa ou não passa
  • Mas os agentes também estão melhorando continuamente sua capacidade de autoverificação, executando o que produziram, testando e encontrando erros por conta própria
  • Quanto melhor os agentes fizerem verificação, mais surge a questão de onde os humanos continuam entrando
  • A alternativa é participar por meio do entendimento
    • A pessoa precisa saber o que o agente está fazendo para continuar sendo um membro ativo do processo criativo
    • Quando entende o sistema, ela não para em avaliar o resultado atual, mas consegue pensar em o que mudar na próxima etapa

Projetos não são um loop só, mas muitos loops

  • Um projeto real não é um loop único em que se dá uma instrução ao agente e se recebe um resultado
  • muitos loops iterativos conectados entre si, de definição de objetivo, implementação, verificação, correção e expansão
  • Em cada iteração, o nível de entendimento do sistema que a pessoa possui determina a qualidade e o alcance da próxima ideia
  • É preciso ter conceitos e estrutura suficientes na cabeça para lidar com fluidez com perguntas como
    • O que deve ser adicionado ou removido?
    • Que estrutura precisa ser alterada?
    • Que novas possibilidades surgiram na implementação atual?
  • Quando falta entendimento, até dá para reagir ao resultado do agente com “parece mais ou menos certo”, mas fica difícil liderar para onde o projeto deve ir

A dívida cognitiva que se acumula ao adiar o entendimento

  • Se você continua aceitando os resultados do agente sem entender o sistema, é possível avançar rápido no curto prazo
  • Mas, assim como a dívida técnica aumenta o custo de mudanças futuras, o trabalho que pula a etapa de entendimento deixa uma dívida cognitiva (cognitive debt)
  • Quando a dívida cognitiva se acumula, quem participa do projeto perde a visão do fluxo geral
    • Fica difícil entender por que o código chegou à estrutura atual
    • Fica difícil decidir onde conectar novos requisitos
    • Fica difícil discutir se a próxima mudança proposta pelo agente faz sentido
  • O problema na era da IA não é a falta de geração de código, mas o fato de as pessoas não terem conceitos suficientes sobre o sistema gerado

Aplicando métodos de ensino ao entendimento de código

  • Em ambientes de trabalho com IA que mudam rapidamente, o problema de construir entendimento humano se parece com um problema que a educação vem enfrentando há muito tempo
  • Para formar entendimento real, não basta transmitir fatos novos; é preciso oferecer junto conhecimento de contexto/intuição/prática/feedback
  • Também é possível aplicar ao entendimento de código métodos desenvolvidos na educação
    • Fornecer contexto e intuição antes dos detalhes de implementação
    • Fazer a pessoa recordar e responder depois da leitura
    • Oferecer um ambiente onde regras abstratas possam ser manipuladas diretamente
    • Fazer com que as pessoas compartilhem os mesmos conceitos e vocabulário

/explain-diff, que ensina as mudanças

  • /explain-diff é uma skill que transforma mudanças feitas por agentes em um documento explicativo estruturado
  • Pode gerar saída em HTML/Markdown ou como página do Notion, e o documento no Notion pode ser usado como um artefato colaborativo em que membros da equipe comentam e discutem juntos
  • Em vez de produzir uma simples lista de mudanças no código, ele gera um material explicativo pensado para que pessoas aprendam a alteração
  • No exemplo que muda a perspectiva da tela de um jogo, a abordagem não começa mostrando o código diretamente, mas segue esta ordem
    • Primeiro explica a forma de renderização do engine de jogo existente
    • Apresenta o objetivo da mudança: “fazer um jardim parecer tridimensional com técnicas de desenho 2D”
    • Explica o que é projeção isométrica para tornar compreensível o princípio visual da mudança
    • Só depois vai para o código de implementação real

Ensinar primeiro o conhecimento de contexto

  • Uma boa explicação começa não por “o que mudou”, mas por “o que existia antes da mudança”
  • Sem conhecer o sistema de coordenadas e a estrutura de renderização do engine existente, mesmo lendo o novo código de perspectiva fica difícil entender o motivo da mudança
  • O documento explicativo primeiro recompõe a estrutura do sistema existente, para que quem não tem o mesmo contexto do agente possa entrar na conversa
  • Isso não é um simples resumo, mas um processo de recolocar a pessoa no contexto atual do projeto

Criar intuição antes dos detalhes de implementação

  • Explicar a essência da mudança em uma frase antes do código ajuda a entender para que objetivo os detalhes de implementação apontam
  • No caso de fazer um jardim parecer tridimensional, em vez de começar pela fórmula da projeção isométrica, transmite-se primeiro o objetivo visual de fazer um desenho plano parecer 3D
  • Depois de entender o contexto e o objetivo, ao olhar os trechos de código fica mais fácil conectar o papel de cada cálculo e transformação no resultado geral
  • O objetivo é fazer da pessoa não uma leitora passiva de detalhes de código, mas uma participante em pé de igualdade que entende a intenção da mudança

Vivenciar transformações de coordenadas com diagramas interativos

  • Em vez de mostrar só imagens estáticas, usa-se um diagrama interativo em que a pessoa pode arrastar diretamente uma pedra no jardim
  • Ao mover a pedra, a posição na tela e as coordenadas internas mudam juntas, permitindo observar a transformação de coordenadas da projeção isométrica
  • Em comparação com apenas ler fórmulas ou código, isso ajuda a formar intuição manipulando diretamente a relação entre entrada e saída
  • Dá para incorporar HTML interativo dentro de uma página do Notion e transformar o próprio documento explicativo do código em um pequeno ambiente executável
  • A IA não fica só na redação da explicação; ela também pode gerar as ferramentas de visualização e manipulação necessárias para o entendimento

Transformando o diff bruto em diff narrado

  • Um diff de código comum lista os arquivos alterados em ordem de nome de arquivo
    • Não explica a relação entre arquivos
    • Não informa o objetivo da mudança
    • Não orienta em que ordem ler
  • Um diff narrado (literate diff) reorganiza as mudanças como o fluxo de um texto
    • Apresenta primeiro o objetivo da alteração
    • Explica arquivos e funções em uma ordem adequada ao entendimento
    • Insere entre as explicações apenas os trechos de código necessários
    • Mostra junto a relação entre o contexto ao redor e as escolhas de implementação
  • Se o diff bruto é como empilhar ingredientes sem preparo, o diff narrado se aproxima mais de editar a mudança como uma história
  • Depois de ler a explicação, revisar o diff bruto fica mais rápido, porque já se sabe por que cada trecho existe, o que acelera a revisão

Ler no papel a documentação gerada por IA

  • O documento explicativo final pode ser usado como um pacote explicativo de código
  • O diff bruto continua sendo lido, mas sempre depois do documento explicativo
  • Quando é preciso mais foco, o documento chega a ser impresso e lido no papel, em um café
  • Surge o paradoxo de que a atividade interativa de programar com IA acaba se transformando em um relatório estático em papel que permite concentração profunda
  • O ponto central não é usar a interface mais moderna, e sim converter a informação para um formato que as pessoas realmente entendam bem

A diferença entre sentir que leu e realmente entender

  • Mesmo com um bom documento explicativo, o ato de ler por si só não garante entendimento
  • É fácil a pessoa se iludir achando que entendeu ou vai lembrar do conteúdo apenas por ter acompanhado as frases com os olhos
  • A ideia vem de “books don't work”, de Andy Matuschak, e de Quantum Country, de Andy Matuschak e Michael Nielsen
  • Quantum Country insere quizzes de repetição espaçada no meio do texto para fazer o leitor recordar o conteúdo ativamente
  • Aplicando a mesma abordagem aos documentos explicativos de código, o material termina com cinco perguntas interativas sobre a mudança

Quizzes são o regulador de velocidade do loop de IA

  • Antes de enviar código para outra pessoa, usa-se a regra de que é preciso passar pelo quiz do documento explicativo
  • O mesmo critério vale ao revisar código escrito por outra pessoa
  • O quiz não é um extra para avaliar conhecimento, mas um mecanismo de controle de ritmo
  • Ao trabalhar com IA, o loop de implementação/correção/regeneração tende a andar mais rápido que o entendimento humano
  • O quiz força, em cada loop, as próximas perguntas
    • Você consegue explicar o que realmente mudou?
    • Entende por que foi usada essa estrutura?
    • Conhece as restrições que afetam a próxima mudança?
  • Se não conseguir passar, é preciso desacelerar o trabalho e reforçar o entendimento, o que permite que a pessoa continue sendo uma participante criativa

Micromundos vindos do Mathland de Seymour Papert

  • O segundo método, os micromundos, parte de uma ideia do educador Seymour Papert
  • Papert defendia que, assim como se vive na França para aprender francês, seria preciso viver em um Mathland, onde a matemática funciona naturalmente, para aprendê-la
  • É uma forma em que a criança, em vez de ouvir explicações passivamente, explora o ambiente guiada pela curiosidade e absorve conceitos matemáticos naturalmente
  • Aplicado ao código, isso significa não oferecer apenas documentos explicando o sistema, mas criar um ambiente em que a pessoa entre e experimente diretamente o modo de funcionamento
  • Um micromundo é um pequeno mundo configurado para observar bem certos princípios e mudanças de estado, em vez de expor o sistema de produção inteiro como ele é

Explorando um interpretador Prolog ao longo do tempo

  • Ao desenvolver um interpretador Prolog, era difícil captar intuitivamente o que acontecia dentro dele
  • Então foi criado, junto com o agente, um debugger dedicado para explorar o processo de execução passo a passo
  • Nesse debugger é possível verificar diretamente
    • Mover-se para frente e para trás no tempo de execução
    • Inspecionar quais valores estão na stack atual
    • Verificar que regras estão sendo avaliadas em cada etapa
    • Anotar o momento em que uma regra específica foi aplicada corretamente
  • Em vez de olhar só para o resultado final, a pessoa pode acompanhar diretamente como a execução de uma linguagem lógica se desenrola ao longo do tempo
  • Se o debugging ficar só com o agente, o problema pode até ser resolvido, mas é preciso que a pessoa manipule o debugger para que surja entendimento sobre a estrutura de execução

A diferença entre o agente debugar por você e criar ferramentas de entendimento

  • “O agente encontra o problema e corrige” e “o agente cria uma ferramenta para a pessoa explorar o problema” geram resultados diferentes
  • O primeiro traz o resultado rapidamente, mas pode quase não aumentar o entendimento humano do processo interno
  • O segundo oferece um processo de exploração em que a pessoa observa estados de execução, formula hipóteses e confere resultados
  • Mesmo delegando parte da escrita de código ao agente, o pensamento e a exploração centrais continuam sendo feitos diretamente pela pessoa
  • É uma abordagem que amplia o papel do agente, de fornecedor de respostas para criador de ambientes de entendimento

Fazer migração de site como se fosse um jogo

  • Ao migrar um site pessoal de um framework para outro, Claude escreveu um script de automação
  • Como o novo framework ainda não era familiar, mesmo lendo o script era difícil avaliá-lo como algo além de “parece mais ou menos certo”
  • Para resolver isso, foi pedido ao Claude que criasse um centro de comando em formato de videogame que executasse a migração diretamente
  • Nesse centro de comando é possível acompanhar visualmente
    • Apertar botões para executar cada etapa da migração
    • Exibir lado a lado o site antigo e o novo na mesma tela
    • Ver como a aparência do novo site muda a cada etapa
    • Observar em que ordem a árvore de arquivos vai se transformando
  • Em vez de rodar toda a transformação de uma vez, a pessoa vivencia diretamente o novo site ganhando vida passo a passo
  • Isso permite obter um entendimento semelhante ao de mover todos os arquivos manualmente, mas com o trabalho necessário e o ambiente de observação já preparados, tornando tudo muito mais rápido

Gerar código para entender código

  • O código que os agentes podem escrever não se limita a funcionalidades de produto ou scripts de automação
  • Eles também podem criar ferramentas temporárias para ajudar pessoas a entender outro código, como
    • Ferramentas de visualização de execução
    • Debuggers passo a passo
    • Telas de comparação lado a lado
    • Visualizadores de mudança na árvore de arquivos
    • Explicações conceituais interativas
    • Centros de comando que dividem o trabalho em pequenas etapas
  • Essas ferramentas têm valor suficiente mesmo quando não são código de produto mantido no longo prazo
  • Como o custo de criar código com IA caiu, tornou-se realista construir também ambientes de aprendizado descartáveis para uma pessoa e uma tarefa específicas

Em equipe, é preciso entender junto

  • Não basta que uma pessoa entenda o sistema para que o trabalho em equipe funcione bem
  • É preciso que os membros do time compartilhem o mesmo modelo mental, para que até expressões curtas evoquem a mesma estrutura e o mesmo funcionamento
  • Quando há vocabulário e imagens compartilhados, fica mais fácil trocar ideias de forma espontânea e desenvolver juntos novas direções
  • No caso contrário, se cada um trabalha isolado com seu próprio agente, surgem problemas como
    • Usar o mesmo termo com significados diferentes
    • Não compartilhar as premissas do plano técnico
    • Mesmo que os resultados se juntem, o entendimento não se junta
  • O uso de IA em equipe não é só uma questão de aumentar a produtividade individual, mas de construir um entendimento compartilhado de todo o time

Deixar o trabalho do agente e das pessoas no mesmo espaço compartilhado

  • No Notion, é possível executar agentes Claude e Cursor dentro da página
  • Os planos técnicos escritos por agentes são criados por padrão como páginas colaborativas
  • Membros do time podem revisar o plano criado pelo agente no mesmo lugar, sem copiá-lo para outro canal
    • Deixando comentários em frases específicas
    • Questionando escolhas de implementação
    • Editando o plano em conjunto
    • Mantendo no mesmo contexto as discussões do time e os resultados do agente
  • Em vez de o agente trabalhar em silos individuais, pessoas e agentes passam a pensar em torno de um documento comum
  • O espaço compartilhado não é um arquivo para guardar resultados, mas um lugar onde o time constrói modelos mentais em conjunto

O propósito do computador sempre foi ampliação

  • O problema de explicações/quizzes/micromundos para entender código não se limita à programação
  • As pessoas precisam de conhecimento não apenas para verificar resultados, mas para entender como o mundo funciona e participar das mudanças
  • Há cerca de 50 anos, Alan Kay imaginou o computador como um novo meio educacional melhor do que livros
  • Nos desenhos da época aparecem crianças olhando para dispositivos parecidos com tablets, mas não de forma passiva
    • Elas manipulam simulações físicas interativas
    • Jogam games enquanto modificam o código diretamente
    • Conferem como o código alterado muda o movimento físico
  • O computador não precisa ser uma máquina para transmitir informação estática; ele pode ser um meio dinâmico para mover, alterar e entender conceitos complexos

Não apenas automação, mas participação mais profunda

  • A ideia central é expressa por um meme em que um astronauta olha para a Terra e pergunta: “o propósito do computador era criar simulações dinâmicas para entender conceitos complexos?”, e o astronauta atrás responde: “sempre foi”
  • Se o propósito do computador e da IA for apenas remover trabalho humano, as pessoas podem ser empurradas para fora do sistema
  • Em vez disso, se a IA for usada para criar explicações/simulações/micromundos/espaços compartilhados, as pessoas podem entender mais conceitos e com mais profundidade
  • Como a IA reduz o custo de criar simulações, torna-se possível gerar sob demanda ambientes sob medida para aprender um conceito específico
  • O objetivo não é apenas tirar a pessoa do loop, mas fazer com que ela entre mais fundo no loop do que antes

Artigos relacionados

2 comentários

 
coremaker 4 시간 전

Para eliminar completamente o gargalo,

  • a confiabilidade dos resultados gerados com IA precisa ser maior do que é hoje, e isso precisa ser percebido pelas pessoas (CEO, gestores).
  • Se for possível assumir um certo nível de risco, considero que uma parte considerável dos gargalos poderá ser eliminada. Por isso, em situações em que o risco é controlado, talvez valha a pena aplicar isso ativamente sem intervenção humana.
  • Se for inevitável adotar Human In The Loop, não se deve criar um processo que dependa completamente de uma única pessoa. Ele precisa poder ser executado por qualquer pessoa e, dependendo da situação, deve haver condição de alocar N pessoas.
  • A capacidade de identificar gargalos precisa ser aprimorada não só pelos profissionais da linha de frente, mas também pelos gestores e pelo CEO. A maioria dos gargalos pode ser eliminada ou reduzida por meio de tomada de decisão.
  • Esse tipo de discussão deve ser feito não pelos profissionais da linha de frente, mas pelos gestores e pelo CEO.
 
shakespeares 4 시간 전

Como a estrutura de cognição e memória das pessoas é dividida em memória de curto prazo e memória de longo prazo, eu diria que, por mais que se tente aumentar assim a velocidade de codificação da IA, o mais eficiente para a dívida cognitiva é a pessoa ir verificando no meio do processo e acumulando memória de curto prazo.