Should Finance Pros Be Using Vibe Coding to Build Their Own Tools? with Brock & Natalia

People talk about Excel being obsolete because of the new tools coming out. And it's the same thing when people talk about these tools being vibe-coded and people say SaaS is dead. I strongly disagree with that. I understand the tools well enough to know that you would never vibe-code an ERP. Anything that has highly sensitive data that you need to be 100% accurate, you're just not going to vibe-code it. Today's guests are Brock Byer, controller at Jump. And Natalia Kudanova, Senior Director Finance at Abby, here to discuss vibe coding in finance and why the future belongs to those who aren't afraid to experiment.

So how did you get started, Natalia? What's your journey?

First discovery was Code for Excel. I used it to automate part of our daily cash reporting process through Power Query. It felt to me like a breakthrough. I've never considered myself as a software engineer or developer, and now I've built Something that works, that actually resolves quite significant process issues.

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. 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 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 2 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 any comments yet, which tells me we're probably dealing with a lag. 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 while 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.

Thanks, Paul. Excited to be here. I'm looking forward to this. My name is Brock Byer. 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, 4 to 6 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 right.

Well, thank you, Brock. Natalia, if you want to take a minute and introduce yourself.

Yes. Hi everyone. So I'm Natalia Kudinova, 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 month-end close, implementing ERP 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 vibe coding.

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.

I'm ready to roll.

I also know she mentioned this isn't 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?

For me, great FP&A is collaborative. So for me, it's really, it's not a completely different department. It's not a completely different function in my eyes, like you are working Hand in hand with the accounting team to like 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.

I like it. Collaborative, good communication. I know, you 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 add?

Yeah, to me, a 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, you know, see clear problems early. And also to add, from treasury perspective, it's very important to connect P&L forecast with cash flow 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.

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 recognized $10 million to the P&L. And a good portion of that was because we had never been paid. So we'd recognized the revenue, but never got the cash. Right. And that's just a recipe for disaster if you let that continue.

Correct. Yeah.

So, all right. We got someone joining from the Little Apple, Manhattan, Kansas. Love it. We 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, you know, 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?

Yeah, for me it's funny because vibe coding, like hot take, I don't love the term vibe coding. I, for me it's just, 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 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.

All right, I like it. When I think of it, I'll give it a little bit of my thoughts and then, Paul, you can add anything if you want. But the way I think of vibe coding, it's a way of Creating a tool using, you're using some kind of coding language, whether it's HTML, CSS, whatever, that you, 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 your Like what you shared, Brock. Natalia, any thoughts from you when you think of vibecoding?

I know that currently there is a new term occurred, like finance engineer or something like that. So I think that it's— vibecoding 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 like manual workarounds, or we were just waiting for IT and developers to help us, like, put those into life. And yeah, finance people know their processes and know their, like, issues better than anyone else. And now, um, this gap between, uh, like the finance people and the tools that help resolve these problems is, uh, really, um, like it reduces, it is reduced by, by coding. So, um, yeah, I think that's, that's what is, what it is for finance. Not, uh, all of us.

I think it's super well said. That is, in my opinion, exactly what it is because like, When you just think about it at the core basis, it's like you, vibe coding is like you building software or like some dashboard or some visualization, whatever the output is. And it's, 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 like 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.

Yeah, I think a lot of our tasks were just in IT backlog for like years.

I would agree with that.

Now it's better, much, much better.

It is, definitely.

Yeah, there's something to be said for not having to wait for the IT backlog. So how did you get started, Natalia? How, what's your journey? What's kind of the thing you vibed with or what convinced you to say, hey, I need to try this?

Yeah, you know, actually I started quite gradually. So my first discovery was maybe for others as well, it was Claude for Excel, right? So I use it to automate part of our cash, daily cash reporting process through Power Query. So the Claude helped me to write scripts for Power Query. We have, you know, numerous banks and accounts and we have to transform all this information from various sources into consistent format for our cash report. And so Power Query does that. So it was already a significant improvement. But then I thought that, okay, like 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 like result? And that's how my bank statement processing script was born. The first version was really very simple, no user interface. It was just a Python file that I had to open and, you know, run it essentially. But still it, it, it like, it felt to me like a breakthrough, like a huge breakthrough. That's because I, I've never considered myself as a person who can Um, write as a, like a software engineer or developer who can write some software. And now I built something that works, that, uh, actually, um, resolves quite significant process issue because it, it was all done manually. It, it took a lot of time. Yeah. And then I remember that, uh, after like a few days of like very big excitement, I said, okay. Can I like, uh, make it better? Can I make it more like user-friendly, maybe run from a web interface, uh, have a date selector, have a process log and so on? And so that's how I actually started Vibe Coding because I asked Claude like, how can I go from this version to a better one? Um, and yeah, it, it just helped me and said, okay, yes, we can have a web app, uh, as simple as that. And I said, okay, let's do that. And, um, that's how it started.

