How AI Is Changing Python Development in Excel

A qualitative look at how coding assistants are changing Excel automation: faster implementation, more accessible Python and VBA, and stricter testing needs.

AI is changing Python-and-Excel work less by making spreadsheets autonomous and more by changing who can build deterministic automation.

In the public practitioner discussions linked below, users describe asking assistants to write or revise VBA and Python, troubleshoot syntax and logic, and turn plain-language business rules into repeatable scripts. Some already know enough code to review the implementation; others start from domain knowledge and iterate against real test data. These are recurring observations from a purposive sample, not a survey of Excel users.

That distinction matters: the durable output is often ordinary Python or VBA that can be inspected, rerun, tested, and reconciled—not an AI answer that must be trusted every time the workbook is opened.

What the linked discussions show

The source material supports a qualitative pattern rather than a precise adoption statistic:

Observed pattern	What the sources describe
AI as an implementation partner	Users ask ChatGPT, Claude, or another coding assistant to draft VBA or Python, then run the result, report errors, and refine it. See the staff-accountant discussion and an accountant’s invoice-automation case study.
Python around Excel	Several users describe reading and writing workbooks from external Python for batch processing, AI-assisted text cleaning, or file-heavy automation. See Python as a middleman between Excel and Claude and an accountant’s Python automation examples.
AI inside Excel	Microsoft’s documentation describes Copilot workbook edits and an advanced-analysis workflow that can create a separate sheet with Python-backed analysis; those capabilities are product-specific and availability-dependent. See Copilot data analysis and Python in Excel availability.
Human-owned rules and review	The discussions consistently treat domain knowledge, testing, and review as the user’s responsibility even when the assistant writes much of the syntax. An Excel AI-tools discussion is a useful counterweight to vendor claims because it includes both use and skepticism.

The useful finding is behavioral: AI assistance and self-written code are no longer opposites. In many workflows, the user still owns the logic and testing while an assistant supplies a growing share of the syntax. The linked discussions are self-selected anecdotes, so this article does not turn them into percentages or market-share estimates.

flowchart LR
    A[Business requirement] --> B[AI-assisted draft]
    B --> C[Inspectable Python / VBA]
    C --> D[Test data]
    D --> E{Correct and reconciled?}
    E -->|No| F[Error / result back to assistant]
    F --> B
    E -->|Yes| G[Reusable deterministic tool]

External chat tools: describe, run, debug, repeat

The most detailed automation stories in the reviewed sample often follow a simple loop:

1. describe the process and representative inputs;
2. ask for Python or VBA;
3. copy the code into the real execution environment;
4. run it on test data;
5. return tracebacks or unexpected output to the assistant;
6. refine the code;
7. retain the final script as a normal software artifact.

That workflow is attractive because an external assistant can discuss Python, VBA, SQL, command-line behavior, PDFs, APIs, and file-system errors in one place. It is particularly useful when the automation extends beyond Excel.

One property-management controller described using ChatGPT and Python for invoice processing. The user reported adapting a base template to six vendors, identifying roughly ten more candidates, and uploading a 400-invoice monthly batch in roughly 3–4 minutes. That is an anecdotal, user-reported result rather than an independently measured benchmark, but it illustrates the pattern: a domain expert specifies the workflow, AI helps write the implementation, and the output becomes a repeatable script.

A separate staff-accountant discussion emphasized using AI to build deterministic tools rather than asking a model to inspect a workbook and provide an unverifiable conclusion. The accountant supplies the requirements and reviews the resulting automation; the assistant handles much of the technical writing.

Integrated Copilot: less copying, more workbook context

Integrated Excel assistants solve a different friction problem: context and execution can stay closer to the workbook.

Microsoft’s current Copilot documentation distinguishes direct Python-backed analysis from an advanced-analysis mode. Direct answers can expose the generated code, while advanced analysis opens a new sheet, runs Python, and lets the user modify or insert the underlying code as a refreshable Python cell. That makes the analytical path more inspectable than a prose-only answer while avoiding the copy-and-paste loop for bounded workbook analysis. Availability still depends on the relevant Microsoft 365 product, client, and licensing context.

Official references:

• Get direct answers to your data analysis questions
• Frequently asked questions about Copilot in Excel
• Introduction to Python in Excel

The tradeoff is that integrated analysis operates within the product’s supported workbook and runtime model. It is not a substitute for an external automation that must walk local folders, process arbitrary documents, run on a server schedule, or coordinate several desktop applications.

Deterministic tools versus model-generated conclusions

For consequential spreadsheet work, this is the most important architectural distinction.

