Lukas Juhrich (Apr 13 2026 at 19:46): Lukas Juhrich (Apr 13 2026 at 19:46):Hey folks,
tl;dr renaming and this:
2026-04-13-roc-insert-inferred-annotation.mp4
To test out the capabilities of my newly acquired cursor license, I told it to add some low-hanging LSP fruits and fix some bugs. specifically,
Is there any coordination going on / people already working on other LSP features / plans this might collide with?
I'm not sure I'm 100% comfortable with opening a PR with changes I could not have written myself, so what's the expected trust level of changes one should have before submitting that?
I will push my branch some time later, would need to fork etc. first.
Luke Boswell (Apr 13 2026 at 22:41):I think @Eli Dowling was poking at the LSP most recently... but I haven't seen anything in a while.
Eli Dowling (Apr 13 2026 at 22:47):I can do some code review :) Just mention me. I haven't made any changes since I got completion working.
Luke Boswell (Apr 13 2026 at 22:49):I don't think we should accept a "vibe" coded PR ... however I don't think this is what you are proposing here. I think you should review your work (LLM assistance or not) and take responsibility for it.
I would encourage you to think about your approach to testing and how you validate things -- for my previous contributions for the LSP I was doing QA manually. I'm not sure if there is a better approach.
Eli Dowling (Apr 13 2026 at 22:59):I'll be honest 90% of my lsp changes were basically vibe coded. I mean I had a handle on how I wanted things to look, but a lot of completion stuff is just boring ast traversal and collation, and I didn't really want to understand the full scope of the new set, I wanted completion to work. So long as the code isn't crap and full of duplication and the overall code paths make sense (I did a few vibe based refactoring passes), and there are tests. Ehhh I wouldn't worry too much. Roc will almost definitely end up with a roc based language server at some point. So it's not like this code is here forever anyway.
If you disagree with that general sentiment please feel free to completely override me here @Luke Boswell. :sweat_smile:
Luke Boswell (Apr 13 2026 at 23:08):I think opening a PR and being honest about "hey I spiked out this cool feature... but I'm not sure about it, would anyone like to help guide me... I'm keen to learn and happy to put the work in to fix things" is definitely encouraged... it's a great way to sharpen our skills as engineers.
One of the things I really appreciate about OSS is the community collaboration, and that takes someone putting their hand up to do things, or make a start on things. I think it's much harder to start something from scratch.. but doing that work makes it easier for others to come along later and polish it.
In your case @Eli Dowling you have a lot of experience in this area, and are confident with reviewing LLM code and making trade-offs like "this if good enough for now". You know what crappy code looks like. From memory I think you took the mess I made on that first pass for the LSP and cleaned that up a lot... :sweat_smile:
Roc will almost definitely end up with a roc based language server at some point. So it's not like this code is here forever anyway.
I don't disagree, though it's hard to say how long that may take. The experimental LSP might be around for quite a while and there may be a lot of people relying on it in the short/medium term.
Eli Dowling (Apr 13 2026 at 23:14):Yeah, I guess all I'm trying to get across is it's not exactly a shimmering tower of perfection as it is.
So, if you need a hand, just ask, and if your change isn't going to make the codebase harder to maintain in the future, and the feature works, it's probably a good addition. Don't get too hung up on perfection.
Better people have the feature now and maybe it gets rewritten in 6 months, than wait 6 months for the perfect implementation.
Luke Boswell (Apr 13 2026 at 23:18):I would add that Roc is in an earlier developmental stage right now, so there is a pretty short half-life on most code... a lot is getting replaced frequently.
Luke Boswell (Apr 13 2026 at 23:20):If we were talking about something like making big changes to the tokenizer or parser which have been pretty stable for a while, then it would be a different set of trade offs.
Steve Howell (Apr 14 2026 at 03:16):I've had some success with training Claude on the different levels of expectation for code quality. The concept I mostly use with Claude is "knobs". I will turn the disposable knob up to 10 if I just want some quick-and-dirty code so that I can start exploring the feature. I turn the quality knob up to 10 if I am willing to sacrifice some turnaround speed. I also work with Claude on leaving annotations into the code for future cleanup. We have a contract that Claude owns the code or Steve owns the code or some hypothetical future maintainer owns the code, and that drives how the agent works.
Luke Boswell (Apr 14 2026 at 03:18):Interesting ideas, I'll need to try that out.
Luke Boswell (Apr 14 2026 at 03:26):I like to start at the end, with a working thing but implemented in a hacky or simulated way... and then iterate on that until I'm happy with the idea... and work backwards to understand what the proper implementation should look like.
This isn't just a code thing... like if I'm scaffolding out a report or email I like to build a strawman and then firm up the detail.
Luke Boswell (Apr 14 2026 at 03:27):I like the idea of having the LLM annotate new or modified functions. I could imagine something like "TODO - this function is a rough draft, please review in future"
Steve Howell (Apr 14 2026 at 03:44):I framed one of my conversations with Claude as follows (paraphrasing from memory): If I totally removed the constraint that humans needed to read your code, and we just needed you to iterate quickly, then what would you do?
I'm not gonna spoil the answer. Ask Claude a similar question and see what he says.
My biggest epiphany from working with Claude is that I have to re-evaluate all the things that I thought were expensive in the old paradigm of not having an agent. Some things are clearly more disposable and inexpensive. Some things are just intrinsically difficult. Watch Claude do a refactoring some time--his process is quite human. He gets the core logic fixed and then has to go back and let the compiler find the missing imports.
Last updated: May 01 2026 at 12:45 UTC