I Vibe Code. You Probably Shouldn't (Yet) — What Accountants Need to Get Right First

Dave Sellick — Founder, Siggrove

Jonathan Gaunt — Founder, Socket (formerly FD Works)

03:52Who we are and why this session exists

Dave: Hi, I’m Dave. I run a practice called Siggrove in London, UK, and I work with around fifty or sixty clients. I’d probably describe myself as more of a portfolio head of finance than a traditional firm. What I’ve been trying to create over the last six years or so of building the firm is a view of where the future of accounting goes — more of what we’d refer to as advisory-led. I do a lot of work with technology and pushing the boundaries of that, which is why I’m speaking about this today.

Jonathan: I’m Jonathan Gaunt. Similar background to Dave. I started life as a chartered management accountant and worked in corporate for nearly twenty years. In 2012 I decided I wanted to work with small businesses, and a lot of that came down to the question of how you create a finance function for a small business. The root of that was a lot of technology. I turned to a client one day and said, “I wish you could code,” and that’s where we spun out Xavier Analytics, which was acquired by Dext — and it’s partly the reason we’re now building Socket. At the heart of it, I love data, I love processes, and I’m a little bit lazy, so I’m always looking for a way to put a spreadsheet behind something if I’m doing it more than once.

Dave: This was originally a session just with me, but I thought Johnny would be a good person to have on because he’s coming from a legitimate development background, having actually built and run apps. He brings his practitioner head into it as well as effectively running a tech team. We’ve got a few slides to set the context and some of our views on vibe coding and GenAI, and then we’ll go into some of the things we’ve built — and we’ll build something live as we go.

07:00The “you’ve got 449 days left” narrative

Dave: The session is called “I Vibe Code, and You Probably Shouldn’t (Yet),” so it’s going against the grain of the general narrative out there, purposefully. Before we get into it, I want to address why we’re even doing this at all — because, you know, we’re done, right? How many days do we have left as accountants, Johnny? According to some, four hundred and forty-nine days. There’s a very prevailing narrative from a lot of tech companies, AI companies, politicians, thought leaders and influencers that our days are numbered — that GenAI is going to automate everything we do, and if we don’t jump on board with things like vibe coding and autonomous GenAI, we won’t have anything left to do.

Jonathan: There’s always something there to scare us. It’s the same as cloud computing — “if you’re not on the cloud…” Certainly from my experience, you’ve still got people walking around going, “You can take a picture of a receipt?” We are so far behind the pace people expect of us that I think we should take this with a pinch of salt. The people telling us it’s the end are the people who want to put fear into us.

Dave: That ties into this concept of “SaaSpocalypse” coming for the accounting tech products we use. There’s a mindset now that anyone can become a coder, anyone can create their own app, and you can just rebuild the apps you’re paying for.

09:41What vibe coding actually is

Dave: Before we go further — what actually is vibe coding? It’s based on the concept that you talk or type using natural language to interact with these agentic GenAI agents that go off and write code for you. It’s a vibes-based approach to code. You don’t need to be technical, you don’t need to be an engineer, and — apparently — you don’t need to understand what’s going on behind the scenes. You can just build apps.

Jonathan: But what’s the difference? You can push a button and submit a VAT return, but we’d all be sitting there going, “That’s not very good, it’s not a certain quality.” Yes, you can — but don’t you need to understand what you’re doing? That’s the thing we keep coming back to: we’re doing it, but we’re doing it in a really careful way.

11:06Why the narrative doesn’t stack up — the GenAI mirage

Dave: I have quite strong opinions on the general narrative towards GenAI, and vibe coding is no different. A lot of the companies and influencers pushing the narrative have a very strong vested interest. Adoption is significant, but it isn’t anywhere near significant enough for these companies to be heading in the right direction on profitability. The further we go, the more fearful the narrative becomes, because in my opinion they become more desperate for adoption.

There’s also what I’ve coined the “GenAI mirage” — the view that GenAI, vibe coding and autonomous AI can take jobs, replace software and replace accountants. It often comes from very intelligent, previously successful people, but they’re making that judgement from afar. They’re not the ones who are hands-on. GenAI has this mirage effect: from a distance it looks like high definition, like the thing that’s going to replace everything. When you’re actually hands-on on the front line, it pixelates. It breaks up. It’s not what it seems from afar.

