The experience of vibe coding a real project in a specific domain (Emacs/Org-mode workflows) is more instructive than synthetic benchmarks. The observation that AI does well with the "mechanical" parts but struggles with the "why" behind design decisions resonates — and it's structural, not a temporary capability gap.
What strikes me about reflections like this is the recurring theme of the developer spending most of their effort on context management: explaining what already exists, why it exists that way, and what constraints matter. That labor is essentially creating the documentation that should have existed from the start.
The Agile Vibe Coding Manifesto frames this as a first-class concern: "context is explicit and versioned" and "knowledge remains accessible." The point isn't that AI is bad at Emacs Lisp — it's that domain knowledge that lives only in the developer's head is a fragility that vibe coding exposes rather than creates.
Worth reading if you're thinking about how to structure AI-assisted projects in specialized domains: https://agilevibecoding.org
What strikes me about reflections like this is the recurring theme of the developer spending most of their effort on context management: explaining what already exists, why it exists that way, and what constraints matter. That labor is essentially creating the documentation that should have existed from the start.
The Agile Vibe Coding Manifesto frames this as a first-class concern: "context is explicit and versioned" and "knowledge remains accessible." The point isn't that AI is bad at Emacs Lisp — it's that domain knowledge that lives only in the developer's head is a fragility that vibe coding exposes rather than creates.
Worth reading if you're thinking about how to structure AI-assisted projects in specialized domains: https://agilevibecoding.org