A significant part of the cost is that newer framework APIs are not known to the current agents. So they need to discover them and learn them on the fly. Eventually future models will have them trained into their weights and efficiency should increase. In the grand scheme of things, the cost might be negligible if it makes up for it in performance or quality.
I found that it's not just text. It's also design and overall user experience. If you have an eye for it, your brain picks up on it immediately with the little pills, busy landing pages, the use of serifs everywhere, bronze accents, and lots of dark mode.
What's buried under the lede: this harness is using Cordis v4 (the paper that dropped today). Cordis has already been used for four years in a different project called Koishi that uses v3. Cordis itself is a way of hot loading and unloading plugins without restarting a running process. The cool part is that when it unloads it can revert any state and side effects it created, cleaning up its connections, memory allocations, registered handlers, etc. and it can also deactivate any dependencies it relied on without disturbing other plugins.
As far as I can find, Cordis didn't exist before they shared it with this harness. It is very likely that its because I didn't search in Chinese (as I don't know it). Can you explain the evolution of it from the different versions?
Anythign that needs to be cleaned up or undone goes in ctx.effect. It returns the "inverse" (the cleanup function) when the plugin loads. Cordis then stores it and runs it when the plugin unloads. Take a look at 5.1.1 in the paper.
The number is eye-catching but it's measuring how non-conforming the source code is, as opposed to whether it results in the intended DOM. This is why HTML validators largely went out fashion since it's more practical to consider source "valid" if it renders correctly in the browser. The way the browser handles non-conforming source code is part of the spec [1].
I don't know if it's a coincidence but this is the same thing an AI explained to me when prompted something like "what replaces SaaS now that AI can build most things on demand". That was like a year ago. I have no proof for this, but we might all just be getting similar responses from similar contextual bubbles and landing on the same conclusions.
to be fair, #2 exists because monorepos and submodules are somewhat antithetical concepts. A monorepo is supposed tobe the single source of truth for the codebase, while submodules are pointers to external repos with their own history. That alone will increase the source of churn for teams that are constantly merging.
> All my finance and payment domain expertise, all the debugging intuition and distributed system knowledge earned through hours of sweat and tears, is now promptable.
I think the author downplays how much of that knowledge is used on knowing what to zoom in on, what to prompt, or what to look for.
It's telling how rhetoric and conjecture are now normalized in company and business culture. When we were at the peak of remote work, companies were reporting record high revenues.
Yeah. Capitalism has never been less about actual profits and efficiency than it is right now. They just tout whatever random thing they're currently doing, regardless of why they're doing it or whether it was voluntary or not, is great and producing amazing results.
The issue was a compromised build pipeline that shipped a poisoned package.
But PSA: If something is critical to the business and you’re using npm, pin your dependencies. I’ve had this debate with other devs throughout the years and they usually point to the lockfile as assurance, but version ranges with a ^ mean that when the lockfile gets updated, you can pull in newer versions you didn’t explicitly choose.
If what you're building can put your company out of business it's worth the hassle.
But it goes the other way too. If there's a security vulnerability that was fixed in a later version, you want the system to automatically pick that up and apply it for you in an ideal scenario.
At this point, the risk of a compromised package outweighs the risk of an upstream vuln that actually matters. Npm audit is full of junk like client side redos vulns, you could probably ignore 90%+ of the reports and still be secure against the majority of of-concern attack classes.
Security patches aren't like bugs or features where you can just roll a new version. Often patches need to be backported to older versions allowing software and libraries to be "upgraded" in place with no other change introduced.
Say you had software that controlled the careful mix of chemicals introduced into a municipal water supply. You just don't move from version 1.4 to 3.2, you fix 1.4 in place.
reply