Meet Magento Poland 2026: Who Checks the Faster Code?

Meet Magento Poland 2026 puts AI-ready teams next to pricing and recovery talks. A store team still needs someone to review a change, a test that matches the job and a clear release decision, however quickly AI wrote it. Before Poznań on 29 October, bring one change that stalled. That gives you a concrete question for the talks instead of another wish list.

The programme puts AI-ready teams, customer-specific B2B pricing and crisis management on the same day. That's a better conversation than treating each as a separate project. Your customers will meet them together, usually while trying to buy something.

Meet Magento Poland 2026: who checks the faster code?

A Magento team needs a clear route from a proposed change to a reviewed, tested release. Producing more changes doesn't remove the work between those steps. It can make that work harder to ignore.

Mateusz Zbylut of Medicover / Medistore has a noon session called Slow Down to Speed Up: Getting a Magento Team Ready for AI Pace. His description covers verification loops and judging released changes on evidence. The title makes room for a question worth taking along: which part of your team's route is actually slow?

Choose one recent change and draw its path on a sheet of paper. Who requested it? Who wrote it? Who checked it? Who decided it could go live? Note the waits between those people as well as the time spent doing the work. A change written before lunch and reviewed next Thursday has a review problem. Another drafting tool might just make Thursday busier.

Then pick a test that matches the change. For a delivery-message edit, compare the product page, checkout and order email. For a price change, compare the offer with the accepted order. The person reviewing the work should know what good looks like before the new version arrives.

A short review note can carry a surprising amount: what changed, why it changed, what was checked and who can release it. Give the reviewer enough context to decide, rather than an invitation to reconstruct the project from chat history. Nobody joined the team for the archaeological opportunities.

Does the customer's price survive the handovers?

Customer-specific B2B prices need to agree across the offer, the purchase and the order that operations receives. A fast price lookup is valuable, but speed alone doesn't explain what happens when the agreement changes.

At 17:00, Milos Glavinic of Foxycom will present Scaling Magento to Support Over a Billion B2B Prices. His abstract describes an Adobe Commerce implementation where SAP holds the pricing data, with a separate pricing layer and later a pricing API. You don't need a billion combinations to bring a useful question.

Take one customer's negotiated rate and follow it through a product page, a quote if your store uses one, checkout and an accepted test order. Add a realistic change, such as a different quantity or a contract reaching its end date. Ask your technical lead where the final agreement is checked and what happens if the price source can't answer.

Write down the rule in merchant language first. For example: which price should a returning buyer see, and when should a quote stop being valid? Those are business decisions. Leaving them implicit gives the implementation team a guessing job, however impressive the architecture is.

Our Magento capacity and high-traffic guide is useful accompanying reading for the performance discussion. Keep the two questions separate: whether the store can serve the load, and whether it serves the agreed price. One successful test doesn't answer both.

What happens when a quicker change goes wrong?

A Magento release plan should include who can stop the release and how the team will respond if the result differs from the test. Make those decisions before the shop is waiting for an answer.

Miłosz Sokół of Medistore has crisis management and disaster recovery on the 14:00 programme. Pair that subject with the AI-development sessions when planning your own follow-up. More frequent changes deserve a recovery conversation as well as a productivity conversation.

For the change you're bringing to Poznań, ask the team to name the signal that would make them pause. Is it a failed purchase, a price disagreement or an order that support can't explain? Then name the person who makes that decision and the people who need to hear it.

Keep a content reversal separate from recovering a wider store incident. Reverting one product description isn't the same job as restoring infrastructure or resolving a compromised system. Our Magento security guide covers the broader preparation, including backups and restore drills. The event is a prompt to revisit that plan, not a reason to improvise a new one on production.

A smaller AI-review example you can try with your catalogue

Moogento ProductContent separates a proposed product-content change from approving and applying it. That makes catalogue editing a concrete place to discuss the review route without starting with a whole engineering release.

Choose a product description that needs work and compare the current text with the proposed version. Check the variant details and delivery claims, not just whether the writing sounds better. Decide who approves the change and who applies it. ProductContent requires an approved draft before application and checks for changes to the recorded product value before applying that draft.

The ProductContent guide explains that workflow and the reversal options. It's a content-review example, not a replacement for code review or a store-wide recovery plan. A product page that reads beautifully but promises the wrong item has still had a bad edit.

What should your team do after Poznań?

Choose one handover to improve and one result to check. If the review queue was the problem, measure whether a suitable change reaches review sooner and whether the reviewer has enough information to decide. Don't make the goal simply producing more drafts.

Bring the discussion back to the colleague who owns that part of the work. Show them the example you took, the question the programme helped you think through and the next check you propose. The useful souvenir is a decision someone can act on. The lanyard can retire.

FAQ

When and where is Meet Magento Poland 2026?

Meet Magento Poland takes place on 29 October 2026 at Concordia Design in Poznań. Use the official event page for current travel and ticket details.

Which sessions connect to Magento store operations?

Mateusz Zbylut's AI-ready team session, Milos Glavinic's B2B pricing case study and Miłosz Sokół's crisis-management session each connect to a different part of changing a live store. Bring a specific example so you can ask about the review, pricing or recovery decision your team actually faces.

Should every AI-generated change go straight into the store?

No. A proposed change still needs review against the product facts or business rule, an appropriate test and a release decision. Making the draft faster doesn't settle those questions.

Where can a store team start if it only has an hour?

Pick one recent change and follow it from request to release. Note who reviewed it, what they checked and where it waited. Bring the slowest or least clear handover to the relevant session, rather than trying to audit the whole store before breakfast.