If you're going to vibe code, why not do it in C?

What “vibe coding” is and whether it works

• Thread distinguishes between:
  • “Pure” vibe coding: user doesn’t understand the code at all, just prompts and ships.
  • Assisted coding: user understands language and reviews/iterates.
• Some argue vibe coding can create “robust, complex systems” and report building full web apps or Rust/Python libraries largely via LLMs.
• Others say everything they’ve seen beyond small prototypes is “hot garbage”: brittle, unreadable, unreliable, and dangerous in production.
• Several note LLMs often hallucinate APIs, mis-handle edge cases, and struggle badly in large, existing codebases.

Why not C (or assembly)?

• Critics of C for vibe coding emphasize:
  • Memory safety, UB, and threading bugs are still very real in LLM output.
  • C has few guardrails; small mistakes can mean security issues or crashes.
  • Debugging AI-written C or assembly is harder, especially if the human isn’t an expert.
• A few report success vibe-coding C for small utilities or numerical tasks, but generally only when they can personally review memory management.
• Some push idea to go further: LLMs could eventually emit machine code directly, bypassing languages—but others say that removes any human-auditable layer.

Languages seen as better for vibe coding

• Many argue for languages with:
  • Strong static types and good tooling: Rust, Haskell, TypeScript, Ada, SPARK, Lean, Coq, etc.
  • Memory safety via ownership or GC.
  • Fast, rich compiler feedback that LLMs can use as a “self-check.”
• Rust is widely cited: ownership, lifetimes, sum types, and error messages help both humans and LLMs; but some note LLMs struggle with lifetimes and deadlocks.
• Others prefer high-level GC’d languages (Python, JS, C#, Go) as safer, terser, and better-covered in training data; C++ and C are seen as long-tail and more error-prone.
• A minority suggest languages explicitly designed for LLMs: extremely explicit, local context, verbose specs/contracts, heavy static checking.

Tests, specs, and formal methods

• Strong view that vibe coding must be paired with:
  • Unit tests, fuzzing, property-based tests, invariants.
  • Possibly formal verification or dependently typed languages (Lean, Idris, Coq).
• Idea: ask LLMs to write tests and specs first (TDD), then iterate until tests pass.
• Some envision “vibe-oriented” languages whose verbosity and proof obligations are hostile to humans but ideal for machines and verification.

Broader process & human role

• Many say biggest bottleneck isn’t typing code but:
  • Vague or incorrect requirements.
  • Cross-team communication and politics.
  • Code review and long-term maintenance.
• LLMs help with scaffolding, refactors, boilerplate, and documentation, but:
  • They weaken human understanding if overused.
  • They risk alienating developers who enjoy problem-solving itself.
• There’s disagreement over net productivity: some report 2–5× speedups; others cite studies and experience suggesting far smaller or even negative gains without disciplined use.