Nesta era de excesso de informação sobre IA, o cansaço já supera a utilidade. Conselhos categóricos que beiram o viés de confirmação, textos com cara de publicidade e até conteúdos no YouTube com um tom fortemente comercial... Hoje em dia, quando todo mundo levanta a voz como se a própria opinião fosse a resposta certa, essa autoconfiança sem fundamento acaba tornando tudo ainda mais desgastante. Às vezes, dá vontade de escapar desse ruído.
Em um único PR, mudam 500 arquivos, e a pessoa que enviou ainda reclama porque não revisaram em 30 minutos. Na descrição, escreve só umas cinco ou seis linhas e pronto, então é para simplesmente confiar nisso e aprovar...?
Concordo. No passado, um PR passava a sensação de que eu assumia a responsabilidade pelo resultado que criei,
mas o PR de um vibe coder parece mais algo como: "nem sei direito o que eu fiz, mas de qualquer forma tem um resultado aí, então você que avalie e encontre os problemas".
Parece que o motivo da morte do PR não é tanto o PR em si, mas a comunicação displicente dos vibe coders.
Com qual fluxo foi implementado, que outras abordagens existiam e por que não foram adotadas, por que o package.lock precisa mudar. Não são todas coisas que deveriam ser explicadas antes?
Se dá para escrever isso na descrição do PR, parece melhor que morram os coders que fazem os outros terem que perguntar isso à força.
O Cursor Composer 1 era Qwen; esta versão parece ser baseada em Kimi. A IDE tem como base o VSCode
A estrutura da empresa inteira parece ser empacotar open source e revendê-lo. Hoje em dia, é a era de ganhar dinheiro reempacotando open source
Eita, se o time do Cursor vir isso, vai doer um pouco..
Entendo o que isso quer dizer, mas avaliar engenheiros pelo número de linhas de código sempre foi uma estupidez. Parece bem difícil encontrar uma métrica realmente boa.
Em vez de perguntar a um engenheiro com salário anual de 500 mil dólares "quantos tokens você usou?",
não deveríamos perguntar "o que você desenvolveu este ano e como isso contribuiu para o lucro operacional da empresa?"
Nesta era de excesso de informação sobre IA, o cansaço já supera a utilidade. Conselhos categóricos que beiram o viés de confirmação, textos com cara de publicidade e até conteúdos no YouTube com um tom fortemente comercial... Hoje em dia, quando todo mundo levanta a voz como se a própria opinião fosse a resposta certa, essa autoconfiança sem fundamento acaba tornando tudo ainda mais desgastante. Às vezes, dá vontade de escapar desse ruído.
Envenenamento de SEO..
Por causa disso, não consigo usar o MagicDNS do Tailscale há dias..
O Copilot é muito mais barato e melhor, então parece que não há mais motivo para usar o Cursor.
Em um único PR, mudam 500 arquivos, e a pessoa que enviou ainda reclama porque não revisaram em 30 minutos. Na descrição, escreve só umas cinco ou seis linhas e pronto, então é para simplesmente confiar nisso e aprovar...?
Testou tudo, né?
Sim
Beleza, vamos fazer direito
Não sei se chamar isso de linguagem é só para gerar polêmica ou se simplesmente chegamos a uma era assim.
Eu uso por causa do ChatGPT Pro no KakaoTalk, mas acho que todos os designs de front-end que o GPT cria são meio sem graça.
Não use gpt de jeito nenhum no frontend. É péssimo. Compare com o opus usando o mesmo prompt.
Concordo. No passado, um PR passava a sensação de que eu assumia a responsabilidade pelo resultado que criei,
mas o PR de um vibe coder parece mais algo como: "nem sei direito o que eu fiz, mas de qualquer forma tem um resultado aí, então você que avalie e encontre os problemas".
Essa sempre foi a postura original da Apple; se você não gosta disso, então o problema é com a Apple. Use outra coisa.
Acho que a pior ferramenta de desenvolvimento da história é o Xcode.
Concordo.
Como o design de front-end costuma ficar bem ruim com o GPT, pedi para outro modelo fazer, então espero que com este o resultado saia um pouco melhor.
Parece que o pencil.dev surgiu há pouco tempo, mas já apareceu uma alternativa open source.
Parece que o motivo da morte do PR não é tanto o PR em si, mas a comunicação displicente dos vibe coders.
Com qual fluxo foi implementado, que outras abordagens existiam e por que não foram adotadas, por que o
package.lockprecisa mudar. Não são todas coisas que deveriam ser explicadas antes?Se dá para escrever isso na descrição do PR, parece melhor que morram os coders que fazem os outros terem que perguntar isso à força.
"Morreu; vida longa"
Esse tipo de texto está ficando comum demais. Mas admito que a IA está mudando tudo.
Para um resumo relacionado, consulte Foi confirmado que o Cursor Composer 2 é um modelo que aplica RL ao Kimi K2.5.
Entendo o que isso quer dizer, mas avaliar engenheiros pelo número de linhas de código sempre foi uma estupidez. Parece bem difícil encontrar uma métrica realmente boa.
Em vez de perguntar a um engenheiro com salário anual de 500 mil dólares "quantos tokens você usou?",
não deveríamos perguntar "o que você desenvolveu este ano e como isso contribuiu para o lucro operacional da empresa?"