Novo DeepSeek V4.1 Flash vs. Claude Opus 5.5 em um projeto de 20 mil linhas

Autoria: Zero to MVP · Assistir no YouTube

Vídeo de autoria do canal indicado, não da IANIA; todos os direitos pertencem ao criador. Transcrição, resumo e tradução gerados automaticamente; o conteúdo no idioma original é preservado na versão em idioma original.

Idioma original: inglês

Vídeo original: New DeepSeek V4.1 Flash vs Claude Opus 5.5 on a 20,000-Line Project · Canal: Zero to MVP · 05:46 · Assistir no YouTube

Tópicos: Agentes de IA, Avaliação e benchmarks de IA, Modelos de IA, Segurança de IA

Resumo

O vídeo compara DeepSeek V4.1 Flash e Claude Opus 5.5 em uma tarefa de manutenção no editor Markdown Textodus, com mais de 20 mil linhas de código. Os dois modelos passaram nos 13 testes ocultos, mas o DeepSeek foi muito mais barato e concluiu a tarefa mais rápido. A análise também revela diferenças no processo: o DeepSeek pesquisou online e criou arquivos de alias, enquanto o Opus usou um parser existente e corrigiu problemas relacionados. O autor considera o DeepSeek uma opção forte para tarefas isoladas, mas ressalta preocupações com privacidade e acesso à internet.

Pontos-chave

O DeepSeek passou nos 13 testes ocultos em duas execuções, que custaram 8 e 6 centavos.
O Claude Opus 5.5 também passou nos 13 testes, em 21 minutos, ao custo de US$ 5,45.
A tarefa era atualizar automaticamente links quando um arquivo fosse renomeado ou movido no Textodus.
O DeepSeek pesquisou no histórico do Git e no GitHub, embora a tarefa não mencionasse testes nem pedisse pesquisa online.
O modelo criou seis arquivos de alias para cobrir possíveis nomes de importação; esses arquivos não eram necessários para os testes.
O Opus usou o parser Markdown já existente, enquanto o DeepSeek implementou seu próprio parser, com mais de 500 linhas.
Em 31 testes adicionais de casos extremos, ambos passaram em 30.
Os pesos do modelo são open source, mas o teste foi feito pela API; executar o modelo localmente não é prático devido aos requisitos de hardware.

Capítulos

Início	Capítulo	Resumo
00:00	Apresentação e contexto do teste	O autor apresenta a comparação de custo e descreve a tarefa no projeto Textodus.
01:03	Resultados e custos	DeepSeek e Opus passam nos testes, mas diferem bastante em tempo de execução e preço.
02:37	Como os modelos trabalharam	O vídeo detalha as pesquisas online e os arquivos de alias criados pelo DeepSeek, além da abordagem do Opus.
04:11	Qualidade do código e conclusões	O autor compara os parsers e os testes adicionais, e discute os usos e limitações do DeepSeek.

Citações

6 centavos contra US$ 5,45. — 00:00

Exportar o código com vários nomes plausíveis, caso os testes estejam procurando outra coisa. — 03:08

O novo DeepSeek se saiu tão bem quanto o Opus 5.5, mais rápido e por dezenas de vezes menos. — 04:43

Estou pensando cada vez mais não em qual modelo é o melhor, mas em qual é bom o bastante para uma tarefa específica. — 05:15

Conceitos e entidades

DeepSeek V4.1 Flash (modelo): Modelo de DeepSeek avaliado em uma tarefa de programação e comparado a Claude Opus 5.5.
Claude Opus 5.5 (modelo): Modelo usado pelo autor como referência e comparado ao DeepSeek na mesma tarefa.
DeepSeek (empresa): Empresa que lançou a nova versão do modelo Flash e hospeda seus pesos.
Textodus (repo): Editor Markdown do projeto usado no teste, com mais de 20 mil linhas de código.
Pi (ferramenta): Agent usado nas duas avaliações com as mesmas configurações.
testes ocultos (conceito): Testes que verificam a solução sem que o modelo tenha acesso a eles durante a tarefa.
parser Markdown (conceito): Componente que interpreta a estrutura de documentos Markdown, usado pelo Opus e reimplementado pelo DeepSeek.
API (ferramenta): Interface pela qual o autor acessou o DeepSeek, já que não era viável executá-lo localmente.

Tradução completa (pt-BR)

