Skip to main content

How AI Is Changing Python Development in Excel

· 8 min read

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

In practitioner discussions from the two years ending August 6, 2026, experienced developers use assistants for boilerplate, debugging, refactoring, and unfamiliar APIs. Excel power users use them to translate an existing formula, Power Query, or VBA workflow into Python. Some non-programmers describe the business process in plain language and iterate on generated scripts until the result is reliable enough to keep as a reusable tool.

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 research actually shows​

A manually coded subset of 12 practitioner discussions that explicitly identified a code source produced this overlapping pattern:

Code-sourcing patternDiscussions mentioning itShare of 12-discussion subset
External chat or agent tools, principally ChatGPT and occasionally Claude867%
Integrated Copilot in Excel542%
Primarily self-written or manually adapted code650%
IDE or desktop coding assistants217%

These categories overlap. One person can use Copilot for a formula, ChatGPT for VBA, and an IDE assistant for a larger Python project. The sample is purposive and self-selected, so the percentages are not market-share estimates.

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.

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 describes workbook editing, formulas, charts, PivotTables, and Python-backed advanced analysis. Advanced analysis can create a separate analysis sheet and insert the Python used for the work. That makes the result more inspectable than a prose-only answer, while avoiding the copy-and-paste loop for bounded analysis.

Official references:

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.

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 application.

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 application. 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 application
    ↓
Operator uses deterministic behavior

See AI authoring for the current product behavior and Building applications for the application contract.

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 based on the same August 6, 2024–August 6, 2026 practitioner review summarized in What People Actually Use Python in Excel For. The research emphasized Reddit, Stack Overflow, Microsoft Tech Community/Q&A, GitHub product issues, and official documentation.

The 12-discussion code-source subset is small, purposive, overlapping, and self-reported. It supports qualitative observations about development workflows; it does not establish tool adoption, market share, productivity gains, or error rates across the broader Excel population.