This is what I wish someone would have told me:

What do we get wrong in the beginning?

People start using AI like a search engine. They run ad hoc financial models through browser prompts. This leads to to a lot of mess, disconnected context, and unverified input files. The challenge is that there is no permanent place for a web chat to hold contextual information. It does not have access to your files and does not know your folder structure or your historical analysis. It cannot cross-share or reference data. Every session starts from limited context, so you spend a ton of time re-explaining your business context to it.

What changed the game for me?

An integrated development environment (IDE). I have used Claude Code and Cursor. However, I am sure Codex is equally relevant. There are many options and it genuinely does not matter which one you pick as your core operating system. These are one-stop shops that can read your local files, connect to your data warehouse and read your schema. They execute commands on your laptop and in your terminal. They can run multiple agents doing a job once or recurringly.

What they still need is a clear set of instructions and active review and audit of everything they deliver. That is the part of the job that has not gone away. Refer to my deep dive on this topic. This first step needs limited permissions. You just need to procure one of these IDEs and then play around with it.

What turns it into a system?

Everything so far makes you faster on your own. It does nothing for anyone else, because an agent has no memory. There are two ways of fixing that:

• Connecting to your own data needs a set of MCPs. One to your financial database and maybe one to your data warehouse. That is super critical, and it is not something you do alone: it means data engineering, a security review, and procurement. For example, Snowflake MCP.

• The repository structure to organize everything. The structure is the part people underrate. A repository is where the context lives instead. It is like a shared intelligence engine for your company. You create one structure, and everyone copies it: shared folders, team folders, and space for everyday work.

Then we need to operate a consistent rhythm. You start the day by pulling the latest context out of it or “The Pull”. You finish by pushing the work you have done back in, so it is backed up and can be audited “The Push”. Every time you pull, you get new skills and context somebody else built. Every time you push, you are doing that for them.

How do you stop the cost running away?

This is critical and does not always get sufficient attention.

A lot of day-to-day tasks are straightforward such as “Summarising a document”. “Answering a question with basic search”. You do not need an advanced model for these tasks. Keep a lower capability model as the default and use the expensive ones only as an escalation path. When to escalate requires judgment and there is no fixed rule. It is a function of how complex the problem is and how nuanced the topic is. Summarising documentation sits at one end. Asking why revenue performance is behind sits at the other.

This matters because of the token-maxing era we have just been through. You obviously still need budgets per person. However, having a budget means people can max the budget. You still have to make sure teams know how to manage this through training and guidance.

How would this look in practice?

You pull the latest context from the repository. >>>>

You identify a problem worth solving. >>>>

You work with an agent on it and it produces the analysis. >>>>

You verify the calculation and audit the numbers, because you retain accountability for any number you put your name to >>>>

Once verified, you commit it to the repository and push it. That is where the compounding comes from, and it only works if people actually do the last step.

Where would I start reading?

If you have never used a repository, start with the resource a beginner’s guide to GitHub. The Claude Code best-practice documentation is great for IDE best practices and is also relevant for other tools such as Codex. For the common pattern across tools, GitHub’s Copilot customisation cheat sheet is very helpful. However, how to apply these skills is covered in OpenAI’s guide on identifying and scaling use cases . It is great for new ideas.

Lastly, two other useful resources: While The Pragmatic Engineer and Lenny’s Newsletter are product and engineering publications, they have up-levelled my thinking more than anything written for Finance per se. That is not a coincidence. The tooling for most of these was built for those functions first and it is why their material is still very helpful if you want to be ahead of the curve.

So what should you do next

Start with the IDE. Everything else follows from there.

Why might product / engineering roles be ahead of the curve?

The disruption is a lot more prominent in product management and engineering, and the reason is not that those functions move faster. The AI toolkit was built with them as the ideal stakeholder in mind. Other functions only started to see real utilisation this year.

OpenAI published its own internal numbers in June. Their engineers moved to agentic tools as their primary way of working by December 2025. Legal, finance and recruiting crossed the same line around April 2026, four months later, although once they started the shift ran faster. This is inside the company that builds the tools, where there is no procurement cycle, no security review and no licence to argue for. Finance was still four months behind engineering. Their own explanation for it is the one above: the tool began with developers, who were the natural audience for what started as a coding product.

