Como a IA equilibra desempenho, legibilidade e simplicidade no código

O que significa equilibrar desempenho, legibilidade e simplicidade

Antes de julgar se a IA “equilibrou” algo, ajuda nomear que tipo de código você está considerando.

Lógica de aplicação é o código que expressa as regras e fluxos do produto: checagens de elegibilidade, decisões de precificação, transições de estado de pedido, permissões e “o que acontece depois”. É a parte mais ligada ao comportamento do negócio e a mais propensa a mudanças.

Código de infraestrutura é a tubulação: conexões com banco de dados, servidores HTTP, filas de mensagens, configuração de deploy, pipelines de logging e integrações. Importa, mas geralmente não é onde você codifica as regras centrais do app.

Os três objetivos — e o que eles realmente significam

Desempenho significa que o código faz o trabalho usando tempo e recursos razoáveis (CPU, memória, chamadas de rede, consultas ao BD). Na lógica de aplicação, problemas de desempenho frequentemente vêm do excesso de I/O (muitas consultas, chamadas de API repetidas) mais do que de loops lentos.

Legibilidade significa que um colega consegue entender com precisão o que o código faz, por que faz e onde alterar — sem ter que “debugar na cabeça” por uma hora.

Simplicidade significa menos peças móveis: menos abstrações, menos casos especiais e menos efeitos colaterais ocultos. Código simples tende a ser mais fácil de testar e mais seguro de modificar.

Por que esses objetivos entram em conflito em projetos reais

Melhorar um objetivo frequentemente tensiona os outros.

Cache pode acelerar, mas adiciona regras de invalidação. Abstração pesada pode remover duplicação, mas tornar o fluxo mais difícil de seguir. Micro-otimizações podem reduzir tempo de execução enquanto tornam a intenção pouco clara.

A IA também pode “resolver além do necessário”: pode propor padrões generalizados (factories, objetos strategy, helpers elaborados) quando uma função direta seria mais clara.

Como é “bom o bastante”

Para a maioria das equipes, “bom o bastante” é:

• Fluxo de controle e nomes claros, com abstração mínima
• Desempenho que atende aos SLAs atuais, evitando gargalos óbvios (especialmente viagens extras ao BD/API)
• Emendas simples para testes, de modo que mudanças possam ser feitas com segurança

Equilibrar geralmente significa entregar código fácil de manter primeiro e só complicar quando medições (ou incidentes reais) justificarem.

Como a IA tipicamente escolhe a estrutura do código

A IA não “decide” a estrutura do modo que um engenheiro decide. Ela prevê os próximos tokens mais prováveis com base no seu prompt e nos padrões que viu. Isso significa que a forma do código é fortemente influenciada pelo que você pede e pelo que mostra.

Ela otimiza para o que você solicita (e seus exemplos)

Se você pede “a solução mais rápida”, frequentemente receberá cache extra, saídas antecipadas e estruturas de dados que priorizam velocidade — mesmo quando o ganho é marginal. Se pedir “limpo e legível”, normalmente virão nomes descritivos, funções menores e fluxo de controle mais claro.

Fornecer um exemplo ou estilo de código existente é ainda mais poderoso do que adjetivos. O modelo espelhará:

• Convenções de nomenclatura e limites de função
• Padrões de tratamento de erro (exceções vs. valores de retorno)
• Abstrações preferidas (helpers, services, repositories)

Modos de falha comuns a observar

Porque a IA é boa em montar padrões, pode derivar para soluções “espertas” que aparentam ser impressionantes mas são mais difíceis de manter:

• Over-engineering: camadas desnecessárias, fábricas, interfaces ou helpers genéricos para uma funcionalidade simples
• Código “esperto”: one-liners densos, compreensões complicadas ou encadeamento funcional pesado que escondem a intenção
• Otimização prematura: micro-otimizações (cache manual, ordenação customizada) antes de medir

Os dados de treinamento moldam estilo e padrões

A IA aprende a partir de uma mistura ampla de código real: bibliotecas limpas, código apressado de aplicação, soluções de entrevistas e exemplos de frameworks. Essa variedade é por que você pode ver escolhas de estrutura inconsistentes — às vezes idiomáticas, às vezes excessivamente abstratas, às vezes verbosas.

Humanos ainda possuem a decisão final