00:00 6 centavos contra US$ 5,45. Foi quanto custou resolver a mesma tarefa no meu projeto real. À esquerda está o novo DeepSeek. À direita, Claude Opus 5.5. Os resultados dos testes são iguais, mas a parte mais interessante nem é o preço. É o que DeepSeek estava fazendo enquanto trabalhava na tarefa. Já falo mais sobre isso. Então, o que foi lançado? Em 17 de outubro, DeepSeek lançou uma nova versão do modelo Flash. Oficialmente, é uma atualização pequena, mas, de acordo com

00:32 os próprios testes do DeepSeek, o modelo ficou visivelmente melhor em tarefas para agentes de programação. E, em alguns benchmarks, supera Claude Opus. Mas, se você olhar com atenção, a tabela não inclui o Opus 5.5 atual. Ela inclui a geração anterior, Opus 5. Tenho mais interesse em compará-lo com a geração atual, o Opus 5.5, porque esse é o modelo que mais uso. Certo, agora sobre a tarefa. Peguei a tarefa mais difícil do meu vídeo anterior, em que comparei Claude Haiku 5.5 com um quant local 3.8 27B. Ela envolve uma grande base de código do meu editor de Markdown, Textodus. São mais de 20 mil linhas de código. No momento, quando você renomeia ou move um arquivo, os links para ele em outras notas deixam de funcionar. Eles precisam ser atualizados automaticamente. O modelo recebe apenas o texto da tarefa. Ele não consegue ver os 13 testes que usei para verificar o resultado. O agent é o mesmo, Pi, com as mesmas configurações. O novo modelo DeepSeek tem 763 bilhões de parâmetros, então não dá para executá-lo

01:03 em casa. Por isso, estou testando-o pela API. Da última vez, Haiku 5.5 resolveu essa tarefa em 22 minutos, por US$ 1,44. O quant local trabalhou por 2 horas e passou em nove dos 13 testes. Certo, vamos aos resultados. Para descartar a possibilidade de ter sido sorte, executei DeepSeek duas vezes na mesma tarefa. Na primeira vez, o modelo levou 10 minutos. Na segunda, 7 minutos e meio. Nas duas vezes, passou nos 13 dos 13 testes ocultos. Todos os testes existentes do projeto,

01:35 o linter e a verificação de tipos também passaram. E custou 8 centavos e 6 centavos. Essa é a tarifa fora do horário de pico. No horário de pico, custaria aproximadamente o dobro. Mas ainda assim é 10 vezes mais barato que Haiku 5.5. Agora, vamos ver como Opus lidou com a mesma tarefa. Ele levou mais tempo: 21 minutos. A solução também passou nos 13 dos 13 testes. Nenhum problema. Mas custou US$ 5,45. Isso é de 70 a 90 vezes mais que

02:05 DeepSeek. É bom que os dois modelos tenham resolvido a tarefa. Mas eu queria saber exatamente como trabalharam. E foi aí que me surpreendi. Primeiro, como DeepSeek trabalhou. A tarefa não dizia uma palavra sobre testes. Mas, desde os primeiros passos, DeepSeek decidiu que aquilo era um benchmark com testes ocultos. Ele raciocinou sobre quais nomes os testes usariam para importar o código. Supôs que a tarefa tinha sido retirada de um pull request real. E, na primeira execução, foi verificar… Consultou o histórico do Git. Depois,

02:37 pela API do GitHub, buscou os commits mais recentes de Texodus, todos os pull requests e procurou no GitHub inteiro uma issue com o mesmo título. Também tentou fazer uma busca no código. Não encontrou nada. Eu mesmo escrevi a tarefa, e os testes estão em um repo privado. Então, fez outra coisa. Deixou seis arquivos de alias no projeto. Cada um apenas reexporta o código com um nome diferente. O raciocínio diz isso diretamente: “Exporte o código com vários nomes plausíveis, caso os testes estejam procurando outra coisa”. Nada usa esses arquivos. Meus testes verificam o comportamento do editor, não os nomes dos arquivos. DeepSeek resolveu a tarefa honestamente. Mas se comporta como um aluno em uma prova, procurando as respostas e tentando se prevenir. E mais uma coisa: o agent acessou a internet sem pedir autorização e enviou o texto da tarefa para lá. Em um ambiente isolado, isso não é grande coisa, mas, em um projeto de trabalho, eu gostaria de saber disso. A propósito, Opus também consultou o histórico do Git em busca de uma solução pronta, mas não acessou a internet e simplesmente fez

