Claude Code Simplify: Meu Código Ficou 40% Menor
Eu vi meu terminal fazer algo que nunca tinha visto uma ferramenta de IA fazer antes. Ela desmontou código que tinha acabado de escrever — e deixou melhor.
Não "melhor" naquele sentido vago e genérico que as pessoas costumam usar. Estou falando de extrair traits reutilizáveis de componentes Livewire duplicados, converter inserções individuais no banco de dados em operações em lote, e transformar templates Blade inchados em partials limpos e modulares. O tipo de refatoração que um desenvolvedor sênior faz durante um code review — só que isso aconteceu em oito minutos e meio, automaticamente, em um projeto Laravel inteiro.
A funcionalidade se chama /simplify, e foi lançada discretamente em uma atualização recente do Claude Code. Venho rodando ela em todo projeto na última semana, e sinceramente? Mudou completamente a forma como eu penso sobre código gerado por IA. Não porque o resultado inicial fosse ruim. Mas porque a segunda passada pega coisas que eu teria pego sozinho — três dias depois, num code review, quando corrigir custa dez vezes mais esforço.
Aqui está o que a maioria das pessoas entende errado sobre essa funcionalidade, e há uma razão específica pela qual a galera do "é só gerar código melhor logo de cara" está perdendo o ponto. Vou chegar lá. Mas primeiro, você precisa entender o que o /simplify realmente faz por baixo dos panos — porque é muito mais sofisticado que um linter.
Por Que Seu Código Gerado por IA Precisa de uma Segunda Olhada
Já faz mais de um ano que desenvolvo com Claude Code. Meus agentes de conteúdo, meus fluxos de automação, projetos de clientes — tudo passa pelo Claude Code em algum momento. E notei um padrão difícil de contestar.
Código de primeiro rascunho de qualquer modelo de IA — Claude, GPT, Gemini, tanto faz — tende a resolver o problema corretamente, mas de forma repetitiva. Você pede um sistema CRUD, recebe um componente de criação e um de edição que compartilham 80% da lógica mas duplicam cada linha. Você pede um dashboard, recebe a mesma string de status hardcoded em quatro arquivos diferentes em vez de puxar de uma constante.
Isso não é um bug. Na verdade é o comportamento correto para um modelo otimizando para "dar ao usuário código funcional agora". O modelo não tem o contexto completo do projeto como um desenvolvedor humano que vive na base de código há meses. Ele gera cada arquivo para ser independente e funcional.
O problema aparece em escala. Quando você está gerando 10, 15, 20 arquivos numa sessão — como eu estava fazendo construindo um sistema de gerenciamento de tarefas com Laravel Livewire — essas pequenas duplicações se acumulam num pesadelo de manutenção.
Eu costumava corrigir isso manualmente. Abrir cada arquivo, identificar os padrões, extrair a lógica compartilhada, testar que nada quebrou. É o tipo de trabalho que leva uma tarde inteira e parece que não deveria ser tão tedioso. É exatamente essa lacuna que o /simplify preenche — e ele faz isso com uma arquitetura multi-agente que genuinamente me surpreendeu quando vi em ação pela primeira vez.
Por Dentro da Máquina: Como o Simplify Realmente Funciona
Aqui é onde fica técnico, e honestamente, essa é a parte que me fez prestar atenção de verdade.
Quando você roda /simplify no Claude Code, ele não simplesmente escaneia seus arquivos com uma regex ou roda um linter básico. O sistema dispara um pipeline de análise em múltiplas etapas que funciona assim:
Etapa 1: Captura do Git Diff. O Simplify olha suas mudanças mais recentes — tudo na sua árvore de trabalho que foi modificado desde seu último commit. Esse escopo é inteligente porque significa que a ferramenta só analisa código que você tocou recentemente, não seu projeto inteiro de 500 arquivos.
Etapa 2: Três Agentes de Revisão em Paralelo. Essa é a parte que me impressionou. O sistema lança três agentes independentes, cada um rodando em Sonnet por velocidade, e cada um focado em uma perspectiva diferente:
-
Agente 1 — Reuso de Código: Escaneia lógica duplicada entre arquivos. Procura funções, métodos ou blocos de template que aparecem em múltiplos lugares com variações menores. Propõe extrações em traits, componentes ou utilitários compartilhados.
-
Agente 2 — Qualidade de Código: Avalia convenções de nomenclatura, padrões estruturais, uso adequado de recursos do framework. Pega coisas como usar strings brutas em vez de constantes, ou construir algo do zero quando o framework já tem uma solução pronta.
-
Agente 3 — Eficiência de Código: Foca em performance. Queries no banco dentro de loops, re-renderizações desnecessárias, operações que poderiam ser feitas em lote, oportunidades de cache.
Etapa 3: Síntese do Agente Principal. Os achados dos três agentes são alimentados a um modelo de raciocínio principal que sintetiza as recomendações, resolve conflitos entre sugestões e produz uma lista priorizada de correções.
Etapa 4: Implementação. O Claude Code aplica as mudanças — com sua aprovação — diretamente nos seus arquivos. Sem copiar e colar. Sem alternar entre ferramentas. Apenas um git diff que você pode revisar.
O processo todo levou 8 minutos e 36 segundos no meu projeto Laravel. Não é instantâneo, mas considere o que aconteceu nesses oito minutos: três analistas de IA separados revisaram cada arquivo que eu tinha alterado, cruzaram padrões ao longo de todo o diff, e produziram uma refatoração acionável que teria me tomado — sendo honesto — pelo menos duas horas de trabalho de revisão focado.
Essa troca faz sentido pra mim. Sempre.
Meu Projeto Laravel: Oito Correções Que Realmente Importaram
Deixa eu te guiar exatamente pelo que o /simplify encontrou no meu projeto de gerenciamento de tarefas. Eu estava construindo um sistema CRUD baseado em Livewire — criar tarefas, editar tarefas, dashboard pra visualizá-las — e tinha acabado de terminar a passada inicial de geração. Tudo funcionava. Os testes passavam. O código estava ok.
"Ok" é inimigo do bom, e o /simplify me mostrou exatamente onde.
Correção 1: Constantes em Vez de Strings Mágicas
O modelo Task tinha valores de status e prioridade espalhados pelos arquivos como strings brutas — "pending", "in_progress", "completed" no controller, as mesmas strings nos templates Blade, de novo na lógica de filtros do dashboard. O Simplify propôs adicionar constantes ao próprio modelo.
class Task extends Model
{
const STATUS_PENDING = 'pending';
const STATUS_IN_PROGRESS = 'in_progress';
const STATUS_COMPLETED = 'completed';
const PRIORITY_LOW = 'low';
const PRIORITY_MEDIUM = 'medium';
const PRIORITY_HIGH = 'high';
}
Agora, eu pessoalmente preferiria enums do PHP aqui — que foram lançados no PHP 8.1 e são a abordagem moderna — mas o princípio está certíssimo. Centralizar esses valores significa que você muda em um lugar só, e toda referência se atualiza. O fato de uma IA ter detectado isso em múltiplos arquivos simultaneamente é impressionante.
Dica profissional: Se você está no PHP 8.1+, pegue a sugestão de constantes do Simplify e evolua para um backed enum. Você ganha type safety de graça.
Correção 2: Extração de um Trait de Formulário Compartilhado
Essa foi a grande. Meus componentes Livewire CreateTask e EditTask compartilhavam cerca de 80% da lógica de formulário — regras de validação, definições de propriedades, o fluxo de salvamento. O Simplify propôs um trait HasTaskForm que ambos os componentes poderiam usar.
trait HasTaskForm
{
public string $title = '';
public string $description = '';
public string $status = 'pending';
public string $priority = 'medium';
protected function taskRules(): array
{
return [
'title' => 'required|min:3|max:255',
'description' => 'required|min:10',
'status' => 'required|in:pending,in_progress,completed',
'priority' => 'required|in:low,medium,high',
];
}
protected function fillFromTask(Task $task): void
{
$this->title = $task->title;
$this->description = $task->description;
$this->status = $task->status;
$this->priority = $task->priority;
}
}
Antes dessa extração, mudar uma regra de validação significava atualizar dois arquivos. Esquecer um criaria bugs sutis e irritantes onde criar uma tarefa aplicava regras diferentes de editar uma. Já vi esse problema exato em apps em produção. É sempre constrangedor.
Correção 3: Consistência do Dashboard com Constantes do Modelo
Uma vez que as constantes existiam no modelo, o Simplify atualizou o componente do dashboard para referenciá-las em vez de strings brutas. Mudança pequena, impacto enorme na manutenibilidade:
// Before
$tasks->where('status', 'completed')->count();
// After
$tasks->where('status', Task::STATUS_COMPLETED)->count();
Esse é o tipo de correção que leva 30 segundos pra fazer mas previne horas de debugging quando alguém decide que "completed" deveria ser "done" daqui a seis meses.
Correção 4: Uso Adequado de Componentes no Blade
Eu tinha um botão dentro de uma tag anchor — <a href="..."><button>Create Task</button></a>. Anti-pattern HTML clássico. O Simplify percebeu que eu estava usando a biblioteca de componentes Flux UI e propôs converter para o componente de botão Flux apropriado com navegação integrada.
Pequeno? Sim. Mas é exatamente o tipo de coisa que causa problemas de acessibilidade e falha na validação HTML. Um dev sênior pegaria isso num code review. Agora a IA pega primeiro.
Correção 5: Extração de um Componente Reutilizável de Linha de Tarefa
Meu template Blade do dashboard tinha a mesma estrutura de div repetida para cada exibição de tarefa — badge de status, título, indicador de prioridade, botões de ação. O mesmo HTML, copiado e colado com pequenas mudanças de variáveis. O Simplify propôs um componente Blade <x-task-row>:
<!-- Before: 40 lines repeated 3 times -->
<!-- After: -->
<x-task-row :task="$task" />
O componente encapsula toda a lógica de exibição. Mudar a aparência das tarefas? Edita um arquivo. Adicionar um novo botão de ação? Um lugar só. Isso sozinho eliminou cerca de 120 linhas do meu template do dashboard.
Correção 6: Partial de Formulário Compartilhado para Views de Criar e Editar
Similar à extração do trait, os templates Blade para os formulários de criar e editar eram quase idênticos. O Simplify propôs um único partial _task-form.blade.php que aceita um parâmetro opcional $task:
@include('tasks._task-form', ['task' => $task ?? null])
O partial preenche condicionalmente os campos ao editar e os deixa vazios ao criar. Um template, dois casos de uso. Limpo.
Correção 7: Limpeza de Instruções Include Verbosas
Algumas das minhas diretivas Blade @include tinham ficado desnecessariamente complexas — caminhos longos, arrays de dados aninhados que podiam ser simplificados. O Simplify as encurtou sem mudar o comportamento. Uma melhoria de legibilidade.
Correção 8: Operações de Banco de Dados em Lote
Essa foi a correção de performance. Meu seeder criava tarefas uma por vez dentro de um loop:
// Before
foreach ($taskData as $data) {
Task::create($data);
}
// After
Task::insert($taskData);
Uma query em vez de N queries. Num seeder com 50 tarefas de exemplo, essa é a diferença entre 50 ida e voltas ao banco de dados e uma só. Escale isso para operações de dados em produção e você está olhando para ganhos de performance significativos.
Se você acompanhou as oito correções, vai notar algo: nenhuma delas é um bug. Cada mudança é sobre tornar código funcional melhor. Esse é um tipo fundamentalmente diferente de assistência de IA do que fomos treinados a esperar, e é por isso que acredito que essa funcionalidade importa mais do que a maioria percebe.
Rodando Simplify nos Seus Próprios Projetos: Passo a Passo
Quer experimentar você mesmo? Aqui está exatamente como eu rodo, incluindo as armadilhas que descobri.
1. Certifique-se de ter mudanças recentes na sua árvore de trabalho do git.
O Simplify opera sobre seu diff — a diferença entre seus arquivos atuais e seu último commit. Se você já fez commit de tudo, não há nada pra analisar. Eu normalmente rodo o Simplify antes de commitar, tratando-o como uma etapa de revisão pré-commit.
# Check that you have uncommitted changes
git status
git diff --stat
2. Rode o comando simplify no Claude Code.
/simplify
Isso é tudo. Um comando. O Claude Code cuida do resto — capturando seu diff, lançando os agentes de revisão, sintetizando os resultados.
3. Aguarde a análise.
Isso leva de 3 a 10 minutos dependendo de quanto código mudou. Minha experiência com um projeto Laravel de tamanho médio (uns 15 arquivos modificados) foi aproximadamente 8.5 minutos. Diffs maiores vão levar mais tempo.
Não entre em pânico se parecer lento. Três agentes estão rodando em paralelo, cada um fazendo uma análise profunda do seu código. Velocidade não é o objetivo aqui — profundidade é.
4. Revise as sugestões.
O Simplify apresenta seus achados como uma lista numerada de mudanças propostas, cada uma com:
- O que ele quer mudar
- Por que a mudança melhora o código
- Os arquivos específicos afetados
5. Aprove ou modifique.
Você pode aceitar todas as sugestões, escolher as específicas, ou pedir ao Claude Code pra modificar uma sugestão antes de aplicar. Eu quase sempre aceito as mudanças estruturais (extração de traits, criação de componentes) mas às vezes ajusto a nomenclatura.
Dica profissional: Rode git diff depois que o Simplify aplicar as mudanças. Leia o diff com cuidado. É aqui que você mais aprende — ver quais padrões a IA pegou e você não treina seu próprio olho de code review ao longo do tempo.
Armadilha comum: Se você está trabalhando numa branch de feature grande com centenas de mudanças, considere rodar o Simplify por etapas. Faça seu trabalho na camada de modelos, rode o Simplify, commite. Faça sua camada de componentes, rode o Simplify, commite. A análise é mais focada e as sugestões são mais acionáveis quando o diff tem escopo definido.
A Questão do Custo Que Ninguém Ignora
Vamos falar sobre tokens, porque isso importa.
Rodar /simplify no meu projeto Laravel consumiu aproximadamente 8% do orçamento de tokens da minha sessão. Estou no plano de $100/mês do Claude com o multiplicador 5x da Anthropic, o que dá uma margem generosa — mas 8% para uma única operação não é pouco.
Veja como eu penso na economia. Duas horas do meu tempo fazendo code review manual na minha taxa de consultoria superam de longe o custo fracionário dos tokens. Mesmo que você não cobre por hora, considere o custo de oportunidade. Essas duas horas gastas extraindo traits e criando componentes Blade são duas horas que você não está entregando funcionalidades ou pegando trabalho novo.
O uso de tokens também escala com o tamanho do seu diff. Um conjunto focado de mudanças em 5-6 arquivos pode consumir 3-4%. Uma passada massiva de geração de 30 arquivos pode chegar a 12-15%. Planejar seu trabalho em lotes menores mantém o custo por execução do Simplify mais baixo e os resultados mais direcionados.
Uma coisa que gostaria de ver em atualizações futuras: uma estimativa de tokens antes da análise rodar, pra você poder tomar uma decisão informada em diffs maiores. Agora, você se compromete com o custo quando aperta enter.
O Debate "É Só Escrever Código Melhor"
Preciso abordar isso porque surge toda vez que alguém demonstra o Simplify.
A crítica vai mais ou menos assim: "Por que a IA precisa de uma segunda passada pra corrigir seu próprio código? É só fazer o modelo gerar código melhor logo de cara." Vi variações dessa opinião de desenvolvedores que eu respeito. E entendo o instinto — parece uma gambiarra.
Mas o negócio é o seguinte. Esse argumento não entende como geração de código funciona num nível fundamental.
Quando você pede pra uma IA gerar um sistema CRUD, ela gera cada componente pra ser correto e independente. O formulário de criação funciona. O formulário de edição funciona. O dashboard funciona. Cada peça é individualmente sólida. A duplicação só fica visível quando você olha o sistema inteiro — quando coloca o componente de criação ao lado do de edição e percebe que compartilham 80% do código.
Isso é exatamente o que desenvolvedores humanos fazem. Escrevemos a primeira implementação pra funcionar. Depois refatoramos pra ficar limpo. "Faça funcionar, faça certo, faça rápido" é literalmente um ditado de programação que antecede a IA em décadas.
A funcionalidade simplify é a etapa do "faça certo", automatizada.
Na verdade, eu argumentaria que tentar gerar código perfeitamente refatorado na primeira passada produziria resultados piores. O modelo teria que resolver simultaneamente o problema funcional E otimizar para padrões entre arquivos, aumentando a chance de bugs sutis. Separar geração de otimização é boa engenharia — para humanos e IAs igualmente.
O que me fez mudar de ideia foi assistir os três agentes de revisão trabalhando. Cada um tem um foco estreito — reuso, qualidade, eficiência — e pegam coisas diferentes. Um modelo de passada única tentando otimizar para os três simultaneamente faria concessões que uma abordagem multi-agente evita. É a mesma razão pela qual code reviews funcionam melhor que auto-revisões. Olhos frescos, prioridades diferentes.
Dito isso, acho que a crítica aponta para uma tensão real no desenvolvimento assistido por IA. Queremos que essas ferramentas sejam mágicas, que produzam resultados perfeitos numa tacada só. A realidade é mais bagunçada e iterativa. Aceitar isso não significa se acomodar — significa construir fluxos de trabalho que levem isso em conta.
O Que Medi Depois de uma Semana com o Simplify
Rodei o /simplify em cinco projetos diferentes na última semana. Três apps Laravel, um projeto Next.js e um script de automação em Python. Aqui está o que observei.
Redução de código: Em todos os cinco projetos, o Simplify reduziu o total de linhas de código entre 15-40%. A maior redução foi o projeto Laravel Livewire (o que detalhei acima) com aproximadamente 38%. A menor foi o script Python com cerca de 15% — havia menos duplicação pra extrair.
Componentes únicos criados: O Simplify propôs criar de 3 a 7 novos componentes compartilhados, traits ou utilitários por projeto. Nem todos valiam a pena manter — às vezes a abstração era prematura pra uma base de código daquele tamanho — mas a maioria foi genuinamente útil.
Bugs prevenidos: Difícil de quantificar, mas encontrei dois casos onde a extração de constantes detectou valores de string inconsistentes entre arquivos. Esses teriam virado bugs eventualmente. Provavelmente durante uma demo.
Investimento de tempo: 3-10 minutos por execução, dependendo do tamanho do diff. Tempo ativo total por projeto (revisando e ajustando sugestões) foi de uns 15-20 minutos. Compare com as 1-2 horas de refatoração manual que isso substituiu.
Custo em tokens: 3-12% do orçamento de sessão por execução. Na média, cerca de 7% no meu uso.
Os números contam uma história clara, mas o valor real é mais difícil de medir. A base de código se sente diferente depois que o Simplify passa por ela. Os arquivos são mais curtos. Os padrões são consistentes. Quando você precisa fazer uma mudança, tem um lugar pra fazer, não quatro. Isso se acumula a cada futura sessão de edição.
Onde Fica Aquém (E O Que Eu Mudaria)
Estaria te fazendo um desserviço se não mencionasse as limitações, porque elas existem de verdade.
O Simplify pode abstrair demais. No meu projeto menor em Python, ele sugeriu extrair uma função auxiliar que era usada em apenas dois lugares. A função tinha três parâmetros, e chamá-la era mal mais curto que o código inline que substituía. Rejeitei essa sugestão. Nem todo padrão merece uma abstração — às vezes dois blocos de código similares são similares por coincidência, não por design.
O custo de tokens se acumula em sessões intensas de geração. Se você está numa sessão maratona gerando uma aplicação inteira, rodar o Simplify múltiplas vezes pode consumir 30-40% do seu orçamento de tokens. Comecei a ser mais estratégico sobre quando rodo — normalmente em pontos de parada naturais, não depois de cada pequena mudança.
Sem prévia do custo de tokens. Como mencionei, você não consegue ver quantos tokens o Simplify vai consumir antes de rodar. Adoraria uma flag --estimate que mostrasse o custo projetado baseado no tamanho do diff.
Sugestões específicas de framework variam em qualidade. As sugestões pra Laravel foram excelentes — a ferramenta claramente entende os padrões e convenções do framework. As sugestões pra Next.js foram boas mas ocasionalmente deixaram passar otimizações específicas do framework como Server Components. Sua experiência vai variar dependendo da sua stack.
Não consegue pegar problemas arquiteturais. O Simplify trabalha no nível do código — extraindo, consolidando, otimizando. Ele não te diz que toda sua abordagem de gerenciamento de estado está errada, ou que você deveria estar usando um padrão completamente diferente. Isso ainda é uma decisão humana.
Essas são limitações reais, mas nenhuma é definitiva. São o tipo de arestas que espero ver arredondadas nas próximas atualizações.
Isso Muda a Forma Como Trabalho com Geração de Código por IA
Aqui está o que mais me surpreendeu ao adotar o /simplify — não melhorou apenas meu código. Melhorou meu fluxo de trabalho.
Antes do Simplify, meu processo era: gerar código, revisar manualmente cada arquivo, refatorar a duplicação óbvia, commitar. A etapa de revisão manual era o gargalo, e vou ser honesto — em tardes cansadas, às vezes eu pulava. Mandava o código funcional-mas-bagunçado e prometia a mim mesmo que limparia depois. (Não limpava.)
Agora meu processo é: gerar código, rodar /simplify, revisar as sugestões em vez do código bruto, aprovar, commitar. A etapa de revisão é mais rápida porque estou avaliando mudanças propostas, não caçando problemas. E nunca pulo porque rodar um comando de uma palavra tem zero atrito.
A percepção mais profunda é esta: desenvolvimento assistido por IA não é um processo de etapa única, e quanto antes aceitarmos isso, melhor nosso código fica. Geração é a etapa um. Revisão e refinamento — seja por um humano, uma IA, ou ambos — é a etapa dois. O Simplify automatiza a etapa dois de uma forma genuinamente útil, não apenas cosmética.
Se você está construindo qualquer coisa com Claude Code — mesmo projetos pequenos — tente rodar /simplify na sua próxima passada de geração. Olhe o diff. Veja o que ele pega. Acho que você vai se surpreender, da mesma forma que eu me surpreendi, com os padrões escondidos à vista de todos.
E da próxima vez que alguém te disser que código gerado por IA é inerentemente bagunçado, você vai ter uma resposta de uma palavra só.
🤝 Vamos Trabalhar Juntos
Procurando construir sistemas de IA, automatizar fluxos de trabalho ou escalar sua infraestrutura de tecnologia? Adoraria ajudar.
- 🔗 Fiverr (desenvolvimento personalizado e integrações): fiverr.com/s/EgxYmWD
- 🌐 Portfólio: mejba.me
- 🏢 Ramlit Limited (soluções empresariais): ramlit.com
- 🎨 ColorPark (design e branding): colorpark.io
- 🛡 xCyberSecurity (serviços de segurança): xcybersecurity.io