Love it. Thank you for sharing your journey. And I love that you shared just using it to help with Power Query, right? M code is a form, it's a scripting language, but it's kind of a form of code. And it's a great example for AI. You know, 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, you know, 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, you know, 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, right? SQL, Power Query, or build automation solutions via Power Automate. And so I think that's a great point. I think, you know, there's a lot of different ways we can think of vibe coding, right? 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. And I think we've had the power before. We have more power. You know, 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, you know, Wayne shares, and I won't read all of this, but right, citizen coding can be dangerous if a developed app breaks. We'll talk a little bit about before, you know, being embedded into a process. But then he also shares, I trust Claude Code more than my own coding, right? I mean, Excel files break. So there's back and 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?

Yeah, so I started out, I went to an event back in September of 2025 where we were, it was the Real at Recon in San Francisco. And we heard about this company called Lovable. And I was like, who is this? Like one of their founders was there. And I'm like, I don't even know what this is. Fast forward to today. Like 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 like, I'd never used it. I'm in accounting, I'm in finance. Like, I don't vibe code. I don't have any need for this, right? But we were moving offices and when we were moving offices, we were trying to find a way to create hotel management. So like the desk management tools, we started looking into it. It was $10,000 to $20,000 for us to buy the software. 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? And 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 3 hours later with like a working prototype. I'm like, this is nuts. And I was like, I'm not like, there's no way this works. And then the next day I did a couple UI things. So like total time was probably about 6 hours of me just like, and it was fun. Like it was a learning opportunity for me. And I showed it to the team and it is what we use today. It's a, we, we call it Perch and it's like our, whenever anybody comes in from out of, uh, 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.

I appreciate the use case. I mean, a couple things. One is 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 as much, but, you know, I'm going to vibe code this big, huge solution. And I'm, I always kind of cringe a little bit. I see you nodding your head. Like I've, you know, I've heard someone say, you know, vibe code an ERP and I'm like, okay, good luck with that. You know, let me know how it goes.

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 I just like, My eyes, I'm afraid they're gonna 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 SaaS 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 like, I would never vibe code like 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 like end-to-end procurement tool. I just would not. I would not vibe code an ERP, but I would vibe code dashboards and something that was, uh, visually pleasing for like a, a rundown of Like a flash report or something like that. 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.

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 programs to my website. Probably wondering why affiliate programs. Well, I can't train you on everything, but I can show you and give you trusted resources with exclusive FP&A Guy 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 programs. I also have other programs 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 Fortin, Matt and Carl Seidman with exclusive discount, the top programs, FPAC, FMI, and more. So go ahead and check it out on my website, sign up, and if you have a question on what program is right for you, go ahead and message me. 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 2 examples I've seen that I'm excited about, actually kind of 3, you know, one, you know, 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, Glenn 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're like vibe coded inside of the tool and it makes sure all those are taken care of. 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 You know, FP&A tools, 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 a little bit. We'll go a little bit deeper on that. But, um, I want to touch on token cost. Because I, 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. I mean, how many tokens can you use? I didn't mean to use irresponsible. Okay, I did. But you know, it's kind of like the old days of how fast can we burn our cash and grow. Shouldn't it be how, 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.