Source: OpenAI, "How agents are transforming work", 25 June 2026.

That sequencing matters more than it looks. Most tech companies have understood that they need to be ahead on AI. They are starting with product and engineering first, because that is who the tools were built for. After that it really comes down to the CXOs and their willingness to drive adoption across functions.

What do the job advertisements actually say?

I have been tracking finance postings across the public job boards of 307 tech companies. Among the companies whose full posting text is available, 72.8% mention AI somewhere in the ad. Finance is not behind on asking.

The gap is in what is being asked for. Running the same parser over product management postings from the same companies in the same week, about half of the AI-mentioning product ads put AI in the responsibilities section, against less than a third of the finance ads. The requirements sections are nearly identical. Finance job descriptions describe AI as a qualification. Product job descriptions describe it as a job.

Also unlike product managers, there is no such thing as an AI Finance Manager. I have been tracking finance postings across the public job boards of 307 tech companies, which skews to venture and growth-stage tech.

What does it mean for interviewing?

A company can be genuinely ahead on AI in product and engineering and still have a finance function where nothing has happened. That is the opportunity.

If you are coming to the interview and saying you use AI as a chat function, you have already lost the AI value proposition point. Chat is something that a person who is not even working in finance, or engineering, or in tech can do. It is super, super basic, and it does not give confidence that you are ahead of the curve.

That is how people are winning these interview races right now. Some people are able to prove their ability to adopt AI natively, and there are people building real expertise.

What happens next?

Over a period of time companies will start to become more sophisticated in their job descriptions, and you can see that that is how product management went. Currently the finance job descriptions are a little bit lighter. They will become stronger and more fine-tuned in terms of specific skills as well as tools, instead of just saying build with AI. Because of the scarcity of talent, the people who were first keeping up with these tools and are now developing real proficiency in them will be able to command a premium.

Over a period of time that scarcity will go away, as more and more people learn, and a baseline expectation will be set for these skills. They will become like Excel, or financial modelling, or SQL. SQL is a good example in finance. Finance managers and finance teams did not even have SQL seven or eight years ago, and as finance tools got more data-intensive it became a very strong enabler. Now most people are expected to have it, and mostly nobody is paid extra for it.

However, in the near term I do expect a distinct premium for AI skills and that is an argument for moving now rather than later.

In the next few articles, I will recommend some resources that I have found to be particularly helpful in learning AI for Finance.

• Protecting credibility through Audit in the AI era.

• Leveraging scaling and automation to compress the other steps.

Auditing

Auditing is not a new discipline and existed long before LLMs. If you have worked in FP&A, in banking, or in corp dev, you probably had a manager who trained or grilled you until you learned to audit your model comprehensively. So, what is different with an LLM? What has changed is that we now operate at a much higher level of instruction and abstraction.

A financial model can be inspected cell by cell. The logic is visible and the source data is clear. However, when you ask an LLM to do a cohort analysis or a variance analysis, traceability becomes substantially harder. In fact, mostly, you have to explicitly demand traceability and verification from an LLM.

This can be a hard lesson to learn. I have seen an analysis walked back after the wrong conclusion had already reached senior leadership. It was a very important topic and that made the analysis failure even more painful for that team.

Where the whole process broke was not the analysis per se, but insufficient audit. The team relied on the LLM’s ability to run the numbers, and the output supported a hypothesis a leader already held. So they ran with it, because the conclusion also confirmed what the room already believed. Nobody interrogates a number that tells them they were right :). That step is reserved for numbers that directionally look wrong.

So how do I approach it? Here is my audit template:

Foundational checks, for every analysis:

• Make sure you did the Control step during the definition phase well. (check Part 1 for details)

• Check the metric / calculation to the aligned definition. If there is no agreed definition, that is the first thing to fix.

• Have the LLM show how the calculation implements that definition, and verify it

• Inspect the query or formula behind any critical numbers

• Calculate one important figure yourself to verify

