Não sei se é uma questão de genética, mas no primeiro dia de uso do warp, já me destaquei em instalação de software e resolução de problemas. Quando se trata de codificação, ainda assim, há várias incompatibilidades. Por exemplo, o mecanismo de sessão é quase imperceptível, ou seja, não é claro. Outras ferramentas de programação, seja chat ou terminal, têm um processo de sessão bem definido. O warp, por precisar ser compatível com a linha de comando, torna esse processo vago, embora exista um botão de reset que também tem uma presença muito baixa. Testei a codificação algumas vezes. Antes, havia uma necessidade de colaborar com o cc para fazer a revisão do o3, mas comparando com a versão completa do chatgpt, o o3 ainda fica muito atrás. A família Warp tem dado muitos brindes ultimamente, o que é um ponto negativo. A aquisição do cursor trouxe uma onda de brindes, e o que é isso? Um ano de newsletter grátis? Isso é um sinal de diminuição da inteligência. Nunca ouvi falar de algo que tenha uma grande quantidade e ainda assim seja de boa qualidade. Vamos voltar ao bom senso.

Qual é a diferença entre Warp e o código Claude? Um é um terminal, o outro é um comando que roda dentro do terminal. A diferença resultante é que o Warp é mais leve que o CC, e essa leveza permite facilmente implementar uma combinabilidade semelhante ao SDK do CC. Para dar um exemplo, o CC é como um mochileiro, que pode usar qualquer meio de transporte, enquanto o Warp é como viajar em um motorhome. Dirigir não é bom? Há limitações, como não poder beber álcool durante o percurso.

O processo de desenvolvimento baseado em especificações da Kiro não me parece adequado para usar os comandos slash do claude code. Porque isso significa que você está vinculado ao modelo claude, e embora o modelo claude seja bom em codificação, pode não ser tão bom em trabalho textual, essa parte ainda é melhor com o o3-pro. Além disso---como é que o trabalho de design pode ser gerado por uma IA em quase um minuto seguindo um template? Eu realmente não me sinto confortável com isso, pelo menos a sensação de um design que não consome muita energia não parece muito séria 😎ི A abordagem séria é usar o chatgpt deep research, escolhendo o o3-pro. Eu fiz um teste e é muito mais detalhado do que quando usei o opus 4. Além disso, na verdade, às vezes um prompt muito específico acaba sendo uma limitação, isso é uma conversa para depois, mas, resumindo, no meu prompt, eu principalmente forneci alguns links relacionados ao kio.

O sub agente do código claude ainda deve ser usado com cautela. Acabei de testar e descobri um problema, que é o aumento da dificuldade de comunicação entre o subagente e o agente pai. Antes, era uma pessoa se comunicando consigo mesma, sem perda de informação. Agora, o problema existente é: Ele diz que terminou a execução, mas eu não sei se realmente terminou, cometendo a síndrome das grandes empresas. Para garantir a qualidade, é necessário um mecanismo de supervisão. Há também uma situação em que, se você interromper o subagente com esc, isso também é um problema potencial.

o código claude ultrapassa facilmente a janela de 1 milhão.

O código do Claude como subagente ainda não é muito evidente no campo da programação, mas trouxe duas vantagens em cenários de uso: 1. Fazer dr no cc, isso pode aproveitar a vantagem de paralelismo imediatamente visível. 2. Para codificação, se o subagente for um contexto independente, uma vantagem inesperada é a expansão do contexto; você pode até usar o mesmo papel para replicar várias cópias e deixá-los passar a tarefa entre si.

Falando sobre o recente problema de redução de inteligência do Claude Code, meu feedback é que você deve ter meios para garantir a qualidade do desenvolvimento de software, mesmo que o CC não funcione. Como fazer isso? Primeiro, não vamos falar sobre como fazer, mas sim sobre as falhas comuns do vibe, que é o problema de abrir caixas pretas. Cada vez é uma operação de caixa preta, e você só percebe que algo está errado depois de dar uma volta, o que instantaneamente causa frustração. Dito isso, a solução também está basicamente clara. Transformar o processo de caixa preta em um processo transparente, não é sobre codificar imediatamente, mas sim gastar mais tempo no planejamento e nas soluções. 1. Se a solução não parecer certa, a qualidade da codificação não será boa. 2. Na fase de solução, existem muitos meios, a revisão por múltiplos modelos é uma ferramenta poderosa, não confie apenas na palavra do CC, confie na revisão por pares. 3. Depois que o código estiver escrito, compilado e atendendo às funcionalidades, faça uma revisão adicional. Esses métodos podem ser expandidos, não tenha medo da redução de inteligência do CC, eu ainda tenho o warp e o cline. Outra questão mais mística é quando é mais fácil ter uma redução de inteligência, a intuição pode ser quando há falta de poder computacional, parece que o tempo de trabalho na zona +8 pode ter uma probabilidade maior, então vamos mudar de fuso horário e testar.

Isso é engraçado, usei IA para escrever código e ainda preciso de outra IA para detectar erros.

O código Claude pode mudar a forma de atualização de 5 horas para um reinício semanal. Esse método pode não ser muito amigável para usuários que utilizam intensamente todos os dias — mas é mais amigável para desenvolvedores comuns, o que significa que você não precisa se preocupar em desperdiçar tempo à noite, podendo ficar inativo nos primeiros dias e concentrar-se em usar a cota de uma semana no terceiro dia.

Este ponto de partida é bom, mas o resultado saiu errado 1. O3 fazer planejamento e design é realmente um consenso 2. Repoprompt era originalmente uma ferramenta de resumo de repositório, agora foi atualizada para MCP e embutida com o modelo O3, o planejamento é baseado nisso 3. O problema está na fase de execução, surpreendentemente não é o CC que faz a execução, mas sim o CC chamando a ferramenta MCP do repositório para fazer a fusão 4. Depois de todo esse alvoroço, o CC é um fantoche, essa ferramenta está a brincar comigo, você está tão confiante?