That was quite a surprising story. So yeah, just to give a perspective, our company provides a $40 monthly allowance for Claude Enterprise, and I used it in one day, as simple as that. So about $30 went to like me formatting a few Excel tables. And then another 10 I spent for 20 minutes of white coding. Yeah, it was quite, quite an experience. And it was very different from using my personal plan because personal Claude subscription costs about $20 per month. And I've really used it for months and built, you know, 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 experiments, so, you know, like freely within our enterprise, within our company, but the whole budget for the month was used like in one session simply. And that essentially like limits, I think, the possibility to experiment and to find new, like new cases for AI implementation and for automation. Because now when I know that how fast these tokens are used, I will be very cautious to experiment. experiment because I will now just think about, oh my God, this will take half of my budget. What shall I do? And I will not be so, you know, open-minded in terms of like, okay, I have this tool, I can now prototype, I can experiment and so on. So anyway, like the whole story is about that enterprise subscription was meant to, you know, increase, I think, AI adoption. Whereas now, from my perspective, the personal subscription is more like suitable for these needs. Of course, I understand why we pay more for enterprise, but still, like, the cost was quite, you know, big for a very small task.

And I think that's interesting. And obviously, I mean, I do think, you know, enterprise costs 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, you know, there's how do you optimize 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 you'll, Brock, you'll probably agree here, right now token costs are subsidized, right? You know, OpenAI, And Anthropic, it's about growth. And anyone can look at the rumors out there. You can look at the S-1s 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? 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? How do you kind of— and it's just maximizing token usage just in general, wherever you want to take it.

Yeah, I think it's a very interesting thing because one thing, like, I think the different companies have gotten much better with monitoring and like 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. Like 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, is how do you define what good ROI is, right? Because everything there is kind of, it just depends on the person. It depends on the output. It depends on what you're trying to accomplish. If you're just using token maxing just to token max, that'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 am a little, I'm a little fearful of what's in the future. What is, what are costs going to be when those tokens are not subsidized? 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. Very good.

I'll throw that up here.

So 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. 2, I would try to find some form of solution for like, what's the actual ROI? And 3, I would sit down and say, what task am I trying to perform? And is that task, does it, which model does it You will see a lot of success from that.

I just wanted to say that with all those implications and all these questions that we need to keep in mind, it's 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 are much, we can't basically experiment so freely. We have to keep in mind, like, so that we have certain, you know, guardrails, we have certain, you know, rules, what we are like allowed to try, what we are allowed to build, and so on. So it's just much more complicated than it initially—

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 2 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. That's fpandaguy.com. Go ahead and go to Wall of 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, you know, Power Query or, you know, 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, you know, 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. You know, 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've been pricing this, Brock, and you ask it to interpret it, do a 20, 30-sheet model, you're going to be blowing through tokens in a hurry because there's just tons of pieces of information. Every single cell is costing tokens, every piece of information. So I agree with you, Natalia. I agree with, you know, Brock, there's, 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 optimize? What models should I be using? How much freedom do I have? We're all kind of figuring it out together, I think.

Oh, absolutely. I would say too, one of the biggest things that I've, I've noticed is the way that you prompt definitely impacts your outputs as well. And like your token. Well, it obviously impacts your outputs, but it also impacts the amount of tokens that you use. And like, 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 like 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 coworker. So like, as an example, a way that I've found a lot of success is with the output in mind. I'm like, I will sit down and I will talk to ChatGPT and say, these are the things that I want to do. 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, right? 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 like, is that going to be the thing that's like materially going to save you a lot? No, but like, it's just like these little tips and tricks that you do with time that make you better at it.

Another thing that makes a big difference, and then I'll get back to some questions I found, is found a— I actually 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. Like 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 it? 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 just, it's all new. It's a lot of learning for everybody.

It's a ton of learning. It's crazy. And I think one thing that I will say is like, 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, right? Like the first time that I learned how to host on Vercel and use Supabase and all these other things and, and code within, uh, code and then push it to GitHub, like all these different things. Like it was just me being like, okay, I've gotta figure this thing out. How do I do it? And like, 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. So.

And that's true of anything, whether we're automating with—

100%.

AI, with Excel, Power Query. Who remembers the first time they had to write a Power Query? You're like, what am I doing? You're trying, you know, 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, A great point. And, you know, there's, 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, 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 where, what are some of the top candidates where people should start? 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?

