Escrevendo regras de cursor que fazem a IA se comportar em uma base de código antiga
Os assistentes de codificação de IA se comportam mal em projetos legados porque não conhecem suas restrições. Um pequeno arquivo de regras corrigiu metade das minhas diferenças ruins.
Minha primeira semana de desenvolvimento orientado a agentes em nossa base de código de quatro anos produziu um belo código que violava três convenções de equipe e uma decisão arquitetônica pela qual brigamos durante meses. A correção não foi melhor solicitada; estava escrevendo a constituição.
Um bom arquivo de regras é curto e negativo. A minha lista o que a base de código nunca deve fazer: nenhuma nova biblioteca de gerenciamento de estado, datas são dayjs e não Date, cada rota de API é validada com os esquemas zod existentes e nunca mexe em arquivos legados/sem perguntar. São as restrições, e não as aspirações, que mudam o comportamento do modelo.
A vitória inesperada foi documentar o porquê de cada regra em uma cláusula. O modelo que sabe que as migrações falharam no último trimestre escreve um código de migração mais cauteloso do que aquele que simplesmente diz para ter cuidado. O contexto converte as regras de obedecidas em compreendidas, e as regras compreendidas generalizam para casos que você não listou.
Mantenha um segundo arquivo de regras por diretório para convenções locais, minha pasta de componentes tem a sua própria e resista à tentação de inchar a pasta global. Cortei meu primeiro rascunho de quarenta para doze linhas e as diferenças melhoraram, porque cada linha que você adiciona dilui as que importam.
Seis semanas depois, o resultado mensurável: diferenças que violam convenções caíram de cerca de uma em cada três para raramente, e os comentários de revisão de código mudaram do estilo de volta para a lógica. O arquivo de regras é o engenheiro sênior mais barato que já contratei.