"It’s verifiable. The books either balance or they don’t. Ledgers either reconcile or they don’t. There’s almost always a “ground truth” to compare against (bank feeds, statements, prior periods). It’s boring and repetitive. Same vendors, same categories, same patterns every month. Humans hate this work. Software loves it."

These are all true statements, but all of those things are solvable with classic software. Quickbooks has done this for decades now. The parts of accounting that aren't solvable with classic computing are generally also not solvable by adding LLMs into the mix.

This conviction doesn't seem to acknowledge the problem at scale. Decades of great UI development will still leave out edge cases that users will need to use the tool for. This happens fundamentally because the people who need to use the tools are not the people who make them, they rarely even talk to each other (instead they are "studied" via analytics).

When /humans/ bring up the idea of integrating LLMs into UIs, I think most of the time the sentiment comes from legitimate frustration about how the UI is currently designed. To be clear, this is a very different thing than a company shimming copilot into the UI, because the way these companies use LLMs is by delegating tasks away from users rather than improving their existing interfaces to complete these tasks themselves. There are /decades/ of HCI research on adaptive interfaces that address this, in the advent of expert systems and long before LLMs -- it's more relevant than ever, yet in most implemenations it's all going out the window!

My experience with accounting ^H^H^H^H^H^H^H^H^H^H bookkeeping / LLMs in general resonates with this. In gnu cash I wanted to bulk re-organize some transactions, but I couldn't find a way to do it quickly through the UI. All the books are kept in a SQL db, I didn't want to study the schema. I decided to experiment by getting the LLM to emit a python script that would make the appropriate manipulations to the DB. This seemed to take the best from all worlds -- the script was relatively straightforward to verify, and even though I used a closed source model, it had no access to the DB that contained the transactions.

Sure, other tools may have solved this problem directly. But again, the point isn't to expect someone to make a great tool for you, but to have a tool help you make it better for you. Given the verifiability, maybe this /is/ in fact one of the best places for this.

They might not be solvable but you can get 5-10% Improvement on them, unfortunately you can't do a new product that is exactly like QuickBooks but 5% better at reconciliation etc.

I go the other way and say this is a vast oversimplication of the job by a tech bro doing what tech bros typically do.

I am not an accountant but for many years I worked adjacent to them as a developer. I got a lot of time to ask questions and I was generally curious. Even at the SMB level accountants don't necessarily always have a "ground truth". There are so many ways to bury financial data that it needs almost constant vigilance. Yes, in theory, there is one ground truth (inputs should balance with whats there) but in practice humans are SHOCKINGLY good at committing accounting fraud. GAAP is another thing.