beyang's comments

If you like Claude Code but either (1) prefer an agent that doesn't ask for review on each file edit or (2) miss the IDE for things like reviewing diffs, I'd humbly submit you try out Amp: https://ampcode.com. It has both a CLI and VS Code extension, and we built it from the ground up for agentic coding, so no asking for permission on each edit, a first-class editor extension (personally I spend more and more time reviewing diffs and VS Code's diff view is great), and it employs subagents for codebase search and extended thinking (using a combo of Sonnet and o3) to maximize use of the context window.

Check out Cody for GoLand and JetBrains: https://plugins.jetbrains.com/plugin/9682-cody-ai-coding-ass...

For those looking for a free coding assistant they can also use at work / in the enterprise, Cody has had a free tier for awhile: https://sourcegraph.com/cody

- Works with local models

- Context-aware chat with very nice ergonomics (we see consistently more chats per day than other coding assistants)

- Used by both indie devs and devs at very large enterprises like Palo Alto Networks

- Hooks nicely into code search, which is important for building a strong mental model inside large, messy codebases

- Open source core

FYI, you can do that with Cody + Ollama. A good portion of our user community does exactly that: https://sourcegraph.com/blog/local-code-completion-with-olla...

Hi there, Cody contributor here—sorry to hear you had a bad experience! In our evals, our DeepSeek variant outperformed previous models and other alternatives. If it's working worse for you know, would be open to sending us some examples/screenshots of poor completions examples? We'd like to incorporate these into our eval set so we can capture a more representative distribution of codebases and how Cody performs!

This is in the cards and thank you for the feedback! (Sourcegraph CTO here)

Author of the post here—as another commenter mentioned, this is indeed a bit dated now, someone should probably write an updated post!

