I mean good for the team, I'm sure they will make out quite nicely.
But it was really great to see high quality OSS being extracted from their enterprise-focused https://code.storage/ service. Not I imagine the oss updates and new libs will decline, maybe not right away, but eventually, especially as they get rolled into whatever the product-offering of the week is that altman cooks up.
This is the second significant exploit against LiteLLM in what, a year or two ? Just last night I came across notes and a script from an older claude session to help audit all project dependencies and verify nothing used litellm.
And buried under the lede is that one of the compromised people was one of the organization owners. So it seems like the culture of insecurity comes from the top, which is unfortunate especially bc they keep acting like "this could've happened to anyone guys"
there's another one this summer that didn't get as much attention (or any at all) which allowed exfiltrating master provider keys with any authenticated user/virtual key
If we lived in a world where people or agents could define those service boundaries up front, correctly, with some reasonable foresight for change on the horizon ...then sure...I'd agree.
However, our world is not that world. Your agents may be happy in their tiny walled kingdom of toil and ineffectiveness, but you and your users will not. Poorly drawn service boundaries will drag you down more than almost any other architectural mistake.
If there is one universal amongst organizations, its that they love walls and silos. Be wary of putting them up ahead of time, cuz tearing them down once established is nearly impossible.
> If there is one universal amongst organizations, its that they love walls and silos.
What's true for human organizations isn't necessarily true for agent-driven engineering. People and human teams struggle with contracts because there's always human negotiation involved. If the decisions are instead made by a team of agents, there's no more ego, ownership, miscommunications; just decisions based on whatever rules have been given to the orchestrator.
> Your agents may be happy in their tiny walled kingdom...
Yes indeed; the agents will always be happier if they can iterate faster, lint faster, build faster, test faster, ship faster, with smaller context.
That would be the point of using contracts as boundaries so the agent can iterate more autonomously so long as it maintains the externally facing contract or version the contract if it needs to.
It’s a fairly simple encoding which is UTF-8 compatible and allows codepoints to be arbitrarily large. It’s a real encoding proposal with a simple rigorous specification. I don’t have a use case for needing arbitrarily large codepoints, but for people who do, this makes more sense than hacks such as having surrogates in Unicode’s hi-bit private use area.
"seam" dates back to refactoring & software engineering literature that pre-date LLM use by 20 years -- see Working Effectively With Legacy Code for one example (https://www.oreilly.com/library/view/working-effectively-wit...). Its a great book, still use techniques from it everyday.
"load-bearing" I have never heard used for programming before Opus, and its incredibly annoying and over-used.
Seam is used liberally throughout because it captures the idea well (i.e. a place where you can cleave ball of mud code apart to begin refactoring efforts in an isolated way) and that takes many different forms throughout the book whether that be via methods and classes, source files as a single unit, linker seams, on and on.
AFAIK there is nothing like this out there, because there is not one standard for a "pull reauest" in the sense of how a web based forge does it. and it gets complicated quickly due to complexity of git and forks.
Weird that searching for it didn't yield any results, though I stand corrected.
However it seems that select is the actual "root" of documentation. Filter sends to find_all, find_all sends to filter or select.
This post sets up a straw man from the outset, and only gets worse from there.
I understand how we got here, where many experienced programmers, managers, and bloggers only know capital-A Agile as the watered down version sold via certifications, crummy medium posts, and atlassian flavored kanban boards. But that isn't agile.
I can’t even with the pitch into spec driven development as some sort of high watermark of software methodology.
I mean good for the team, I'm sure they will make out quite nicely.
But it was really great to see high quality OSS being extracted from their enterprise-focused https://code.storage/ service. Not I imagine the oss updates and new libs will decline, maybe not right away, but eventually, especially as they get rolled into whatever the product-offering of the week is that altman cooks up.
Oh well. so it goes
reply