Code Driven Manifesto
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 an unfinished hands-on review of Burnish and its Code Driven Manifesto workflow: generating, editing, and exporting a manifesto; turning it into internal instructions for the storefront, articles, visibility, reputation, and discovery; and considering how its status and Autopilot integration should appear. Testing surfaced issues with generation, progress, navigation, state updates, scoring, auto-publishing, and background jobs. Some next-batch logic appeared to work in one attempt, but critical bugs and questions about cancellation, timeouts, concurrency, and persistence remained under investigation. Luqman emphasized backend wiring, user experience, and debugging before interface polish, arguing that premium-positioned software needs commensurate reliability while acknowledging that no launch can eliminate every bug. Other discussions covered an exploratory Telegram community workspace, audience questions about learning programming with AI and the advantage of experience, uncertain opinions about coding-tool quality, pricing, and context capacity, and acquisition and retention measurement without invented figures, plus shorter conversations about YouTube music copyright, Algerian music, personal goals, and screen-use glasses.
85 moments from the stream
- 2:38:44
Trust Levels for Product-Optimization Autopilot
Explains a gradual design that earns merchant trust before granting full autonomy: scheduled optimizations initially require manual publishing, then low-risk changes may be auto-published, and broader unattended operation follows repeated approvals. The rationale is the sensitivity of product titles, descriptions, and metadata, with similar autopilot concepts used elsewhere in the application.
- 2:42:18
Finding a Level 2 Auto-Publishing Bug
A practical check showed that products processed at Level 2 were not auto-published as expected. The issue was treated as critical, with concern that the full-autonomy level might also be affected, prompting a code investigation into multiple possible causes before resetting and trying again.
- 2:59:34
How Low-Risk Auto-Publishing Is Gated
The speaker explains that safe or low-risk auto-publishing is not gated by fields, but by the number of products the system is allowed to auto-publish.
- 3:02:08
Separate Fix Sessions for Faster Debugging
The speaker demonstrates a workflow that analyzes a bug, produces a precise suggested task, and starts it in a separate fix session while the original debugging session remains open. He also considers assigning multiple tasks to one fix session, but first pauses to understand an additional point.
- 3:09:30
Designing the Manifesto UI and Diagnosing Stalled Generation
The speaker discusses how the manifesto panel should appear before and after creation, then observes a generation process that remains stuck and a progress bar that restarts after a refresh. He asks whether the result reached the database, why the process is failing, and why there is no clear way to stop it.
- 3:14:57
Integrating the Manifesto Workflow into Autopilot
The speaker considers wording such as “Powered by your manifesto,” then proposes replacing the Rules area in Autopilot with the full manifesto workflow. The interface should recommend activation when inactive, clearly show the active state afterward, and be fully wired to the underlying behavior.
- 3:18:46
The Quality Bar for Premium-Positioned Software
The speaker argues that premium-positioned software should ship with polish appropriate to its pricing. He acknowledges that eliminating every bug is unrealistic, while stressing the need to uncover visible problems and deliver an experience that supports the product’s value.
- 3:22:14
Understanding Missing Projected-Lift Indicators Before Fixing Them
The speaker asks for a code-level investigation of the exact conditions that could suppress projected-lift indicators in the FAQ and another copy-related field. When returning to the issue, he insists on a plain-language explanation of both the cause and proposed fix before allowing changes.
- 3:25:25
Is Maximum Reasoning Effort Always Better?
The speaker relays a benchmark-based opinion that the maximum reasoning-effort setting may not always outperform the level below it: it may be more capable while also showing a higher hallucination rate. This is presented as a cited viewpoint, not as a result the speaker personally verified.
- 3:26:23
How Programming Experience Affects Application-Building Speed
Answering an audience question, the speaker says an experienced programmer would likely implement the same idea much faster and perhaps better. He does not think his own limited experience necessarily reduced the current application’s quality, but considers programming background a strong competitive advantage, especially for speed.
- 3:28:49
Displaying Projected Lift and Rubric Scores in Burnish
The speaker argues that the “beyond the copy” section should not be blank even when structured data is already complete. He proposes showing a fixed projected lift based on a rubric score for what Burnish applied, while clarifying that this is an estimate or score rather than a promise of actual improvement, and asks that the existing rubric score be checked and used.
- 3:33:44
Available Log Categories in Railway
In the context of a question about Railway access, the discussion distinguishes an unavailable or unlisted runtime log from the deploy, network-flow, and build logs shown as available.
- 3:33:59
Description of Glasses Intended for Screen Use
The speaker describes glasses that are not needed for vision correction, saying they have an anti-reflective coating and yellow lenses intended to reduce blue light from screens. This reflects his description and claim, not verified medical effectiveness.
- 3:36:16
Showing Structured-Data Application Status Without a Score
The proposed UI shows a green check indicating whether structured data is applied, without including it in the rubric score. It should be enabled by default after installation, with a link to the AI discoverability tab opening in a new window.
- 3:43:41
Investigating Stalled Regeneration and Background Tasks
After a regeneration attempt remained stuck, the discussion asked whether it depended on a follow-up branch and requested a plain-language explanation for the sudden failure. A later, fragmentary statement says the shop’s background tasks run in a single line.
- 3:46:45
Bulk Publishing and Product Optimization Status Tracking
The AI-ready tab needs a product-selection row so users can select multiple products and publish them in bulk. The recent-optimization card should promptly reflect optimized and published products, while “queued” should become “next batch” and show how many products are scheduled for it, following logic documented in the backend.
- 3:50:24
Manifesto Panel State-Update Bug
After the manifesto was completed, the Product Optimization panel reportedly continued prompting the user to create it instead of advancing to an application state. The issue was flagged for a suggested task to verify that the state transition is wired correctly.
- 3:55:59
Autopilot as a Command Center for AI Visibility
A Burnish page was described as more than a conventional log: it exposes an automated, recurring autopilot loop intended to improve what was called ‘GAO presence’ or AI visibility. The dashboard is envisioned as a command center for regular review.
- 3:57:17
Exploring the Visibility Page Before Scoring It
The work was framed as exploration rather than a QA walkthrough or scoring exercise. The proposed investigation covers the Visibility page’s layout, backend wiring, and possible variables before findings are gathered; the instructions continue beyond this page.
- 3:58:49
Implementation Priorities: Backend Before UI Polish
A practical review prioritizes completing backend logic, wiring the remaining components, and polishing the dashboard and UI afterward. Visibility, articles, and autopilot are identified as the main workstreams, without exposing private estimates.
Got a question about something in this stream?
Ask in the group