Muse Code review

Muse Code hoort bij dezelfde familie als Claude Code en Codex: je beschrijft wat er moet gebeuren en de agent leest je codebase, maakt een plan, wijzigt bestanden en draait tests. Je kijkt mee en grijpt in. Dat is een andere manier van werken dan een editor waarin de AI meetypt terwijl jij stuurt.

Het onderscheidende punt is dat hij meerdere sub-agenten tegelijk kan laten lopen. Eén die de tests draait, één die documentatie bijwerkt, één die aan de eigenlijke wijziging werkt. Dat klinkt aantrekkelijker dan het in de praktijk vaak is, want de bottleneck verschuift naar jouw vermogen om drie parallelle veranderingen te beoordelen.

Praktisch werkt dat zo: je opent een terminal in de map van je project, start de agent en typt wat er moet gebeuren. Hij inventariseert eerst welke bestanden ertoe doen, laat zien wat hij van plan is, en gaat pas daarna schrijven. Bij elke stap kun je stoppen, bijsturen of terugdraaien. Dat laatste is belangrijker dan het klinkt: een agent die je niet kunt afkappen, is een agent die je niet kunt vertrouwen.

Wat opvalt in het gebruik is hoe expliciet hij is over wat hij niet weet. Waar een editor-assistent bij twijfel iets plausibels invult, stelt Muse Code vaker een vraag terug. Dat kost je aandacht, maar het scheelt de categorie fouten die je pas drie stappen later ontdekt.

De eerste sessie met een agent voelt bijna altijd als een doorbraak. Je beschrijft iets in twee zinnen en er ontstaat werkende code. Wat je in de week erna merkt, is of dat volhoudt op een codebase die inmiddels jouw gewoontes en jouw compromissen bevat.

Waar Muse Code goed blijft, is bij werk met een duidelijke buitengrens: een koppeling schrijven, een set schermen aanleggen, tests uitbreiden. Waar hij minder wordt naarmate het project groeit, is bij wijzigingen die door de hele codebase heen lopen. Dan wordt de vraag hoeveel van je project hij tegelijk kan overzien, en dat is bij elke agent een harde grens.

Het praktische advies dat daaruit volgt: houd je project overzichtelijk in mappen die elk één ding doen. Dat is los van AI al goede gewoonte, maar het wordt met een agent direct zichtbaar in wat je terugkrijgt.

Tegenover Claude Code verliest Muse Code op diepte: bij een taak die veertig stappen ver gaat, houdt Claude Code de draad langer vast en komt hij verder voordat hij vastloopt. Tegenover een editor als Cursor verliest hij op directheid, want in een editor zie je de wijziging ontstaan terwijl je meekijkt en kun je halverwege een zin ingrijpen.

Waar hij wint is de combinatie van zelfstandig doorwerken en afrekenen naar gebruik. Wie een paar keer per week een afgebakende klus heeft, betaalt bij een abonnement voor de dagen dat hij niets doet. Dat is precies het gat waar Muse Code in zit: agentwerk zonder vaste last.

De keuze wordt dus zelden 'welke is beter'. Hij wordt 'hoeveel dagen per maand laat ik een agent echt werken'. Dat is een vraag die je over jezelf kunt beantwoorden zonder één benchmark te lezen.

Een bruikbare opdracht noemt drie dingen: wat er moet veranderen, waar in de code dat waarschijnlijk zit, en waaraan je afleest dat het klaar is. Dat laatste wordt het vaakst vergeten. Zonder eindtoets blijft een agent doorpoetsen aan iets dat allang goed was, en bij afrekenen per token betaal je voor dat poetsen.

Verder loont het om de context klein te houden. De verleiding is om de hele map mee te sturen zodat hij 'alles ziet'. In de praktijk levert een selectie van vijf relevante bestanden beter werk op dan tweehonderd bestanden waarin het antwoord ergens verstopt zit, en het scheelt bovendien verbruik.

Tot slot: laat hem zijn eigen werk nakijken voordat jij het doet. Een tweede ronde waarin je vraagt om de wijziging kritisch te lezen, haalt er verrassend veel slordigheden uit. Dat is goedkoper dan dat jij ze vindt.

In een bouwdag is voorspelbaarheid belangrijker dan maximale kracht. We gebruiken agents voor het werk dat af te bakenen is: een koppeling schrijven, een schermenset opzetten, tests aanvullen. De keuzes die het product bepalen maken we zelf, want die zijn niet terug te draaien met een prompt.

Een terminal-agent haalt het bouwen weg uit het scherm waarin je het resultaat ziet. Dat klinkt triviaal en het is het niet: als je aan een interface werkt, wil je bij elke wijziging kijken. Een agent die zelfstandig vijf bestanden aanpast en dan meldt dat hij klaar is, dwingt je om achteraf te controleren wat er visueel gebeurde. Voor ontwerpwerk is dat een slechtere lus dan een editor of een visuele bouwer.

Daarnaast raak je het gevoel voor je eigen codebase sneller kwijt. Wie zelf typt, onthoudt waar dingen staan. Wie beschrijft en beoordeelt, onthoudt vooral wat hij gevraagd heeft. Dat is geen ramp zolang het project klein blijft, maar het maakt de dag waarop je een lastige fout moet zoeken zwaarder.

Wat je ervoor terugkrijgt is dat je aan meer dingen tegelijk kunt denken. Of die ruil goed uitpakt, hangt af van of je project vooral logica is of vooral interface.