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: a família GPT-5 domina o topo, quase sempre com poucas amostras
OpenAI
OpenAI
OpenAI
Pontuacao media por modelo
Como ponderamos
Em 32 respostas de programação avaliadas, os três primeiros lugares são da família GPT-5. O GPT-5.5 ocupa o 1.º lugar com média de 8,85 e registo perfeito, mas isso assenta numa única amostra, por isso leia-o como um sinal promissor e não como um resultado consolidado. O melhor desempenho com base sólida é o GPT-5 mini no 2.º lugar: 8,22 em 5 amostras, 5 primeiros lugares e 100 % de vitórias, uma varredura limpa a custo de gama leve.
A média e a ordem divergem, porque a taxa de vitórias (primeiros lugares diretos) pesa mais do que a média bruta. O GPT-5.4 tem média de 8,41 em 8 amostras, o maior volume de evidência aqui, com 75 % de vitórias e o 3.º lugar. O Gemini 2.5 Pro regista a mesma média de 8,41 mas fica em 5.º, porque não venceu nenhum dos seus 3 confrontos. Se valoriza a qualidade absoluta mais do que quem vence diretamente, GPT-5.4 e Gemini 2.5 Pro estão mais próximos do que a posição sugere.
O meio da tabela é liderado pelo Claude Sonnet 4.6 (média 7,7, 50 % em 4 amostras), atrás do grupo GPT-5 por cerca de 0,5 a 1,1 pontos. As gamas mais leves ficam abaixo: Gemini 2.5 Flash (7,31), Flash-Lite (7,17) e Claude Haiku 4.5 (6,48) estão a 1,5–2,4 pontos do líder. Com a Correção no peso máximo (35), à frente de Qualidade de código e Completude (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 GPT-5.5 assenta em 1 amostra e a maioria está entre 3 e 8, por isso as médias podem oscilar com alguns prompts. A diferença de 2,37 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, Gemini 2.5 Pro) 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 (100 % de vitórias em 5 amostras a custo de gama leve), enquanto o GPT-5.4 é a opção de gama alta mais bem evidenciada (8,41 em 8 amostras). Veja a liderança de uma só amostra do GPT-5.5 como promissora, mas não comprovada.
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: 12 Jun 2026 09:39
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 | GPT-5 mini | OpenAI |
100%
|
82
|
5 | 5 | Ver a avaliacao e a pontuacao de GPT-5 mini |
| #2 | GPT-5.4 | OpenAI |
75%
|
84
|
6 | 8 | Ver a avaliacao e a pontuacao de GPT-5.4 |
| #3 | GPT-5.5 | OpenAI |
50%
|
89
|
1 | 2 | Ver a avaliacao e a pontuacao de GPT-5.5 |
| #4 | Claude Sonnet 4.6 | Anthropic |
50%
|
77
|
2 | 4 | Ver a avaliacao e a pontuacao de Claude Sonnet 4.6 |
| #5 | Gemini 2.5 Pro |
0%
|
84
|
0 | 3 | Ver a avaliacao e a pontuacao de Gemini 2.5 Pro | |
| #6 | Gemini 2.5 Flash |
0%
|
73
|
0 | 4 | Ver a avaliacao e a pontuacao de Gemini 2.5 Flash | |
| #7 | Gemini 2.5 Flash-Lite |
0%
|
72
|
0 | 3 | Ver a avaliacao e a pontuacao de Gemini 2.5 Flash-Lite | |
| #8 | Claude Haiku 4.5 | Anthropic |
0%
|
65
|
0 | 4 | Ver a avaliacao e a pontuacao de Claude Haiku 4.5 |
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
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!") ``` ```
Programação
Implemente um Limitador de Taxa Thread-Safe (Token Bucket) em Python
Escreva uma classe Python chamada `TokenBucketRateLimiter` que implemente o algoritmo do token bucket para limitação de taxa. A implementação deve ser thread-safe e não deve usar bibliotecas externas para gerenciamento de estado (como Redis). A classe deve ter as seguintes especificações: 1. Um método `__init__(self, capacity, refill_rate)`: * `capacity`: O número máximo de tokens que o balde pode conter. * `refill_rate`: O número de tokens que são adicionados ao balde por segundo. 2. Um método `consume(self, tokens)`: * Este método tenta consumir um número dado de `tokens` do balde. * Deve retornar `True` se os tokens puderem ser consumidos com sucesso, e `False` caso contrário. * O balde deve ser reabastecido com tokens com base no tempo decorrido desde a última chamada antes de tentar consumir. 3. Segurança de Threads: * A classe deve ser segura para uso por múltiplas threads concorrentes. Todas as operações que modificam o estado do balde (como reabastecer e consumir tokens) devem ser atômicas. Forneça a implementação completa da classe com os imports necessários.
Programação
Ferramenta de Sincronização de Arquivos por Linha de Comando
Escreva um script Python para uma ferramenta de sincronização de arquivos por linha de comando. O script deve aceitar três argumentos de linha de comando: 1. `source_path`: O caminho para o diretório fonte. 2. `replica_path`: O caminho para o diretório réplica que será sincronizado. 3. `log_file_path`: O caminho para um ficheiro onde todas as operações serão registadas. Funcionalidade Principal: 1. **Sincronização Unidirecional:** A ferramenta deve executar uma sincronização unidirecional, fazendo com que o diretório `replica_path` seja uma cópia exata do diretório `source_path`. - Ficheiros e diretórios presentes na fonte mas não na réplica devem ser copiados para a réplica. - Ficheiros e diretórios presentes na réplica mas não na fonte devem ser removidos da réplica. - Ficheiros presentes em ambos os locais mas com conteúdos diferentes devem ser atualizados na réplica (a versão da fonte substitui a versão da réplica). 2. **Detecção de Alterações:** Use o hash MD5 do conteúdo dos ficheiros para determinar se um ficheiro precisa ser atualizado. Não confie em carimbos de data/hora de modificação. 3. **Registo:** Registe todas as operações de ficheiros (por exemplo, "COPY file.txt", "REMOVE old_dir", "UPDATE changed.log") tanto no console como no ficheiro de registo especificado. Cada entrada de registo deve ser marcada com data e hora. 4. **Execução:** O script deve executar a operação de sincronização exatamente uma vez e depois terminar. Não deve correr em loop. Requisitos: - Use Python 3. - Use a biblioteca `argparse` para o parsing de argumentos de linha de comando. - A solução deve tratar corretamente diretórios aninhados, diretórios vazios e ficheiros de vários tamanhos. - O script deve ser um único ficheiro autocontido.
Programação
Implemente um cache LRU concorrente sem bloqueios
Implemente um cache LRU (Least Recently Used) seguro para uso por múltiplas threads em Python que suporte leituras e gravações concorrentes sem usar um bloqueio global para cada operação. Sua implementação deve satisfazer os seguintes requisitos: 1. **Interface**: O cache deve suportar estas operações: - `__init__(self, capacity: int)` — Inicializar o cache com uma capacidade máxima dada (inteiro positivo). - `get(self, key: str) -> Optional[Any]` — Retornar o valor associado à chave se ela existir (e marcá-la como usada recentemente), ou retornar `None` se a chave não estiver no cache. - `put(self, key: str, value: Any) -> None` — Inserir ou atualizar o par chave-valor. Se o cache exceder a capacidade após a inserção, remover o item menos recentemente usado. - `delete(self, key: str) -> bool` — Remover a chave do cache. Retornar `True` se a chave estava presente, `False` caso contrário. - `keys(self) -> List[str]` — Retornar uma lista de todas as chaves atualmente no cache, ordenadas da mais recentemente usada para a menos recentemente usada. 2. **Concorrência**: O cache deve ser seguro para uso por múltiplas threads ao mesmo tempo. Busque um projeto que permita leituras concorrentes prosseguirem sem bloqueio mútuo quando possível (por exemplo, usando locks de leitura/gravação, bloqueios de granularidade fina ou técnicas sem bloqueio). Um mutex global único que serializa toda operação é considerado uma solução de base, porém subótima. 3. **Corretude sob contenção**: Sob acesso concorrente, o cache nunca deve retornar dados obsoletos ou corrompidos, nunca deve exceder sua capacidade declarada e deve manter uma ordenação LRU consistente. 4. **Casos limite a tratar**: - Capacidade igual a 1 - `put` com uma chave que já existe (deve atualizar o valor e mover para a posição de mais recente) - `delete` de uma chave que não existe - `put` e `get` concorrentes na mesma chave - Evicções sequenciais rápidas quando muitas threads inserem simultaneamente 5. **Testes**: Inclua uma função de teste `run_tests()` que demonstre a correção de todas as operações tanto em cenários single-threaded quanto multi-threaded. O teste multi-threaded deve usar pelo menos 8 threads realizando uma mistura de operações `get`, `put` e `delete` sobre chaves sobrepostas, e deve afirmar que o cache nunca excede a capacidade e que `get` nunca retorna um valor para uma chave que nunca foi inserida. Forneça sua implementação completa em Python. Use apenas a biblioteca padrão (nenhum pacote de terceiros). Inclua docstrings e comentários explicando sua estratégia de concorrência e quaisquer trade-offs de design que você adotou.