But even if it’s not — I can’t build a scenario in my head where recalculating it on real GPUs is cheaper/faster than retrieving it from some kind of slower cache tier

Why not use tired cache?

Obviously storage is waaay cheaper than recalculation of embeddings all the way from the very beginning of the session.

No matter how to put this explanation — it still sounds strange. Hell — you can even store the cache on the client if you must.

Please, tell me I’m not understanding what is going on..

otherwise you really need to hire someone to look at this!)

I agree that this is still the most important thing, and I don’t try to challenge this.

At the same time we have quite adopted bumping our dependencies when it does not incorporate breaking changes (especially if there are know security vulnerabilities) — and my point is exactly about it, why even simple renames, extraction or flattening or other simple changes have to be treated so differently than internal changes that do not touch public interface?

This is not only true for the open-source, widely used software, but also for internal software. The existence of companies with big mono repositories to support dynamic rhythm of changes that do not break in unknown parts is a good illustration of how important to have the ability to refactor without the fear.

Even in the pre-LLM era we had a technical ability to do some changes without the fear which we didn't really adopt. For over 20 years we already had tools that implement a number of deterministic refactorings for typed languages. If our change consisted of only a sequence of such deterministic changes – we could automatically generate codebase migration scripts together with the new versions of our libraries. And maybe we could even search for all the usages of our libraries on the GitHub and programmatically produce PRs with all the needed changes.

Today, with all the progress in LLMs it's not hard to imagine that instead (or together with) automated migration scripts we can distribute some automatically generated migration prompts. And for all the opensoruce code, we can actually validate the results of our migrations (by pulling all the code dependent on our library, applying migration prompts, building and running tests) – and everything that is validatable, usually reach very confident levels with LLMs.

It's not hard to imagine even better LLMs in future with the ability to do even more complex refactorings. And this might remove a lot of fear associated with the changes, which in turn will significantly improve the speed of innovation for old projects where a lot of historical decisions are cemented in the public interface.

This is the future of software engineering I would want to see, and I'm curious to hear what are your thoughts about this?

P.S. Migrating from one computer language to another should become a matter of "prompted change" at some point too!

Comments URL: https://news.ycombinator.com/item?id=46344728

Points: 1

# Comments: 4

`‹tr : for="user of users">`

sorry to disappoint, but human brain fits the same definition

Tech superiority might be relevant today, but I highly doubt it will stay the same for a long time even if openai continues to hide details (which I agree is bad). We could argue about the training data, but we have so much publicity available so that is not an issue as well.

Performance is never a complete product – neither for Apple, nor for Open AI (its for-profit part).