Something that hit home with me: name me an app or a website that has actually got better since GenAI became a thing. I’ll wait. All I’ve seen is apps and websites becoming more buggy. This is supposed to be a revolutionary generational shift in how we code, so why are we not seeing improvements?

Jonathan: You can throw it out there too — where have you actually got a cost-benefit analysis from the apps you’ve made? Sometimes I’m building something and ask, “Why am I doing this?” I spend hours, I spend weekends building something to throw away an app I’m paying twenty pounds a month for, that’s going to take twenty years to pay back. How quickly do you actually see the benefits, and could you spend your time elsewhere and get more value?

Dave: The last point I’d make holistically: the technology this is based on is economically, environmentally and to some degree socially unsustainable right now. I’m sure we’ll make advancements, but from an economic point of view the key concern is that pricing will go up. Embedding a workflow that depends on a technology that’s currently unsustainable — without a clear path to it becoming sustainable — is something we need to be mindful of.

14:57The real risks: code quality, security and PI claims

Jonathan: What we’re seeing is that it’s very easy to create things. I’ll build something, get sucked in, then come back and go, “Is that right?” I really worry about the quality of the code I’m producing. What happens if I haven’t set it up properly and suddenly one client can see another client’s code? It’s very easy to generate ten thousand lines of code, but then I give it to Rich, Ben or Oliver and they say, “That’s repeated, that’s repeated, that’s repeated.” The way they’d build it, you’d have smaller functions, you’d reuse functions. You just dive in, push go, and it gives you all this garbage — and then it doesn’t work. You ask someone who knows what they’re doing and the answer is, “Should we throw it away and start again?”

Dave: But why is that, if the narrative says this is getting better and can replace coders and accountants?

Jonathan: It comes back to the actual design of the technology.

Dave: It’s an obvious thing when you think about it, but I don’t think many of us think about the reality of the technology that drives this — transformer-based, LLM-driven generative AI. It’s effectively a very, very advanced autocomplete. It does not understand holistically what you’re asking it to do. It breaks everything into tokens, assigns some measurement of importance to them, and then guesses, in a very clever way, what comes next. It doesn’t have intelligence the way we think of it. It can be the most intelligent and the most stupid technology all at the same time.

Jonathan: There’s a bit of snake oil out there — “you can vibe code something production-ready.” Can you? For me, if you’re starting to dismiss engineers, what’s the difference from someone turning around and saying, “You don’t need an accountant anymore”? We’d be offended by that. It’s exactly the same: yes you can, but should you?

Dave: And if you’re dealing with client data, or inviting clients onto the platforms you vibe code, one small slip — a breach — leads to a potential professional indemnity claim. It’s a massive risk. Is it a risk worth taking? If you have a coding background or you’re working with an engineer, you can mitigate those risks, but they are significant.

19:36Where it genuinely helps: replicating existing processes

Jonathan: A spreadsheet has always been my happy place — give me data and I can play around with it. Where I find vibe coding very good is taking an existing process and replicating it. Replicating it makes it simpler, repeatable, and then I can share it with other people. That’s where you see efficiencies. We’ve got seventy-five clients, so if it can save half an hour on a simple process, we’ll build it.

An example: we built something that started as a vibe-coded tool around our VAT returns. Once we’d proved it works, we gave it to a legitimate engineer to build it properly and take away the sharp edges. It’s great for net-present-value cases, great for replicating, great for an existing process where you’ve always got something to fall back on.

We also chose new software purely because it had an API — we chose PayCircle for payroll because it was one of the very few payroll packages with an API. That means if the software doesn’t do something, we can build a solution for it.

Dave: The idea of open APIs, connecting software and creating automations previously required technical knowledge, or felt daunting to accountants. Now you can dive into something like Claude Code and ask it to build that automation, build a platform that connects APIs, or push notifications. I talk a lot about using generative AI to go out and build those deterministic automations — wired-up, consistent, rules-based, watertight — rather than using GenAI to run everything for you.

