Eu também não fumo, então não sabia disso, mas descobri recentemente ao ver uma máquina de venda de cigarros eletrônicos descartáveis em um café autônomo que abriu no meu bairro há pouco tempo. Metade dos comentários no Hacker News abaixo também fala sobre o desperdício absurdo de recursos, haha.
Isso me faz lembrar dos tempos, lá no fim dos anos 2000, quando eu trabalhava numa empresa de software de navegação veicular desenvolvendo um módulo de busca de rotas.
O Dijkstra é lento demais para busca de rotas em navegação, então não se usa; em vez disso, usa-se o A* (A Star), uma versão aprimorada com heurística. Fui pesquisar e vi que o A* não é um algoritmo de SSSP, e sim de SPSP (Single-Pair Shortest Path).
O markitdown é prático para converter entre formatos, mas com PDF não dá para usar de jeito nenhum.
Já existem muitos métodos de extração de documentos usando LLMs multimodais como o Gemini, e nos benchmarks eles também têm um desempenho bem bom. O problema é o custo.
De baixo nível... quer dizer... para implementar formulários, algo que daria para resolver só usando a tag input do HTML acaba exigindo saber um monte de coisas desnecessárias, como state, JSX, componentes controlados/não controlados, além de gerar muito código, então imagino que esse tenha sido o motivo do texto.
Parece como dizer que, só porque surgiu um novo jeito, o método antigo morreu.
Isso realmente significa que o método antigo não pode mais ser usado e que é obrigatório usar o novo?
Concordei bastante com o conceito, então fiz alguns testes no fim de semana com um projeto novo, mas não funcionou tão bem quanto eu esperava. Acho que ainda precisa de muitas melhorias. Por enquanto, o fluxo geral parece ser mais ou menos o seguinte, como já foi apresentado várias vezes:
redigir a constituição → redigir a especificação → redigir as tarefas → implementar
O problema é que
o arquivo constitution.md é o guia central sobre "como desenvolver", mas não contém "o que este app será no final"
spec.md é um documento que descreve uma funcionalidade
não existe um documento mestre sobre "o que é este app"
lendo as discussões no GitHub, parece que a ideia é que a chain of specs acabe se tornando a source of truth. Fiquei meio desconfiado, mas deu para entender mais ou menos.
os comandos /specify e /tasaks geram muitos documentos como resultado (que era o que eu queria), e por isso o contexto é consumido rapidamente (estou usando Claude Code)
quando a implementação de fato começa, você acaba se afastando um pouco do Spec Kit e termina a implementação conversando com o Claude Code como de costume
quando todo o contexto é consumido e acontece a compactação, ou quando você inicia uma nova sessão, ele esquece que os documentos gerados pelo Spec Kit existem
ao executar as tarefas definidas em tasks.md, às vezes você sobrescreve algo que tinha feito corretamente antes, e no processo de corrigir bugs acaba criando novas funcionalidades, então vai se afastando cada vez mais do tasks.md. Não vejo muito sentido em manter tasks.md permanentemente.
Por enquanto, a conclusão a que cheguei é a seguinte:
mesmo que o resultado saia diferente do que foi pensado no início, é melhor concluir a especificação primeiro e depois criar novas especificações para ir ajustando aos poucos
a especificação inicial inevitavelmente vai ficar grande, então talvez seja melhor não explicar as funcionalidades do app e criar apenas o boilerplate
ao fazer algo em nível de PoC, é melhor não usar o Spec Kit
Concordo muito. Por melhor que seja, algo que interfere acaba sendo incômodo. O ideal é que esteja ali quase como se não existisse e apareça para ajudar quando parecer necessário, e a questão principal provavelmente é o quão adequada é essa capacidade de avaliar a situação. Com as pessoas também há quem faça isso bem e quem não faça, então, se a inteligência artificial conseguir superar isso, acho que teremos uma revolução.
Para ser mais preciso sobre o Vulkan, o correto é dizer que "a API Vulkan suportada pela iGPU do Pi 5 ainda não é compatível no llama.cpp". Fico curioso para saber que desempenho teria saído se isso tivesse sido suportado.
O markitdown usa isto para fazer o parsing de PDF: https://github.com/pdfminer/pdfminer.six, e extrai diretamente do arquivo o texto ou as imagens incorporadas. Falar em OCR já até dá tontura...
Para quem precisa de prompts em coreano, aqui estão prompts traduzidos para o coreano. Basta clicar e eles são inseridos imediatamente no ChatGPT e no Claude.
Quando eram só um ou dois anúncios de 5 segundos, eu assistia tudo com a mentalidade de convivência mútua, mas aí começaram a exagerar com anúncios em sequência sem fim e colocando propaganda no meio do vídeo, então instalei um ad blocker na hora, haha
Eu também não fumo, então não sabia disso, mas descobri recentemente ao ver uma máquina de venda de cigarros eletrônicos descartáveis em um café autônomo que abriu no meu bairro há pouco tempo. Metade dos comentários no Hacker News abaixo também fala sobre o desperdício absurdo de recursos, haha.
Isso me faz lembrar dos tempos, lá no fim dos anos 2000, quando eu trabalhava numa empresa de software de navegação veicular desenvolvendo um módulo de busca de rotas.
O Dijkstra é lento demais para busca de rotas em navegação, então não se usa; em vez disso, usa-se o A* (A Star), uma versão aprimorada com heurística. Fui pesquisar e vi que o A* não é um algoritmo de SSSP, e sim de SPSP (Single-Pair Shortest Path).
Falando como alguém que já fez isso, para personalização é necessária uma quantidade de informação que pode passar de 2 gigabytes.
O
markitdowné prático para converter entre formatos, mas com PDF não dá para usar de jeito nenhum.Já existem muitos métodos de extração de documentos usando LLMs multimodais como o Gemini, e nos benchmarks eles também têm um desempenho bem bom. O problema é o custo.
Algo como o
doclingtambém é bom.Parece ter funcionalidades e abordagem parecidas com o Atlas: https://atlasgo.io/
Eu me identifico muito com essas três armadilhas principais. Mesmo ter apenas um gatekeeper já acaba gerando vários problemas.
De baixo nível... quer dizer... para implementar formulários, algo que daria para resolver só usando a tag
inputdo HTML acaba exigindo saber um monte de coisas desnecessárias, como state, JSX, componentes controlados/não controlados, além de gerar muito código, então imagino que esse tenha sido o motivo do texto.Como eu não fumo, não entendi do que se tratava de início, mas a questão é que, apesar de serem descartáveis, usam recursos demais, certo?
A imponência de um karma de -47 kkk
Parece como dizer que, só porque surgiu um novo jeito, o método antigo morreu.
Isso realmente significa que o método antigo não pode mais ser usado e que é obrigatório usar o novo?
Concordei bastante com o conceito, então fiz alguns testes no fim de semana com um projeto novo, mas não funcionou tão bem quanto eu esperava. Acho que ainda precisa de muitas melhorias. Por enquanto, o fluxo geral parece ser mais ou menos o seguinte, como já foi apresentado várias vezes:
redigir a constituição → redigir a especificação → redigir as tarefas → implementar
O problema é que
constitution.mdé o guia central sobre "como desenvolver", mas não contém "o que este app será no final"spec.mdé um documento que descreve uma funcionalidade/specifye/tasaksgeram muitos documentos como resultado (que era o que eu queria), e por isso o contexto é consumido rapidamente (estou usando Claude Code)tasks.md, às vezes você sobrescreve algo que tinha feito corretamente antes, e no processo de corrigir bugs acaba criando novas funcionalidades, então vai se afastando cada vez mais dotasks.md. Não vejo muito sentido em mantertasks.mdpermanentemente.Por enquanto, a conclusão a que cheguei é a seguinte:
kkkkkkkkkkk
Concordo muito. Por melhor que seja, algo que interfere acaba sendo incômodo. O ideal é que esteja ali quase como se não existisse e apareça para ajudar quando parecer necessário, e a questão principal provavelmente é o quão adequada é essa capacidade de avaliar a situação. Com as pessoas também há quem faça isso bem e quem não faça, então, se a inteligência artificial conseguir superar isso, acho que teremos uma revolução.
Para ser mais preciso sobre o Vulkan, o correto é dizer que "a API Vulkan suportada pela iGPU do Pi 5 ainda não é compatível no
llama.cpp". Fico curioso para saber que desempenho teria saído se isso tivesse sido suportado.O docling também é bom
Uau! Um cortador ultrassônico!
O
markitdownusa isto para fazer o parsing de PDF: https://github.com/pdfminer/pdfminer.six, e extrai diretamente do arquivo o texto ou as imagens incorporadas. Falar em OCR já até dá tontura...Parece ser mais caro e mais lento que o gpt-oss, então fico curioso para saber por que tanta gente está usando..
Para quem precisa de prompts em coreano, aqui estão prompts traduzidos para o coreano. Basta clicar e eles são inseridos imediatamente no ChatGPT e no Claude.
https://gongbuhow.com/posts/chatgpt-students-100-use-cases/
Quando eram só um ou dois anúncios de 5 segundos, eu assistia tudo com a mentalidade de convivência mútua, mas aí começaram a exagerar com anúncios em sequência sem fim e colocando propaganda no meio do vídeo, então instalei um ad blocker na hora, haha