skp1995

Thanks for your interest in Aide!

If I understood that correctly, it would mean supporting Claude via the AWS Bedrock endpoint, we will make that happen.

If the underlying LLM does not change then adding more connectors is pretty easy, I will ping the thread with updates on this.

VSCode forks are not new, there are many companies out there building towards this vision. What sets us apart is partly our philosophy (deeply integrating into the editor) and also the tech stack (running everything to the dot locally) and giving developers control over the LLM usage and also other niceness (like rollbacks which I think are paramount and important)

measuring that part is hard IMHO (without the whole context)

I think in the same vein, the first token generated is also not as important as the final answer, without the full context it generally gives no signal.

To measure the intelligence of a string of text, the context in which it has been generated is far more important.

I do think coming up with better ways to measure intelligence in any part of the answer O(10 tokens), O(20 tokens)... would be useful

isn't difftastic the new way to do this? https://news.ycombinator.com/item?id=39778412

I highly recommend trying it out.

That's what we are doing at Aide (shameless plug since I work on Aide)

I think using the LSP is not just a trivial task of grabbing definitions using the LSP, there is context management and the speed at which inference works. On top of it, we also have to grab similar snippets from the surrounding code (open files) so we generate code which belongs to your codebase.

Lots of interesting challenges but its a really fun space to work on.

https://aide.dev/

cursor is cool ngl, I do find it missing for the use-cases I would want help. Honestly I don't use LLMs a lot daily (copilot is distracting, chat is ¯\(°_o)/¯ I know the codebase pretty well) The kind of help I personally want is not something cursor supports .... so the best way to bring our own vision to life is by taking a step towards building and editor and thats what we are doing

oh I could write a book on this lol, lots of limitations. One of the core reasons being: extensions by design are super limited in the functionality they can provide.

We did have an extension which worked okay while we were still learning the ropes but after 2 months developing it we realized that we didn't have access to many of the APIs which we wanted to tinker with or change the UX dynamically!

