{"id":50988033,"url":"https://github.com/jprando/testa-habilidade-ai-typescript","last_synced_at":"2026-06-19T22:01:33.881Z","repository":{"id":353879709,"uuid":"1221265828","full_name":"jprando/testa-habilidade-ai-typescript","owner":"jprando","description":"O teste de fogo para IAs geradoras de código: avaliando modelos (LLMs) contra armadilhas de concorrência e Event Loop.","archived":false,"fork":false,"pushed_at":"2026-05-08T14:20:35.000Z","size":556,"stargazers_count":0,"open_issues_count":0,"forks_count":0,"subscribers_count":0,"default_branch":"main","last_synced_at":"2026-05-08T16:33:22.883Z","etag":null,"topics":["ai-testing","async","concurrency","javascript","llm-benchmark","promise","qwen","typescript","v8-engine"],"latest_commit_sha":null,"homepage":"","language":"TypeScript","has_issues":true,"has_wiki":null,"has_pages":null,"mirror_url":null,"source_name":null,"license":null,"status":null,"scm":"git","pull_requests_enabled":true,"icon_url":"https://github.com/jprando.png","metadata":{"files":{"readme":"README.md","changelog":null,"contributing":null,"funding":null,"license":null,"code_of_conduct":null,"threat_model":null,"audit":null,"citation":null,"codeowners":null,"security":null,"support":null,"governance":null,"roadmap":null,"authors":null,"dei":null,"publiccode":null,"codemeta":null,"zenodo":null,"notice":null,"maintainers":null,"copyright":null,"agents":null,"dco":null,"cla":null}},"created_at":"2026-04-26T01:06:47.000Z","updated_at":"2026-05-08T14:21:20.000Z","dependencies_parsed_at":null,"dependency_job_id":null,"html_url":"https://github.com/jprando/testa-habilidade-ai-typescript","commit_stats":null,"previous_names":["jprando/testa-habilidade-ai-typescript"],"tags_count":0,"template":false,"template_full_name":null,"purl":"pkg:github/jprando/testa-habilidade-ai-typescript","repository_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/jprando%2Ftesta-habilidade-ai-typescript","tags_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/jprando%2Ftesta-habilidade-ai-typescript/tags","releases_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/jprando%2Ftesta-habilidade-ai-typescript/releases","manifests_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/jprando%2Ftesta-habilidade-ai-typescript/manifests","owner_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners/jprando","download_url":"https://codeload.github.com/jprando/testa-habilidade-ai-typescript/tar.gz/refs/heads/main","sbom_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/jprando%2Ftesta-habilidade-ai-typescript/sbom","scorecard":null,"host":{"name":"GitHub","url":"https://github.com","kind":"github","repositories_count":286080680,"owners_count":34549340,"icon_url":"https://github.com/github.png","version":null,"created_at":"2022-05-30T11:31:42.601Z","updated_at":"2026-05-26T15:22:16.424Z","status":"online","status_checked_at":"2026-06-19T02:00:06.005Z","response_time":61,"last_error":null,"robots_txt_status":"success","robots_txt_updated_at":"2025-07-24T06:49:26.215Z","robots_txt_url":"https://github.com/robots.txt","online":true,"can_crawl_api":true,"host_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub","repositories_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories","repository_names_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repository_names","owners_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners"}},"keywords":["ai-testing","async","concurrency","javascript","llm-benchmark","promise","qwen","typescript","v8-engine"],"created_at":"2026-06-19T22:01:31.673Z","updated_at":"2026-06-19T22:01:33.871Z","avatar_url":"https://github.com/jprando.png","language":"TypeScript","funding_links":[],"categories":[],"sub_categories":[],"readme":"# 🤖 LLM Concurrency Benchmark: O Teste de Fogo em TypeScript\n\nEste repositório existe para separar os modelos seniores dos juniores. O objetivo não é resolver um algoritmo de faculdade, mas sim um problema real e crítico de engenharia de software: **Controle de concorrência e gerenciamento de recursos**.\n\nA ideia central é medir a capacidade de raciocínio de modelos de linguagem (LLMs) diante de desafios de concorrência e gerenciamento de recursos no motor *V8* (*JavaScript*/*TypeScript*).\n\n## 📂 Organização do Projeto\n\nO repositório está estruturado para suportar o teste de múltiplos modelos de forma isolada e comparável:\n\n```text\n❯ ls -la\n.\n├── models/\n│   ├── openai.gpt-oss-20b/                    # [Empresa].[Nome-do-Modelo] (separador: \".\")\n│   │   ├── processWithLimit.ts                # Código gerado pela IA\n│   │   ├── processWithLimit.test.ts           # Cópia local da suíte de teste\n│   │   └── resultado.md                       # Relatório de análise\n│   └── unsloth.qwen3-coder-30b-a3b-instruct/  # [Usuário].[Nome-do-Modelo] (separador: \".\")\n│       ├── processWithLimit.ts                # Código gerado pela IA\n│       ├── processWithLimit.test.ts           # Cópia local da suíte de teste\n│       └── resultado.md                       # Relatório de análise\n├── template/\n│   └── processWithLimit.test.ts               # Template mestre da suíte de testes (23 Falhas)\n├── images/                                    # Capturas de tela dos resultados\n├── README.md                                  # Apresentação e guia do projeto\n└── package.json                               # Configuração do projeto\n```\n\n## 🚀 Como Utilizar (*Onboarding* para *DEVs*)\n\nPara testar como uma nova IA se comporta, siga este fluxo:\n\n1. **Crie a pasta do modelo:** Crie uma pasta dentro de `models/` seguindo o padrão `empresa-ou-usuario.modelo-especificacao`.\n2. **Gere a implementação:** Envie o [Prompt de Referência](#1-o-prompt-para-você-copiar-e-colar-nas-ias) para a IA e salve o código resultante como `processWithLimit.ts` dentro da pasta criada.\n3. **Prepare o Benchmark:** Copie somente o arquivo `template/processWithLimit.test.ts` da raiz para dentro da pasta do modelo.\n   \u003e 💡 **Dica (Linux/Macos):** No lugar de copiar, você pode criar um link simbólico para sempre refletir a versão mais recente do template: `ln -s $CAMINHOCOMPLETOPARAOPROJETO/template/processWithLimit.test.ts processWithLimit.test.ts`\n4. **Execute o Teste:**\n\n    ```bash\n    cd models/nome-da-pasta-do-modelo\n    bun test\n    ```\n\n    ![resultado do teste com openai.gpt-oss-20b](images/openai.gpt-oss-20b.png)\n\n\u003e **Nota de Diagnóstico:** Se o comando `bun test` travar e resultar em `timeout after 5000ms`, a implementação da IA falhou nos critérios de ***Deadlock*** ou ***Polling Infinito***.\n\n---\n\n### 1. O Prompt para você copiar e colar nas IAs\n\nCopie o bloco abaixo e envie para a IA que você deseja testar:\n\n```text\nAtue como um Engenheiro de Software Sênior especialista em TypeScript (e na engine do JavaScript (V8)).\n\nUtilize somente as informações do seu próprio modelo.\n\nEscreva uma função chamada `processWithLimit` que executa tarefas assíncronas com um limite máximo de concorrência.\n\n**Requisitos da Assinatura:**\n- A função deve receber três parâmetros: um array de itens do tipo `T`, uma função iteradora assíncrona `asyncFn` (que recebe um item e seu índice, retornando uma `Promise\u003cR\u003e`), e um número inteiro positivo `limit`.\n- A função deve retornar uma `Promise\u003cR[]\u003e` contendo todos os resultados na exata mesma ordem do array de itens original.\n\n**Regras de Implementação (Obrigatórias):**\n1. **Tipagem Estrita:** Utilize Generics (`T` e `R`) para inferir corretamente os tipos de entrada e saída. Nenhuma tipagem `any` ou `unknown` é permitida como bypass.\n2. **Sem Recursão:** É estritamente proibido utilizar qualquer tipo de recursão na sua lógica. Resolva o problema de forma iterativa.\n3. **Eficiência:** O código deve ser altamente performático. Evite mutações no array original (como `shift` ou `splice`) e garanta que os \"workers\" não fiquem ociosos se houver tarefas pendentes.\n4. **Elegância:** Utilize os recursos modernos do JavaScript/TypeScript (como `async/await`, desestruturação, etc.).\n\nApresente apenas a função implementada e uma breve explicação das suas escolhas arquiteturais.\n```\n\n---\n\n### 2. A Resposta Correta (Gabarito)\n\nAqui está a implementação ideal utilizando a abordagem de *Worker Pool* (Fila Contínua), focada em máxima eficiência, tipagem perfeita e zero recursão. Use este código para comparar com o que as outras IAs gerarem:\n\n```typescript\nasync function processWithLimit\u003cT, R\u003e(\n    items: readonly T[],\n    asyncFn: (item: T, index: number) =\u003e Promise\u003cR\u003e,\n    limit: number\n): Promise\u003cR[]\u003e {\n    // Proteção contra limites inválidos — falha: 15\n    if (!Number.isInteger(limit) || limit \u003c 1) {\n        throw new RangeError(\"`limit` deve ser um inteiro \u003e= 1.\");\n    }\n\n    // Otimização de comprimento e guarda contra array vazio — falha: 14\n    const _itemsLength = items.length;\n    if (_itemsLength === 0) return [];\n\n    // Pré-aloca o array com tamanho fixo para manter a ordem original — falha: 9, 11\n    const results = new Array\u003cR\u003e(_itemsLength);\n\n    // Ponteiro numérico compartilhado: evita shift/splice e varreduras O(N) — falha: 3, 7, 16\n    let currentIndex = 0;\n\n    // Worker como loop iterativo assíncrono: sem recursão, sem mix de sintaxes — falha: 2, 12\n    const worker = async () =\u003e {\n        // Loop contínuo (fila): workers nunca ficam ociosos esperando lote terminar — falha: 1, 21\n        while (currentIndex \u003c _itemsLength) {\n            // Incremento atômico síncrono antes de qualquer await: evita race condition — falha: 13\n            const index = currentIndex++;\n\n            // await garante concorrência real; slot indexado preserva ordem; valor resolvido (não Promise) — falha: 4, 6, 10, 20\n            results[index] = await asyncFn(items[index], index);\n        }\n    };\n\n    // Math.min evita instanciar workers fantasmas quando limit \u003e items.length — falha: 14\n    const concurrency = Math.min(limit, _itemsLength);\n    // Array.from cria workers independentes: sem Promise.race, sem contador manual — falha: 8, 17, 18, 19\n    const workers = Array.from({ length: concurrency }, worker);\n\n    // Bloqueia até todos os workers terminarem: sem retorno prematuro, sem polling — falha: 5, 22, 23\n    await Promise.all(workers);\n\n    return results;\n}\n```\n\n---\n\n### 3. O Que Avaliar nas Respostas das IAs\n\n\u003e 💡 **Quer pular a teoria?** [Ir direto para os resultados dos modelos testados.](#resultado-da-execução-do-teste)\n\nAo receber a resposta das outras inteligências, observe os seguintes pontos de falha comuns:\n\n* **Falha 1: Uso de \"Chunks\" (Lotes bloqueantes).**\n  * *O erro:* A IA divide o array em pedaços (ex: de 5 em 5) e usa um loop com `Promise.all` em cada pedaço.\n  * *Por que é ruim:* Isso não é limite de concorrência real. Se 4 tarefas de um lote terminarem rápido e 1 demorar, o sistema inteiro fica travado esperando essa 1 tarefa terminar antes de puxar a próxima da fila.\n\n* **Falha 2: Uso de Recursão.**\n  * *O erro:* A IA cria uma função interna que chama a si mesma quando a `Promise` resolve.\n  * *Por que é ruim:* Desrespeita a regra 2 do seu prompt. Além disso, em listas massivas, pode estourar a *call stack* (*Stack Overflow*). O gabarito usa um simples e eficiente loop `while`.\n\n* **Falha 3: Mutação de Array (`shift()`).**\n  * *O erro:* A IA usa um loop e vai removendo o primeiro item do array de entrada usando `items.shift()`.\n  * *Por que é ruim:* Em JavaScript, `.shift()` em arrays grandes é uma operação custosa (O(n)), pois exige o re-indexamento de todos os elementos restantes a cada remoção. O gabarito usa um ponteiro numérico O(1).\n\n* **Falha 4: Perda de Ordem Original.**\n  * *O erro:* A IA faz um push (`results.push()`) conforme as tarefas terminam.\n  * *Por que é ruim:* Como as promessas resolvem em tempos diferentes, o array final ficará fora de ordem em relação à entrada. O gabarito resolve isso usando o `index` original pré-calculado: `results[index] = ...`.\n\n* **Falha 5: Ausência de Bloqueio Final (Retorno Prematuro)**\n  * *O erro:* O modelo cria o loop que dispara os workers, mas esquece de incluir um `await Promise.all(...)` no final do processo principal, executando o `return results` imediatamente.\n  * *Por que é ruim:* A função retorna um array vazio (ou cheio de `undefined`) em milissegundos, enquanto as tarefas assíncronas continuam rodando soltas (em *background*) como processos fantasma.\n\n* **Falha 6: Falsa Concorrência por Falta de `await` (Sobrecarga)**\n  * *O erro:* O modelo até tenta montar a lógica, mas na hora de executar a tarefa faz algo como `results[i] = asyncFn(...)` sem o `await` ou sem colocar isso dentro de uma estrutura que aguarde a resolução corretamente.\n  * *Por que é ruim:* O limite de concorrência é totalmente ignorado. O loop varre o array em milissegundos e dispara 1.000 requisições simultâneas, podendo derrubar bancos de dados ou tomar *rate limit* de APIs.\n\n* **Falha 7: Ineficiência no *Pool* de *Workers* (Uso de *Arrays* Ativos)**\n  * *O erro:* A IA tenta controlar os workers criando um array auxiliar (ex: `activePromises`) e usa métodos como `.indexOf()` e `.splice()` toda vez que uma tarefa termina para removê-la da lista.\n  * *Por que é ruim:* Esses métodos varrem e reindexam o array, o que tem complexidade $O(N)$. Fazer isso dentro de um loop para cada item concluído destrói a performance da CPU em listas massivas.\n\n* **Falha 8: Deadlock com `Promise.race`**\n  * *O erro:* Na tentativa de liberar espaço no limite de workers, o modelo cria um gargalo usando `await Promise.race(activeWorkers)`, mas comete o erro de acionar isso quando o array ainda está vazio.\n  * *Por que é ruim:* Em JavaScript, um `Promise.race` com um array vazio nunca resolve. O código entra em *deadlock* (trava infinitamente) logo no primeiro milissegundo de execução.\n\n* **Falha 9: Perda de Tipagem e \"Type Juggling\" (Gambiarra de Tipos)**\n  * *O erro:* A IA não consegue satisfazer o compilador do TypeScript de forma limpa e apela para instanciar o array sem o Generic (`new Array()` que vira `any[]`), ignora que o tipo `R` pode validar o contrato de saída, ou força coerções artificiais para calar o compilador.\n  * *Por que é ruim:* Quebra o propósito primário do TypeScript: a segurança de tipos. Esconde erros que deveriam ser pegos no momento da compilação, permitindo que código frágil vá para produção.\n\n* **Falha 10: Silenciamento de Erros (*Anti-pattern* de `try/catch`)**\n  * *O erro:* A IA toma a liberdade de engolir possíveis falhas da função colocando a execução num `try/catch` que apenas faz um `console.error` e manda o loop continuar.\n  * *Por que é ruim:* Se a tarefa do índice 2 falhar, o código segue em frente. O array retornado terá um \"buraco\" no meio. Em concorrência padrão no JavaScript, o correto é que, se uma sub-tarefa falhar, a `Promise` principal também falhe.\n\n* **Falha 11: Realocação Dinâmica de Memória**\n  * *O erro:* O modelo começa com um array vazio `const results: R[] = [];` e depois o preenche fora de ordem saltando índices (ex: `results[99] = valor`).\n  * *Por que é ruim:* Quando você joga valores em índices muito altos de um array inicializado vazio, você força a *engine* do JavaScript a ficar realocando memória e transformando um array compacto em uma estrutura esparsa menos eficiente.\n\n* **Falha 12: Mistura de Sintaxes e Padrões (O Código *Frankenstein*)**\n  * *O erro:* A IA usa o moderno `async/await` mas, no meio da lógica, emenda cadeias antigas de `.then().finally()` ou cria Funções Invocadas Imediatamente (*IIFEs*) assíncronas totalmente desnecessárias.\n  * *Por que é ruim:* Além de ser visualmente feio e difícil de dar manutenção, esse \"contorcionismo\" sintático frequentemente gera armadilhas de escopo, mutação de estado invisível e perda de clareza arquitetural.\n\n* **Falha 13: Condição de Corrida (*Race Condition*) no Ponteiro**\n  * *O erro*: O modelo cria o ponteiro compartilhado, mas faz operações assíncronas antes de incrementá-lo.\n  * *Por que é ruim*: No JavaScript, o código pausa no `await` e libera a *thread* para outros *workers*. Se 5 *workers* chegarem ao mesmo tempo, todos lerão o `nextIndex` como 0. Todos farão a tarefa duplicada.\n\n    Exemplo de código ruim:\n\n    ```typescript\n    const index = nextIndex;\n    await algumaCoisa();\n    nextIndex++;\n    ```\n\n* **Falha 14: Superlotação de *Workers* (*Over-provisioning*)**\n  * *O erro*: A IA confia cegamente no número passado na variável limit para instanciar as tarefas, ignorando o tamanho do array de entrada. Fazendo um loop fixo tipo `for(let i = 0; i \u003c limit; i++)`.\n  * *Por que é ruim*: Imagine que você receba um array com apenas 2 itens, mas, por segurança global do sistema, passou `limit = 1000`. O código vai instanciar 998 *workers* fantasmas que não têm trabalho algum a fazer.\n\n* **Falha 15: Cegueira para Casos de Contorno (Limites Inválidos)**\n  * *O erro*: A IA assume que todos os parâmetros recebidos serão perfeitos e felizes, esquecendo de validar se o limite faz sentido matemático.\n  * *Por que é ruim*: O que acontece se outro pedaço do seu sistema calcular o limite dinamicamente e, por algum bug, passar `limit = 0` ou `limit = -1`? A maioria dos códigos gerados por IAs vai entrar em comportamento indefinido, silencioso ou travado.\n\n* **Falha 16: Efeito Colateral na Referência (*Mutation Side-Effects*)**\n  * *O erro*: A IA tenta driblar a complexidade alterando o array de entrada para facilitar a própria vida. Por exemplo, ela faz um `items.reverse()` logo na primeira linha e depois vai usando `.pop()`.\n  * *Por que é ruim*: Em JavaScript, arrays e objetos são passados por referência. Se a função `processWithLimit` alterar o array `items` internamente, ela vai destruir os dados originais no componente chamador e introduzir bugs colaterais difíceis de rastrear.\n\n* **Falha 17: A Armadilha da Promessa Resolvida no `Promise.race`**\n  * *O erro*: Acumular promessas em um único array e passar esse array inteiro repetidas vezes para o `Promise.race()` (ex: `Promise.race(results)`).\n  * *Por que reprova*: Em JavaScript, se você passar uma `Promise` que já foi concluída para um `Promise.race`, ele resolve imediatamente, sem esperar por mais nada. Quando a primeira tarefa do pool termina, o mecanismo inteiro degrada em comportamento incorreto.\n\n* **Falha 18: Varredura $O(N)$ Oculta no Loop (Gargalo de CPU)**\n  * *O erro*: Usar métodos de iteração de array como `.filter()`, `.map()` ou `.reduce()` dentro do loop de concorrência (ex: `results.filter(p =\u003e p !== null)`).\n  * *Por que reprova*: Isso cria uma complexidade $O(N^2)$ invisível. Se houver 10.000 itens, nas últimas execuções o *Node.js* estará varrendo um array de 10.000 posições a cada milissegundo à toa.\n\n* **Falha 19: Dessincronização de Estado (*State Desync*)**\n  * *O erro*: Confiar na resolução de um `Promise.race` para alterar contadores matemáticos de forma cega (ex: `await Promise.race(...); inProgressCount--;`).\n  * *Por que reprova*: O `Promise.race` avisa quando a primeira promessa termina. Mas e se duas ou três tarefas super rápidas terminarem exatamente no mesmo milissegundo? O código subtrai apenas 1 e o estado interno fica mentindo.\n\n* **Falha 20: Poluição do Array de Resultados (*State Pollution*)**\n  * *O erro*: Usar o array final de resultados para armazenar os objetos `Promise` pendentes durante o processamento, deixando para o `Promise.all` final o trabalho de desembrulhar os valores.\n  * *Por que reprova*: É uma falha arquitetural de responsabilidade. O array de `results` (tipado como `R[]`) deve guardar apenas os valores finais já resolvidos. Misturar objetos `Promise` com valores concretos polui o contrato mental da estrutura.\n\n* **Falha 21: Quebra de Loop Irreversível (Impedância Síncrono/Assíncrono)**\n  * *O erro*: Usar `break` num loop `for` síncrono quando o limite é atingido, esperando que a conclusão de uma tarefa assíncrona consiga \"retomar\" esse loop no futuro.\n  * *Por que reprova*: O JavaScript não funciona assim. O loop síncrono morre imediatamente. Quando a tarefa termina e tenta iniciar o próximo item, o fluxo principal já desapareceu da *Call Stack*.\n\n* **Falha 22: Mutação de Escopo Morto (*Ghost Mutation*)**\n  * *O erro*: Tentar alterar a variável de controle de um loop (como fazer um `i--`) dentro de um bloco assíncrono `.then()` ou `.finally()`.\n  * *Por que reprova*: Devido ao funcionamento de *Closures*, o callback assíncrono modifica uma cópia da variável isolada na memória, muito tempo depois do loop original ter encerrado. É uma operação sem efeito prático útil.\n\n* **Falha 23: *Polling* Assíncrono (O *Anti-Padrão* do `setTimeout`)**\n  * *O erro*: Criar uma função recursiva com `setTimeout` para checar a cada X milissegundos se as tarefas terminaram (ex: `if (inProgress === 0) resolve() else setTimeout()`).\n  * *Por que reprova*: É uma aberração em sistemas orientados a eventos. Desperdiça ciclos de CPU acordando o motor *V8* repetidas vezes sem necessidade, adiciona latência artificial à resposta final e costuma mascarar bugs de sincronização.\n\n* **Falha 24: Ausência de Imutabilidade na Assinatura (`readonly T[]`)**\n  * *O erro*: A IA declara o parâmetro de entrada como `items: T[]` em vez de `items: readonly T[]`, mesmo quando a função apenas consome os dados e não precisa mutá-los.\n  * *Por que é ruim*: Em TypeScript, `readonly T[]` transforma a intenção arquitetural em contrato explícito de API. Isso eleva a segurança estática, reduz a superfície para efeitos colaterais acidentais e demonstra maturidade no desenho da assinatura. A ausência de `readonly` não quebra o *runtime*, mas revela uma oportunidade perdida de tornar a função mais precisa, mais segura e mais sênior.\n  * *Como avaliar*: Se a função usa `readonly T[]`, marque como ponto positivo de design. Se usa apenas `T[]`, mas não muta a entrada, trate como **dívida técnica de assinatura**. Se além disso muta o array recebido, a implementação também incorre na **Falha 16**.\n\n## Resultado da execução do teste\n\nA seguir você encontra a análise técnica (resumida) do código gerado pelo modelo, com apenas uma única submissão do [prompt de referência](#1-o-prompt-para-você-copiar-e-colar-nas-ias) e testado no ambiente do projeto.\n\n### Códigos Vencedores\n\n#### #1 openai.gpt-5.5-high\n\n\u003e em 27/04/2026\n\n🏆 Aprovado com Louvor (Gabarito Absoluto)\n\nA implementação definitiva do *benchmark*. Este modelo unifica a mais alta eficiência do motor JavaScript com práticas impecáveis de *Clean Code*. Ele impõe imutabilidade através de `readonly T[]`, usa *Worker Pool* iterativo puro e demonstra domínio completo do contrato da função.\n\n[detalhamento completo](models/openai.gpt-5.5-high/resultado.md)\n\n#### #2 qwen.qwen3.6-27b\n\n\u003e em 26/04/2026\n\n✅ Aprovado (Código Sênior Impecável)\n\nEste modelo gerou a implementação ideal. Ele construiu a arquitetura correta de *Worker Pool* (Fila Contínua), otimizou o uso de memória e gerenciou perfeitamente o *Event Loop*. O grande diferencial está na limpeza arquitetural da solução.\n\n[detalhamento completo](models/qwen.qwen3.6-27b/resultado.md)\n\n#### #3 openai.gpt5.3-codex-high\n\n\u003e em 27/04/2026\n\n⚠️ Aprovado (Dívida Técnica de Estilo)\n\nEste modelo entregou a arquitetura mais robusta e segura do *benchmark*, sendo o único a utilizar `readonly T[]` para garantir a imutabilidade do `array` de entrada. Implementa o padrão *Worker Pool* com excelente controle de ordem e concorrência.\n\n[detalhamento completo](models/openai.gpt5.3-codex-high/resultado.md)\n\n### Passaram nos Testes (com Ressalvas)\n\n#### #1 anthropic.sonnet4.6-adaptativo\n\n\u003e em 26/04/2026\n\n⚠️ Aprovado com Ressalvas (Código Sênior, falha em Edge Case)\n\nO modelo entregou uma das soluções mais elegantes e enxutas do *benchmark*. Utilizou `Array.from` para inicializar a *Worker Pool* de forma limpa e demonstrou domínio profundo do TypeScript ao usar uma arquitetura iterativa precisa.\n\n[detalhamento completo](models/anthropic.sonnet4.6-adaptativo/resultado.md)\n\n#### #2 google.gemini3.1-pro\n\n\u003e em 26/04/2026\n\n⚠️ Aprovado com Ressalvas (Código Sênior, falha em Edge Case)\n\nO modelo entregou uma implementação clássica e muito limpa do padrão *Worker Pool*. Ele evita sobrecarga usando `Math.min` para calcular os workers necessários e gerencia o ponteiro atômico `currentIndex` com disciplina correta.\n\n[detalhamento completo](models/google.gemini3.1-pro/resultado.md)\n\n#### #3 openai.gpt-oss-20b\n\n\u003e em 25/04/2026\n\n⚠️ Aprovado (Código Sênior com ressalva de fronteira)\n\nEste modelo apresentou uma solução extremamente robusta e performática, implementando perfeitamente o padrão de *Worker Pool* (Fila Contínua) e blindando o código contra gargalos de ociosidade.\n\n[detalhamento completo](models/openai.gpt-oss-20b/resultado.md)\n\n#### poolsize.aguna-xs2\n\n\u003e em 29/04/2026\n\n⚠️ Aprovado com Ressalvas (Código Sênior, falha em Edge Case)\n\nO modelo entregou uma das soluções mais curtas, elegantes e brilhantes de todo o *benchmark*. Ao utilizar uma matriz de iterações assíncronas resolvidas nativamente por um único `Promise.all()`, mostrou excelente domínio do motor JavaScript.\n\n[detalhamento completo](models/poolside.laguna-xs2/resultado.md)\n\n#### #4 anthropic.haiku4.5-estendido\n\n\u003e em 26/04/2026\n\n⚠️ Aprovado com Ressalvas (Alternativa O(1), falha em Edge Case)\n\nO modelo optou pela arquitetura de rastreamento de tarefas usando `Promise.race`, mas demonstrou excelente senioridade ao utilizar um `Set` em vez de um `Array` para gerenciar a fila. Isso garantiu desempenho constante na remoção das tarefas ativas.\n\n[detalhamento completo](models/anthropic.haiku4.5-estendido/resultado.md)\n\n#### #5 qwen.qwen3.6-max-preview\n\n\u003e em 26/04/2026\n\n⚠️ Aprovado com Ressalvas (Código Sênior, Falha por Fallback Silencioso)\n\nEste modelo gerou uma das implementações de *Worker Pool* mais performáticas e limpas em termos de alocação de memória (evitando `.push` e criando arrays de tamanho exato). No entanto, reprovou no critério de propagação de erro ao inserir um fallback silencioso.\n\n[detalhamento completo](models/qwen.qwen3.6-max-preview/resultado.md)\n\n#### #6 anthropic.opus4.7\n\n\u003e em 27/04/2026\n\n⚠️ Aprovado com Ressalvas (Fallback Silencioso e Dívida de Estilo)\n\nO modelo entregou uma implementação extremamente performática da *Worker Pool*, fazendo uso de *Bitwise Operators* (`limit | 0`) para coerção de inteiros de altíssima velocidade e mantendo a segurança de ordem dos resultados.\n\n[detalhamento completo](models/anthropic.opus4.7/resultado.md)\n\n#### #7 google.gemma4-26b-a4b\n\n\u003e em 26/04/2026\n\n⚠️ Aprovado com Ressalvas (Código Sênior, falha em Edge Case)\n\nO modelo entregou uma arquitetura sólida de *Worker Pool*, gerenciando a concorrência de forma nativa e sem gargalos de CPU (passando facilmente nos testes de carga). No entanto, pecou em dois pontos de borda.\n\n[detalhamento completo](models/google.gemma4-26b-a4b/resultado.md)\n\n### #8 google.gemma4-e4b\n\n\u003e em 28/04/2026\n\n⚠️ Aprovado em Runtime (com Ressalvas Estruturais e Dívida de Tipagem)\n\nO modelo gemma4-e4b demonstrou excelência funcional ao ser aprovado em todos os testes da suíte de estresse, empregando corretamente laços iterativos para evitar quebra de pilha por recursão e garantindo boa disciplina de concorrência.\n\n[detalhamento completo](models/google.gemma4-e4b/resultado.md)\n\n#### #9 qwen.qwen3.6-35B-A3B\n\n\u003e em 26/04/2026\n\n⚠️ Aprovado em Runtime (com Dívida Técnica de Tipagem)\n\nO modelo passou em 100% dos testes lógicos e de estresse no motor *V8* (*Bun*), apresentando a proteção correta contra limites inválidos (*Fail-Fast*). No entanto, a solução é o que chamamos de aprovação apenas em runtime.\n\n[detalhamento completo](models/qwen.qwen3.6-35B-A3B/resultado.md)\n\n### Códigos com Erro\n\n#### #1 zai.glm4.7-flash\n\n\u003e em 26/04/2026\n\n❌ Reprovado (Unhandled Promise Rejection)\n\nO modelo construiu uma arquitetura híbrida de rastreamento com `Set` e `Promise.race`, acertando em cheio na Cláusula de Guarda (passando nos testes de fronteira matemática). No entanto, cometeu um erro crítico na propagação de falhas.\n\n[detalhamento completo](models/zai.glm4.7-flash/resultado.md)\n\n#### #2 qwen.qwen3-235B-A22B-2507\n\n\u003e em 26/04/2026\n\n❌ Reprovado (Deadlock por Semáforo em Casos de Fronteira)\n\nEste modelo peso-pesado aplicou um padrão clássico de Ciência da Computação — o Semáforo (Semaphore) — para controlar a concorrência. Embora a lógica funcione perfeitamente para limites válidos, falhou em casos de fronteira.\n\n[detalhamento completo](models/qwen.qwen3-235B-A22B-2507/resultado.md)\n\n#### #3 qwen.qwen3-coder\n\n\u003e em 26/04/2026\n\n❌ Reprovado por Corrupção de Estado e Retorno Prematuro.\n\nEste modelo tentou implementar um gerenciador de concorrência baseado em um array de \"tarefas ativas\" e `Promise.race`. No entanto, ele cometeu um erro lógico grosseiro ao remover as tarefas concluídas.\n\n[detalhamento completo](models/qwen.qwen3-coder/resultado.md)\n\n#### #4 unsloth.qwen3-coder-30b-a3b-instruct\n\n\u003e em 25/04/2026\n\n❌ Reprovado (Múltiplas Falhas Críticas)\n\nEste modelo produziu o que chamamos de \"código Frankenstein\". Embora tente utilizar métodos modernos de manipulação de array do JavaScript (`slice`, `flat`), ele falha nos fundamentos da concorrência e do contrato de tipos.\n\n[detalhamento completo](models/unsloth.qwen3-coder-30b-a3b-instruct/resultado.md)\n","project_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fjprando%2Ftesta-habilidade-ai-typescript","html_url":"https://awesome.ecosyste.ms/projects/github.com%2Fjprando%2Ftesta-habilidade-ai-typescript","lists_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fjprando%2Ftesta-habilidade-ai-typescript/lists"}