Yeah, actually, I would select a process or part 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, you know, clean the data, maybe apply VLOOKUP, XLOOKUP. Then do some pilots, merge with something else, and then like maybe do some visual, 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 vibe coding. And that is exactly the types of work that I automated in my vibe coded application, Finance Control Center, that I have done for myself for my daily work. Yeah. So I would start with some, like, if you have a number of various processes, I would select something that requires a lot of data preparation because it's a kind of work that VACoding can automate very quickly and give you very clear visual form in the way you need. And if you don't like, you can change it very quickly and so on and so forth. So, and the beauty of it is that it uses Python, so it doesn't hallucinate. And because the logic is fixed, so it'll apply the same logic over and over if you need to, you know, like update the file if you need it. So like first month and you need the same thing in the second month or week by week. So it's a repetitive, you know, data processing, let's say this, that you do on a regular basis. So something like that. That's where I would start with.

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.

Yeah, I think Natalia's spot on. Like 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 there are 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 anyone's out there, raise your hand if you enjoy 'em. We'd love to know.

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 like when it comes to judgment and it, when it comes to like 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. 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. If you give an output or if you give a financial report that AI helped generate, but it's wrong, like you can't just blame AI, that it's on you, right? So those are just important things to note, I would say.

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, right, 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, the Power Query, right? If you want something to repeat repeat the same 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? You know, is it, 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 you, how do we think about all this?

Yeah, I think it's, it's a great question. There's a lot to think about and unpack because like 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 like even when you hear the term AI, it's pretty ambiguous and it's kind of a black box. Like for me, like when I sit down and think about it, like I try to clearly define and clearly understand the breakdown of how and when to use the different elements of AI. So like the LLM that I use mostly is Claude. There's 3 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 like a multi-step task tool that can help pull files and be able to upload things and organize your desktop, do whatever tasks you need performed. And then code is where you have like an output. Or you have some visualization that's created as a result, right? So you can use all 3 together. You can use 1, you can use 2. It doesn't matter really. The vibe coding element to me is like when you're using code, right? Code is more vibe coding in my opinion. But when you're using AI, it can be all 3 to be able to perform the various tasks. And it really just depends on the task you're trying to perform. For 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 elaborate.

Yeah, no, I think you touched on something that, you know, can be its own, pretty much its own episode. I'm sure Natalia would love to be around. What are the different tools? How do we think about them? We're all, 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, you know, none of them were anywhere near this fast. So, you know, Natalia, I'd love to get your thoughts. I think you talked a little bit about this, but what would you say people should not be doing with live coding? What are maybe, where do you think the limits are? Or kind of how should they think about that? Are there situations where it's like, look, Don't— AI doesn't make sense here as far as building in your thoughts.

We touched that a bit earlier and I agree here with Brock. Yeah, I agree here with Brock actually, because I also think that we shouldn't wipe code things that are business critical, such as, for example, ERP or even within, uh, if we, if we, uh, take aside ERP, but something that touches cash, for example. Or payroll tax. So, where the impact of error or impact of, you know, 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, I think that's a good way to think about it.

Team and personal versus business critical. I will share really interesting, and I'll see if Brock wants to add anything. I chatted with a guy yesterday, so if anyone's interested, and I'm just going to throw this up here real quick, um, you have till Friday. Drivetrain is actually doing a hack. You can find my, uh, post online about that and go to Drivetrain AI, the FinHack, 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, you know, one's an 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 2 years. He's applied for patents and he's built an entire solution. Like, 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. Like, 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, I don't think any of us would say that's what we should be doing. And so it was really, it was interesting. I'm like, it'll be, yeah, when he submits it, because it was definitely something that was a ton of time. And I'm like, Okay. Yeah, I wouldn't encourage anyone to try to do that in their job. I see Brock going, no, please don't.

No, I wouldn't either. Like, you gotta think about it like 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 right now. Think about your day-to-day process. Think about like, I, I'm an accountant, so like 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, right? What if a payment comes in and it doesn't, it's, it has the wrong date on it? How is that going to be impacted within the ERP? What if I marked 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, A bank statement that like isn't reconciling correctly, and all the feeds are messed up, and I need to remove some of the duplicates. Some of them were duplicates; some of them were not. Like 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 spent like. Saving time and money and like, just pay for the ERP for heaven's sakes. So like, I, I agree. If it is a very, very important business, um, related software or tool, like, it's not worth it. It's just not. And at the end of the day, that, that's the most important thing. Like, do you know, go ahead.

I was going to say, and imagine if you're want to like resign, like what is next? Who will be taking care of that? So yeah, if not, of course, if you are not the business owner, but still.

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 is going to think differently than you. So, you know, 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? Because I feel like that's a, 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 don't really know. Let me think about it for 2 seconds because for me, there's so many things. Yeah. Let me think about it for 2 seconds.

