This speaks to the general problem with using LLMs for writing. The audience they are writing for us you, but you're trying to write for a totally different audience. In code, this manifests as comments in the code that are hyperspecific to the conversation you are having, and not the long term benefit of having those comments in the code.
I see this in docs a lot. I've been reading a lot of docs these days where it feels like the LLM is trying to hype up the person writing the docs. It's like it has no conception that the writing is meant for a 3rd party audience.
It reminds me of something I've always wanted as a coder but never cared enough to implement, which would be a verbosity switch.
I see the full multi-paragraph comments in my codebases and get annoyed but also feel like the additional context helps improve the llm results over time because that history helps it know what's been tried and removed in the past. It's additional context for the system that improves with context.
The feature I want in the code tool itself (for me) is to adjust how verbose the comments are so I can read "just code", then "terse comments" then "full comments" then "full comments with historical context" (including fit commits and ticket references) and finally, full-on literate programming. And I'd like to switch between on the fly as I read through the code.
I think this is something we could actually produce with llms, and I feel the ability to switch between these modes would help the llm as well.
Sometimes I just need to see what's being done. Sometimes I need to know why. Sometimes I need to know what's been tried. Never always all of these things. And expecting to find this context in git comments doesn't feel right either.
What you want can be accomplished with an extra doc, call it the Log, where the llm appends things tried, lessons learned, failed experiments etc.. while leaving the comments as terse accurate snapshot of the current state. I've been using this log pattern and it works well.
Despite all of this though, GPT 5.6 Sol to me has significantly less trouble with this. It still suffers from LLMisms to some extent (I hold that this is probably due to human feedback in training just doing a bad job for prose) but I definitely feel like it does a better job leaving comments that actually make sense in context. Not perfect. But better.
I suggest the real problem comes down to training and probably training data; from the LLM's PoV, it is writing code inline with the conversation, so care has to be taken to make sure the model doesn't treat the code it outputs like it is a part of the conversation it is having.
It's an empty point and a boring one and leads nowhere. It means nothing, but sounds deep. It's so shallow, any taxi driver and sociologist can come up with it and has, already in December 2022.
I don’t even think comments are useful at all given AI. I can ask my AI to explain a piece of code if I am stuck and I will get a reply in context of what I am looking for.
Agree about Graal being really good. there are some different use cases for embedding wasm in an application. chicory / endive is not just for embedding another language. the main use case was always secure plugin-systems. but there are other use cases. also it's not controlled by Oracle and works well outside of their ecosystem, which i think some people value. this question came up a few times and were addressed in talks and blog articles:
the "redline" compiler is cranelift which is written in rust, but i think it's being compiled to Wasm first then JVM bytecode so it still works zero dependency. not sure if that will continue to be the case.
if i understand correctly, the new redline compiler doesn't have these limitations. it's not based on asm. (edit: but this hasn't been merged to mainline yet)
Just wanted to chime in to say this is really cool. I dreamed of building something like this for the Extism ecosystem but it was a huge lift to unlock all the pieces. This looks like lots of innovation all the way down the stack. Kudos!
Thanks Ben! Took us a bit to figure out the best architecture for it, but once it became clear then it was just a matter of implementing the missing bits.
I think the fact that WASIX is much more mature now have helped to increase development speeds quite a bit!
Speaking of community, there is a really nice little tech community going strong in New Orleans that I think reflects the culture talked about here. If you are ever in town you should stop by an event https://www.noladevs.org/.
Feel free to reach out to me if you want some intros.
Hack night is the generic networking meetup at the rusty nail. It's way more casual. No presentations or organizing. below-c-level and frontend party are generally more organized and have talks. All the meetups happen before (and geographically near) to hack night on the same night. So you can generally do both. See a meetup then walk to the bar with everyone for the networking event.
This is the first i've heard of people using the SSE transport locally. What purpose what that serve? Is this by design because the chrome extension could not talk to it otherwise?
BTW, you should really run your MCP servers in a sandboxed environment, esp if they don't need to do things like `exec` or read from the filesystem. We do this with the https://mcp.run ecosystem by wrapping them in wasm. Because they are wasm you could also run them right in the chrome extension!
I see this in docs a lot. I've been reading a lot of docs these days where it feels like the LLM is trying to hype up the person writing the docs. It's like it has no conception that the writing is meant for a 3rd party audience.