Thanks, David! I agree that capabilities for spreadsheets are not very strong at the moment.
I’ve tried a few times to get Claude Code to help with converting our CEAs into databases and haven’t been very successful as it commonly tries to take shortcuts or the context window runs out. If you (or anyone else) has advice on converting them, I would love to hear it.
For context, our most complex CEAs (example) are where we’d get the most value and they’re often 1,500+ lines and 10+ tabs, which is where we run into issues.
I’ll try a bit myself and share progress if I make any. Better still, I’ll try to signal-boost this and see if others with more engineering chops have suggestions. This seems like something @Sam Nolan and others (@Tanae, @Froolow , @cole_haus ) might be interested in and good at.
(Tbh my own experience was more in the other direction… asking Claude Code to generate the Google Sheets from other formats because google sheets are familiar and either to collab with. That was a struggle.)
One of the big recurring arguments in pharma cost effectiveness modelling is whether to use databases and scripts with a proper statistical programming languages like R, or whether to stick with Excel /​ Sheets for our models. The advantages of proper languages are manifold, including—as you’ve pointed out—that you can probably use LLMs on them more successfully to audit and augment your code. However the advantage of spreadsheets is that they are extremely portable, meaning almost anyone can run them natively on their laptop and anyone can understand how they work if they want to change parameters. This matters a lot if transparency is a goal, and transparency is often such an overriding goal that we pick Excel over technically stronger languages. So I’d caution that in converting the existing models to databases /​ scripts you’re actually making implicit decisions about the nature and audience of the model far beyond just whether they are legible to LLMs or not.
I mention this because I’m about to get nerd-sniped by the problem and want to make sure the limitations of the approach are well understood before I get sucked into it!
Fair point, some counterpoints (my POV obviously not GiveWell’s):
1. GW could keep the sheets as the source of truth, but maintain a tool that exports to another format for LLM digestion. Alternately, at least commit to maintaining a sheets-based version of each model
2. Spreadsheets are not particularly legible when they get very complicated, especially when the formulas in cells refer to cell numberings (B12^2/​C13 etc) rather than labeled ranges.
3. LLMs make code a lot more legible and accessible these days, and tools like Claude Code make it easy to create nice displays and interfaces for people to more clearly digest code-based models
We are planning to keep spreadsheets as the primary format for our models (for transparency/​simplicity reasons like you both noted). However, some way to convert spreadsheets to code for LLM digestion and potentially building web apps or running more complex uncertainty analyses would be valuable to us.
Definitely not asking anyone to spend time on this for us! I was just wondering if anyone was aware of a good way to do the conversion.
We did a conversion from Excel to R in 2025, although not LLM assisted. It took about three months, which I would say was a disappointing but realistic downside-case timeline (we basically budgeted for two months and something complex came up). So if you’re finding you can get it done in weeks rather than months with an LLM you’re actually a long way ahead of the state of the art.
If you want help converting to a database let me know. It looks like a weekend project. We could also develop a front end for easier input, if you want. I would be happy to assist you.
Thanks, David! I agree that capabilities for spreadsheets are not very strong at the moment.
I’ve tried a few times to get Claude Code to help with converting our CEAs into databases and haven’t been very successful as it commonly tries to take shortcuts or the context window runs out. If you (or anyone else) has advice on converting them, I would love to hear it.
For context, our most complex CEAs (example) are where we’d get the most value and they’re often 1,500+ lines and 10+ tabs, which is where we run into issues.
This feels doable, if challenging.
I’ll try a bit myself and share progress if I make any. Better still, I’ll try to signal-boost this and see if others with more engineering chops have suggestions. This seems like something @Sam Nolan and others (@Tanae, @Froolow , @cole_haus ) might be interested in and good at.
(Tbh my own experience was more in the other direction… asking Claude Code to generate the Google Sheets from other formats because google sheets are familiar and either to collab with. That was a struggle.)
One of the big recurring arguments in pharma cost effectiveness modelling is whether to use databases and scripts with a proper statistical programming languages like R, or whether to stick with Excel /​ Sheets for our models. The advantages of proper languages are manifold, including—as you’ve pointed out—that you can probably use LLMs on them more successfully to audit and augment your code. However the advantage of spreadsheets is that they are extremely portable, meaning almost anyone can run them natively on their laptop and anyone can understand how they work if they want to change parameters. This matters a lot if transparency is a goal, and transparency is often such an overriding goal that we pick Excel over technically stronger languages. So I’d caution that in converting the existing models to databases /​ scripts you’re actually making implicit decisions about the nature and audience of the model far beyond just whether they are legible to LLMs or not.
I mention this because I’m about to get nerd-sniped by the problem and want to make sure the limitations of the approach are well understood before I get sucked into it!
Fair point, some counterpoints (my POV obviously not GiveWell’s):
1. GW could keep the sheets as the source of truth, but maintain a tool that exports to another format for LLM digestion. Alternately, at least commit to maintaining a sheets-based version of each model
2. Spreadsheets are not particularly legible when they get very complicated, especially when the formulas in cells refer to cell numberings (B12^2/​C13 etc) rather than labeled ranges.
3. LLMs make code a lot more legible and accessible these days, and tools like Claude Code make it easy to create nice displays and interfaces for people to more clearly digest code-based models
Thank you both!
We are planning to keep spreadsheets as the primary format for our models (for transparency/​simplicity reasons like you both noted). However, some way to convert spreadsheets to code for LLM digestion and potentially building web apps or running more complex uncertainty analyses would be valuable to us.
Definitely not asking anyone to spend time on this for us! I was just wondering if anyone was aware of a good way to do the conversion.
We did a conversion from Excel to R in 2025, although not LLM assisted. It took about three months, which I would say was a disappointing but realistic downside-case timeline (we basically budgeted for two months and something complex came up). So if you’re finding you can get it done in weeks rather than months with an LLM you’re actually a long way ahead of the state of the art.
If you want help converting to a database let me know. It looks like a weekend project. We could also develop a front end for easier input, if you want. I would be happy to assist you.