I don't see how this can be so difficult to understand. If the second word in my first sentence were misspelled, does that make every other word or letter that comes after wrong?
Well, that's their prerogative, I guess. But the burden of proof will be on them, of course. They can't expect users to prove a negative. There are simple tells that would reveal a lot of projects. Claude Code's moronic defaults of littering commit messages with both a CC author trailer as well as a session link will reveal some, but those are easy to disable. Then there is stuff like prolific comments, em-dashes in comments, etc.. but none of those are real proof that a project was built with agents.
Either way, I was never interested in codeberg and this just means that I'm less interested.
Sure. And I'm sure that their users will take kindly to being banned with prejudice and without recourse. By adopting this policy they are committing to policing it and acting as judges. And at some point someone will be banned that shouldn't have and it will go on social media and so on and so forth.
They'll also have a fun time drawing the line. What if someone uses agents to generate boilerplate like tests? Are a few files out of hundreds enough for a ban? If not, are they going to force users to write the code manually? How are they going to verify that?
That legalistic "I can do whatever I want as long as it's not breaking the law" argumnet lasts until the first time they ban wrongfully ban someone for it and get huge negative PR
Also famously terrible. If not for the walled garden and the fact that anthropic can take away our ability to use custom harnesses any day, I would not be using CC. Given some of the features they add I've also started to suspect that their models are making product decisions. Not necessarily intentionally, but more in the sense that I think their engineers just let their models build and add whatever it feels like is a good idea to the codebase and then they just publish that.
Everything Steve yegge has done has been trash. That's why nobody is talking about beads or gas town. It was clear even in the beginning that it was a borderline AI-psychosis-fueled trash fire.
I think if you're suggesting that Steve Yegge somehow invented having agents collaborate, you're way off base. People started talking about agents collaborating very, very early on, and people have been doing experiments like this for ages. There have been libraries to build e.g. graph-based (possibly multi-agent) workflows from the early days, before even structured output was a standard thing in the APIs.
The only thing Yegge did was come up with really stupid, convoluted and anthropomorphized language to describe the process and then write unhinged articles about it
It has to be both. You can lay things out in memory so they are tightly packed together and thus ostensibly cache efficient but that doesn't help you if you index into that data structure in such a way that every new index loads a new cache line.
Stop using compaction. Stop treating sessions as something you keep alive for weeks. Set up a proper workflow for handing off work and start handing off well before maximum context is hit. It's less efficient, slower and more costly to constantly be sitting at high context and compaction is just not good.
There isn't, but everything that they said above is absolutely true and people who try to fight it will suffer. There is lots of flexibility within those constraints, but the constraints aren't imaginary.
If you want to use LLMs effectively, everything OP said is true. It has been this way since the beginning. There will be a time when long context and compaction will be effective, but now isn't it.
But push is not for use in production? It's for development. You generate a single custom migration that sets strict, apply it, and then you can use push as you want (during development, not for deploying actual changes to your database)
It's really weird to me how the SQLite author is clearly a very smart guy and talented developer and then his argument against type safety effectively just boils down to
> But I do not recall a single instance where the bugs might have been caught by a rigid type system.
Which is a shame. Of course the author writes more than this, but this is IMO largely the gist of the argument. At this point it's beginning to feel like this is mostly a sort of stubborn sunken cost fallacy, where they've been arguing this for so long they can't take the "hit" of agreeing to change the defaults.
But only just. It doesn't really replace graph databases. It's mostly a slightly more convenient ways to write certain kinds of queries, but it doesn't come with anything else you might expect from a graph database.
reply