• Reconcile to the right authoritative source: closed accounting books for financials OR data warehouse for operational metrics like pipeline

• State period, currency, FX basis

• Separate fact from inference. Label hypotheses as hypotheses

How deep you want to go with these checks requires judgment. You can always pursue additional checks for very high impact work. Everything above, plus:

• Start a fresh chat with only the raw data and the question. Do not show it the first answer. Otherwise you risk anchoring the second review on the original reasoning.

• Human peer review by someone who can audit the SQL query, not just the findings. Usually someone in Analytics, but the qualification is the skill, not the team

• Falsification: what would make this wrong? Go check that

Red flags, stop and verify:

• Round numbers that are unlikely

• Percentages that do not reconcile to the underlying counts

• A metric that changed definition mid-analysis

Most importantly, ownership applies at every level. Whoever runs the analysis signs off on it. They decide how far to take verification and they carry the confidence. Going deeper is an incremental investment and a judgment call, not a rule.

Scale and automate

Scaling and automating shrinks every step in the sequence. A definition agreed once and kept in a central .md file makes the next problem faster to define. A packaged analysis makes the next one faster to run, and lets a peer find it before they rebuild it. We need to stop treating each analysis as a one-off, and this is one of the biggest ways to create leverage through AI.

A new agent does not have memory. It can only rely on repository rules and skills that are centrally available, so anything you do not write down dies with the chat. This is where the decision spec from Part 1 comes back. Not all four of its layers may be worth keeping every single time.

The steps I use are: run the analysis, audit it, then ask what part of this someone else can reuse. Package that and create a skill out of it. Route definition changes to the person who owns and maintains the central file. Then distribution kicks in and the next person does not start from nothing. However, if everyone starts doing this, how do you make sure that there is a level of fidelity and credibility to what is being pushed centrally? This is where the approval process comes in.

On approval, the rule is clear. You audit your own work. However, if you are going to build something that is going to get used centrally or by your peers, it should get a second pair of eyes before it gets shared.

However, it is easier said than done. This is not guidance you share in one meeting. It needs consistent training, office hours by experts, and to be brought to the team in a format that they can absorb without overwhelming them. And it is worth being honest about the size of it. This is overwhelming for every single person, and that makes it tricky.

The flywheel

Early on the audit and analysis steps are heavy, and they are heavy because the scale investment has not been made yet. Every output is bespoke, so every output gets defined and audited from scratch. However, if the leaders start early to invest in scale and automation then every other step shrinks. That frees time for problem definition, and for the higher-impact problems you were not getting to. Which is why this is not really a sequence. What you scale and automate at the end feeds back into the problems you pick, and into how you define them next time.

Finance and strategy and similar analytics roles are going through a critical transition in the age of AI, where the role itself will change substantially. The generation before us had to adjust to the move into Excel. My generation never had to do that. However, this AI transition is our version of it.

People who are on the frontier of taking advantage of this transition will not only retain their jobs better, they will command a higher compensation premium in the market. They will be the most sought-after finance professionals for the next few years. This is going to be the topic of my next post.

While analysis has gotten easier and faster, some things have become more challenging. I would argue that two weeks came down to two hours only because you are not doing some of the other tasks, problem definition, auditing, scaling, as well as you could be. The time to analysis compressed. However, the work around it has not disappeared and might have gotten more complicated: deciding which problem to solve, defining the problem, and auditing.

I have seen first hand that leaders have already burned their hands in many cases. They took AI outcomes that were not audited sufficiently, drew the wrong conclusions, communicated the insights, and lost face. This has led to a more realistic tempering of their expectations to what is achievable. There is time being saved. However, the question is: Where should the freed time go?

An ideal sequence would be »»»» pick the right problem to pursue »»»» define the problem »»»» run the analysis »»»» audit it effectively »»»» and then scale and automate what you learned.

AI has compressed the middle step. The time it frees needs to go to the steps around it: defining the problem better so that AI can absorb it, auditing the output, and converting the analysis into something your team can reuse. If time still permits, expand the number of problems. People sometimes make the mistake of taking that path first, working on more problems and skipping the other tasks, and that is the core challenge in the AI era.

