Video summary

How to Use AI for Programming

Main summary

Key takeaways

Educational

Main ideas / lessons

  • AI can be good for programming, but results vary based on the user and workflow.

    • The speaker argues AI is objectively good for programming (with the best current models), but it’s not a replacement for an engineer.
    • If someone expects AI to “take the workload off” completely, they’ll likely be disappointed.

  • AI is a tool that amplifies an experienced engineer’s productivity.

    • You must still learn, understand systems, and direct/verify what AI produces.

  • For best results, use AI in a “high-signal” workflow:

    • Ask AI for workflow guidance
    • Build guardrails (tests, sanitizers, conventions)
    • Keep human oversight

  • Practical engineering beats theory—AI can help you test faster and more thoroughly.

    • Instead of arguing performance theoretically, AI can help generate code, benchmarks, and test harnesses so you can measure reality.

  • In serious/high-performance domains (game engines/robotics simulation), quality requires discipline.

    • The speaker explicitly rejects “let agents run all night and don’t read code” for their context.
    • They still review and micromanage code; AI runs help in the background, but code must be refined and verified before production.

  • Ask for provenance and evidence from AI.

    • When AI generates reports or claims, the speaker values sources/line references so they can verify accuracy.

  • Structure your AI knowledge with persistent instructions (“Claude.md”) and reusable procedures (“skills”).

    • A persistent repo-level instruction file helps prevent repeated mistakes.
    • Skills/commands represent repeatable procedures (like code review, testing, creating PRs).

  • Be specific in prompts to reduce wasted tokens and improve success rate.

    • “Broad prompts” can lead to inefficiency or missed root causes.
    • Narrow, context-rich prompts (e.g., “renderer2d.cpp line X…”) can be much faster and more actionable.

Methodology / workflow instructions (detailed)

1) Start by asking AI how to use it well (meta-prompt)

  • Example prompt style:
    • “Hey Claude, how do I use you for programming? You seem to misunderstand my project—what can I do to make you work better?”
  • Goal:
    • Get AI to propose a workflow tailored to your purpose and quality expectations.
  • Expected benefit:
    • Guidance will likely match the speaker’s points, and it will also come from AI’s own “view” of the task.

2) Treat AI as “engineer on your team,” not “auto-builder”

  • Keep responsibilities with humans. You still must:
    • Maintain understanding of architecture and tradeoffs
    • Keep learning
    • Direct design decisions
    • Verify correctness, performance, and safety
  • Use AI to do:
    • Draft code
    • Generate tests/benchmarks
    • Set up tooling and harnesses
    • Create reports and documentation
    • Explore options and accelerate iteration cycles

3) Build guardrails: conventions + testing + verification

  • Create a repo root instruction file (for Claude: Claude.md) that:
    • Is loaded every session
    • Focuses on “non-negotiable rules” and mistake prevention, such as:
      • Performance constraints (e.g., no allocations in hot paths)
      • Exception policy in engine core (e.g., no exceptions)
      • Memory ownership conventions
      • Naming conventions
      • Module boundaries
      • Build/test commands and test bench commands
      • Graphics API rule: “When in doubt, stop and cite the spec; do not guess”
  • Ask/enable AI to suggest additional guardrails:
    • Regression checks
    • Sanitizer builds (e.g., ASAN/UBSAN conceptually)
    • Tooling that enforces quality continuously

4) Prefer a “tested slices” approach over fully autonomous coding

  • Quality philosophy:
    • Even if AI can run pipelines, the team:
      • Reads every line of code
      • Uses micromanagement for production-quality work
      • Lets AI run longer tasks only when they can later be refined/verified
  • Verification pipeline concept:
    • AI writes C++ + code
    • AI can also generate:
      • Python harnesses
      • Test runners
      • Comparisons
    • The suite checks:
      • Compiles
      • Passes tests
      • Meets performance targets
    • If it fails, AI iterates until passing (behind the scenes)

5) Use the CLI workflow (terminal + model integration)

  • Example tooling described:
    • Using Claude from the terminal/CLI rather than a desktop app
    • Working with multiple directories/checkouts/branches concurrently
  • Core benefit:
    • Faster iteration and better context switching across branches/tasks.

