Kotlin creator's new language: talk to LLMs in specs, not English

Original Article ↗ Hacker News Discussion ↗

What CodeSpeak Is (and Isn’t)

  • Many readers conclude it’s less a “new language” and more a workflow/tool: write per-file markdown specs, run a CLI that calls an LLM to generate or update code.
  • Two-way flow: build turns specs into code; takeover derives specs from existing code, enabling “mixed mode” where only some files are spec-managed.
  • Some see it as an intermediate “IL for natural language queries,” or as a structured way to pin and version prompts alongside code.

Perceived Benefits

  • Makes explicit, versioned specs the “source of truth,” with code treated as a compiled artifact.
  • Encourages spec-driven / BDD-like development: write requirements, generate code and tests, iterate by editing specs.
  • Can shrink hand-written code and centralize decisions; useful especially for agent-based workflows where specs guide autonomous tools.
  • Supporters like the declarative feel: specify intent, let agents handle imperative changes.

Critiques and Skepticism

  • Many argue it’s not truly “formal”; specs are still natural language with light structure, so ambiguity and model quirks remain.
  • Concern that nondeterministic LLMs mean the same spec won’t reliably regenerate the same code; some see this as incompatible with “spec as source of truth.”
  • Fear of spec–implementation drift, especially in large systems with many interacting specs.
  • Several think it’s easily reproducible with plain markdown + existing LLM IDEs; question the value of a closed, commercial wrapper.
  • Examples are seen as trivial; no convincing multi-file or architecture-scale case study yet.

Specs, Formality, and Correctness

  • Some want a pipeline: text → formal spec → verifiable code or tests, citing tools like TLA+, Dafny, etc.
  • Others note full formal verification is hard and expensive; most real systems settle for tests and partial guarantees.
  • Debate over whether fully detailed specs are “as hard as code,” and whether variable implementations are fine if tests and requirements pass.

Broader Reflections and Alternatives

  • Comparisons to UML, BDD/Gherkin, literate programming, and “spec as tests” workflows.
  • Some argue the main bottleneck is model context/knowledge, not prompt language; advocate structuring domain knowledge rather than inventing new DSLs.
  • Mixed sentiment about a future where humans mainly write specs/tests and rarely touch code.

UX and Miscellaneous

  • Complaints about dark-mode-only design and lack of an easy light theme.
  • Multiple references to similar or competing tools and personal ad-hoc spec systems.