Discussion

Shrink your codebase5-10x

ljlolel: Getting so close to the idea. We will only have Englishscripts and don’t need code anymore. No compiling. No vibe coding. No coding. Https://jperla.com/blog/claude-electron-not-claudevm

pjmlp: I think stuff like Langflow and n8n are more likely to be adopted, alongside with some more formal specifications.

theoriginaldave: I for one can't wait to be a confident CodeSpeak programmer /sarcDoes this make it a 6th generation language?

lich_king: We built LLMs so that you can express your ideas in English and no longer need to code.Also, English is really too verbose and imprecise for coding, so we developed a programming language you can use instead.Now, this gives me a business idea: are you tired of using CodeSpeak? Just talk to our product in English and explain what CodeSpeak program you need.

amelius: COBOL?

souvlakee: No joke. I'm 100% sure that if it's successful, we will find CC's skill to write specs for CodeSpeak.

jajuuka: We created programming languages to direct programs. Then created LLM's to use English to direct programs. Now we've create programming languages to direct LLM's. What is old is new again!

the_duke: This doesn't make too much sense to me.* This isn't a language, it's some tooling to map specs to code and re-generate* Models aren't deterministic - every time you would try to re-apply you'd likely get different output (without feeding the current code into the re-apply and let it just recommend changes)* Models are evolving rapidly, this months flavour of Codex/Sonnet/etc would very likely generate different code from last months* Text specifications are always under-specified, lossy and tend to gloss over a huge amount of details that the code has to make concrete - this is ine in a small example, but in a larger code base?* Every non-trivial codebase would be made up of of hundreds of specs that interact and influence each other - very hard (and context - heavy) to read all specs that influence functionality and keep it coherentI do think there are opportunities in this space, but what I'd like to see is:* write text specifications* model transforms text into a *formal* specification* then the formal spec is translated into code which can be verified against the spec2 and three could be merged into one if there were practical/popular languages that also support verification, in the vain of ADA/Spark.But you can also get there by generating tests from the formal specification that validate the implementation.

davedx: My process has organically evolved towards something similar but less strictly defined:- I bootstrap AGENTS.md with my basic way of working and occasionally one or two project specific pieces- I then write a DESIGN.md. How detailed or well specified it is varies from project to project: the other day I wrote a very complete DESIGN.md for a time tracking, invoice management and accounting system I wanted for my freelance biz. Because it was quite complete, the agent almost one-shot the whole thing- I often also write a TECHNICAL-SPEC.md of some kind. Again how detailed varies.- Finally I link to those two from the AGENTS. I also usually put in AGENTS that the agent should maintain the docs and keep them in sync with newer decisions I make along the way.This system works well for me, but it's still very ad hoc and definitely doesn't follow any kind of formally defined spec standard. And I don't think it should, really? IMO, technically strict specs should be in your automated tests not your design docs.

the_duke: I think many have adopted "spec driven development" in the way you describe.I found it works very well in once-off scenarios, but the specs often drift from the implementation. Even if you let the model update the spec at the end, the next few work items will make parts of it obsolete.Maybe that's exactly the goal that "codespeak" is trying to solve, but I'm skeptical this will work well without more formal specifications in the mix.

