Cursor Composer en SWE‑1.5 Review – Waarom een bedrijf van $10 mrd een ondermaats model heeft uitgebracht

Introductie

De markt voor AI‑codeerassistenten loopt op, en deze week hebben twee zwaargewichten — Cursor en Windsurf — nieuwe modellen gelanceerd, Cursor Composer en SWE‑1.5. Beide beweren een ultralage latentie voor “agentisch” coderen, maar de onderliggende technologie en prestaties roepen serieuze vragen op. Dit artikel ontleedt de beweerde mogelijkheden van de modellen, de testmethodologie, en waarom de resultaten zelfs de meest tolerante gebruikers kunnen teleurstellen.

---

Achtergrond van de nieuwe modellen

Cursor Composer

• Gepositioneerd als een “frontier”-model dat vier keer sneller is dan vergelijkbare LLM’s.
• Ontworpen voor lage‑latentie, meerstaps‑coderingstaken, waarbij de meeste beurten in minder dan 30 seconden voltooid zijn.
• Gebouwd op een niet-openbaar “open‑weights” fundament, naar verluidt gebaseerd op een 4.6‑class model.
• Er zijn geen publieke benchmarkresultaten vrijgegeven, waardoor onafhankelijke verificatie moeilijk is.

SWE‑1.5 (Windsurf)

• Gepromoot als de snellere van de twee, met een doorvoersnelheid tot 950 tokens per seconde op Cerebras‑hardware.
• Getraind op een niet-openbare open‑source basis met propriëtaire reinforcement‑learning‑data.
• Gepositioneerd als een high‑throughput alternatief voor codegeneratie.

---

Testmethodologie

De evaluatie maakte gebruik van de officiële CLI‑tools die door elke leverancier werden geleverd:

• Cursor Composer – benaderd via de Cursor‑CLI (de editor‑UI toonde alleen het oudere Cheetah‑model).
• SWE‑1.5 – benaderd via de Windsurf‑editor.

Beide modellen kregen een reeks representatieve codeeruitdagingen, variërend van eenvoudige rekenmachines tot complexere web‑app‑prototypes. Uitvoertijd, correctheid en foutpercentages werden voor elke taak vastgelegd.

---

Overzicht van de prestaties

Cursor Composer

• Movie‑tracker app – talrijke UI‑fouten; de discover‑view was kapot.
• Goatee UI calculator – werkte correct, wat aantoont dat het model eenvoudige logica aankan.
• Godo game – kon niet uitgevoerd worden; moderne modellen zoals GLM‑4.5 en Miniax doen dit moeiteloos.
• Open‑code big task – werd niet voltooid.
• Spelt app – er verscheen alleen een inlogscherm; backend‑fouten waren alomtegenwoordig.
• Tari Rust image‑cropper – niet functioneel.
• Algemene rang: 11e op het interne leaderboard, achter modellen zoals Kilo, Miniax en GLM‑4.5.

SWE‑1.5

• Behaalde 19e plaats op hetzelfde leaderboard.
• Kon een rekenmachine‑UI genereren, maar faalde bij het uitvoeren van berekeningen.
• Produceerde consequent onjuiste of onvolledige code in de hele testreeks.

---

Waarom de resultaten belangrijk zijn

1. Gebrek aan transparantie – Beide bedrijven verbergen het exacte basismodel dat ze hebben gefinetuned. De beschrijving suggereert een GLM‑4.5‑ of Qwen‑3‑Coder‑afkomst, maar er wordt geen concreet bewijs geleverd.
2. Snelheid‑vs‑kwaliteit afweging – Hoewel SWE‑1.5 een hogere token‑per‑seconde‑doorvoer behaalt, is de outputkwaliteit vaak onbruikbaar. Snelheid alleen compenseert geen defecte code.
3. Ontbrekende benchmarks – Zonder door de gemeenschap geaccepteerde evaluaties (bijv. HumanEval, MBPP) blijven de beweringen over “frontier” prestaties onbewezen.
4. Mogelijke ethische kwesties – Het inzetten van een gefinetuned open‑source model zonder attributie kan in strijd zijn met gemeenschapsnormen en, in sommige rechtsgebieden, met licentievoorwaarden.

---

Technische analyse

• Modelkeuze – Het waargenomen gedrag komt meer overeen met Qwen‑3‑Coder of een oudere GLM‑4.5‑checkpoint dan met een echt 4.6‑class model. Het ontbreken van geavanceerde redenering en tool‑gebruik duidt op onvoldoende pre‑training‑alignering.
• Impact van Reinforcement Learning (RL) – De bescheiden winst door RL‑fine‑tuning wordt tenietgedaan door de slechte basismodelkeuze. Een juiste alignering tijdens de pre‑training zou nodig zijn om echte verbeteringen te zien.
• Hardware‑overwegingen – Beide modellen draaien op high‑throughput hardware (Cerebras voor SWE‑1.5, ongespecificeerd voor Cursor). Echter, nieuwere open modellen (bijv. Miniax, GLM‑4.5) behalen al vergelijkbare of betere snelheden op dezelfde hardware, waardoor het snelheidsvoordeel zinloos wordt.

---

Implicaties voor de industrie

• Transparantiekloof – Het weigeren om het onderliggende model bekend te maken ondermijnt het vertrouwen. Gebruikers kunnen niet verifiëren of het product een echte innovatie is of een hergebrand open‑source checkpoint.
• Alternatieve kosten – Bedrijven met een marktkapitalisatie van $10 miljard zouden dedicated ML‑teams kunnen inhuren om propriëtaire modellen te ontwikkelen of, op zijn minst, openlijk het basismodel dat ze finetunen crediteren.
• Reactie van de gemeenschap – Het ontbreken van kritiek vanuit de bredere AI‑gemeenschap duidt op een groeiende zelfgenoegzaamheid rond model‑attributie.

---

Aanbevelingen voor professionals

• Geef prioriteit aan bewezen open modellen – Wanneer snelheid cruciaal is, overweeg gevestigde open‑weights zoals Miniax, GLM‑4.5 of Mistral‑7B en voer zelf fine‑tuning uit.
• Valideer vóór integratie – Voer een kleine benchmark‑suite uit (bijv. codegeneratie, tool‑gebruik, foutafhandeling) voordat je een nieuw vendor‑model adopteert.
• Eis transparantie – Sta op voor duidelijke documentatie van het basismodel, de trainingsdata en de licentie om juridische en prestatie‑valkuilen te vermijden.

---

Conclusie

Zowel Cursor Composer als SWE‑1.5 beloven bliksemsnelle codegeneratie, maar de realiteit is een verzameling snelle‑maar‑gebrekkige outputs. De modellen worstelen met basistaken die oudere open‑source checkpoints moeiteloos aan kunnen, en het ondoorzichtige ontwikkelingsproces roept ethische zorgen op. Totdat de bedrijven hun fundamenten openbaar maken of een werkelijk superieur model leveren, zijn ontwikkelaars beter af door vast te houden aan goed gedocumenteerde, door de gemeenschap geteste alternatieven.

Dit artikel weerspiegelt een onafhankelijke technische beoordeling en onderschrijft geen specifiek product.