This part of the newsletter covers the first two steps: Picking the right problem and Defining the problem well.

How do you pick the right problems?

This is not new. It is the same discipline as before AI came into play: identifying problems that are worthy of your time and the ROI. I always tell my team to think through three questions.

Am I the right person to solve this?
If you have received a problem, are you the right person to solve it, or could you delegate it to a team member better placed?

Has somebody already solved it?
If you are the right person, has one of your peers already solved it? Take advantage of that before building anything.

Is it worth your time?
Is this the highest-impact problem you could work on within your constraints and against the list of problems you already have?

Someone has to gate the flow. Usually that is you: the one running the analysis, the manager of the team, or the director or VP setting the tone for the context the team operates in.

Is the gate temporary or permanent? Only time can tell. People must have had the same challenge with Excel modelling once, whether they could trust it, and over a period of time enough trust built up that it could be managed. AI workflows are still in early stages of development. We need the gate until we can be confident in not only the robustness of the workflow, but the capacity of people and stakeholders to understand the challenges.

How do you define a problem so AI can absorb it?

A lot of focus today goes into building prompts and agents, and very little into defining problems well. Finance can take inspiration from product management here. Most prompts look like a task: “Do variance analysis”, “Create a deck that does….”, and “Summarize XYZ”. The task is not the problem.

Take a request like: analyze pipeline coverage by account and tell me whether we have enough pipeline to hit quarterly quota.

There is nothing obviously wrong with it. That is the problem. AI has to fill in almost everything that matters.

• What does coverage mean?

• At what level should it be calculated?

• Which opportunities are eligible?

• Should open pipeline be weighted, and at what probabilities?

• What counts as insufficient?

• Which data is authoritative?

• Can it infer a missing assumption, or should it stop and flag it?

I use a 4-part structure for this, and I call it a decision spec. The inspiration for starting with decision-first comes from Google’s decision-intelligence work, and the analysis and task framing from Google’s ML problem-framing guidance. Google has done a lot of incredible research in this area. The Control layer is my addition to ensure the framework is suitable for Finance and Strategy roles. The first three parts define what you are delegating. Control defines what you are not.

What I would leave you with

When analysis gets cheap, the critical thing is to protect the time investment. Getting better at problem definition, at auditing, and at working on the right problems matters more than ever before. Everyone knows the analysis has gotten cheaper, and the expectation will be simple: the cohort model takes a few hours instead of a week, so why are you not doing 100x? The honest answer is the work around the analysis. More importantly, it is critical not to compromise on the credibility of the analysis, and the work around it helps you do that.

Part 2 covers the other side of the sequence: auditing the analysis, and scaling and automating it, so you can continue to scale the wins.

Appendix (Full Prompt ready to Copy)

Decision.
The Finance Director and Sales VP need to determine whether current pipeline is sufficient to achieve this quarter’s sales quota, and identify the regions, territories and accounts where intervention is required while there is still time to influence the quarter. Prioritize issues that could materially change the quarterly outcome.

Analysis.
Use the following analytical logic:

• Calculate coverage primarily at account level and roll it up to territory and region

Remaining Quota = Quarterly Quota − Closed Won this quarter
Pipeline Coverage = Eligible Open Pipeline expected to close this quarter ÷ Remaining Quota

• Calculate weighted pipeline coverage using the approved stage probabilities: X, Y and Z

• Use document X for coverage targets; do not invent a target if none is provided

Determine:
(a) where coverage is insufficient
(b) the absolute pipeline gap
(c) whether risk is caused by insufficient pipeline, late-stage concentration, slippage, or dependency on a small number of opportunities
(d) how much additional qualified pipeline would be required to reach the target

AI Task.
Perform the following tasks:

• calculate the metrics above for every account

• flag accounts and territories below the approved coverage threshold

• rank them by potential impact on quarterly attainment

• identify the opportunities contributing most to each gap or concentration risk

• roll the findings up by territory and region

Produce a table showing: Account, Quota, Closed Won, Remaining Quota, Eligible Pipeline, Weighted Pipeline, Coverage, Coverage Target, Pipeline Gap and Risk Driver.

