Should Finance Pros Be Using Vibe Coding to Build Their Own Tools? with Brock & Natalia
In this episode of FP&A Unlocked, host Paul Barnhurst is joined by Brock Beyer and Natalia Kudinova to discuss how vibe coding is changing the way finance professionals automate work and build practical tools. They explore real-world use cases, AI token costs, security and maintenance concerns, and why finance teams should start with simple, repetitive processes rather than business-critical systems.
Brock Beyer is the CPA Controller at Jump, where he has used vibe coding to build internal productivity tools. Natalia Kudinova is a Senior Director at ABBYY with experience across finance leadership, treasury, tax, reporting, transformation, and process improvement.
Expect to Learn:
What vibe coding means for finance professionals
Practical finance processes you can automate with AI
How to manage AI token usage and costs
Why security and human oversight remain essential
How to start small and learn through experimentation
Here are a few relevant quotes from the episode:
“You don't have to feel this pressure to vibe code every single tool.” - Brock Beyer
“Start with the tasks that you are most tired of doing manually.” - Natalia Kudinova
Vibe coding is giving finance professionals new ways to automate repetitive work and build practical tools without traditional coding expertise. The key is to start small, focus on well-defined processes, and keep humans involved in reviewing results. As AI adoption grows, security, cost, and maintainability will remain critical considerations.
Follow Natalia:
Follow Brock:
LinkedIn: https://www.linkedin.com/in/brockbeyer/
Disclosure: Portions of this episode (such as the introduction or promotional segments) use AI-generated voice narration produced under human editorial review.
Earn Your CPE CreditFor CPE credit, please go to earmarkcpe.com, listen to the episode, download the app, answer a few questions, and earn your CPE certification. To earn education credits for the FPAC Certificate, take the quiz on earmark and contact Paul Barnhurst for further details.
In Today's Episode:
[00:00] - Trailer
[03:12] - What Great FP&A Looks Like
[04:59] - What Is Vibe Coding?
[09:36] - Getting Started With Vibe Coding
[16:02] - Where Vibe Coding Makes Sense
[20:21] - AI Token Costs and ROI
[34:12] - Best Finance Processes to Automate
[41:53] - What You Shouldn't Vibe Code
[46:17] - Maintenance and Security
[54:17] - Final Advice
Full Show Transcript:
Host: Paul Barnhurst (00:00):
Welcome everyone to another episode of FP&A Unlocked. This one's going to be a live episode where you get to ask questions. I'd love to start before we get started, we'll give it a minute to let people join, but if you're out there and you can hear us, just confirm you can hear us, let us know where you're coming from and your name. So go ahead and throw that in the chat and we'll get started here in a minute. So we'll give it another minute or two for people to join before we get started. And just so everybody knows, I'll introduce them in a minute, but I have Brock and Natalia with me, so we'll just give you a moment to comment here. All right. I'm going to give it just one more minute. If you can hear us, let us know. I haven't seen a comment yet, which tells me we're probably dealing with a lag.
(00:42):
There they go. I see Wayne. Wayne Phillips just joined us. Great. Anyone else out there can hear us? Let us know where you're coming from. Would love to know. And before we get started here with the actual interviews, why don't we go ahead and let our guests introduce themselves. We'll take a minute. Well, hopefully a few more of you will join, let us know where you're coming from. So Brock, why don't we start with you? If you want to take a minute and just introduce yourself.
Guest: Brock Beyer (01:06):
Thanks, Paul. Excited to be here. I'm looking forward to this. My name is Brock Beyer. I am the controller at Jump. We are the leading AI operating system for financial services professionals. So we started out, AI note-taking have evolved immensely. We started out with just wealth management and it's grown immensely. So we're working with insurance professionals, tax and accounting professionals. It's been super, super fun. So yeah, that's a little bit about me. I started vibe coding probably, I don't even know, four to six months ago. I never remember the timeline. It just keeps becoming a blur. I love it. It's been super, super fun time in my career. All
Host: Paul Barnhurst (01:47):
Right. Well, thank you, Brock. Natalia, if you want to take a minute and introduce yourself.
Guest 2: Natalia (01:51):
Yes. Hi everyone. So I'm Natalia Kudinovai, senior director at Abby. Spent most of my career in finance leadership roles in international technology companies, and I've led a lot of different departments within finance, accounting, reporting, operations. Projects included accelerating mountain close, implementing EP systems across multiple countries, and also finance transformation. And today my focus is treasury, tax, transfer pricing and different cross-functional projects and also process improvement. And that focus on process improvement eventually led me to automation and fibe coding.
Host: Paul Barnhurst (02:29):
Awesome. Well, thank you for that introduction and want to thank Natalia for going out of her comfort zone. She mentioned this is the first time she's done a podcast like this, so I told her I would take it easier on her. I'd give all the hard questions to Brock. I hope you're ready, Brock.
Guest: Brock Beyer (02:43):
I'm ready to roll. I love
Host: Paul Barnhurst (02:43):
It. I also know she mentioned her. English isn't her native language, so I appreciate her putting herself out there. I love when people do that. So we'll go ahead and get started. But again, if you're out there, please let us know where you're coming from. Let us know any questions you have. And where I want to start is there's a question I always like to ask, so we're going to get both your perspectives on this, and I'm going to get yours first as a controller. As a controller, from your perspective, what does great FP&A look like?
Guest: Brock Beyer (03:12):
For me, great FP&A is collaborative. So for me, it's not a completely different department. It's not a completely different function. In my eyes, you are working hand in hand with the accounting team to drive the business. So for me, every single successful FP&A leader that I've worked with, they love the accounting team. They love getting the numbers. They love doing it in a timely manner, but it's also having open door communication. So whenever we make changes, we want to make sure that FP&A is in the loop and vice versa. So for me, good communication, but it's also just collaborative.
Host: Paul Barnhurst (03:51):
I like it. Collaborative, good communication. I know the best FP&A roles had a close relationship with accounting and controller, and obviously very important. So Natalia, from your perspective, when you think of great FP&A, what comes to mind? Anything you want to
Guest 2: Natalia (04:05):
Add? Yeah, to me, great FP&A not only explains what has happened and why, but also it's about what is likely to happen. And it helps business to see problems early. And also to add from treasury perspective, it's very important to connect P&L forecast with cashflow because we know that revenue and profits on paper do not always cash in the bank. So to me, great FP&A also gives a connection between P&L and cash.
Host: Paul Barnhurst (04:32):
I love that you mentioned the cash because I've definitely seen situations where cash is kind of forgotten by FP&A. And I learned early in my career how important it was when we brought in all our billing back in-house and in the first year we recognised 10 million to the P&L, and a good portion of that was because we had never been paid. So we'd recognised the revenue, but never got the cash. And that's just a recipe for disaster if you let that continue.
Guest 2: Natalia (04:57):
Correct. Yeah.
Host: Paul Barnhurst (04:59):
All right, we got someone joining from the Little Apple, Manhattan, Kansas. Love it. You got Wayne out there, so keep letting us know. We're going to be discussing vibe coding today. So that's the topic. We're going to jump into that for a minute. I'd love for any of you to share how you would define it. I'm going to give Brock a chance and I'll share some of my thoughts. I think everybody looks at it a little different. We're hearing terms finance engineer, vibe coding. And even with Excel, Microsoft coined the term vibe working for the idea of natural language prompting to work in Excel. So we're seeing a lot of new terms. But Brock, I know you've been kind of on the leading edge of this. You've done several webinars around it, developed quite a bit of tools. How would you define vibe coding? How do you think about it, particularly for finance?
Guest: Brock Beyer (05:42):
Yeah, for me, it's funny because vibe coding, like hot take, I don't love the term vibe coding. For me, it's as simple as using simple, easy communication to be able to create something big. And it's that simple. It really is. So for me, when I first started out, I was just trying to figure out how to build a few tools here and there that looked in our branding and looked nice. It's really just like you prompting and making small tweaks here and there to build something bigger than you thought was imaginable. It's crazy. That's how it's been for me. Yeah, that's what I would say.
Host: Paul Barnhurst (06:28):
All right. I like it. When I think of it, I'll give a little bit of my thoughts and Natalia, you can add anything if you want. But the way I think of vibe coding, it's a way of creating a tool. You're using some kind of coding language, whether it's HTML, CSS, whatever, that you may or may not fully understand. So through prompting, through conversations with AI, you're able to create something that is code. And I mean, the good and bad is a lot of things are created that we don't necessarily understand the language, and that's cool that we can do it. And there's some scary things I think that come with that. We'll talk a little bit about later, but that's kind of how I think of it. I like what you shared, Brock. Natalia, any thoughts from you when you think of vibe coding?
Guest 2: Natalia (07:11):
I know that currently there is a new term occurred like finance engineer or something like that. So I think that vibe coding is not actually about turning every one of us, like finance professionals turning into engineers. It's about just having ability to create tools that help finance people to solve a lot of tasks that previously were either left in spreadsheets or manual workarounds, or we were just waiting for IT and developers to help us put those into life. And yeah, finance people know their processes and know their issues better than anyone else. And now this gap between the finance people and the tools that help resolve these problems is really, it is reduced by coding. So yeah, I think that's what it is for finance, not all of us.
Guest: Brock Beyer (08:20):
I think it's super well said. That is, in my opinion, exactly what it is. Because when you just think about it at the core basis, it's like vibe coding is like you building software or some dashboard or some visualisation, whatever the output is. And you're building it by using plain language to be able to have the assistant write the code and then write the code for you so that you're not doing it line by line and then create some output of your desire. And the thing that's very valuable about it is, like you said, historically, professionals haven't been able to do this. So if I wanted a dashboard back in the day or some kind of report or whatever it was that required more technical expertise, it was much more challenging to do that where now it is so much easier because of the tools that are out there.
Guest 2: Natalia (09:24):
Yeah. I think a lot of our tasks were just in IT backlog for years. I
Guest: Brock Beyer (09:30):
Would agree with that.
Guest 2: Natalia (09:32):
Now it's better, but much better.
Guest: Brock Beyer (09:35):
It is, definitely.
Host: Paul Barnhurst (09:36):
Yeah. There's something to be said for not having to wait for the IT backlog. So how did you get started? What's your journey? What's kind of the thing you've uploaded or what convinced you to say, "Hey, I need to try this."
Guest 2: Natalia (09:48):
Actually, I started quite gradually. So my first discovery was maybe for others as well, it was Cloud for Excel. So I used it to automate part of our daily cache reporting process through Power Query. So the Cloud helped me to write scripts for Power Query. We have numerous banks and accounts, and we have to transform all this information from various sources into a consistent format for our Cache report. And so Power Query does that. So it was already a significant improvement. But then I thought that, okay, Power Query only works within Excel and it works on Python. So what if I have a script that could be kind of independent and could be used outside of Excel, but at the same time provide me with the same result? And that's how my bank statement process and script was born. The first version was really very simple, no user interface.
(10:54):
It was just a Python file that I had to open and run it essentially. But still it felt to me like a breakthrough, a huge breakthrough because I've never considered myself as a person who can write a software engineer or a developer who can write some software. And now I built something that works that actually resolves quite significant process issue because it was all done manually. It took a lot of time. And then I remember that after a few days of very big excitement, I said, okay, can I make it better? Can I make it more user-friendly? Maybe run from a web interface, have a date selector, have a process log and so on. And so that's how I actually started Vibecoding because I asked Claude, how can I go from this version to a better one? And yeah, it just helped me and said, okay, yes, we can have an web app as simple as that.
(12:07):
And I said, okay, let's do that. And that's how it started.
Host: Paul Barnhurst (12:12):
Love it. Thank you for sharing your journey. And I love that you shared just using Adult with Power Query. M-Code is a form, it's a scripting language, kind of a form of code, and it's a great example for AI. There's so many different places you start. I think sometimes people think vibe coding means you have to start with this whole big application. And I see Brock nodding his head no. And I think we're all in agreement that that's probably not the right definition for it. That's sometimes how I think, but I want to share a couple comments we've got just real quick. I like what Alberto said. Aligned with what Natalia just shared. Vibe coding does not necessarily mean that you are building an app or a website. It can be as simple as having AI write the queries for you. SQL, Power Query, our build automation solutions via Power Automate.
(12:59):
And so I think that's a great point. I think there's a lot of different ways we can think of Vibe coding. Another one said, agreeing that we're not always the first in line to get those IT resources. We now have the power to do it ourselves. So I think we've had the power before, we have more power. Before it required a lot of knowledge to do it in Excel, to do it in Python. I still think having those knowledge is helpful and it's easier, but you can do stuff without the level you needed before. And then Wayne shares, and I won't read all of this, but citizen coding can be dangerous if a developed app breaks. We'll talk a little bit about that before being embedded into a process. But then he also shares, I trust Claude Code more than my own coding. I mean, Excel files break.
(13:45):
So there's a lot of different thoughts here and we'll jump into more of that. But Brock, your story, why don't you give us that?
Guest: Brock Beyer (13:52):
Yeah. So I started out, I went to an event back in September of 2025 where it was the Real at Recon in San Francisco, and we heard about this company called Lovable. And I was like, who is this? One of their founders was there and I'm like, I don't even know what this is. Fast-forward to today. That was one of the coolest experiences ever because one of the founders of Lovable was there in the audience. But we got a subscription to Lovable. And later on, I just had accumulated credits because I'd never used it. I'm in accounting, I'm in finance. I don't vibe code. I don't have any need for this. But we were moving offices. And when we were moving offices, we were trying to find a way to create hotel management, so the desk management tools. We started looking into it. It was 10 to $20,000 for us to buy the software.
(14:51):
We could use Excel, but as everyone here knows, Excel is great if you work in finance. Most people don't know how to use Excel. And so we're like, "No, that's not going to work either." And then someone made the joke, "What if we vibe code it?" I was like, "Oh, maybe I should try to vibe code it." So I used those credits that I had been accumulating for months. And I went home and I sat down and I started vibe coding. And I didn't know what to expect, but I walked away three hours later with a working prototype. I'm like, "This is nuts." And I was like, "There's no way this works." And then the next day I did a couple of UI things. So total time was probably about six hours of me just like. And it was fun. It was a learning opportunity for me.
(15:38):
And I showed it to the team and it is what we use today. We call it perch. And it's like whenever anybody comes in from out of state, they use it to book their desk for the day. And yeah, it's crazy. So that was my first experience and it's just been so much more since then.
Host: Paul Barnhurst (16:02):
I appreciate the use case. I mean, a couple things. One, it's something that's internal. It's relatively low risk, not complex, something you could have done in Excel. So I think those are the places to start. When I hear people saying, and you don't hear this much, but I'm going to vibe code this big, huge solution. And I always kind of cringe a little bit. I see you nodding your head. I've heard someone say vibe code an ERP. And I'm like, okay, good luck with that. Let's go how it goes.
Guest: Brock Beyer (16:33):
It's crazy. You and I have had this conversation before where you see people talk about Excel being obsolete because of the new tools coming out. And my eyes, I'm afraid they're going to get stuck in the back of my head from them rolling so hard. And it's the same thing with when people talk about these tools being vibe coded and people say SAS is dead. I strongly disagree with that because I understand the tools well enough to know that you would never vibe code an ERP. You would never vibe code high risk areas of sensitive data. So I would never vibe code a procurement tool, like end-to-end. Well, not a procurement tool. I would vibe code a procurement intake tool. I would not vibe code end-to-end procurement tool. I just would not. I would not vibe code an ERP, but I would vibe code dashboards in something that was visually pleasing for a rundown of a flash report or something like that.
(17:38):
There's so many different use cases and it's a balancing act, but anything that has highly sensitive data that you need to be 100% accurate, you're just not going to vibe code it, period.
Host: Paul Barnhurst (17:48):
FP&A guy here. I want to take a minute and share something I've been working on. I've spent several months adding new affiliate programmes to my website. Probably wondering why affiliate programmes? Well, I can't train you on everything, but I can show you and give you trusted resources with exclusive FP&A guide discounts in many cases on my website. I have several of the top FP&A AI people in the world. I have the top certificate programmes. I also have other programmes like Excel, Power BI. I'm bringing you some of the top people that train in the world. There's Nicholas Boucher with exclusive discounts, David 14. I'm adding Carl Seidman with Exclusive Discount. The top programmes, FPAC, FMI, and more. So go ahead and check it out on my website. Sign up. And if you have a question on what programme is right for you, go ahead and message me.
(18:48):
I'll get back to you, LinkedIn, or you can email me. So go to thefpnaguy.com and check out my trusted list of resources for you to upskill yourself. I think it's a good point. And I'll share one thing and we'll get back to some of the questions I had here, but if anyone wants to enter comments, please do. So two examples I've seen that I'm excited about, actually kind of three. One, Microsoft has released what they call, I think it's called Rayfin that works within its Power BI fabric where you can develop your own apps to help with dashboarding and different things via vibe coding. I think that's a great case. My co-host on Future Finance, Glen Hopper, has developed his own tool that helps for applications you vibe coded to ensure it's secure. It's meeting all the security requirements. You vibe coded inside of the tool and it makes sure all those are taken care of.
(19:36):
Now, I'm not saying that means you should vibe code an ERP, but it addresses some of those issues. I've seen a few vendors, one that they've created a section where what they've done within their FP&A tool is they're now allowing you to vibe code your own app. So you get their database and their security and their. I mean, there's still other things, but we're seeing more and more solutions that will allow you to do a little bit more in a safer environment. At the same time, there's a limit. And we'll talk about that. I think we've talked about it a little bit. We'll go a little bit deeper on that. But I want to touch on token cost because I hear people for a while we all heard token maxing, if you heard that term. And some companies had dashboards of how irresponsible can you be?
(20:21):
I mean, how many tokens can you use? I didn't mean to use irresponsible. Okay, I did. But it's kind of like the old days of how fast could we burn our cash and grow? Shouldn't it be how responsibly can we grow? So I'd love your experience, Natalia, because I know you started using, when you and I chatted, you started with your own personal account, doing it on your own, and then you were given some credits at work. And so tell us that story of what happened with your tokens.
Guest 2: Natalia (20:48):
That was quite a surprising story. So yeah, just to give a perspective, our company provides a $40 monthly allowance for cloud enterprise. And I used it in one day, as simple as that. So about $30 went to me formatting a few Excel tables. And then another 10 I spent for 20 minutes of white coding. It was quite an experience. And this was very different from using my personal plan because personal cloud subscription costs about $28 per month. And I really used it for months and built a few tools, a few applications after my processing script. So yeah, the surprising part I think was that we were expected to adopt AI experiment freely within our company. But the whole budget for the month was used in one session simply. And that essentially limits, I think, the possibility to experiment and to find new cases for AI implementation and for automation.
(22:18):
Because now when I know that how fast these tokens are used, I will be very cautious to experiment because I will now just think about, oh my God, this will take for my budget. What shall I do? And I will not be so open-minded in terms of like, okay, I have this tool I can now prototype. I can experiment and so on. So anyway, the whole story is about that enterprise subscription was meant to increase, I think, AI adoption. Whereas now from my perspective, the personal subscription is more suitable for these needs. Of course, I understand why we pay more for enterprise, but still the cost was quite big for a very small task.
Host: Paul Barnhurst (23:15):
And I think that's interesting. And obviously, I mean, I do think enterprise cost can be higher when you're paying for it directly versus consumer. And I think there's a lot of learning for all of us. So there's how do you optimise it? What's the right model? I mean, I think there's so many things that go into token costs, enterprise versus personal. But what you're sharing is I think a challenge we're all going to see more of in the future is, and I think Brock, you'll probably agree here. Right now, token costs are subsidised. OpenAI and anthropic, it's about growth. And anyone can look at the rumours out there. You can look at the S1s that are coming or whatever been published. None of them are anywhere close to profitable. They're losing billions and billions of dollars annually and they have huge cash outflows. So what does that mean when they go public?
(24:09):
Prices aren't going to get cheaper. Now, they may get better models that brings the cost down to run the model. But as far as what we're doing today, cost is only going to go up in the sense of what they're going to charge. I mean, they got to charge quite a bit more to be profitable. Any your thoughts on that, Brock? And then just maximising token usage just in general, wherever you want to take it.
Guest: Brock Beyer (24:31):
Yeah, I think it's a very interesting thing because one thing, I think the different companies have gotten much better with monitoring and the way that you can monitor token usage. And there are tools that are starting to come out that are very helpful to help you understand how much you're spending and who's spending what. For example, Claude, once you're on the enterprise plan, Anthropic does a really good job of just saying, setting limits. So you can say this is a usage limit. This is how much money they can spend, et cetera, et cetera. So that is super helpful because then you can actually safeguard and make sure that you're not just blowing out spend left and right. But the challenge is how do you define what good ROI is? Because everything there is kind of. It just depends on the person. It depends on the output.
(25:29):
It depends on what you're trying to accomplish. If you're just using and token maxing just a token max, it's not really good ROI, but if it's saving you 10, 15, 20 hours a week because of the tasks it's performing, I'd say it's a pretty good use case. I will say, I agree with you, Paul, I'm a little fearful of what's in the future.
(25:52):
What are costs going to be when those tokens are not subsidised? How much more money are we going to be spending? And if we're very reliant, what's going to be the outcome? I don't know. And I think Wayne just made a comment in the chat.
Host: Paul Barnhurst (26:06):
Very, very good. He did. I'll throw that up here.
Guest: Brock Beyer (26:07):
Very, very good call out on this one. It absolutely matters the model that you're using. Fable is one that has been used right now that is just token maxing extreme. Everyone is like, "How am I using this? How is this happening? How have I used all my tokens in 20 minutes?" It's because of the model that you're using. And so I would definitely recommend if you're trying to be smart about how you're using these tokens, one, I would set limits. I would always set thresholds so you're not just spending and spending and spending and spending. Two, I would try to find some form of solution for what's the actual ROI? And three, I would sit down and say, "What task am I trying to perform? And is that task. Which model does it require?" You will see a lot of success from that.
Guest 2: Natalia (27:03):
I just wanted to say that with all those implications and all these questions that we need to keep in mind, again, it makes the AI adoption much more difficult because now we need to think, okay, what is the model? What is the task? We can't basically experiment. So freely, we have to keep in mind so that we have certain guardrails, we have certain rules, what we are allowed to try, what we are allowed to build and so on. So it's just much more complicated than it's initially.
Host: Paul Barnhurst (27:43):
FP&A guy here. We'll get back to the show in a minute. This section is unscripted. When I started my business, I had two main goals. To be trusted and for my content to come across as authentic and helpful. I've heard from many of you that I've accomplished those. Today I have three goals, to be trusted, authentic, and have the best beard in finance. All right, enough with the jokes, enough with the fun. What I'm asking for is I'm asking for you to help me out. If you've enjoyed the show, if you've enjoyed an interview, if you found it helpful in your career, can you please leave a rating and review? That helps more people find the show, helps me grow the show, helps me grow my business. So I'd really appreciate it if you could take a moment and leave me a review. You can do it on Apple, Spotify, YouTube, wherever you listen, or you can go to my website, thefpandaguy.com.
(28:35):
That's F-P-A-N-D-A guy.com. Go ahead and go to Walla Love. Go down to the bottom and you can click to leave a testimonial. Thanks for doing that. Thanks for listening. It's a lot different than being handed a spreadsheet where there's no cost outside the application and say, "Try whatever you want. Go experiment. Power Query or the internet, go search and figure it out." Or, "Hey, here's a book on Python. Go build whatever you want because there is a cost behind this." Now, the reality is in general, what they found is for most tasks, the cost, the token cost tends to be about 5% of the overall cost when you add the humans to review it in finance. Somebody did a study and took general process, more workflow than vibe coding. So a little bit of a different case, but it was really interesting to see some of those numbers.
(29:29):
When you get into vibe coding, especially when you get into Excel, anything you do in Excel, it's going to use more tokens because it's a spreadsheet and it has to read it differently than something that's very much structured because it's unstructured and it has to go through often. If you have a big, huge model, and I think you probably see this Brock, and you ask it to interpret it through a 20, 30 sheet model, you're going to be blowing through tokens in a hurry because there's just tonnes of pieces of information. Everything Single cell, costing tokens, every piece of information. So I agree with you, Natalia. I agree with Brock, there's things you can do to set limits and all that. And then there's just a lot of learning. And so trying to learn from others, how do you optimise? What models should I be using?
(30:16):
How much freedom do I have? We're all kind of figuring it out together, I think.
Guest: Brock Beyer (30:21):
Oh, absolutely. I would say too, one of the biggest things that I've noticed is the way that you prompt definitely impacts your outputs as well and your token. Well, it obviously impacts your outputs, but it also impacts the amount of tokens that you use. And so if you're trying to use something in co-work or if you're trying to use something in code, I highly recommend not just going straight to the source and trying to prompt directly in those things. I would start with chat and make a very good prompt and have a very, very good conversation before you actually take that and put it into code or cowork. So as an example, a way that I've found a lot of success is with the output in mind, I will sit down and I will talk to chat and say, "These are the things that I want to do.
(31:12):
Pressure test this, help me think through this. What am I missing? What can make this better?" And then essentially it will go through the whole process and then I sit back and I say, "Okay, now put that into a prompt that I can put into code." And then it will give you the exact prompt. Now, if you think about it, it's taking it and giving exactly what you need in the way that you've explained it, the way that you've pressure tested it. It's very, very good. As opposed to going right into code and going back and forth and being like, "Ah, I actually don't like that. No, tweak this. No, do this. Change this." It just burns tokens left and right. And is that going to be the thing that's materially going to save you a lot? No. But it's just like these little tips and tricks that you do with time that make you better at it.
Host: Paul Barnhurst (32:00):
Another thing that makes a big difference, and then I'll get back to some questions I found is I ended up probably using more tokens, but I was much more efficient. Once I started, you create some skills, you create folders, you have a workflow around whatever you're doing. I code a lot of my website and at first it was just, let's try it all in the chat. Why am I doing? And then it's, okay, let's put this in some folders. All right, let's create some skill files and audit file and other things. And all of a sudden I'm finding I could get a lot further than I could before with just a little bit of structure. And so it's all new. It's a lot of learning for everybody.
Guest: Brock Beyer (32:39):
It's a tonne of learning. It's crazy. And I think one thing that I will say is you will hear people talk about these things all the time, but the way that you actually learn is just by rolling up your sleeves and trying to do it yourself. The first time that I learned how to host on Vercel and use Superbase and all these other things and code within code and then push it to GitHub, all these different things, it was just me being like, okay, I've got to figure this thing out. How do I do it? And it took me forever. But now if I did it again, it would take me, I don't know, a fourth of the time, maybe significantly less than that.
Host: Paul Barnhurst (33:24):
And that's true of anything, whether we're automating with -
Guest: Brock Beyer (33:27):
100%.
Host: Paul Barnhurst (33:28):
AI, with Excel, Power Query. Who remembers the first time they had to write a Power Query? You're like, what am I doing? Where you actually had to write it, not just drag and drop, but you had to figure something out on your own. It was like, oh, this is painful. But then once you've done it a couple of times, it just becomes easier. That first complex formula you write, whatever it may be. So I think you make a great point and you can go as deep or as shallow as you want. But before we get into that, I want to talk about some pros and cons and some different thoughts. What do you think of when I say, what are the prime things to vibe code? And I think you hinted on this earlier, Natalia. You mentioned workflows, I think dashboards, but what are some of the top candidates where people should start?
(34:12):
Somebody wants to try some vibe coding or maybe the areas you start. You even mentioned Power Query. Is it starting with having it write some code for a tool you already know? Or what would you recommend for somebody for starting, Natalia, your thoughts?
Guest 2: Natalia (34:25):
Yeah, actually I would select a process or parts of the process that takes a lot of time for processing data. So for example, if you have something like you download a report, you then have to clean the data, maybe apply VLOCAP, XLOCAP, then do some pilot, merge with something else, and then maybe do some visual presentation out of this. So this type of work, essentially not analysis, but kind of preparation for analysis, this all can be automated with VIP coding. And that is exactly the types of work that I automated in my VIP coded application, finance control centre that I have done for myself for my daily work. So I would start with some. If you have a number of various processes, I would select something that require a lot of data preparation because it's a kind of work that web coding can automate very quickly and give you very clear visual form in the way you need.
(35:35):
And if you don't like, you can change it very quickly and so on and so forth. And the beauty of it is that it uses Python, so it doesn't hallucinate because the logic is fixed. So it will apply the same logic over and over if you need to update the file, if you need it first month and you need the same thing in the second month or week by week. So it's a repetitive data processing, let's say this, that you do on regular basis. So something like that, that's where I would start with.
Host: Paul Barnhurst (36:13):
Thank you. Appreciate that. I want to get your thoughts on this, Brock, and then I'm going to share something Wayne shared in the comments, but go ahead. We'll let you share your thoughts, Brock.
Guest: Brock Beyer (36:21):
Yeah, I think Natalia's spot on. For me, the way that I would encourage people to start is by looking at the tasks that you perform on a regular basis that are repeatable and are rules-based. Sometimes they're tasks that you do not enjoy performing. So for me, I did not like doing bank reconciliations every single month. Go figure, that's not the most fun or glamorous thing in the world. If
Host: Paul Barnhurst (36:50):
Anyone's out there, raise your hand if you enjoy them. We'd love to know.
Guest: Brock Beyer (36:54):
Bless your heart if you are one that enjoys doing bank recons, because I am not one of those people. But what's crazy is you sit down and you define the task, you define the scope, you write out the instructions, and what you do is you essentially can then take that and have the task be automated. Now, the thing that I would say is when it comes to judgement and when it comes to really thinking, I would still keep a human in the loop. And I think human in the loop is a very, very good term to use. And it's a thing that you need to always be thinking about because even when you do these rules-based tasks, it's important to have human in the loop so you can have the AI perform the recon, but there's still going to be a need for a human to sit back and just not blindly accept the output that is performed.
(37:47):
So a human needs to be in the loop to review and make sure that what has been created is still good and accurate because at the end of the day, AI can perform the task for you. That's great. But the buck stops with you.
(38:03):
If you give an output or if you give a financial report that AI helps generate, but it's wrong, you can't just blame AI that it's on you. So those are just important things to note, I would say.
Host: Paul Barnhurst (38:15):
And I want to ask a question here, and then I'm sure Wayne shared. As I've listened to you talk and as we talk, how do you define building with AI like you're taking skills, you're automating workflows, but you're not necessarily coding. Maybe you're doing some coding in that, but how do you think about the two? Because sometimes the process isn't necessarily. There's a lot of intermingling. I think some people think vibe coding means you have to get an application. But anytime we want something deterministic, we need a formula or we need code. Whether it's using an Excel formula, it's a Power Query. If you want something to repeat the saying every single time, you need it to be deterministic because you're not going to get the exact same answer every single time if you just let AI do it. So how do you think about that?
(39:07):
If I use a little bit of Python script and some kind of workflow I built at agents, am I vibe coding? I'm just kind of curious your thoughts, Brock. How do we think about all this?
Guest: Brock Beyer (39:16):
Yeah, I think it's a great question. There's a lot to think about and unpack because when we hear the term vibe coding, it's kind of a black box. It's pretty ambiguous and it makes it very challenging. And even when you hear the term AI, it's pretty ambiguous and it's kind of a black box. For me, when I sit down and think about it, I try to clearly define and clearly understand the breakdown of how and when to use the different elements of AI. So the LLM that I use mostly is Claude. There's three components of the Claude desktop once you're in a pro subscription. You have chat, you have cowork, and you have code. Chat is like a conversation piece when you're going back and forth and you're just conversing back and forth. Cowork is a multi-step task tool that can help pull files and be able to upload things and organise your desktop, do whatever tasks you need performed.
(40:14):
And then code is where you have an output or you have some visualisation that's created as a result. So you can use all three together. You can use one, you can use two. It doesn't matter really. The vibe coding element to me is like when you're using code. Code is more vibe coding in my opinion. But when you're using AI, it can be all three to be able to perform the various tasks. And it really just depends on the task you're trying to perform on a monthly basis. And it depends on the tools that you have access to and what connectors are in place. So there's a lot to unpack with that, but yeah, happy to
Host: Paul Barnhurst (40:58):
Elaborate. Yeah, no, I think you touched on something that can be pretty much its own episode. I'm sure Nicole - It easily cut. Around what are the different tools? How do we think about them? There's no perfect answer. I've seen some people define finance engineer as someone who's building systems, which frankly, I disagree that that's the primary role. I think it's someone who's primarily fixing workflows and automating workflow type tasks versus building what I'll call true systems. But everybody has a different opinion. And that's what is so fascinating is how fast this has moved. I remember when the internet came out and it was nowhere near this fast. Or I remember when I got my first computer in junior high and using some of the very early computers in elementary school and none of them were anywhere near this fast. So Natalia, I'd love to get your thoughts.
(41:53):
I think you talked a little bit about this, but what would you say people should not be doing with vibe coding? Where do you think the limits are or how should they think about that? Are there situations where it's like, look, AI doesn't make sense here as far as building in your thoughts?
Guest 2: Natalia (42:12):
We touched that a bit earlier and I agree with you with Brock. Yeah. I agree here with Brock actually, because I also think that we shouldn't vibe code things that are business critical such as, for example, ERP or even within, if we take aside ERP, but something that touches cash for example, or payroll tax. So where the impact of error or impacts of failure in this vibe coded application is huge and material essentially. So that are the areas that I think we should not touch with vibe coding. Vibe coding for me is more about maybe personal productivity plus maybe team productivity, but not business critical. So yeah.
Host: Paul Barnhurst (43:01):
I think that's a good way to think about it, team and personal versus business critical. I will share a really interesting, and I'll say if Brock wants anything, I chatted with a guy yesterday. So if anyone's interested, and I'm just going to throw this up here real quick, you have till Friday, Drivetrain is actually doing a hack. You can find my posts online about that and go to Drivetrain AI, the FIN hack and register where you can submit anything you vibe coded. And I've been talking to a bunch of people where they've been sharing their ideas. And most of them have been one's in application to help with dunning or different ideas. But one guy reached out to me yesterday and he's like, "I've been doing it for nearly two years. He's applied for patents and he's built an entire solution. He actually has a patent of connecting AI to OLAP and relational databases, and he has patents pending." And I was like, "Okay, that's the extreme case.
(43:55):
He's built an entire software. He's now hired a developer to help him with the next phase of it. And he plans on releasing it commercially. Sure, he vibe coded, but I don't think any of us would say that's what we should be doing." And so it was interesting when he submits it because it was definitely something that was a tonne of time. And I'm like, "Okay, yeah, I wouldn't encourage anyone to try to do that in their job." I see Brock, oh no, please don't. No,
Guest: Brock Beyer (44:24):
I wouldn't either. You got to think about it from this perspective. If it breaks, if you build it and if it breaks, who's responsible for fixing it? It's usually the person who built it. Now think about your day-to-day process. Think about I'm an accountant. So for me, let me speak from an accounting lens. If I was trying to build an ERP, think about the hundreds of thousands of one-off scenarios that might occur. What if a payment comes in and it has the wrong date on it? How is that going to be impacted within the ERP? What if I march something as paid, but it shouldn't have been paid? It was the wrong invoice. Can I go back and fix that? What if I have a bank statement that isn't reconciling correctly and all the feeds are messed up and I need to remove some of the duplicates?
(45:21):
Some of them were duplicates, some of them were not. Think of the hundreds of thousands of scenarios that I have to go through and personally say, "In this scenario, we actually need you to do X, Y, and Z. There is no world where I'm saving time and money and just pay for the ERP for heaven's sakes." So I agree, if it is a very, very important business related software or tool, it's not worth it. It's just not. And at the end of the day, that's the most important thing. Go ahead.
Guest 2: Natalia (46:04):
I was going to say, and to mention if you want to resign, what is next? Who will be taking care of that? Oh, you're in trouble. Yeah. Of course, if you are not the business owner.
Host: Paul Barnhurst (46:17):
The resign part. Now, if I asked how many of you, when you inherited a financial model in Excel, use what the prior person gave you or started over? I'm going to guess probably 60% of the time you start over. As you're vibe coding these tools, I think we're going to run into a lot of that. The next person's going to think differently than you. So you got to balance that. How critical is what you vibe coded to the process? How good are the instructions? We're going to run into maintenance issues. We're going to run into, I think a lot of these tools will be similar to Excel where when someone puts VBA in there, you don't understand it. Yes, you can now ask code to help you. So there are some benefits. But that's one of my biggest concerns with all this is how do we make sure it can be maintained for the long term and we're not creating a bunch of sprawl?
(47:07):
Because I feel like that's a real risk. So I'll ask both of you on this. I'll start with you here, Brock. Love some of your thoughts. I
Guest: Brock Beyer (47:15):
Don't really know. Let me think about it for two seconds because for me, there's so many things. Yeah, let me think about it for two seconds.
Host: Paul Barnhurst (47:22):
No, you can have a minute to think about it. Do you have any thoughts there, Natalia, you can share?
Guest 2: Natalia (47:27):
If we think about that, not every tool we need to maintain forever. So I think again, if we think about the vibe coded apps as tools for personal productivity versus team productivity, then a personal productivity tool can be personal and it doesn't have to be transferred over. So the new person can use or create its own for this work. But yeah, if we think about team productivity tool that is shared maybe within the team, then I think it's important that we have certain handover process. So we shouldn't maintain it alone or the person should not maintain it alone. We should maybe involve IT team. We should host it in some infrastructure, in some company's cloud, wherever. And maybe IT team can help us then hand over it to the next person or the next team member. So that's why I think we will maybe have certain kind of tools that are just used by one person and it still can be okay.
Host: Paul Barnhurst (48:49):
No, appreciate that. Brock, have a little time to think on
Guest: Brock Beyer (48:52):
It. Yeah, I think that's spot on. I think it really depends on the organisation as a whole and what tasks you're trying to perform. From a security perspective, the best way for you to just be completely safe is if it is something that is not locally hosted. So when you create tools, you can be able to just have it locally hosted on your desktop, which is pretty safe. But when you actually start to have things hosted, you should always be running that through the security teams. No questions asked in my opinion. But when it comes to just cross-collaboration, there's so many ways to think about it. And there's companies out there that are doing a very, very good job of sharing these tools. I know of a handful who have created these tools that make it so that it's easily able to just share tools, skills, other things that have been created, but it's done in a secure way.
(49:52):
It's always done through the security team. Another way of sharing some of these skills and things that you've built are, well, it's become easier to share skills specifically, but when it comes to outputs and code and other things like that, usually you have some form of a private GitHub repo that's only shared with your team that you can be able to upload those and have your team download those. So I think it really just depends on the team, but I would always. We're just talking about from security perspective, you should always involve your security team for sure.
Host: Paul Barnhurst (50:24):
I agree. So I think on the security side, you're always going to need to involve IT. If it's something personal, 100% on your desktop, okay. But as soon as others involved internet connections to any tool that goes outside your company, so any third-party tool, there should be that just kind of check. Now, if they've already given approval, if it's standard MCPs, that's one thing. But beyond that, if you're building an API or you're connecting something that isn't standard, you're giving passwords that are whatever those may be, always have that conversation. I think the second side is there's the long-term maintenance, which is something engineers are designed for. It's why you'll see a little bit more of this finance engineer role is when things break, there's going to be some challenges. So it's going to be interesting to watch. I would imagine a number of things we build ourselves won't get passed on like Excel spreadsheets.
(51:14):
Is that good? Is that bad? Depends on who's yes. Depends on what it is. Again, it comes back to documentation. The great thing is, and knowledge. It's always hard to maintain something when you don't understand it, but it's much easier when you can ask a tool that does and that you can have it right documentation. Doesn't mean it's foolproof, doesn't mean it's not going to break. Those are things to consider, but I don't think that's enough to stop somebody from experimenting. I still think the right decision to experiment. I'm going to take a couple questions and I'm going to ask both of you your final thoughts and we'll wrap up here as we're coming up on the top of the hour. So someone asked a little bit more about Cowork. I saw a few comments there. So I'm just going to share one thing. Someone said it's desktop based for me.
(51:56):
Yes. Cowork sits within the Cloud application on your desktop, but Cowork works in the cloud. It processes everything in the cloud. Code processes things on your machine, hence why you do a plugin when you've built skills. So code has the ability, since it's cloud, to take control of your machine and work on it, but you access it through the desktop. So that's a little more colour there since there are a couple questions. I would encourage anyone that's trying to understand if it's the cloud library you're trying, whichever one you're trying to understand, whether it's cloud, whether it's Copilot, whether it's ChatGPT, they have a lot of great free training. Anthropic probably has 40 hours worth of training. Yes, you can go pay someone if you want specific finance, but if you're just trying to understand the basics of the tool, go check them out. It's a great place to start.
(52:46):
And there's a lot of other sharing things. I know Brock's been sharing some things on LinkedIn and also TikTok if you have a newsletter now. So there's a lot of resources out there. So that's what I was going to say on that one. Another great tip here that somebody shared that you were like, if you use AI for VBA code, make sure you create a skill and give it some examples of what good code looks like, because the reality is a lot of the code on the internet is not good. So some samples and guardrails. Now, if you don't know VBA, that becomes tough. And that's where one of the things I say is AI is a magnifier in many ways. If you know what you're doing, it will magnify that. If you don't, it will magnify that eventually. Doesn't mean you can't get there, doesn't mean you can't figure it out, but it's why you still need to know accounting or modelling or Excel because you'll be better with AI than if you didn't know it.
(53:36):
All right, we'll do one more here. You can quickly vibe code an Excel add-in that can be shared with coworkers for your productivity macros. Yeah, cloud code. Yes, you could do that. So you could even create your own add-ins within Excel. That's something that's a little more secured example Wayne shared. I haven't gone there at all. I don't know if either of you have tried that, but that's one he's done. That's an interesting one. I'll be honest, I hadn't even thought about it, but that's a good use case in that Microsoft. If you're putting an ad into Excel, you're going through Microsoft, they're going to make sure that's secure. So there's another interesting kind of case. There's all kinds and we'll continue to see them. So why don't we go ahead and wrap up? If we get any more comments, I may take one more.
(54:17):
But why don't we go to you, Brock, first, and then we'll go to you, Natalia. Just any last thoughts around vibe coding you want to share?
Guest: Brock Beyer (54:23):
Yeah, I think you touched on this. I highly recommend, and I think that I'm going to go back and look more at some of these things. Anthropic really does have a lot of free courses just to teach you the fundamentals of AI just in general. Claude and understanding Claude, the platform, understanding co-work, understanding code, things like that. Very, very, very helpful. But just in general, the thing that I would say is you don't have to feel this pressure to vibe code every single tool. You shouldn't. I think that's just silly to just think that, nor should you. At the end of the day, you're supposed to be doing your tasks and your job effectively in a good manner. And these tools absolutely help you, and they absolutely can be very crucial in making you more successful in your role. However, don't feel like there's huge pressure to vibe code everything.
(55:16):
Just take it case by case, and if it makes sense, try it. Be surprised and be impressed with what you're doing. And those are some of the things that I would think through. And don't be overwhelmed when things go south and when things aren't working. That's part of the learning process. I think that it's more important to fail and not figure out how to do it and then finally find a way to make it work. I think those moments you learn more. So those are my parting words.
Host: Paul Barnhurst (55:40):
One of the keys to success at a camp I worked at, one of their principles was failure leads to success. Nothing wrong with failing. It's are you going to continue to learn through the process? If not, well, then you're going to fall short.
Guest 2: Natalia (55:52):
Yep.
Host: Paul Barnhurst (55:53):
Natalia, we're going to give you last word here.
Guest 2: Natalia (55:55):
Yeah. Good luck everyone with the vibe coding. I agree totally with Brock. You should not start with a thought, okay, I need to build an application. No, start with something simple and something that you know very well. Yeah, don't be afraid that the first version will not be super cool. My first tool was not beautiful at all, but it was enough to give me the excitement and to understand that it can work and it'll work and I can make it better. And I actually learned a lot through the way, through the process. And yeah, I just recommend everyone to start with the tasks that you are most tired of doing manually. That's the key. So good luck.
Host: Paul Barnhurst (56:40):
So I need to create an avatar to do my interviews. No, I'm kidding.
Guest: Brock Beyer (56:44):
I
Host: Paul Barnhurst (56:45):
Love doing interviews. Joking. All right. Thank you, Natalia. Thank you, Brock. Loved what you shared. Thank you everybody for joining and the participation, Wayne, Kevin. There were others out there as well that participated. So thank you for. Alberto was out there. Thank you for joining us. This will get released as an episode here in a few weeks, probably beginning of August or September in the next month or so. But thank you for joining us and really appreciate it. You guys can reach out to Brock or Natalia. I'm sure on LinkedIn if you have any questions and be happy to answer those. But thank you Brock and Natalia for taking the time. Appreciate it.
Guest: Brock Beyer (57:20):
Absolutely. Thanks for having us.This has been awesome.
Guest 2: Natalia (57:24):
Yeah, that was great.
Host: Paul Barnhurst (57:25):
Thank you. I might get you to hold on. Yes, thank you so much. All right. Thank you everybody. That's it for today's episode of FP&A Unlocked. If you enjoy FP&A Unlocked, please take a moment to leave a five-star rating and review. It's the best way to support the FP&A guy and help more FP&A professionals discover the show. Remember, you can earn CPE credit for this episode by visiting earmarkcpe.com, downloading the app and completing the quiz. If you need continuing education credits for the FPAC certification, complete the quiz and reach out to me directly. Thanks for listening. I'm Paul Barnhurst, the FP&A guy, and I'll see you next time.