Concordo pra caramba em vários pontos kkk. Fica tão frustrante que você simplesmente larga de mão e entra no modo de trabalhar só o tanto que paga, e aí eles até gostam porque, ironicamente, o trabalho passa a fluir de forma mais suave. Na prática, mesmo vendo uma direção de desenvolvimento arriscada, a pessoa já entrou no estado de “não é problema meu”.
No entanto, como o modelo de permissões não estava implementado, não era possível controlar as permissões do token (se eu estiver errado, por favor me avisem)
1. "A sensação de velocidade é energizante" (visão positiva)
Posição: como a IA resolve rapidamente tarefas entediantes, ela acaba trazendo mais energia e ainda reduz o custo de aprender novas stacks tecnológicas, o que é visto de forma positiva.
Exemplo: ao usar uma linguagem ou framework desconhecido, foi possível pular a parte tediosa do aprendizado graças ao agente de IA e focar direto na implementação.
2. "A disputa sobre a definição de vibe coding" (confusão de termos)
Debate: há divergência sobre se "vibe coding" significa simplesmente programar com ajuda da IA ou se é gerar código e apenas checar o resultado, sem revisar o que foi produzido.
Consenso: originalmente, o termo tinha uma conotação negativa de "código não revisado", mas hoje seu significado se ampliou e passou a indicar programação assistida por IA de forma mais geral.
3. "Velocidade sem validação é dívida técnica" (visão cautelosa)
Crítica: confiar apenas no resultado gerado pela IA sem entender o código é arriscado. Os bugs futuros e o custo de manutenção (dívida técnica) provavelmente serão maiores.
Metáfora: é "como entrar num carro autônomo sem saber para onde ele está indo"; implementar sem compreender acaba reduzindo a capacidade de resolver problemas.
4. "O cansaço da troca de contexto" (visão de identificação)
Concordância: enquanto a IA gera código, ocorrem trocas frequentes de contexto (Context Switching), o que aumenta drasticamente a carga cognitiva do cérebro.
Sintomas: o processo repetitivo de revisar e corrigir o que a IA produz consome mais energia mental do que programar diretamente. Quatro horas de trabalho podem parecer um dia inteiro de exaustão.
5. "A perda da diversão de programar" (falta de dopamina)
Experiência: desaparece a sensação de conquista (dopamina) que vinha de resolver problemas por conta própria. Em vez da diversão de montar um Lego com as próprias mãos, fica a sensação vazia de apenas olhar o produto pronto.
Resultado: trabalhar só para entregar resultados rapidamente, sem a satisfação do processo, acaba esgotando os desenvolvedores.
6. "Veneno para iniciantes, remédio para experientes" (diferença por nível de experiência)
Análise: desenvolvedores experientes conseguem detectar e corrigir rapidamente os erros da IA, o que aumenta a produtividade; já iniciantes correm maior risco de usar código incorreto como está, perder oportunidades de aprendizado e produzir código ruim em escala.
7. "Mudança forçada para o papel de gerente" (mudança de função)
Fenômeno: o desenvolvedor deixa de ser o "criador" que escreve código diretamente e passa a atuar como "gerente/revisor", analisando e corrigindo o código despejado pela IA.
Pressão: isso gera um estresse extremo, como ter de revisar em tempo real, sozinho, o código escrito por cinco desenvolvedores juniores (a IA).
8. "Falta de compreensão da lógica de negócio" (limitação apontada)
Problema: a IA escreve bem código, mas não entende o contexto de negócio nem a arquitetura como um todo.
Realidade: no fim, alinhar os requisitos de negócio ao código e lidar com edge cases complexos continua sendo tarefa humana, e é nesse processo que surgem gargalos.
9. "O desaparecimento das pausas e da folga" (tempo de máquina)
Metáfora: assim como trabalhadores de fábrica no passado precisavam acompanhar o ritmo das máquinas, hoje as pessoas ficam presas ao "tempo de máquina", sendo arrastadas pela velocidade de geração da IA.
Necessidade: pausas forçadas, como o tempo de espera da compilação, desapareceram, e o cérebro já não tem espaço para processar informação e descansar. Pausas intencionais se tornam indispensáveis.
10. "Um problema transitório das ferramentas" (perspectiva futura)
Diagnóstico: o cansaço atual vem do descompasso entre a velocidade de geração da IA e a falta de ferramentas de validação (testes, linters etc.) capazes de acompanhá-la.
Solução: se evoluírem ferramentas que automatizem a validação no mesmo ritmo da geração, o problema da fadiga poderá ser resolvido.
1. Reações mistas ao formato ("clima de LinkedIn?")
Predomínio de críticas: houve muitas avaliações negativas dizendo que o formato com quebras de linha a cada frase parece "texto afetado de influencer do LinkedIn" ou "texto gerado por IA". Apontaram que a embalagem faz barulho, mas falta conteúdo.
Algumas defesas: houve quem visse isso como uma organização mais legível, considerando a curta capacidade de atenção das pessoas hoje, ou como um estilo proposital com ritmo poético.
2. Relatos práticos sobre o "desejo espesso"
Casos de sucesso: pessoas compartilharam experiências de superar a depressão e dar mais densidade à vida por meio de hobbies físicos e demorados, como escultura, projeto de circuitos analógicos e escrita de cartões-postais.
Debate sobre assar pão: a partir do exemplo de "assar pão de forma ineficiente" citado no texto, engenheiros passaram a trocar dicas de "otimização do tempo de fermentação" usando forno, gerando uma discussão paralela ironicamente contraditória.
3. Análise das origens filosóficas e religiosas
Rebranding de sabedoria antiga: houve quem dissesse que isso apenas reapresenta em termos modernos (Thin/Thick) conceitos antigos, como os "fantasmas famintos" do budismo (Hungry Ghosts) ou temas clássicos da filosofia ocidental, como em Agostinho.
Validade da percepção: embora não seja algo novo, houve concordância de que se trata de uma percepção bem organizada para a sociedade contemporânea.
4. Limites da lógica dicotômica
Cautela com a simplificação dos conceitos: o esquema "consumo = raso, criação = espesso" foi considerado perigoso. Uma leitura profunda (consumo) também pode ser espessa, e uma criação comercial também pode ser rasa.
Valor do descanso: apontou-se que atividades que "parecem rasas", como ficar à toa ou jogar, também podem ser formas necessárias de descanso e recuperação.
5. Apontamentos sobre causas estruturais e ambientais
Não é culpa do indivíduo: o problema fundamental estaria no sistema de recompensa dopamínica deliberadamente projetado pelas empresas de TI.
Limitações reais: houve contestação da premissa de que "já somos prósperos". Diante de ameaças à sobrevivência como custo de moradia e despesas médicas, muita gente relatou que é difícil buscar um "desejo espesso" com tranquilidade.
Não seria um estado de analfabetismo do tipo “o branco é código e o preto é terminal”? Tipo, se não sabe ler logs ou não consegue nem copiar e colar, é praticamente o mesmo que não conseguir desenvolver nada.
Parece que também existem o texto Part 1, que examinou por que engenheiros seniores saem, e o Part 2, The Economic Intervention That Stops Engineer Attrition.
Quando vejo esse tipo de coisa, eu simplesmente penso na importância do prompt de sistema da ferramenta. Hoje, ao usar no Cursor, pessoalmente acho que opus >= gpt 5.2 > gemini 3. Fora isso, Sonnet, 5.1 e tal... pessoalmente, não uso mais. Só que... no gpt5.2, a diferença entre os níveis de effort é bem grande... mas nem sempre effort alto é melhor. Então acabo usando mais o Opus e o Gemini como principais. Quando encontro algum problema mais cabeludo, faço os três programarem, peço para avaliarem o código uns dos outros, e depois eu mesmo confiro e aplico.
Parece que muita gente está executando --dangerously-skip-permissions fora de um ambiente sandbox. Será que não sabem o significado de “danger”... buá buá
Hum, por outro lado, também já vi júnior que faz um código estranho e depois usa o GPT como escudo, dizendo que foi ele que fez, então acho que varia de caso para caso.
Agradeço pela opinião! Acho que seria bom colocar isso no README.
Separadamente, achei que algo como um pacote Rust de código aberto talvez pudesse ser usado em vários tipos de ambiente, mas no caso de estar completamente isolado em uma rede interna, aí realmente seria difícil T_T
Ficou meio estranho colocar isso como tópico, então vou escrever aqui nos comentários.
Por enquanto, gostei bastante.
O fato de registrar o carimbo de data/hora também é ótimo,
e, como alguém que já apagou anotações e se arrependeu muito, o que mais gostei foi que dentro do programa as anotações não são apagadas.
Mas acho que seria ainda melhor se a guia trouxesse exemplos de como preencher tarefas e tags.
Pessoalmente, no meu ambiente de trabalho tudo é segregado em rede interna, então é uma pena enorme não poder usar.
Concordo pra caramba em vários pontos kkk. Fica tão frustrante que você simplesmente larga de mão e entra no modo de trabalhar só o tanto que paga, e aí eles até gostam porque, ironicamente, o trabalho passa a fluir de forma mais suave. Na prática, mesmo vendo uma direção de desenvolvimento arriscada, a pessoa já entrou no estado de “não é problema meu”.
JavaScript의 간략한 역사
Acho que vale a pena ver junto com este artigo também
Atualmente isso já é suportado.
https://code.visualstudio.com/updates/v1_107/…
1. "A sensação de velocidade é energizante" (visão positiva)
2. "A disputa sobre a definição de vibe coding" (confusão de termos)
3. "Velocidade sem validação é dívida técnica" (visão cautelosa)
4. "O cansaço da troca de contexto" (visão de identificação)
5. "A perda da diversão de programar" (falta de dopamina)
6. "Veneno para iniciantes, remédio para experientes" (diferença por nível de experiência)
7. "Mudança forçada para o papel de gerente" (mudança de função)
8. "Falta de compreensão da lógica de negócio" (limitação apontada)
9. "O desaparecimento das pausas e da folga" (tempo de máquina)
10. "Um problema transitório das ferramentas" (perspectiva futura)
1. Reações mistas ao formato ("clima de LinkedIn?")
2. Relatos práticos sobre o "desejo espesso"
3. Análise das origens filosóficas e religiosas
4. Limites da lógica dicotômica
5. Apontamentos sobre causas estruturais e ambientais
Não seria um estado de analfabetismo do tipo “o branco é código e o preto é terminal”? Tipo, se não sabe ler logs ou não consegue nem copiar e colar, é praticamente o mesmo que não conseguir desenvolver nada.
Parece que também existem o texto Part 1, que examinou por que engenheiros seniores saem, e o Part 2, The Economic Intervention That Stops Engineer Attrition.
https://codegood.co/writing/…
Ontem também vi um post no Facebook dizendo que era muito conveniente liberar espaço no Mac inteiro (mandando o Claude apagar tudo sozinho)...
Será que não dá para fazer com que os executivos vejam este texto..?
Muito legal.
Quando vejo esse tipo de coisa, eu simplesmente penso na importância do prompt de sistema da ferramenta. Hoje, ao usar no Cursor, pessoalmente acho que
opus >= gpt 5.2 > gemini 3. Fora isso, Sonnet, 5.1 e tal... pessoalmente, não uso mais. Só que... nogpt5.2, a diferença entre os níveis de effort é bem grande... mas nem sempre effort alto é melhor. Então acabo usando mais o Opus e o Gemini como principais. Quando encontro algum problema mais cabeludo, faço os três programarem, peço para avaliarem o código uns dos outros, e depois eu mesmo confiro e aplico.Parece que muita gente está executando
--dangerously-skip-permissionsfora de um ambiente sandbox. Será que não sabem o significado de “danger”... buá buáNão há uma palavra errada aí.
Hum, por outro lado, também já vi júnior que faz um código estranho e depois usa o GPT como escudo, dizendo que foi ele que fez, então acho que varia de caso para caso.
Agentes que usam ferramentas são realmente perigosos. Vamos só ouvi-los falar.
Entendi. Eu não sabia porque não uso muito o Bloco de Notas integrado do Windows 11. Obrigado.
É só apertar F5 no bloco de notas
Agradeço pela opinião! Acho que seria bom colocar isso no README.
Separadamente, achei que algo como um pacote Rust de código aberto talvez pudesse ser usado em vários tipos de ambiente, mas no caso de estar completamente isolado em uma rede interna, aí realmente seria difícil T_T
Ficou meio estranho colocar isso como tópico, então vou escrever aqui nos comentários.
Por enquanto, gostei bastante.
O fato de registrar o carimbo de data/hora também é ótimo,
e, como alguém que já apagou anotações e se arrependeu muito, o que mais gostei foi que dentro do programa as anotações não são apagadas.
Mas acho que seria ainda melhor se a guia trouxesse exemplos de como preencher tarefas e tags.
Pessoalmente, no meu ambiente de trabalho tudo é segregado em rede interna, então é uma pena enorme não poder usar.