Jonathan: But if I roll you back two or three years, you were probably doing a lot of this anyway — building spreadsheets, or using something like Make or Zapier to join things together. This is just taking that thinking a stage further.

22:35AI lowers the barrier — it doesn’t change the fundamentals

Dave: A hundred percent. I’m not really changing accounting, but for many people what AI does is open up access and reduce barriers to what the more progressive accountants were already doing. Everyone always said to me, “What you’re doing is great, but it’s not scalable or implementable at scale.” What GenAI does now is give better access to that. You can talk to Claude Code, or Claude, and it walks you through setting up some of these more technical aspects.

Jonathan: How many clients have you got, Dave?

Dave: Around fifty — predominantly full finance function.

Jonathan: And how many in your team?

Dave: It’s just me, but I have teams internal to the client.

Jonathan: So before you even got into vibe coding, you’d demonstrated that with solid processes you can scale and operate a very human side of finance. What’s changed is that it might make some of those processes more robust, because they’re coded and you can control them.

Dave: Agreed. This is why I call people out on “where is GenAI changing everything.” Most of my accounting — if not all of it — still runs on those OG technologies that are deterministic, rules-based, consistent, wired-up, reliable and proven. GenAI is helping in an ancillary way: it helps me build within those tools faster. I haven’t really changed the core of how I run my practice over the last few years.

24:48Dave’s vibe coding stack and a live one-shot build

Dave: Very quickly, my stack. Claude Code is what I use — to get started it’s just a case of going into Claude Code and talking to it. I push all my code to GitHub, which operates like a Google Drive for code: it stores it, and I pull it down on the various computers I work from. From there it connects into a hosting site — in my case Vercel — and somewhere to store the data if your app has data.

Let me show you the process live. I’m going to start the way I start a lot of projects, by grabbing a prompt I created earlier and putting it into Claude’s chat. I’ve asked it to plan out an app I want to build and give me a prompt I can hand to Claude Code. It’s given me a few app options — let’s take the salary versus dividend optimizer, a pretty simple but useful app. “Can you give me a prompt for Claude Code for this app to optimize the build from a one-shot perspective?”

It’s giving us caveats with its advice — basically, “this data may not be correct, be aware” — which is helpful, because it’s basing the app on some hard-coded rates. Now I’ll toggle to the code section, Claude Code. I’ll set it to work in a local folder I created called “AI demo.” You can choose whether it tells you when it’s making changes; if you’re vibe coding with no technical understanding it’s kind of irrelevant, because you’ll just say okay to everything — which is one of the risks. In this instance I’ll bypass permissions.

I’ll also go into the Claude design tool — a tool within the Claude ecosystem that helps you create a brand book so you get consistent styling across everything you build. I’ll share that brand book into Claude Code so we get some styling, then let it do its thing.

29:31Jonathan’s tour: replacing spreadsheets with simple tools

Jonathan: What I’m doing in nearly every case is simply replacing something I’ve already built. Here’s a marginal-rate explainer — how do you explain the marginal rate to clients? I’ve vibe-coded something simple and put it on my website. Is it dangerous? It’s got no client data in it, it’s very simple, but everyone on the team knows where to look, and it doubles as a lead magnet — you put in your details and it emails you the result.

Same idea with the salary and dividend calculator Dave is building. We did ours because there were lots of salary calculators out there but few that put real emphasis on dividends. Then you start thinking, “How do I link this back to my customer journeys?” — so there’s a “what’s the lifestyle you want” tool that reverse-engineers it to “here’s the profit you need.” I’ve got a WordPress website, so I learned how to package this up as a plugin. I understand the logic, I can run tests in my existing spreadsheet to get it back to exactly what I want.

Dave: Is the team using this every day, and what’s the feedback?

Jonathan: It’s consistency, but what I’m really seeing is that it’s raised the learning of the team, and that pushes the conversation forward so I can bring it back and build the next thing. We built something simple around client profitability — some clients were giving discounts or not chasing payments. Previously I’d have built a spreadsheet, then had to replicate and reset it multiple times. This just makes it simple.

32:32Confetti cannons and Google Sheets superpowers