No, you can have a minute to think about it. Do you have any thoughts there, Natalia, you can share?

If we think about that, Not every tool we need to maintain forever, right? So, I think, again, if I, if you think about the vibe-coded apps as like tools for personal productivity versus team productivity, then a personal productivity tool can be personal and it doesn't have to be like, you know, transferred over. So, the new person can use the, or create its own. for this work. But yeah, if we think about like team productivity tool, like that is shared maybe within the team, then I think it's important that we have certain, you know, handover process. So we shouldn't maintain it alone or the person should not maintain it alone. We should maybe like involve IT team. We should host it in some, you know, 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's It still can be okay.

No, appreciate that. Brock, have a little time to think on it?

Yeah, I think that's spot on. I, I think it really depends on the organization as a whole and like what tasks you're trying to perform. Like from a security perspective, the best way for you to just be completely safe is like if it is something that is not locally hosted. So like when you create tools, you can be able to just have it locally hosted on your desktop, which is pretty safe, right? Like, but when you actually start to have things hosted, you should always be running that through the security teams, like no questions asked, in my opinion. But when it comes to like just cross-collaboration, there's so many ways to think about it. And like there's companies out there that are doing a very, very good job of like sharing these tools. Like 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. It's always done through the security team. Another way of sharing like some of these skills and things that you've built are, well, it's become easier to share skills specifically, but like when it comes to like outputs and like code and other things like that, Usually you have like some form of a private GitHub repo that's only shared with your team that you can be able to upload those and then have your team download those. So I think it really just depends on the team, but like, I would always, like, if we're just talking about from a security perspective, you should always involve your security team for sure.

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, you know, whatever those may be, always have that conversation. I think the second side is there's the long-term maintenance, which is something You know, engineers are designed for. It's why you'll see a little bit more of this finance engineer role is, you know, 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. Is that good? Is that bad? Depends on who you ask. 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 the right documentation. Doesn't mean it's foolproof, doesn't mean it's not going to break. Those are things to consider, but that— I don't think that's enough to stop somebody from experimenting. I still think the right decision is to experiment. I'm going to take a couple of questions and I'm going to ask both of you kind of your final thoughts and we'll wrap up here as we're coming up on the top of the hour. So, you know, someone asked a little bit more about cowork. I saw a few comments there, so I'm just going to share one thing. You know, someone said, It's desktop-based for me. Yes, Cowork sits within the Claude 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 color there since there are a couple questions. I would encourage anyone that's trying to understand, if it's the Claude library you're trying, whichever one you're trying to understand, whether it's Claude, 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. And you know, there's a lot of other sharing things. I know, uh, you 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, they 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 I 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 modeling or Excel, because you'll be better with AI than if you didn't know it. All right, we'll do one more here. You can quickly write code in Excel add-in that can be shared with coworkers for your productivity macros. Yeah, Clad Code. Yes, you could do that. So you could even, you know, 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's good. If you're putting an add-in 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, 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?

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, right? Like Claude and understanding Claude, like the platform, understanding Cowork, understanding Code, things like that. Very, very, very helpful. But like, just in general, the thing that I would say is you don't have to feel this like pressure to vibe code every single tool. You shouldn't. Like, I think that's just silly to just think that, nor should you. Like, at the end of the day, you're supposed to be doing your tasks and your job effectively in a good manner and like 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 this huge pressure to vibe code everything. Just take it case by case. And if it makes sense, try it, like be surprised and be impressed with what you're doing. Right. 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.

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.

Yep.

Natalia, we're going to give you last word here.

Yeah. Good luck everyone with life coaching. I agree totally with Brock. You should not start with like 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, you know, super cool. My first tool was not beautiful at all, but it was enough to, you know, give me the excitement and to understand that it can work and it will 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.

So I need to create an avatar to do my interviews. No, I'm kidding.

I love doing interviews.

Joking. All right. Thank you, Natalia. Thank you, Brock. Loved what you shared. Thank you everybody for joining in the participation. Wayne, Kevin. I know 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.

Absolutely. Thanks for having us. This has been awesome.

Yeah, that was great.

Thank you. 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 5-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 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. Thank you.