Debugging Core Product Engine
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 centers on moving Burnish toward a Shopify-ready V1: reviewing its product engine and value proposition, auditing what is actually wired between the frontend and backend, and refining onboarding plus the Pulse, Mentions, and settings sections around Polaris and Built for Shopify expectations. Luqman discusses making background-agent work visible through a continuous activity feed and connecting research, action, and measurement in a closed loop, alongside demo-state and free-audit funnel ideas; whether these ideas are sufficient, and how attribution and measurement should work, remain unresolved. Practical work includes tracing intermittent HTTP 500 errors and missing CSS registration on the Pulse route, noting an initial Supabase connection problem and caution around resetting onboarding state in the database without establishing a diagnosis, and auditing branches, Git worktrees, and pull requests after mismatched development environments made preserved changes appear lost. Audience questions and side discussions cover context-dependent Shopify app selection, SEO/GEO and product metadata, browser agents and Codex/Claude workflows, broader Git and agent-orchestration guidance, evaluating agent skills, AI-assisted study, and the tradeoff between livestream latency and quality. Other exploratory discussions address Product Hunt’s suitability for Shopify apps, traffic measurement, advertising, and possible discrimination around product launches, as well as practical comparisons of AI-generated storefronts; some model names and versions are inconsistent in the captions, and perceived speed was not formally measured. The stated direction is to finish Burnish’s core, simplify onboarding, and conduct a thorough Shopify compliance review before expanding marketing, while acknowledging that limited development-store testing, expected V1 bugs, migration and performance issues, and several measurement questions still require verification and concrete resolution.
121 moments from the stream
- 3:33:55
Separating Working-Tree Noise from the Scan-Funnel Scope
While reviewing several commits, unclear files and changes remained in the working tree. The discussion returned to the scan-funnel scope—the landing page, the /scan page, and possibly the live-scan section—then checked the files and funnel-pivot alignment, with a proposed five-phase workflow beginning with worktree setup.
- 3:40:35
Verifying the First-Loop Demo State
The first-loop demo is described as a show-before-pay experience in which Burnish runs the full research flow. Conflicting agent reports then left it unclear whether its files had been deleted or were still untracked in the worktree, highlighting the need to inspect file state rather than rely on one agent's report.
- 3:42:35
Commit and Merge Frequently to Limit Work Buildup
The speaker explains that untracked work becomes difficult to recall after days of accumulated changes, so he recommends merging nearly daily or after completing a defined task, and at minimum creating a commit to preserve the state.
- 3:45:25
Squash and Merge vs. Merge Commit
An explanation that squash and merge combines a branch’s changes into one commit, while a merge commit preserves the branch’s commit history and adds a merge commit. The choice was framed as guidance: squash small, single-purpose PRs, while preserving history can suit larger or more involved PRs.
- 3:49:20
Rebuilding a Shopify App’s Onboarding Experience
After conflicts emerged between earlier work and parallel worktrees, the decision was to retain the first demo as a reference and rebuild onboarding from scratch. The intended flow begins after installation, guides the merchant through setup and plan selection, and should align with Shopify conventions using Polaris Web Components and Shopify Dev MCP.
- 3:53:29
Organizing Work with Git Worktrees and a Broader Design Pass
A practical discussion about temporarily retaining earlier work, cleaning up branches, and opening a new worktree to isolate changes. The planned design pass broadened from a single page to several application areas so the overall design could be completed coherently.
- 3:58:40
Auditing Onboarding and Recovering an Earlier Demo View
The onboarding state was to be audited against existing decision documents, alongside a separate request to locate an earlier demo view and determine whether it remained accessible. Codex was mentioned as a possible helper, but these pages do not show the resulting implementation.
- 4:00:39
Coordinating Coding Agents and Completing a Milestone Autonomously
Work was divided among agents to address missing pieces, polish pages, and reuse prior research context. After the server crashed, the instruction was to restore it and complete the small milestone in one pass without waiting for review unless a critical problem arose.
- 4:10:45
Optimizing an Ad Landing Page for Mobile and Conversion
A landing-page direction was shown with a somewhat different mobile treatment. Because it was intended for Facebook Ads, it was expected to be fully optimized with conversion-rate optimization in mind, but this step was deferred until the application was complete.
- 4:12:25
Controlling Assistant Language and Verbosity
The discussion covered adjusting language behavior in Claude and using an instruction such as “no verbose” to reduce excess wording visible in the transcript view, while recognizing that this kind of control can be useful.
- 4:14:04
Reading Agent Skills Carefully and Weighing Their Side Effects
The speaker stressed reading skill instructions line by line before installation because they may introduce unwanted behavior or improve one dimension at another’s expense, depending on their author. A fact-checking skill seemed promising for accuracy, though its possible extra token use remained an open question; voice-matching instructions were also noted as capable of producing an unsuitable style.
- 4:15:22
Trading Stream Latency for Viewing Quality
The speaker explained that Telegram could provide more immediate interaction because YouTube had a delay. That latency could be reduced, but it was being retained to support stream quality.
- 4:16:48
Careful Human Review of Interface Copy
The speaker said that every visible piece of interface copy is reviewed carefully and either approved or rejected, and that the same oversight applies across the application, emphasizing the importance of human review for user-facing text.
- 4:18:06
Landing Page CRO and A/B Testing
He explains that a landing page receiving paid-ad traffic needs careful attention to its copy and every page element, and recommends A/B testing for optimization.
- 4:20:12
Using Branches and Worktrees to Protect Main
He discusses uncertainty between developing directly on main and using branches and worktrees, saying an AI tool advised him to get used to branches and worktrees and avoid touching main until changes are verified. The practical issue emerges when the Pulse page looks different after several merges and expected scan results appear to be missing.
- 4:25:57
Diagnosing Changes That Appeared Lost After Merging
He reviews work on settings, Pulse, and Mentions that appeared missing or broken despite pull requests being created and merged into main. He discusses how merge problems and coding agents switching branches can confuse the working state, then reaches a preliminary, incomplete explanation that the application changes may have transferred while he was viewing a different development side.
- 4:33:34
Stream Lag Despite a Healthy Status
The stream showed lag even though the speaker’s status display reported it as healthy; he noted that the delay was visible on his side before the content reached the audience.
- 4:38:36
Switching Between Codex and Claude When a Coding Task Stalls
The speaker observes that one assistant may stall on a coding task that the other completes quickly, while the reverse can also happen. This is presented as practical experience, not a claim that either tool is always better.
- 4:38:53
Why Updates Disappeared from the Dev Server After a Worktree Merge
The development server used during the work was tied to a Git worktree. After that branch was merged, the original server showed its earlier state even though the changes remained in the code and pull requests, indicating an environment mismatch rather than lost work.
- 4:40:55
Aligning the Dev Server with the Correct Worktree and Branch
The speaker attributed the interface mismatch to running the Shopify dev server from a checkout tied to earlier work. He qualified that he was still learning Git, and relayed advice that becoming comfortable with worktrees and branches is important for a clean workflow before a public launch.
Got a question about something in this stream?
Ask in the group