System Prompt Downstream Funnel
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
A wide-ranging working stream combining a Burnish review and submission readiness with discussion of AI-assisted product building. Practical work covered installation, scopes, billing, the storefront, tiered human-approved Autopilot optimization, the brand manifesto, traffic and revenue dashboards, pixel/GA4 integrations, and meaningful empty states. Some narrow checks worked—such as a level transition and selected product-data updates—but the stuck optimization/publishing flow and missing analytics remained unresolved, prompting discussion of tunnel vision, error monitoring, debugging orchestration, and subagent workflows. The stream also explored product-scope discipline, capped trials, market and competitor validation, unit economics, and learning software development while building with AI. Luqman argued that deep software-lifecycle expertise is not an absolute prerequisite for starting, while making clear that AI tools do not guarantee bug-free production software. Audience questions additionally touched on APIs versus webhooks, local and future AI models, and context-window limits, alongside lighter conversations about stream music, World Cup predictions, and a virtual-office idea for tracking project progress.
69 moments from the stream
- 3:08:13
API Access vs. Webhook Notifications
A plain-language discussion of API and webhook roles: the API lets external systems automatically pull Burnish data with read-only access, while a webhook sends notifications to a customer-provided URL when events such as a score change occur. The discussion concludes with placing both capabilities in the enterprise tier.
- 3:09:27
A Short Merge-and-Verify Release Workflow
A brief operational plan is stated for launching changes by pushing a pull request, merging it, and then verifying the result on the main branch; the later reference to a deployment tool is too fragmentary to interpret further.
- 3:11:57
Reviewing Remaining Work After the Autopilot Fix Deployment
After the fix is merged and deployed, the speaker prepares to test Autopilot from the storefront and outlines follow-up work covering mobile presentation, Shopify compliance, and a light design sweep, while noting that most of the complexity lies in backend logic, wiring, and some UX.
- 3:15:11
Diagnosing Autopilot’s Stuck Optimization Loop
The speaker tests the storefront automation after the fix is deployed, but products expected to move into auto-publishing remain stuck in optimization even after a refresh. He asks for the database state to be inspected, questions a repeated diagnostic loop that has not produced a working result, and considers broadening the investigation and checking for gaps in Shopify documentation knowledge.
- 3:22:20
How to Task Codex with a Persistent Bug
The suggested approach was to give Codex extensive context about the issue, its suspected causes, prior repair attempts, and repeated failures, while allowing it to investigate with multiple subagents instead of prescribing a solution.
- 3:23:43
Tool-Access Friction and Context Limits in Coding Agents
The speaker discusses frustration with repeatedly clarifying access to Supabase and Railway, along with his view that the context window can run out before enough progress is made.
- 3:25:51
An Inconclusive Debugging Attempt and Deferred Design Polish
A refresh left the app stuck, and no confirmed fix was reported. Small design details were treated as deferrable while the underlying bug remained the priority, after which Codex was given a chance to continue the investigation.
- 3:36:56
Moving from Warp to Agent-Oriented IDEs
The speaker says he used Warp before preferring agent-oriented IDEs that felt cleaner to him, while still finding Warp useful for running CLIs and terminals in parallel.
- 3:41:23
Context Compaction and Context-Window Limits
The speaker criticizes automatic conversation compaction because, in his view, it can lose parts of the working context, and argues that a larger context window may help. He relays an unconfirmed expectation he heard about a much larger window in a future release, while emphasizing that actual work quality remains the key criterion.
Got a question about something in this stream?
Ask in the group