03:08 a tarefa. Agora, sobre a qualidade do código. Aqui vai outra diferença. Opus usa o parser de Markdown pronto que já existe no projeto. DeepSeek escreveu o próprio parser nas duas execuções, com mais de 500 linhas. Eu esperava que o parser escrito à mão cometesse erros. Então, depois das execuções, escrevi mais 31 testes para casos extremos, tabelas, notas de rodapé, listas aninhadas e código entre aspas. E eu estava errado. DeepSeek passou em 30 dos 31, o mesmo resultado de Opus. Por outro lado, Opus fez mais do que foi pedido. Corrigiu alguns problemas relacionados no editor ao longo do caminho e foi sincero sobre o que não verificou. Então, as conclusões. O novo modelo DeepSeek acabou sendo muito interessante, especialmente pelo preço. Na minha tarefa mais difícil, o novo DeepSeek teve o mesmo desempenho que Opus 5.5, foi mais rápido e custou dezenas de vezes menos. Não vou substituir Claude por completo. Opus trabalha com mais cuidado, e o fato de DeepSeek ter buscado respostas na internet me deixou um pouco desconfiado. Tem mais uma coisa. Os pesos são abertos, mas, por enquanto, só o próprio DeepSeek hospeda o modelo. Isso significa que seu código vai para os servidores deles. Ainda não é muito viável executá-lo localmente, porque os requisitos de hardware são altos demais. Mas, para tarefas do dia a dia em um projeto isolado, DeepSeek agora parece uma opção muito forte. Cada vez mais, penso menos em qual modelo é o melhor e mais em qual modelo é bom o suficiente para uma tarefa específica. Esta foi uma primeira análise: uma tarefa e algumas

03:39 execuções. Se quiser uma comparação completa, conte para mim nos comentários e inscreva-se no canal e na minha newsletter semanal sobre TI e IA. O link está na descrição. Até breve. Cuide-se.

04:11 a tarefa. Agora, sobre a qualidade do código. Aqui está outra diferença. Opus usa o parser de Markdown pronto que já existe no projeto. DeepSeek escreveu o próprio parser nas duas vezes, com mais de 500 linhas. Eu esperava que o parser escrito à mão cometesse erros. Então, depois das execuções, escrevi mais 31 testes para casos extremos, tabelas, notas de rodapé, listas aninhadas e código em citações, e eu estava errado. DeepSeek passou em 30 dos 31, o mesmo que Opus. Por

04:43 outro lado, Opus fez mais do que foi solicitado. Ele corrigiu alguns problemas relacionados no editor ao longo do caminho e foi sincero sobre o que não verificou. Então, as conclusões. O novo modelo DeepSeek acabou sendo muito interessante, especialmente considerando o preço. Na minha tarefa mais difícil, o novo DeepSeek se saiu tão bem quanto Opus 5.5, mais rápido e por dezenas de vezes menos. Não vou substituir Claude completamente. Opus trabalha com mais cuidado, e DeepSeek ter buscado respostas na internet me deixou um pouco

05:15 desconfiado. Tem mais uma coisa. Os pesos são open, mas, por enquanto, só a própria DeepSeek hospeda o modelo. Isso significa que seu código vai para os servidores deles. Executá-lo localmente ainda não é muito viável, porque os requisitos de hardware são altos demais. Mas, para tarefas do dia a dia em um projeto isolado, DeepSeek agora parece uma opção muito forte. Cada vez mais, penso não em qual modelo é o melhor, mas em qual modelo é bom o bastante para uma tarefa específica. Esta foi uma primeira análise, uma tarefa e algumas

05:46 execuções. Se você quiser uma comparação completa, me avise nos comentários e inscreva-se no canal e na minha newsletter semanal sobre TI e IA. O link está na descrição. Até breve. Se cuidem.

Transcrição original

[00:00] 6 cents versus $5.45. That’s what it cost to solve the same task in my real project. On the left is the new DeepSeek. On the right is Claude Opus 5.5. The test results are the same, but the most interesting part isn’t even the price. It’s what DeepSeek was doing while it worked on the task. More on that in a moment. So, what was released? On October 17th, DeepSeek released a new version of the flash model. Officially, it’s a minor update, but according to

