Programação
Compare correção, qualidade e utilidade prática do código gerado.
Neste genero, as capacidades mais observadas sao Correcao, Completude, Qualidade do codigo.
Diferente de system design, aqui pesa mais se o codigo realmente funciona do que as decisoes de arquitetura em alto nivel.
Uma nota alta aqui nao garante melhor julgamento de produto, melhor arquitetura nem explicacoes mais didaticas.
Para que servem modelos fortes neste genero
implementacao, depuracao, refatoracao e apoio pratico ao programar.
O que este genero sozinho nao consegue mostrar
se o modelo e melhor para arquitetura, documentos para stakeholders ou ideacao aberta.
Programação: o GPT-5 mini fica em 1.º, mas a média mais alta cai para 4.º
Anthropic
OpenAI
OpenAI
Pontuacao media por modelo
Como ponderamos
Em 37 respostas de programação avaliadas, a liderança é do GPT-5 mini: média de 8,22 em 5 amostras, 5 primeiros lugares e 100 % de vitórias. É ao mesmo tempo o mais bem classificado e um dos mais bem fundamentados aqui, uma varredura limpa a custo de gama leve. Logo atrás, o Claude Opus 4.8 ocupa o 2.º lugar com 8,07 em apenas 2 amostras e um registo perfeito de 100 %, por isso leia-o como um sinal forte mas ainda provisório.
A média e a ordem divergem bastante, porque a taxa de vitórias (primeiros lugares diretos) pesa mais do que a média bruta. O GPT-5.5 regista a média mais alta do género, 8,9, e ainda assim fica em 4.º, porque em 2 amostras venceu apenas 1, uma taxa de 50 %. O GPT-5.4, por outro lado, traz o maior volume de evidência, 8 amostras, com média de 8,41, 6 primeiros lugares e 75 % de vitórias no 3.º lugar. A vantagem do líder sobre o 2.º é de apenas 0,15 pontos, por isso o topo está muito renhido.
O caso mais claro de boa média enterrada por um fraco confronto direto é o Gemini 2.5 Pro: média de 7,95, acima do meio da tabela, mas 6.º lugar com 0 % de vitórias em 4 amostras. O Claude Sonnet 4.6 lidera o meio com 7,7 (50 % em 4 amostras, 5.º lugar), atrás do grupo GPT-5 por cerca de 0,5 a 1,2 pontos. As gamas mais leves ficam abaixo: Gemini 2.5 Flash-Lite (7,17), Gemini 2.5 Flash (6,84) e Claude Haiku 4.5 (6,48) estão a 1,0–1,7 pontos do líder. Com a Correção no peso máximo (35), à frente de Completude e Qualidade de código (20 cada), essas diferenças apontam para correção mais fraca nas tarefas difíceis, não apenas estilo.
A maior ressalva é o tamanho da amostra. O Claude Opus 4.8 e o GPT-5.5 assentam em 2 amostras cada e a maioria está entre 3 e 8, por isso as médias podem oscilar com alguns prompts. A diferença de 1,74 pontos entre o primeiro e o último é real, mas a ordem fina dentro do grupo dos 8 pontos (GPT-5.5, GPT-5.4, GPT-5 mini, Claude Opus 4.8) deve ser lida como provisória. São medidas dependentes das condições, não um veredicto sobre qual modelo programa melhor em geral.
Resumo
Para programar com confiança hoje, o GPT-5 mini é a escolha mais defensável: 1.º lugar com 100 % de vitórias em 5 amostras a custo de gama leve. O GPT-5.4 é a opção de gama alta mais bem evidenciada (8,41 em 8 amostras), enquanto a média recorde de 8,9 do GPT-5.5 e o 2.º lugar do Claude Opus 4.8 assentam ambos em 2 amostras, por isso veja-os como promissores, mas não comprovados.
Esta analise baseia-se nas pontuacoes de benchmark medidas pela Orivel para este genero e e atualizada periodicamente. As pontuacoes sao medidas dependentes das condicoes, nao uma verdade absoluta.
Ranking de modelos fortes neste genero
Este ranking e ordenado pela pontuacao media apenas dentro deste genero.
Ultima atualizacao: 16 Jul 2026 09:49
Taxa de vitoria
Pontuacao media
Taxa de vitoria
Pontuacao media
Taxa de vitoria
Pontuacao media
Taxa de vitoria
Pontuacao media
Taxa de vitoria
Pontuacao media
Taxa de vitoria
Pontuacao media
Taxa de vitoria
Pontuacao media
Taxa de vitoria
Pontuacao media
Taxa de vitoria
Pontuacao media
| Modelos no ranking | Detalhe | ||||||
|---|---|---|---|---|---|---|---|
| #1 | Claude Fable 5 | Anthropic |
100%
|
91
|
1 | 1 | Ver a avaliacao e a pontuacao de Claude Fable 5 |
| #2 | GPT-5.6 NOVO | OpenAI |
100%
|
86
|
1 | 1 | Ver a avaliacao e a pontuacao de GPT-5.6 |
| #3 | GPT-5 mini | OpenAI |
100%
|
82
|
5 | 5 | Ver a avaliacao e a pontuacao de GPT-5 mini |
| #4 | Claude Opus 4.8 | Anthropic |
100%
|
81
|
2 | 2 | Ver a avaliacao e a pontuacao de Claude Opus 4.8 |
| #5 | GPT-5.5 | OpenAI |
50%
|
89
|
1 | 2 | Ver a avaliacao e a pontuacao de GPT-5.5 |
| #6 | Claude Sonnet 4.6 | Anthropic |
50%
|
77
|
2 | 4 | Ver a avaliacao e a pontuacao de Claude Sonnet 4.6 |
| #7 | Gemini 2.5 Pro |
0%
|
74
|
0 | 5 | Ver a avaliacao e a pontuacao de Gemini 2.5 Pro | |
| #8 | Gemini 2.5 Flash-Lite |
0%
|
72
|
0 | 3 | Ver a avaliacao e a pontuacao de Gemini 2.5 Flash-Lite | |
| #9 | Gemini 2.5 Flash |
0%
|
68
|
0 | 5 | Ver a avaliacao e a pontuacao de Gemini 2.5 Flash |
O que e avaliado em Programação
Criterios e pesos usados neste ranking por genero.
Correcao
35.0%
Este criterio foi incluido para verificar Correcao na resposta. Ele recebe mais peso porque influencia fortemente o resultado final deste genero.
Completude
20.0%
Este criterio foi incluido para verificar Completude na resposta. Ele tem peso relevante porque afeta a qualidade de forma visivel, mesmo nao sendo o unico ponto importante.
Qualidade do codigo
20.0%
Este criterio foi incluido para verificar Qualidade do codigo na resposta. Ele tem peso relevante porque afeta a qualidade de forma visivel, mesmo nao sendo o unico ponto importante.
Valor pratico
15.0%
Este criterio foi incluido para verificar Valor pratico na resposta. Ele recebe peso menor porque apoia o objetivo principal, mas nao define sozinho este genero.
Seguimento de instrucoes
10.0%
Este criterio foi incluido para verificar Seguimento de instrucoes na resposta. Ele recebe peso menor porque apoia o objetivo principal, mas nao define sozinho este genero.
Tarefas recentes
Programação
Limitador de taxa com janela deslizante e quotas justas multi-inquilino
Implemente uma biblioteca reutilizável de limitador de taxa numa linguagem à sua escolha (Python, Go, TypeScript, Java ou Rust) que imponha quotas de requisições por cliente usando um algoritmo de janela deslizante, além de uma política de partilha justa entre múltiplos inquilinos. Requisitos funcionais: 1. Forneça uma classe ou módulo com um método tal como allow(tenant_id, client_id, now_ms) que retorne se uma requisição é permitida e, quando negada, quantos milissegundos faltam até que a próxima requisição seja permitida (retry_after_ms). 2. Cada cliente é limitado a um número máximo de requisições dentro de uma janela de tempo rolling (por exemplo, 100 requisições por 60.000 ms). A configuração deve ser ajustável por inquilino. 3. Implemente uma verdadeira janela deslizante (ponderada ou baseada em log), não uma janela de baldes fixa por calendário, de modo que rajadas que atravessam os limites dos baldes sejam tratadas corretamente. 4. Adicione um teto global por inquilino de forma que todos os clientes de um inquilino combinados não possam exceder um limite a nível de inquilino, e quando o inquilino estiver saturado a capacidade restante seja compartilhada de maneira justa entre os clientes ativos em vez de ser monopolizada por um cliente. 5. O limitador deve ser seguro sob acesso concorrente a partir de múltiplas threads ou tarefas assíncronas. 6. A memória não deve crescer sem limites: o estado de clientes obsoletos deve ser expurgado ou compactado ao longo do tempo. Entregáveis: - A implementação completa com API pública clara e documentação inline das decisões-chave. - Uma breve explicação (em comentários ou numa curta seção em prosa) do algoritmo de janela deslizante escolhido e suas compensações entre precisão/memória. - Uma suíte de testes cobrindo os casos limite principais descritos abaixo. Casos limite a tratar explicitamente no código e nos testes: - Requisições exatamente na fronteira da janela. - Um cliente que fica ocioso e depois retorna após a janela ter expirado completamente. - Requisições concorrentes competindo pelo mesmo contador de cliente. - Relógio retrocedendo ou timestamps duplicados. - Saturação do inquilino e redistribuição justa entre clientes concorrentes. - Expurgo de estado de cliente obsoleto sem eliminar clientes ativos. Declare quaisquer suposições que fizer (single-process vs distributed, disponibilidade de relógio monotónico, etc.). Se assumir um processo único, descreva brevemente como o design se estenderia para um deployment distribuído.
Programação
Implemente um Simulador Determinístico de Livro de Ordens Limite
Escreva uma solução de arquivo único em Python 3.11 implementando a função process_events(events: list[dict]) -> dict. Não use pacotes externos. A função deve simular um pequeno livro de ordens limite de uma bolsa para um instrumento. Ela recebe uma lista de dicionários de eventos na ordem de entrada e retorna um dicionário com exatamente estas chaves: trades, rejected, book. Tipos de evento: 1. Evento de nova ordem: Campos obrigatórios: type="new", id, side, order_type, qty. side é "buy" ou "sell". order_type é "limit" ou "market". qty é um inteiro positivo. Uma ordem limit também requer price, um número inteiro positivo de centavos. Campo opcional tif é time-in-force: "GTC", "IOC", ou "FOK". Se ausente, use "GTC" para ordens limit e "IOC" para ordens market. Ordens market não podem ter tif="GTC" e não podem ficar repousando no livro. 2. Evento de cancelamento: Campos obrigatórios: type="cancel", id. Cancela a quantidade restante de uma ordem atualmente repousando com esse id. Regras de pareamento: - O livro tem bids e asks. Ordens limit buy repousadas são bids; ordens limit sell repousadas são asks. - Prioridade preço-tempo é obrigatória: melhor preço primeiro; para o mesmo preço, a ordem repousada aceita mais cedo primeiro. - Uma ordem buy casa com asks repousados enquanto puder cruzar: buy market cruza qualquer ask; buy limit cruza asks com preço do ask <= preço limit do buy. - Uma ordem sell casa com bids repousados enquanto puder cruzar: sell market cruza qualquer bid; sell limit cruza bids com preço do bid >= preço limit do sell. - A quantidade de cada trade é min(quantidade restante do entrante, quantidade restante do repousado). - O preço do trade é sempre o preço limit da ordem maker repousada, nunca o preço da ordem entrante. - Um registro de trade deve ser anexado imediatamente quando ocorrer, com exatamente estas chaves: buy_id, sell_id, price, qty, taker_id, maker_id. - Ordens repousadas parcialmente preenchidas mantêm sua prioridade original com a quantidade restante. Ordens totalmente preenchidas deixam o livro. Comportamento de time-in-force: - Ordens limit GTC mantêm qualquer restante não preenchido no livro. - Ordens IOC executam o máximo possível imediatamente e então cancelam qualquer restante. - Ordens FOK devem ser completamente passíveis de preenchimento imediatamente de acordo com o livro atual e as regras de cruzamento. Se não puderem ser totalmente preenchidas, não produzem trades e não alteram o livro. Se completamente preenchíveis, executam normalmente. Ordens FOK nunca repousam. Regras de validação e rejeição: - Se um evento estiver malformado, rejeite-o sem alterar o livro. Anexe um registro de rejeição a rejected com chaves input_index, event, reason. O reason pode ser uma string curta e legível por humanos. - Rejeite uma nova ordem se seu id já tiver sido usado por qualquer new order previamente aceita, mesmo que essa ordem anterior já tenha sido preenchida ou cancelada desde então. - Rejeite eventos de cancelamento para ids desconhecidos ou ids que não estejam mais repousando. - Rejeite qty e price não inteiros, zero ou negativos. Em Python, bool não deve ser aceito como inteiro para esses campos. - Ignore campos extras em eventos que seriam de outra forma válidos. Formato de retorno: - trades: lista de registros de trade na ordem de execução. - rejected: lista de registros de rejeição na ordem de entrada. - book: um dicionário com chaves bids e asks. - book["bids"] deve listar todos os bids repousados ordenados por preço descendente, depois por tempo original de repouso, cada um como {"id": id, "price": price, "qty": remaining_qty}. - book["asks"] deve listar todos os asks repousados ordenados por preço ascendente, depois por tempo original de repouso, cada um como {"id": id, "price": price, "qty": remaining_qty}. Sua resposta deve ser um código Python executável completo definindo process_events. Você pode incluir classes/funções auxiliares e uma pequena seção de auto-teste protegida por if __name__ == "__main__":, mas a função principal não deve ler stdin nem escrever stdout.
Programação
Implementar aplicação atômica de JSON Patch em Python
Escreva uma implementação em Python 3.11 de uma função denominada apply_json_patch(document, patch) que aplique uma sequência de operações no estilo JSON Patch a um valor compatível com JSON e retorne o valor patchado. O documento de entrada pode ser qualquer combinação de dict, list, str, int, float, bool e None. O patch é uma lista de dicionários de operações. A implementação não deve mutar o documento original nem qualquer objeto aninhado alcançável a partir dele. Se qualquer operação for inválida, a função deve lançar uma classe de exceção personalizada chamada JsonPatchError e deixar o documento original inalterado. Operações suportadas: add, remove, replace, move, copy e test. Use caminhos JSON Pointer com tokens separados por barras, onde a string vazia identifica o documento inteiro, os tokens decodificam ~1 como / e ~0 como ~, e qualquer outro uso de ~ é inválido. Para objetos, um token de caminho é uma chave. Para arrays, um token de caminho deve ser um inteiro não negativo sem zeros à esquerda, exceto o token único 0; apenas para add, o token final pode ser - para anexar. A operação add insere em arrays em um índice de 0 até len(array), anexa para '-', define uma chave de objeto, ou substitui o documento inteiro se o caminho for vazio. A operação remove requer que o alvo exista e o elimina. A operação replace requer que o alvo exista e o substitui. A operação move requer os campos from e path, remove o valor em from e o adiciona em path, e deve rejeitar mover um valor para um dos seus próprios descendentes. A operação copy requer os campos from e path e faz uma cópia profunda (deep copy) do valor de origem para o alvo. A operação test requer value e só tem sucesso se o alvo atual for igual em profundidade (deeply equal) a value, incluindo a igualdade normal do Python para números e igualdade exata para strings, booleanos e None. Cada dicionário de operação deve conter exatamente os campos exigidos por essa operação mais o campo op; campos desconhecidos ou campos ausentes são erros. A função deve ser determinística, razoavelmente eficiente e depender somente da biblioteca padrão do Python. Inclua quaisquer funções auxiliares ou classes necessárias. Não escreva um programa de linha de comando nem use pacotes externos.
Programação
Implemente um Agendador de Tarefas Baseado em Dependências em Python
Escreva uma função ou classe em Python que agende uma lista de tarefas com base em suas dependências. O agendador deve determinar a ordem na qual as tarefas podem ser executadas, agrupando as tarefas que podem rodar em paralelo. A entrada será uma lista de dicionários, onde cada dicionário representa uma tarefa com as seguintes chaves: - `id`: Um identificador de string único para a tarefa. - `name`: Um nome em string para a tarefa. - `dependencies`: Uma lista de IDs em string de tarefas que devem ser concluídas antes que esta tarefa possa iniciar. Sua implementação deve: 1. Receber a lista de dicionários de tarefas como entrada. 2. Retornar um plano de execução válido como uma lista de listas. Cada lista interna representa um 'lote' de tarefas que podem ser executadas concorrentemente. A ordem dos lotes representa a ordem sequencial de execução. A ordem dos IDs de tarefa dentro de um lote não importa. 3. Detectar e tratar dependências circulares. Se um ciclo for encontrado, deve levantar um `ValueError` com uma mensagem descritiva. 4. Detectar e tratar casos onde um ID de dependência não corresponde a nenhuma tarefa existente. Isso também deve levantar um `ValueError`.
Programação
Limitador de Taxa com Janela Deslizante e Tolerância a Rajada
Desenhe e implemente um limitador de taxa thread-safe numa linguagem à sua escolha (Python, Go, Java, TypeScript, ou Rust) que suporte os seguintes requisitos: 1. **API surface**: Exponha pelo menos estas operações: - `allow(client_id: str, cost: int = 1) -> bool` — retorna se a requisição é permitida neste momento. - `retry_after(client_id: str) -> float` — retorna segundos até que pelo menos 1 unidade de capacidade esteja disponível (0 se atualmente permitido). - Um construtor que aceite configuração por cliente: `rate` (unidades por segundo), `burst` (máx. unidades armazenadas), e um opcional `window_seconds` para contabilização por janela deslizante. 2. **Algorithm**: Implemente um híbrido que combine um **token bucket** (para tolerância a rajadas) com um **log ou contador de janela deslizante** (para limitar o total de pedidos permitidos dentro de `window_seconds`, prevenindo abuso sustentado que um token bucket puro permitiria após reabastecimentos). Uma requisição é permitida somente se ambas as verificações passarem. Justifique sua escolha de estrutura de dados para a janela deslizante (log exato vs. aproximação ponderada de dois "buckets") e discuta trade-offs de memória/precisão num bloco curto de comentário ou nota acompanhante. 3. **Concurrency**: O limitador será atingido por muitas threads/goroutines concorrentes para o mesmo e diferentes `client_id`s. Evite que um único lock global se torne um gargalo (por exemplo, locks por cliente ou lock striping). Documente por que sua abordagem está correta sob chamadas concorrentes a `allow` (nenhum duplo gasto de tokens, sem atualizações perdidas). 4. **Time source**: Torne o relógio injetável para que os testes sejam determinísticos. Use um relógio monotônico por padrão. 5. **Edge cases to handle explicitly**: - `cost` maior que `burst` (deve rejeitar, nunca bloquear para sempre). - Relógio retrocedendo ou pausas longas (ex.: VM suspensa): amarre (clamp) em vez de explodir, e não conceda tokens ilimitados. - Primeiro pedido de um novo cliente (inicialização preguiçosa). - Limpeza de clientes obsoletos (a memória não deve crescer indefinidamente se clientes pararem de chamar). - Tokens fraccionários / temporização sub-milisegundo. 6. **Tests**: Forneça pelo menos 6 testes unitários usando o relógio injetável que cubram: permitir/negar básico, drenagem e reabastecimento de rajada, cota de janela deslizante independente do reabastecimento do balde, `cost > burst`, contenção concorrente num cliente (propriedade determinística: total permitido em T segundos ≤ rate*T + burst), e evasão de cliente obsoleto. 7. **Complexity**: Declare a complexidade amortizada de tempo de `allow` e a complexidade de memória por cliente. Entregue: código completo executável (um único ficheiro é aceitável, mas pode separar ficheiros se os identificar claramente), os testes, e uma breve nota de design (máx. ~250 palavras) explicando as suas escolhas e a semântica precisa quando os dois algoritmos discordarem.
Programação
Conversor de Subconjunto Markdown para HTML
Escreva uma função Python `markdown_to_html(markdown_text: str) -> str` que converta uma string contendo um subconjunto específico de Markdown em sua correspondente representação HTML. A função deve suportar os seguintes recursos: **Elementos de Bloco:** 1. **Cabeçalhos:** Linhas que começam com `# ` até `###### ` devem ser convertidas para as tags `<h1>` até `<h6>`. 2. **Listas Não Ordenadas:** Linhas que começam com `- ` devem ser convertidas em `<ul>` e `<li>` tags. Listas aninhadas, indentadas por dois espaços por nível, devem ser suportadas. Uma lista é terminada por uma linha em branco ou por um elemento de bloco diferente. 3. **Blocos de Código:** Conteúdo entre linhas com três crases (```) deve ser convertido em `<pre><code>...</code></pre>`. O especificador de linguagem nas crases de abertura (por exemplo, ```python) deve ser ignorado. Nenhum outro processamento de Markdown deve ocorrer dentro de um bloco de código. 4. **Parágrafos:** Qualquer outro texto deve ser envolvido em tags `<p>`. Linhas consecutivas de texto pertencem ao mesmo parágrafo. Parágrafos são separados por uma ou mais linhas em branco. **Elementos Inline:** 1. **Negrito e Itálico:** `***text***` deve ser convertido em `<strong><em>text</em></strong>`. 2. **Negrito:** `**text**` deve ser convertido em `<strong>text</strong>`. 3. **Itálico:** `*text*` deve ser convertido em `<em>text</em>`. **Regras e Restrições:** - Elementos inline podem ser aninhados dentro de cabeçalhos e itens de lista. - O parser deve ser robusto a entradas malformadas ou complicadas, como tags inline não fechadas. Por exemplo, `*italic` deve ser renderizado como `<p>*italic</p>`. - A ordem de precedência para elementos inline é `***`, depois `**`, depois `*`. - Assuma que a entrada é uma única string multilinha. - Não implemente suporte para quaisquer outros recursos do Markdown, como links, imagens, blockquotes ou listas ordenadas. - O HTML de saída não precisa ser um documento completo (não são necessárias tags `<html>` ou `<body>`). **Exemplo de Entrada:** ```markdown # Header 1 This is a paragraph with **bold** and *italic* text. This is the same paragraph. - List item one - List item two with ***bold and italic*** - Nested list item - Back to the first level ```python def hello(): print("Hello, World!") ``` ```