6) Choose model and “effort” settings based on needs

  • Model guidance (speaker’s stated preferences):
    • Stick with a performant model (e.g., “Opus” mentioned as good)
    • Avoid models that:
      • Take much longer
      • Use more tokens
      • Don’t return enough extra value (speaker’s experience with “Fable”)
  • Effort setting strategy:
    • Default: medium-high (“X high”)
    • Switch to higher (“max”) when needed
    • Ultra not relied on (speaker indicates limited testing)

7) Understand domain differences (avoid comparing workflows blindly)

  • Web apps vs engines/robotics simulation:
    • Capabilities/workflows aren’t interchangeable.
    • Engines can be harder; AI may behave differently depending on training data availability and domain complexity.

8) Use reports to accelerate learning and debugging

  • For codebase understanding:
    • Ask AI to generate technical reports (often Markdown; optionally converted to PDF).
  • Report content the speaker expects:
    • Strengths/weaknesses compared to other approaches
    • Existing bugs to fix and suggested solutions
    • Performance/architecture analysis
  • How to ensure correctness:
    • Demand sources/line references
    • Verify claims by checking referenced files
    • Use intuition and engineering judgment (AI and humans both make mistakes)

9) Convert AI output into repo artifacts (documentation that sticks)

  • Examples of what the speaker has AI generate:
    • building.md style instructions for users
    • Claude.md guardrail documentation
    • Markdown/PDF reports about subsystems
  • Benefit:
    • AI output becomes reusable team knowledge and onboarding material.

10) Debugging: be narrow and use exact anchors

  • Bad approach (inefficient):
    • “It crashes when I draw too many circles” (broad → rabbit hole, more tokens, slower)
  • Better approach (speaker’s preferred pattern):
    • Provide exact location/context, e.g.:
      • “renderer2d.cpp line 45…485… we haven’t implemented next batch for circles—do that”
  • Expected result:
    • Faster, more targeted changes
    • Reduced token usage
  • Additional caution:
    • In large obscure engines, narrow prompts may matter even more; broad prompts may fail to find the root cause.

11) Organize reusable procedures with “skills” (not everything in Claude.md)

  • Claude.md:
    • Holds “always true” guardrails.
  • Skills:
    • Hold repeatable procedures and automation, such as:
      • A code review skill (/cr)
      • Running tests/benchmarks
      • Generating render tests and image diffs
      • Creating architecture decision records (ADR)
  • Skill design principles:
    • Only “skillify” when the procedure is:
      • Non-obvious
      • Must be consistent
      • Requires real work that saves time repeatedly
    • Don’t create skills for tasks you’d do correctly anyway.

12) Example skill: /cr (code review automation)

  • Behavior described:
    • Checks unstaged/staged/uncommitted files (working tree treated as change set)
    • Enforces conventions
    • Ensures testing is present
    • Flags overly verbose comments
    • Avoids duplicate code
    • Prefers existing engine APIs; recommends extending APIs when appropriate
  • Skill usage:
    • Invoke via /cr and optionally pass options like --stage
    • AI can provide help via “How do I use the /cr skill?”

13) Example advanced automation (self-testing loop concept)

  • Capability described:
    • Create a skill that:
      • Runs automated engine tests (e.g., puppeteer-like UI control)
      • Executes deterministic scenarios (create scene objects, physics, render outcomes)
      • Takes screenshots or records output
      • Verifies expected behavior
      • If failing, digs via logs/tooling, then iterates to fix and rerun
  • Key idea:
    • Make testing reproducible and loopable so AI can iterate with verification.

14) Use modes like auto/plan to structure larger features

  • Auto mode:
    • Let AI implement while maintaining guardrails.
  • Plan mode:
    • Ask AI to plan a feature properly (generate reports/iterations), then implement based on the plan.
  • Recommendation:
    • For bigger changes in existing codebases, planning + staged implementation improves outcomes.

Speaker(s) / sources featured

  • Primary speaker: The YouTube creator/host (speaker repeatedly refers to “my experience,” “my team,” and their workflow; references “this channel” and “new game engine series”).
  • Sponsored source: Let’s Get Rusty
    • Rust training site: let'sgetrusty.com/startwithchannel
  • AI model(s) referenced as tools:
    • Claude Opus (and “Claude” generally)
    • GPT Codex
    • Fable
    • Mentions CodeX (as another AI agent platform)

Original video