5 TASKS IN 7 HOURS
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 work on a Shopify app and a multi-agent “Command Center” workflow that divides exploration, implementation, and auditing while keeping the human responsible for setup and sensitive decisions. Practical work centered on connecting AI APIs, aligning environment variables across Railway and Supabase, configuring Sentry for production monitoring, and troubleshooting deployment, authentication, trial, approval, and cancellation flows. Some deployments and checks were reported complete, but issues including an HTTP 500 error and parts of the user flow remained unresolved, illustrating the limits of automation and the value of clear logs, staged audits, and CI/CD. Luqman also discussed choosing coding tools by task, retained context, and usage limits; his comparisons of Codex, Claude, and Kimi K2 were framed as limited workflow impressions rather than controlled benchmarks. Broader topics included designing defensible scores for stores’ visibility in AI answers, the unsettled GEO-versus-AEO terminology relative to SEO, and validating markets, pricing, distribution, and product economics before accelerating development. Research-oriented discussion extended to LLM interpretability and the lottery ticket hypothesis, as well as Luqman’s views on Chinese and US model ecosystems, reliance on NVIDIA chips, and the need for accessible Arabic models and local pricing. Audience discussions covered AI’s effect on developer roles, code comprehension and debugging, parallel milestones and dependencies, agent-rule context costs, productivity habits, and peer learning. This portion also included additional practical discussions about workstation and operating-system choices, stream latency, development practices before AI, and programmatic video creation with Remotion. Preparing Shopify submission media and polishing the Command Center for a possible GitHub release remained future plans, not completed outcomes.
127 moments from the stream
- 2:14:05
Inspecting Failure Logs Before Redeployment
He asks for a careful analysis of the deployment log, a proposed fix before another attempt, and a preflight review with questions whenever confidence is low. He suspects—but does not confirm—that configuration such as API keys, database URLs, or the Supabase integration may be involved.
- 2:16:34
Choosing Tools and Parallel Execution Based on Task Context
He discusses whether to continue with an agent that already holds the session’s long context or pass the error log to Codex. He also describes running a related batch of tasks in parallel rather than one by one to accelerate a milestone, presented as a workflow experience rather than a controlled benchmark.
- 2:18:40
Baseline Rules and Per-Task Generated Instructions
Answering a question about general rules, he explains that baseline rules load with each session while task-specific prompt files are generated dynamically before each task for the builder agent to follow. He also mentions an older rules folder whose present value he is unsure about and has not developed further.
- 2:21:44
Possible Failure from External-Provider Requirements
He offers a tentative general explanation that some failures can arise when an integration must follow an external provider’s own rules or requirements. The captions are unclear here, so no specific provider or root cause is asserted.
- 2:23:25
Handling environment setup and provider connections
Work was temporarily delayed by environment variables, APIs, and connections between the project and external providers, with the workflow expected to resume once they were configured.
- 2:26:11
Redeploying on Railway or pushing through GitHub?
A practical discussion of whether to rebuild a failed deployment with the same Railway configuration or push changes through GitHub to trigger an automatic redeploy.
- 2:27:19
Agent rules files and context cost
Rules files are described as persistent instructions read by a coding agent, with a suggestion to let an agent inspect the project and recommend suitable rules. The speaker cautions that rules should stay focused because rereading them each session may increase token usage, and mentions Kilo Code without claiming to have tested this feature personally.
- 2:30:23
Verifying deployment and push after configuration changes
After configuration changes, the process appeared faster, and the captions record a completed deployment and push before moving to the next step.
- 2:31:16
A task shared by the agent and operator
The speaker begins explaining a blue-marked task state in Command Center, indicating that both the agent and the human operator have required parts; the excerpt ends before the explanation is completed.
- 2:32:21
Handing Off Tasks Between a Coding Agent and the User
The speaker explains that an agent can wire code components, while some steps—such as supplying API keys—still require human action. The speaker plans to have Codex audit the milestone’s tasks and prepare prompts for the next milestone from scratch, expecting this to take time and tokens.
- 2:36:08
Assessing Coding-Agent Utilization
The speaker critiques the day's workflow efficiency but explains that tedious manual prerequisites had to be completed before the coding agent could be useful. The broader point is that low agent utilization does not always mean there was a practical opportunity to use it.
- 2:39:15
Completing the Manual Portion After the Agent's Work
After the agent finishes its portion, the speaker moves to the part requiring his intervention and begins working with a service and a configuration-file path. The captions are too unclear to support more specific technical steps or names.
- 2:45:47
Can Multiple Milestones Be Worked on at Once?
Answering an audience question, he explains that multiple milestones can be worked on concurrently when the project is structured for it, but some tasks remain blocked until dependencies in earlier milestones are completed. He says these relationships are documented in the roadmap and that the workflow operator chooses the execution approach.
- 2:49:38
Command Center Automation and Deployment Monitoring
He explains that the command center is designed to be automated, with an agent advancing tasks after a milestone begins while respecting dependencies. During the ongoing work, he reviews a possible deployment warning and then checks logs that appeared healthy at that point, without claiming final success.
- 2:53:20
Considering AI Models for Web Work and Debugging
The speaker discussed AI models he was considering trying for website work and debugging, and noted that one option was not working for him. The captioned model and version names are too uncertain to state as fact.
- 2:57:12
Not Sacrificing Quality for Speed
The speaker said that although he wanted to finish quickly, he did not want speed to come at the expense of quality or the value delivered to users.
- 2:58:14
GEO or AEO? Naming Optimization for AI Answers
The speaker explained that optimizing content or product visibility in AI-generated answers was still a young field whose name had not settled between GEO and AEO. He compared interest in the terms and their relationship to SEO, judged GEO to be more widely used at the time of recording, allowed that the market might still adopt AEO, and noted that GEO techniques can also support SEO.
- 3:04:35
Long Context When Switching Coding Tools
He explains that some coding tasks become tedious and that he did not move this particular task to Codex, despite its usefulness for debugging, because the current session contained extensive context that would be costly to rebuild.
- 3:11:23
Plan to Publish Command Center on GitHub
Responding to an audience question, he says he intends to organize and polish the Command Center and publish it on GitHub when time allows; this is a future intention, not a claim that a release is complete.
- 3:13:08
Giving Precise Evidence to Fix a Failed Deployment
In a final attempt with a coding tool, he asks it to stop guessing and make the next deployment succeed, attaching a screenshot and identifying two issues: only the worker service deployed while the web service did not deploy automatically, and the process crashed near the end. The captions do not establish that the issue was resolved.
Got a question about something in this stream?
Ask in the group