Know Today
👀 Keep an eye on
- Coding agents can now reportedly build a playable, asset-free 3D vertical slice and iterate against browser screenshots, shifting the bottleneck toward evaluation and design judgment.
- A versioned
design.mdorSTATUS.mdgives a new agent enough context to continue work without re-explaining the codebase from scratch. - Browser execution catches failures that static code review misses, including broken controls, camera clipping, unclear navigation, and unreachable content.
- Choosing one model per development phase may outperform standardising on one agent for scaffolding, debugging, visual polish, and targeted fixes.
🛠️ Practical workflows
| Workflow | Practical use |
|---|---|
| Brief → runnable slice | Use a detailed product brief to test an interaction loop before investing in a full asset or engineering pipeline. |
| Run and inspect | Require the agent to launch the app, execute checks, capture screenshots, and compare results with explicit acceptance criteria. |
| Checkpoint before handoff | Commit working state before switching sessions or models, so a misguided change is cheap to reverse. |
| Human product review | Reserve playtesting and UX review for affordances, pacing, visual distinction, and whether fixes actually improve the experience. |
💭 Opinions worth testing
- Opinion: AI is becoming a strong implementation multiplier, but experienced design, QA, art direction, and prioritisation remain the work that makes a prototype worth shipping.
- Prediction: Most people will still choose curated software and games over generating every detail themselves; this supports treating generated experiences as an additional format, not a replacement for polished products.
⚠️ Caveats
- Reported capability: Timing, model performance, code volume, and quality claims are anecdotal and need task-specific verification.
- Agent-reported fixes can be wrong; visual changes and balancing decisions need a fresh run plus human review.
- A code-generated prototype does not establish production quality, licensing suitability, accessibility, performance, or maintainability.
✨ Try this today
1. Run a two-agent handoff
Ask one LLM to scaffold a tiny browser app, then commit it and give a second LLM a concise STATUS.md with architecture, known defects, and acceptance checks. The outcome should reveal whether the document preserves enough intent for a focused follow-up change.
2. Make visual verification mandatory
Pick a small UI or game prototype and have an LLM run it locally, take screenshots, and list observed failures before proposing fixes. Expect to find issues that are invisible in the source, such as layout overflow, unclear controls, or broken interaction paths.
3. Benchmark by development phase
Give two LLMs the same narrowly scoped debugging task and separately compare them on a greenfield scaffold or UI refinement task. The result is a practical model map for your own workflow instead of a single vague “best model” ranking.
4. Test an interaction loop before polishing
Describe a compact interactive concept in a detailed prompt and ask an LLM to make a runnable vertical slice with no external assets. Use a short human test session to decide whether the core loop deserves further engineering and design time.