BREAKING MY APP TO FIX IT
Want to back the stream? The «داعم» membership on YouTube is EGP 60 a month: badges, emoji, and I answer your questions first on stream. Become a supporter
The gist
The stream follows an AI assistant for Shopify as development shifts from building to review, debugging, and UI/UX polish. Luqman evolves a command center that separates UI, UX, and backend verification from fix tasks, records outcomes, and supports step-by-step retesting, while routing work among Codex, Claude, and other agents according to the task. Practical work includes migrating the interface to Polaris, reviewing the homepage and report card, and diagnosing classifier, routing, conversation-button, image, live-counter, and relative-date issues. Some cases were verified as fixed, while others remained unresolved, including app slowness, conversation-flow problems, and a vision-analysis failure. Audience discussions cover model and coding-tool selection, voice-chat applications, and local versus cloud model access, with the comparisons treated as informal impressions rather than definitive benchmarks. On product strategy, Luqman argues for examining demand, unit economics, pricing, and customer-acquisition cost before scaling, while acknowledging that pre-validation is not the only path and that currency mismatch and purchasing power can complicate sustainability in some Arab markets.
105 moments from the stream
- 1:02:05
Choosing an AI tool mode by task difficulty
The speaker considers automatic mode suitable for lighter work and conserving usage, while reserving stronger options for tasks it cannot finish. He expresses a personal preference for higher-quality tools and multi-model execution without settling on one best service.
- 1:04:03
A Shopify agent that answers and executes tasks
The speaker describes a Shopify app in development: an AI agent that talks with merchants and answers questions, but is also intended to receive tasks and execute actions inside Shopify. He then returns to a task validating earlier Polaris migration work.
- 1:05:24
Why model benchmark results need interpretation
The speaker sees coding-model competition as close, but explicitly says he does not yet understand some indices or why one model ranks above another in certain tables, and wants to learn how to read benchmarks before drawing conclusions.
- 1:07:07
Diversifying models for text, vision, and audio tasks
The speaker says he uses OpenRouter with a limited model set and wants to expand it with additional vision and audio models so the workflow does not depend entirely on Claude.
- 1:08:13
Building a voice-chat app with coding assistants
Responding to an audience question, the speaker says a voice-chat app is broadly feasible with Claude provided it is not heavily hardware-dependent. When Codex is compared with Claude, he asks for concrete examples distinguishing UI from backend shortcomings.
- 1:09:11
Balancing native Polaris UI with a custom chat component
The speaker connects the Polaris migration with fitting Shopify review expectations and the admin’s native design language, then asks whether the assistant or chat box may remain custom. He notes that the later debugging and UX/UI-polish phase will be a more iterative, back-and-forth cycle.
- 1:13:20
Choosing AI Coding Tools and Using Multiple Models
The discussion presents a personal impression that Codex and Claude may differ in philosophy and focus: one may stay closer to the current task while another may notice downstream issues. The practical advice is to test what works best and remain capable of using several models and tools rather than depending on only one.
- 1:17:23
Evaluating the Unit Economics of an AI Chat App
Before building a chat app backed by paid model APIs, the discussion suggests deciding whether it is a commercial product or a personal experiment, then comparing usage costs with expected revenue, target market, and competition. It also suggests using an LLM to help structure unit-economics assumptions, without implying that this replaces real validation.
- 1:20:13
Initial Inspection of Shopify App UI Changes
The inspection reviews changes to the command center and a new review tab, which is described as helpful for debugging and UX/UI work. Billing, activity, and settings appear improved, while the overall layout still raises questions and issues.
- 1:23:11
A Qualified View of Stitch for Interface Creation
Stitch is discussed as a tool that may speed up interface creation, with references to Gemini integration, possible MCP connectivity, and potential usefulness for mobile apps. The speaker explicitly says he has not tried it personally, so these are second-hand impressions rather than a hands-on evaluation.
- 1:26:07
Testing Demand with Landing Pages Before Building
The discussion outlines a general method for testing several ideas with simple frontends or landing pages and an early-reservation offer, comparing market response, and focusing development on the idea showing the strongest demand before investing in backend work. A rapid interface-design tool could shorten the validation cycle.
- 1:27:43
Polishing Shopify Pages While Preserving Polaris Structure
The review finds the settings, billing, and activity pages improved, while the home and impact pages are weaker than the prior version, especially the report banner. The proposed direction is to retain Polaris page and layout structure while customizing visual elements, such as restoring the dark treatment, and to hand off a narrowly scoped UI-polish pass without breaking functionality.
- 1:36:36
Using Multiple Models in a Workflow
Responding to an audience suggestion, the speaker said he had not yet tried the proposed models but considered having several models available a useful working approach.
- 1:37:02
Logging UI Polish Tasks in an Agent Session
After moving from building into debugging, UI polish, and UX-flow fixes, the speaker set up automatic task logging and scoped the session to homepage fixes so they could be tracked one by one during the Polaris migration.
- 1:38:57
Convenient Multi-Model Access Through OpenCode
The speaker considered installing OpenCode to access audience-suggested models, noting that its convenience may come with a small margin above the underlying cost.
- 1:42:18
A Side-by-Side Model Design Comparison and Its Limits
The speaker demonstrated using LMArena to send the same eyewear-store landing-page prompt to two models and compare their outputs. He agreed with an audience objection that a large real project would reveal differences more realistically, stressing that this was only a rough design test—not a backend evaluation—and that his expected winner was a prior opinion, not a demonstrated result.
- 1:46:55
Practical Homepage UI Review
The speaker reviewed homepage changes after the agent reported a clean type check. He liked the copy and typography but requested better contrast for the report button on the dark background and removal of the duplicated assistant button at the top.
- 1:49:05
Setting Up a Visual Comparison of GPT and GLM
Luqman used another project in Warp with Codex, asked for GPT and GLM outputs to be rendered in a browser, then copied/saved the content and opened both results for comparison before inviting the audience to decide. The captions do not describe the visual differences or establish a winner.
- 1:53:13
Comparing AI-Generated Landing Pages
A broad comparison of two models given the same eyewear landing-page prompt. One produced relatively good content and a strong footer but used product-irrelevant imagery and backgrounds; the other showed HTML issues, missing imagery, and unrelated sections. The assessment is presented as an informal broad test, not a definitive benchmark.
- 1:55:53
Choosing AI Models for Quality and Cost
A discussion of testing multiple models while maintaining a high quality bar, and distinguishing between stronger models for development work and lower-cost models inside an application when operating economics matter.
Got a question about something in this stream?
Ask in the group