> I still think it's only good for demos and getting a prototype

Have you actually tried that? Because my bet is that if your "prototype" is a anything that is very VERY traditional, e.g. a CMS, online shop, or anything that has examples online, yes it will be quick, but if it's genuinely new, namely something NOT available out there, maybe because it is relying on the latest stack that is not yet well documented, then I bet it will also fail terribly.

Edit: I personally did, namely using LLMs to make XR demos relying on a now relatively popular framework https://aframe.io and basically it fails most of the time by proposing "traditional" HTML/CSS, missing entirely that it's 3D. Anyway, long story short, didn't work for me so curious to know if the "getting a prototype" (a genuine prototype, not a codebase starting from scratch because IMHO that's different) part is validated or just an idea.

Another possibility: your teams are working less now.

Your understanding is somewhat incomplete. There is a strong top-down push to celebrate output maximization without inquiring too closely about if this output is meaningful, valuable, repeatable, or even happened at all.

It’s about making the productivity metrics go up, even if at the expense of real productivity or common sense. The man who it was named after ironically (unironically?) faked his own metrics

> Stakhanovism is kind of the opposite of US work culture in that it lionizes the worker and social contributions

Lionizes the worker for their output. Just the same as quota or target driven systems. It's the same kind of lionization as "employee of the month" schemes, i.e. a sham to encourage people to work harder.

If they’re mandating use like this I doubt it’s their only dysfunction. At least this one has a built in scapegoat.

Sounds like they are going to consider it a success no matter what.

Make it long enough that it's not worth any human's time reading it. Like full-on balls to the walls slop. Pass it between different LLMs to add additional conclusions and subheadings.

In fact, do it in parallel where one chatbot is adding another few pages here, and simultaneously and independently, another is adding different pages somewhere else and concatenate the results together.

Once you get about 25 pages of dense slop, just conclude that AI made writing this report 1000x more efficient.

Their ability to convince themselves they are geniuses far exceeds your ability to convince them they're not. They've already decided that the decision was a success. The only question is are you still going to be around to suffer the consequences when their delusions collide with objective reality?

I know you don't want to hear this, but I also know you know this is true: you would genuinely need to look at the full dataset that team collected to draw any meaningful conclusion here. Your single example means pretty much nothing in terms of whether the tool makes sense at large scale. Not a single tool or technology exists in this entire field that never fails or has issues. You could just as well argue that because you read something wrong on Google or Stack Overflow that those tools should be banned or discouraged, yet that is clearly false.

That said, I don't agree with or advocate the specific rollout methodology your company is using and agree that it feels more abusive and adversarial than helpful. That approach will certainly risk backfiring, even if they aren't wrong about the large-scale usefulness of the tools.

What you're experiencing is perhaps more poor change management than it is a fundamentally bad call about a toolset or technology. They are almost certainly right at scale more than they are wrong; what they're struggling with is how to rapidly re-skill their employee population when it contains many people resistant to change at this scale and pace.

Lets imagine it is 1990 and the tool is e-mail over snail mail. Would you want leadership of a company to allow every employee to find out on their own if email is better way to communicate despite the spam, impersonal nature, security and myriad other issues that patently exist to this day ? or allow exceptions if an employee insists (or even shows) how snail is better for them?

It is hardly feasible for an organization to budget time for replicating and validating results, form their own conclusions, for any employee form who wishes to question the effectiveness of the tool or the manner of deployment.

Presumably the organization has done that validation with reasonably sized sample of similar roles over significant period of time. It doesn't matter though, it would be also sound reasoning for leadership to take a strategic call even when such tests are not conducted or not applicable.

There are costs and time associated with accurate validation which they are unable / unwilling to wait or even pay for, even if they wish to. The competition is moving faster and not waiting, so deploying now rather than wait and validate is not necessarily even a poor decision.

---

Having said that, they can articulate their intent better than "write about how it made you more productive", by adding more description along the lines of "if not then explain all the things you have tried to try and adopt the tool and what and how it did not go well for you/ your role"

Typically well structured organizations with in-house I/O psychologists would add this kind of additional language in the feedback tooling, line managers may not be as well trained to articulate it in informal conversations, which is whole different kind of problem.

The answer isn't pre-ordained -- it's simply already known from experience, at least to a sufficient degree to not trust someone claiming it should be totally avoided. Like I said, there are not many corporate roles where it's legitimately impossible to find any kind of gain, even a small or modest one, anywhere at all.