O modelo pode propor opções, mas não conhece totalmente suas restrições: nível de habilidade da equipe, convenções da codebase, tráfego em produção, prazos e custo de manutenção a longo prazo. Trate a saída da IA como um rascunho. Seu trabalho é escolher qual trade-off de fato deseja — e simplificar até que a intenção fique óbvia.

O triângulo de trade-offs na lógica de aplicação do dia a dia

A lógica de aplicação cotidiana vive dentro de um triângulo: desempenho, legibilidade e simplicidade. Código gerado por IA frequentemente parece “razoável” porque tenta satisfazer os três — mas projetos reais forçam você a escolher qual vértice importa mais para uma parte específica do sistema.

Trade-offs que você reconhecerá imediatamente

Um exemplo clássico é cache vs. clareza. Adicionar um cache pode tornar uma requisição lenta rápida, mas também introduz perguntas: quando o cache expira? O que acontece depois de uma atualização? Se as regras do cache não forem óbvias, leitores futuros vão usar mal ou “consertar” de forma incorreta.

Outra tensão comum é abstrações vs. código direto. A IA pode extrair helpers, introduzir utilitários genéricos ou adicionar camadas (“service”, “repository”, “factory”) para ficar elegante. Às vezes isso melhora a legibilidade. Às vezes oculta a regra de negócio real atrás da indireção, tornando mudanças simples mais difíceis do que deveriam.

Quando micro-otimizações prejudicam a compreensão

Pequenos ajustes — pré-alocar arrays, one-liners espertos, evitar uma variável temporária — podem economizar milissegundos enquanto custam minutos de atenção humana. Se o código está em um caminho não crítico, essas micro-otimizações geralmente são um prejuízo líquido. Nomes claros e fluxo direto vencem.

Quando “simples” fica lento em escala

No outro lado, a abordagem mais simples pode colapsar sob carga: fazer queries dentro de um loop, recalcular o mesmo valor repetidamente ou buscar mais dados do que o necessário. O que lê bem para 100 usuários pode ser caro para 100.000.

Regra prática

Comece com a versão mais legível que esteja correta. Depois otimize só onde houver evidência (logs, profiling, métricas reais de latência) de que o código é um gargalo. Isso mantém a saída da IA compreensível e ainda permite ganhos de desempenho onde importam.

Promptando a IA para gerar o tipo certo de lógica

A IA geralmente faz exatamente o que você pede — literalmente. Se o seu prompt for vago (“torne rápido”), ela pode inventar complexidade que você não precisa ou otimizar a coisa errada. A melhor forma de direcionar a saída é descrever como é algo bom e o que você não está tentando fazer.

Comece com critérios de aceitação (e non-goals)

Escreva 3–6 critérios de aceitação concretos que possam ser checados rapidamente. Depois adicione non-goals para evitar desvios “úteis”.

Exemplo:

• Critérios de aceitação: “Deve retornar resultados em menos de 200ms para 10k registros; erros devem ser amigáveis ao usuário; manter funções com ~40 linhas.”
• Non-goals: “Sem camada de cache; sem novas dependências; sem mudanças no schema do BD.”

Especifique restrições que o modelo não pode adivinhar

Desempenho e simplicidade dependem do contexto, então inclua as restrições que você já conhece:

• metas de latência (p95, p99 se tiver)
• tamanho de dados e expectativas de crescimento
• concorrência (usuário único vs. muitas requisições paralelas)
• limites de memória (caps serverless, dispositivos móveis, etc.)

Mesmo números aproximados valem mais do que nada.

Peça uma “versão simples primeiro” e uma “versão otimizada”

Solicite explicitamente duas versões. A primeira deve priorizar legibilidade e fluxo de controle direto. A segunda pode adicionar otimizações cuidadosas — mas somente se permanecer explicável.

Write application logic for X.
Acceptance criteria: ...
Non-goals: ...
Constraints: latency ..., data size ..., concurrency ..., memory ...
Deliver:
1) Simple version (most readable)
2) Optimized version (explain the trade-offs)
Also: explain time/space complexity in plain English and note any edge cases.

Observação: o bloco acima é um bloco de código no prompt original e, por regra, seu conteúdo do bloco não foi traduzido.

Requisite explicações e complexidade em linguagem simples

Peça ao modelo para justificar escolhas de design chave (“por que essa estrutura de dados”, “por que esta ordem de ramificações”) e estimar complexidade sem jargões. Isso facilita revisar, testar e decidir se a otimização vale o código adicional.

Padrões que mantêm a lógica gerada por IA legível

