Erik Brynjolfsson published new data last week showing the AI productivity takeoff is, in his words, “finally visible.” Aggregate numbers, real sectors, not just vibes from Twitter. And almost simultaneously, Aaman Lamba, the creator of OpenCode, posted a contrarian piece arguing that most developers are fooling themselves about AI productivity gains, that the self-reported numbers are wildly inflated because people conflate speed-of-typing with speed-of-shipping. I read both on the same morning and spent the rest of the day trying to figure out why two smart people looking at the same phenomenon arrived at opposite conclusions.

They’re both right. That’s the uncomfortable part.

The data moved, but unevenly

Brynjolfsson’s numbers track sector-level output per hour worked, and the uptick is concentrated in a handful of industries: software, financial services, customer support, content production. These are exactly the sectors where AI tools have been integrated into actual workflows, not bolted on as afterthoughts, but woven into the places where work happens. Customer support teams using AI that reads tickets and drafts responses inside the ticketing system itself saw real gains. So did coding teams using Cursor and Copilot, where the AI lives in the editor, sees the file, understands the context without anyone copy-pasting a damn thing.

But Lamba’s point holds for the vast majority of knowledge workers who adopted AI the other way: by opening a chat tab and manually shuttling information back and forth between their work and a text box. That workflow adds a step. It feels faster because the AI’s output is impressive, but the overhead of context-switching, copying, pasting, reformatting, and then verifying that nothing got lost in translation eats most of the theoretical gain. You’re running a relay race where the AI sprints its leg in two seconds and you spend four minutes passing the baton.

Who actually got faster

The pattern in Brynjolfsson’s data is not “people who use AI are more productive.” It is more specific than that, and the specificity matters. The productivity gains cluster around workers whose AI tools are embedded in their working environment. Developers with code-aware AI in their IDE. Support agents with AI inside Zendesk. Analysts with AI plugged into their spreadsheet tools. The common thread is not the model. GPT-5.2, Claude, Gemini, whatever. The common thread is proximity. The AI sits where the work sits, reads what the worker reads, and acts without requiring the worker to become a manual integration layer between two disconnected applications.

And then there is everyone else, the much larger group, still copy-pasting between ChatGPT and their browser like it is 2024. These people genuinely believe they are more productive, which is what Lamba is reacting to, and the belief is sincere but wrong in a measurable way. Because the five seconds the AI saves on generating a response gets buried under the thirty seconds of tab-switching and context reconstruction surrounding it.

The IDE figured this out already

Cursor’s growth tells the story pretty clearly. It is not a better model. It is a better integration. The AI reads your codebase, sees your cursor position, understands which file you have open and what you just changed. So when it suggests code, the suggestion is contextually aware in a way that asking ChatGPT to “help me write a function” never will be. Developers did not get more productive because models got smarter this year. They got more productive because someone finally put the model inside the tool instead of beside it.

Browsers are the Cursor problem all over again, except bigger, because most knowledge work happens in a browser and there is no equivalent of “put AI inside the browser” for the average worker. Or there wasn’t.

Browser agents are the missing integration

A browser agent does for web-based work what Cursor did for coding. It lives in your browser, reads the page you are on, understands your context, and acts on it directly. No copying. No pasting. No rebuilding context in a separate chat window. The AI sees the email thread before it drafts your reply. It reads the form before it fills it out. It looks at the spreadsheet before it summarizes the data.

This is not a small UX improvement. It is the difference between the two groups in Brynjolfsson’s data. The productive group has AI embedded in their workflow. The stalled group has AI in a separate tab. dassi sits in your browser’s side panel and closes that gap for anything you do on the web, which for most knowledge workers is basically everything they do at work.

Lamba is not wrong, he is just describing the wrong group

The OpenCode creator’s skepticism comes from watching people overestimate their AI productivity while doing the exact workflow that guarantees they won’t actually be more productive. And he is right to be skeptical of those self-reports. But the mistake is generalizing from that group to everyone. The people showing up in Brynjolfsson’s productivity data are not the same people Lamba is criticizing. They are the ones who stopped treating AI like a search engine in a separate window and started using it as a layer on top of their actual work.

So both takes coexist without contradiction. The takeoff is real, and most people are fooling themselves. Both at the same time. Because the takeoff is only happening for workers whose tools eliminated the copy-paste tax, and the people fooling themselves are the ones who never did.

If your AI workflow involves the words “let me paste this into ChatGPT,” you are in Lamba’s group whether you realize it or not. The productivity paradox does not resolve itself through better prompting or smarter models. It resolves itself when the AI moves from a separate destination to an ambient layer over the place you already work. For coders, that was the IDE. For everyone else, it is the browser.