Why Choosing the Right AI Model Matters for Real-World Problem Solving

Android mobile ecommerce carousel debugging from complex interactions to a native scroll solution

AI models can all produce convincing answers, but they are not equally capable of solving complex, real-world problems. The difference becomes obvious when a task involves debugging, live systems, device-specific behaviour and repeated verification.

A recent DigiStoreSG homepage issue provides a useful example.

The problem: clickable on desktop, broken on mobile

Our homepage displayed collection images that linked to their respective Shopify collections. Every card had the correct destination, and every collection page was online. On desktop, the links worked normally.

On Android, however, only the first collection image could be opened. A visitor could swipe to the next image, but tapping the newly visible card did nothing.

At first glance, this looked like a broken-link problem. Inspection showed otherwise. The links were present, their URLs were correct and the destination pages returned successful responses. Something in the mobile interface was preventing Android Chrome from activating those links.

Why the first fixes sounded right but did not solve it

Several technically reasonable explanations emerged during the investigation:

  • Inactive carousel slides used content-visibility rules that could remove them from browser hit testing.
  • The image and content layers might be positioned above the full-card link.
  • The carousel drag handler could suppress the normal click generated after a tap.
  • The collection cards needed more height for longer names.

Each theory described a real part of the Shopify Horizon theme. Targeted changes were applied and verified in the live theme, yet the Android problem persisted.

The exact model switch

The first phase of the debugging used GPT-5.6 Luna with medium reasoning. It identified several plausible CSS, visibility and pointer-event causes and eventually produced a clickable mobile grid workaround. That workaround proved that the collection links themselves were sound, but it consumed too much screen space and subsequent layout adjustments introduced text truncation and page-width overflow. It did not preserve the compact, swipeable carousel the storefront required.

We then switched to GPT-5.6 Sol with high reasoning. Instead of continuing to patch the Horizon slideshow, Sol returned to the original requirement and reconsidered the underlying interaction model. It replaced the JavaScript-controlled mobile slideshow with a native CSS scroll-snap carousel, keeping every collection card as an ordinary link before and after a swipe. That was the change that solved the Android click problem while retaining a compact carousel.

The comparison is not that Luna produced no useful work. Its iterations exposed important constraints and demonstrated that a simpler grid could restore clickability. The decisive improvement was that Sol, running at a higher reasoning level, connected the failed tests and device evidence to an architectural change instead of another incremental patch.

Finding the actual source of the problem

The Horizon theme used a custom slideshow component for the mobile collection carousel. That component did much more than move cards horizontally. It managed active and hidden slide states, pointer events, drag behaviour, content visibility, accessibility attributes and JavaScript-controlled scrolling.

On Android Chrome, those behaviours could interact in a way that left a newly visible card unable to receive a normal tap. Desktop worked because it used a conventional grid. Mobile failed because it depended on the more complicated slideshow interaction model.

The decisive move was to stop patching the component and replace it for this section.

The final solution: a native scroll-snap carousel

The mobile collection section was rebuilt as a native CSS scroll-snap carousel. It still looks and behaves like a carousel, but horizontal movement is handled by the browser rather than by the theme slideshow script.

Each collection card remains an ordinary link throughout the interaction. There is no hidden-slide state to reconcile after a swipe and no custom drag handler deciding whether a tap should become a click.

The result is simpler:

  • Visitors can swipe naturally on Android.
  • Every visible collection card remains clickable.
  • Collection names have enough space.
  • The carousel stays within the screen width.
  • The desktop layout remains unchanged.
  • Less JavaScript is involved.

Most importantly, it worked on the affected Android device.

The right model does more than generate code

Choosing an appropriate AI model is not merely about receiving better-written code. More capable models become valuable when a task requires several abilities at once.

Maintaining context

The model must track which Shopify theme is live, which changes were applied, what the user tested and which approaches have already failed.

Revising assumptions

A model should not defend an earlier diagnosis simply because it sounded correct. New evidence must be allowed to change the direction of the investigation.

Understanding interactions between technologies

This issue involved Shopify Liquid, responsive CSS, JavaScript pointer events, carousel state, Android Chrome and live theme deployment. The failure existed in the interaction between those layers.

Working with live evidence

The successful diagnosis depended on inspecting the generated storefront, reviewing the actual theme files, checking a real Android screenshot and verifying the published assets after deployment.

Choosing a simpler architecture

The best answer was not another adjustment to the existing slideshow. It was replacing an unreliable interaction model with a native browser capability.

Model capability is only part of the solution

Even a strong model can begin with an incomplete diagnosis. The advantage is not that it will always be correct immediately. The advantage is that it can investigate systematically, learn from failed tests and eventually select a more reliable approach.

Good results also require clear feedback from the user, access to the relevant system, testing on the affected device, narrow changes and verification after deployment. A capable model combined with disciplined verification is far more useful than either one alone.

The practical lesson

Simple models are often sufficient for rewriting text, formatting data or producing basic code examples. Stronger reasoning and agentic models become more valuable when work involves production systems, multiple technologies, device-specific bugs, repeated debugging, live deployment and architectural trade-offs.

The DigiStoreSG carousel problem was not solved by producing more code. It was solved by forming a better model of the system and then choosing a simpler implementation that matched how mobile browsers naturally work.

That is why selecting the right AI model matters: complex problems require more than an answer. They require investigation, adaptation and sound technical judgement.

How we connected Codex to Shopify

This debugging work depended on a controlled Shopify connection, narrow permissions and verification after every live change. Read How We Connected Codex to Shopify: What Worked and What We Got Wrong for the setup, authentication lessons and safeguards behind the workflow.

Related product for a flexible mobile workspace

USB-C multiport adapter with 4K HDMI, USB 3.0 and power delivery

USB-C Hub with 4K HDMI, USB 3.0 and Power Delivery

A compact adapter for connecting a laptop or compatible tablet to a monitor, USB accessory and USB-C charger. From S$6.00.

View the USB-C multiport adapter

Frequently asked questions

Which AI models were used in this case study?
The initial troubleshooting used GPT-5.6 Luna with medium reasoning. The final successful approach used GPT-5.6 Sol with high reasoning, which replaced the Horizon mobile slideshow with a native CSS scroll-snap carousel.

Why could the first collection card be clicked while later cards could not?
The first card started as the active slideshow item. After a swipe, the theme could leave the newly visible card affected by hidden-slide or drag state, preventing Android Chrome from treating the tap as a normal link click.

Why did the collection links work on desktop?
Desktop used a conventional grid of normal links. Mobile used the Horizon slideshow component, which added JavaScript state, content visibility and custom pointer handling.

Why was native CSS scroll-snap more reliable?
The browser handled horizontal touch scrolling directly, while every card remained an ordinary link. This removed the extra slideshow state that interfered with taps.

Does choosing a stronger AI model guarantee the first fix will work?
No. Its value is the ability to retain context, reconsider failed assumptions, inspect evidence and change the technical approach when incremental patches are not enough.

What is the safest way to use AI for Shopify theme changes?
Start from the current live theme, make a narrow change, preview it on the affected devices and verify the rendered storefront. For higher-risk changes, work on a fresh duplicate and publish only after testing.