jeremychone

I looked at your solution and extension README, and it's very interesting and well thought out.

The fact that you've been using it for six months and that it performs well says a lot. At the end of the day, that's what counts.

I like your idea of piggybacking on top of the LSP services, and I can imagine that this was quite a bit of work. Doing it as an MCP server makes it usable across different tools.

I also really like the name "Context Master."

In my case, it's much more niche since it's for the tool I built. Though it's open source, the key difference is that the "indexing" is only agentic at this point.

I can see value in mixing the two. LSP integration scares me because of the amount of work involved, and tree-sitter seems like a good path.

In that case, in the code map, for each item, there could be both the LLM response info and some deterministic info, for example, from tree-sitter.

That being said, the current approach works so well that I think I am going to keep using and fine-tuning it for a while, and bring in deterministic context only when or if I need it.

Anyway, what you built looks great. If it works, that's great.

Yes, there is a parallel here. Now, some of those "indexing" steps can be performed by an LLM.

And that does not prevent mixing and matching the two, as some comments in this thread suggest.

Anyway, it's a great time for production coding.

Very good point. I had two options:

1) Deterministic

  - Using a tree-sitter/AST-like approach, I could extract types, functions, and perhaps comments, and put them into an index map.

  - Cons:

    - The tricky part of this approach is that what I extract can be pretty large per file, for example, comments.

    - Then, I would probably need an agentic synthesis step for those comments anyway.

2) Agentic

  - Since Flash is dirt cheap, I wanted to experiment and skip #1, and go directly to #2.

  - Because my tool is built for concurrency, when set to 32, it's super fast.

  - The price is relatively low, perhaps $1 or $2 for 50k LOC, and 60 to 90 seconds, about 30 to 45 minutes of AI work.

  - What I get back is relatively consistent by file, size-wise, and it's just one trip per file.

So, this is why I started with #2.

And then, the results in real coding scenarios have been astonishing.

Way above what I expected.

The way those indexes get combined with the user prompt gets the right files 95% of the time, and with surprisingly high quality.

So, I might add deterministic aspects to it, but since I think I will need the agentic step anyway, I have deprioritized it.

point taken.

- The ..-code-map.json files are per "developer folder," which would create too many conflicts if they were kept in Git.

- I have two main globs, which are lists of globs: knowledge_globs and context_globs. Knowledge can be absolute and should be relatively static. context_globs have to be relative to the workspace, since they are the working files.

- As a dev, you provide them in the top YAML section of the coder-prompt.md.

- The auto-context sub-agent calls the code-map sub-agent. Sub-agents can add to or narrow the given globs, and that is the goal of the auto-context agent.

It looks complicated, but it actually works like a charm.

Hopefully, I answered some of your questions.

I need to make a video about it.

But regardless, I really think it's not about the tools, it's about the techniques. This is where the true value is.

Even there, I use AI to augment rows and build the code to put data into Json or Polars and create a quick UI to query the data.

Oh, that's great.

I've always wanted to explore how to fit tree-sitter into this workflow. It's great to know that this works well too.

Thanks for sharing the code.

