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

• 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

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 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...

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

Recentemente vi que o civit.ai tinha um recurso de bounty e achei que fosse bounty de bugs, mas eles deixam assim, publicamente, pedidos de implementação de funcionalidades com recompensa. Foi um conceito meio curioso. Se há dinheiro, mas falta capacidade interna, talvez faça sentido.

Eu achava que uma das razões pelas quais os EUA se tornaram uma grande potência era o fato de mestres, doutores e engenheiros brilhantes do mundo todo irem para lá cheios de sonhos, mas parece que os próprios americanos estão destruindo essa vantagem.

Dizer que se arrepende depois de ter se divertido pra caramba é dose kkk. Não é muito diferente de dizer que um jogo não foi divertido mesmo tendo mais de 1000 horas de gameplay.

É verdade que React e Java já são lixo de uma era passada, apesar de já existirem alternativas muito melhores, mas continuam dominando por tempo demais kkk

;; As pessoas que foram aos EUA para fazer mestrado ou doutorado vão ficar em uma situação complicada.

Você ainda não caiu na real, hein.

Embora se diga que há muitos indianos naturalizados, isso também não é uma boa notícia para os engenheiros coreanos.
Sinceramente, também não sei muito bem se isso realmente é algo bom para os Estados Unidos.

Entre os inúmeros tratores de duas rodas, a proposta é mirar em um de alto desempenho, né? kkk