Then provide the five issues management should inspect first, explaining why each matters.

Control.
Perform the following control checks:

• Validate the analysis before presenting conclusions

• Reconcile total Closed Won and Open Pipeline to the source CRM data, and total quota to the approved quota file

• Use only opportunities with a close date inside the quarter unless explicitly instructed otherwise

• Do not infer missing quota, stage probability or opportunity status

• Flag missing or inconsistent data rather than filling it in

• For every material risk callout, identify the opportunities and data underlying the conclusion

• Clearly distinguish calculated facts from AI-generated interpretation

• AI may identify and prioritize risks, but it must not change the forecast, CRM data, quota, pipeline stage or management target. Those remain human decisions.

How do companies decide where to look?

All companies are different and the approach varies based on size and culture. However, I will share how I have seen this happen front and center. Three flags come up again and again in various discussions.

Token consumption is the first. If most of the incremental AI budget sits with one function, the question writes itself: are there productivity gains, and where are they showing up? Usage is not impact. However, it is where the scrutiny starts.

The nature of work is the second. Transactional, rules-based work with little need for long-term context or judgment gets examined first. Relationship-heavy, judgment-heavy work is harder to automate.

The third flag is peer pressure: Folks underestimate how much peer pressure companies face and how that gets compounded by Wall Street / shareholders. You just have to see quarterly analyst call transcripts to see pointed questions like “Intuit just laid off people in X department, what opportunities do you see?”. Companies are closely watching what their peers have automated and which functions they have reduced. Peer behaviour proves nothing about your own productivity. However, it increases a company’s conviction.

How is assessment done?

I have been in these rooms and the pressure to show results is high. Many companies are running multiple pilots to test whether there are any savings without compromising on the North Star metrics. For example, whatever the function’s North Star is, customer satisfaction, roadmap delivery, forecast quality, can it hold at roughly that level while the cost falls materially? If customer satisfaction drops from 95 to 90 while the cost of the function falls 20%, that is a trade leadership will seriously consider. Not perfect automation. An acceptable outcome at a materially lower cost.

Sometimes, the companies are more aggressive and willing to go deeper in HC cuts, beyond what the pilot results showed, and it comes with its own risks. Case in point: Klarna had to reassign engineers and marketers to customer support after its AI bet went too far (Business Insider). This is what happens when you do not have any margin of safety and want to showcase your aggressiveness, which can harm the business in the longer-run.

When companies do not cut?

I have also been on the other side of this review. The function was mine. I was leading FP&A and the function was clearly seeing productivity improve. The team was spending visibly less time on transactional reporting and automation work. However, Leadership chose not to reduce HC, because the freed capacity moved into strategic, judgment-heavy work the company wanted more of anyway. The ROI showed up as more output that the company needed, not fewer people. However, nothing is permanent. These reviews recur, and what was safe this cycle is up for scrutiny again the next. Surviving once does not mean it cannot happen again.

Who makes the call, and what makes them move?

These reviews are top-down. Either group leadership is asked to find reduction opportunities, or the CEO and CFO arrive with specific functional mandates. Finance drives and evaluates the analysis underneath the decision. If you sit in finance, you are not watching this process. You are running it.

Speed comes down to two things: the quality of the evidence and the shareholder / market pressure on the company. Solid data and no pressure lets you capture gains gradually, without taking undue risk. Weak data and heavy pressure is the dangerous quadrant, where cuts run ahead of evidence, especially when peers are announcing AI-driven reductions.

Which brings up the noise. Some layoffs attributed to AI are ordinary restructuring, overhiring being corrected, wearing an AI narrative. While sophisticated competitors who do their diligence can tell, the shareholders might not, thereby sending a signal to the market.

What I would leave you with

AI does not decide the headcount plan. Leadership places a bet under uncertainty, and companies are no more rational about these decisions than markets are about stock prices. Some bets get proven wrong quickly. Some take years.

If you run a function, two questions matter: Is there real demand for the capacity AI frees up in your team? Can your function hold its North Star while costing less? Whoever has good answers is not waiting for the review. They’re the one running it.

Appendix