There's been a ton of evolution in dev tools in the past 3 years with some old workhorses retiring (RIP Phabricator) and new ones (like Graphite, which is awesome) emerging... and of course AI-AI-AI. LLMs have created some great new tools for the developer inner loop—that's probably the most glaring omission here. If I were to include that category today, it would mention tools like ChatGPT, GH Copilot, Cursor, and our own Sourcegraph Cody (https://cody.dev). I'm told that Google has internal AI dev tools now that generate more code than humans.

Excited to see what changes the next 3 years bring—the pace of innovation is only accelerating!

If folks want to continue searching open source, https://sourcegraph.com/search does not require sign in and also includes major projects that are not on GitHub.

(Full disclosure: I'm the Sourcegraph CTO)

Zoekt was heavily inspired by Google's internal code search, as mentioned in the blog post. The original version of the internal code search is described in the rsc post. Zoekt keeps some of the foundational ideas (e.g., trigram index), but was a from-scratch implementation. We probably should link to the rsc post for completeness, will update.

Great call out! We've built this code navigation infra on top of Zoekt into Sourcegraph. Example: https://sourcegraph.com/github.com/golang/go/-/blob/src/net/...

Docs: https://docs.sourcegraph.com/code_navigation/explanations/pr...

This was a great listen that really resonated with the approach we've taken in building our code AI tool (Sourcegraph's Cody: https://cody.dev). We found that the biggest levers we had to drive improvement in the accuracy of Q&A and code generation quality was fetching relevant snippets of code and docs into the context window. So we pivoted from investigating more expensive, long-iteration-cycle updates at the model training level and invested more into code-specific information retrieval mechanisms (it helps that we spent the past 10 years building a code search and code intelligence engine). We've found RAG to be cheap, fast, and directly impactful compared to model-layer improvements (but as Jerry points out, still a very hard engineering problem).

Anyway, Jerry and LlamaIndex has been a huge source of learning and inspiration—please keep tweeting and publishing, Jerry!

Hello, Sourcegrapher here! We are making some simplifications to eliminate the need for the separate local app install. Should be out in the next month or so. Until then, apologies for the added friction here, we're working hard to smooth it out.

Hi there, Sourcegraph CTO here. Code search remains free for individual devs, and I hope you'll continue using us for your projects! https://about.sourcegraph.com/code-search/pricing

We have lots to reflect on given the feedback here on HN. We were honestly a bit blindsided by the number of people who appear to be using open source Sourcegraph, or who really wanted to use it but found the process too difficult. Part of this is because we had a zero telemetry policy for the open source distribution. Perhaps that was a mistake in hindsight, but introducing telemetry there would've been another can of worms!

Now that the usage is more visible, it's actually kicked off a lively internal discussion. We're going to take some time to gauge the size of the user community and figure how we can best support it. Aside from individual use being free (still the case) and making deployment more straightforward (through something like code search in App), are there other things we can do to make it easier to adopt? Sorry about the confusion here, we should have handled this better. But the silver lining is we realized there were a lot of users of Sourcegraph that we didn't know about and we're now discussing how best to engage and support you all. I do hope you'll take the chance to pop into our Discord and say hello and continue with feedback that can help us make the best decisions for our users.

Hey, I'm the Sourcegraph CTO. Appreciate the critical feedback here. I suspect that Cody is using "keyword context", which is our fallback when we don't have an index on Sourcegraph that Cody can use (we need to do a better job of conveying when this happens to users). Would you mind sending me a screenshot of Cody not doing a good job of answering a question / fetching the wrong context? You can email me at [email protected] or DM me on Twitter (https://twitter.com/beyang).

Hopefully it's not just on paper :) There are a lot of rough edges still, but we hope to iron them out as quickly as we can.

One of our core design principles for Cody is to make it "unmagic". Like, the AI is magic enough, but the rest of what we're doing in terms of orchestrating the LLMs in combination with various other data sources and backends should be clear and transparent to the user. This allows for greater understandability and steerability (e.g., if Cody infers the wrong context, maybe you can just tell it the file it should be reading and then regenerate the answer).

Copilot is a great tool, and Oege de Moor, Alex Graveley, and the whole GitHub Next team deserve huge credit for shipping it. That being said, I really want the standard AI coding assistant to be open, and there's been a ton of innovation in LLMs since Copilot's initial launch that doesn't seem to have been rolled in yet. I think this is a case where being open means we can accelerate the pace of innovation.

I'll add if folks want to submit a PR to turn on other LLMs (or have Cody talk to the base LLM provider directly, sans Sourcegraph), we're happy to accept those. Literally the only thing preventing us from doing that right now is prioritization (our team is 4 people and we're scrambling to improve context fetching and implement autocomplete rn :sweat-laugh-emoji:)

Cody is being open sourced under Apache 2. The source code is here: https://sourcegraph.com/github.com/sourcegraph/sourcegraph/-.... The analog would be if GitHub open-sourced Copilot but didn't open source GitHub (Sourcegraph is open core, similar to GitLab, with all the code publicly available and the enterprise-licensed code under "enterprise" directories).

The network dependencies are Cody --> Sourcegraph --> Anthropic. Cody does need to talk to a chat-based LLM to generate responses. (It hits other APIs specific to Sourcegraph that are optional.)

We are working on making the chat-based LLM swappable. Anthropic has been a great partner so far and they are stellar to work with. But our customers have asked for the ability to use GPT-4 as well as the ability to self-host, which means we are exploring open source models. Actively working on that at the moment.

Sorry for any lack of clarity here. We would like to have Cody (the 100% open source editor plugin) talk to a whole bunch of dev tools (OSS and proprietary). We think it's totally fine to have proprietary tools in your stack, but would prefer to live in a world where the thing that integrates all that info in your editor using the magic of AI and LLMs to be open source. This fits into our broader principle of selling to companies/teams, and making tools free and open for individual devs.

Cody is free to use and doesn't strictly require Sourcegraph. It can make use of Sourcegraph APIs (e.g., code search, soon find refs) to improve its context fetching. We hope to integrate other dev tool APIs (e.g., monitoring, tracing, etc.) as well.

Sourcegraph is also free to use and downloadable as a local app (https://docs.sourcegraph.com/app) or you can use sourcegraph.com for open source. Our intention is to sell to teams/companies, while making tools for individual devs free to use. There have been a few cases in the past where we've misstepped and come across as selling to individual devs. If this ever happens, please flag to me (https://twitter.com/beyang) or sqs (https://twitter.com/sqs) directly and we'll correct it.

The best way to accelerate this is to bug https://twitter.com/teej_dv on Twitter. Tell him Beyang sent you and that he thinks he can have an Emacs plugin out faster :P

We don't have autocomplete yet, which is what Copilot is mainly used for. But we're working on it, with the same context-aware mechanisms that provide a quality lift on the Q&A side.