Solution Architect & Engineering Leader in E-Commerce Development – I lead engineering teams and design e-commerce solutions that deliver top-notch results. My mantra is delivering well-designed, high-quality software that meets customer needs.
Meet Magento Poland 2026
Slow Down to Speed Up: Getting a Magento Team Ready for AI Pace
AI can produce a Magento change in minutes. But maintaining a store was never about typing code – it’s about proving the change didn’t break anything, and fixing it fast when it did. When the volume of changes multiplies and your ability to verify them stays flat, technical debt and incidents grow faster than delivery ever will.
AI removed the typing bottleneck. It didn’t remove the other two: can we ship this safely, and can we tell whether it was worth shipping?
This is the story of how we deliberately slowed down at Medistore – a high-traffic multi-vendor medical marketplace running headless Magento with a Nuxt frontend – to get our setup and our team ready for the pace AI actually creates.
The engineering half comes down to a single idea: an agent is only as good as the feedback loop you can give it, so we shortened every loop we had. Static analysis that answers in seconds, including PHPStan at level 10 on a Magento codebase. A CI pipeline we cut in half. Wider unit, integration, and GraphQL coverage. Playwright E2E regression running across every storefront. A development environment that stops blocking people. All of it now has two users instead of one: a developer and an agent – and it needs to work for both.
The other half is about product development itself. Most e-commerce teams are set up so that business decides what to build and engineering estimates it. That split made sense when writing code was the expensive step. It doesn’t anymore. We restructured around a simple principle: the people closest to the system should be the ones shaping what it becomes. That means engineers making authoritative calls on scope and direction, working directly with business and data rather than downstream of them, and treating every change as something you release carefully and then judge on evidence. I’ll walk through how that decision-making actually works day to day, what it takes to make it safe, and where it breaks.
Finally, the part that never makes it into an architecture diagram: what faster delivery does to the people doing it. Autonomy here isn’t a perk – it’s what keeps engineering from becoming a delivery mechanism for tickets nobody understands. Developers are not prompt couriers.
This is a maintenance talk, and maintenance rarely gives you a dramatic before-and-after. What it gives you is compounding: delivery that means something, changes that are safe to roll out, and production issues that stay short. I’ll show what that looked like along the way, including the parts we’re still fighting with.
You’ll leave with a concrete list of guardrails worth having before you let AI loose in your Magento repository, and with a harder question about who owns the outcome once code stops being the slow part.