AI
Directing AI agents is a management job
I have spent the last year building an enterprise platform almost entirely by directing coding agents. The surprise was not how much they can do. It was how precisely the work rewards the things good management has always rewarded.
For twenty-five years my relationship with software was the one most finance people have. Somebody built a system, I was handed its output, and my job was to explain the output to a board. I was more curious than most, so I usually walked over to the engineering team and asked how it worked. But I did not build it.
Eighteen months ago I decided that I could not have a credible opinion about what AI does to the finance function without finding out what these tools actually do. So I started building. Not a prototype and not a proof of concept: a multi-tenant, enterprise-grade platform for finance teams and Chartered Accountant practices, with real permissions, real audit trails and real tenant isolation. There has been a commit almost every day since.
I do not type the code any more. Agents write it and I direct them, which means I have to be able to read what comes back, judge whether it is right, and send it back when it is not. That is a real skill and it is not the one I expected to need. The single most useful thing I can tell another leader considering this is that the binding constraint is not technical. It is the skill of running people, applied to something that is not a person.
A brief that is vague comes back vague
Every manager knows the failure where you ask for "a view of the receivables position", receive something unusable, and discover on inspection that you never said as at what date, in which currency, at what level of aggregation, or for what decision. You blame the analyst. The fault was in the brief.
Agents make this lesson unavoidable, because the loop is fast enough that you cannot hide behind the delay. Ask for "a page to manage users" and you get a page to manage users. Plausible, complete, and wrong in every way you did not specify. Ask instead for a page that lists active members of the current organisation only, that cannot show a member from another tenant even if someone guesses the identifier, that disables the remove button for the last remaining administrator and says on screen why it is disabled, and you get something close to correct on the first attempt.
The quality of what comes back is a near-perfect mirror of the quality of what went out. There is no longer any way to pretend otherwise.
This is the same discipline as writing a decent scope of work, or a decent audit instruction, or a decent brief to a corporate lawyer. Finance professionals are, on the whole, unusually good at this. We are trained to specify. It transfers.
Delegation without abdication
The failure mode I see most often in people trying this for the first time is that they treat the agent as either a toy or an oracle. Both are ways of avoiding the actual job.
Treat it as a toy and you supervise every keystroke. That is slower than doing the work yourself and it teaches you nothing. Treat it as an oracle and you accept output you have not understood, which is how organisations end up with systems nobody can explain.
The posture that works is the one you would take with a bright junior on their second week. Give the context generously. Review the work where a mistake is expensive, not everywhere. Never sign off on something you have not understood.
Where judgement still lives
People expect me to say that the agents cannot code. They can code, and better than I can. What they cannot do is decide.
They cannot tell you that a particular convenience is not worth the tenant-isolation risk it introduces. They cannot tell you that a feature which is technically correct will be misread by a user under pressure at a month end. They cannot tell you that a control which looks redundant is the one an auditor will ask about first, or that the elegant approach is the wrong one because in three years somebody who is not you will have to maintain it. Those are all judgement calls, and every one of them is a judgement about consequences in the real world, which is exactly the thing a model has never had to live with.
I have made every one of those decisions on this platform myself. Security posture, data model, what gets logged, what never leaves the tenant, where the guardrails sit, what the product refuses to do. That is the part of the work that is mine, and I notice it is also the part that most closely resembles being a CFO.
The uncomfortable implication
If you are a finance leader reading this and waiting for a vendor to bring you a demo, consider that the demo will tell you what the vendor wants you to know. Ten hours of building something yourself, however small and however badly, will tell you more about what this technology can and cannot be trusted with than a year of watching presentations. It also makes you much harder to sell to, which is its own return.
I will not pretend any of this is new. It is what I was doing as a CFO with a team in Mumbai and a boss several time zones away. Write the brief properly. Check the work where a mistake can hurt you. Never sign anything you have not understood.
What has thrown me is how little of the last eighteen months has felt like learning engineering. I sat down to learn to build software. Most days I find I am just managing again, with a team that never sleeps and never remembers. I have not decided yet whether that is a comfort or a disappointment.