Relatório antrópico sobre como sua IA está mudando sua própria prática de desenvolvimento de software program.
- A maior parte do uso é para depuração e ajuda a entender o código existente
- Aumento notável no uso dele para implementação de novos recursos
- Desenvolvedores usam-no em 59% de seu trabalho e obtêm aumento de produtividade de 50%
- 14% dos desenvolvedores são “usuários avançados” relatando ganhos muito maiores
- Claude ajuda os desenvolvedores a trabalhar fora de sua área principal
- Preocupações com mudanças na profissão, evolução na carreira e dinâmica social
❄ ❄ ❄ ❄ ❄
Grande parte da discussão sobre o uso de LLMs para desenvolvimento de software program carece de detalhes sobre o fluxo de trabalho. Em vez de apenas ouvir as pessoas falarem sobre como isso é maravilhoso, quero entender os detalhes. Que tipos de interações ocorrem com o LLM? Que decisões os humanos tomam? Ao revisar os resultados do LLM, que tipos de coisas os humanos procuram, que correções eles fazem?
Obie Fernández escreveu uma postagem que aborda esses tipos de detalhes. Durante o período de Natal/Ano Novo, ele usou Claude para construir um aplicativo de destilação de conhecimento, que pega transcrições de sessões do Claude Code, discussões ociosas, tópicos de relações públicas do github, and so on., transforma-os em um banco de dados gráfico RDF e fornece um aplicativo da net com maneiras de linguagem pure para consultá-los.
Não é uma prova de conceito. Não é uma demonstração. A primeira versão do Nexus, um sistema pronto para produção com autenticação, pesquisa semântica, um servidor MCP para acesso de agentes, integrações de webhook para nossas principais plataformas SaaS, cobertura de testes abrangente, implantado, integrado e pronto para adoção em larga escala na minha empresa na próxima segunda-feira. Quase 13.000 linhas de código.
O artigo é longo, mas vale a pena lê-lo.
Uma característica importante de seu fluxo de trabalho é contar com Desenvolvimento Orientado a Testes
Aqui está o que tornou isso sustentável em vez de caótico: TDD. Desenvolvimento orientado a testes. Para a maioria dos recursos, insisti que Claude Code seguisse o ciclo de refatoração vermelho-verde comigo. Escreva primeiro um teste com falha. Faça passar com a implementação mais simples. Em seguida, refatore enquanto mantém os testes verdes.
Isto não period apenas purismo metodológico. O TDD desempenhou uma função crítica no desenvolvimento assistido por IA: manteve-me informado. Ao direcionar milhares de linhas de geração de código, você precisa de uma função de forçamento que faça você realmente entender o que está sendo construído. Os testes são essa função de forçar. Você não pode escrever um teste significativo para algo que não entende. E você não pode verificar se um teste captura corretamente a intenção sem entendê-la por si mesmo.
A conta inclui uma grande refatoração e muita evolução da versão inicial da ferramenta. É também um vislumbre interessante de como as ferramentas de IA podem finalmente tornar o RDF útil.
❄ ❄ ❄ ❄ ❄
Ao pensar em requisitos de software program, a maioria das discussões concentra-se na priorização. Algumas pessoas falam sobre baldes como o Conjunto MoSCoW: Deve, Deveria, Poderia e Querer. (A velha piada é que, no MoSCoW, a vaca fica em silêncio, porque quase nenhuma exigência acaba nesses baldes.) Jason Frito tem um conjunto diferente de intervalos para design de interface: Óbvio, fácil e possível. Isto ressoa imediatamente em mim: uma boa maneira de pensar sobre como alocar os custos cognitivos para quem usa uma ferramenta.
❄ ❄ ❄ ❄ ❄
Casey Newton explica como ele acompanhou uma história interessante sobre padrões obscuros na entrega de alimentos e descobriu que period uma história falsa, apoiada pela criação de imagens e documentos de IA. Por um lado, esclarece o importante papel que os repórteres desempenham na exposição de mentiras que ganham força na Web. Mas o tempo necessário para fazer isso não é gasto na investigação de histórias reais
Durante a maior parte da minha carreira até este ponto, o documento partilhado comigo pelo denunciante teria parecido altamente credível, em grande parte porque teria levado muito tempo a ser elaborado. Quem perderia tempo elaborando um documento técnico detalhado de 18 páginas sobre a dinâmica do mercado apenas para enganar um repórter? Quem se daria ao trabalho de criar um crachá falso?
Hoje, porém, o relatório pode ser gerado em minutos e o selo em segundos. E embora nenhum bom repórter alguma vez publicasse uma história baseada num único documento e numa fonte desconhecida, muitos dedicariam algum tempo a investigar o conteúdo do documento e a ver se fontes humanas o apoiariam.
A web sempre foi cheia de lixo e sempre precisamos ter cuidado com o que lemos nela. A IA agora facilita a produção de evidências convincentes, e isso nunca é mais perigoso do que quando confirma crenças e medos fortemente arraigados.
❄ ❄ ❄ ❄ ❄
As descrições do desenvolvimento orientado a especificações que vi enfatizam a escrita de toda a especificação antes da implementação. Isso codifica a suposição (para mim bizarra) de que você não aprenderá nada durante a implementação que possa alterar a especificação. Já ouvi essa história tantas vezes contada de tantas maneiras por pessoas bem-intencionadas – se ao menos conseguíssemos acertar a especificação, o resto seria fácil.
Assim como ele, essa história tem sido a sirene constante de minha carreira em tecnologia. Mas o ciclo de aprendizagem de experimentação é essencial para a construção do modelo que está no centro de qualquer tipo de especificação que valha a pena. Como Unmesh coloca:
Grandes modelos de linguagem nos dão uma grande vantagem – mas só funcionam se nos concentrarmos no aprendizado e na compreensão. Eles tornam mais fácil explorar ideias, configurar coisas e traduzir intenções em código em muitas linguagens especializadas. Mas a verdadeira capacidade – a nossa capacidade de responder às mudanças – não provém da rapidez com que conseguimos produzir código, mas da profundidade com que compreendemos o sistema que estamos a moldar.
Quando Kent definiu Excessive Programming, ele fez opinião um dos seus quatro valores fundamentais. Parece-me que a chave para fazer pleno uso da IA no desenvolvimento de software program é como usá-la para acelerar os ciclos de suggestions.
❄ ❄ ❄ ❄ ❄
Ao ouvir pessoas que levam a sério a programação assistida por IA, o que ouço é o gerenciamento do contexto. As ferramentas voltadas para programação estão cada vez mais sofisticadas para isso, mas também há esforços para fornecer ferramentas mais simples, que permitam customização. Carlos Villela recomendou recentemente o Pi e seu desenvolvedor, Mario Zechner, tem um weblog interessante sobre o seu desenvolvimento.
Então, o que um velho gritando com Claudes vai fazer? Ele escreverá seu próprio equipamento de agente de codificação e dará a ele um nome totalmente impossível para o Google, para que nunca haja usuários. O que significa que também nunca haverá problemas no rastreador de problemas do GitHub. Quão difícil pode ser?
Se algum dia eu tiver tempo para sentar e realmente brincar com essas ferramentas, então algo como Pi seria algo que eu gostaria de experimentar. Apesar de ser um viciado no The One True Editor, estou interessado em algumas bibliotecas que trabalham com isso, como gptel. Isso me permitiria usar a programabilidade inerente do Emacs para criar meu próprio conjunto de comandos para conduzir a interação com LLMs.
❄ ❄ ❄ ❄ ❄
Fora do meu trabalho profissional, tenho postando regularmente sobre meus jogos de tabuleiro no website especializado BoardGameGeek. No entanto, seu ambiente de weblog não faz um bom trabalho ao fornecer um índice para minhas postagens, então criei uma lista das minhas postagens do BGG no meu próprio website. Se você estiver interessado em minhas postagens regulares sobre jogos de tabuleiro e estiver no BGG, pode se inscrever lá. Se você não está no BGG você pode se inscrever no weblog Feed RSS.
Eu também criei uma lista de meus jogos de tabuleiro favoritos.
