Oh wow, I used to work on Excel Add-Ins about 10 years ago. Even got a patent for it. I'd be curious to see how they implemented the calls.
We came up with what I still consider a pretty cool batch-rpc mechanism under the hood so that you wouldn't have to cross the process boundary on every OM calls (which is especially costly on Excel Web). I remember fighting so hard to have it be called context.sync() instead of context.executeAsync()...
That being said, done poorly it can be slow as the round-trip time on web can be on the order of seconds (at least back then).
Do you mean that you worked on the Excel Add-Ins platform in Excel (and not on a specific Add-In)?
If you were working on the platform itself, then I would be interested in hearing your more detailed thoughts on the matters you mentioned (especially since I am developing an open source Excel Add-In Webcellar (https://github.com/Acmeon/Webcellar)).
What do you mean with a "OM" call? And why are they especially costly on Excel web (currently my add-in is only developed for desktop Excel, but I might consider adding support for Excel web in the future)?
In any case, context.sync() is much better than context.executeAsync().
I worked on the Excel Add-Ins platform at Microsoft, yes. By OM call I mean "Object Model" call, basically interacting with the Excel document.
The reason those calls are expensive on Excel Web is that you're running your add-in in the browser, so every .sync() call has to go all the way to the server and back in order to see any changes. If you're doing those calls in a loop, you're looking at 500ms to 2-3s latency for every call (that was back then, it might be better now). On the desktop app it's not as bad since the add-in and the Excel process are on the same machine so what you're paying is mostly serialization costs.
Happy to answer more questions, though I left MSFT in 2017 so some things might have changed since.
No, as the other comment mentioned. But I’ve heard of more than a few customers running their own “server excel workflow” where they have an instances of excel.exe running a VBA macro that talks to a web server (and does some processing).
While working at MS I remember someone in the office team saying that the original version of Excel online spun to the actual Excel backend and had it output HTML instead of the usual win32 UI. Was I misinformed by chance?
Excel Online was a component of WAC. It was an ASP.NET (and C++???) web application that used OAuth between SharePoint Server and Exchange Server.
So I mean yes, you viewed Excel docs through a webpage just like you do today via ODSP or OneDrive consumer. The backend is completely different in the cloud service, though.
Yeah, that makes sense. For some reason, I was under the impression that all calculations run locally in the browser, which would have been comparable to how Excel desktop works (i.e., local calculations). Is there a reason for why the Excel calculations run on the server (e.g., excessive workload of a browser implementation, proprietary code, difficult to implement in JavaScript, cross browser compatibility issues, etc.)? Furthermore, if the reason for this architecture is (or was) limitations in JavaScript or browsers, do you find it plausible that the Excel calculations will some day be implemented in Webassembly?
Regardless, I have always preferred Excel desktop over Excel web (and other web based spreadsheet alternatives). This information makes me somewhat less interested in Excel web. Nonetheless, I find Excel Add-Ins useful, primarily because they bring the capabilities of JavaScript to Excel.
I don’t think Excel web will ever be running the calc engine browser side, no. The only way I could see this happen would be via compiling the core to wasm, which I don’t think is worth the engineering effort.
Excel has this legacy (but extremely powerful) core with very few people left that knows all of it. It has legacy bugs preserved for compatibility reasons as whole businesses are ran on spreadsheet that break if the bug is fixed (I’m not exaggerating). The view code for xldesktop is not layered particularly well either leading to a lot of dependencies on Win32 in xlshared (at least back then).
Is it doable? I’m sure. But the benefits are probably not worth the cost.
So the first thing that's important to understand is that Excel is the product of another era. One where resources like memory were very constrained and compilers and optimizers weren't as good as they are today (so much so that the Excel team at one point wrote their own because MSVC sucked, but I digress)...
And so, a lot of the core code is used to that. Cell formatting data for example is super tightly packed in deeply nested unions to ensure that as little memory is used to store that info. If something only needs 3 bits, it'll only use 3 bits. The calc engine compiles all of your formulas to its own (IIRC variable-instruction-width) bytecode to make sure that huge spreadsheets can still fit in memory and calc fast.
And a lot of it still carries the same coding and naming practices that it started with in the 80s: Hungarian notation, terse variable and file names, etc. Now, IMO, Hungarian notation by itself is pretty harmless (and even maybe useful in absence of an IDE), but it seemed to encourage programmers to eschew any form of useful information from variable names, requiring you to have more context to understand "why" something is happening. Like, cool, I have a pszxoper now (pointer to zero terminated string of XOper), but why?
So the code is tight, has a lot of optimization baked in and assumes you know a lot about what's happening already.
But more importantly, a lot of "why" information also just lives in people's head. Yes, some teams would have documentation in an ungodly web of OneNote notebooks, or spread across SharePoint pages, which had the least useful search functionality I've ever witnessed, but finding anything you wanted was hard. But that didn't use to matter, since the core team had been there for a long time, so you could ask them question.
That being said, I joined MSFT in 2012 and started working on Excel closer to 2014. At that point, heavyweight like DuaneC (who wrote like 10% of Excel and I don't think I'm exaggerating) had already retired and while others people were very knowledgeable in some areas, nobody seemed to have a good cross view of the whole thing.
You have to understand that I was in the Office Extensibility team. We were building APIs for the whole thing. I had to touch the calc system, the cells and range, the formatting, tables, charts and images (the whole shared oart system was interesting), etc. Answering "How do I do X" was always a quest because you would usually:
- Find 3 different ways of achieving it
- One of them was definitely the wrong way and could make the app crash in some situations (or leak memory)
- All the people on the "blame" had left
- One of them was via the VBA layer which did some weird stuff (good ol' pbobj)
- Be grateful that this wasn't Word because their codebase was much worse
And so, a lot of the API implementation was trial and error and hunting down someone who understood the data structures. The fact that full sync and rebuild took about 6 hours (you ran a command called ohome and then you went home) meant that experimenting was sometimes slow (at least incremental builds were OK fast). The only lifeline back then was this tool called ReSearch2 that allowed you to search the codebase efficiently.
But the thing is, once you got thing to work, they worked really well. The core was solid and performant. Just slightly inscrutable at time and not the kind of code you're use to reading outside of Excel.
Thanks for the interesting info! Yeah, maybe Excel web will someday support local calculations via wasm, but for now I think I will stick with Excel desktop with add-ins.
> though I left MSFT in 2017 so some things might have changed since.
Honestly, I struggle to think about what has actually changed between Office 2013 and Office 2024 (and their Office 365 equivalents); I know the LAMBDA function was a big deal, but they made the UI objectively worse by wasting screen-space with ever-increasingly phatter non-touch UI elements; and the Python announcement was huge... before deflating like a popped party balloon when we learned how horribly compromised it was.
...but other than that, Excel remains exactly as frustrating to use for even simple tasks - like parsing a date string - today just as it was 15 years ago[1].
This looks bad for Microsoft. They added a Copilot button to all their products but it doesn't do much more than open a chat side panel.
I recently tried Claude Cowork for PowerPoint and I was stunned by the content as well as design quality of the deck it produced. That's a threat for Microsoft because now you don't need the editing tools of PowerPoint, AI replaces it, so all you need is the presentation mode of PowerPoint.
Copilot for Excel is useless. Ask it what is in cell A1 and it can't answer. I am looking forward to trying ChatGPT for Excel.
Claude for excel is already amazing. Fully capable of doing junior work. Formatting is great. Can refactor large multi-tab spreadsheets. It just burns tokens. If OpenAI is going to subsidize this on the monthly enterprise plans for a while then it's a game changer.
Claude for Excel (I work in finance) was one of the absolutely critical reasons we added Anthropic enterprise licenses. But they've turned out to be quite expensive ($100/day for heavy users). We'll see what OpenAI's quotas are.
From my experience, LLM performance in these areas is being massively oversold. I have repeatedly tried using Claude to modify a range of models typical of investment banking / private equity / sellside research contexts, and the results have been generally disastrous. On multiple occasions, the xlsx would no longer open.
Just my experience, it’s not a solution but rather a productivity tool. I mostly use it for tasks I can do myself but it would probably take 20-30min to dial in - now Claude can do it in 2-3min. (E.g. in a data table - add a new column that checks column a if the data is a, do x, if the data is b, do y, if the data is c, do z - then combine that with the word after the hyphen in column b —- or another example —- create a new sheet that is the same format as sheet one but show calculates the difference between column a and b bot for sheets 1-12 in a summary)
I don’t get good results when I just have Claude build things on its own - but for these types of specific productivity tasks I can save a couple of hours here and there.
I work with large files a lot, running claude code on it is not token intense at all. Probably because it does a lot with scripts. But its a bit more raw, but i think in the end more powerful. Have to pick a good excel library and language. I do node, maybe python can work as well
Work in a firm similar to yours and we have been going to though the motions of figuring ways for the bullpen to make use of these tools and would love to hear your thoughts if you would be willing to share!
I run the Excel team at Microsoft. The experience you're describing sounds like it's from the earlier versions of Copilot in Excel that were genuinely limited.
Today, Excel Copilot takes a model-forward approach where we give the models full access to Excel's capabilities. We give customers the choice of the latest models from both OpenAI and Anthropic, and we encourage the models to iteratively explore the spreadsheet before taking action. It builds a full understanding of the semantics and structure of the spreadsheet, find issues in it, and ultimately gives you much better results.
Copilot can write formulas, build PivotTables, create charts, build multi-tab models, do multi-step analysis. The models are quite proficient at it, and they do a great job. We have an auto-mode which is the default where we pick the model for you, but you can also select specific models if you have a preference. I often see people switch between models to get the benefit of diverse perspectives, similar to how a diverse team approaches problems differently.
If you tried it a few months ago and walked away, it's worth another look.
There is a significant difference in experience between Copilot Basic for a M365 user whose IT admins have blocked integration capabilities with Sharepoint content vs Copilot Premium for a M365 user whose IT admins have allowed integration capabilities with Sharepoint content.
PowerPoint is the poster child for the class of applications that AI totally obsoletes:
* A large application whose outputs are independent of the all (people still print slides; when presenting nobody knows or cares what app was used)
* Complicated and requires users to learn lots of skills unrelated to the work they’re doing (compare to Excel, where the model and calculations require and reflect domain knowledge about the data)
* Practically zero value add in document / info management (compare to word where large documents benefit from structure and organization)
We’re pretty close to presentations just being image files without layers and objects and smartart and all that.
AI will come for all productivity tools, but PowerPoint will be the canary that gets snuffed first, and soon.
Chatgpt for Excel is still an office add-in running in the same sandbox though. strongpigeon described the exact bottleneck upthread, process boundary crossings, context.sync() roundtrips that take seconds on web. That's a platform limitation, not a model limitation.
Swapping AI behind the add-in doesn't fix the fundamental constraint that third-party add-ins can't deeply integrate with Excel's runtime the way a native feature can. If copilot is bad despite having more access to excel internals(I don't like how Copilot is designed or implemented tho), an add-in with less access is likely not be better.
I am still surprised that outside of open source AI models, Microsoft is just routing to external models, to a degree its kind of smart because they don't have to have all the skin in the game for the infrastructure, plus they sell some of the hosting anyway, but man. Why does Microsoft not have a frontier model yet? Would have been a great time any time in the last few years to introduce a real Cortana AI model.
> They added a Copilot button to all their products but it doesn't do much more than open a chat side panel.
I was hyped when I heard about Copilot. "I can tell it to make pivot tables now!" When I tried to use it I was shocked how underbaked it was. Below even my worst expectations. This really was someone shoving ChatGPT into Excel with almost zero additional effort. Copilot can't DO anything useful.
I've had the same experience. Copilot for Excel can't even parse basic cell references. Meanwhile Claude handles document formatting in one pass. The catch is it works externally, not inside the app, but at least it works.
The MCP ecosystem is what makes this interesting. Claude isn't just a chat panel bolted onto existing software, it's building integrations that actually manipulate the files. Microsoft had the distribution advantage but they're losing on capability.
Maybe a dumb question, but why does Microsoft care? They should have good apps and if OpenAI or Claude wants to create plugins, great. That's what they're there for and Microsoft invested a lot of effort to make the new add-ins much more powerful and intuitive for this very reason. It's really nice experience compared to VBA.
It obv makes Excel much more valuable and they can gatekeep by requiring the subscription for addins.
We have many people in my wider team (Finance) that are AI skeptics purely because of their experience with Copilot. Like they don't know what AI is actually capable of when outside of the shackles of Copilot.
> I recently tried Claude Cowork for PowerPoint and I was stunned by the content as well as design quality of the deck it produced. That's a threat for Microsoft because now you don't need the editing tools of PowerPoint, AI replaces it, so all you need is the presentation mode of PowerPoint.
Actually, someone here posted a Claude Code skill recently that generates a presentation as a self-contained HTML5 file, so all you need is a browser.
Hi everyone, engineer on ChatGPT for Excel here - we launched ChatGPT for Excel to bring the power of GPT-5.4 to Excel. Keen to hear feedback and happy to answer any questions!
I’ve always found it unbelievable how bad Gemini’s Google Sheets interaction is. Copying the sheets into Claude and then modifying them there and copying them back actually outperforms it.
Nowadays I just make single-purpose websites with Claude Code because Google Sheets has such poor AI integration and is outrageously tedious to edit.
They had all the parts and I have a subscription and it still does terrible things like prompt me to use pandas after exporting as a CSV. It will mention some cell and then can’t read it. It can’t edit tables so they just get overwritten with other tables it generates.
It reminds me of something a friend told me: he heard that Google employees do dogfood their products; some even multiple times every year. There’s no way anyone internal uses Sheets even that often.
I've experimented with ChatGPT for spreadsheets the past 6 months, and while the results look nice now it has been excruciatingly slow for even the simplest spreadsheet. I'm talking 15-20 minutes to make some pretty basic calculator with graphs. IIRC, it used a lot of time purely on the styling.
In principle, I find it valuable to integrate tools. However, in this case I would be somewhat cautious, especially as "your chats, attachments, and workbook content — may be shared with OpenAI" (as per the Microsoft Marketplace description: https://marketplace.microsoft.com/en-us/product/WA200010215?...).
This seems like a security nightmare, which is especially relevant because sensitive data is often stored in Excel files.
Several months ago, ChatGPT swore to me it had interoperability with both excel and Google Sheets. I spent 90 minutes thinking I was an idiot, trying to follow its guidance before asking the internet.
It was partially a joke but someone posted a image of Co-pilot in Excel to demonstrate the limits of these things. Three cells with three numbers (1, 2, 3) and co-pilot asked to sum these three up.
Instead of answering with 6, it came up with 15. The comment was "If AI is doing this, a global financial crash is inevitable."
Might not be real but it is something to keep an eye on. Hopefully, they are a bit more cautious on how this is implemented.
Speaking of which... The corporate world, which was already, since forever, producing Powerpoint presentations containing bogus numbers from buggy spreadsheet (I've been tasked once to port a corporate spreadsheet to a dedicated internal app and I then understood decisions in the world were taken, everywhere, based on bogus numbers from broken reports made by spreadsheets full of broken numbers/assumptions) is now going full-speed ahead: many vendors have added "Artificial 'Intelligence'" to their corporate tools and...
There are now just even more errors than there already were.
Now there's hope though: I take it at some point, just like we have AI that can already find (and fix and sometimes even properly fix) errors in code, we may end up with AI tools able to find all the broken assumptions and errors / wrong formulas the spreadsheets that make the corporate world are full of. But atm that's not where we are.
One such corporate-world company producing a gigantic turd would the "biggest" (but it's really not that big) european software company, SAP... They're going full on "business AI" as they see (rightly so?) AI as a terminal death threat to their revenue model. Market cap went from $360 bn to $200 bn: don't know if it's related to their "genius" AI-move.
And so now we have countless corporate drones who were already incapable of doing any kind of financial/accounting/math computation in a rigorous way who are now double-speeding on the errors, but this time AI-augmented.
It's the "let's add an AI chatbot to our site" (which so many companies are adding to their websites right now), but corporate version: "let's add AI to our corporate tools".
Just to be clear: I think this cannot fail. Failure and bogus numbers are the norm in spreadsheets, not the exception. More failure, more bogus computations, actually won't change a thing.
Microsoft has this built-in using Claude models (for M365 Copilot licensed users). I don't know why you'd use this as an M365 subscriber in an enterprise. I'm sure there's some edge cases, but MSFT has been moving away from OAI. Even Copilot Studio agents now default to Sonnet 4.6 and not GPT 5.
I am a ChatGPT plus user in the UK. I believe this should work for me as I am outside the EU (!), but every time I have tried it I get ‘Currently Unavailable - please try again later’. Which is very unhelpful.
> (…) you can verify each step and revert edits if needed.
I wish there were different workflows.
It feels like current most popular way of working with GenAI requires the operator to perform significant QA. The net time savings are usually positive. But it still feels inefficient, risky and frustrating, especially with more complex and/or niche problem areas.
Are there GenAI products that focus more on skill enhancement than replacement? Or any other workflows that improve reliability?
Show HN: I've built a C# IDE, Runtime, and AppStore inside Excel
670 points | 179 comments
One of the main use cases was to analyze Excel data with SQL. I'm the kind of nerd that loves stuff like that, but stuff like that seems completely obsolete now.
198 comments
We came up with what I still consider a pretty cool batch-rpc mechanism under the hood so that you wouldn't have to cross the process boundary on every OM calls (which is especially costly on Excel Web). I remember fighting so hard to have it be called
context.sync()instead ofcontext.executeAsync()...That being said, done poorly it can be slow as the round-trip time on web can be on the order of seconds (at least back then).
If you were working on the platform itself, then I would be interested in hearing your more detailed thoughts on the matters you mentioned (especially since I am developing an open source Excel Add-In Webcellar (https://github.com/Acmeon/Webcellar)).
What do you mean with a "OM" call? And why are they especially costly on Excel web (currently my add-in is only developed for desktop Excel, but I might consider adding support for Excel web in the future)?
In any case,
context.sync()is much better thancontext.executeAsync().The reason those calls are expensive on Excel Web is that you're running your add-in in the browser, so every
.sync()call has to go all the way to the server and back in order to see any changes. If you're doing those calls in a loop, you're looking at 500ms to 2-3s latency for every call (that was back then, it might be better now). On the desktop app it's not as bad since the add-in and the Excel process are on the same machine so what you're paying is mostly serialization costs.Happy to answer more questions, though I left MSFT in 2017 so some things might have changed since.
So I mean yes, you viewed Excel docs through a webpage just like you do today via ODSP or OneDrive consumer. The backend is completely different in the cloud service, though.
> WAC
Now that’s an acronym that I had forgotten about.
Regardless, I have always preferred Excel desktop over Excel web (and other web based spreadsheet alternatives). This information makes me somewhat less interested in Excel web. Nonetheless, I find Excel Add-Ins useful, primarily because they bring the capabilities of JavaScript to Excel.
Excel has this legacy (but extremely powerful) core with very few people left that knows all of it. It has legacy bugs preserved for compatibility reasons as whole businesses are ran on spreadsheet that break if the bug is fixed (I’m not exaggerating). The view code for xldesktop is not layered particularly well either leading to a lot of dependencies on Win32 in xlshared (at least back then).
Is it doable? I’m sure. But the benefits are probably not worth the cost.
> Excel has this legacy (but extremely powerful) core with very few people left that knows all of it.
Would love to hear more about this. Especially history and comparison to Lotus etc.
And so, a lot of the core code is used to that. Cell formatting data for example is super tightly packed in deeply nested unions to ensure that as little memory is used to store that info. If something only needs 3 bits, it'll only use 3 bits. The calc engine compiles all of your formulas to its own (IIRC variable-instruction-width) bytecode to make sure that huge spreadsheets can still fit in memory and calc fast.
And a lot of it still carries the same coding and naming practices that it started with in the 80s: Hungarian notation, terse variable and file names, etc. Now, IMO, Hungarian notation by itself is pretty harmless (and even maybe useful in absence of an IDE), but it seemed to encourage programmers to eschew any form of useful information from variable names, requiring you to have more context to understand "why" something is happening. Like, cool, I have a pszxoper now (pointer to zero terminated string of XOper), but why?
So the code is tight, has a lot of optimization baked in and assumes you know a lot about what's happening already.
But more importantly, a lot of "why" information also just lives in people's head. Yes, some teams would have documentation in an ungodly web of OneNote notebooks, or spread across SharePoint pages, which had the least useful search functionality I've ever witnessed, but finding anything you wanted was hard. But that didn't use to matter, since the core team had been there for a long time, so you could ask them question.
That being said, I joined MSFT in 2012 and started working on Excel closer to 2014. At that point, heavyweight like DuaneC (who wrote like 10% of Excel and I don't think I'm exaggerating) had already retired and while others people were very knowledgeable in some areas, nobody seemed to have a good cross view of the whole thing.
You have to understand that I was in the Office Extensibility team. We were building APIs for the whole thing. I had to touch the calc system, the cells and range, the formatting, tables, charts and images (the whole shared oart system was interesting), etc. Answering "How do I do X" was always a quest because you would usually:
- Find 3 different ways of achieving it
- One of them was definitely the wrong way and could make the app crash in some situations (or leak memory)
- All the people on the "blame" had left
- One of them was via the VBA layer which did some weird stuff (good ol' pbobj)
- Be grateful that this wasn't Word because their codebase was much worse
And so, a lot of the API implementation was trial and error and hunting down someone who understood the data structures. The fact that full sync and rebuild took about 6 hours (you ran a command called
ohomeand then you went home) meant that experimenting was sometimes slow (at least incremental builds were OK fast). The only lifeline back then was this tool called ReSearch2 that allowed you to search the codebase efficiently.But the thing is, once you got thing to work, they worked really well. The core was solid and performant. Just slightly inscrutable at time and not the kind of code you're use to reading outside of Excel.
> though I left MSFT in 2017 so some things might have changed since.
Honestly, I struggle to think about what has actually changed between Office 2013 and Office 2024 (and their Office 365 equivalents); I know the LAMBDA function was a big deal, but they made the UI objectively worse by wasting screen-space with ever-increasingly phatter non-touch UI elements; and the Python announcement was huge... before deflating like a popped party balloon when we learned how horribly compromised it was.
...but other than that, Excel remains exactly as frustrating to use for even simple tasks - like parsing a date string - today just as it was 15 years ago[1].
[1]: https://stackoverflow.com/questions/4896116/parsing-an-iso86...
I recently tried Claude Cowork for PowerPoint and I was stunned by the content as well as design quality of the deck it produced. That's a threat for Microsoft because now you don't need the editing tools of PowerPoint, AI replaces it, so all you need is the presentation mode of PowerPoint.
Copilot for Excel is useless. Ask it what is in cell A1 and it can't answer. I am looking forward to trying ChatGPT for Excel.
Claude for Excel (I work in finance) was one of the absolutely critical reasons we added Anthropic enterprise licenses. But they've turned out to be quite expensive ($100/day for heavy users). We'll see what OpenAI's quotas are.
You get models that are formatted and structured and which balance - but there are errors introduced which an analyst / human wouldn’t make.
Stuff like hard coded values, or incorrect cell logic which guarantees the model balances.
I don’t get good results when I just have Claude build things on its own - but for these types of specific productivity tasks I can save a couple of hours here and there.
Does this remove (or at least increase) the upload limit?
No limits.
> No limits.
Yet.
Today, Excel Copilot takes a model-forward approach where we give the models full access to Excel's capabilities. We give customers the choice of the latest models from both OpenAI and Anthropic, and we encourage the models to iteratively explore the spreadsheet before taking action. It builds a full understanding of the semantics and structure of the spreadsheet, find issues in it, and ultimately gives you much better results.
Copilot can write formulas, build PivotTables, create charts, build multi-tab models, do multi-step analysis. The models are quite proficient at it, and they do a great job. We have an auto-mode which is the default where we pick the model for you, but you can also select specific models if you have a preference. I often see people switch between models to get the benefit of diverse perspectives, similar to how a diverse team approaches problems differently.
If you tried it a few months ago and walked away, it's worth another look.
* A large application whose outputs are independent of the all (people still print slides; when presenting nobody knows or cares what app was used) * Complicated and requires users to learn lots of skills unrelated to the work they’re doing (compare to Excel, where the model and calculations require and reflect domain knowledge about the data) * Practically zero value add in document / info management (compare to word where large documents benefit from structure and organization)
We’re pretty close to presentations just being image files without layers and objects and smartart and all that.
AI will come for all productivity tools, but PowerPoint will be the canary that gets snuffed first, and soon.
I am surprised that Microsoft's own copilot product is so far behind though.
> This looks bad for Microsoft.
Maybe(?) from a product catalogue perspective... But from a strategic perspective less so because they own ~27% of OpenAI.[0]
[0] - https://openai.com/index/next-chapter-of-microsoft-openai-pa...
> They added a Copilot button to all their products but it doesn't do much more than open a chat side panel.
I was hyped when I heard about Copilot. "I can tell it to make pivot tables now!" When I tried to use it I was shocked how underbaked it was. Below even my worst expectations. This really was someone shoving ChatGPT into Excel with almost zero additional effort. Copilot can't DO anything useful.
The MCP ecosystem is what makes this interesting. Claude isn't just a chat panel bolted onto existing software, it's building integrations that actually manipulate the files. Microsoft had the distribution advantage but they're losing on capability.
It obv makes Excel much more valuable and they can gatekeep by requiring the subscription for addins.
Microsoft fumbled so badly here.
> I recently tried Claude Cowork for PowerPoint and I was stunned by the content as well as design quality of the deck it produced. That's a threat for Microsoft because now you don't need the editing tools of PowerPoint, AI replaces it, so all you need is the presentation mode of PowerPoint.
Actually, someone here posted a Claude Code skill recently that generates a presentation as a self-contained HTML5 file, so all you need is a browser.
PowerPoint, as a whole, is doomed.
Nowadays I just make single-purpose websites with Claude Code because Google Sheets has such poor AI integration and is outrageously tedious to edit.
They had all the parts and I have a subscription and it still does terrible things like prompt me to use pandas after exporting as a CSV. It will mention some cell and then can’t read it. It can’t edit tables so they just get overwritten with other tables it generates.
It reminds me of something a friend told me: he heard that Google employees do dogfood their products; some even multiple times every year. There’s no way anyone internal uses Sheets even that often.
This seems like a security nightmare, which is especially relevant because sensitive data is often stored in Excel files.
Damn that OAI valuation is like a sore boil that is about to explode.
Also once again, a lack of imagination from OAI. Damn vision really is super scarce huh.
Instead of answering with 6, it came up with 15. The comment was "If AI is doing this, a global financial crash is inevitable."
Might not be real but it is something to keep an eye on. Hopefully, they are a bit more cautious on how this is implemented.
There are now just even more errors than there already were.
Now there's hope though: I take it at some point, just like we have AI that can already find (and fix and sometimes even properly fix) errors in code, we may end up with AI tools able to find all the broken assumptions and errors / wrong formulas the spreadsheets that make the corporate world are full of. But atm that's not where we are.
One such corporate-world company producing a gigantic turd would the "biggest" (but it's really not that big) european software company, SAP... They're going full on "business AI" as they see (rightly so?) AI as a terminal death threat to their revenue model. Market cap went from $360 bn to $200 bn: don't know if it's related to their "genius" AI-move.
And so now we have countless corporate drones who were already incapable of doing any kind of financial/accounting/math computation in a rigorous way who are now double-speeding on the errors, but this time AI-augmented.
It's the "let's add an AI chatbot to our site" (which so many companies are adding to their websites right now), but corporate version: "let's add AI to our corporate tools".
Just to be clear: I think this cannot fail. Failure and bogus numbers are the norm in spreadsheets, not the exception. More failure, more bogus computations, actually won't change a thing.
> Follow along so you can trust the work
> (…) you can verify each step and revert edits if needed.
I wish there were different workflows.
It feels like current most popular way of working with GenAI requires the operator to perform significant QA. The net time savings are usually positive. But it still feels inefficient, risky and frustrating, especially with more complex and/or niche problem areas.
Are there GenAI products that focus more on skill enhancement than replacement? Or any other workflows that improve reliability?
Show HN: I've built a C# IDE, Runtime, and AppStore inside Excel
670 points | 179 comments
One of the main use cases was to analyze Excel data with SQL. I'm the kind of nerd that loves stuff like that, but stuff like that seems completely obsolete now.
[0] https://news.ycombinator.com/item?id=34516366