3 ms·
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
by lifis 7mo ago
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.
- deleted 7mo ago[deleted]
- souvlakee 7mo agoAs 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 7mo agoI second that :)
- abreslav 7mo ago> The limitation seems to be that you can't modify the code yourself if you want the spec to reflect it Eventually, 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 https://codespeak.dev/blog/codespeak-takeover-20260223
- newsoftheday 7mo ago> 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 7mo agoWe will and soon because it does not have to be deterministic like a compiler. It only has to pass all tests.
- my_throwaway23 7mo agoWho is writing the tests?
- justonceokay 7mo agoIn the future users will write the tests
- abreslav 7mo agoThere are different kinds of tests: * regression tests – can be generated * conformance tests – often can be generated * acceptance tests – are another form of specification and should come from humans. Human intent can be expressed as * documents (specs, etc) * review comments, etc * tests with clear yes/no feedback (data for automated tests, or just manual testing) And this is basically all that matters, see more here: https://www.linkedin.com/posts/abreslav_so-what-would-you-sayyou-do-here-activity-7433088584083017728-I_u0 https://www.linkedin.com/posts/abreslav_so-what-would-you-sa...
- vbezhenar 7mo agoCompiler is not 100% deterministic. Its output can change when you upgrade its version, its output can change when you change optimization options. Using profile-guided optimization can also change between runs.
- abreslav 7mo ago> 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. Working on that as well. We need to be a lot more flexible and configurable
- lifis 7mo agoAlso 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.
- boznz 7mo agoAlso a bit formal. Maybe something like this will be the output of the prompt to let me know what the AI is going to generate in the binary, but I doubt I will be writing code like this in 5 years, English will probably be fine at my level.
- WASDx 7mo agoI think these limitations could be addressed by allowing trivial manual adjustments to the generated code before committing. And/or allowing for trivial code changes without a spec change. The judgement of "trivial" being that it still follows the spec and does not add functionality mandating a spec change. I haven't checked if they support any of this but I would be frustrated not being allowed to make such a small code change, say to fix an off-by-one error that I recently got from LLM output. The code change would be smaller than the spec change. Cool idea overall, an incremental psuedocode compiler. Interesting to see how well it scales. I can also see a hybrid solution with non-specced code files for things where the size of code and spec would be the same, like for enums or mapping tables.