Claude Code Simplify: Mi Código Se Redujo un 40%
Vi mi terminal hacer algo que nunca había visto hacer a una herramienta de IA. Desarmó código que acababa de escribir — y lo mejoró.
No "mejoró" en el sentido vago y difuso con el que la gente suele usar esa palabra. Hablo de extraer traits reutilizables de componentes Livewire duplicados, convertir inserciones individuales en la base de datos en operaciones por lotes, y colapsar plantillas Blade infladas en partials limpios y modulares. El tipo de refactorización que un desarrollador senior hace durante una revisión de código — excepto que esto ocurrió en ocho minutos y medio, automáticamente, en un proyecto Laravel completo.
La función se llama /simplify, y se lanzó discretamente en una actualización reciente de Claude Code. La he estado ejecutando en cada proyecto durante la última semana, y ¿sinceramente? Ha cambiado por completo mi forma de pensar sobre el código generado por IA. No porque el resultado inicial fuera malo. Sino porque la segunda pasada detecta cosas que yo habría detectado por mi cuenta — tres días después, en una revisión de código, cuando corregirlo cuesta diez veces más esfuerzo.
Esto es lo que la mayoría de la gente entiende mal sobre esta función, y hay una razón específica por la que los del bando "simplemente genera mejor código desde el principio" no captan el punto. Llegaré a eso. Pero primero, necesitas entender qué hace realmente /simplify bajo el capó — porque es mucho más sofisticado que un linter.
Por Qué Tu Código Generado por IA Necesita una Segunda Revisión
Llevo más de un año desarrollando con Claude Code. Mis agentes de contenido, mis flujos de automatización, proyectos de clientes — todo pasa por Claude Code en algún momento. Y he notado un patrón difícil de refutar.
El código de primer borrador de cualquier modelo de IA — Claude, GPT, Gemini, da igual — tiende a resolver el problema correctamente pero de forma repetitiva. Pides un sistema CRUD, obtienes un componente de creación y uno de edición que comparten el 80% de su lógica pero duplican cada línea. Pides un dashboard, obtienes la misma cadena de estado codificada en cuatro archivos diferentes en lugar de extraerla de una constante.
Esto no es un error. En realidad es el comportamiento correcto para un modelo que optimiza para "darle al usuario código funcional ahora mismo". El modelo no tiene el contexto completo del proyecto como lo tiene un desarrollador humano que lleva meses viviendo en el código base. Genera cada archivo para que sea autónomo y funcional.
El problema aparece a escala. Cuando estás generando 10, 15, 20 archivos en una sesión — como yo estaba haciendo construyendo un sistema de gestión de tareas con Laravel Livewire — esas pequeñas duplicaciones se acumulan hasta convertirse en una pesadilla de mantenimiento.
Antes lo arreglaba manualmente. Abrir cada archivo, detectar los patrones, extraer la lógica compartida, verificar que nada se rompiera. Es el tipo de trabajo que lleva toda una tarde y se siente como si no debería ser tan tedioso. Ese es exactamente el vacío que llena /simplify — y lo hace con una arquitectura multi-agente que genuinamente me sorprendió cuando la vi en acción por primera vez.
Dentro de la Máquina: Cómo Funciona Realmente Simplify
Aquí es donde se pone técnico, y honestamente, esta es la parte que me hizo prestar atención de verdad.
Cuando ejecutas /simplify en Claude Code, no simplemente escanea tus archivos con una regex ni ejecuta un linter básico. El sistema inicia un pipeline de análisis en múltiples pasos que funciona así:
Paso 1: Captura del Git Diff. Simplify examina tus cambios más recientes — todo en tu árbol de trabajo que ha sido modificado desde tu último commit. Este alcance es inteligente porque significa que la herramienta solo analiza código que has tocado recientemente, no tu proyecto entero de 500 archivos.
Paso 2: Tres Agentes de Revisión en Paralelo. Esta es la parte que me voló la cabeza. El sistema lanza tres agentes independientes, cada uno ejecutándose en Sonnet por velocidad, y cada uno enfocado en una perspectiva diferente:
-
Agente 1 — Reutilización de Código: Escanea lógica duplicada entre archivos. Busca funciones, métodos o bloques de plantillas que aparecen en múltiples lugares con variaciones menores. Propone extracciones en traits, componentes o utilidades compartidas.
-
Agente 2 — Calidad de Código: Evalúa convenciones de nomenclatura, patrones estructurales, uso adecuado de las características del framework. Detecta cosas como usar cadenas de texto directas en lugar de constantes, o construir algo desde cero cuando el framework ya tiene una solución incorporada.
-
Agente 3 — Eficiencia de Código: Se enfoca en rendimiento. Consultas a base de datos dentro de bucles, re-renderizados innecesarios, operaciones que podrían agruparse en lotes, oportunidades de caché.
Paso 3: Síntesis del Agente Principal. Los hallazgos de los tres agentes se alimentan a un modelo de razonamiento principal que sintetiza sus recomendaciones, resuelve cualquier conflicto entre sugerencias y produce una lista priorizada de correcciones.
Paso 4: Implementación. Claude Code aplica los cambios — con tu aprobación — directamente a tus archivos. Sin copiar y pegar. Sin cambiar entre herramientas. Solo un git diff que puedes revisar.
Todo el proceso tomó 8 minutos y 36 segundos en mi proyecto Laravel. Eso no es instantáneo, pero considera lo que pasó en esos ocho minutos: tres analistas de IA separados revisaron cada archivo que yo había cambiado, cruzaron patrones a lo largo de todo el diff, y produjeron una refactorización accionable que me habría tomado — siendo honesto — al menos dos horas de trabajo de revisión concentrado.
Ese intercambio tiene sentido para mí. Siempre.
Mi Proyecto Laravel: Ocho Correcciones Que Realmente Importaron
Déjame guiarte exactamente por lo que /simplify encontró en mi proyecto de gestión de tareas. Estaba construyendo un sistema CRUD basado en Livewire — crear tareas, editar tareas, dashboard para visualizarlas — y acababa de terminar la pasada inicial de generación. Todo funcionaba. Los tests pasaban. El código estaba bien.
"Bien" es el enemigo de lo bueno, y /simplify me mostró exactamente dónde.
Corrección 1: Constantes en Lugar de Cadenas Mágicas
El modelo Task tenía valores de estado y prioridad dispersos por los archivos como cadenas de texto sin procesar — "pending", "in_progress", "completed" en el controlador, las mismas cadenas en las plantillas Blade, de nuevo en la lógica de filtros del dashboard. Simplify propuso agregar constantes al propio 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';
}
Ahora, yo preferiría enums de PHP aquí — que se lanzaron en PHP 8.1 y son el enfoque moderno — pero el principio es completamente correcto. Centralizar estos valores significa que los cambias en un solo lugar, y cada referencia se actualiza. El hecho de que una IA detectara esto a través de múltiples archivos simultáneamente es impresionante.
Consejo profesional: Si estás en PHP 8.1+, toma la sugerencia de constantes de Simplify y conviértela en un backed enum. Obtienes seguridad de tipos gratis.
Corrección 2: Extracción de un Trait de Formulario Compartido
Esta fue la grande. Mis componentes Livewire CreateTask y EditTask compartían aproximadamente el 80% de su lógica de manejo de formularios — reglas de validación, definiciones de propiedades, el flujo de guardado. Simplify propuso un trait HasTaskForm que ambos componentes pudieran 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 de esta extracción, cambiar una regla de validación significaba actualizar dos archivos. Olvidar uno crearía bugs sutiles y exasperantes donde crear una tarea aplicaba reglas diferentes a editarla. He visto este problema exacto en aplicaciones en producción. Siempre es vergonzoso.
Corrección 3: Consistencia del Dashboard con Constantes del Modelo
Una vez que las constantes existían en el modelo, Simplify actualizó el componente del dashboard para referenciarlas en lugar de cadenas directas. Cambio pequeño, impacto enorme en la mantenibilidad:
// Before
$tasks->where('status', 'completed')->count();
// After
$tasks->where('status', Task::STATUS_COMPLETED)->count();
Este es el tipo de corrección que toma 30 segundos hacer pero previene horas de depuración cuando alguien decide que "completed" debería ser "done" seis meses después.
Corrección 4: Uso Adecuado de Componentes en Blade
Tenía un botón envuelto en una etiqueta anchor — <a href="..."><button>Create Task</button></a>. Anti-patrón HTML clásico. Simplify notó que estaba usando la biblioteca de componentes Flux UI y propuso convertirlo al componente de botón Flux apropiado con navegación incorporada.
¿Pequeño? Sí. Pero es exactamente el tipo de cosa que causa problemas de accesibilidad y falla la validación HTML. Un desarrollador senior lo detectaría en una revisión de código. Ahora la IA lo detecta primero.
Corrección 5: Extracción de un Componente Reutilizable de Fila de Tarea
Mi plantilla Blade del dashboard tenía la misma estructura de div repetida para cada visualización de tarea — badge de estado, título, indicador de prioridad, botones de acción. El mismo HTML, copiado y pegado con cambios menores de variables. Simplify propuso un componente Blade <x-task-row>:
<!-- Before: 40 lines repeated 3 times -->
<!-- After: -->
<x-task-row :task="$task" />
El componente encapsula toda la lógica de visualización. ¿Cambiar cómo se ven las tareas? Edita un archivo. ¿Agregar un nuevo botón de acción? Un solo lugar. Solo esto eliminó alrededor de 120 líneas de mi plantilla del dashboard.
Corrección 6: Partial de Formulario Compartido para Vistas de Crear y Editar
Similar a la extracción del trait, las plantillas Blade para los formularios de crear y editar eran casi idénticas. Simplify propuso un único partial _task-form.blade.php que acepta un parámetro opcional $task:
@include('tasks._task-form', ['task' => $task ?? null])
El partial rellena condicionalmente los campos al editar y los deja vacíos al crear. Una plantilla, dos casos de uso. Limpio.
Corrección 7: Limpieza de Sentencias Include Verbosas
Algunas de mis directivas Blade @include se habían vuelto innecesariamente complejas — rutas largas, arrays de datos anidados que podían simplificarse. Simplify las acortó sin cambiar el comportamiento. Una mejora de legibilidad.
Corrección 8: Operaciones de Base de Datos por Lotes
Esta fue la corrección de rendimiento. Mi seeder creaba tareas de una en una dentro de un bucle:
// Before
foreach ($taskData as $data) {
Task::create($data);
}
// After
Task::insert($taskData);
Una consulta en lugar de N consultas. En un seeder con 50 tareas de ejemplo, esa es la diferencia entre 50 viajes de ida y vuelta a la base de datos y uno solo. Escala eso a operaciones de datos en producción y estás viendo mejoras de rendimiento significativas.
Si has seguido las ocho correcciones, notarás algo: ninguna es un bug. Cada cambio trata de hacer que código funcional sea mejor. Ese es un tipo fundamentalmente diferente de asistencia de IA al que nos han acostumbrado a esperar, y es por eso que creo que esta función importa más de lo que la mayoría de la gente piensa.
Ejecutando Simplify en Tus Propios Proyectos: Paso a Paso
¿Quieres probarlo tú mismo? Así es exactamente como lo ejecuto, incluyendo las trampas que he descubierto.
1. Asegúrate de tener cambios recientes en tu árbol de trabajo de git.
Simplify opera sobre tu diff — la diferencia entre tus archivos actuales y tu último commit. Si ya has hecho commit de todo, no hay nada que analizar. Yo normalmente ejecuto Simplify antes de hacer commit, tratándolo como un paso de revisión pre-commit.
# Check that you have uncommitted changes
git status
git diff --stat
2. Ejecuta el comando simplify en Claude Code.
/simplify
Eso es todo. Un comando. Claude Code se encarga del resto — capturando tu diff, lanzando los agentes de revisión, sintetizando los resultados.
3. Espera el análisis.
Esto toma entre 3 y 10 minutos dependiendo de cuánto código cambió. Mi experiencia con un proyecto Laravel de tamaño mediano (unos 15 archivos modificados) fue aproximadamente 8.5 minutos. Diffs más grandes tomarán más tiempo.
No te asustes si parece lento. Tres agentes están ejecutándose en paralelo, cada uno haciendo un análisis exhaustivo de tu código. La velocidad no es el objetivo aquí — la profundidad sí.
4. Revisa las sugerencias.
Simplify presenta sus hallazgos como una lista numerada de cambios propuestos, cada uno con:
- Qué quiere cambiar
- Por qué el cambio mejora el código
- Los archivos específicos afectados
5. Aprueba o modifica.
Puedes aceptar todas las sugerencias, seleccionar las específicas, o pedirle a Claude Code que modifique una sugerencia antes de aplicarla. Yo casi siempre acepto los cambios estructurales (extracción de traits, creación de componentes) pero a veces ajusto los nombres.
Consejo profesional: Ejecuta git diff después de que Simplify aplique sus cambios. Lee el diff cuidadosamente. Aquí es donde más aprendes — ver qué patrones detectó la IA que tú pasaste por alto entrena tu propio ojo de revisión de código con el tiempo.
Trampa común: Si estás trabajando en una rama de feature grande con cientos de cambios, considera ejecutar Simplify por etapas. Haz tu trabajo de capa de modelos, ejecuta Simplify, haz commit. Haz tu capa de componentes, ejecuta Simplify, haz commit. El análisis es más enfocado y las sugerencias son más accionables cuando el diff tiene un alcance definido.
La Pregunta del Costo Que Nadie Ignora
Hablemos de tokens, porque esto importa.
Ejecutar /simplify en mi proyecto Laravel consumió aproximadamente el 8% del presupuesto de tokens de mi sesión. Estoy en el plan de $100/mes de Claude con el multiplicador 5x de Anthropic, lo que da un margen generoso — pero 8% para una sola operación no es insignificante.
Así es como pienso en la economía. Dos horas de mi tiempo haciendo revisión de código manual a mi tarifa de consultoría superan con creces el costo fraccionario de los tokens. Incluso si no cobras por hora, considera el costo de oportunidad. Esas dos horas gastadas extrayendo traits y creando componentes Blade son dos horas que no estás enviando funcionalidades o tomando nuevo trabajo.
El uso de tokens también escala con el tamaño de tu diff. Un conjunto enfocado de cambios en 5-6 archivos podría consumir 3-4%. Una pasada masiva de generación de 30 archivos podría llegar al 12-15%. Planificar tu trabajo en lotes más pequeños mantiene el costo por ejecución de Simplify más bajo y los resultados más dirigidos.
Algo que me gustaría ver en futuras actualizaciones: una estimación de tokens antes de que se ejecute el análisis, para que puedas tomar una decisión informada en diffs más grandes. Ahora mismo, te comprometes con el costo cuando presionas enter.
El Debate de "Simplemente Escribe Mejor Código"
Necesito abordar esto porque surge cada vez que alguien demuestra Simplify.
La crítica va algo así: "¿Por qué la IA necesita una segunda pasada para arreglar su propio código? Simplemente haz que el modelo genere mejor código desde el principio." He visto variaciones de esta opinión de desarrolladores que respeto. Y entiendo el instinto — se siente como un parche.
Pero aquí está el asunto. Este argumento malinterpreta cómo funciona la generación de código a un nivel fundamental.
Cuando le pides a una IA que genere un sistema CRUD, genera cada componente para que sea correcto y autónomo. El formulario de creación funciona. El formulario de edición funciona. El dashboard funciona. Cada pieza es individualmente sólida. La duplicación solo se hace visible cuando miras a través de todo el sistema — cuando pones el componente de creación junto al de edición y notas que comparten el 80% de su código.
Esto es exactamente lo que hacen los desarrolladores humanos. Escribimos la primera implementación para que funcione. Luego refactorizamos para que quede limpio. "Haz que funcione, haz que sea correcto, haz que sea rápido" es literalmente un axioma de programación que precede a la IA por décadas.
La función simplify es el paso de "haz que sea correcto", automatizado.
De hecho, argumentaría que intentar generar código perfectamente refactorizado en la primera pasada produciría peores resultados. El modelo tendría que resolver simultáneamente el problema funcional Y optimizar para patrones entre archivos, aumentando la probabilidad de bugs sutiles. Separar generación de optimización es buena ingeniería — para humanos e IAs por igual.
Lo que me hizo cambiar de opinión fue ver a los tres agentes de revisión trabajar. Cada uno tiene un enfoque estrecho — reutilización, calidad, eficiencia — y detectan cosas diferentes. Un modelo de una sola pasada intentando optimizar para los tres simultáneamente haría concesiones que un enfoque multi-agente evita. Es la misma razón por la que las revisiones de código funcionan mejor que las auto-revisiones. Ojos frescos, prioridades diferentes.
Dicho esto, creo que la crítica apunta a una tensión real en el desarrollo asistido por IA. Queremos que estas herramientas sean mágicas, que produzcan resultados perfectos en un solo intento. La realidad es más desordenada e iterativa. Aceptar eso no significa conformarse — significa construir flujos de trabajo que lo contemplen.
Lo Que He Medido Después de una Semana con Simplify
Ejecuté /simplify en cinco proyectos diferentes durante la última semana. Tres aplicaciones Laravel, un proyecto Next.js y un script de automatización en Python. Esto es lo que observé.
Reducción de código: En los cinco proyectos, Simplify redujo el total de líneas de código entre un 15-40%. La mayor reducción fue el proyecto Laravel Livewire (el que detallé arriba) con aproximadamente un 38%. La menor fue el script de Python con cerca del 15% — había menos duplicación que extraer.
Componentes únicos creados: Simplify propuso crear entre 3 y 7 nuevos componentes compartidos, traits o utilidades por proyecto. No todos valían la pena conservar — a veces la abstracción era prematura para un código base de ese tamaño — pero la mayoría fueron genuinamente útiles.
Bugs prevenidos: Difícil de cuantificar, pero encontré dos casos donde la extracción de constantes detectó valores de cadena inconsistentes entre archivos. Estos habrían sido bugs eventualmente. Probablemente durante una demo.
Inversión de tiempo: 3-10 minutos por ejecución, dependiendo del tamaño del diff. El tiempo activo total por proyecto (revisando y ajustando sugerencias) fue de unos 15-20 minutos. Compara con las 1-2 horas de refactorización manual que esto reemplazó.
Costo en tokens: 3-12% del presupuesto de sesión por ejecución. Promediando alrededor del 7% en mi uso.
Los números cuentan una historia clara, pero el valor real es más difícil de medir. El código base se siente diferente después de que Simplify lo procesa. Los archivos son más cortos. Los patrones son consistentes. Cuando necesitas hacer un cambio, hay un solo lugar donde hacerlo, no cuatro. Eso se acumula con cada futura sesión de edición.
Donde Se Queda Corto (Y Qué Cambiaría)
Te haría un flaco servicio si no mencionara las limitaciones, porque las hay de verdad.
Simplify puede sobre-abstraer. En mi proyecto más pequeño de Python, sugirió extraer una función auxiliar que solo se usaba en dos lugares. La función tenía tres parámetros, y llamarla era apenas más corto que el código inline que reemplazaba. Rechacé esa sugerencia. No todo patrón merece una abstracción — a veces dos bloques de código similares son similares por coincidencia, no por diseño.
El costo de tokens se acumula durante sesiones intensas de generación. Si estás en una sesión maratónica generando una aplicación completa, ejecutar Simplify múltiples veces puede consumir el 30-40% de tu presupuesto de tokens. He empezado a ser más estratégico sobre cuándo lo ejecuto — normalmente en puntos de parada naturales, no después de cada pequeño cambio.
Sin vista previa del costo de tokens. Como mencioné, no puedes ver cuántos tokens consumirá Simplify antes de ejecutarlo. Me encantaría un flag --estimate que muestre el costo proyectado basado en el tamaño del diff.
Las sugerencias específicas de framework varían en calidad. Las sugerencias para Laravel fueron excelentes — la herramienta claramente entiende los patrones y convenciones del framework. Las sugerencias para Next.js fueron buenas pero ocasionalmente pasaron por alto optimizaciones específicas del framework como Server Components. Tu experiencia variará dependiendo de tu stack.
No puede detectar problemas arquitectónicos. Simplify trabaja a nivel de código — extrayendo, consolidando, optimizando. No te dice que todo tu enfoque de gestión de estado está mal, o que deberías estar usando un patrón completamente diferente. Eso sigue siendo una decisión humana.
Estas son limitaciones reales, pero ninguna es un factor decisivo. Son el tipo de asperezas que espero que se suavicen en las próximas actualizaciones.
Esto Cambia Mi Forma de Trabajar con Generación de Código por IA
Esto es lo que más me sorprendió al adoptar /simplify — no solo mejoró mi código. Mejoró mi flujo de trabajo.
Antes de Simplify, mi proceso era: generar código, revisar manualmente cada archivo, refactorizar la duplicación obvia, hacer commit. El paso de revisión manual era el cuello de botella, y seré honesto — en tardes de cansancio, a veces me lo saltaba. Enviar el código funcional-pero-desordenado y prometerme que lo limpiaría después. (No lo hacía.)
Ahora mi proceso es: generar código, ejecutar /simplify, revisar las sugerencias en lugar del código crudo, aprobar, hacer commit. El paso de revisión es más rápido porque estoy evaluando cambios propuestos, no cazando problemas. Y nunca me lo salto porque ejecutar un comando de una sola palabra tiene cero fricción.
La perspectiva más profunda es esta: el desarrollo asistido por IA no es un proceso de un solo paso, y cuanto antes lo aceptemos, mejor será nuestro código. La generación es el paso uno. La revisión y el refinamiento — ya sea por un humano, una IA, o ambos — es el paso dos. Simplify automatiza el paso dos de una manera que es genuinamente útil, no solo cosmética.
Si estás construyendo cualquier cosa con Claude Code — incluso proyectos pequeños — prueba ejecutar /simplify en tu próxima pasada de generación. Mira el diff. Observa qué detecta. Creo que te sorprenderás, de la misma forma que me sorprendí yo, por los patrones escondidos a simple vista.
Y la próxima vez que alguien te diga que el código generado por IA es inherentemente desordenado, tendrás una respuesta de una sola palabra.
🤝 Trabajemos Juntos
¿Buscas construir sistemas de IA, automatizar flujos de trabajo o escalar tu infraestructura tecnológica? Me encantaría ayudarte.
- 🔗 Fiverr (desarrollo personalizado e integraciones): fiverr.com/s/EgxYmWD
- 🌐 Portfolio: mejba.me
- 🏢 Ramlit Limited (soluciones empresariales): ramlit.com
- 🎨 ColorPark (diseño y branding): colorpark.io
- 🛡 xCyberSecurity (servicios de seguridad): xcybersecurity.io
