17 comments

[ 0.24 ms ] story [ 9.5 ms ] thread
Having seen some spreadsheets in my time, I can imagine what the training data is like.
There are way worse choices to fall back on than LibreOffice. Heck, it's the primary tool I actually use in my business. I can tell you first hand that it does not handle all the random stuff that corporate Excel users come up with, but if you start with basic principles the files usually work great in the other direction.
My agents can deal with Excel all right. What’s the story?
I once tried using Gemini directly in Google Sheets to make a graph. I never managed to get it to do exactly what I wanted; after wasting way too much time on it I was able to fix the problem in a matter of seconds. It's fascinating because it is quite different from the situation in coding agents where they are in general really quick to read code and find issues/fixes.
Tried Gemini in Google sheets today and it was horrible. I simply asked it to apply a nice visual formatting (bold, header filling, currency signs etc) but it made everything look ugly despite working for 4-5 mins.
Yeah, it seems like such an easy value add (especially since they gate it on gemini subs) to make Gemini do a great job in the google productivity apps, but they are generally pretty awful.

Claude with MCP access to the google workplace APIs consistently does a better job with any manipulation of google docs

Yeah I don't know what's holding it back in the browser, doing stuff to sheets is fine from antigravity.
I didn't know that. Agents can't do today what I used VB for 20 years ago?
The key is to have agents generate code which exports Excel with live formulae (there's a good Python library).
I've tried to 'reverse engineer' some of our excel sheets, and it's difficult to get the model to stop scolding me for using so many =INDIRECT statements.
> Orcaset takes an entirely different approach to financial modeling. It builds financial models in pure Python code rather than attempting to interpret xlsx files. Model calculations are fully traceable, deterministic, and programmatically accessible by agents. Additionally, since Orcaset isn't limited to a spreadsheet's two-dimensional grid of A1:B2 cells, it can leverage software best practices like type checks to guard against invalid models.

Note that this is just an ad for Orcaset. But more interesting, if you look at Orcaset, they say its product is "Financial Models as Code". So instead of using Excel, you use Python. Reasonable and most serious models are in code. But I still can't figure out what Orcaset adds. It looks like the worst of both worlds. You have this cell concept, but it doesn't relate to an actual workbook so it's not transparent. And then you have the magic formulas and decorators that you have to learn.

@PeriodSeries.define("Revenue", accrual(YF.cmonthly))

def revenue():

    for k in Period.seq(date(2026, 1, 1), relativedelta(months=1)):

        def cell(p: Period = k):

            prior = yield from get_at(revenue, p.shift(-relativedelta(months=1)))

            return prior * 1.10 if not isna(prior) else 100.0

        yield k, factory
costs = (revenue * -0.50).named("Costs")

profit = (revenue + costs).named("Profit")

Thanks for reading the article! Responding to what orcaset adds, it lets users define line items than can be composed fluently and safely with strong type annotations. It also adds dependency tracing, memoization, and an iterative solver for cyclic dependencies.

Working on better documentation, the compositional form is probably easier to understand than then decorator. `Cell` might be a bad name as well. It doesn't map 1:1 to a spreadsheet cell, it just lifts a value into a wrapped object that the effect handler can work with.

flag because submarine article.