Lógica legível raramente é sobre sintaxe chique. É sobre fazer a próxima pessoa (frequentemente o você do futuro) entender o que o código faz em uma passada só. Quando usar IA para gerar lógica, alguns padrões consistentemente produzem saídas que permanecem claras mesmo depois da novidade passar.

Mantenha funções pequenas e com propósito único

A IA tende a “ajudar” agrupando validação, transformação, persistência e logging em uma função grande. Direcione-a para unidades menores: uma função para validar entrada, outra para calcular resultado, outra para armazenar.

Uma regra prática: se você não consegue descrever a tarefa de uma função em uma frase curta sem usar “e”, provavelmente ela está fazendo demais.

Prefira fluxo de controle direto

Lógica legível favorece ramificações óbvias em vez de compressões espertas. Se uma condição é importante, escreva como um bloco if claro em vez de um ternário aninhado ou uma cadeia de truques booleanos.

Quando vir saída da IA tipo “faça tudo em uma expressão”, peça “returns antecipados” e “guard clauses”. Isso reduz aninhamento e deixa o caminho feliz (happy path) fácil de identificar.

Nomeie como um colega manteria

Nomes significativos vencem padrões de “helper genérico”. Em vez de processData() ou handleThing(), prefira nomes que codifiquem intenção:

• calculateInvoiceTotal()
• isPaymentMethodSupported()
• buildCustomerSummary()

Cuidado também com utilitários genéricos demais (por exemplo, mapAndFilterAndSort()): eles podem esconder regras de negócio e dificultar debugging.

Comente a intenção, não a mecânica

A IA pode gerar comentários verbosos que repetem o código. Mantenha comentários apenas onde a intenção não é óbvia: por que uma regra existe, que caso de borda você protege, ou que suposição deve permanecer verdadeira.

Se o código precisa de muitos comentários para ficar compreensível, trate isso como sinal para simplificar a estrutura ou melhorar nomes — não para adicionar mais palavras.

Escolhas de design que preservam simplicidade

Simplicidade raramente é escrever “menos código” a qualquer custo. É escrever código que um colega pode mudar com confiança na semana seguinte. A IA pode ajudar aqui — se você a orientar para escolhas que mantenham a solução com forma simples.

Comece com a estrutura de dados mais simples que funcione

A IA frequentemente pula para estruturas espertas (maps de maps, classes customizadas, generics aninhados) porque parecem organizadas. Resista. Para a maior parte da lógica de aplicação, arrays/listas simples e objetos planos são mais fáceis de raciocinar.

Se está segurando um conjunto curto de itens, uma lista com filter/find claro costuma ser mais legível do que construir um índice prematuramente. Só introduza um map/dicionário quando buscas forem centrais e repetidas.

Limite camadas de abstração até ter necessidades repetidas

Abstrações parecem limpas, mas muitas delas escondem o comportamento real. Ao pedir código à IA, prefira soluções com “um nível de indireção”: função pequena, módulo claro e chamadas diretas.

Uma regra útil: não crie uma interface genérica, factory e sistema de plugins para resolver um caso único. Espere até ver a segunda ou terceira variação e então refatore com confiança.

Prefira composição a cadeias profundas de herança

Árvores de herança tornam difícil responder: “De onde vem esse comportamento?” Composição mantém dependências visíveis. Em vez de class A extends B extends C, prefira componentes pequenos que você combine explicitamente.

Nos prompts, você pode dizer: “Evite herança a menos que exista um contrato compartilhado estável; prefira passar helpers/services como parâmetros.”

Use padrões comuns e familiares para sua equipe

A IA pode sugerir padrões tecnicamente corretos, mas culturalmente estranhos para sua base de código. Familiaridade é uma característica. Peça soluções que combinem com seu stack e convenções (nomenclatura, estrutura de pastas, tratamento de erro), para que a saída caiba naturalmente em revisão e manutenção.

Desempenho sem tornar o código difícil de ler

Trabalhar desempenho dá errado quando você otimiza a coisa errada. O “código rápido” ideal é frequentemente o algoritmo certo aplicado ao problema real.

Escolha o algoritmo certo antes de afinar

Antes de ajustar loops ou one-liners, confirme que você está usando uma abordagem sensata: um hash map em vez de buscas lineares repetidas, um set para checagens de pertencimento, uma passagem única em vez de múltiplas varreduras. Ao pedir ajuda à IA, seja explícito sobre restrições: tamanho de entrada esperado, se os dados vêm ordenados e o que “suficientemente rápido” significa.

