<\/p>\n\n\n\n
Faz um tempo que fa\u00e7o pair programming com IA em c\u00f3digo de produ\u00e7\u00e3o de verdade. N\u00e3o por novidade, n\u00e3o para testar \u2014 porque funciona. O que quero discutir aqui n\u00e3o \u00e9 se IA \u00e9 \u00fatil. Essa quest\u00e3o j\u00e1 est\u00e1 resolvida, pelo menos pra mim. O que quero discutir \u00e9 como <\/em>torn\u00e1-la \u00fatil de verdade \u2014 as decis\u00f5es que transformam uma ferramenta capaz em uma parceira de design genu\u00edna.<\/p>\n\n\n\n Este artigo \u00e9 sobre uma sess\u00e3o espec\u00edfica. Eu tinha uma classe de 295 linhas que precisava virar um m\u00f3dulo bem estruturado \u2014 limpo o suficiente para quem sabe virar uma gem. Trabalhei com o Claude do in\u00edcio ao fim. O projeto foi o LexxyPrawn<\/strong>: um m\u00f3dulo Ruby que transforma o JSON do editor de rich-text Lexxy <\/a>em um PDF gerado pelo Prawn<\/a>. O contexto \u00e9 espec\u00edfico; as li\u00e7\u00f5es, n\u00e3o.<\/p>\n\n\n\n O que vem a seguir \u00e9 um relato detalhado de como essa sess\u00e3o realmente aconteceu \u2014 os prompts que funcionaram, as conversas de design que moldaram o resultado, e os padr\u00f5es que continuo usando. O c\u00f3digo era Ruby. As li\u00e7\u00f5es valem para qualquer linguagem, qualquer stack, qualquer dev que j\u00e1 usa IA no dia a dia e quer ir mais fundo.<\/p>\n\n\n\n Parte 1 \u2014 Uma Sess\u00e3o de AI Pair Programming<\/strong><\/p>\n\n\n\n O Ponto de Partida<\/strong><\/p>\n\n\n\n Uma \u00fanica classe de 295 linhas que traduzia JSON de um editor rich-text para PDF – lidando com t\u00edtulos, par\u00e1grafos, listas, cita\u00e7\u00f5es, links, divisores, tabelas e anexos de imagem, mais toda a formata\u00e7\u00e3o inline de texto, em um \u00fanico arquivo. Sem testes. O objetivo: isol\u00e1-la em um m\u00f3dulo limpo e extra\u00edvel como gem.<\/p>\n\n\n\n Como Trabalhamos<\/strong><\/p>\n\n\n\n N\u00e3o come\u00e7amos escrevendo c\u00f3digo. Come\u00e7amos com um plano – decidindo o design antes de tocar em qualquer arquivo. Depois constru\u00edmos incrementalmente, um tipo de n\u00f3 por vez, cada etapa com seus pr\u00f3prios testes e uma checagem do linter antes de avan\u00e7ar. No final, o monolito antigo havia sumido, substitu\u00eddo por 17 arquivos focados.<\/p>\n\n\n\n O que fez o ritmo funcionar foi uma restri\u00e7\u00e3o expl\u00edcita desde o primeiro prompt: a IA pediria permiss\u00e3o antes de cada nova etapa. Diffs pequenos e revis\u00e1veis em vez de uma mudan\u00e7a gigante. Essa regra impediu a sess\u00e3o de virar um amontoado de c\u00f3digo que eu teria que limpar depois.<\/p>\n\n\n\n Onde Ficou Interessante<\/strong><\/p>\n\n\n\n A parte mec\u00e2nica \u2014 extrair, testar, repetir \u2014 foi tranquila. A parte interessante foi todo o resto.<\/p>\n\n\n\n Houve momentos em que paramos para avaliar 3 abordagens diferentes para um problema de design antes de escolher uma. Um momento em que percebi que algo estava errado, identifiquei o problema, e aquele instinto virou a melhor refatora\u00e7\u00e3o da sess\u00e3o. Um momento em que paramos de confiar na mem\u00f3ria e fomos ler o c\u00f3digo-fonte da biblioteca antes de continuar. E uma regress\u00e3o que apareceu no meio da sess\u00e3o \u2014 um comportamento de formata\u00e7\u00e3o que quebrou silenciosamente na refatora\u00e7\u00e3o \u2014 que corrigimos do jeito certo: teste primeiro, provar que falha, a\u00ed sim corrigir.<\/p>\n\n\n\n 70 testes, 102 asser\u00e7\u00f5es, 0 falhas ao final. Mas esse n\u00famero n\u00e3o \u00e9 o ponto.<\/p>\n\n\n\n O Que Ficou Depois da Sess\u00e3o<\/strong><\/p>\n\n\n\n \u00c0 medida que conven\u00e7\u00f5es iam surgindo \u2014 prefer\u00eancias sobre nomenclatura, formata\u00e7\u00e3o, estilo de c\u00f3digo \u2014 elas eram registradas como regras permanentes em vez de corre\u00e7\u00f5es pontuais. No final, essas regras estavam sendo aplicadas automaticamente ao c\u00f3digo novo, sem precisar lembrar.<\/p>\n\n\n\n \u00c9 essa parte que se acumula. N\u00e3o o c\u00f3digo de uma sess\u00e3o espec\u00edfica, mas o entendimento compartilhado que se carrega para a pr\u00f3xima.<\/p>\n\n\n\n A Parte 2 \u00e9 sobre os prompts espec\u00edficos que fizeram tudo isso acontecer.<\/p>\n\n\n\n Parte 2 \u2014 Prompts que Geraram \u00d3timas Intera\u00e7\u00f5es<\/strong><\/p>\n\n\n\n Os prompts que realmente fizeram essa sess\u00e3o avan\u00e7ar, agrupados pelo padr\u00e3o de colabora\u00e7\u00e3o que cada um demonstra \u2014 com uma nota sobre como cada um se desenrolou.<\/p>\n\n\n\n “We will now refactor Lexxy::PdfRenderer. First and foremost, I envision this class becoming a gem in the future\u2026 DO NOT write all of the new nodes in one step, let’s write them one by one, extracting from pdf_renderer one content at a time, and you willask me permission for each one.”<\/em><\/p>\n\n\n\n “Vamos agora refatorar o Lexxy::PdfRenderer. Antes de mais nada, eu imagino essa classe se tornando uma gem no futuro\u2026 N\u00c3O escreva todos os novos n\u00f3s de uma vez, vamos escrev\u00ea-los um por um, extraindo do pdf_renderer um conte\u00fado por vez, e voc\u00ea vai me pedir permiss\u00e3o para cada um.”<\/em><\/p>\n<\/blockquote>\n<\/blockquote>\n\n\n\n Como foi: <\/strong>Esse \u00fanico prompt definiu o destino (um m\u00f3dulo extra\u00edvel como gem), a estrutura (uma classe por n\u00f3) e <\/em>o ritmo de trabalho (incremental, com permiss\u00e3o a cada passo). Como o ritmo era expl\u00edcito, a sess\u00e3o inteira virou uma s\u00e9rie de etapas pequenas e revis\u00e1veis em vez de um diff gigante. A cl\u00e1usula “voc\u00ea vai me pedir permiss\u00e3o para cada um” foi a instru\u00e7\u00e3o mais importante \u2014 ela manteve o humano no controle o tempo todo.<\/p>\n\n\n\n Li\u00e7\u00e3o: <\/strong>o melhor prompt inicial n\u00e3o define s\u00f3 o que <\/em>construir \u2014 define como voc\u00eas v\u00e3o trabalhar juntos<\/em>.<\/p>\n\n\n\n 2. Seja Curioso \u2014 Questione Qualquer Coisa que Pare\u00e7a Estranha<\/strong><\/p>\n\n\n\n “now LexxyPrawn::Node. Why is there only 4 aliases?”<\/em><\/p>\n\n\n\n <\/p>\n\n\n\n “agora LexxyPrawn::Node. Por que tem s\u00f3 4 aliases?”<\/em><\/p>\n<\/blockquote>\n<\/blockquote>\n\n\n\n <\/p>\n\n\n\n <\/p>\n\n\n\n “why base implements a private method for pdf and config, but not for fragments?<\/em> “<\/em><\/p>\n\n\n\n <\/p>\n\n\n\n “por que a base implementa um m\u00e9todo privado para pdf e config, mas n\u00e3o para fragments?”<\/em><\/p>\n<\/blockquote>\n<\/blockquote>\n\n\n\n Como foi: <\/strong>Ambas eram perguntas genu\u00ednas, n\u00e3o corre\u00e7\u00f5es \u2014 e as duas encontraram algo. A primeira revelou que 3 dos 4 aliases eram redundantes (mapeando um nome para ele mesmo), ent\u00e3o os deletamos. A segunda exp\u00f4s uma inconsist\u00eancia de design real e levou a uma decis\u00e3o deliberada de adicionar o delegador que faltava. A curiosidade fez mais trabalho de design do que qualquer instru\u00e7\u00e3o.<\/p>\n\n\n\n Li\u00e7\u00e3o: <\/strong>trate o output da IA como um rascunho a ser interrogado. “Por que est\u00e1 assim?” \u00e9 uma pergunta poderosa.<\/p>\n\n\n\n 3. Exija Op\u00e7\u00f5es Antes de Decidir<\/strong><\/p>\n\n\n\n “pros and cons about the tempfile lifecycle proposes”<\/em><\/p>\n\n\n\n <\/p>\n\n\n\n “pr\u00f3s e contras das propostas de ciclo de vida do tempfile”<\/em><\/p>\n<\/blockquote>\n<\/blockquote>\n\n\n\n <\/p>\n\n\n\n <\/p>\n\n\n\n “I want you to fold option C so we can better analyze.”<\/em><\/p>\n\n\n\n <\/p>\n\n\n\n “quero que voc\u00ea inclua a op\u00e7\u00e3o C para analisarmos melhor.”<\/em><\/p>\n<\/blockquote>\n<\/blockquote>\n\n\n\n Como foi: <\/strong>Em vez de aceitar a primeira sugest\u00e3o, pedi uma an\u00e1lise real de trade-offs e explicitamente trouxe uma terceira op\u00e7\u00e3o para a mesa. Chegamos a um modelo de ownership com escopo de bloco que era significativamente melhor do que onde hav\u00edamoscome\u00e7ado. A decis\u00e3o foi minha, tomada com informa\u00e7\u00e3o completa.<\/p>\n\n\n\n Li\u00e7\u00e3o: <\/strong>force a compara\u00e7\u00e3o. “Me d\u00e1 os trade-offs” transforma a IA de uma m\u00e1quina de respostas em uma parceira de design.<\/p>\n\n\n\n 4. Traga Evid\u00eancia Real e Questione o Plano<\/strong><\/p>\n\n\n\n “before going further with the markup approach, check this snippet from prawn-tablemanual\u2026”<\/em><\/p>\n\n\n\n <\/p>\n\n\n\n “antes de continuar com a abordagem de markup, confira esse trecho do manual doprawn-table\u2026”<\/em><\/p>\n<\/blockquote>\n<\/blockquote>\n\n\n\n <\/p>\n\n\n\n <\/p>\n\n\n\n “lets discuss, from what I understood from the snippet, the text_fragment can be used in the cell as it is, no need for markup tags, no?”<\/em><\/p>\n\n\n\n <\/p>\n\n\n\n “vamos discutir \u2014 pelo que entendi do trecho, o text_fragment pode ser usado na c\u00e9lula como est\u00e1, sem precisar de tags de markup, n\u00e3o?”<\/em><\/p>\n<\/blockquote>\n<\/blockquote>\n\n\n\n Como foi: <\/strong>Essa intera\u00e7\u00e3o foi bem interessante. Colei o manual da biblioteca e questionei o plano <\/em>com uma hip\u00f3tese razo\u00e1vel. Em vez de contornar a d\u00favida, a IA foi ler o c\u00f3digo-fonte <\/em>do prawn-table para resolver definitivamente. O questionamento transformou a resposta de <\/em>baseada em mem\u00f3ria para baseada em evid\u00eancia.<\/p>\n\n\n\n Li\u00e7\u00e3o: <\/strong>uma IA raciocina a partir da mem\u00f3ria de treinamento por padr\u00e3o. Jogar documenta\u00e7\u00e3o real na mesa – e questionar a abordagem – for\u00e7a a verifica\u00e7\u00e3o.<\/p>\n\n\n\n 5. Confie nos Seus Instintos Arquiteturais<\/strong><\/p>\n\n\n\n <\/p>\n\n\n\n “something bothering me is that wrapped_table node deals directly withaction_text_attachment, although there is a node specialized on it\u2026 If CellContent delegates its real ‘rendering power’ to Nodes, we could fix both image and text formatting cases.”<\/em><\/p>\n\n\n\n <\/p>\n\n\n\n “o que me incomoda \u00e9 que o wrapped_table node lida diretamente com o action_text_attachment, sendo que existe um n\u00f3 especializado nisso\u2026 Se o CellContent delegar seu ‘poder de renderiza\u00e7\u00e3o’ real para os Nodes, poder\u00edamos resolver tanto o caso de imagem quanto o de formata\u00e7\u00e3o de texto.”<\/em><\/p>\n<\/blockquote>\n<\/blockquote>\n\n\n\n Como foi: <\/strong>Percebi a duplica\u00e7\u00e3o antes de a IA sinalizar. Esse instinto levou \u00e0 melhor refatora\u00e7\u00e3o da sess\u00e3o. A IA adicionou uma restri\u00e7\u00e3o que eu n\u00e3o havia percebido ainda, mas a dire\u00e7\u00e3o foi inteiramente minha.<\/p>\n\n\n\n Li\u00e7\u00e3o:<\/strong> o seu “isso me incomoda” \u00e9 sinal, n\u00e3o ru\u00eddo – identifique o desconforto mesmo antes de ter a solu\u00e7\u00e3o.<\/p>\n\n\n\n 6. Ensine Regras Dur\u00e1veis, N\u00e3o Corre\u00e7\u00f5es Pontuais<\/strong><\/p>\n\n\n\n “add a new code rule to CLAUDE.md: keyword params with the same name as the variables, can omit the variable\u2026”<\/em><\/p>\n\n\n\n <\/p>\n\n\n\n “adicione uma nova regra de c\u00f3digo ao CLAUDE.md: keyword params com o<\/em> mesmo nome das vari\u00e1veis podem omitir a vari\u00e1vel\u2026”<\/em><\/p>\n<\/blockquote>\n<\/blockquote>\n\n\n\n <\/p>\n\n\n\n “another rule: prefer to use meaningful variable names\u2026 except the traditionals, like i for loops or f\/ff for simple_form.”<\/em><\/p>\n\n\n\n <\/p>\n\n\n\n “outra regra: prefira usar nomes de vari\u00e1veis significativos\u2026 exceto os tradicionais, como i para loops ou f\/ff para simple_form.”<\/em><\/p>\n<\/blockquote>\n<\/blockquote>\n\n\n\n <\/p>\n\n\n\n <\/p>\n\n\n\n “but add a new styling rule: whenever you write a block, add an empty line above (unless the block is the first code in the scope) and below\u2026”<\/em><\/p>\n\n\n\n <\/p>\n\n\n\n “mas adicione uma nova regra de estilo: sempre que escrever um bloco, adicione uma linha em branco acima (a menos que o bloco seja o primeiro c\u00f3digo no escopo) e abaixo\u2026”<\/em><\/p>\n<\/blockquote>\n<\/blockquote>\n\n\n\n Como foi: <\/strong>Cada uma dessas virou uma conven\u00e7\u00e3o permanente do projeto em vez de uma corre\u00e7\u00e3o pontual. No final, a IA estava aplicando as regras automaticamente ao c\u00f3digo novo sem precisar ser lembrada. Uma at\u00e9 capturou um gotcha do Ruby no meio da sess\u00e3o \u2014 que foi adicionado de volta na regra.<\/p>\n\n\n\n Li\u00e7\u00e3o: <\/strong>quando voc\u00ea corrige uma IA, se pergunte se \u00e9 uma regra. Codificar uma vez rende em todos os arquivos seguintes. Suas conven\u00e7\u00f5es se acumulam.<\/p>\n\n\n\n 7. Mantenha o N\u00edvel de Qualidade<\/strong><\/p>\n\n\n\n “fix it” (sobre uma regress\u00e3o de sub\/superscript pr\u00e9-existente que havia sido identificada)<\/p>\n\n\n\n <\/p>\n\n\n\n “corrige isso”<\/em><\/p>\n<\/blockquote>\n<\/blockquote>\n\n\n\n Como foi: <\/strong>Prompt curto, retorno grande. A corre\u00e7\u00e3o veio com um teste de regress\u00e3o TDD \u2014 e, criticamente, provamos que o teste falhava <\/em>contra o comportamento com bug antes de restaurar a corre\u00e7\u00e3o.<\/p>\n\n\n\n Li\u00e7\u00e3o: <\/strong>quando a IA exp\u00f5e um bug latente, “corrige isso” deve implicar “e prove que continua corrigido.”<\/p>\n\n\n\n O fio condutor: <\/strong>os prompts mais fortes n\u00e3o eram os mais longos nem os mais t\u00e9cnicos. Eram os que mantinham o humano no controle do design – questionando, exigindo op\u00e7\u00f5es, trazendo evid\u00eancia, codificando regras e controlando o ritmo. A IA digitou; o humano fez a engenharia.<\/p>\n\n\n\n Conclus\u00e3o \u2014 Tudo que Importa, no Mesmo Lugar<\/strong><\/p>\n\n\n\n No final dessa sess\u00e3o, t\u00ednhamos 17 arquivos focados, 70 testes, 0 falhas e o l\u00ednter limpo. Mas o output real n\u00e3o foi o c\u00f3digo. Foi um conjunto de padr\u00f5es de colabora\u00e7\u00e3o que se sustentaram em condi\u00e7\u00f5es reais \u2014 um legado bagun\u00e7ado, ambiguidade arquitetural genu\u00edna, uma regress\u00e3o ao vivo, e uma biblioteca cujo comportamento precisamos verificar na fonte.<\/p>\n\n\n\n Aqui est\u00e3o todas as li\u00e7\u00f5es, reunidas:<\/p>\n\n\n\n 1<\/strong>. O melhor prompt inicial define como voc\u00ea quer trabalhar, n\u00e3o s\u00f3 o que construir.<\/strong><\/p>\n\n\n\n Vis\u00e3o + limites + ritmo \u2014 os 3, desde o in\u00edcio.<\/p>\n\n\n\n 2<\/strong>. “Por que est\u00e1 assim?” \u00e9 uma pergunta poderosa.<\/strong><\/p>\n\n\n\n Curiosidade acima de instru\u00e7\u00f5es. Questione o output antes de aceitar.<\/p>\n\n\n\n 3.<\/strong> “Me d\u00e1 os trade-offs” transforma uma m\u00e1quina de respostas em parceira de<\/strong> design.<\/strong><\/p>\n\n\n\n N\u00e3o aceite a primeira sugest\u00e3o. Force a compara\u00e7\u00e3o.<\/p>\n\n\n\n 4.<\/strong> Traga evid\u00eancia real e questione o plano. <\/strong><\/p>\n\n\n\n Uma IA raciocina a partir da mem\u00f3ria por padr\u00e3o. Documenta\u00e7\u00e3o real \u2014 e questionamento genu\u00edno \u2014 for\u00e7am verifica\u00e7\u00e3o.<\/p>\n\n\n\n 5.<\/strong> Seu desconforto arquitetural \u00e9 sinal, n\u00e3o ru\u00eddo. <\/strong><\/p>\n\n\n\n Identifique-o antes mesmo de ter a solu\u00e7\u00e3o. A IA ajuda a articular a restri\u00e7\u00e3o; a dire\u00e7\u00e3o vem de voc\u00ea.<\/p>\n\n\n\n 6.<\/strong> Quando voc\u00ea corrige uma IA, pergunte se \u00e9 uma regra. <\/strong><\/p>\n\n\n\n Codificar uma vez rende em todos os arquivos seguintes. Suas conven\u00e7\u00f5es se acumulam.<\/p>\n\n\n\n 7<\/strong>. “Corrige isso” deve implicar “e prove que continua corrigido.” <\/strong><\/p>\n\n\n\n Testes de regress\u00e3o n\u00e3o s\u00e3o opcionais. Se um bug vale corrigir, vale um teste que teria pego antes.<\/p>\n\n\n\n Os momentos mais valiosos dessa sess\u00e3o n\u00e3o foram aqueles em que a IA escreveu c\u00f3digo. Foram as conversas de design \u2014 o vai e vem sobre ownership, duplica\u00e7\u00e3o, verifica\u00e7\u00e3o. O tipo de pensamento que acontece entre dois engenheiros que confiam um no outro o suficiente para questionar.<\/p>\n\n\n\n \u00c9 assim que parece um bom pair programming. E foi isso que aconteceu aqui.<\/p>\n\n\n\n Ah, e mais uma coisa.<\/p>\n\n\n\n Voc\u00ea acabou de ler um artigo sobre colabora\u00e7\u00e3o humano-IA no desenvolvimento de software. A estrutura, a prosa, a introdu\u00e7\u00e3o, a conclus\u00e3o, as sete li\u00e7\u00f5es \u2014 tudo foi escrito pelo Claude, com base em notas de sess\u00e3o e documenta\u00e7\u00e3o de arquitetura fornecidas pelo desenvolvedor. Sem edi\u00e7\u00e3o humana. A contribui\u00e7\u00e3o do humano foi a sess\u00e3o em si: as decis\u00f5es, os instintos, as perguntas e o c\u00f3digo.<\/p>\n\n\n\n Ent\u00e3o quando eu disse a IA digitou <\/em>\u2014 era mais literal do que voc\u00ea imaginava.<\/p>\n\n\n\n A quest\u00e3o n\u00e3o \u00e9 se a IA consegue escrever seus artigos. \u00c9 se voc\u00ea est\u00e1 fazendo as perguntas certas.<\/p>\n\n\n\n Escrito por: Fillipe Palhares<\/p>\n","protected":false},"excerpt":{"rendered":" Uma sess\u00e3o real de pair programming com Claude revelou 7 li\u00e7\u00f5es para transformar a IA em uma parceira de design, melhorar a arquitetura do c\u00f3digo e manter o humano no controle da engenharia de software. Leia o artigo completo.<\/p>\n","protected":false},"author":2,"featured_media":1504,"comment_status":"closed","ping_status":"open","sticky":false,"template":"","format":"standard","meta":[],"categories":[15,23,8],"tags":[1241,1243,1239,1016,1017,1242,1238,1237,1240,1015],"yoast_head":"\r\n\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n