Em vez de substituir o JavaScript, ele o complementa; acho que esse foi o fator de sucesso que fez o TypeScript vencer o Dart. Realmente sinto que foi uma ótima decisão ter aprendido isso.

 

Cometi um erro de digitação. ;_;

Em especial, o segundo caso se devia em grande parte ao fato de que não era fácil fazer a IA 'seguir o que eu dizia' -> o primeiro

 

Concordo! Claro que a IA também vai ajudar ali, mas acho que no modo vibe seria difícil.

 

No Vibe Coding, a ideia de monitorar e supervisionar o processo parece meio deslocada.
Pelo que entendo, o vibe coding original é só explicar para a IA em linguagem natural, e não o conceito de Efficient Coding with LLM. Parece uma proposta com uma vibe totalmente diferente da que o Karpathy descreveu. Na minha opinião, isso é mais low-code with LLM.

 

Aaah, que coisa mais sem graça...

 

Ahá.....
Muito obrigado aos dois que responderam!

 

É difícil concordar com o ponto 1.

  • As boas empresas tentam contratar apenas engenheiros excelentes. Esses recursos de engenharia são limitados. Por isso, as contratações não aumentam.

Eu sinto muito isso. Porque, apesar de estarmos tentando contratar bons engenheiros em uma empresa pequena, realmente não é nada fácil.

 

Acho que é bom entender profundamente a engenharia de produto necessária para startups, mas também acredito que seguir o caminho de levar a tecnologia ao limite e refiná-la ao máximo continua sendo algo muito válido. O desenvolvimento para criar aplicações web simples será substituído pela IA, mas alguém ainda vai precisar conceber o Kubernetes e projetar o ElasticSearch.

 

O comentário dizendo que isso é o sonho do ASO é marcante.

 

Foi incluído no JDK 23.
Nos meus testes, mesmo que a versão do JDK do projeto seja inferior à 23, funciona normalmente se a IDE ou a ferramenta de exportação do Javadoc oferecer suporte.

 

Há muita percepção aqui. Obrigado.

 
nicewook 2025-03-25 | comentário pai | em: "Vibe Coding" vs. realidade (cendyne.dev)

A parte “nível atual” chama a minha atenção. Será que não estamos olhando para os LLMs com uma noção de tempo humana?

 
  • Análise detalhada do prompt de sistema do Cursor — impressionante.
  • Só de pensar que a Anthropic pode lançar uma AI IDE, já fico animado.
 

Parece que foi incorporado ao padrão.

 

O Linux Landlock é um módulo de segurança nativo do kernel que permite que processos sem privilégios se coloquem em sandbox — mas ninguém o usa porque a API é... difícil!

Nunca tinha ouvido falar de Landlock, mas achei interessante

 

O que sinto ao programar com IA é que, mesmo dando apenas uma parte do código para a IA, para que ela consiga entender o contexto, quando acabo dividindo em unidades no estilo princípio da responsabilidade única + TDD, ela precisa captar bem sem precisar ler o contexto maior, de modo que o contexto local da parte já seja suficiente.

 

O que eu mais uso IA para hobbies é a criação de jogos web, então concordo. Quando o projeto passa de um certo porte, chega um ponto em que a IA claramente perde muito a capacidade de foco, por assim dizer. Eu uso isso da seguinte forma: junto toda a árvore e o código-fonte do jogo em um único arquivo, incluindo o TOC, e então crio uma nova thread, envio esse arquivo e continuo o trabalho. E, quando faço perguntas, sempre peço a resposta deixando explicitamente claro o nome do projeto atual. Mesmo assim, ainda há partes que me deixam insatisfeito... mas estou muito satisfeito com o fato de conseguir concluir, em relativamente pouco tempo, hobbies que no passado eu nem conseguia começar por estar ocupado demais com a vida real.

 

Caí no título. rsrs Concordo~~

 

LLMs, incluindo deep research, ainda não são úteis para resolução de problemas de alto nível. (Por exemplo, desenvolvimento de algoritmos em nível de artigo científico)
O mesmo vale para otimização extrema e para programação que exige entender diversas características de sistemas e questões técnicas: isso ainda precisa de intervenção humana. Desenvolvedores não são programadores simples, e sim solucionadores de problemas. Um dia talvez a resolução end-to-end de problemas também se torne possível, mas, por enquanto, isso parece positivo do ponto de vista da produtividade, porque economiza tempo gasto com digitação e programação simples e permite investir mais na abordagem de problemas mais difíceis.