Jonathan: My happy place is still a spreadsheet — specifically Google Sheets.

Dave: What’s your mindset on when you’d choose a spreadsheet over a vibe-coded app now?

Jonathan: I still use a lot of spreadsheets because of the security around them — I’m not sharing them with anyone and everyone. This tool goes into Xero and pulls out the data. You’re all thinking, “Why didn’t you use G-Accon?” We can and we do use G-Accon — this was an experiment.

Dave: For those who don’t know, G-Accon is an app built into Sheets that connects to Xero, QuickBooks and Sage and can pull data down and push it back via the API.

Jonathan: This was a pure frustration of mine — I wanted to build a hierarchy so that when I do the reporting, everything sits in the right place. Part of this is me pushing my own boundaries. Let me show you how simple it is. Dave was using Claude in the chat; I’m using it within a code editor. I started by saying, “Here’s the spreadsheet I want to connect it to,” then, “Can you create me a menu with one option that opens a form with a button and runs a confetti cannon.” The code runs, I use the term clasp push and it pushes across — and hey presto, I’ve got a confetti cannon. I’ve got a normal spreadsheet with a menu of hidden superpowers.

If you’re going to get into this, learn about GitHub — it’ll save you a whole heap of time saving checkpoints as you go. It’s like art: you’ll add something extra and destroy the last two days of work, and that picture will never be the same again.

35:48Back to the live build — and the reality of live coding

Dave: Let’s check on the app. It’s not great at the moment. I asked it to start a preview so we could see it live. The moment we’ve got issues — this is the reality of live coding. Anyone who shows you an app from start to finish in five minutes, that’s not a realistic scenario. There we go — now we’ve got something that looks okay. It’s gone really big on the gradient background, but it’s doing a thing. That was around ten minutes, maybe less.

For context, I haven’t done anything other than put in the prompt I curated via Claude’s chat. It asked what frameworks I wanted; I picked the recommended one. Now we have an app I can open in the browser and start working with. It may not be correct — you’d want to check that — but I wanted to show the process. From here you’d curate it, then say, “Can we host this on Vercel, please?” and let it deploy. That’s how straightforward it is to build a utility app where you haven’t got the client-data risk.

38:03Siggrove Intelligence — a suite built from spreadsheets

Dave: I’ve built utility apps in my suite called Siggrove Intelligence. It started with this product, using my demo company Circle. I wanted my clients to have an app version of their cash flow by contact that updated every morning, in a more visual way than they were getting. This tool interacts with Slack, so my demo company gets weekly cash-flow updates that direct them back to the cash tool. Previously it was a spreadsheet — I gave the sheet to Claude Code and told it to replicate it, which also gives me a backup.

As that worked, I added more: management accounts, year-end working papers, payroll, variances and reporting, month-end schedules, accruals and prepayments posting into Xero, payroll reallocations, deferred and accrued revenue. Most of these were created by giving the spreadsheets to Claude Code.

Jonathan: What’s interesting is you’re filling gaps that existed. On payroll, the core software couldn’t post a journal reflecting different departments or allocations for your management accounts. That’s where it’s powerful — if a feature doesn’t exist, how do you close that gap? It’s about being curious, spending time on what’s in the API, looking at the reports and joining things together.

Dave: A hundred percent — though for me it was less about new functionality. I’ve done a similar thing to you with Google Sheets extensions, because I couldn’t find anything that let me pull from the LLMs in a way I could rely on, so I built my own. I’ve got a sidebar that pulls data from the LLMs, tied into the various assets I use across clients. I’ve also got a G-Accon-style backup that pulls P&L, balance sheet and account transaction data.

41:49Knowing when you’d need a real engineer

Dave: I’ve also built things because I can and because it’s fun, and it’s of huge medium-to-long-term value. I had all these spreadsheets that aren’t particularly scalable, and I wanted to see if I could turn them into a product — really experimenting with where a spreadsheet is impactful versus where something works well as an app, because I now have the opportunity to MVP it.

