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

Original Article ↗ Hacker News Discussion ↗

A new tool called CodeSpeak aims to replace free-form English prompts with structured Markdown-style “specs” that LLMs use to generate and update code, positioning the spec rather than source files as the primary artifact. Commenters are split on whether this is truly a new programming language or just an orchestrated workflow for spec‑driven, agentic development, raising concerns about non‑determinism, under‑specified requirements, and drift between specs and implementation. Others see value in standardizing how intent is expressed to models, but argue that test generation, formal methods, and better handling of project knowledge and context may matter more than inventing a semi‑formal prompt language.

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.