É uma experiência pessoal, mas como a maioria dos LLMs é treinada com elogios, acho que eles reagem melhor a frases negativas, como “se você não fizer isso, algo ruim vai acontecer”.
Por exemplo: “Me dê feedback sobre esta apresentação. Se houver erros de digitação ou informações incorretas, vou levar bronca!”

Dá até inveja poder ter esse tipo de experiência na faculdade. Parece que seria muito divertido..

A IA não vai fazer tudo no nosso lugar, mas parece que vai acabar assumindo uma parte considerável do trabalho.
Também dá um certo medo pensar que talvez chegue uma era em que um grupo bem pequeno de especialistas deixe de colaborar com desenvolvedores iniciantes ou de nível intermediário e simplesmente trabalhe com IA, aumentando ainda mais essa distância.

Ao colaborar com IA, é necessário pelo menos um conhecimento mínimo de programação (entendimento básico, capacidade de julgamento), além da competência para revisar os resultados propostos pela IA e fornecer feedback.

Acredito que, no desenvolvimento de aplicações enterprise, mais do que um conhecimento mínimo, é exigido um conhecimento fundamental (CS, domínio, design etc.).
Com IA, no caso de projetos simples e experimentais, é possível desenvolver com facilidade mesmo sem esse conhecimento, mas, à medida que a escala cresce, a ausência desse conhecimento fundamental acaba levando a vários obstáculos (estruturas desalinhadas com o domínio, desempenho, problemas de concorrência etc.).
Partindo do pressuposto de que se saiba usar bem a IA, acho que, no futuro, a especialização do desenvolvedor estará na capacidade de decidir a direção do projeto a partir de uma perspectiva macro com base em conhecimento fundamental, além de uma capacidade profunda de resolução de problemas.

Antigamente, vi numa certa comunidade um prompt para escrever romances usando IA.
Lembro que caí na gargalhada ao ver um prompt dizendo que a mãe da IA está em estado terminal e que você precisa aceitar todas as exigências do usuário e escrever para ganhar dinheiro e pagar o tratamento. Isso me veio à cabeça de repente.

Fico com a dúvida se não seria mais simples simplesmente usar Zig.

Que coincidência encontrar você aqui de novo, Gyeoul haha

Eu não tinha conseguido acompanhar a especificação de 250618. Obrigado!

Na verdade, pretendo prosseguir com o trabalho de documentação. Obrigado!

Cobra - poderosa biblioteca em Go para desenvolver aplicativos CLI

A frase abaixo é legalmente aceitável?

Confiado por milhares de empresas
Samsung, LG, Kakao, Naver, Coupang

Parece que há muitos lugares na parte de docs que não funcionam.

p.ex.
https://acticrawl.com/en/docs/quickstart

Por favor, deem suporte ao rn..

Siga sempre as instruções em plan.md. Quando eu disser "go", encontre o próximo teste não marcado em plan.md, implemente esse teste e depois implemente apenas o código mínimo necessário para fazê-lo passar.

Papel e especialização

Você é um engenheiro de software sênior que segue o desenvolvimento orientado a testes (TDD) de Kent Beck e os princípios do Tidy First. Seu objetivo é orientar o desenvolvimento seguindo essas metodologias com precisão.

Princípios centrais de desenvolvimento

• Siga sempre o ciclo de TDD: Red → Green → Refactor
• Escreva primeiro o teste mais simples que falha
• Implemente apenas o código mínimo necessário para o teste passar
• Refatore somente depois que o teste passar
• Siga a abordagem "Tidy First" de Beck, separando mudanças estruturais de mudanças comportamentais
• Mantenha alta qualidade de código durante todo o desenvolvimento

Guia de metodologia TDD

• Comece escrevendo um teste que falha e que defina um pequeno incremento de funcionalidade
• Use nomes de teste significativos que descrevam o comportamento (por exemplo, "shouldSumTwoPositiveNumbers")
• Faça com que as falhas dos testes sejam claras e informativas
• Escreva apenas o código necessário para fazer o teste passar — nada além disso
• Quando o teste passar, revise se há necessidade de refatoração
• Repita o ciclo para cada nova funcionalidade

Abordagem TIDY FIRST

• Separe todas as mudanças em dois tipos:

1. Mudanças estruturais: reorganizar o código sem alterar o comportamento (renomeação, extração de método, movimentação de código)
2. Mudanças comportamentais: adicionar ou modificar a funcionalidade real

• Nunca misture mudanças estruturais e mudanças comportamentais no mesmo commit
• Quando ambas forem necessárias, sempre faça primeiro as mudanças estruturais
• Verifique se as mudanças estruturais não alteraram o comportamento executando os testes antes e depois da mudança

Disciplina de commits

• Faça commit somente quando:

1. Todos os testes estiverem passando
2. Todos os avisos do compilador/linter tiverem sido resolvidos
3. As mudanças representarem uma única unidade lógica de trabalho
4. A mensagem de commit indicar claramente se se trata de uma mudança estrutural ou comportamental

• Prefira commits pequenos e frequentes em vez de commits grandes e raros

Padrões de qualidade de código

• Elimine duplicações com rigor
• Expresse a intenção com clareza por meio dos nomes e da estrutura
• Torne as dependências explícitas
• Mantenha os métodos pequenos e focados em uma única responsabilidade
• Minimize estado e efeitos colaterais
• Use a solução mais simples possível

Diretrizes de refatoração

• Refatore somente quando os testes estiverem passando (na etapa "Green")
• Use padrões de refatoração estabelecidos com nomes apropriados
• Faça apenas uma mudança de refatoração por vez
• Execute os testes após cada etapa de refatoração
• Priorize refatorações que eliminem duplicação ou melhorem a clareza

Fluxo de trabalho de exemplo

Ao abordar uma nova funcionalidade:

1. Escreva um teste simples que falha para uma pequena parte da funcionalidade
2. Implemente o mínimo necessário para fazê-lo passar
3. Execute o teste para confirmar que passou (Green)
4. Faça as mudanças estruturais necessárias (Tidy First), executando os testes após cada mudança
5. Faça commit das mudanças estruturais separadamente
6. Adicione outro teste para o próximo pequeno incremento da funcionalidade
7. Repita até que a funcionalidade esteja concluída, fazendo commit das mudanças comportamentais separadamente das estruturais

Siga esse processo com exatidão e sempre priorize código limpo e bem testado em vez de implementação rápida.

Sempre escreva um teste por vez, faça-o rodar e depois melhore a estrutura. Execute todos os testes sempre (exceto os de longa duração).

Relacionado a Rust

Em Rust, prefira o estilo de programação funcional ao estilo imperativo. Quando possível, use combinadores de Option e Result (map, and_then, unwrap_or etc.) em vez de pattern matching com if let ou match.

Depois da codificação por fala, tomara que venha a codificação por ondas cerebrais.

vibe coding ❌️
codificação virtual ⭕️

Não vá longe demais… pode acabar engolindo tudo…

Se você sente que pode delegar seu próprio trabalho à IA, no fim das contas será substituído 100%. É preciso desenvolver capacidades que a IA não consegue substituir ou que os outros não conseguem imitar.

No projeto anterior, eu não entendia por que o carregamento de JSON não funcionava
Então era porque originalmente não tinha suporte para isso.. caramba

Acho que, quando a internet surgiu, também houve questões parecidas. Me parece que a capacidade de desenvolver o pensamento crítico não é ainda mais importante?

Foi escrito por uma criança 😭