Project ideas from Hacker News discussions.

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

📝 Discussion Summary (Click to expand)

1. Spec‑driven development is the core idea, but its formality is debated

“We built LLMs so that you can express your ideas in English and no longer need to code.” – lich_king
“The idea is this would be a kind of IL for natural language queries.” – kevin_thibedeau
“It is a formal ‘way’ aka like using json or xml like tons of people are already doing.” – koolala

2. Determinism and consistency of LLM‑generated code are a major concern

“Models aren’t deterministic – every time you would try to re‑apply you’ll likely get different output.” – the_duke
“If the spec is so complete that it covers everything, you might as well write the code.” – tomtomtom777
“The entire thing about determinism is a red herring… prompt instability doesn’t matter because… the code does not matter if the spec is formal enough.” – vidarh

3. Human‑coding vs LLM‑coding: job impact and trust

“We built LLMs so that you can express your ideas in English and no longer need to code.” – lich_king (repeated)
“We’re looking to eliminate the need for humans to touch code, but we’re not there yet.” – abreslav
“If you’re going to eliminate our job, we need to be sure the output is 100 % deterministic.” – newsoftheday

4. Practicality and skepticism of CodeSpeak/“English‑like” languages

“It looks like a tool that just turns code into specs, and it’s not clear how it’s better than existing wrappers.” – pshirshov
“The tool severely limits the configurability of the agentic generation process.” – abreslav
“I don’t think this is the gotcha you think it is… it’s just a code‑generator wrapper.” – paxys

These four themes capture the bulk of the discussion: the promise of spec‑driven, English‑like interfaces; the technical hurdle of deterministic LLM output; the debate over whether LLMs will replace human coders; and the ongoing skepticism about whether CodeSpeak actually offers a meaningful improvement over current tooling.


🚀 Project Ideas

Generating project ideas…

SpecLint

Summary

  • A linter for natural‑language specifications that flags ambiguity, missing structure, and consistency errors.
  • Provides instant feedback to spec writers, reducing the need for manual review and improving downstream code generation.

Details

Key Value
Target Audience Spec writers, LLM‑driven dev teams, product managers
Core Feature Real‑time parsing of Markdown/Plain‑English specs, syntax‑style checks, consistency validation, auto‑suggestions
Tech Stack Node.js, TypeScript, NLP libraries (spaCy, HuggingFace), VS Code extension, CLI
Difficulty Medium
Monetization Hobby

Notes

  • HN commenters complain about “not clear what the language was or that there was any syntax” (matthewkayin). SpecLint turns vague specs into a structured, linted format.
  • Enables teams to adopt spec‑driven workflows without the overhead of learning a new formal language.

SpecDiff

Summary

  • A diff engine that tracks changes in natural‑language specs and automatically generates LLM prompts to update code accordingly.
  • Keeps code and spec in sync, reducing manual re‑generation and ensuring intent preservation.

Details

Key Value
Target Audience LLM‑based dev teams, CI/CD pipelines, product owners
Core Feature Spec change detection, prompt generation, versioned spec repository, integration with Git hooks
Tech Stack Python, FastAPI, OpenAI/Anthropic API, GitHub Actions, Docker
Difficulty High
Monetization Revenue‑ready: subscription (team tier)

Notes

  • Addresses frustration that “specs designed for LLM consumption don’t need a formalized syntax” (oceanwaves) but still need structure. SpecDiff bridges the gap by automating the “apply changes” step.
  • Provides a practical utility for teams that want to avoid “re‑generating the entire program” on every spec tweak.

SpecTestGen

Summary

  • Automatically generates property‑based and scenario‑based tests from natural‑language specs.
  • Ensures that generated code satisfies the spec and provides a safety net against LLM hallucinations.

Details

Key Value
Target Audience QA engineers, LLM‑driven devs, test‑first teams
Core Feature Spec parsing → test skeletons (Python/JS), integration with Hypothesis/QuickCheck, test coverage reports
Tech Stack Go, Rust, or Python, test frameworks, CLI, CI integration
Difficulty Medium
Monetization Hobby

Notes

  • HN users note the lack of “formal acceptance tests” (tobias). SpecTestGen turns vague specs into concrete test suites, giving developers confidence in LLM‑generated code.
  • Encourages a “tests are the spec” mindset, reducing the drift between spec and implementation.

HN Light‑Mode Reader

Summary

  • A browser extension that renders Hacker News pages in a customizable light theme with accessibility options (font size, contrast, reader mode).
  • Solves the pain point of “black‑on‑white is best” for users with light‑sensitivity or visual impairments.

Details

Key Value
Target Audience HN readers, accessibility advocates, developers
Core Feature Theme toggling, CSS overrides, reader‑mode extraction, dark‑mode bypass
Tech Stack JavaScript, WebExtension APIs, CSS, optional React for options UI
Difficulty Low
Monetization Hobby

Notes

  • Directly addresses comments from “kleiba” and “skydhash” about difficulty reading dark mode.
  • Provides a practical utility that could spark discussion on accessibility in tech communities.

Read Later