Not shape, but even with napkin math, you can work out the conclusion. Take email vs snail mail. Online ordering vs relying on catalog. The spreadsheet, the word processor, the various CAD software.
The key thing is that it's easy to contrast the old way vs the new way and the evidence become obvious.
The thing with LLM tooling is that they're not reliable. I can do fine with risks, but only when there's a way to manage it so that if the disaster happens, it's practically a black swan event.
Typing more code or solving one task has never been the core problem. The core problem has always been to encode a whole system into the computer AND then provide a control interface for it. It requires both an understanding of the system you want to encode (especially how it behaves over time) and empathy to know what would be the best control interface for the users.
That understanding does not rely on the amount of code, and the best control is found through communication.
An understanding of the system could be the following: A conference schedule consisting of events (time, place, speaker, description,...) stored or presented in some format. The interface would be: A web app with a mobile first UI that presents the information in an accessible manner (highlighting, filtering, exports,...).
A relatively quick (I haven't tested it), would have been to open the web inspector and extract the data using the dom API (requires knowledge of the dom api and a desktop browser), put the data into some json or a tsv file, then write a php script or a python script and then serve that. The interface could have been built with the standard elements of some css framework (bulma?).
Not saying the above is better. But the thing is that is doable from even a raspberry pi. And more it's repeatable and extensible. And the individual piece of knowledge are reusable in different situation.
Con: "Where's the evidence that this actually is improving productivity?"
Pro: "The evidence hasn't shown up in statistics yet; it's too new!"
Con: "And won't this destroy maintainability?"
Pro: "Show me the maintainability disasters caused by AI."
Con: "I can't yet; it's too new!"
Both sides are playing the "it's too new" card when asked for actual evidence to prove their claims. In fairness, it actually is too new for there to be much statistically-valid data, especially if the inflection point was November 2025. So both sides are trumpeting their position, neither with actual trustworthy data.
Everybody has their anecdote. Nobody has data yet.
Okay thanks. But what I'm saying is all of these anecdotes should add up to something measurable if there's something to the idea that an inflection point was reached in November 2025, right? There's a lot of marketing and hype and motivated reasoning going on, so that's why I don't trust broadly-reported notions.
Exactly, "productivity" and similarly "efficiency" are meaningless weasel word unless they're qualified and measured against something. So which measurable things? Let's start with just anything really because then we could ground the conversation in something real rather than just feelings of being more productive, which can be deceptive.
AnimalMuppet in their reply to my OP comment makes the point that these things haven't been around long enough to measure end-to-end productivity gains and come to a conclusion either way, and I agree with that. But we can still at least be measuring something.
For example, in my case AI has allowed me to write 10x more LOC than I usually would in a similar amount of time. But having to review it all, I've also deployed 1/4 the number of releases I normally would in the same period. By one measure I'm more productive, by another I'm less productive.
People could claim to be more productive by skipping the review. But in that case did AI make you more productive or did you lower standards? People could say they're using AI to do the review but is the impact of that being measured and has that caused more or fewer bugs? If more bugs, has the time to fix those been factored into overall productivity? In my experience it's common for people to eagerly count immediate productivity gains and discount long-term productivity sinks.
For this reason I think case studies are the best convincing thing, because they properly contextualize the usage and consider a longer-term window. They're also backwards looking instead of in-the-moment, so have the benefit of hindsight. But they're harder to come by and we probably won't see any meaningful case studies for a thing that people say happened in November.
But the very least people can be doing is just defining what they mean when they say "productivity" because otherwise everyone is talking past one another.
What shape did that evidence take?