This made us look for 2 options: - either move out of the editor and become a cloud blackbox AI engineer (not a big fan, I don't want to spend my time just reviewing code) - or own the editor where people code

We chose the editor route and didn't look back after. Over that time we have changed the UX of the editor completely can better play into the APIs which are hidden in VSCode and really build something which I personally could use daily :)

We are working on https://aide.dev/ an editor forked from VSCode which allows you to utilize LLMs to speed up coding.

Our approach is a bit different since unlike making a better copilot or a chat experience we are building workflows which encourage engineers to work alongside AI and not just offload tasks to AI.

its a bit more than that, you can clearly see that the decoding speed is super fast

yeah that caught my eye too, looks to me like speculative editing (they mentioned that its faster to each its input) + prompt-caching it would literally build up on all the tech they have

yeah for me too, I learnt so much from code reviews and how to do a good code review, it is a super important workflow

Not sure about tedious but code reviews do come to mind. IMHO code reviews are super important but the context switch between coding and reviewing code gets to you at some point.

This is a pretty good implementation. I like the simplicity of it, reminds me of SQLite backed storage decorators we used to have, where the data was persisted to a DB instead of the file system (altho thats just a different storage engine)

Does this also take care of the thundering heard problem? That was one of the cases where lru_cache really blows

StarCoder2 shows good performance on Code Completion benchmarks

This has more to do with the fact that copilot by nature is additive and not editing your code. There was a recent report about how code quality is dropping in codebases because of the repetitive code being introduced by copilot.

The next evolution as you are saying would be to detect if its a repetitive code and modularise it or refactor it.

As someone building in the AI space I can give my unbiased opinion. I do not think AI is the big productivity boost we expect them to be yet. I have been a software engineer for around 6 years now and I the only AI tooling I prefer and have really can not live without today is autocomplete (a better and smarter LSP).

When it comes to making a more complicated change, things are never easy because of the limited context window and the general lack of reasoning and inherent knowledge of the codebase I am working with.

Having said this, GPT4 has been really good for the one off questions I have about either syntax or if I forget how to do "the thing I know is possible I am just not sure" or the mundane things like docker commands or some other commands which I need help with.

But... if you guys have seen Gemini-1.5 Pro I was seriously mind blown and I think the first time I felt a LLM is better than me and that has to do with code search. I have had my fair share of navigating large codebases and spending time understanding implementations (clicking go-to-reference, go-to-definition) and keeping a mental model.. the fact that this LLM can take a minute to understand and answer questions about codebase does feel like a game changer.

I think the right way to think about AI tooling for programming is not to ask them to go and build this insane new feature which will bring lots of money for you, but how they can help you get that edge in your daily workflows (small quality of life changes which compound over time, just like how LSP is taken for granted in the editor now a days).

Another point to mention here which I believe is a major miss is that these copilots write code without paying attention to the various tools we as humans would use when writing code (LSP, linters, compilers etc). They are legit writing code like they would on a simple notepad and that is another reason why the quality is often times pretty bad (but copilot has proved that with a faster feedback loop and the right UX its not too big a hassle)

We are still very early in this game and with many people building in this space and these models improving over time I do think we will look back and laugh how things were done pre-AI vs post-smart-AI models.

I have a love/hate relationship with "hack days". Back when I was an intern I had a lot of fun during hack days. Getting to see a new part of the codebase and getting to interact with new teams is always fun.

When I was working full time, my idea of "hack days" changed quite a bit. I took it as time to work on the weird idea in the back of my mind. My demo's were not impressive by any means but I learnt quite a bit out of it. I also think its part of the team dynamics, some teams embrace hack days while others do not. Think if the tech lead of a team actively encourages hack days the vibes would be completely different say compared to just doing your day job and planned activities.

not really copying the whole files, but I work in an editor which has keyboard shortcuts for adding the relevant context from files and putting that in the prompts.

Straight up giving large files tends to degrade performance (so you need to do some reranking on the snippets before sending them over

I use the default prompt template which is defined in the tokenizer.config https://huggingface.co/deepseek-ai/deepseek-coder-33b-instru...

No special flags or anything, just the standard format. Do take care of the spaces and end of lines. sharing a gist of the function I use for formatting it: https://gist.github.com/theskcd/a3948d4062ed8d3e697121cabd65... (hope this helps!)

not sure why you are getting downvoted, its a very valid question. Its kind of down to the ergonomics of running LLM. Downloading a user friendly CLI tool with good UX beats having to clone a repo and run make files. llama.cpp is the better option if you want to do anything non-trivial when it comes to LLMs

I have found deepseek coder 33B to be better than codellama 70B (personal opinion tho).. I think the best parts of deepseek are around the fact that it understands multi-file context the best.

I have been looking for a tool like scuba, which I used it at my time at Facebook. The amount of data you could slice and dice without breaking a sweat was amazing.

Are there alternatives for this out in the open?

Thats true, maybe one of the reasons I like rust. But logical puzzle solving implies constraints and that's something LLMs can solve (in a constrained environment with the compiler telling you what's right and what's wrong..) I might be over ambitious about this but to me rust code would seem more solvable compared to say python or raw javascript (which have no such compiler based guidance)

This is something I have noticed in practice, copilot and other AI coding tools help you solve your use-case faster because they see the pattern(s?) in your open files and use that. While I was working at Facebook, one of the unsaid rules that was drilled down upon me was to avoid code repetition, copilot does not go the extra length and tells you: "hey, these 2 code blocks are very very similar, why not just create a common function?" its on the developer to take care of these things.

I do love copilot (saves me from writing a lot of boiler plate code) but it not going the extra step, we probably need another abstraction (ha!) on top of the copilot generated code to fix this behaviour with AI generated code, or just stop using copilot and go back to writing code with LSP.

I do think its solvable tho, and we will get there sooner rather than later.

Not a dig at the team, deepseek coder is one of the best coding models out there. What surprised me was the lack of training data for rust 0.08% compared to python which is around 15.12%

Is it just the fact that python and js like languages are more popular in OSS so they get a bigger share in in the datasets being generated for training these models? As a rust developer I would love to contribute towards creating more rust data out there (other than just writing rust code and open sourcing it)..

I have been using axflow in my projects and its a game changer. Really well designed and thought out APIS.

I would love to know a bit more on the future, coming from non ML/AI related background can axflow in the future help me with making my own ML/AI products better? Since all prompts/completions are passing through the APIs that would be neat to have

Hey! I am the cofounder for codestory.ai In terms of differentiation,while buildt and sourcegraph are geared towards making the code search experience the best in class, for us the search is a part of the overall experience which the developer and AI agent needs to do at the same time.

Our idea is to really rethink the editor and make it a place where both humans and AI come together to develop software together, all the tools out there today focus on AI assisting humans, we consider the humans and AI to be on the same level.

Hopefully this answers your question, happy to expand further.

Hey! sorry if it came off that way.

We wanted to share our initial thoughts on what the future of IDE will look like, in hindsight I can see why it feels that way, but the onus is on us to figure out the research and build it.

Would love to hear your thoughts on why its DOA? We are still discovering the right UX, interaction points

lol thats true tho! we built it on a custom template :V