Acho, com certa cautela, que o processo de escrever à mão as partes extremamente complexas e centrais para a lógica de negócio, refletir sobre elas e depois transmiti-las aos engenheiros de IA talvez possa ajudar na produtividade. Matemáticos também usam ferramentas como calculadoras, mas, quando pensam nas ideias centrais, costumam fazer muitas anotações à mão.
A adoção de software sempre deve ser avaliada sob a ótica do TCO ao longo de "5 anos". Caso contrário, você só vai acumulando "bombas" que de fato explodem depois.
Respeito o ideal de felicidade e satisfação pessoal de cada um, mas, do ponto de vista de um trabalho em que se oferece mão de obra e se recebe dinheiro, isso me parece uma mentalidade inadequada.
Cada vez mais, não sei se essa expressão é a mais precisa, mas dá a sensação de que o desenvolvedor está se tornando cada vez mais um “líder técnico”.
Se a IA assumir a “escrita de código”, no fim só sobra:
resolver problemas (estresse)
revisar resultados (estresse)
responsabilidade (estresse)
Só isso.
Ou seja, o desenvolvedor deixa de ser um “produtor” e passa cada vez mais a atuar como
“tomador de decisões”
“revisor”
“responsável”
Então surge um tipo de fadiga no trabalho que antes não existia,
e a pessoa começa a se perguntar se essa direção realmente combina com a aptidão profissional de desenvolvedor que ela buscava.
Também concordo com essa opinião: mesmo que a própria pessoa insista em programar tudo manualmente, a menos que toque o negócio sozinha, isso inevitavelmente acaba sendo substituído,
mas parece que ela não percebe isso.
Isso sim é uma metodologia de desenvolvimento para tornar a manutenção realmente difícil. É alguém que, adaptando-se à era da IA, está colocando em prática uma nova forma de garantir seu lugar para o resto da vida.
Ultimamente, continuam aparecendo textos de desenvolvedores ultrapassados tentando se convencer. De qualquer forma, não dá para impedir o fluxo dos tempos.
O autor deste texto, Jakob Nielsen, é um especialista em UX com 42 anos de experiência.
Quando a WWW foi aberta ao público, ele previu que “hipertexto seria a interface do usuário do futuro”.
Por isso, já em 1990, ele escreveu o livro “Hypertext and Hypermedia”.
Ele também foi cofundador do Nielsen Norman Group, a consultoria mais conhecida na área de UX (https://www.nngroup.com/). (Donald Norman é a pessoa que criou o termo UX.)
Existem frameworks bem organizados, com muito material em que a IA já foi treinada; será que realmente faz sentido eu criar algo novo só meu? Pelo contrário, isso me parece algo que reduz a produtividade.
Acho que não há necessidade de jogar fora algo que foi feito justamente para reduzir o custo de desenhar a arquitetura e permitir focar no essencial (o serviço).
Também acho que parece haver um certo romantismo em torno de "código escrito à mão".
A direção de "fazer muito com pouca escrita" sempre existiu,
e, mesmo antes da IA, acho que já havia um clima parecido na época em que o GC surgiu.
Mesmo escrevendo código à mão, achamos que não há problema no nosso código, mas quando surge um problema acabamos abrindo o código interno ou vasculhando a memória.
Mesmo escrevendo prompts à mão, acho que vai ser a mesma coisa: achamos que não há problema no nosso prompt, mas quando surgir um problema vamos acabar abrindo o código interno.
Claro que, na maioria dos casos, isso também provavelmente vai ser resolvido por serviços de IA.
Também fico imaginando se código escrito à mão não vai acabar virando, em certo sentido, arte moderna... rs
Hum... essa prática não seria da época em que o Cursor oferecia uso ilimitado? Em vez disso, a direção daqui para frente, pelo menos por um tempo, parece ser mais algo como: como economizar tokens e dar um bom suporte à IA?
Mesmo sem preços de tokens caros dá para eliminar duplicação, então por que não usar frameworks?
Quando isso foi postado antes, houve comentários de que era arriscado um app de terceiros que não era open source poder ver todas as minhas mensagens; refletindo isso, agora ele foi totalmente aberto como open source.
Iniciantes e novos participantes têm dificuldade para participar
Não há absolutamente nenhum motivo para ser difícil receber um Vouch
O principal objetivo do Vouch é impedir participação aleatória e sem esforço
Nos meus projetos (incluindo este), basta se apresentar na issue e explicar brevemente como gostaria de contribuir para poder receber um Vouch
Em resumo, como na vida social comum, se você se apresentar, pode receber um Vouch
Mas, se abusar das permissões dentro do grupo, estará sujeito a sanções
É vulnerável a engenharia social
Usuários que recebem um Vouch apenas obtêm permissão para participar do projeto
Eles não recebem permissões para mesclar pull requests, fazer push de código ou realizar releases
Todas essas ações continuam restritas pelos processos de revisão existentes e pelos controles do sistema
Além disso, apenas administradores/colaboradores podem recomendar usuários
Portanto, mesmo que um usuário problemático receba uma recomendação, ele não poderá recomendar outros usuários
Não há procedimento de recurso para denúncias.
O processo de recurso varia conforme o subprojeto
No caso dos meus projetos, se você entrar em contato conosco por Discord, e-mail ou qualquer outro meio, conversar como uma pessoa e reconhecer o erro, damos outra chance. Não é difícil
O ponto central deste projeto é que a IA fornece informações às pessoas por meio de chamadas de API, minimizando as barreiras naturais já existentes
Em projetos comunitários centrados em humanos, a interação humana só é necessária nos pontos de fronteira
Acho, com certa cautela, que o processo de escrever à mão as partes extremamente complexas e centrais para a lógica de negócio, refletir sobre elas e depois transmiti-las aos engenheiros de IA talvez possa ajudar na produtividade. Matemáticos também usam ferramentas como calculadoras, mas, quando pensam nas ideias centrais, costumam fazer muitas anotações à mão.
A adoção de software sempre deve ser avaliada sob a ótica do
TCOao longo de "5 anos". Caso contrário, você só vai acumulando "bombas" que de fato explodem depois.Parece que o próprio sistema precisa conquistar autoridade para ser aceito.
Parece, no máximo, uma proposta de entrar em choque frontal com a direção que as empresas estão buscando..
Isso já passou muito dos limites.
Respeito o ideal de felicidade e satisfação pessoal de cada um, mas, do ponto de vista de um trabalho em que se oferece mão de obra e se recebe dinheiro, isso me parece uma mentalidade inadequada.
Cada vez mais, não sei se essa expressão é a mais precisa, mas dá a sensação de que o desenvolvedor está se tornando cada vez mais um “líder técnico”.
Se a IA assumir a “escrita de código”, no fim só sobra:
Só isso.
Ou seja, o desenvolvedor deixa de ser um “produtor” e passa cada vez mais a atuar como
Então surge um tipo de fadiga no trabalho que antes não existia,
e a pessoa começa a se perguntar se essa direção realmente combina com a aptidão profissional de desenvolvedor que ela buscava.
Na verdade, os desenvolvedores realmente talentosos, que programam muito bem, é que curtem vibe coding...
Não sou eu quem está dizendo isso (Linus Torvalds ou Robert Martin)
Também concordo com essa opinião: mesmo que a própria pessoa insista em programar tudo manualmente, a menos que toque o negócio sozinha, isso inevitavelmente acaba sendo substituído, mas parece que ela não percebe isso.
Toda discussão antes de surgirem evidências é um julgamento precipitado
Isso sim é uma metodologia de desenvolvimento para tornar a manutenção realmente difícil. É alguém que, adaptando-se à era da IA, está colocando em prática uma nova forma de garantir seu lugar para o resto da vida.
Nossa, isso foi pesado demais 😭
Ultimamente, continuam aparecendo textos de desenvolvedores ultrapassados tentando se convencer. De qualquer forma, não dá para impedir o fluxo dos tempos.
Fazia tempo que eu não encontrava um projeto que parece tão interessante assim.
O autor deste texto, Jakob Nielsen, é um especialista em UX com 42 anos de experiência.
Quando a WWW foi aberta ao público, ele previu que “hipertexto seria a interface do usuário do futuro”.
Por isso, já em 1990, ele escreveu o livro “Hypertext and Hypermedia”.
Ele também foi cofundador do Nielsen Norman Group, a consultoria mais conhecida na área de UX (https://www.nngroup.com/). (Donald Norman é a pessoa que criou o termo UX.)
O artigo 10 heurísticas de usabilidade para design de interface também é bastante famoso.
Existem frameworks bem organizados, com muito material em que a IA já foi treinada; será que realmente faz sentido eu criar algo novo só meu? Pelo contrário, isso me parece algo que reduz a produtividade.
Acho que não há necessidade de jogar fora algo que foi feito justamente para reduzir o custo de desenhar a arquitetura e permitir focar no essencial (o serviço).
Também acho que parece haver um certo romantismo em torno de "código escrito à mão".
A direção de "fazer muito com pouca escrita" sempre existiu,
e, mesmo antes da IA, acho que já havia um clima parecido na época em que o GC surgiu.
Mesmo escrevendo código à mão, achamos que não há problema no nosso código, mas quando surge um problema acabamos abrindo o código interno ou vasculhando a memória.
Mesmo escrevendo prompts à mão, acho que vai ser a mesma coisa: achamos que não há problema no nosso prompt, mas quando surgir um problema vamos acabar abrindo o código interno.
Claro que, na maioria dos casos, isso também provavelmente vai ser resolvido por serviços de IA.
Também fico imaginando se código escrito à mão não vai acabar virando, em certo sentido, arte moderna... rs
Hum... essa prática não seria da época em que o Cursor oferecia uso ilimitado? Em vez disso, a direção daqui para frente, pelo menos por um tempo, parece ser mais algo como: como economizar tokens e dar um bom suporte à IA?
Mesmo sem preços de tokens caros dá para eliminar duplicação, então por que não usar frameworks?
DoNotNotify – registra notificações no Android e as bloqueia de forma inteligente
Quando isso foi postado antes, houve comentários de que era arriscado um app de terceiros que não era open source poder ver todas as minhas mensagens; refletindo isso, agora ele foi totalmente aberto como open source.
Parece que o assunto gerou interesse, mas também alguns mal-entendidos, então ele organizou um FAQ separado.
https://x.com/mitchellh/status/2020628046009831542