Suppose an accountant needs to reconcile two systems. There are two very different requests:

Request A: “Look at these files and tell me whether the accounts reconcile.”

Request B: “Write a script that joins on these keys, applies these tolerance rules, produces an exceptions table, and proves that source totals reconcile to output totals.”

The second request creates something that can be:

• reviewed before use;
• tested against known cases;
• rerun next month;
• version controlled;
• reconciled independently;
• logged when inputs are malformed;
• handed to another maintainer.

An LLM can still make a business-logic mistake in the generated code. The advantage is not that generated software is automatically correct; it is that the logic becomes explicit and testable. That review requirement is visible in the Excel AI-tools discussion, where users describe plausible-but-wrong suggestions, security constraints, and the need to double-check outputs. The thread is anecdotal, but it is a useful counterweight to treating code generation itself as validation.

The domain expert still has to specify the rules

AI is weakest where the prompt silently assumes business knowledge that has never been made explicit.

A model cannot safely infer organization-specific rules such as:

• fiscal-calendar conventions;
• entity and account mappings;
• sign conventions;
• revenue-recognition treatment;
• which duplicates are legitimate;
• missing-data policy;
• outlier handling;
• forecast horizons;
• acceptable reconciliation tolerance;
• when a human approval is required.

The strongest practitioner stories are therefore not “AI replaced the accountant/analyst.” They are examples of a domain expert converting tacit knowledge into a specification and using AI to accelerate the implementation.

What minimum skill does the user still need?

A person does not need to become a full-time software engineer to benefit from AI-generated Python. They do need enough literacy to recognize dangerous or obviously incorrect behavior.

At minimum, recurring business automation owners should understand:

• data types and missing values;
• DataFrame filtering, joins, and grouping;
• functions, parameters, and return values;
• file paths and overwrite behavior;
• exceptions and tracebacks;
• the difference between test and production inputs;
• how to compare totals before and after a transformation;
• how dependencies and credentials are supplied.

This is also why a generated script should become maintained organizational code once it supports a recurring business process.

A review pattern for finance and accounting automation

For high-impact workflows, ask the assistant to produce controls along with the implementation.

A useful checklist is:

1. Define inputs and outputs. State schemas, required columns, units, signs, and allowable missing values.
2. Make assumptions explicit. Put mappings, thresholds, and dates in configuration rather than hiding them in prose.
3. Add assertions. Check row counts, uniqueness, ranges, and required totals.
4. Preserve source records. Never overwrite the only copy of an input file.
5. Log exceptions. Skipped or malformed records should be visible.
6. Reconcile. Compare source and output totals with documented tolerances.
7. Test known cases. Include both expected successes and expected failures.
8. Version the code. Record what changed and which version produced an output.

The AI can generate much of this scaffolding. The owner still decides whether the controls prove what the business process actually requires.

Where Boardflare’s notebook AI fits

Boardflare uses AI on the authoring side of a workbook-connected notebook.

The notebook assistant is instructed on the public workbook API and marimo’s reactive programming rules. Depending on the authoring action, supplied notebook context can be used to create cells, revise a selected region, explain code, or provide inline completion.

The assistant does not become the runtime for the notebook. It does not receive an unrestricted tool that can execute arbitrary notebook code or mutate live workbook state on its own. The durable artifact remains inspectable notebook source plus explicit workbook inputs and published outputs/functions.

That creates the same pattern seen in the strongest practitioner evidence:

Author intent
    ↓
AI-assisted implementation
    ↓
Inspectable reactive Python
    ↓
Validation and testing
    ↓
Saved workbook + notebook source
    ↓
Operator uses deterministic behavior

See AI authoring for the current product behavior and Designing notebooks for the notebook design guidance.

What to expect next

AI will continue reducing the amount of syntax a spreadsheet expert has to write manually. That does not remove the need for architecture, validation, or domain ownership. It makes those disciplines more important because more people can now produce code quickly.

The most useful question is therefore not “did a human or an AI write this Python?” It is:

Can another person inspect the logic, reproduce the result, detect bad inputs, and maintain the tool when the business rule changes?

That is the standard that turns AI-assisted code generation into dependable spreadsheet automation.

Methodology and limitations

This article is a qualitative synthesis of a purposive set of public practitioner discussions and official documentation. Representative sources include Python as a middleman between Excel and Claude, an invoice-processing case study, an accountant’s automation examples, how a staff accountant uses AI, and Excel users discussing AI tools at work. The sources support qualitative observations about development workflows; they do not establish tool adoption, market share, productivity gains, or error rates across the broader Excel population.