lifis: As far as I can tell it's not a new language, but rather an alternative workflow for LLM-based development along with a tool that implements it.The idea, IIUC, seems to be that instead of directly telling an LLM agent how to change the code, you keep markdown "spec" files describing what the code does and then the "codespeak" tool runs a diff on the spec files and tells the agent to make those changes; then you check the code and commit both updated specs and code.It has the advantage that the prompts are all saved along with the source rather than lost, and in a format that lets you also look at the whole current specification.The limitation seems to be that you can't modify the code yourself if you want the spec to reflect it (and also can't do LLM-driven changes that refer to the actual code), and also that in general it's not guaranteed that the spec actually reflects all important things about the program, so the code does also potentially contain "source" information (for example, maybe your want the background of a GUI to be white and it is so because the LLM happened to choose that, but it's not written in the spec).The latter can maybe be mitigated by doing multiple generations and checking them all, but that multiplies LLM and verification costs.Also it seems that the tool severely limits the configurability of the agentic generation process, although that's just a limitation of the specific tool.

zozbot234: > you can't modify the code yourself if you want the spec to reflect itYou could diff the code afterwards and ask the LLM to reverse-engineer these changes into the spec. This is something that LLMs do quite well at.

souvlakee: As far as I can tell C is not a new language, but rather an alternative workflow for assembly development along with a tool that implements it.

abreslav: I second that :)

gritzko: So is it basically Markdown? The landing does not articulate, unfortunately, what the key contribution is.

matthewkayin: I tried looking through some of the spec samples, and it was not clear what the "language" was or that there was any syntax. It just looks like a terse spec.

oceanwaves: In my building and research of Simplex, specs designed for LLM consumption don't need a formalized syntax as much as they just need an enforced structure, ideally paired with a linter. An effective spec for LLMs will bridge the gap between natural language and a formal language. It's about reducing ambiguity of intent because of the weaknesses and inconsistencies of natural language and the human operator.

onion2k: Models aren't deterministic - every time you would try to re-apply you'd likely get different output (without feeding the current code into the re-apply and let it just recommend changes)If the result is always provably correct it doesn't matter whether or not it's different at the code level. People interested in systems like this believe that the outcome of what the code does is infinity more important than the code itself.

SpaceNoodled: That's a huge "if."

tamimio: As someone who hates writing (and thus coding) this might be a good tool, but how’s is it different from doing the same in claude? And I only see python, what about other languages, are they also production grade?

ppqqrr: i’ve been doing this for a while, you create an extra file for every code file, sketch the code as you currently understand it (mostly function signatures and comments to fill in details), ask the LLM to help identify discrepancies. i call it “overcoding”.i guess you can build a cli toolchain for it, but as a technique it’s a bit early to crystallize into a product imo, i fully expect overcoding to be a standard technique in a few years, it’s the only way i’ve been able to keep up with AI-coded files longer than 1500 lines

lifis: Also they seem to want to run this as a business, which seems absurd to me since I don't see how they can possibly charge money, and anyway the idea is so simple that it can be reimplemented in less than a week (less than a day for a basic version) and those alternative implementations may turn out to be better.It also seems to be closed-source, which means that unless they open the source very soon it will very likely be immediately replaced in popularity by an open source version if it turns out to gain traction.

DrJokepu: > Models aren't deterministicIs that really true? I haven’t tried to do my own inference since the first Llama models came out years ago, but I am pretty sure it was deterministic: if you fixed the seed and the input was the same, the output of the inference was always exactly the same.

abreslav: > The limitation seems to be that you can't modify the code yourself if you want the spec to reflect itEventually, we'll end up in a world where humans don't need to touch code, but we are not there yet. We are looking into ways to "catch up" the specs with whatever changes happen in the code not through CodeSpeak (agents or manual changes or whatever). It's an interesting exercise. In the case of agents, it's very helpful to look at the prompts users gave them (we are experimenting with inspecting the sessions from ~/.claude).More generally, `codespeak takeover` [1] is a tool to convert code into specs, and we are teaching it to take prompts from agent sessions into account. Seems very helpful, actually.I think it's a valid use case to start something in vibe coding mode and then switch to CodeSpeak if you want long-term maintainability. From "sprint mode" to "marathon mode", so to speak[1] https://codespeak.dev/blog/codespeak-takeover-20260223

newsoftheday: > Eventually, we'll end up in a world where humans don't need to touch code, but we are not there yet.Will we though? Wouldn't AI need to reach a stage where it is a tool, like a compiler, which is 100% deterministic?

intrasight: We will and soon because it does not have to be deterministic like a compiler. It only has to pass all tests.

roxolotl: This doesn't seem particularly formal. I still remain unconvinced reducing is really going to be valuable. Code obviously is as formal as it gets but as you trend away from that you quickly introduce problems that arise from lack of formality. I could see a world in which we're all just writing tests in the form of something like Gherkin though.

tasuki: > I could see a world in which we're all just writing tests in the form of something like Gherkin though.Yes, and the implementation... no one actually cares about that. This would be a good outcome in my view. What I see is people letting LLMs "fill in the tests", whereas I'd rather tests be the only thing humans write.

newsoftheday: > Yes, and the implementation... no one actually cares about that.There has been a profession in place for many decades that specifically addresses that...Software Engineering.

rebolek: AGENTS.md is nice but I still need to remind models that it exists and they should read it and not reinvent the wheel every time.

allthetime: There should be a setting to include specific files in every prompt/context. I’m using zed and when you fire up an agent / chat it explicitly states that the file(s) are included.