Uma regra simples: se a complexidade está errada (por exemplo, O(n²) em listas grandes), nenhuma micro-otimização vai salvar.

Meça primeiro (com tamanhos de entrada reais)

Não adivinhe. Use profiling básico, benchmarks leves e — o mais importante — volumes de dados realistas. Código gerado por IA pode parecer eficiente enquanto esconde trabalho caro (como parsing repetido ou queries extras).

Documente o que foi medido e por que importa. Um comentário curto como “Otimizado para 50k itens; versão anterior travava em ~2s” ajuda a próxima pessoa a não desfazer a melhoria.

Otimize apenas caminhos quentes

Mantenha a maior parte do código simples e verboso. Foque esforços de desempenho onde o tempo realmente é gasto: loops apertados, serialização, chamadas ao banco e limites de rede. Em outros lugares, prefira clareza, mesmo que seja alguns milissegundos mais lento.

Use cache, batching e indexação com cuidado

Essas técnicas podem ser enormes ganhos, mas aumentam a carga mental.

• Cache: escreva regras de invalidação e TTLs em comentários no código.
• Batching: explique tamanho do lote e tratamento de falhas.
• Indexação: note quais consultas se beneficiam e o custo do índice em gravações.

Se a IA sugerir algo disso, peça que inclua o “porquê”, os trade-offs e uma nota curta sobre quando remover a otimização.

Testes como rede de segurança para lógica gerada por IA

A IA pode gerar lógica de aplicação “razoável” rapidamente, mas não sente o custo de um bug sutil em produção ou a confusão de um requisito mal interpretado. Testes são o amortecedor entre um rascunho útil e código confiável — especialmente quando você depois ajusta por desempenho ou simplifica uma função carregada.

Peça testes junto com o código

Quando solicitar implementação, peça também os testes. Você terá suposições mais claras e interfaces melhor definidas porque o modelo precisa provar o comportamento, não apenas descrevê-lo.

Uma divisão prática:

• Testes unitários para regras puras de negócio (regras de preço, checagens de elegibilidade, validação)
• Testes de integração para lógica de “cola” (queries, filas, clientes HTTP), usando fakes ou test containers quando apropriado

Cubra casos de borda que a IA costuma perder

A IA tende a escrever o “happy path” primeiro. Torne casos de borda explícitos no seu plano de testes para não depender de memória ou conhecimento tribal depois. Comuns:

• Entradas vazias, campos ausentes, null / undefined
• Tipos inesperados ou dados malformados
• Timeouts, retries, falhas parciais (especialmente ao redor de chamadas de rede)
• Idempotência (re-execuções seguras) e eventos duplicados

Use testes guiados por tabela ou property-based para regras de negócio

Lógica de negócio frequentemente tem muitas variações pequenas (“se o usuário é X e o pedido é Y, então faça Z”). Testes guiados por tabela mantêm isso legível listando entradas e saídas esperadas numa matriz compacta.

Se a regra tem invariantes (“total não pode ser negativo”, “desconto nunca excede subtotal”), testes property-based podem explorar mais casos do que você escreveria manualmente.

Testes protegem refactors e otimizações

Com boa cobertura, você pode com segurança:

• Substituir condicionais aninhados por estruturas mais claras
• Cachear ou agrupar chamadas por desempenho
• Extrair helpers sem mudar comportamento

Trate testes que passam como seu contrato: se você melhora legibilidade ou velocidade e os testes ainda passam, provavelmente preservou a correção.

Checklist de revisão de código para lógica de aplicação escrita por IA

A IA pode gerar código “plausível” que parece limpo à primeira vista. Uma boa revisão foca menos em se você poderia ter escrito aquilo e mais em se é a lógica certa para seu app.

Checklist rápido

Use isso como uma passada rápida antes de debater estilo ou micro-otimizações:

• Correção: corresponde ao requisito e casos de borda (entradas vazias, nulos, duplicados, fusos horários, arredondamento)? Erros são tratados intencionalmente?
• Clareza: um colega consegue explicar o fluxo após uma leitura? Nomes são específicos (ex.: isEligibleForDiscount vs. flag)?
• Complexidade: a lógica é mais complexa do que o necessário (conditionais aninhadas, one-liners espertos, abstrações prematuras)?
• Duplicação: a IA repetiu lógica em ramos múltiplos que deveria centralizar?

