Como houve erros demais, pelo visto eles acabaram publicando um aviso às pressas.
Mas também fico pensando se não demoraram demais...
Já estão dizendo que houve tantos erros que todo mundo está abandonando a plataforma ;_;
As pessoas dizem coisas desse tipo, que não conseguem confiar só porque é chinês, mas eu realmente sou grato à DeepSeek pelo menos por seguir pesquisando e abrindo seu trabalho, e até por divulgar os erros e tentativas no processo.
Colocamos uma fase de revisão cruzada com o Codex dentro do fluxo de slash command (no /ship, algo como planejamento → implementação → validação → revisão do Codex → relatório) e, ao mesmo tempo, também aplicamos a mesma revisão no pre-push hook. Se deixar só o slash command, na correria a pessoa simplesmente faz o push e a revisão acaba sendo pulada; se deixar só o hook, o resultado só aparece imediatamente antes do push, tarde demais.
Em ambos os caminhos, em vez de chamar o Codex CLI diretamente, os dois lados invocam da mesma forma um único script bash encapsulado (codex-review.sh). Esse script centraliza timeout, verificação de autenticação, checagem de secrets e formato de saída, então tanto no slash command quanto no hook o lado que chama fica mais limpo.
O ponto principal é que nunca bloqueamos com base no resultado da revisão do Codex. Mesmo que a CLI caia ou apareça um CRITICAL, o push continua passando e só exibimos o resultado. Se isso virar bloqueio uma única vez, quando o Codex marcar por engano um código que na prática não tem problema, o usuário vai recorrer à opção de contornar o hook para conseguir fazer push (git push --no-verify), e, quando isso vira hábito, é praticamente o mesmo que ter um hook configurado que nunca roda. Por isso, as verificações que realmente precisam bloquear (lint, tipos, testes, push de arquivos com secrets) ficam separadas em outros gates, e a opinião do modelo fica só como referência.
Os trechos do script, do slash command e do corpo do hook estão incluídos integralmente nos capítulos 4 a 6 do track, então talvez valha a pena consultar.
Ouvi dizer que há pessoas que fazem assim, mas fico curioso sobre como seria na prática.
Se o desenvolvedor chama cada um diretamente quando precisa, sem agrupar as duas ferramentas como agentes separados,
ou se configuram para que o Codex faça a revisão automaticamente ao usar Git Hook.
Ultimamente a Meta estava parecendo um pouco menos nojenta, mas isso já recarrega minha indignação contra a Meta.
Mudando um pouco de assunto, também rolou um papo de que esses lockdowns de OS de hoje em dia foram lobby da Meta... desde a história de fundação até cada passo da empresa, parece mesmo que venderam qualquer noção de ética.
Os provedores de LLM tendem a coletar e treinar por padrão, para melhorar o modelo, os dados dos "serviços para consumidores" que usuários comuns usam gratuitamente ou por assinatura. Em contrapartida, os dados de APIs ou serviços corporativos, usados por empresas ou desenvolvedores mediante pagamento, na maioria dos casos são protegidos por contrato para não serem usados no treinamento.
Aqui, porém, é preciso apontar uma questão importante. A dúvida fundamental é: "um produto pago realmente não usa meus dados para treinamento de forma alguma?"
Os serviços corporativos da OpenAI deixam explícito em contrato que os dados não são usados para treinamento, mas como esse "compromisso" pode ser verificado tecnicamente e garantido do ponto de vista legal/institucional? No momento, como não podemos monitorar diretamente o pipeline de treinamento da OpenAI, isso acaba sendo uma área que depende inteiramente da ética do provedor e do contrato.
A mesma pergunta — "não existe o risco de meus dados serem incorporados ao conhecimento do modelo?" — não é um problema exclusivo da DeepSeek, e seguimos sem uma solução perfeita além de "comprar" condições contratuais mais seguras conforme o orçamento e a necessidade (por exemplo, API, plano corporativo) ou, para garantir integridade técnica total, hospedar o modelo diretamente por conta própria.
Dizer que "por ser um LLM chinês ele automaticamente rouba dados pessoais" é um exagero, e o risco estrutural ligado ao uso de dados não é tão diferente nos LLMs americanos. O importante é analisar com cuidado o tipo de serviço e as condições contratuais, pagar para proteger nossos dados ou escolher alternativas técnicas (como hospedagem própria).
Eu também pedi reembolso...
Os créditos de IA também não acumulam... e aplicarem uso de tokens e tempo de uso (a parte gasta quando está em Think) sem um critério claro...
Então que fizessem cobrança por consumo...
Se vão cobrar pelo uso, pelo menos deveriam definir um prazo de validade e permitir rollover...
Sendo assim, não vejo motivo para usar...
Qual é a vantagem disso ser melhor que ChatGPT, Claude ou Gemini...?
Eu usava no plano anual, não como principal, mas de vez em quando... e isso parece uma baita punhalada pelas costas. Para usuários anuais, no mínimo deveriam manter o preço antigo até o fim do período de validade, mas se de repente aumentam o preço e ainda apertam mais o limite de uso...
Parece que esqueceram o significado de pagamento anual...
Você paga adiantado de uma vez, em troca de um pouco mais de promoção e da fidelização do cliente durante aquele período...
Sai a cada trimestre.
Com certeza, já havia bastante IA em YC's Requests for Startups - Summer 2025,
mas neste ano parece que a aplicação de IA se aproximou ainda mais do lado vertical e enterprise.
Como houve erros demais, pelo visto eles acabaram publicando um aviso às pressas. Mas também fico pensando se não demoraram demais... Já estão dizendo que houve tantos erros que todo mundo está abandonando a plataforma ;_;
As pessoas dizem coisas desse tipo, que não conseguem confiar só porque é chinês, mas eu realmente sou grato à DeepSeek pelo menos por seguir pesquisando e abrindo seu trabalho, e até por divulgar os erros e tentativas no processo.
Vai ser bom para quando delegar o front-end para a IA, obrigado por compartilhar.
Nós acabamos nos estabelecendo no uso dos dois.
Colocamos uma fase de revisão cruzada com o Codex dentro do fluxo de slash command (no
/ship, algo como planejamento → implementação → validação → revisão do Codex → relatório) e, ao mesmo tempo, também aplicamos a mesma revisão nopre-push hook. Se deixar só o slash command, na correria a pessoa simplesmente faz o push e a revisão acaba sendo pulada; se deixar só o hook, o resultado só aparece imediatamente antes do push, tarde demais.Em ambos os caminhos, em vez de chamar o Codex CLI diretamente, os dois lados invocam da mesma forma um único script bash encapsulado (
codex-review.sh). Esse script centraliza timeout, verificação de autenticação, checagem de secrets e formato de saída, então tanto no slash command quanto no hook o lado que chama fica mais limpo.O ponto principal é que nunca bloqueamos com base no resultado da revisão do Codex. Mesmo que a CLI caia ou apareça um CRITICAL, o push continua passando e só exibimos o resultado. Se isso virar bloqueio uma única vez, quando o Codex marcar por engano um código que na prática não tem problema, o usuário vai recorrer à opção de contornar o hook para conseguir fazer push (
git push --no-verify), e, quando isso vira hábito, é praticamente o mesmo que ter um hook configurado que nunca roda. Por isso, as verificações que realmente precisam bloquear (lint, tipos, testes, push de arquivos com secrets) ficam separadas em outros gates, e a opinião do modelo fica só como referência.Os trechos do script, do slash command e do corpo do hook estão incluídos integralmente nos capítulos 4 a 6 do track, então talvez valha a pena consultar.
Ouvi dizer que há pessoas que fazem assim, mas fico curioso sobre como seria na prática.
Se o desenvolvedor chama cada um diretamente quando precisa, sem agrupar as duas ferramentas como agentes separados,
ou se configuram para que o Codex faça a revisão automaticamente ao usar Git Hook.
Ai, meu Deus...
Ultimamente a Meta estava parecendo um pouco menos nojenta, mas isso já recarrega minha indignação contra a Meta.
Mudando um pouco de assunto, também rolou um papo de que esses lockdowns de OS de hoje em dia foram lobby da Meta... desde a história de fundação até cada passo da empresa, parece mesmo que venderam qualquer noção de ética.
Os provedores de LLM tendem a coletar e treinar por padrão, para melhorar o modelo, os dados dos "serviços para consumidores" que usuários comuns usam gratuitamente ou por assinatura. Em contrapartida, os dados de APIs ou serviços corporativos, usados por empresas ou desenvolvedores mediante pagamento, na maioria dos casos são protegidos por contrato para não serem usados no treinamento.
Aqui, porém, é preciso apontar uma questão importante. A dúvida fundamental é: "um produto pago realmente não usa meus dados para treinamento de forma alguma?"
Os serviços corporativos da OpenAI deixam explícito em contrato que os dados não são usados para treinamento, mas como esse "compromisso" pode ser verificado tecnicamente e garantido do ponto de vista legal/institucional? No momento, como não podemos monitorar diretamente o pipeline de treinamento da OpenAI, isso acaba sendo uma área que depende inteiramente da ética do provedor e do contrato.
A mesma pergunta — "não existe o risco de meus dados serem incorporados ao conhecimento do modelo?" — não é um problema exclusivo da DeepSeek, e seguimos sem uma solução perfeita além de "comprar" condições contratuais mais seguras conforme o orçamento e a necessidade (por exemplo, API, plano corporativo) ou, para garantir integridade técnica total, hospedar o modelo diretamente por conta própria.
Dizer que "por ser um LLM chinês ele automaticamente rouba dados pessoais" é um exagero, e o risco estrutural ligado ao uso de dados não é tão diferente nos LLMs americanos. O importante é analisar com cuidado o tipo de serviço e as condições contratuais, pagar para proteger nossos dados ou escolher alternativas técnicas (como hospedagem própria).
O GitHub anda com muitos problemas ultimamente.
Está incluído
O código pode ser considerado objeto de proteção?
É uma pena que não ofereça suporte a
fallback font, então a exibição em coreano deixa a desejar.Eu também pedi reembolso...
Os créditos de IA também não acumulam... e aplicarem uso de tokens e tempo de uso (a parte gasta quando está em
Think) sem um critério claro...Então que fizessem cobrança por consumo...
Se vão cobrar pelo uso, pelo menos deveriam definir um prazo de validade e permitir rollover...
Sendo assim, não vejo motivo para usar...
Qual é a vantagem disso ser melhor que ChatGPT, Claude ou Gemini...?
Eu usava no plano anual, não como principal, mas de vez em quando... e isso parece uma baita punhalada pelas costas. Para usuários anuais, no mínimo deveriam manter o preço antigo até o fim do período de validade, mas se de repente aumentam o preço e ainda apertam mais o limite de uso...
Parece que esqueceram o significado de pagamento anual...
Você paga adiantado de uma vez, em troca de um pouco mais de promoção e da fidelização do cliente durante aquele período...
É legal, mas quando tento usar depois de ter usado um terminal comum, fica engasgando demais e acabo deixando de lado.
Se o modelo for bom, a carga do projeto de chicotes também diminui.
Sai a cada trimestre.
Com certeza, já havia bastante IA em YC's Requests for Startups - Summer 2025,
mas neste ano parece que a aplicação de IA se aproximou ainda mais do lado vertical e enterprise.
Quem já tinha migrado para outro lugar (como o Codeberg) provavelmente vai se convencer ainda mais, vendo esse caso, de que fez muito bem em se mudar.
Fiz a correção.
Obrigado. Precisa ser corrigido.
O Sr. No Seong-hoon → Sr. Kim Seong-hyeon.