# 埃森哲：昔日与今朝，以及它如何预示未来

- 来源：Gary Marcus：The Road to AI We Can Trust（RSS）
- 作者：Gary Marcus
- 发布时间：2026-06-19 02:17
- AIHOT 分数：48
- AIHOT 链接：https://aihot.virxact.com/items/cmqjvs07c00mhslhi8i42gwcr
- 原文链接：https://garymarcus.substack.com/p/accenture-then-and-now-and-how-it

## AI 摘要

埃森哲去年九月高调宣称AI将改变其业务，但本季度财报令人失望，股价下跌约18%，本周跌幅近23%，较52周高点已跌超50%。生成式AI并未带来预期的大幅收益，MIT、麦肯锡、贝恩等多份研究均显示类似结论。Claude Code（特殊神经符号系统，非通用聊天机器人）或能提升程序员生产力，但企业整体AI投资回报未达预期，tokenmaxxing热潮正在消退。

## 正文

Blip, or one more data point that is on trend?

Last September, Accenture was crowing about how AI was going to transform its business:

Today, as I write this, the stock has dropped around 18%, almost 23% for the week, well over 50% from the 52 week high, after a disappointing quarter.

Doesn’t look like their massive AI bet paid off. (Of course competition from AI might be eating into their business, but either way, Accenture’s rolling it out hasn’t produced the miracles they were hoping for.)

I really do think that Claude Code (which remember, is a special-purpose neurosymbolic system rather than a generic chatbot) will increase productivity for coders (if technical debt doesn’t swallow back those gains).

But on the whole, Generative AI has not been delivering great gains. We have seen that now in study after study, MIT, McKinsey, Bain, and many more.

Accenture’s mediocre quarter doesn’t seem like a blip; instead, it seems like one more example of corporate AI RoI not meeting expectations.

Small wonder tokenmaxxing is dying; if enough other big customers are similarly disappointed, the whole jig will be up.

Tweet of the day:

Discussion about this post

Author

i would flip it around and say whenever AI fails it’s probably a pure LLM. all the big wins lately have in fact involved code interpreters, symbolic code (in addition to neural networks etc).

The joke that is becoming viral is exactly what some working class engineers are we saying to anybody that wants to listen every time some de says that he is 10x productive with code agents.

It does not matter that you go ahead 100 meters in 8 seconds, if after you have to go back 500 meters.

In 25 years I did not see any valid productivity metric for developers. Zero. All BS. Measuring software by quantity, supposed quality (infinite definitions here about what is supposed to be quality in software) or complexity (here the only metrics still valid are ciclomatic Complexity and dependencies graphs, because more ifs more hard to maintain, and more dependencies, harder to maintain).

There is not any metric that is long term and that is not bullshit. Time to market could be totally erased by time to go back from market with your reputation as brand damaged for ever. Number of features per month could be downgraded by number of users not using them and complaining about your bloated product.

Technical debt was called like that because the engineer proposing it wanted to explain to suits that any technical shortcut or less than optimal technical solution works like financial debt : you will have to pay it someday, and if you start collecting other debts to pay that debt... Well, you know how is finishing the people that need to use their credit card to pay their mortgage.

Software is always one step near a combinatorial explosion of states. Every day you have to "cut the grass" from it, to maintain the number of different states manageable. Because as soon as the explosion starts, states not contemplated arise always. And any new feature adds more probability to that to happen.

How to measure that? No idea. But people not understanding that, just prompting because they can finish their tasks faster and be at home with their kids, are not receiving the incentives that is going to produce more productive software. Not at all.

So yeah. Stop saying that LLMs might have a productive application in software when still nobody was able to probe it (and dev tech bros claiming it in Twitter is not proof of nothing)

Ready for more?