Andrey Breslav created Kotlin to escape Java’s stagnation. Now, after 7 million developers adopted his language, he’s building CodeSpeak—a programming language where you write plain English instead of code. Launched in alpha this month, CodeSpeak promises to shrink codebases 5-10x by letting LLMs handle implementation while developers maintain high-level specifications. But Hacker News developers aren’t convinced: 146 comments debate whether this is software engineering’s future or a determinism nightmare.
What CodeSpeak Actually Is
CodeSpeak isn’t another AI coding assistant like Copilot or Cursor. It’s a formal programming language that uses plain-English descriptions as source code. You write specifications in structured English, and LLMs compile them to traditional languages—Python, JavaScript, Go, TypeScript, Kotlin, or Swift.
The pitch: “Maintaining specs is easier than maintaining code.” Instead of writing 100 lines of Python to fetch API data, validate emails, and store records, you write a 10-line specification. The LLM generates the implementation. Real-world examples on CodeSpeak’s website show 5.9x code reduction for yt-dlp and 9.9x for Faker.
This isn’t “vibe coding” for prototypes. CodeSpeak targets engineers building production systems where long-term maintenance matters more than rapid iteration. Version 0.1.0 is available now via PyPI as an alpha release. Mixed-mode projects let you combine manual code with generated components, integrating with existing codebases rather than forcing complete rewrites.
“CodeSpeak is built for humans, because we benefit from structure, knowing how to express what we want,” Breslav explained. The language adds modularity and reuse to natural language, designed for teams to organize and collaborate—not casual one-off scripts.
Why the Kotlin Creator’s Opinion Matters
Breslav isn’t just another startup founder chasing AI hype. He created Kotlin at JetBrains between 2010 and 2020, taking it from a whiteboard sketch to the default language for Android development. Seven million developers later, Kotlin proved he understands how to design languages that actually ship.
Kotlin succeeded because Java stagnated. From 2004 to 2010, Java 6 made zero language changes. Java 7’s improvements were minor. Lambdas didn’t arrive until 2014 with Java 8. Developers needed modern features—null safety, functional programming, concise syntax. Kotlin filled that gap.
Breslav sees a similar gap today. Traditional languages like Python, JavaScript, and Java were designed for humans writing code. But with AI coding tools hitting 65% weekly adoption among developers, according to Stack Overflow’s 2025 survey, we’re entering an era where LLMs generate most implementation code. Existing languages weren’t built for that workflow.
“Keeping humans in control of the software development lifecycle will matter even more as AI becomes more capable,” Breslav argues. CodeSpeak isn’t about replacing developers—it’s about elevating what they do. Less time debugging boilerplate, more time on system design and business logic.
The Determinism Problem Developers Can’t Ignore
Hacker News developers raised hard questions in a 176-point thread with 146 comments. The biggest concern: LLMs are non-deterministic. The same specification compiled twice might generate different code each time.
“This isn’t truly a language—it’s tooling to map specs to code,” argued user the_duke. “Non-deterministic model output, rapidly evolving LLM versions, and underspecified text create huge amounts of details that code has to make concrete.” If generated code changes on every compile, version control diffs become meaningless. How do you debug when the implementation shifts beneath you?
User pron went further: “Both formal specifications and generated code would be nondeterministic. This doesn’t solve the problem—it just moves it.” Another developer, sensanaty, noted that proving correctness is “basically impossible” when the output varies.
Spec-to-code drift is another concern. If developers manually modify generated code, it breaks synchronization with the specification. Regenerating from the spec wipes out manual fixes. User lifis pointed out that specs inevitably omit implementation details—variable names, algorithm choices, data structures—forcing LLMs to make arbitrary decisions developers can’t control without over-specifying and defeating the purpose.
User tonipotato identified what might be the core issue: “The problem with formal prompting languages is they assume the bottleneck is ambiguity in the prompt. In my experience, the bottleneck is actually the model’s context understanding, not prompt clarity.”
But supporters pushed back. User intrasight called this “an important direction in software engineering.” User seanmcdirmid suggested practical solutions: generate tests from specifications, use differential testing for validation, avoid regenerating entire codebases on spec changes, and maintain specs in version control alongside generated code.
Breslav addressed the drift problem directly, noting that CodeSpeak will include tooling to convert code back into specifications—letting developers synchronize changes in either direction.
The Irony Nobody’s Missing
User lich_king captured the absurdity: “We built LLMs so you can express ideas in English…English is too verbose…so we developed a programming language instead.”
User jajuuka expanded the thought: “We created programming languages to direct programs. Then created LLMs to use English to direct programs. Now we’ve created programming languages to direct LLMs.”
This is the philosophical tension at CodeSpeak’s core. Are we solving a real problem—that boilerplate code is tedious and error-prone—or creating new complexity by introducing another abstraction layer between intent and execution? The answer probably depends on your codebase. CRUD-heavy backends might benefit enormously. Performance-critical systems where implementation details matter won’t.
What This Means If You Actually Write Code
Should you learn CodeSpeak right now? No. It’s alpha 0.1.0. Wait for production stability and real-world validation before investing time.
But the skills shift is real regardless of whether CodeSpeak succeeds. AI coding tools are moving from assistants (autocomplete, chat suggestions) toward formal integration (structured specifications, automated generation). Developers who understand how to write clear, unambiguous specifications for AI systems will have an advantage. Those who only know syntax won’t.
The question isn’t whether Kotlin will be replaced by CodeSpeak—Kotlin is mature and battle-tested, CodeSpeak is an experiment. The question is whether junior developers who currently write boilerplate CRUD operations, API wrappers, and data transformations will find their roles automated by spec-driven generation.
Programming languages evolve with technology paradigms. Machine code gave way to assembly, then C, then high-level languages like Python. Each shift raised the abstraction level, letting developers focus on higher-order problems. CodeSpeak proposes the next shift: from code to specifications.
An Experiment Worth Watching
If CodeSpeak succeeds, expect a wave of “spec-first” programming languages. Bootcamps will teach specification writing instead of syntax memorization. Code reviews will become spec reviews. IDEs will optimize for spec-to-code workflows, not just autocomplete.
If CodeSpeak fails, it proves LLMs aren’t ready for formal language design. Developers will stick with traditional languages augmented by AI assistants—Cursor, Copilot, Claude Code—rather than adopting AI-native languages. The dream of 10x code reduction will remain a marketing pitch.
Either way, the conversation matters. Programming languages will evolve for the AI era. Whether Breslav’s vision is right or wrong, the experiment pushes the industry to confront how development workflows must change as AI generates more of our code.
Andrey Breslav changed how millions write Android apps with Kotlin. CodeSpeak might be his second revolution—or a cautionary tale about over-engineering the AI transition. Watch this space.