(Here is the AIPack runtime I built, MIT: https://github.com/aipack-ai/aipack), and here is the code for pro@coder (https://github.com/aipack-ai/packs-pro/tree/main/pro/coder) (AIPack is in Rust, and AI Packs are in md / lua)

So, I have a pro@coder/.cache/code-map/context-code-map.json.

I also have a `.tmpl-code-map.jsonl` in the same folder so all of my tasks can add to it, and then it gets merged into context-code-map.json.

I keep mtime, but I also compute a blake3 hash, so if mtime does not match, but it is just a "git restore," I do not redo the code map for that file. So it is very incremental.

Then the trick is, when sending the code map to AI, I serialize it in a nice, simple markdown format.

- path/to/file.rs - summary: ... - when to use: ... - public types: .., .., .. - public functions: .., .., ..

- ...

So the AI does not have to interpret JSON, just clean, structured markdown.

Funny, I worked on this addition to my tool for a week, planning everything, but even today, I am surprised by how well it works.

I have zero sed/grep in my workflow. Just this.

My prompt is pro@coder/coder-prompt.md, the first part is YAML for the globs, and the second part is my prompt.

There is a TUI, but all input and output are files, and the TUI is just there to run it and see the status.

Fair point, but because I spent a year building and refining my custom tool, this is now the reality for all of my AI requests.

I prompt, press run, and then I get this flow: dev setup (dev-chat or plan) code-map (incremental 0s 2m for initial) auto-context (~20s to 40s) final AI query (~30s to 2m)

For example, just now, in my Rust code (about 60k LOC), I wanted to change the data model and brainstorm with the AI to find the right design, and here is the auto-context it gave me:

- Reducing 381 context files ( 1.62 MB)

- Now 5 context files ( 27.90 KB)

- Reducing 11 knowledge files ( 30.16 KB)

- Now 3 knowledge files ( 5.62 KB)

The knowledge files are my "rust10x" best practices, and the context files are the source files.

(edited to fix formatting)

Interesting, I’ve never needed 1M, or even 250k+ context. I’m usually under 100k per request.

About 80% of my code is AI-generated, with a controlled workflow using dev-chat.md and spec.md. I use Flash for code maps and auto-context, and GPT-4.5 or Opus for coding, all via API with a custom tool.

Gemini Pro and Flash have had 1M context for a long time, but even though I use Flash 3 a lot, and it’s awesome, I’ve never needed more than 200k.

For production coding, I use

- a code map strategy on a big repo. Per file: summary, when_to_use, public_types, public_functions. This is done per file and saved until the file changes. With a concurrency of 32, I can usually code-map a huge repo in minutes. (Typically Flash, cheap, fast, and with very good results)

- Then, auto context, but based on code lensing. Meaning auto context takes some globs that narrow the visibility of what the AI can see, and it uses the code map intersection to ask the AI for the proper files to put in context. (Typically Flash, cheap, relatively fast, and very good)

- Then, use a bigger model, GPT 5.4 or Opus 4.6, to do the work. At this point, context is typically between 30k and 80k max.

What I’ve found is that this process is surprisingly effective at getting a high-quality response in one shot. It keeps everything focused on what’s needed for the job.

Higher precision on the input typically leads to higher precision on the output. That’s still true with AI.

For context, 75% of my code is Rust, and the other 25% is TS/CSS for web UI.

Anyway, it’s always interesting to learn about different approaches. I’d love to understand the use case where 1M context is really useful.

Very interesting approach.

The trick is that sometimes developers use a hybrid approach, AI + Human / IDE, and in this case, we use the language formatter (for example, rustfmt).

For example: For my AI Agent / CLI, the dev can add a sub-agent (non-AI) that just runs cargo fmt, and I can definitely see the value in including this as part of the default flow. But my issue is that it won't really follow rustfmt.

Am I missing something?

Anyway, this is great. And btw, I have been thinking about using tree-sitter for "context extraction / optimization" for code indexing, but I did not have time to explore this further.

Impressive.

By the way, I’ve been switching to RustFS as my S3 mock server, and it works like a charm.

They maintain the Docker image, so it works great in a k8s environment, for both local and remote development.

Big thanks to MinIO for providing this option for so many years. I genuinely wish them the best.

Not sure "convenience" alone should be the deciding factor when choosing a language for a project/product.

What matters more is the long-term value for what’s being built and maintained.

For portable, high-performance backends, Rust often offers a higher value/friction tradeoff, IMO.

For Apple platform development, Swift is the obvious choice.

Swift’s cross-platform story has improved, but outside the Apple ecosystem the incentives still seem weaker compared to Rust.

So overall, IMO, Rust tends to have a higher net value beyond Apple-specific use cases.

This is so awesome. Well done! I played a little with Pico/RP2040 (as a hobby), and it is so much fun. I wish educational content and institutions would embrace it more quickly.

Reached 8K+!

This is so counterproductive. I hope the Rust Foundation and the Rust Project change their minds and take a more reasonable route.

Protecting against misrepresentation is completely understandable, but forbidding any common and reasonable use just because of it is so counterproductive.

There is a learning tax at the beginning, for sure, but this is a fixed cost. We experience that once this first hump is passed, the code and output quality is higher, and the cloud resource cost decreases significantly.

Now the challenge is to hire new developers that are not familiar with Rust; it would take a month or so for them to be productive (assuming robust internal code practice). But, well worthwhile in our opinion, as least for greenfield application/services.

(We are coming from Java / nodejs/TS)

We have been building relatively big enterprise cloud applications with a high level of compliance over the last decade and a half, and our next blueprint is all Rust on the backend (web server, web services, and job/micro services). For our approach, Rust is a transformative language for those parts of our systems.

Agree, for our approach, sqlx has the right level of abstraction. Not too high, not too low, and close enough of a sql builder pattern to be very useful. (We are not using the compile time type validation though).

As usual, great article from Discord team.

Rust in the Cloud will make more and more sense as companies focus on optimizing operational costs without compromising scalability and quality.

I have rewritten a relatively small but critical 2k CLI from nodejs/ts to Rust, and this was the best decision ever. Cold start and runtime performance got a big boost, but also the code design got much better, and the code is much simpler to maintain and evolve. The single binary install was also a big boost, which I assume is similar to Go.

Since then, we have written all our CLI in Rust, regardless of size.

Tip: for small personal CLI, "cargo watch -x 'install --path .'" can make the whole dev experience script-like.

Seems we will need to wait a little more for the if-let-chain.

Assuming you want a zero-vm runtime, life will be much simpler with a borrow checker than without.

The learning curve is a fixed tax for a recurrent return.

Pola.rs is another good example of how a great Rust library can have an excellent Python façade. Polars ingenuously uses Python's operator overloading scheme to maximize data frames operation efficiencies.

I think Python & Rust can become great pairs, especially in the data processing field.

Agree. The problem is that languages like Java, C#, ... are making it so easy not to worry about memory that we (at least I) tend to forget the basics after a decade or so. And the basics have mostly stayed the same.

Nice one. Never knew about this story. I was still at the Mozilla CSS story.

Railway is very promising. It makes total sense to write those CLI in Rust. We have rewritten our CLI to Rust, and the runtime reliability, performance, and developer productivity paid off.

This is a very informative article with some excellent points. Indeed, having worked a little in the UI toolkit realm, I agree that a different UI Component model is warranted for an efficient Rust UI toolkit.

Perhaps some of Bevy "ECS" model, where UI node becomes barebone UI entities, and everything is composed by type.

Anyway, not an easy one to crack, but I hope that one day we will get an awesome cross-device native UI a toolkit in pure Rust.

After a couple of years of coding Rust, I found the error system, including the ?, well thought out. It is explicit and clear that the error is or maps to the function return error.

The only thing is that Rust rightfully uses the ? to return early system on option as well, which removed the ability to have None coalescing with "?". This was the right choice from a language point of view, but I wish there would be a None coalescing syntax in Rust.