There are customers who would like to see attribution on changes where AI contributed (companies, users, etc). True, that's not everyone, but you can query our repo for the issues for which this feature was implemented.
The rationale I suppose is those customers what to be more careful with code that was contributed by AI.
I don't see how this would actually help. If people don't want to disclose they used AI they will just strip the message from the commit.
Maybe those customers should just be more selective with the people they allow to contribute to their project?
Also, this kind of message doesn't even bring valuable info: it doesn't explain how the AI was used (could be 99% vibe-coding, or just a quick "Please review current changes" + minor fixes at the end?), which model was used, etc. Like other commenters here I can't see this as anything else than a marketing push for Copilot.
Don't take it personally though, you are probably not the one that should be taking the heat since the change was directly pushed by your product manager.
Claude tends to disregard "NEVER do X" quite often, but funnily enough, if you tell it "Always ask me to confirm before going X", it never fails to ask you. And you can deny it every time
There are plenty of examples in the RL training showing it how and when to prompt the human for help or additional information. This is even a common tool in the "plan" mode of many harnesses.
Conversely, it's much harder to represent a lack of doing something
Calculators are a particularly bad example for your case. There was absolutely hyperbole against calculators when they were introduced. [1]
With similar sentiment as well
"They make us dumb"
"Machines doing the thinking for us"
Cars were definitely seen as a fad. More accurately a worse version of a horse [2]
If you looked through your other examples, you'd see the same for those as well.
Some things start as fads, but only time will tell if they gain a place in society.
Truthfully it's too early to tell for AI, but the arguments you're making, calling it a fad already don't stand up to reason
We did an A/B test of an old SPA app, and a modern re-write using SSR and server-rendered pages.
By every performance metric, the new app was faster.
But we kept getting user feedback that the new site was "clunky" and "slow", even though we saw that the p90 was much lower on the new site. Most of our users asked us to enable a toggle to let them go back to the old "fast" site.
I'm not sure if this is a universal experience, but I think a lot of other sites that tried the CSR -> SSR move had similar experiences. It's just harder to talk about, since it goes against the usual narrative.
SSR can feel worse than SPA if you don't get the end-to-end latency under a certain threshold. If your SSR pages are taking upward of 100ms to render on average, it's going to start to feel like shit once you factor in the network latency.
My design goal for modern SSR pages is 500 microseconds render time on the server. A modern CPU can crank through several gigabytes of UTF8 text per second. There really isn't any excuse from a technology perspective. SSR pages being perceived as clunky & slow boils down to a skill / people / organizational problem. The computers and associated networks can definitely do it well.
Every single action should have no perceivable latency between the action and the feedback that the action was received. You can implement that with SSR but it is clunky and also requires a lot of JS generally.
Looked at the first one, and that's in a game setting? And they test 600 ms??
edit: The second one is more useful IMO. It's hard to get under 100 ms with a roundtrip, but < 300 ms should be doable, right? So you do lose the sense that you are directly manipulating data. In most cases I think that's a good trade-off. Exceptions would be things like Google docs, but that's also because it's a well made app I trust to actually sync my data without loss. Unlike most SPAs..
300ms for network latency both ways, with server potentially doing its own network calls for data to fulfill the request, interpolating the html, and then browser rerendering client seems like a stretch
I am curious to identify what your users are perceiving that isn't be being captured by your metric. If it is accurate and not just rhetoric that MOST of your users are asking for a rollback for purely performance reasons, that is a very extreme outcome.
Are your p90 metrics testing:
- navigation after first load?
- users who are going to the app after it is cached on their browser?
Are your actions going through server actions or rest apis? Do you have metrics on those?
You can write memory safe code in any language, but having a machine i.e. the Rust compiler check it for you is less error-prone than if a human does it.
Also if you look at the repo, only 3% of the codebase is in Assembly.
IMO if >95% project is in Rust, you can definitely claim it's a Rust project.
Parts of it could probably already exists in the LLM's corpus, but being able to join them together to build new things is what makes "vibe coding" so useful.
Even though, from personal experience, at scale it still falls apart
Seems a bit ironic considering that it's supposed to be a specification on how a website should be.
reply