IA: revisar antes de copiar
O curso monta uma checklist de quatro perguntas para revisar sugestões de código de IA numa app Rails antes de aceitá-las. Cada pergunta ganha uma aula: se a sugestão faz o que foi pedido, se traz um problema de segurança, se duplica uma lógica existente e se segue as convenções deste código. Os exemplos incluem uma validação de unicidade sem escopo, uma action create corrigida com permit!, uma consulta direta de publicados e um controller com regra de negócio. Um exemplo prático aplica as quatro perguntas a um predicado de Article, lendo e seguindo dados à mão.
O que você vai aprender
- ✓Por que código de IA fluente e idiomático ainda pode impor a regra errada
- ✓Conferir uma sugestão contra as palavras exatas do pedido
- ✓Identificar riscos de mass assignment, como o permit! em correções de IA
- ✓Manter uma definição única da regra no model, como um scope published
- ✓Comparar sugestões com as regras de camadas e o padrão de service objects do projeto
- ✓Seguir à mão dados-limite, como um rascunho com published_at nil
Plausível mas errado: o problema da revisão de IA
Um assistente de IA sugere uma validação, uma consulta ou uma action de controller inteira, e cada linha parece algo que um desenvolvedor Rails competente escreveria: indentação arrumada, os nomes de método certos, os idiomas de sempre do Rails. Nada disso diz se o código está certo. A fluência de…
Ler a aula completa grátis →Currículo
7 aulasPlausível mas errado: o problema da revisão de IA
Mostra por que código de IA fluente e idiomático pode estar errado e apresenta as quatro perguntas de revisão.
Ela faz o que foi pedido?
Uma validação de unicidade sem escopo bloqueia títulos repetidos entre autores; o scope: :author_id aplica a regra pedida.
Checagem de segurança: mass assignment e sugestões de IA
Uma action create com params crus quebra, e a correção com permit! deixa passar toda chave, inclusive admin.
Checagem de lógica duplicada: fonte única de verdade
Uma consulta direta em published_at duplica o Article#published?; nomear a regra uma vez como scope mantém tudo alinhado.
Combinando com as convenções do seu codebase
Uma action publish com find cru e regra de negócio quebra as regras de camadas; um service object resolve.
Exemplo prático: uma checagem de Article sutilmente errada
Seguir um rascunho com published_at nil pelas quatro perguntas revela uma quebra e lógica duplicada no evergreen?.
Juntando tudo: a revisão de quatro perguntas
Retoma as quatro perguntas e mostra como o exemplo do evergreen? falhou em duas delas de uma vez.