AI coding: exploração/refactor/debug
O laboratório combina um pedido claro ao assistente com uma reprodução mínima. Você usará casos de fronteira para testar uma hipótese e revisará o diff como parte da entrega. A ferramenta de coding escolhida deve receber somente as capacidades necessárias ao exercício.
Trabalhe em um arquivo de prática ou em uma cópia isolada do módulo. Se usar um repositório real, confira alterações existentes antes de editar. O código local ensina a regra; integração com checkout depende dos contratos e verificações daquele projeto.
JavaScriptIA & MLProgramaçãoAo terminar esta aula
- Explore o fluxo por perguntas concretas.
- Debugging precisa de hipótese refutável.
- Código gerado é uma proposta que exige evidência.
Antes de continuar: Leitura: AI coding: exploração/refactor/debug
Preparar o pedido e o mapa
FundamentosEscreva uma tarefa concreta: o frete deve ser gratuito no limite de 100 e os descontos continuam sendo aplicados na ordem atual. Peça ao assistente primeiro os arquivos e testes relevantes, depois a hipótese sobre a comparação. Essa separação evita editar o primeiro resultado da busca. Registre a entrada que falha e a saída observada. Leia as instruções persistentes do repositório e confirme o comando de verificação disponível. Se o módulo usa valores em centavos, transforme os casos do exercício para a unidade correta antes de executar. O requisito de negócio é o mesmo, mas a representação numérica pode mudar.
Implementar a reprodução
FundamentosCrie o teste mínimo com 99.99, 100 e 100.01, adaptando moeda e arredondamento ao projeto. Antes da correção, confirme qual caso falha; isso estabelece que o teste observa a discrepância. Inspecione a função que recebe subtotal e a origem desse subtotal. Se o desconto foi aplicado duas vezes, mudar a comparação não resolve a causa. Quando a hipótese for confirmada, aplique a alteração menor e execute os mesmos casos. Preserve a saída do comando ou o resultado do runner para que a conclusão seja verificável por outra pessoa. Não confunda leitura do código com execução do teste.
Exercitar limites e revisar diff
FundamentosAcrescente subtotal zero, valor negativo e entrada inválida conforme o contrato existente. Esses casos verificam que a correção não criou uma nova fronteira silenciosa. Abra o diff e confira se só o módulo e os testes necessários mudaram. Procure formatação global, dependência adicional e alteração de textos sem relação com o pedido. Se o assistente refatorou um caminho maior, peça justificativa ligada à tarefa e verifique contratos afetados. Um diff pequeno é mais fácil de revisar, mas tamanho por si só não garante correção: a condição errada pode estar em uma única linha.
Documentar resultado e integração
FundamentosEscreva um registro curto com requisito, hipótese, alteração e evidência. Identifique quais verificações foram executadas e quais dependem de ambiente externo. Um caso E2E pode confirmar que o total exibido usa a função corrigida, enquanto o teste unitário confirma a fronteira numérica. Se o E2E não foi executado, mantenha essa limitação explícita. Ao avaliar a assistência, descreva onde ela encontrou contexto útil e onde precisou de correção humana. O artefato final deve permitir que um colega reproduza o caso sem reler toda a conversa com o agente.
Caso adicional para diagnóstico e decisão
FundamentosAgora considere que o checkout representa valores em centavos e recebe subtotal 10000. Uma correção que compara esse número com 100 concederia frete gratuito a partir de um real. Antes de executar, escreva qual camada converte unidade e quais testes detectam esse erro. Crie um caso de desconto que reduz subtotal de 105 reais para 95 e defina se a política considera valor antes ou depois do desconto. Não deduza a regra do nome da variável. Procure requisito ou decisão autorizada. A rubrica adicional exige unidade correta, fronteira inclusiva e ordem de operações preservada. Compare duas propostas de refatoração: converter em cada chamada ou normalizar uma vez na fronteira. A segunda pode reduzir ambiguidades, mas só é adequada se o contrato do projeto a sustenta. O relatório deve mostrar a razão da escolha e os casos que a distinguem, evitando um código elegante que implementa outra política.
Execução, inspeção e diagnóstico
FundamentosExecute o programa, depois substitua >= por > para confirmar que o caso no limite detecta a regressão. Restaure a correção e rode novamente. A mutação deliberada demonstra que os casos realmente verificam a regra pretendida, em vez de apenas exercer linhas de código sem critério.
function frete(subtotal) {
if (!Number.isFinite(subtotal) || subtotal < 0) throw new Error("Subtotal inválido");
return subtotal >= 100 ? 0 : 12;
}
for (const [entrada, esperado] of [[99.99,12],[100,0],[100.01,0]]) {
const obtido = frete(entrada);
if (obtido !== esperado) throw new Error("Falhou em "+entrada);
console.log({entrada,esperado,obtido});
}Se todos os testes passam com >, o conjunto não cobre o requisito. Se o teste local passa e a interface cobra frete, investigue unidade, subtotal e caminho de integração. Não conclua que o modelo falhou só porque uma camada diferente continua usando uma regra antiga.
Exercício aplicado
Entregue uma correção assistida com reprodução, diff revisado e registro de evidência.
- Localize módulo, chamadas e testes.
- Demonstre falha no limite antes da mudança.
- Aplique condição inclusiva e verifique fronteiras.
- Revise diff e documente escopo de integração.
Abrir resolução comentada
A resolução começa demonstrando a falha do limite, depois troca a condição para >= e mantém os casos abaixo e acima. Verifica também subtotal inválido. O relatório cita o módulo alterado e explica por que a mudança não altera a ordem de aplicação de desconto.
Uma refatoração pode extrair a política para configuração, mas isso é uma decisão separada. A tarefa atual não exige nova biblioteca nem reorganização global. O critério final é que a regra inclusiva apareça no comportamento e que as verificações existentes pertinentes continuem passando.
Uma entrega satisfatória inclui a saída do caso que falhava e sua aprovação após a mudança, com o requisito que justifica >=. A alteração deve preservar a representação de moeda e a ordem de desconto do projeto.
A resolução reproduz a discrepância com a função antiga, verifica a condição inclusiva e inclui inválidos, subtotal zero e desconto. A unidade monetária é centavos e a política fictícia considera o subtotal depois do desconto. O mapa e o diff correspondem ao arquivo de prática, sem fingir inspeção de um checkout externo. No repositório real, o estudante confirma unidade, política e fluxo antes de aplicar a alteração e registra as verificações de integração realmente executadas.
import assert from "node:assert/strict";
// Política fictícia: subtotal após desconto, centavos internos, limite inclusivo de R$100.
function antigo(centavos){return centavos>10000?0:1200;}
function frete(centavos){
if(!Number.isSafeInteger(centavos)||centavos<0)throw new Error("SUBTOTAL_INVALIDO");
return centavos>=10000?0:1200;
}
const casos=[[9999,1200],[10000,0],[10001,0],[0,1200]];
assert.notEqual(antigo(10000),0); // Reprodução antes da correção.
for(const [entrada,esperado] of casos)assert.equal(frete(entrada),esperado);
assert.throws(()=>frete(-1),/SUBTOTAL_INVALIDO/);
assert.throws(()=>frete(99.99),/SUBTOTAL_INVALIDO/);
const subtotal=10500,desconto=1000;
assert.equal(frete(subtotal-desconto),1200);
const mapa={modulo:"função frete deste arquivo",chamadas:"loop de casos e caso com desconto",
testes:"asserts explícitos",contrato:"centavos depois do desconto"};
const diff={antes:"centavos > 10000",depois:"centavos >= 10000",
representacao:"normalização em centavos preservada",alteracoesForaDaTarefa:[]};
assert.equal(diff.alteracoesForaDaTarefa.length,0);
console.log({status:"aprovado",mapa,diff,casos:casos.length,
integracaoCheckout:"não executada; localizar o fluxo real antes de aplicar a política fictícia"});Como conferir seu resultado
- O teste distingue > de >=.
- Alterações fora da tarefa foram revisadas.
- Não há afirmação de verificação que não ocorreu.
Aplique em um problema novo
Primeiro resolva sem consultar a resposta. Explique suas decisões e guarde a evidência. A conclusão de leitura é independente desta autoavaliação.
Confira seus pré-requisitos
- Encontrar regra/chamadores/testes.
- Preservar unidade monetária.
Fixture desconta 10 a partir de 200. Teste três fronteiras e subtotal negativo; UI não foi executada.
Conferir raciocínio e critérios de domínio
199,99 permanece;200→190;200,01→190,01 na unidade declarada.
Negativo é erro; usar centavos inteiros quando o contrato exigir.
Teste local não prova UI; registrar E2E pendente e diff revisado.
Evidências para autoavaliação ou revisão por pares
- Valores de fronteira: 199,99 permanece;200→190;200,01→190,01 na unidade declarada.
- Validação e unidade: Negativo é erro; usar centavos inteiros quando o contrato exigir.
- Evidência da UI: Teste local não prova UI; registrar E2E pendente e diff revisado.
Um erro frequente
Corrigir um operador exige refatoração global.
Alterações devem respeitar o escopo autorizado e dependências.
Teste sua compreensão
Responda com suas palavras antes de abrir o comentário. Saber explicar uma decisão é parte do domínio.
1. Um checkpoint é necessariamente um commit Git?
Não.
Mecanismos de recuperação do editor e histórico Git têm contratos diferentes.
2. Uma explicação convincente comprova o bug?
3. Refatoração pode alterar regra de frete silenciosamente?
Seu progresso fica salvo neste navegador. Concluir a leitura não substitui demonstrar o domínio nos exercícios.
Referências e aprofundamento
Documentação oficial e trabalhos originais. As referências registram o escopo e as limitações para você conferir o que sustentam.
- Common workflows
Anthropic • consulta: 2026-10-06
AutomaçãoExploração de codebase, debugging, refatoração, testes, review e análise assistida.
Limites: Resultados do agente devem ser verificados com testes, análise estática e review humano apropriado.
- GitHub Copilot on GitHub.com
GitHub • consulta: 2026-10-06
FundamentosSuperfície Copilot, agente de coding e fluxo de review no GitHub.
Limites: Disponibilidade e limites dependem de plano e organização; verificar antes do laboratório.
- Cursor Agent overview
Cursor • consulta: 2026-10-06
AgentesExploração, edição, terminal, ferramentas de agente e checkpoints.
Limites: Checkpoints locais do Cursor não são commits Git; recursos mudam por versão/plano.
- OpenCode Agents
OpenCode • consulta: 2026-10-06
AgentesAgentes primários, subagentes, configuração, tools e permissões.
Limites: Documentação dinâmica; fixar a versão usada no laboratório e conferir compatibilidade antes de executar.
- Custom instructions with AGENTS.md
OpenAI • consulta: 2026-10-06
OpenAIAgentesInstruções globais e de projeto, descoberta, AGENTS.override.md e precedência por diretório.
Limites: Precedência documentada para Codex; instruções são orientação, não garantia de cumprimento ou controle de acesso.