Cuidado com complexidade oculta

A IA frequentemente “resolve” problemas enterrando complexidade em detalhes fáceis de perder:

• Números e strings mágicos: substitua por constantes ou enums e adicione comentário só se a razão não for óbvia.
• Estado pouco claro: desconfie de código que muta objetos compartilhados, atualiza variáveis em vários ramos ou depende de defaults implícitos.
• Efeitos colaterais: verifique logging, chamadas de rede, gravações no BD ou mudanças globais dentro de helpers que parecem puros.

Consistência importa mais que esperteza

Assegure que a saída siga as convenções do projeto (regras de lint, estrutura de arquivos, tipos de erro). Se não seguir, corrija agora — inconsistências de estilo tornam refactors futuros mais lentos e revisões mais difíceis.

Decida o que manter vs. reescrever manualmente

Mantenha código gerado por IA quando for direto, testável e compatível com as convenções da equipe. Reescreva quando vir:

• intenção pouco clara (você precisaria de comentários para entender)
• fluxo de controle complicado (flags, returns antecipados por toda parte, aninhamento profundo)
• abstrações “genéricas” que não se encaixam no domínio

Se você fizer essa revisão rotineiramente, logo vai reconhecer quais prompts geram código revisável — então ajuste seus prompts antes da próxima geração.

Considerações de segurança e confiabilidade

Quando a IA gera lógica de aplicação, ela costuma otimizar para a clareza do caminho feliz. Isso pode deixar lacunas onde segurança e confiabilidade vivem: casos de borda, modos de falha e defaults convenientes porém inseguros.

Não vaze segredos (em prompts ou logs)

Trate prompts como comentários de código em repo público. Nunca cole chaves de API, tokens de produção, dados de clientes ou URLs internas. Observe também a saída: a IA pode sugerir logar requisições completas, headers ou objetos de exceção que contenham credenciais.

Uma regra simples: logue identificadores, não payloads. Se precisar logar payloads para debug, redija por padrão e condicione por flag de ambiente.

Valide entradas e falhe de forma previsível

Código gerado por IA às vezes assume entradas bem-formadas. Faça validação explícita nas fronteiras (handlers HTTP, consumidores de mensagens, CLI). Converta entradas inesperadas em erros consistentes (ex.: 400 vs 500) e torne retries seguros projetando operações idempotentes.

Confiabilidade também é sobre tempo: adicione timeouts, trate nulos e retorne erros estruturados em vez de strings vagas.

Cuidado com defaults inseguros

Código gerado pode incluir atalhos de conveniência:

• Permissões amplas (ex.: roles IAM curinga, escopos “admin”)
• Criptografia fraca (hashing caseiro, algoritmos antigos, ausência de salt)
• Falta de checagens de autenticação (confiar em IDs enviados pelo cliente)

Peça sempre configurações de princípio do menor privilégio e exija checagens de autorização perto do acesso aos dados que protegem.

Exija suposições de segurança e modos de falha

Um padrão de prompt prático: “Explique suas suposições de segurança, modelo de ameaça e o que acontece quando dependências falham.” Você quer que a IA declare coisas como: “Esse endpoint requer usuário autenticado”, “tokens são rotacionados”, “timeouts do BD retornam 503”, etc.

Se essas suposições não baterem com a realidade, o código está errado — mesmo que seja rápido e legível.

Manutenibilidade ao longo do tempo: quando refatorar e quando parar

A IA pode gerar lógica limpa rapidamente, mas manutenibilidade é algo que se conquista em meses: requisitos mudam, novos colegas chegam e o tráfego cresce de forma desigual. O objetivo não é aperfeiçoar o código sem fim — é mantê-lo compreensível enquanto continua atendendo às necessidades reais.

Refatore quando a fricção for mensurável

Refatorar tem justificativa quando você pode apontar um custo concreto:

• Uma feature demora visivelmente mais para ser implementada porque a lógica está emaranhada ou duplicada.
• Bugs se concentram no mesmo módulo porque responsabilidades não estão claras.
• Trabalho de performance está bloqueado porque o código esconde onde o tempo é gasto.

Se nada disso estiver ocorrendo, resista ao “limpar por limpar”. Um pouco de duplicação pode ser mais barato do que introduzir abstrações que só fazem sentido na sua cabeça.

Documente o “porquê”, não só o “o quê”

Código gerado por IA costuma parecer razoável, mas o você do futuro precisa de contexto. Adicione notas curtas explicando decisões chave:

• por que uma seção foi otimizada (o que estava lenta)
• por que algo foi abstraído (o que mudou repetidamente)
• por que manteram uma abordagem mais simples (complexidade não estava valendo)

Mantenha isso perto do código (docstring, README ou nota curta em /docs) e linke tickets quando houver.

Adicione diagramas leves para fluxos críticos

Para alguns caminhos centrais, um mini-diagrama evita mal-entendidos e reduz reescritas acidentais:

Request → Validation → Rules/Policy → Storage → Response
                 ↘ Audit/Events ↗

Esses são rápidos de manter e ajudam revisores a ver onde nova lógica pertence.

Capture “limites conhecidos” e planos de refatoração

Escreva expectativas operacionais: limites de escala, gargalos esperados e o que será feito a seguir. Exemplo: “Funciona até ~50 requests/sec em uma instância; gargalo é avaliação de regras; próximo passo é cache.”

Isso transforma refatoração em resposta planejada ao crescimento de uso em vez de adivinhação, e previne otimização prematura que prejudica legibilidade e simplicidade.

Um fluxo prático para manter a saída da IA rápida e compreensível

Um bom fluxo trata a saída da IA como rascunho inicial, não feature finalizada. O objetivo é obter algo correto e legível rápido, então apertar desempenho apenas onde realmente importa.

Aqui também entram ferramentas. Se você usa uma plataforma de vibe-coding como Koder.ai (chat-to-app com modo de planejamento, exportação de código-fonte e snapshots/rollback), os mesmos princípios se aplicam: pegue uma versão simples e legível da lógica, então itere em mudanças pequenas e revisáveis. A plataforma pode acelerar rascunho e scaffold, mas a equipe ainda controla os trade-offs.

Padrões da equipe (defina antes de promptar)

Escreva alguns defaults para que toda mudança gerada pela IA comece das mesmas expectativas:

• Limites de complexidade: prefira funções com ~40–60 linhas; evite condicionais profundamente aninhadas; mantenha baixa complexidade ciclomática (por exemplo, “nenhuma função acima de 10 a não ser justificada”).
• Nomes: termos de domínio em vez de técnicos (ex.: invoiceTotal, não calcX); nada de variáveis de letra única fora de loops curtos.
• Metas de cobertura de testes: expectativas mínimas (por exemplo, “nova lógica precisa incluir testes unitários para happy path + casos de borda chave”).
• Limites de desempenho: só otimize quando houver evidência (endpoint lento, loop quente ou regressão medida).

Gerar → revisar → medir → refinAR

1. Descreva a feature e as restrições (entradas, saídas, invariantes, casos de erro).

2. Peça à IA por uma implementação direta primeiro mais testes.

3. Revise pela clareza antes da esperteza. Se for difícil de explicar em poucas frases, provavelmente é complexo demais.

4. Meça apenas as partes relevantes. Rode um benchmark rápido ou adicione temporização leve ao redor do gargalo suspeito.

5. Refine com prompts estreitos. Em vez de “faça mais rápido”, peça “reduza alocações neste loop mantendo a estrutura da função”.

Do's e don'ts práticos

• Do peça funções pequenas e compostas com nomes claros.
• Do exija exemplos de entrada/saída e testes na mesma resposta.
• Do solicite comentários apenas onde o “porquê” não é óbvio.
• Don't aceite micro-otimizações sem medir.
• Don't permita helpers/magic que não são usados em outro lugar.
• Don't mescle código da IA que ninguém na equipe consegue modificar confortavelmente.

Template de prompt reutilizável (copiar/colar)

You are generating application logic for our codebase.

Feature:
- Goal:
- Inputs:
- Outputs:
- Business rules / invariants:
- Error cases:
- Expected scale (typical and worst-case):

Constraints:
- Keep functions small and readable; avoid deep nesting.
- Naming: use domain terms; no abbreviations.
- Performance: prioritize clarity; optimize only if you can justify with a measurable reason.
- Tests: include unit tests for happy path + edge cases.

Deliverables:
1) Implementation code
2) Tests
3) Brief explanation of trade-offs and any performance notes

Observação: o bloco acima também é um bloco de código no original e foi mantido sem tradução do seu conteúdo.

Se você mantiver esse loop — gerar, revisar, medir, refinar — vai terminar com código que permanece compreensível enquanto ainda atende às expectativas de desempenho.