Claude Code Simplify: Mijn Code Werd 40% Korter
Ik keek toe terwijl mijn terminal iets deed wat ik nog nooit een AI-tool heb zien doen. Het haalde code die het net had geschreven uit elkaar — en maakte het beter.
Niet "beter" op de vage, handwuivende manier waarop mensen dat woord rondstrooien. Ik heb het over het extraheren van herbruikbare traits uit gedupliceerde Livewire-componenten, het converteren van één-voor-één database-inserts naar batch-operaties, en het samenvouwen van opgeblazen Blade-templates tot schone, modulaire partials. Het soort refactoring dat een senior developer doet tijdens een code review — behalve dat dit in acht en een halve minuut gebeurde, automatisch, over een heel Laravel-project.
De functie heet /simplify, en het werd stilletjes uitgebracht in een recente Claude Code update. Ik draai het al een week op elk project, en eerlijk? Het heeft veranderd hoe ik denk over AI-gegenereerde code. Niet omdat de initiële output slecht was. Maar omdat de tweede doorgang dingen opvangt die ik zelf zou hebben opgemerkt — drie dagen later, in een code review, wanneer het fixen tien keer meer moeite kost.
Dit is wat de meeste mensen fout begrijpen aan deze functie, en er is een specifieke reden waarom de "genereer gewoon betere code de eerste keer" menigte het punt mist. Ik kom daar op terug. Maar eerst moet je begrijpen wat /simplify daadwerkelijk doet onder de motorkap — want het is veel geavanceerder dan een linter.
Waarom Je AI-Gegenereerde Code een Tweede Blik Nodig Heeft
Ik bouw nu al ruim een jaar met Claude Code. Mijn content-agents, mijn automatiseringsworkflows, klantprojecten — alles loopt op een bepaald moment door Claude Code. En ik heb een patroon opgemerkt dat moeilijk te weerleggen is.
Eerste-versie code van elk AI-model — Claude, GPT, Gemini, maakt niet uit — lost het probleem meestal correct maar repetitief op. Je vraagt om een CRUD-systeem, je krijgt een create-component en een edit-component die 80% van hun logica delen maar elke regel dupliceren. Je vraagt om een dashboard, je krijgt dezelfde statusstring hardcoded in vier verschillende bestanden in plaats van opgehaald uit een constante.
Dit is geen bug. Het is eigenlijk het juiste gedrag voor een model dat optimaliseert voor "geef de gebruiker nu werkende code." Het model heeft niet de volledige projectcontext zoals een menselijke developer die al maanden in de codebase leeft. Het genereert elk bestand om op zichzelf staand en functioneel te zijn.
Het probleem toont zich op schaal. Wanneer je 10, 15, 20 bestanden genereert in een sessie — zoals ik deed bij het bouwen van een taakbeheersysteem met Laravel Livewire — stapelen die kleine duplicaties zich op tot een onderhoudsnachtmerrie.
Ik loste dit vroeger handmatig op. Elk bestand openen, de patronen herkennen, de gedeelde logica extraheren, testen dat niets kapot ging. Het is het soort werk dat een middag kost en aanvoelt alsof het niet zo vervelend zou moeten zijn. Dat is precies de kloof die /simplify vult — en het doet het met een multi-agent architectuur die me oprecht verraste toen ik het voor het eerst in actie zag.
Onder de Motorkap: Hoe Simplify Echt Werkt
Hier wordt het technisch, en eerlijk gezegd is dit het deel dat me deed opletten.
Wanneer je /simplify draait in Claude Code, scant het niet gewoon je bestanden met een regex of draait het een simpele linter. Het systeem start een meerstaps analysepijplijn die als volgt werkt:
Stap 1: Git Diff Capture. Simplify kijkt naar je laatste wijzigingen — alles in je working tree dat is gewijzigd sinds je laatste commit. Deze afbakening is slim omdat het betekent dat de tool alleen code analyseert die je recent hebt aangeraakt, niet je hele project van 500 bestanden.
Stap 2: Drie Parallelle Review-Agents. Dit is het deel dat me versteld deed staan. Het systeem lanceert drie onafhankelijke agents, elk draaiend op Sonnet voor snelheid, en elk gericht op een andere lens:
-
Agent 1 — Code Hergebruik: Scant op gedupliceerde logica over bestanden heen. Zoekt naar functies, methoden of template-blokken die op meerdere plaatsen verschijnen met kleine variaties. Stelt extracties voor naar gedeelde traits, componenten of utilities.
-
Agent 2 — Code Kwaliteit: Evalueert naamgevingsconventies, structurele patronen, correct gebruik van framework-functies. Vangt dingen op zoals het gebruik van ruwe strings in plaats van constanten, of iets vanaf nul bouwen wanneer het framework al een ingebouwde heeft.
-
Agent 3 — Code Efficiëntie: Focust op prestaties. Database-queries in loops, onnodige re-renders, operaties die gebatcht kunnen worden, caching-mogelijkheden.
Stap 3: Hoofdagent Synthese. De bevindingen van alle drie agents worden ingevoerd in een primair redeneermodel dat hun aanbevelingen synthetiseert, eventuele conflicten tussen suggesties oplost, en een geprioriteerde lijst met fixes produceert.
Stap 4: Implementatie. Claude Code past de wijzigingen toe — met jouw goedkeuring — direct op je bestanden. Geen kopiëren en plakken. Geen wisselen tussen tools. Gewoon een git diff die je kunt reviewen.
Het hele proces duurde 8 minuten en 36 seconden op mijn Laravel-project. Dat is niet instant, maar bedenk wat er in die acht minuten gebeurde: drie aparte AI-analisten reviewden elk bestand dat ik had gewijzigd, kruisrefereerden patronen over de hele diff, en produceerden bruikbare refactoring die mij — eerlijk gezegd — minstens twee uur gefocust reviewwerk zou hebben gekost.
Die afweging is voor mij logisch. Elke keer.
Mijn Laravel-Project: Acht Fixes Die Er Echt Toe Deden
Laat me je precies doorlopen wat /simplify vond op mijn taakbeheerproject. Ik was een op Livewire gebaseerd CRUD-systeem aan het bouwen — taken aanmaken, taken bewerken, dashboard om ze te bekijken — en had net de initiële generatiedoorgang afgerond. Alles werkte. Tests slaagden. De code was prima.
"Prima" is de vijand van goed, en /simplify liet me precies zien waar.
Fix 1: Constanten in Plaats van Magische Strings
Het Task-model had status- en prioriteitswaarden verspreid over bestanden als ruwe strings — "pending", "in_progress", "completed" in de controller, dezelfde strings in de Blade-templates, weer in de dashboard filterlogica. Simplify stelde voor om constanten aan het model zelf toe te voegen.
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';
}
Nu zou ik eigenlijk PHP enums prefereren hier — die in PHP 8.1 zijn gelanceerd en de moderne aanpak zijn — maar het principe klopt volledig. Het centraliseren van deze waarden betekent dat je ze op één plek wijzigt, en elke referentie wordt bijgewerkt. Het feit dat een AI dit over meerdere bestanden tegelijk opmerkte is indrukwekkend.
Pro tip: Als je op PHP 8.1+ zit, neem Simplify's constante-suggestie en upgrade het naar een backed enum. Je krijgt type safety gratis.
Fix 2: Een Gedeelde Form Trait Extraheren
Dit was de grote. Mijn CreateTask en EditTask Livewire-componenten deelden ongeveer 80% van hun formulierverwerkingslogica — validatieregels, property-definities, de save-workflow. Simplify stelde een HasTaskForm trait voor die beide componenten konden gebruiken.
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;
}
}
Vóór deze extractie betekende het wijzigen van een validatieregel dat je twee bestanden moest bijwerken. Eén missen zou subtiele, frustrerende bugs creëren waarbij het aanmaken van een taak andere regels afdwong dan het bewerken ervan. Ik heb dit exacte probleem in productie-apps gezien. Het is altijd gênant.
Fix 3: Dashboard Consistentie met Model Constanten
Zodra de constanten in het model bestonden, werkte Simplify het dashboard-component bij om ernaar te verwijzen in plaats van ruwe strings. Kleine wijziging, enorme impact op onderhoudbaarheid:
// Vóór
$tasks->where('status', 'completed')->count();
// Na
$tasks->where('status', Task::STATUS_COMPLETED)->count();
Dit is het soort fix dat 30 seconden kost om te maken maar uren debugging voorkomt wanneer iemand beslist dat "completed" eigenlijk "done" moet zijn over zes maanden.
Fix 4: Correct Componentgebruik in Blade
Ik had een button gewrapped in een anchor-tag — <a href="..."><button>Create Task</button></a>. Klassiek HTML-antipatroon. Simplify merkte op dat ik de Flux UI-componentbibliotheek gebruikte en stelde voor het te converteren naar het juiste Flux-buttoncomponent met ingebouwde navigatie.
Klein? Ja. Maar het is precies het soort ding dat toegankelijkheidsproblemen veroorzaakt en HTML-validatie faalt. Een senior developer zou het opmerken in code review. Nu vangt de AI het eerst op.
Fix 5: Een Herbruikbaar Task Row Component Extraheren
Mijn dashboard Blade-template had dezelfde div-structuur herhaald voor elke taakweergave — statusbadge, titel, prioriteitsindicator, actieknoppen. Dezelfde HTML, gekopieerd en geplakt met kleine variabelewijzigingen. Simplify stelde een <x-task-row> Blade-component voor:
<!-- Vóór: 40 regels 3 keer herhaald -->
<!-- Na: -->
<x-task-row :task="$task" />
Het component kapselt alle weergavelogica in. Hoe taken eruitzien veranderen? Eén bestand bewerken. Een nieuwe actieknop toevoegen? Eén plek. Dit alleen al schrapte ongeveer 120 regels uit mijn dashboard-template.
Fix 6: Gedeelde Form Partial voor Create- en Edit-Views
Vergelijkbaar met de trait-extractie waren de Blade-templates voor create- en edit-formulieren bijna identiek. Simplify stelde een enkele _task-form.blade.php partial voor die een optionele $task parameter accepteert:
@include('tasks._task-form', ['task' => $task ?? null])
De partial vult velden conditioneel vooraf in bij bewerking en laat ze leeg bij aanmaking. Eén template, twee gebruiksscenario's. Schoon.
Fix 7: Opschonen van Uitgebreide Include-Statements
Sommige van mijn Blade @include-directieven waren onnodig complex geworden — lange paden, geneste data-arrays die vereenvoudigd konden worden. Simplify verkortte ze zonder het gedrag te veranderen. Een leesbaarheidswinst.
Fix 8: Batch Database-Operaties
Dit was de prestatiefix. Mijn seeder maakte taken één voor één aan in een loop:
// Vóór
foreach ($taskData as $data) {
Task::create($data);
}
// Na
Task::insert($taskData);
Eén query in plaats van N queries. Op een seeder met 50 voorbeeldtaken is dat het verschil tussen 50 database-roundtrips en één. Schaal dat naar productie-dataoperaties en je kijkt naar betekenisvolle prestatiewinst.
Als je alle acht fixes hebt gevolgd, merk je iets op: geen van deze zijn bugs. Elke wijziging gaat over het beter maken van werkende code. Dat is een fundamenteel ander soort AI-assistentie dan we gewend zijn te verwachten, en het is waarom ik denk dat deze functie meer betekent dan de meeste mensen beseffen.
Simplify Draaien op Je Eigen Projecten: Stap voor Stap
Wil je dit zelf proberen? Hier is precies hoe ik het draai, inclusief de valkuilen die ik heb ontdekt.
1. Zorg dat je recente wijzigingen hebt in je git working tree.
Simplify werkt op je diff — het verschil tussen je huidige bestanden en je laatste commit. Als je alles al hebt gecommit, is er niets te analyseren. Ik draai Simplify meestal vóór het committen, als pre-commit reviewstap.
# Controleer dat je uncommitted changes hebt
git status
git diff --stat
2. Draai het simplify-commando in Claude Code.
/simplify
Dat is het. Eén commando. Claude Code regelt de rest — het vastleggen van je diff, het lanceren van de review-agents, het synthetiseren van de resultaten.
3. Wacht op de analyse.
Dit duurt ergens tussen de 3-10 minuten afhankelijk van hoeveel code er is gewijzigd. Mijn ervaring met een middelgroot Laravel-project (ongeveer 15 gewijzigde bestanden) was ruwweg 8,5 minuten. Grotere diffs duren langer.
Raak niet in paniek als het langzaam lijkt. Drie agents draaien parallel, elk een grondige analyse van je code uitvoerend. Snelheid is hier niet het doel — diepte wel.
4. Review de suggesties.
Simplify presenteert zijn bevindingen als een genummerde lijst van voorgestelde wijzigingen, elk met:
- Wat het wil veranderen
- Waarom de wijziging de code verbetert
- De specifieke bestanden die beïnvloed worden
5. Goedkeuren of aanpassen.
Je kunt alle suggesties accepteren, specifieke cherry-picken, of Claude Code vragen een suggestie aan te passen voordat het wordt toegepast. Ik accepteer bijna altijd de structurele wijzigingen (trait-extractie, componentcreatie) maar pas soms de naamgeving aan.
Pro tip: Draai git diff nadat Simplify zijn wijzigingen heeft toegepast. Lees de diff zorgvuldig door. Dit is waar je het meest leert — zien welke patronen de AI opmerkte die jij miste, traint je eigen code review-oog na verloop van tijd.
Veelgemaakte fout: Als je werkt op een grote feature-branch met honderden wijzigingen, overweeg dan Simplify in fasen te draaien. Doe je model-laag werk, draai Simplify, commit. Doe je component-laag, draai Simplify, commit. De analyse is gerichter en de suggesties bruikbaarder wanneer de diff is afgebakend.
De Kostenvraag Die Niemand Negeert
Laten we het over tokens hebben, want dit doet ertoe.
Het draaien van /simplify op mijn Laravel-project verbruikte ongeveer 8% van het tokenbudget van mijn sessie. Ik zit op het $100/maand Claude-plan met de 5x Anthropic-multiplier, wat ruime marge geeft — maar 8% voor een enkele operatie is niet niets.
Zo denk ik over de economie. Twee uur van mijn tijd handmatige code review tegen mijn consultancy-tarief overtreft ruim de fractionele kosten van tokens. Zelfs als je niet per uur factureert, bedenk de opportuniteitskosten. Die twee uur besteed aan het extraheren van traits en het creëren van Blade-componenten zijn twee uur die je niet besteedt aan het leveren van features of het aannemen van nieuw werk.
Het tokengebruik schaalt ook met je diffgrootte. Een gerichte set wijzigingen aan 5-6 bestanden kan 3-4% verbruiken. Een massieve generatiedoorgang van 30 bestanden kan 12-15% halen. Het plannen van je werk in kleinere batches houdt de kosten per Simplify-run lager en de resultaten gerichter.
Eén ding dat ik graag zou zien in toekomstige updates: een tokenschatting voordat de analyse draait, zodat je een geïnformeerde keuze kunt maken bij grotere diffs. Op dit moment commit je aan de kosten wanneer je op enter drukt.
Het "Schrijf Gewoon Betere Code" Debat
Ik moet dit adresseren omdat het elke keer opkomt wanneer iemand Simplify demonstreert.
De kritiek gaat ongeveer zo: "Waarom heeft de AI een tweede doorgang nodig om zijn eigen code te fixen? Laat het model gewoon betere code genereren de eerste keer." Ik heb variaties van deze mening gezien van developers die ik respecteer. En ik begrijp het instinct — het voelt als een hack.
Maar hier is het punt. Dit argument begrijpt verkeerd hoe codegeneratie op fundamenteel niveau werkt.
Wanneer je een AI vraagt om een CRUD-systeem te genereren, genereert het elk component om correct en op zichzelf staand te zijn. Het create-formulier werkt. Het edit-formulier werkt. Het dashboard werkt. Elk onderdeel is individueel solide. De duplicatie wordt pas zichtbaar wanneer je over het hele systeem kijkt — wanneer je het create-component naast het edit-component houdt en merkt dat ze 80% van hun code delen.
Dit is precies wat menselijke developers doen. We schrijven de eerste implementatie om het werkend te krijgen. Dan refactoren we om het schoon te maken. "Make it work, make it right, make it fast" is letterlijk een programmeerwijsheid die decennia ouder is dan AI.
De simplify-functie is de "make it right" stap, geautomatiseerd.
Ik zou eigenlijk beweren dat proberen om perfect gerefactorde code te genereren bij de eerste doorgang slechtere resultaten zou opleveren. Het model zou tegelijkertijd het functionele probleem EN optimalisatie voor cross-bestand patronen moeten oplossen, waardoor de kans op subtiele bugs toeneemt. Het scheiden van generatie en optimalisatie is goed engineering — voor mensen en AI's gelijk.
Wat mij van gedachten deed veranderen was het kijken naar de drie review-agents die werkten. Elk heeft een nauwe focus — hergebruik, kwaliteit, efficiëntie — en ze vangen verschillende dingen op. Een single-pass model dat probeert te optimaliseren voor alle drie tegelijk zou afwegingen maken die een multi-agent aanpak vermijdt. Het is dezelfde reden waarom code reviews beter werken dan zelf-reviews. Verse ogen, andere prioriteiten.
Dat gezegd hebbende, ik denk dat de kritiek wijst op een echte spanning in AI-ondersteunde ontwikkeling. We willen dat deze tools magisch zijn, dat ze perfecte output produceren in één poging. De realiteit is rommelig en iteratiever. Dat accepteren betekent niet berusten — het betekent workflows bouwen die daar rekening mee houden.
Wat Ik Heb Gemeten Na een Week Simplify
Ik heb /simplify gedraaid op vijf verschillende projecten de afgelopen week. Drie Laravel-apps, één Next.js-project, en één Python-automatiseringsscript. Dit is wat ik heb waargenomen.
Codereductie: Over alle vijf projecten reduceerde Simplify het totaal aantal coderegels met 15-40%. De grootste reductie was het Laravel Livewire-project (degene die ik hierboven gedetailleerd heb) met ruwweg 38%. De kleinste was het Python-script met ongeveer 15% — er was minder duplicatie om te extraheren.
Unieke componenten gecreëerd: Simplify stelde het creëren voor van 3-7 nieuwe gedeelde componenten, traits of utilities per project. Niet allemaal waren het waard om te behouden — soms was de abstractie prematuur voor een codebase van die omvang — maar de meeste waren oprecht nuttig.
Bugs voorkomen: Moeilijk te kwantificeren, maar ik vond twee gevallen waarin de constante-extractie inconsistente stringwaarden tussen bestanden opving. Deze zouden uiteindelijk bugs zijn geworden. Waarschijnlijk tijdens een demo.
Tijdsinvestering: 3-10 minuten per run, afhankelijk van de diffgrootte. Totale actieve tijd per project (suggesties reviewen en aanpassen) was ongeveer 15-20 minuten. Vergelijk met de 1-2 uur handmatige refactoring die dit verving.
Tokenkosten: 3-12% van het sessiebudget per run. Gemiddeld ongeveer 7% over mijn gebruik.
De cijfers vertellen een duidelijk verhaal, maar de echte waarde is moeilijker te meten. De codebase voelt anders nadat Simplify eroverheen is gegaan. Bestanden zijn korter. Patronen zijn consistent. Wanneer je een wijziging moet maken, is er één plek om het te doen, niet vier. Dat stapelt op over elke toekomstige bewerkingssessie.
Waar Dit Tekortschiet (En Wat Ik Zou Veranderen)
Ik zou je een slechte dienst bewijzen als ik de beperkingen niet noemde, want er zijn echte.
Simplify kan overabstraheren. Op mijn kleinere Python-project suggereerde het een helperfunctie te extraheren die maar op twee plekken werd gebruikt. De functie had drie parameters, en het aanroepen ervan was nauwelijks korter dan de inline code die het verving. Ik verwierp die suggestie. Niet elk patroon verdient een abstractie — soms zijn twee gelijkaardige blokken code gelijkaardig bij toeval, niet door ontwerp.
De tokenkosten lopen op tijdens zware generatiesessies. Als je in een marathon-codeersessie zit die een hele applicatie genereert, kan Simplify meerdere keren draaien 30-40% van je tokenbudget opeten. Ik ben strategischer geworden over wanneer ik het draai — typisch bij natuurlijke breekpunten, niet na elke kleine wijziging.
Geen preview van tokenkosten. Zoals ik noemde, kun je niet zien hoeveel tokens Simplify gaat verbruiken voordat het draait. Ik zou graag een --estimate vlag zien die de verwachte kosten toont op basis van diffgrootte.
Framework-specifieke suggesties variëren in kwaliteit. De Laravel-suggesties waren uitstekend — de tool begrijpt duidelijk de patronen en conventies van het framework. De Next.js-suggesties waren goed maar misten soms framework-specifieke optimalisaties zoals Server Components. Je resultaten zullen variëren afhankelijk van je stack.
Het kan geen architectuurproblemen opvangen. Simplify werkt op codeniveau — extraheren, consolideren, optimaliseren. Het vertelt je niet dat je hele aanpak van state management verkeerd is, of dat je een heel ander patroon zou moeten gebruiken. Dat is nog steeds een menselijk oordeel.
Dit zijn echte beperkingen, maar geen dealbreakers. Het zijn het soort ruwe randen die ik verwacht glad te strijken in de volgende updates.
Dit Verandert Hoe Ik Werk Met AI-Codegeneratie
Dit is wat me het meest verraste aan het adopteren van /simplify — het verbeterde niet alleen mijn code. Het verbeterde mijn workflow.
Vóór Simplify was mijn proces: code genereren, elk bestand handmatig reviewen, de voor de hand liggende duplicatie refactoren, committen. De handmatige reviewstap was het knelpunt, en ik zal eerlijk zijn — op vermoeide middagen sloeg ik het soms over. De werkende-maar-rommelige code leveren en mezelf beloven dat ik het later zou opschonen. (Dat deed ik niet.)
Nu is mijn proces: code genereren, /simplify draaien, de suggesties reviewen in plaats van de ruwe code, goedkeuren, committen. De reviewstap is sneller omdat ik voorgestelde wijzigingen evalueer, niet op problemen jaag. En ik sla het nooit over omdat het draaien van een één-woord commando nul wrijving heeft.
Het diepere inzicht is dit: AI-ondersteunde ontwikkeling is geen éénstapsproces, en hoe eerder we dat accepteren, hoe beter onze code wordt. Generatie is stap één. Review en verfijning — door een mens, een AI, of beide — is stap twee. Simplify automatiseert stap twee op een manier die oprecht nuttig is, niet alleen cosmetisch.
Als je iets bouwt met Claude Code — zelfs kleine projecten — probeer /simplify te draaien op je volgende generatiedoorgang. Bekijk de diff. Zie wat het opvangt. Ik denk dat je verrast zult zijn, op dezelfde manier als ik, door de patronen die zich in het volle zicht verstopten.
En de volgende keer dat iemand je vertelt dat AI-gegenereerde code inherent rommelig is, heb je een antwoord van één woord.
🤝 Laten We Samenwerken
Op zoek naar het bouwen van AI-systemen, het automatiseren van workflows, of het opschalen van je technische infrastructuur? Ik help graag.
- 🔗 Fiverr (maatwerk builds & integraties): fiverr.com/s/EgxYmWD
- 🌐 Portfolio: mejba.me
- 🏢 Ramlit Limited (enterprise-oplossingen): ramlit.com
- 🎨 ColorPark (design & branding): colorpark.io
- 🛡 xCyberSecurity (beveiligingsdiensten): xcybersecurity.io
