.png)
4 months ago
6
The future of elderly lives entrusted now into younger hands.
Life happens until it doesn’t, but there’s a long twilight. Power of attorney documents get signed.
At the moment I'm trying to speedrun a PhD; I’m lecturing in computer science and AI during a time of such rapid change that we can safely reuse last semester’s exam questions because all the answers have changed; I have a consulting business; I’m writing a book and trying to keep up my previous pace of composing music. None of those are as stressful or as brain-consuming as having to take over the affairs of an elderly relative when they are no longer able to take care of themselves.
I think the reason is that over one's life one acquires certain patterns and habits, and suddenly I’m having to catch up with seven or eight decades worth of someone else’s habits and how they automated their affairs. Often it’s very opaque. Just when you think you are on top of something (e.g. medication management), you find out that the insurance company is still charging them for the house they sold three years ago.
I thought that by writing some programs I could relieve the burden of it. As I wrote a few weeks ago — https://solresol.substack.com/p/the-answer-to-the-million-dollar — we really can be much more ambitious now in what software we build.
So I set up an environment for the programs that I would need to write. I set it up in OpenAI’s Codex product, which is part of the suite that you get if you're willing to pay $200 per month. When I’m doing software development projects, it usually pays for itself within the first two or three hours of the month, so in the grand accounting of what software subscriptions stay or are dismissed from service, this one is likely to stay.
But then… I didn’t find I need all that many programs after all. I did write a program that automatically pulled some files in from my email, but that didn’t save me much time. Sometimes, the future arrives quietly, making your hardest preparations look like overthinking. I had built an elaborate workshop, but the tools had learned to craft themselves.
This is the prompt I used to set up the environment (lightly edited for obvious reasons).
This is what we need in this environment. Write notes for yourself so that you know in the future where these things are stored: - A scheduled tasks list. Things that I need to do on a regular basis. On that list now "Once per week, pay the physiotherapist"; "Once per month, pay the chemist" - An ad-hoc to-do list. Things I need to do, which aren't going to repeat. On that list now, there should be "Get the pension organised" and "Cancel home insurance" and "Assemble the re-imbursement claim for everything that I've bought for her" and "Do some treasury work: figure out how much money we can put into a term deposit" - A list of completed activities (especially with dates). This is how we'll know whether a scheduled activity is due to be done again. I'm very overdue paying the physiotherapist. I think the chemist was last paid at the start of May. - An index of the documents in the records/ directory, which shows whether it has been actioned or not. - hledger environment for tracking paid and unpaid invoices. - Here are the bank accounts ... [what they are used for] this will help in creating ABA files. - A list of medications. Remind yourself that whenever you update that list of medications, you should use your knowledge of drug-drug interactions to identify any contraindicated drugs. Whenever you see a new invoice from a chemist, compare the line items on it with the medications that you know about and bring any changes to my attention.At this point, it’s not that different to using Claude + Google Drive — if you tell Claude where everything is, it can keep track of what is on your to-do list. For non-programmers with elderly relatives, this is what I would recommend unless you want a crash course in living in the future.
But I see life’s routines and responsibilities as the source code of the operating system: structured, trackable and too important to be left to paper and memories. Agency matters, so this needs an agent.
The magical promise of AI agents is to do the work themselves, not just enable human beings to work faster as talking to a chatbot would. But the danger of AI agents is that there needs to be some kind of review process. They can't be trusted not to mess up in extraordinary and unexpected ways that no human being would —which is not surprising because they are extraordinary, unexpected, and inhuman. Powerful magic must be tamed.
Rule 1. I'm not letting this agent have direct access to the Internet. The potential for screw-ups and the danger is too great. It can create a bank transfer file, but it doesn’t have access to the bank’s website to do the transwer.
Rule 2. Anything it wants to do, I will review. I take seriously that it is my responsibility to take decisions that my relatives couldn't. I'm not abnegating that to AI. The responsibility has to be mine.
So my workflow looks like this:
I paid the chemist.It then replied with a request to update a number of files:
It added a completed activity, it added a journal entry to the (hledger) accounting system, it added to the paid invoices file, and removed the chemist from the unpaid invoices.
Since that looked correct, I approved it.
It already knew how much I had to pay because the invoice from the chemist had made its way into the repository via the email-attachment-to-git email bot I had written.
I didn’t explicitly program any receipt scanning software. Receipt scanning software is the backbone of enterprise accounting systems — but that software is now obsolete. OpenAI’s o3 model knows how to do it ad hoc.
It also knew how much I was going to pay the chemist because I had asked it for that information just beforehand. It was both the information source and the information sink. The judge and the policeman.
I could just as easily have told it about the latest prescription to add to the medications list, and it would have updated the appropriate files and done a sanity check on whether the prescribing doctor was paying attention. Except that I didn’t need to, it got that from the invoice from the chemist. So far it found one overlooked drug interaction but it was minor.
I know what I needed to set up because I grew up in a medical family and drug interactions were one of a range of unusual dinner table conversation topics. I know about accounting systems because I’m married to an accountant. I know about software development processes because I’ve spent a lifetime honing my craft.
Speech recognition works inside Codex, so I am literally whispering incantations to rocks and sand that we have tricked into thinking, ordering bots who have mastery of tasks I’ve spent a lifetime merely practicing. They perform their incantations upon themselves, while the lore says that there are even more spells yet unwritten waiting silently for me to realise that they need to be spoken.
The hledger that it used is an interesting piece of software. It's open source and runs on a huge variety of platforms. It's an accounting system that is simultaneously very retro and also very modern.
It is from a family of plain-text-based accounting platforms. It doesn't have a relational database storing transactions — so it is unlike pretty much every other accounting system you've ever seen. It stores the ledger as a plain text file that you could print out, and if you did, it would make perfect sense to a 15th-century Venetian merchant at the dawn of double-entry bookkeeping.
This isn't an efficient storage format. You couldn't run an enterprise accounting package like this. But for a small to medium-sized enterprise that might only ever do 50,000 transactions in their entire existence? A plain text file can be read in a few hundred milliseconds by modern CPUs. It’s fine.
And with that plain text format comes a number of advantages.
Interoperability. You can swap between different plain text accounting packages as required, or if you want to edit with a text editor and use no external software at all, you can do that too.
Compatibility with Git for version control. You can store this plain text ledger in a version control repository and be able to reconstruct what the accounts looked like at any moment in history.
Reproducibility. I can just copy the file. I know with complete confidence that I don't need to install other applications in particular ways to work with that file. I can recreate an environment for working on this set of accounts straightforwardly.
Better archiving, both in the short and long term. Future digital archaeologists will have no problems understanding each ledger account, where they will have no hope of ever knowing what was going on in our large enterprises that were running SAP.
Also, because these kinds of tools tend to be associated with software developers doing accounting, there are all sorts of command-line tools for manipulating the accounts directly which make things easier. In the rest of the accounting universe integrations are a big deal: congratulations on getting Shopify to talk to QuickBooks using Zapier. But a small company using hledger would have a workflow that just triggers a hledger command to add the transaction. Integration between hledger and other systems is so trivial that nobody talks about it.
The o3 model that powers OpenAI Codex knows about hledger's command line, and it knows the hledger file format as well, so it can act as an accounting agent, performing all the tasks that a bookkeeper would do, and generate reports that an accountant would do. It can do all this in a sandbox environment where there is no danger of it causing havoc in a real set of accounts, and all the changes it wants to do can be reviewed by me using the pull request infrastructure that I'm using every day anyway as part of my software development work.
You'll see the second file that it wanted to change was adding a transaction to the hledger journal. I don't know whether it added this by running an hledger command and then presenting the modified file to me or whether it modified the file directly. It doesn't matter. Either way, it worked and was correct.
These are the agent’s subroutines and subresponsibilities with their substructures, subtracks and subimportances in their digital equivalences of paper and memory.
One thing that these text-based accounting systems do very poorly is payroll, and payroll projects are the death of enterprise software projects. So for an organization that has payroll to pay, this isn't going to be practical in the short term.
Fortunately, none of my family are wealthy enough to have paid servants, so there is no payroll for me to run. There is only personal accounting.
I probably would not have bothered with an accounting system if I'd had to pay for it or if I'd had to use a bookkeeper to keep it intact. But since I get this for free simply by having the environment set up, accounting and finances and bank reconciliations are a lot better under control than they otherwise would have been. Best practice doesn’t require mastery and practice when the agent has absorbed all the written words on the topic.
I think something like the hledger-inside-codex is the way forward though for all organizations eventually though. We have to review agent actions, which either means either that:
we are chained to our desks, reviewing every action independently (as we would with, for example, the MCP connectors for Xero and QuickBooks), or
we have to be able to reproduce the entire accounting environment, define changes in bulk, and review in bulk.
I’ve never heard anyone talk about the latter which is what I stumbled into here.
Others are crafting elaborate tools, but I think the workshop itself is going to be the masterwork.
OpenAI definitely weren’t thinking about accounting and elder care where they made an AI software development agent. But once we build agents that are smart enough to do some tasks, there’s a blast radius of other areas that they can adapt to: accounting and pharmacy being two of them. There’s more that would be possible — presumably insurance broking — but we’re just stumbling around the jagged frontier in our explorations.
It’s not obvious that administering one’s elderly relative’s affairs could be improved by a bot that was designed to accelerate the development of AI software improvements.
It’s also strange that the skills an AI bot needs in order to be that accelerator of software development overlaps strongly with the skills needed to obviate the need for software to be written.
I suspect we already can build viable and useful organisations out of the bots we have today. The race to AI-enabled disemployment is not going to be won by the smarter AI, but by the cultures that let AI technology diffuse through their society faster. We live in that twilight era when it is still happening.
The limitation is that we (the human) beings are trying to fit AI bots between walls that were hewn for human intelligences. AI bots aren’t human. They can and will refactor job roles and tasks in ways that are as utterly alien to us as those job roles are alien to them.
What they think of as being obviously connected will read to us a bit like a chiasmic substack post that goes from eldercare to futurism via accounting and software development.
The future of artificial lives entrusted now into human hands.
