3 ms·
> 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
by 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.
- CWIZO 7mo agoIf you change inputs then obviously you will get a different output. Crucially using the same inputs, however, produces the same output. So compilers are actually deterministic.
- jason_oster 7mo agoThis is irrelevant over the long run because the environment changes even if nothing else does. A compiler from the 1980's still produces identical output given the original source code if you can run it. Some form of virtualization might be in order, but the environment is still changing while the deterministic subset shrinks. Having faith that determinism will last forever is foolish. You have to upgrade at some point, and you will run into problems. New bugs, incompatibilities, workflow changes, whatever the case will make the determinism property moot.
- mike_hearn 7mo agoMany compilers aren't deterministic. That's why the effort to make Linux distros have reproducible builds took so long and so much effort. The reason is, it's often more work to be deterministic than not deterministic, so compilers don't do it. For example, they may compile functions in parallel and append them to the output in the order they complete.
- deleted 7mo ago[deleted]
- abreslav 7mo agoTwo things to mention here: 1. You are right that we can redefine what is code. If code is the central artefact that humans are dealing with to tell machines and other humans how the system works, then CodeSpeak specs will become code, and CodeSpeak will be a compiler. This is why I often refer to CodeSpeak as a next-level programming language. 2. I don't think being deterministic per se is what matters. Being predictable certainly does. Human engineers are not deterministic yet people pay them a lot of money and use their work all the time.
- discreteevent 7mo ago>Human engineers are not deterministic yet people pay them Human carpenters are not deterministic yet they won't use a machine saw that goes off line even 1% of the time. The whole history of tools, including software, is one of trying to make the thing do more precisely what is intended, whether the intent is right or not. Can you imagine some machine tool maker making something faulty and then saying, "Well hey, humans aren't deterministic."
- pjmlp 7mo agoThey do it all the time with their EULAs.
- ferguess_k 7mo agoWhy are we eliminating our own job and maybe hobby so eagerly? Whatever. It is done.