The pattern we keep converging on is to treat model calls like a budgeted distributed system, not like a magical API. The expensive failures usually come from retries, fan-out, and verbose context growth rather than from a single bad prompt. Once we started logging token use per task step and putting hard ceilings on planner depth, costs became much more predictable.
Kotlin creator's new language: talk to LLMs in specs, not English
161–170 of 304 posts
Re: Kotlin creator's new language: talk to LLMs in specs, not English
#162[flagged]
Re: Kotlin creator's new language: talk to LLMs in specs, not English
#163Earlier quoted context omitted.
The shoe is what the shoe does. Except one shoe is made by children in a fire-trap sweatshop with no breaks, and the other was made by a well paid adult in good working conditions. The ends don’t justify the means. The process of making impacts the output in ways that are subtle and important, but even holding the output as a fixed thing - the process of making still matters, at least to the people making it.
The end is whether the code meets the functional and non functional requirements. And guess how much shoe companies make who manufacture shoes in sweatshop conditions versus the ones who make artisanal handcrafted shoes?
Functional requirements are known knowns.
Out of bounds behavior is sometimes a known unknown, but in the era of generated code is exclusively unknown unknowns.
Good luck speccing out all the unanticipated side effects and undefined behaviors. Perhaps you can prompt the agent in a loop a bnumber of times but it's hard to believe that the brute-force throw-more-tokens-at-it approach has the same level of return as a more attentive audit by human eyeballs.
Re: Kotlin creator's new language: talk to LLMs in specs, not English
#164[flagged]
Isn't that the point though? In the development loop, you'd diagnose why it's not building what you expect, so you flush out those previous implicit or even subconscious edge cases, undocumented behaviors, and tribal knowledge and codify them into the spec.
It would actually end up being a lot easier to maintain than a bunch of undocumented spaghetti.
Re: Kotlin creator's new language: talk to LLMs in specs, not English
#165[deleted]
Re: Kotlin creator's new language: talk to LLMs in specs, not English
#166This seems like a step backwards. Programming Languages for LLMs need a lot of built in guarantees and restrictions. Code should be dense. I don't really know what to make of this project. This looks like it would make everything way worse.
I've had good success getting LLMs to write complicated stuff in haskell, because at the end of the day I am less worried about a few errant LLM lines of code passing both the type checking and the test suite and causing damage.
It is both amazing and I guess also not surprising that most vibe coding is focused on python and javascript, where my experience has been that the models need so much oversight and handholding that it makes them a simple liability.
The ideal programming language is one where a program is nothing but a set of concise, extremely precise, yet composable specifications that the _compiler_ turns into efficient machine code. I don't think English is that programming language.
Re: Kotlin creator's new language: talk to LLMs in specs, not English
#167This 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 co…
Maybe we're entering the non-deterministic applications too. No more mechanical predictable thing.. more like 90% regular and then weird.
Slightly sarcastic but not sure this couldn't become a thing.
Re: Kotlin creator's new language: talk to LLMs in specs, not English
#168Literally the first example on the main page declared as code.py would result in an indentation error :)
Re: Kotlin creator's new language: talk to LLMs in specs, not English
#169This 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.
[flagged]
Re: Kotlin creator's new language: talk to LLMs in specs, not English
#170When we understand that AI allows the spec to be in English (or any natural language), we might stop attempting to build "structured english" for spec.