Vibe coding in accounting firms: what actually works in 2025

MacBook Pro on top of brown table

Accounting firms are not replacing their general ledger systems with AI-generated code. But they are quietly building things their vendors never would, and a handful of them are getting genuinely useful results.

Ellen Choi, founder and CEO of AI consultancy Edgefield Group and former co-founder of accounting practice management provider Aywin, has been inside enough firms to know what separates a working vibe coded app from a prototype that collapses the first time someone other than its builder touches it. Here is what she told Accounting Today’s podcast On The Air.

️ What Firms Are Actually Building

No one is vibe coding a full ERP. Choi is direct about this: the profession is in the crawl phase. The apps being built are narrow, single-purpose tools that live at the edges of existing systems.

The most common examples she has seen:

  • Power Automate scripts written faster with AI assistance
  • Internal OCR replacements that take scans and output trial balance data in a specific format the firm controls
  • Small automation fixes for manual processes the IT team never had capacity to address
  • Internal productivity and collaboration tools with no client data involved

One top 50 firm built a prompt exchange platform using Replit. It lets practitioners share and discover AI prompts across the firm, includes gamification features, and has driven meaningful internal engagement. There is no proprietary client data in it, which makes it a low-risk first project and a good model for other firms to copy.

3D rendered ai text on dark digital background

The Build vs. Buy Calculus Is Not About Cost

Choi’s team vibe coded Edgefield’s own AI learning hub. Her conclusion after going through the process: it was not meaningfully cheaper than buying a vendor solution.

“I don’t actually think it was any cheaper. That’s my conclusion.”

What practitioners are actually getting from vibe coding is specificity, not savings. Choi describes the pattern she hears repeatedly from firms: the vibe coded tool has roughly 70% of the features a vendor would offer, but it’s exactly the 70% they need. The other 30% from a vendor package would have gone unused anyway.

The real driver is that vendors build for scale across thousands of customers. They cannot customize every workflow edge case. For a firm with a very specific internal process, the market size is one or five. No vendor is building that. Vibe coding fills the gap, and if the cost is roughly neutral, it’s a win.

️ How Choi’s Team Built Their Platform

Before writing a single line of code, Choi’s team spent significant time with Claude discussing backend schema and database structure. Her reasoning: that is the hardest thing to fix if it’s wrong from the start.

The process involved:

  1. Writing detailed product requirement documents before touching any code generation tool
  2. Using Claude Code to work through backend architecture and data schemas
  3. Bringing in multiple engineer advisors to review the vibe coded output periodically, not full-time
  4. Switching to Lovable for interface generation and front-end wiring

Choi names Lovable and Replit as the leading tools firms are using right now. The upfront architecture investment is what she credits for making the actual code generation phase move quickly once it started.

lines of HTML codes

⚠️ What Goes Wrong

Vendors have classically trained engineers reviewing AI-generated code, running security audits, and enforcing scalability standards. A practitioner who vibe codes a tool has none of that. They don’t know what they don’t know.

The specific failure mode Choi describes: the app works perfectly for the one person who built it, for the one workflow they had in mind. The moment someone else uses it, or the use case shifts slightly, it breaks. Vibe coded apps without engineering oversight are brittle by default.

Security and deployment are the other gap. Getting a vibe coded tool from working prototype to something that can be deployed within a firm’s governance framework is a real jump. Vendors ship enterprise-grade products out of the box. A practitioner’s vibe coded script is not that.

There is also an organizational risk. Choi flags the worst-case pattern: practitioners building tools on the side, without IT knowledge, without a firm-wide policy, in a gray area nobody has defined. Accountants generally want to follow the rules, she notes, but if there are no rules, no one knows what they’re allowed to build.

✅ What Good Looks Like

Firms doing this well have three things in place before the first line of code gets generated:

  • A sanctioned environment. Specific tools like Replit are approved, licensed, and available to practitioners. There is no ambiguity about which platforms are allowed.
  • IT or AI team involvement from day one. Not oversight after the fact. A technical person is in the loop during ideation and build, providing the human engineering judgment the AI cannot.
  • Firm-wide AI governance policy. A written policy that defines what is and is not allowed. Choi is explicit: you cannot layer a vibe coding initiative on top of the absence of one.

The goal is an app that, by the time it’s done, is already in a shape that can be shared, reviewed, and scaled across the firm rather than siloed with its creator.

Where This Is Heading

Choi’s read on the trajectory: this is not a short-term trend. She describes watching accountants learn markdown files and GitHub workflows through the Microsoft Copilot and SharePoint agent ecosystem. They’re becoming more technical without necessarily thinking of it in those terms.

Her prediction is that practitioners will increasingly wear an engineering hat, not as a replacement for software professionals, but as better product managers. When you understand how to build something, even roughly, you write better requirements for the engineers who build the real version. That feedback loop is new, and it is valuable.

The vendor risk she identifies is concentrated in specific categories. Tools that compete primarily on OCR and document classification are exposed, she argues, because those capabilities are now available directly through prompting in Claude, Copilot, or similar tools. Vendors selling deep workflow-specific, regulated features have more protection for now. Systems of record built around secure data ownership are harder to displace.

She also points to a rising services category: vibe coded app support, migration, and maintenance. That’s a new class of competitor that vendors have not had to account for before.

Advice for Firm Leaders

Choi’s framework for getting started without making expensive mistakes:

  1. Build AI literacy first. Systematic education across the firm before anyone touches a code generation tool. Most people who say they want to build an AI agent cannot explain what they mean by that.
  2. Write a governance policy. Before anything else. Define what is allowed, what platforms are sanctioned, and what data cannot be used.
  3. Max out the base LLMs before vibe coding. ChatGPT, Copilot, Claude. Practitioners can solve a lot of problems with prompting before they need to generate any code.
  4. Run hackathons and innovation days. Make vibe coding visible, social, and low-stakes. The practitioners who are already AI-curious can teach the rest.
  5. Get the right human in the loop. Not just any human. Someone with enough technical judgment to tell whether the thing that was built will still work in six months.

The crawl-walk-run framing matters here. The firms that skip to running, without the governance, the AI literacy foundation, and the engineering oversight, are the ones generating prototypes that break and then calling a vendor to clean it up.

Stay on top of AI & Automation with BizStack Newsletter
BizStack  —  Entrepreneur’s Business Stack
Logo