390 karma · joined June 4, 2025
Isn't this the point of Pi to implement all the features you need yourself? Complaining about lack of features in Pi doesn't make sense to me, it's their whole identity.
Although I must say that describing specific problems is valuable on its own. It's just (a) why stop there and (b) if stop there, why shape it as a complaint and not as a list of features that are worth discussing.
> As it tends to be heavily trafficked, the overall bandwidth is a key consideration
I guess this is also done to prevent bad actors from abusing the fact that this domain is hit by people who might not know what they're doing (the ones copy-pasting code without reading it)
> No one rewatches a team meeting from 3 years ago to remember constraints around a feature. People write things down and use those records instead.
Memory plugins don't re-read old transcripts. Memory snippets are basically the notes that people write down after the meeting.
The problem, however, is different. The problem with memory plugins is that your agent basically writes a note every time someone says a sentence, and then tries to work with those 5000 notes.
Instead, the agent should recognize what's important and write only that. And that is, of course, a documentation. (And ADRs, if you want not only a description of the final state, but also the trajectory of how the agent arrived to it. Which, arguably, contains more information than the docs themsleves.)
Another difference is that memory snippets are immutable, append-only and don't have a lot of structure. Of course, this is done to be able to store lots and lots of notes: they should be independent. The main problem is that increasing the number of notes adds not enough benefits to compensate for downsides of this structure-less immutable format.
I guess the main advantages of Git history are that it’s (1) uneditable and (2) directly linked to a specific commit.
For an item to become currency in a society, it must already be something people value independently of its use as money, and people must expect others to accept it as well. Say the villagers live near the sea and find some beautiful shiny stones that everyone wants. Those stones can then become currency.
A good example of this is tobacco in colonial America. It came to be used as currency because it was already widely traded and valued.
There, problem solved. This covers all cases I think.
> I hope that Fontra can develop into a fully online collaborative tool, under a sustainable business model. We like to say: “like Figma for fonts”, or “like Google Docs for fonts”.
I stumbled upon this page a few years back and was very confused by the language. It took me some time to parse it and realize that all the comments are actually sarcastic. Overall, the general style feels like I'm reading comments on TikTok.
It's not that I'm against this style; it's just that you don't expect it in a technical article.
Although I agree that it would be cool to have some hello-world example pre-opened.
No, users were used to it because that's how Google works.
However, I can see another counter-argument to my claim: not every consumer has specific requests for the product they're buying! Sometimes people are just not sure what they want. In that case, yes, I can agree that customization doesn't help. Moreover, having a limited set of pre-defined products helps to educate a consumer on what their options even are.
So, if a large part of consumers are the ones that don't know exactly what they want, then yes, you're right. I guess the distribution of “know-what-they-want” vs. “don't” depends on the product, although I think generally it tends to be that most people usually don't know.
Anyway, thanks for the good argument! Thinking about other products and industries, as cars, really helped, I missed that.
I think having to open a web interface is a big entry barrier.
Imagine if those pseudocode files could live in your codebase, and the CLI tool would just “build” the actual code, with sourcemaps. You could edit the code in your favorite editor and run “build” commands in your favorite shell.
(TBH, I haven't looked deeply inside the repo and maybe it's exactly how it works. I just saw that demo and readme tell you to open a http://localhost:5173 as if you can use it only via custom UI.)
I'm not sure how to do syntax highlighting for this pseudocode in any IDE, but you could start with supporting something like Alabaster theme, the whole point of which is to highlight as little as possible.
I say this because I really think that if the setup was simpler lots of people would use it. It's a kind of concept that when you read about it, you think “Wait, how did I not came up with this”. Finally some interesting concept in this endless stream of skills, MCPs, loops etc.
Thanks, I was waiting for this pun the moment turns were introduced in the article.
But how does that contradicts the idea of extendable software? If anything, extendable software will better do what the user wants it to do.
It's just right now we think of extending the software as if it's a complex operation. It looks to me like the article envisions a future, where extending your software is as simple as, say, creating a new google doc or opening a link.
It is doubtable, however, that such level of ease of extendibility can be achieved at all. There might be enough essential complexity, like answering lots of questions, which, I agree, most users won't be doing.
1. What happens if it overflows during assistant's turn, while it makes tool calls? Is it better to make a compaction in the middle of the chain of tool calls, or maybe before a potentially long chain of tool calls? If latter, how to choose the right point for compaction?
2. There should be enough space in the context window for a summary. What if, theoretically, a single new user message already overflows the context window? Or what happens if a summary is too long?
Maybe those are stupid questions, but I'm making a point that there is a room for going in-depth.
Say, what happens when chain of summaries grows so long, that it still overflows context window. Is summarization runned over the summaries in the context window?