La (seule) bonne façon de coder avec l’IA

Technological themes: “coding with AI” vs reality of speed

• The video opens with the idea that people split between those who “code with AI” and those who adopt it by necessity.
• It challenges the promise that AI automatically makes devs much faster:
  • Prompts can generate huge amounts of code quickly.
  • But sometimes you must “start all over,” raising the question of whether time is truly saved.
• Real speedups come from experienced practitioners being 5–10x faster, not from raw prompting alone.

Product/approach described: a practical “agent + orchestration” development workflow

A core claim is that the effective role evolves from “developer who writes everything” to an orchestrator who:

• turns tickets/specs into instructions,
• supervises/validates outputs,
• and intervenes only at key decision points.

Key workflow changes

• Specs first

  • Non-technical product people create reasonably good technical specs using AI tools (e.g., Cursor).
  • The engineer receives structured requirements rather than blank tasks.

• Implementation split by complexity

  • Small changes: often already implemented in the codebase (easy technical path).
  • Major/new features: require deeper engineering work (real-time, integration, new components/tools).

• Iterate with AI, then review

  • AI drafts via iterative prompts (“no, that doesn’t work” loops).
  • Then code generation proceeds; the human mainly reviews/approves (with agents assisting review).

• Design system thinking

  • The engineer shifts effort toward higher-level architecture (e.g., using Markdown docs rather than whiteboards).
  • Code writing is delegated to AI.

How “AI learns” without fine-tuning: context + persistence

AI improves mostly through prompt/context engineering, not by automatic long-term learning.

The guest explains a two-layer idea:

1. Within-session correction

   • If you fix a mistake and re-prompt, the AI “remembers” for that session.

2. Cross-session memory requires persistence

   • You must save rules/constraints so the AI applies them later (e.g., a project-wide rules file / context markdown).

Many teams try to make the AI “learn from mistakes,” but the practical mechanism is still to persist better rules and constraints.

Context engineering + token management are central constraints

The guest emphasizes that long context windows can fail subtly:

• If you stuff too much into the prompt, models effectively “forget” the beginning (context window saturation).

Selective context injection

• Rules apply only to relevant parts (front-end vs back-end).
• Tools or “wheel selection” helps the model include only what matters.

Token budgeting

• Keeping up with rapidly changing model/tool versions consumes both time and tokens.

Concrete tool examples (technology features)

1) RTK (Rust Token Killer)

• Purpose: reduce token usage from terminal/CLI command outputs during AI workflows.
• Mechanism: uses hooks to intercept commands and “filter” verbosity, keeping only essentials.
• Claimed impact: saves ~80–90% tokens for command-related context, improving latency/cost.
• Safety/bypass: AI may need full output sometimes; the system must allow bypassing RTK to avoid degrading results.

2) “Caveman” compression idea

• Purpose: reduce verbosity of text generated/used in prompts.
• Mechanism: instruct outputs in a compressed style (e.g., “talk to me like a caveman” / bullet-like minimal format).
• Notes:
  • token reduction can apply to both input and output billing,
  • overly extreme compression can reduce usefulness.

Prompt engineering essentials taught as an onboarding guide

The guest outlines common “levels” of how people start using Claude/AI:

1. Chatbot mode (level 0)

   • Re-explaining everything every time.
   • No project memory.

2. Add project memory via context markdown

   • Constraints/rules so the model stays consistent.

Training topics emphasized

• Context engineering
  • Providing constraints, quality rules, TDD rules, etc.
• Agents
  • Summoning specialized “characters” (backend/frontend/testing/system architect reviewers).
• Hooks
  • Trigger guardrails and automation (e.g., block dangerous patterns like rm -rf).
• Skills vs orchestration
  • Understanding small specialized capabilities (“skills”) vs agents orchestrating them.
• Measurable, structured, reusable prompts
  • Metaprompts and templated “tickets”.

Review/quality philosophy: monitoring, engineering basics, and “no YOLO shortcuts”

AI can speed generation, but quality still depends on engineering fundamentals:

• design patterns / SOLID,
• code slicing/modularity concepts,
• tests and monitoring strategies.

Key points:

• Monitoring is non-negotiable
  • Outages from traffic spikes and the cost of missing earlier monitoring signals are repeatedly stressed.
• Avoid a purely “YOLO” approach
  • Precision in prompts and engineering rules limits cost/latency and prevents fragile systems.

Key risks and lesson learned from management experiences (translated to engineering risk)

While not purely technical, the stories reinforce this theme:

• Under-specification/misalignment causes failures (e.g., miscommunication leading to an incident).
• Therefore, AI teams need alignment mechanisms:
  • constraints,
  • monitoring,
  • validation gates.

Main speakers / sources

• Main speaker/guest: Florian Brunot
• Host: Mathieu Sanchez (mentioned as host/intro)