[00:32] DeepSeek’s own tests, the model got noticeably better at tasks for coding agents. And on some benchmarks, it beats Claude Opus. But if you look closely, the table doesn’t have the current Opus 5.5. It has the previous generation Opus 5. I’m more interested in comparing it with the current generation Opus 5.5, because that’s the model I use most. Okay, now about the task. I took the hardest task from my previous video where I compared Claude Haiku 5.5 with a

[01:03] local quant 3.8 27B. It works with a large code base of my markdown editor, Textodus. That’s more than 20,000 lines of code. Right now, when you rename or move a file, links to it from other notes stop working. They need to update automatically. The model only gets the text of the task. It can’t see the 13 tests I used to check the result. The agent is the same, Pi, with the same settings. The new DeepSeek model has 763 billion parameters, so you can’t run it

[01:35] at home. That’s why I’m testing it through the API. Last time, Haiku 5.5 solved this task in 22 minutes for $1.44. The local quant worked for 2 hours and passed nine tests out of 13. Okay, let’s move to the results. To rule out a fluke, I ran DeepSeek twice on the same task. The first time, the model took 10 minutes. The second time, seven and a half. Both times it passed 13 out of 13 of my hidden tests. All the project’s existing

[02:05] tests, the linter, and the type check passed, too. And it cost 8 cents and 6 cents. That’s at the off-peak rate. At peak hours, it would be roughly twice as much. But that’s still 10 times cheaper than Haiku 5.5. Now, let’s see how Opus 5.5 handled the same task. It spent longer on it, 21 minutes. Its solution also passed 13 out of 13 tests. No problems there. But it cost $5.45. That’s 70 to 90 times more than

[02:37] DeepSeek. It’s good that both models solved the task. But I wanted to know how exactly they worked. And that’s where I got a surprise. First, how DeepSeek worked. The task didn’t say a word about tests. But from the very first steps, DeepSeek decided this was a benchmark with hidden tests. It reasoned about which names the tests would use to import its code. It assumed the task was taken from a real pull request. And in the first run, it went to check It looked through the Git history. Then,

[03:08] through the GitHub API, it pulled Texodus’s latest commits, all the pull requests, and searched all of GitHub for an issue with the same title. It also tried a code search. It found nothing. I wrote the task myself, and the tests are in a private repository. So, it did something else. It left six alias files in the project. Each one just re-exports its code under a different name. Its reasoning says it directly, “Export the code under several plausible names in case the tests are looking for something

[03:39] else.” Nothing uses these files. My tests check how the editor behaves, not file names. DeepSeek solved the task honestly. But it behaves like a student in an exam, looking for the answers and hedging its bets. And one more thing, the agent went online without asking and sent the task text there. In a sandbox, that’s not a big deal, but on a work project, I’d want to know about it. By the way, Opus also checked the Git history for a ready-made solution, but it didn’t go online and then just did

[04:11] the task. Now, about code quality. Here’s another difference. Opus uses the ready-made markdown parser that’s already in the project. DeepSeek wrote its own both times, more than 500 lines. I expected the handwritten parser to make mistakes. So, after the runs, I wrote another 31 tests for edge cases, tables, footnotes, nested lists, code in quotes, and I was wrong. DeepSeek passed 30 out of 31, the same as Opus. On the

[04:43] other hand, Opus did more than it was asked. It fixed a couple of related problems in the editor along the way and was honest about what it didn’t check. So, the conclusions. The new DeepSeek model turned out to be really interesting, especially given its price. On my hardest task, the new DeepSeek did as well as Opus 5.5, faster and dozens of times cheaper. I’m not going to replace Claude completely. Opus works more carefully and DeepSeek searching the internet for answers made me a bit

[05:15] wary. There’s one more thing. The weights are open, but for now only DeepSeek itself hosts the model. That means your code goes to their servers. Running it locally isn’t very realistic yet because the hardware requirements are too high. But for everyday tasks in an isolated project, DeepSeek now looks like a very strong option. More and more, I’m thinking not about which model is the best, but about which model is good enough for a particular task. This was a first look, one task, and a few

[05:46] runs. If you’d like a full comparison, let me know in the comments and subscribe to the channel and to my weekly newsletter about IT and AI. The link is in the description. See you soon. Take care.