
All stories
n8n
How n8n made cubic its “first port of call” on every PR
“cubic is the first port of call for my team. Every engineer clears its comments before a teammate even opens the review.”
— Marc Littlemore, engineering manager at n8n
Background
n8n’s open-source workflow-automation platform drives production workloads for Cisco, Wayfair, Pearson, Twilio, Splunk and Microsoft.
The project recently surpassed 100 000 GitHub stars, cementing its place among the most-watched repositories on the site.
Pairing that community velocity with enterprise-grade reliability demands finesse from the company’s thirty-plus engineers. They are continually expanding a single mono-repo that must delight hobbyist contributors while satisfying the scrutiny of Fortune-100 SRE teams.
The Bottleneck
Before cubic, a pull request on Marc’s team could sit for an entire day waiting for its first review.
During that lull, more PRs piled up and developers pinged one another on Slack just to keep reviews moving.
When feedback finally arrived it usually focused on details—ambiguous test names, inconsistent status codes, missing edge-case checks. Reviewer energy drained away on items that, though important, added little architectural insight.
Static-analysis tools helped, but subtle permission gaps and other edge-case bugs still slipped through and resurfaced later as regression work.
The “Aha” Moment
While addressing a security bug, Marc fixed the line of code he knew about. As soon as he pushed, cubic highlighted a completely different file—an area of the codebase he had never touched—that contained the same vulnerability.
He opened a second pull request, patched both endpoints in the same sprint and accepted cubic’s suggested regression tests so the issue can’t recur.
“I’d fixed the obvious line, then cubic said ‘there’s another endpoint with the same vulnerability.’ I had no idea that code even existed—catching it was really valuable.”
Marc Littlemore
Solution in Action
Enabling cubic took only a couple of minutes. From the very next pull request onward, authors received instant, context-aware suggestions on missing tests, duplicated logic, stray status codes, potential security gaps and style inconsistencies.
The team then codified its house conventions—such as requiring tests for sensitive parts of the codebase—directly into cubic’s repository rules.
Because everyone is expected to resolve cubic’s feedback before requesting a colleague’s review, human attention now arrives only after the easy wins are out of the way.
Reviewers can focus on API design, performance trade-offs and long-term maintainability instead of repetitive nit-picks.
Results after Three Months
“cubic gets us to a better review more quickly—nit-picks are gone, and over time you can feel the velocity increase.”
Marc Littlemore
Engineers on Marc’s team now fix more than half of the low-hanging issues before a human reviewer ever opens the diff, reducing backlog pressure and smoothing deploy trains.
Ready to accelerate your own reviews?
Book a cubic demo and watch your merge times shrink.
© 2025 cubic. All rights reserved. Terms