The key thing: I’m aware that if I were to deploy this commercially or scale it, I’d probably need to rebuild it with an engineer from scratch. In the meantime I’m working with an engineer to make sure the data in here is secure. I do have client data going in. I’ve also done half a year of a coding boot camp and I work with code every day. I’m not a coder, but I understand the fundamentals, and I work with an engineer. I’m only building tools with client data when I’ve got those guardrails around it.

I also recently built a tool that integrates with GitHub to pull down slides created by GenAI, so I can edit them in a structured way. What you’ll find with AI-generated slides — like everything — is you tell it to do something and it won’t do it exactly as you want. So I pull it back, rewrite it as Markdown, hand it back to Claude Code in a format it understands, and go again. It’s that constant back-and-forth, the frustration of GenAI, but you get a really nice-looking presentation out of the box. As long as you’re aware of the drawbacks and put guardrails in place, it’s really helpful.

44:04Q&A — client data, where the data comes from, Sheets vs Excel

Q (Christie): Do you ask clients if they’re okay with you putting their data into AI, and do you have additional insurance?

Jonathan: We don’t particularly ask, because we haven’t taken it so far that we’re physically storing data in AI. We use AI to speed up processes, and if we’re storing client data it’s in secure, production-ready databases or spreadsheets.

Dave: That’s the difference. I’m not a big fan of running autonomous GenAI over everything, including client data. The data in my apps is held in databases, and we ensure the security around those. We don’t need to ask the client if they’re happy for data to be stored in a secure place — they’d assume that anyway. It’s like putting data into Google Drive. Be wary of running things like an autonomous coworker agent over client data, but in a secured database it has nothing to do with GenAI once it’s there.

Q: Where do the apps pull all the financial information from?

Dave: We talked about using Claude Code or similar vibe coding tools — there are others like Replit, Cursor, Codex and Lovable, which is a bit different. I’m using the Xero API to pull the accounting data, and the payroll API for payroll data, and the same to push data back. I use Claude Code to walk me through setting up those APIs, and I have a registered internal Xero app driving the integration.

Jonathan: Same. There are different types of APIs to navigate. PayCircle is very simple, whereas Xero is a bit more complex with OAuth around it. Three years ago I struggled to do this; now, with a bit of AI behind it, it’s way easier.

Q: Do you both use Google Sheets over Excel, and why?

Jonathan: I don’t use Excel at all. I loved Excel and wouldn’t hear a bad word against it, but I love Sheets because I can code in the background — I’ve been writing Apps Script for five years or so, and that’s pushed me towards coding in a safe environment.

Dave: I use both — different tools for different use cases. On a pure spreadsheet basis, Excel is the better tool. But with GenAI there’s huge value in data being in the cloud, so Sheets is the better online tool — for collaboration with clients, for accessing APIs, for sharing data and building tools with GenAI. My mindset now is: can I put it into Sheets without compromising how I work with the data? If yes, I go Sheets. But I still use Excel for working quickly on the fly, and tools like Power Query — they’re both incredibly powerful.

Jonathan: Dave and I share work, and I’m always envious of how his Excel spreadsheets look. That makes me think I should push things into more of a front end to present them — but then I immediately worry about the security of that.

Q: What about GDPR and the DPA?

Dave: Be careful with GenAI. The GenAI I use in my app is via the API, which has a DPA — an enterprise-level agreement. Yes, the AI sees the data, but it’s secure in the sense that there’s that agreement. I’d still be very conscious about running too much GenAI over client data when you don’t need to. The first question should be: do you need to use GenAI at all? If you do, make sure the APIs or subscription you’re using put you under that enterprise agreement.

49:31Final word — build solutions, not replacements

Jonathan: The whole point is you’re using AI to help generate the code, which then makes it predictable — so you get the same answer today, tomorrow and the next day.

Dave: That’s where vibe coding does best: building things that are deterministic and don’t rely on GenAI at runtime. We don’t know where this is going — where the pricing goes, whether the sustainability improves or gets worse as GenAI starts ingesting its own output and its own mistakes. But if you can use it right now to build secure utility apps, and you’re willing to work with an engineer or you have a coding background, it’s a great tool to play with. The focus should be on creating solutions to problems — not replacing apps that already exist, are well priced, and do a good job.