Embora a mensagem do autor tenda a ser um tanto forte, se você ler o texto com atenção, não é “não use IA”. Há uma proposta sobre como utilizá-la, e o ponto principal é a mensagem de que o próprio desenvolvedor não pode carecer de competência.
Se formos ver por que a mensagem do autor soa tão forte, ela foi construída como uma resposta à visão de que será possível desenvolver com o Copilot (com a nuance de uma alta dependência de desenvolvimento em relação ao Copilot). Nesse contexto, ele conduziu a mensagem no sentido de não adotar uma postura que prejudique, para os próprios desenvolvedores, o valor da sua existência.
Como o autor também não está passando a mensagem de “não use IA”, no fim, se a ideia é aproveitar a IA, isso acabará ficando em algum ponto de equilíbrio; por isso, a mensagem ficou, em linhas gerais, parecida com o que você respondeu há pouco.
No entanto, tive dificuldade em concordar com a parte de “visão tendenciosa” no que você escreveu inicialmente, então quis responder primeiro sobre isso.
Criar é só o começo, e depois de operar um serviço por uns 10 anos, todo tipo de coisa vai acontecer no meio do caminho; para aguentar firme nessa hora, é preciso ter uma base... é preciso aprender.
Primeiro, no que eu disse sobre "usar IA dentro do domínio", é claro que o design e a coordenação ficam a cargo dos humanos...
Na verdade, isso talvez fosse algo a se dizer antigamente, mas hoje, quando todo mundo já conhece as limitações dos LLMs, virou algo tão óbvio que nem precisa ser mencionado.
Em seguida, sobre o caso de pessoas comuns sem conhecimento de desenvolvimento usarem LLMs,
acho que nem o texto principal, nem o Hacker News, nem eu chegamos a falar disso, mas, de qualquer forma, mesmo nesse caso a tecnologia já chegou a um nível em que os usuários ficam satisfeitos com o resultado.
Se não fosse assim, Bolt.new, v0 e até o Cursor não estariam recebendo a avaliação que têm hoje.
É difícil tomar a decisão sobre até onde reinventar e até onde depender de dependências externas.
Seja qual for o caso, escolher essa dependência para economizar tempo porque eu mesmo poderia fazer isso, e ficar preso a uma dependência porque sem ela não é possível criar o serviço, são histórias completamente diferentes.
Talvez isso não seja possível para todo tipo de código (como um sistema operacional), mas fazer o esforço para ir o máximo possível na direção da primeira opção vai ajudar a entender o sistema.
Acho que há um pequeno mal-entendido sobre o sentido que o autor quis transmitir.
O foco do autor está no desempenho, na estabilidade e em uma arquitetura e consistência de código que facilitem a manutenção dos projetos que ele gerencia, e, em especial, arquitetura e consistência de código são justamente áreas em que os LLMs atuais realmente não são bons.
Especialmente na web, há muita gente entrando em desenvolvimento e uma mentalidade forte de "se funcionar de qualquer jeito, está bom", então uma quantidade enorme de código de baixa qualidade acaba sendo colocada em produção. E como os LLMs foram treinados com base nisso, a qualidade do que eles geram cai a um nível absurdamente ruim.
Simplesmente peça ao GPT: "vou colocar isso no front-end web, então implemente um algoritmo quicksort em JS para mim". Se você não conseguir identificar os problemas na saída, acho que esta conversa não tem muito sentido.
> Pelo que vi em posts antigos do autor, parece que ele é desenvolvedor de jogos
> Como LLMs não conseguem aprender em grande volume conhecimento ou materiais de desenvolvimento de jogos, ao contrário dos casos de apps CRUD, parece que o autor do texto sente mais claramente as limitações dos LLMs
Li tudo, e no fim acho que o autor acabou ficando com uma visão um pouco enviesada por causa disso.
Claro, fazer como o texto principal diz é algo quase didático e está correto,
mas acho que IA já faz bem o suficiente em CRUD e front-end, onde há muito material para treinar.
Parece que o ideal é aproveitar ao máximo dentro do próprio domínio.
O item 1 é realmente uma mudança digna de pesadelo, algo que eu jamais gostaria de aceitar. É como ver o rastreamento do histórico do código-fonte se tornar sem sentido.
Pedi ao bot de IA do GN+ para extrair o roteiro do YouTube e fazer um resumo, e o desempenho é bem bom.
Ficou difícil assistir a tantos vídeos, então isso parece muito útil.
Provérbios têm um significado embutido, mas tem aumentado o número de pessoas que interpretam só pelas palavras
Se esse tipo de argumento virar moda, a sala de reunião vai acabar em caos de novo como se fosse a coisa mais normal do mundo
O pessoal do paperwork fica eufórico e sai aprontando, e os mesmos fracassos se repetem todo ano
Isso está muito ligado aos critérios da legislação trabalhista de cada país... Em muitas empresas nos EUA, o normal é simplesmente fazer rodízio e, quando alguém não pode em determinado período, trocar a ordem. Como é algo pesado... também há empresas com uma equipe dedicada só para on-call.
Na Europa, quase sempre há uma compensação separada, seja porque a natureza do trabalho mudou ou porque é considerado trabalho fora do horário.
Aqui na Coreia, por causa do sistema de salário inclusivo, acaba sendo tratado mais ou menos assim. On-call claramente também é trabalho, mas vendem a ideia como se o adicional por esse tempo fosse um benefício.
Na verdade, já seria difícil usar todos esses serviços, então ter MCP é uma grande vantagem.
Daqui para frente, se a manutenção da API continuar boa, acho que pode ser útil.
Embora o hardware da Apple seja excelente, o software é cheio de mecanismos feitos para manter o usuário na coleira.
Mesmo que você só queira fazer um app que você mesmo criou e compilou rodar apenas no seu próprio dispositivo, ainda precisa de uma assinatura de 100 dólares.
Se você é um desenvolvedor que usa apps open source pequenos ou médios e compila para uso próprio,
fazer jailbreak explorando vulnerabilidades e usar sideload nos dispositivos da Apple é menos prático do que simplesmente usar Android.
No nosso caso, o plantão era pago com metade do valor da hora normal, havia auxílio para telecomunicações, e o tempo de atendimento era considerado hora extra com adicional de 50%.
[link removido] Parece que colocaram aqui a captura de tela da versão Android. Quanto mais eu uso, mais ele parece uma ferramenta curiosa. A comunidade também é bem animada e há muitos aspectos surpreendentes.
Com apenas o Emacs, dá para fazer de tudo. Recentemente até consegui instalar no Android, então é ótimo poder aproveitar no desktop exatamente os mesmos recursos. Estou me aprofundando bastante no tema de ferramentas de gestão do conhecimento no Emacs. Quando meu filho, que ainda está no jardim de infância, entrar no ensino fundamental, talvez nessa época eu já esteja fazendo lifelogging com Emacs haha. Como basta aprender uma única ferramenta, no longo prazo isso acaba reduzindo as preocupações.
Embora a mensagem do autor tenda a ser um tanto forte, se você ler o texto com atenção, não é “não use IA”. Há uma proposta sobre como utilizá-la, e o ponto principal é a mensagem de que o próprio desenvolvedor não pode carecer de competência.
Se formos ver por que a mensagem do autor soa tão forte, ela foi construída como uma resposta à visão de que será possível desenvolver com o Copilot (com a nuance de uma alta dependência de desenvolvimento em relação ao Copilot). Nesse contexto, ele conduziu a mensagem no sentido de não adotar uma postura que prejudique, para os próprios desenvolvedores, o valor da sua existência.
Como o autor também não está passando a mensagem de “não use IA”, no fim, se a ideia é aproveitar a IA, isso acabará ficando em algum ponto de equilíbrio; por isso, a mensagem ficou, em linhas gerais, parecida com o que você respondeu há pouco.
No entanto, tive dificuldade em concordar com a parte de “visão tendenciosa” no que você escreveu inicialmente, então quis responder primeiro sobre isso.
Criar é só o começo, e depois de operar um serviço por uns 10 anos, todo tipo de coisa vai acontecer no meio do caminho; para aguentar firme nessa hora, é preciso ter uma base... é preciso aprender.
Primeiro, no que eu disse sobre "usar IA dentro do domínio", é claro que o design e a coordenação ficam a cargo dos humanos...
Na verdade, isso talvez fosse algo a se dizer antigamente, mas hoje, quando todo mundo já conhece as limitações dos LLMs, virou algo tão óbvio que nem precisa ser mencionado.
Em seguida, sobre o caso de pessoas comuns sem conhecimento de desenvolvimento usarem LLMs,
acho que nem o texto principal, nem o Hacker News, nem eu chegamos a falar disso, mas, de qualquer forma, mesmo nesse caso a tecnologia já chegou a um nível em que os usuários ficam satisfeitos com o resultado.
Se não fosse assim, Bolt.new, v0 e até o Cursor não estariam recebendo a avaliação que têm hoje.
É difícil tomar a decisão sobre até onde reinventar e até onde depender de dependências externas.
Seja qual for o caso, escolher essa dependência para economizar tempo porque eu mesmo poderia fazer isso, e ficar preso a uma dependência porque sem ela não é possível criar o serviço, são histórias completamente diferentes.
Talvez isso não seja possível para todo tipo de código (como um sistema operacional), mas fazer o esforço para ir o máximo possível na direção da primeira opção vai ajudar a entender o sistema.
Acho que há um pequeno mal-entendido sobre o sentido que o autor quis transmitir.
O foco do autor está no desempenho, na estabilidade e em uma arquitetura e consistência de código que facilitem a manutenção dos projetos que ele gerencia, e, em especial, arquitetura e consistência de código são justamente áreas em que os LLMs atuais realmente não são bons.
Especialmente na web, há muita gente entrando em desenvolvimento e uma mentalidade forte de "se funcionar de qualquer jeito, está bom", então uma quantidade enorme de código de baixa qualidade acaba sendo colocada em produção. E como os LLMs foram treinados com base nisso, a qualidade do que eles geram cai a um nível absurdamente ruim.
Simplesmente peça ao GPT: "vou colocar isso no front-end web, então implemente um algoritmo quicksort em JS para mim". Se você não conseguir identificar os problemas na saída, acho que esta conversa não tem muito sentido.
> Pelo que vi em posts antigos do autor, parece que ele é desenvolvedor de jogos
> Como LLMs não conseguem aprender em grande volume conhecimento ou materiais de desenvolvimento de jogos, ao contrário dos casos de apps CRUD, parece que o autor do texto sente mais claramente as limitações dos LLMs
Li tudo, e no fim acho que o autor acabou ficando com uma visão um pouco enviesada por causa disso.
Claro, fazer como o texto principal diz é algo quase didático e está correto,
mas acho que IA já faz bem o suficiente em CRUD e front-end, onde há muito material para treinar.
Parece que o ideal é aproveitar ao máximo dentro do próprio domínio.
A empresa é um lugar para aprender? Ou é um lugar para recriar valor com a roda que outra pessoa fez?
https://pt.news.hada.io/topic?id=21091
Depois de ler este texto, fico pensando se isso está mesmo certo.
O item 1 é realmente uma mudança digna de pesadelo, algo que eu jamais gostaria de aceitar. É como ver o rastreamento do histórico do código-fonte se tornar sem sentido.
Pedi ao bot de IA do GN+ para extrair o roteiro do YouTube e fazer um resumo, e o desempenho é bem bom. Ficou difícil assistir a tantos vídeos, então isso parece muito útil.
É porque você nunca foi a uma casa que manda bem com Electron ~
... acho que é isso que estão querendo dizer kkk
Provérbios têm um significado embutido, mas tem aumentado o número de pessoas que interpretam só pelas palavras
Se esse tipo de argumento virar moda, a sala de reunião vai acabar em caos de novo como se fosse a coisa mais normal do mundo
O pessoal do paperwork fica eufórico e sai aprontando, e os mesmos fracassos se repetem todo ano
Isso está muito ligado aos critérios da legislação trabalhista de cada país... Em muitas empresas nos EUA, o normal é simplesmente fazer rodízio e, quando alguém não pode em determinado período, trocar a ordem. Como é algo pesado... também há empresas com uma equipe dedicada só para on-call.
Na Europa, quase sempre há uma compensação separada, seja porque a natureza do trabalho mudou ou porque é considerado trabalho fora do horário.
Aqui na Coreia, por causa do sistema de salário inclusivo, acaba sendo tratado mais ou menos assim. On-call claramente também é trabalho, mas vendem a ideia como se o adicional por esse tempo fosse um benefício.
Na verdade, já seria difícil usar todos esses serviços, então ter MCP é uma grande vantagem.
Daqui para frente, se a manutenção da API continuar boa, acho que pode ser útil.
Embora o hardware da Apple seja excelente, o software é cheio de mecanismos feitos para manter o usuário na coleira.
Mesmo que você só queira fazer um app que você mesmo criou e compilou rodar apenas no seu próprio dispositivo, ainda precisa de uma assinatura de 100 dólares.
Se você é um desenvolvedor que usa apps open source pequenos ou médios e compila para uso próprio,
fazer jailbreak explorando vulnerabilidades e usar sideload nos dispositivos da Apple é menos prático do que simplesmente usar Android.
No nosso caso, o plantão era pago com metade do valor da hora normal, havia auxílio para telecomunicações, e o tempo de atendimento era considerado hora extra com adicional de 50%.
Tem uma turma do C# escondida aí no meio.
> Falando bem francamente, hoje em dia, para desenvolver em Java, não é exatamente necessário usar produtos da JetBrains
Essa parte... é um pouco difícil de concordar, sniff sniff...
[link removido] Parece que colocaram aqui a captura de tela da versão Android. Quanto mais eu uso, mais ele parece uma ferramenta curiosa. A comunidade também é bem animada e há muitos aspectos surpreendentes.
Com apenas o Emacs, dá para fazer de tudo. Recentemente até consegui instalar no Android, então é ótimo poder aproveitar no desktop exatamente os mesmos recursos. Estou me aprofundando bastante no tema de ferramentas de gestão do conhecimento no Emacs. Quando meu filho, que ainda está no jardim de infância, entrar no ensino fundamental, talvez nessa época eu já esteja fazendo lifelogging com Emacs haha. Como basta aprender uma única ferramenta, no longo prazo isso acaba reduzindo as preocupações.
[link removido]