Gitanjali Venkatraman faz ilustrações maravilhosas de assuntos complexos (é por isso que fiquei tão feliz em trabalhar com ela em nosso Especialistas Generalistas artigo). Ela publicou agora o mais recente de sua série de guias ilustrados: abordando o complexo tema da Modernização de Mainframe
Nele ela ilustra a história e o valor dos mainframes, por que a modernização é tão complicada e como resolver o problema dividindo-o em pedaços tratáveis. Adoro a clareza de suas explicações e sorrio frequentemente com sua maneira de realçar suas palavras com suas imagens peculiares.
❄ ❄ ❄ ❄ ❄
Gergely Orosz em mídia social
Opinião impopular:
As ferramentas atuais de revisão de código simplesmente não fazem muito sentido para código gerado por IA
Ao revisar o código, eu realmente quero saber:
- O immediate feito pelo desenvolvedor
- Quais correções o outro desenvolvedor fez no código
- Marcação clara do código gerado por IA não alterado por um ser humano
Algumas pessoas reagiram dizendo que não se importam (e não deveriam se importar) se foi escrito por um humano, gerado por um LLM ou copiado e colado do Stack Overflow.
Na minha opinião, isso importa bastante – por causa do segundo propósito very important da revisão de código.
Quando questionadas sobre por que fazer revisões de código, a maioria das pessoas responderá ao primeiro propósito very important – controle de qualidade. Queremos garantir que o código incorreto seja bloqueado antes de atingir linha principal. Fazemos isso para evitar bugs e outros problemas de qualidade, em explicit a compreensibilidade e a facilidade de alteração.
Mas ouço com menos frequência o segundo propósito very important: a revisão de código é um mecanismo para comunicar e educar. Se estou enviando algum código abaixo do padrão e ele for rejeitado, quero saber o motivo para poder melhorar minha programação. Talvez eu não conheça alguns recursos da biblioteca, ou talvez haja alguns padrões específicos do projeto que ainda não encontrei, ou talvez minha nomenclatura não seja tão clara quanto eu pensava. Quaisquer que sejam as razões, preciso saber para aprender. E meu empregador precisa que eu aprenda para que eu possa ser mais eficaz.
Precisamos conhecer o redator do código que revisamos para que possamos comunicar-lhes nossas melhores práticas, mas também para saber como melhorar as coisas. Com um humano, é uma conversa e talvez alguma documentação, se percebermos que precisamos explicar as coisas repetidamente. Mas com um LLM trata-se de como modificar seu contexto, bem como de os humanos aprenderem como conduzir melhor o LLM.
❄ ❄ ❄ ❄ ❄
Quer saber por que tenho feito tantos posts como esse recentemente? Eu explico por que Estou revivendo o weblog do hyperlink.
❄ ❄ ❄ ❄ ❄
Simon Wilson descreve como ele usa LLMs para criar aplicativos da internet descartáveis, mas úteis
Estas são as características que considero mais produtivas na construção de ferramentas desta natureza:
- Um único arquivo: JavaScript e CSS embutidos em um único arquivo HTML significa menos complicações para hospedá-los ou distribuí-los e, principalmente, significa que você pode copiá-los e colá-los de uma resposta LLM.
- Evite React ou qualquer coisa com uma etapa de construção. O problema com o React é que o JSX requer uma etapa de construção, o que torna tudo muito menos conveniente. Eu peço “não reagir” e pulo toda aquela toca do coelho.
- Carregue dependências de um CDN. Quanto menos dependências, melhor, mas se houver uma biblioteca bem conhecida que ajude a resolver um problema, ficarei feliz em carregá-la do CDNjs ou jsdelivr ou comparable.
- Mantenha-os pequenos. Algumas centenas de linhas significam que a capacidade de manutenção do código não importa muito: qualquer bom LLM pode lê-los e entender o que está fazendo, e reescrevê-los do zero com a ajuda de um LLM leva apenas alguns minutos.
Seu repositório inclui todas essas ferramentas, junto com transcrições dos chats que levaram os LLMs a construí-los.
❄ ❄ ❄ ❄ ❄
Obie Fernández: embora muitos engenheiros não fiquem impressionados com as ferramentas de IA, alguns engenheiros seniores as consideram realmente valiosas. Ele sente que os engenheiros seniores têm uma mentalidade muitas vezes tácita, o que, em conjunto com um LLM, permite que o LLM seja muito mais valioso.
Níveis de abstração e problemas de generalização são muito comentados porque são fáceis de nomear. Mas eles estão longe de ser toda a história.
Outras ferramentas aparecem com a mesma frequência no trabalho actual:
- Uma noção do raio da explosão. Saber quais mudanças são seguras para serem feitas em voz alta e quais devem ser silenciosas e contidas.
- Uma sensação de sequenciamento. Saber quando uma mudança tecnicamente correta ainda está errada porque o sistema ou a equipe ainda não está pronto para isso.
- Um instinto de reversibilidade. Preferir movimentos que mantenham as opções em aberto, mesmo que pareçam menos elegantes no momento.
- Uma consciência do custo social. Reconhecer quando uma solução inteligente irá confundir mais pessoas do que ajudar.
- Uma alergia à falsa confiança. Identificar locais onde os testes são verdes, mas o modelo está errado.
❄ ❄ ❄ ❄ ❄
Emil Stenstrom construí um analisador HTML5 em python usando agentes de codificação, usando Github Copilot no modo Agent com Claude Sonnet 3.7. Ele aprovou automaticamente a maioria dos comandos. Demorou “alguns meses fora do horário comercial”, incluindo pelo menos uma reinicialização do zero. O analisador agora passa em todos os testes do conjunto de testes html5lib.
Depois de escrever o analisador, ainda não conheço o HTML5 corretamente. O agente escreveu para mim. Eu o orientei quando se tratava de design de API e corrigi decisões erradas em alto nível, mas ele fez TODO o trabalho pesado e escreveu todo o código.
Eu mesmo lidei com todos os commits do git, revisando o código à medida que ele entrava. Não entendi todas as escolhas algorítmicas, mas entendi quando ele não fez a coisa certa.
Embora ele dê uma visão geral do que acontece, não há muitas informações sobre seu fluxo de trabalho e como ele interagiu com o LLM. Certamente não há detalhes suficientes aqui para tentar replicar sua abordagem. Isso contrasta com Simon Willison (acima), que possui hyperlinks detalhados para suas transcrições de bate-papo – embora sejam ferramentas muito menores e eu não as tenha examinado adequadamente para ver como são úteis.
Uma coisa que está clara, entretanto, é a necessidade very important de um conjunto de testes abrangente. Grande parte de seu trabalho é impulsionado por ter esse conjunto como um guia claro para ele e os agentes do LLM.
JustHTML tem cerca de 3.000 linhas de Python com mais de 8.500 testes aprovados. Eu não poderia ter escrito isso tão rapidamente sem o agente.
Mas “rapidamente” não significa “sem pensar”. Passei muito tempo revisando código, tomando decisões de design e orientando o agente na direção certa. O agente digitou; Eu pensei.
❄ ❄
Então Simon Willison portou a biblioteca para JavaScript:
Tempo decorrido desde a ideia do projeto até a biblioteca finalizada: cerca de 4 horas, durante as quais também comprei e decorei uma árvore de Natal com a família e assisti ao último filme Knives Out.
Uma de suas lições:
Se você puder reduzir um problema a um conjunto de testes robusto, poderá definir um loop de agente de codificação nele com um alto grau de confiança de que eventualmente terá sucesso. Eu liguei para isso projetando o loop de agente alguns meses atrás. Acho que é a habilidade chave para desbloquear o potencial dos LLMs para tarefas complexas.
Nossa experiência na Thoughtworks confirma isso. Temos trabalhado bastante recentemente na modernização de legados (mainframe e outros) usando IA para migrar sistemas de software program substanciais. Ter um conjunto de testes robusto é necessário (mas não suficiente) para fazer isso funcionar. Espero compartilhar as experiências dos meus colegas sobre isso nos próximos meses.
Mas antes de deixar o cargo de Willison, devo destacar as suas últimas questões abertas sobre a legalidade, a ética e a eficácia de tudo isto – vale a pena contemplá-las.