I’ve spent the last few weeks living with two of the most talked-about AI coding assistants, Cursor Composer 1 and Cognition SWE 1.5, inside real multi-service projects connected through Composio’s Rube MCP gateway.

Not toy apps. Not single-file demos. Actual workflows: browser extensions, API connections, and live data running through real services.

Here’s what stood out.

Cursor’s Secret Strength: Flow

Cursor still nails what it set out to do: get you to a working prototype fast. It keeps you in a “flow” state where ideas turn into working code almost immediately. The feedback loop feels natural, like coding with a hyperactive pair programmer who doesn’t get tired.

But when the project grew past one file, that same speed started working against it. Quick fixes piled up. Error handling got messy. The MVP was done, but scaling it felt like untangling a ball of wires.

SWE 1.5’s Advantage: Structure

SWE 1.5 took longer to reach the same MVP, but the code it wrote looked like something a senior engineer would hand off to a team. It separated logic cleanly, anticipated edge cases, and wrote comments that actually explained why things worked.

When I connected it through Rube MCP to multiple services, it handled streaming events, retries, and failure cases like a pro. It wasn’t flashy, but it was quietly solid.

What Surprised Me

Error recovery: SWE 1.5 caught and retried partial SSE events automatically. Cursor often just… stopped.

Architecture: SWE 1.5 created multi-file structures with clear boundaries. Cursor favored single-file speed.

Debugging: SWE 1.5 left breadcrumbs in logs. Cursor left mystery.

Iteration speed: Cursor was addictive for prototyping. SWE 1.5 rewarded patience with cleaner long-term code.

The Numbers Speed & Scaffolding:

Cursor reached a working build in ~25 minutes (~40-50K tokens, ~$0.15-0.25) but required several debugging loops.

SWE 1.5 took ~45 minutes (~55-65K tokens, ~$0.50-0.60) but fewer debugging loops (~3 vs ~6) and a more modular structure.

Architecture & Maintainability:

Cursor sample: single background.js, minimal separation of concerns. Fine for MVPs but weak on error handling.

SWE 1.5: multi-file (background, popup, config, proxy), strong error recovery, buffered SSE handling, fallback logic.

Error Handling & Debugging:

Cursor: Syntax or stream parsing errors required manual fixes.

SWE 1.5: Detected root causes, implemented retries, managed partial SSE messages, clearer logs.

The Takeaway

If you want momentum, something you can see and share within an hour, Cursor Composer is still unmatched. If you want something you can build on top of, with fewer “why did it break?” moments, SWE 1.5 is the safer bet.

Both are excellent in their lanes. But in real multi-service builds powered by Composio, structure beats speed more often than not.

I’ve detailed the full experiment, metrics, and side-by-side comparisons here: Read the full write-up on Post link

Curious, have you tried building real integrations with these assistants (or others like Devin or Aider)? What patterns or failure modes have you noticed?