Vibe Coding For Cybersecurity Marketers (not dummies) - Joseph Barringhaus VP Marketing Maze

Are you struggling to stand out in the crowded cybersecurity marketplace? Wondering how to build unique marketing or sales assets without a dedicated engineering team? Curious how other leaders are leveraging AI-driven “vibe coding” to create real value, not gimmicks? This episode is packed with proven, creative ways cybersecurity sales and marketing pros are innovating faster than ever.

In this conversation we discuss:
👉 How “vibe coding” tears down traditional barriers to building tools and experiences for buyers. No developer background required
👉 Real-world examples of internal and external tools that drive sales and engagement, from pricing calculators to viral, satirical content sites
👉 The practical steps, mindsets, and pitfalls for teams who want to experiment and win more attention in their market

About our guest:
Joseph Barringhaus is the VP of Marketing at Maze, a high-impact leader in the cybersecurity world. Known for his high-energy approach and relentless creativity, Joseph specializes in hands-on marketing innovation.

Summary:
Tune in as Joseph Barringhaus shares his team’s journey in bringing “vibe coding” from experiment to game-changing practice. Learn how to build powerful marketing and sales assets, get buy-in for creative risks, and inspire your organization to try new things. Listen now and spark your own ideas for RSA or your next big campaign!

Links:

• Connect with Joseph Barringhaus on LinkedIn
• Learn more about Maze
• Book a 30-minute strategy call with Andrew Monaghan

Fast ramp to revenue for your new sales hires

A proven training program to get your new sales hires productive in just 4 weeks using your content and sales process, but without using your own headcount.

Transcript

Andrew Monaghan:
You know how when you talk to someone and they're so passionate and excited about what they're doing, it just kind of inspires you and rubs off on you? Well, that's what we have today. Returning guest Joseph Barringhaus, who's the VP of Marketing at Maze, is joining us today. Joseph actually was on stage at the Cybersecurity Marketing Society's conference in Austin in December and did a whole session about using vibe coding in marketing. And I saw the buzz about his talk, so I invited him onto the podcast. He's gonna talk about how easy it is to sit there with no developer experience whatsoever and start trying out ideas about how you might be able to make your life better, either in sales or marketing, or engage with your prospects better in different ways that you may or may not have thought about in, over the years. There's no doubt that thinking that this was possible 10 or 15 years ago would be crazy talk. But now it's real. It's here today and it's possible.

Andrew Monaghan:
So stay tuned. So, Joseph, you are a second-time guest on the Cyber Go-To-Market Talk podcast. Welcome back.

Joseph Barringhaus:
What's up? Thank you. Glad to be here.

Andrew Monaghan:
Yeah, I feel like it's been quite a while since we talked last time, but not that long. Just over a year, I think it is.

Joseph Barringhaus:
Yeah, it was a good time. Last time around, I think you grilled me on, on KPIs and planning, if I remember correctly.

Andrew Monaghan:
Well, let's talk about something a lot more interesting this time.

Joseph Barringhaus:
Fair enough.

Andrew Monaghan:
So the prompt for this episode was right after the Cybersecurity Marketing Conference in in Austin in early December, there's a few posts went out, people saying I was there and it was awesome and fantastic and Gianna and Maria did a great job. And then they were saying the highlights of the conference. So friend of the pod, the legendary Scott Tashler, wrote down his number one highlight of the conference, Joseph Baringhaus showed how he vibe codes cool shit without an engineering team or agency. And then Gerald Auger of Kairos and Simply Cyber said he got an accelerated crash course on vibe coding. It was a well-laid-out talk, had tons of takeaways, and the speaker with great energy, Joseph, said, the pressure's on, you got to bring the magic today.

Joseph Barringhaus:
I got a smile or something crazy.

Andrew Monaghan:
And, uh, and he said you had an obvious passion for sharing the knowledge. So that's why we're here. I'm kind of intrigued, what the heck were you talking about on stage at the conference that the rest of the world of cybersecurity marketing was paying attention to and loved so much.

Joseph Barringhaus:
Yeah, we talked about vibe coding. Like that was the high level and there's this fun conversation about can we stop calling it vibe coding?

Andrew Monaghan:
I don't know.

Joseph Barringhaus:
I still think it's fun. So I'm going to keep calling it that until we come up with a better term. But it was thinking in two parts. Part one, how to use these tools. And part two, like tips to actually build cool shit that attracts your buyer. And I think that was the big, the big part of that was we talked about like vibe coding your way to the next promotion that you may get, or thinking outside the box. But the core function of all of that is, can you think about stuff that your buyers will actually care about that's relevant to them and/or making your own life better? And so I think those are the two pieces that we broke the talk up into. That's kind of the kickstart piece.

Andrew Monaghan:
Yeah. Well, let's go back to Scott's comment. He said, cool shit that you've built before. Your top of the culture. Give some examples like what, what could this mean beyond just using these tools? What could a marketing person or salesperson build with something like this?

Joseph Barringhaus:
Yeah, I'll talk through some of the stuff that I built that we've— not even I, that we as a team or the people I've worked with have built too. I think it's maybe, maybe this is a little bit of a challenge first, but when you're starting to think about the ideas to execute on, like the barrier to execution is so low now, like it's not hard to go build these things. The idea itself is often the thing that's the harder point that you can't go and ask an LLM to create. So this is going to sound maybe kind of harsh or rude, but we live in this world where the creative people win. And even if I vibe coded the app for you, if the idea was shit, it wouldn't matter. And so that's why it's important to think about, I think, how you can use it. So there's internal and external examples for sure. Some of the internal examples I've done, just at companies even that I've been at, um, an internal pricing calculator.

Joseph Barringhaus:
Everyone, and Andrew, you're on the sales side of the house, you probably had a spreadsheet or multiple spreadsheets at different worlds that help you calculate the price of the cost of your product. And, you know, it was probably this ugly sheet that you had on the side screen while you were talking to a customer when they said this number of things, this number of users equals this dollar amount. It's like even just something simple, like an internal pricing calculator. How much does this thing cost? How much should it be? And actually, we found that even pulling that up in the middle of a conversation, now I have an asset that I can show to them and have them help me fill in the pieces. It becomes almost like a visual aid, if you will, versus this spreadsheet on the side that I'm not allowed to show kind of thing, you know? And then baking that into making it, now I add a discount to it. And so now I have an external piece as well that I can show the customer. Like, now here's the price that I can apply a discount for. Like, it won't even let me go higher than this because someone has to sign off on it or whatever, right? I built, uh, one of the least favorite parts of my job is, uh, is budgeting.

Joseph Barringhaus:
I hate it. It's always the thing I don't like. I'm decent at it actually, but I really, really hate it. And so I built a budget app that I use myself instead of a spreadsheet because I was tired of using a Google Sheet and having to go and change things every time, uh, and update formulas 1,000 times. So we just built a budget tool instead for internal use. You could create something like a tool for sales enablement. There's platforms that you can buy for sales enablement. If you're an early stage startup, you probably don't need that.

Joseph Barringhaus:
You probably need the ability to ask quizzes. And get the answer in real time and maybe see how the rest of the company did and track that. That is a very simple prompt for an internal team to go build. The list goes on. Now, like external use case, things that you can think of, uh, we rebuilt a resource center at one of my companies, at one of the companies I've been at. We rebuilt the resource center in one of these Vibe-coded tools, gave it a ton of screenshots of things I liked, and then had it spit out the resource center in the exact way I wanted. And that's not really that novel. It's not even something I would ever use externally, but it made it to where my internal team and I could work quicker on the thing that we actually wanted to go build..

Joseph Barringhaus:
And so instead of being like, ah, designer, I want that button over here. I want this thing to be that color. I want this hover effect. I just built it and then I sent it to him and I said, now let's go make this polished because it's close enough, but let's go polish it. Now the really external things were we built a game for this event that we put on in a past company. We built a game that went inside of the event. It was a Rock 'Em Sock 'Em themed game where you could actually play and you look at the webpage where this was on. With the exception of the registration form, the next most popular section of that page was the game at the bottom.

Joseph Barringhaus:
So people would scroll down to register. They skipped right past the agenda, which was wild, right past the agenda, filled out the form. The game was right below it. And then they played the game after they filled out the form. Just like little things to make the content we're already creating more exciting. I'll pause for a second before I share my favorite one, but go.

Andrew Monaghan:
Yeah. Yeah. So rewind 10 years. I mean, you wouldn't even be thinking that these things are something you would do, right? You mean, you know, no one would.

Joseph Barringhaus:
Think to build a game 10 years ago, I'd have to hire a frontend engineer, backend engineer, something, tons, tens, if.

Andrew Monaghan:
Not hundreds of thousands of dollars in a 6, 9-month project. And, you know, just unbearably hard to justify internally the whole thing. It's funny what you're saying with the pricing calculator. I remember 20 years ago when I was selling at McAfee, I think I'm right in saying this, we had one spreadsheet. It probably had, I think, I don't know, 15, 20, 30 tabs along the bottom. Each tab had maybe hundreds of lines of SKUs and little things, and, and, uh, you dig around, try to figure out what you're supposed to be quoting for what and how it all works. Was, was so difficult. The idea that you just type in maybe somewhere and say, look, I'm trying to sell this thing and this sort of configuration, you know, give me, spit me out how it might look like, right? And then I can adjust it.

Andrew Monaghan:
That'd be huge for, for a bigger company.

Joseph Barringhaus:
Um, I legit, we just built this one.

Andrew Monaghan:
You tease us with your favorite one, so come on, what's the What's the favorite one that you, you got?

Joseph Barringhaus:
There's actually two. So one only be— it's only my favorite because it's the most recent, but there's an internal tool that we just built. We're doing sales territory planning. It's that time of year, right? We're doing planning for next year and for reps that come in and maybe where we go. And you used to have this maybe Google Slide or PowerPoint or a long, again, a long Excel doc with every territory and state and zip code and region. And again, created this app in, uh, one of the tools we'll talk about in a minute, but created an app that basically every time we want to go change it or we need to go change a piece of it, I just tell the LLM what to go change. And an interactive map that's hosted on a website that anyone can go access can adjust and make it to where the team can go and see and export their territories. They get to see a changelog of what was changed and what they lost or what they gained.

Joseph Barringhaus:
We can break it down into these little tiny minutiae of like, well, I own this part of California, but I own this part of California. If you really want to be crazy like that. And so you— we've broken that out, and that's my favorite internal one at the moment. The absolute coolest thing, very appropriate for this time of year. Exactly, exactly. Like budgeting for marketing, uh, territory planning for sales.

Andrew Monaghan:
Salespeople are sitting there right now. We're recording this on the 13th of January. How exactly am I being screwed in my territory allocation this year?

Joseph Barringhaus:
And show it to me. I want to see exactly how you took it away from me.

Andrew Monaghan:
Who has got to get pizza by territory.

Joseph Barringhaus:
I think that's like the— before I share the favorite one, like, that's the thing though. Like, that, that's what we try to challenge ourselves internally. I've got— there's an awesome, uh, GTM engineer on my team. His name's George. Uh, does an awesome job at this of when we're thinking about a problem, we start with the problem and then we think about ways we can solve it using these type of technology, which is almost a shift in your head of like, well, for 10 years I've made a spreadsheet in Google Sheets. It's like, no, for 10 years you've done that, but that sucks. And why would we do that again? Can we think of a better way now? And so there's a challenge that we almost have to retrain ourselves to think, can we think in a different way? And again, he does a great job at it. I think, like to think we do as well as a team and just thinking in that different way.

Joseph Barringhaus:
You asked, you know, a second ago, creating this stuff 10 years ago is impossible. My favorite thing that we've built thus far, again, shout out to George, who I just mentioned, who actually was the one that put hands on keyboards for the majority of this stuff, was the exploit. Think of it like the Onion meets Hacker News. So if you go to theexploit.co, you'll get the website. I promise it's not a vulnerability site, but if you go to theexploit.co, you'll get this mixture of the Onion if it was all security themed and jokes. And on there, we've got stories like burnt out CISO forced to decline Michelin-starred roundtable. And that was written by a CISO that was a friend of, you know, a friend of a friend of a friend. We've got one that pokes fun at one of those really famous review sites where all of the reviews just happen to sound like almost the exact same.

Joseph Barringhaus:
Mine's in the top right corner, or mine has 17 stars that are, you know, 4.9, not 5, because 5 sounds too, too unreal. Um, and that story is called Tech Buyers Excited to Outsource All Cybersecurity Decisions to Company That Just Learned What MFA Stands For. Like, I literally couldn't come up with all of these things on my own, but if you give people this forum to create, they will. And if you give this, this, if you poke fun at yourself, admittedly, like some of the stories that we wrote, are us poking fun at some of our own ideas of like, you read it and we talked about, uh, announcing 2026 predictions for the year. And I literally was sitting there thinking that one was written by me and somebody else on the team as well, George again. And it was when we were writing that, we're like, I keep seeing these vendor predictions and every single one of them just happens to be like, number 1, not my product, but number 2, 3, 4, 5, 6, my product. Crazy how my roadmap aligns exactly with those predictions. And so We were just like, let's just poke fun at ourselves because we were talking about doing a predictions post and that was like, no, that's dumb.

Joseph Barringhaus:
We're not doing that. So we went and made fun of it. And I think that's just like, again, think of an idea that would attract your buyer. That's what we're trying to create. Now the barrier to create that thing, that was actually about 2 weeks worth of work, which we can get into the how in a second. But like that 2 weeks of work meant we weren't working on anything else for about 2 weeks. And that's a lot to give up, but there's a balance of, of value that you can get from these things that you wouldn't have been able to get.

Andrew Monaghan:
You know, I'll, I'll second you on going to the exploit.co. When you launched it, my favorite one I saw was the headline is security engineer finally completes homegrown SIEM. Only took 12 years and 3 divorces. Yep.

Joseph Barringhaus:
And it's just like, it's so funny. Yeah, it really is.

Andrew Monaghan:
But let's talk about this. So you're not sitting there writing this out word for word and doing a whole kind of writer's room about is your satire better than my satire. What are you using the vibe coding for to make this so easy?

Joseph Barringhaus:
Yeah, so the technology itself that vibe coded the majority of that, we used Cursor for the majority of it. There's a ton of tools we can go down and like where to go on tools in a minute, but we specifically used that solution Cursor to build this, George did. And the actual prompts to create this are arguably more important than the tool you use to create. Like, you can't see it obviously, but there's a whole backend to the site, a complete backend that connects everything together and pulls everything and loads up in real time. That's how you experience the actual site. It's how you see that there are authors on the site. It's how you see dates that exist. But again, the, the creation process was how can we make this really easy for somebody to enjoy, for somebody to submit, and for us to manage? And then so we thought those three, three things, and then we worked backwards., and there's this concept of, of, uh, like thinking what the end state should be when it comes together and then building for that.

Joseph Barringhaus:
And that's kind of how we tried to think. And actually, even in our, our retro of building that, we, we started talking about like, we actually will do a better job next time of that. We think we did okay, but there's a, a, an even better way of, of building with the end state in mind so that the end user receives what they wanted.

Andrew Monaghan:
Um, yeah, in that one example, you do the 2 weeks of work to build it and then going forward, if I remember rightly, you just put in a little prompt about, here's, I think something like this is gonna, here's what the kind of punchline is, whatever. And it just spits out, you know, I don't know, a 300 or 400 word article, paragraph by paragraph, satire all the way through, punchy examples, all done for you, right?

Joseph Barringhaus:
Yeah. And so there, that's part of the, there, there's two pieces behind the scenes that happened when we first were building it and we were going through early iterations that George put together. Myself and our CEO, we were looking at it and we're like, who's going to actually go submit the story? Like, this is a lot of work to write the story and write it really well. Like, okay, well, is there a place that, again, thinking in a different way than we would have thought 10 years ago, is there a way that an LLM could write this for me and make me the editor of my own story? And so in the submission section, we made it to where as you submit a story, the headline, you write a headline, you write part of the story, like almost as if you're giving it bullet points. And then there's this little part that pops up on the, on the on the submission form that says, hey, copy this prompt. And if you copy and paste it into LM, it does a pretty good job of getting it to a good point. You can put it in ChatGPT, Claude, whatever you want. And it does a pretty good job.

Joseph Barringhaus:
Now we also then have a BS meter on the backend that says, hey, how much of this is written by, you know, AI. And if it doesn't match, uh, you know, a true story that's about something they experienced, then we'll try and go edit ourselves or revision, which again puts the human in the seat. So we've got people on our team, contractors that'll go through and rewrite and re-edit and then submit and share, which, you know, have experienced as well. Um, and we want to make sure like it, it matches the tone and the vibe and we help as well along the way. But in the beginning it was how can we get someone to submit? And so we were thinking about ways to make it submit. A lot of the exploit staff articles you see, those are actually also written heavily by LLMs, not exclusively, um, because that would be boring and suck. But the stories itself came from other RSS feeds. So in the backend, George set it up.

Joseph Barringhaus:
To where an RSS feed from Hacker News and from all sorts of other places where news articles are genuinely published come into our system. It analyzes it with an LLM and says, hey, what's the angle we could take on this funny thing? And then it goes and writes, you know, a couple sentences on it. And then I get to go give input and feedback to it and be like, hey, that angle sucks. Like, this is a good story. Here's how we should kind of handle it. And so, for example, when the AWS DNS issue happened earlier this year, we went and wrote about the AWS DNS issue. When the Cloudflare issue happened, it came in in real time. We wrote about the Cloudflare issue in real time because, hey, we made it to where the barrier to start was so low because I already had a starting place.

Joseph Barringhaus:
Now I get to go become a copy editor and a copy, you know, a cleaner, not a writer from a blank page, which is always the hardest place. So like our, our Cloudflare one was live following AWS's lead. Cloudflare also attempts turning the internet off and on again. And like that was the headline that then led us to an amazing story within. So again, we've made it to where it's this repeatable function that can be built upon.

Andrew Monaghan:
So let's, let's kind of go back to first principles then. You know, we've got, uh, we got listeners, let's say a marketing team at a company, you know, they're, they're like you were thinking, we need to get our unfair share of attention out there. We need to, you know, get some pipeline. We need to, we can't go to RSA and be hidden away and forgotten about. We gotta do something a little bit different. So let's go back, right? How, how should they be thinking about starting the process to figure out what is it that we could be doing?

Joseph Barringhaus:
Yeah, I think you need to be— this is going to be kind of harsh as well, but you need to be in an environment where you're encouraged to take chances and take risk in addition to an environment where you're encouraged to try things. So it's like, take risk. Yes, no, it's not going to always pay off. And then flip side, like the rest of the people around you need to be encouraging and supportive and also knowledgeable in that. And I give a lot of props that I'm at an AI company. Like we are of course using AI. Everyone from our CEO to our VP Ops to the engineers to the marketing team are all using AI in every capacity of our work in different fashions to make ourselves faster and quicker. So I think that like part one is you need to be in an environment where that's allowed and encouraged.

Joseph Barringhaus:
And if you're not, you're probably at a company you shouldn't, like you don't want to be at that company anymore unless that's your vibe. The second piece is be willing to make bets. And so like willing to, when we first started about the exploit, we were like, maybe this will pay off. Maybe it won't. I have no clue. I have absolutely no clue. We talk about if it did it in a second or not, but like, it was just a bet. It was 2 weeks of time.

Joseph Barringhaus:
That's expensive time, like to, to be spending a heavy amount of it on this. But we started with the first principles of thinking like your buyer. And so if you can think like your buyer first, then you can go build cool shit. So like, where do they hang out? What social channels are they on? Are they on Reddit? Are they on Discord? Are they on Twitter? Where are they? What do they do? Do they go to conferences? What kind of conferences? What do they talk about there? What sessions are interesting? What do they hear on podcasts or YouTube or whatever? And then what do they care about? Like, is your audience compliance focused? Is it, you know, are they scared about an audit? Are they vulnerability focused? Are they identity focused? What does your audience actually care about? And then what's a day actually look like for them? And I used to think that this was really, really hard to do because customers were gated or whatever. And maybe I'm in a different place in my career now, but at the time, I would just say, fine, I can't get to a customer because the customers are owned by whatever team or whatever at a bigger company. Do you know how many of these people are on Reddit? Do you know how many of these people are on Twitter or on LinkedIn and would take a DM and be like, hey, I live in Dallas. You also live in Dallas. Can I buy you coffee and just learn about your, like, what the hell your life is? I work in content.

Joseph Barringhaus:
I'd like to make something that people actually care about and not some BS on the, on the internet. You will get surprisingly good responses from people willing to take you up on that kind of thing. But you have to be willing to want that.

Andrew Monaghan:
And the purpose is that you want to show them in the, with whatever you build, that you get them, right? That they're gonna feel like these guys know my role. They, they get it, right? They appreciate what I need. They appreciate the angles to do a satirical article, whatever it might be. They just get me and therefore I'm gonna be more attached to that company is, is what the thinking is.

Joseph Barringhaus:
100%. And I, I think once you have that understanding, then you can do this you can do this creation idea of I now understand who they are and what, like, what they are about. And you can take that into this. Tom Orbach, the director of growth at Wiz, has this great format that I shouted out in the talk as well. If you take this format and match it with an audience, you get some pretty interesting concepts. So if you understand what they care about, you can then match it with that audience and bring things together. And so like, you can put this in mind with, yeah, the toy store for CISOs, which they created over at Wiz. Again, a great idea of something that is relevant to my industry, is different, and I cared about.

Joseph Barringhaus:
So I give some props to them for that, of like coming up with this creative idea that aligns to, you know, the buyer. It's really easy to come up with out-of-the-box ideas that are just absolutely unnecessary, astronomical, wouldn't care about. But if you can actually bring it to where like, I understand you're a security company too, that's the real challenge. I, we made fun of this the other day in a nice way, kind of, but like a petting zoo at a booth in RSA. I don't know what you do. I pet a goat. Like, are you the goat? Maybe? Is that the reference you're trying to give me? But like, I just don't— please don't do a petting zoo at RSA this year, people. Please don't.

Joseph Barringhaus:
Like, that's just not the thing. Go do something different that stands out in a way that I wouldn't have been able to come up with, but aligns to what you actually do or kind of the space you're in.

Andrew Monaghan:
Yeah, that's a great point. I saw the petting zoo. I couldn't tell you who the company was that did it, right? So really good for attracting attention, but that's not screaming, these guys get me, they know my job, they figured they know my challenges, they're out for my best interest. Basically what they're saying, I think, is, hey, they just want my attention.

Joseph Barringhaus:
Yep. Which is fine. And that can totally— like, there is a scenario where the goal is just to get attention. Like, in this super noisy space, the goal can also just sometimes be to get attention. And that's fine. You just need to accept that that's the goal. And so when you're setting goals for the thing you're building, make sure that that's aware at the company, or you will not have a job. Like, if your goal is to get attention, and it can lead to things down the road.

Andrew Monaghan:
I remember 2, 3 years ago now, I think, on the podcast I had, uh, David Klein on. David is the CMO at Kentik, which is an observability company, not really in cyber at the time, but I think they've moved more into cyber. And he, uh, if you look at their YouTube channel, um, they, uh, their videos are a lot of, you know, how-tos and use of product, and they have like 2 or 300 likes or views each time, right? And then they got 2 or 3 which have 50,000 views. And what he did was in an afternoon with one of the guys in his team, they filmed an advert, a perfume advert about Cantique, and it was about the sweet sense of observability. And if you listen to the actual, the talk track that he goes through, I mean, it's just like the, It's like the French perfume advert, all the kind of emotion and all the rest of it. But the words he used were kind of attached to kind of this guy would get why observability is so important for, you know, the people that they were targeting. So it, beyond being a funny thing to do, it was actually attached to the important things that the prospects are thinking about.

Joseph Barringhaus:
For sure. And you know, there's two points of it, right? Like one is to create attention, one's to create attention for the space you're in, or at least aligned to the space you're in. And you can go either way. Like you really can. You could go create a Tinder 2.0 that your company owns just because you could. Like, that's probably not the thing that's going to attract your right buyer. Is that who, again, is that who my persona actually is? Are they on this app? I don't know. But like, think about, think about the thing that actually would bring somebody in for your solution.

Joseph Barringhaus:
And that's not to say you shouldn't also go create a petting zoo, just like try and bring those two things together in some capacity, you know?

Andrew Monaghan:
Well, let's say this, our team, our small team of marketeers got to the point they got a couple of great ideas and they're thinking, well, you know what, we just like to try these out, see what we can, see how far we can get. And they're looking at the Google vibe coding tools. There's gonna be a few that come up. What should they be thinking about? Which one should they be thinking about? How would they even get going?

Joseph Barringhaus:
Yeah, so first of all, there's some really good videos to go watch and I'll try and share some of them as well. And maybe we can put 'em in the show notes or something like that. But the basics in my mind, you need a GitHub account. If you listen to the CMO at Incident.io, Tom, also another Tom, he'll talk about like in interviews, he'll brag about the fact that I have a GitHub account and like, you know, looking at developer jobs or security jobs and it's like, I have a GitHub account and that's a rare thing. There's only a handful of marketers that can truly say, I have GitHub, know what it is, know how to push to a repo, know what, you know, a branch is, know how to submit a PR. Or even what a PR is. Like those things are pull requests, by the way, those things are like not super common for marketers to actually know.

Andrew Monaghan:
I'm glad you told me.

Joseph Barringhaus:
Yes, I got you. I saw, I can see, but like there's only so many marketers that know what those things are. And so learn the basics first, learn how these things actually work and the backend behind them. And so in my mind, a few things you really need on the basics, GitHub account. I think you need a basic understanding of domains and even just application architecture, how those things work. ChatGPT is your friend. If you don't know how these things are, go ask ChatGPT or Claude how an application would actually be built. Like if I say the words you need a frontend and a backend and you have no clue what those things are, you are not ready to go create an app yet.

Joseph Barringhaus:
You should do a little bit of reading first. Frontend controls what is actually displayed on the site, how it's bring— comes to life. Backend controls all of the storage of the thing on the site that's displayed. So think like the frontend calls to the backend, the interaction on the frontend will change the backend, but you need to understand how those things work more than the 30-second clip I just gave you that was Mostly correct. You probably should then go get a free account with one of the vibe coding tools. Like, don't go dive straight into Cursor or Claude Code is my recommendation. Some people think you should just go into the deep end. I wouldn't recommend that.

Joseph Barringhaus:
Like, start with one of the free tools, um, which we talked about in a second. And then the advanced side of the house, once you get that basics down, go work on getting a database, a backend, something like a Supabase. Go get, uh, one of the IDEs like Cursor or Claude Code or Codex, which is ChatGPT's version, or, WinSurf or any of the other IDEs that are more specific to actual developers, then go play with N8N or Zapier and trying to make things actually interact between each other. And so like the RSS feed that then calls an LLM to then send us a story submission, that's done in N8N. And so like think about the ways to build that piece together. The super advanced, like extra advanced would be building all of that with an AWS or within a cloud provider like Google, Probably not Azure, but AWS or Google, you could go do that. I will not be doing that myself personally, because I don't need to. There's enough tools that I don't need to go learn that yet, and I can still do pretty cool shit.

Joseph Barringhaus:
And so that to me is the basics and the advanced. We can talk about the tools too if you want, but maybe tell me where you want to go from there.

Andrew Monaghan:
That's a good, good little spiel. My experience is I played around with Bolt. I played around with, I think, Lovable. And, you know, if anyone's not done it before, you know, someone like me just goes in there and you get to a box and it says, what do you want to build? You just type it out. I wanna build an app that does, you know, pricing, pulls from a pricing model and gives me an output of a quote. You know, you, you put in some examples of, I like blue and green and here's some UIs that I like. I need it to work off, you know, I don't know, a Google Sheet with 5,000 rows in it and the output's gonna be on a single page. You just give it, you just talk to it basically.

Andrew Monaghan:
You know, you should actually get like, Is it Super Whisperer? I think it is. And you just talk and it just puts it all in for you.

Joseph Barringhaus:
You don't even have to type it.

Andrew Monaghan:
Oh, Whisperer?

Joseph Barringhaus:
It's Whisperer. Man, Whisperer. This goes back to like our team constantly being building things, you know, and like trying new stuff too. Our VP of Ops introduced, his name's Phil, introduced me to Whisperer. And oh my gosh, it is life-changing. Like the speed at which I'm talking right now, I'm a fast typer. I grew up with technology like this, you know, but like I cannot type as fast as I can talk. And boy, is it a life-changing tool.

Joseph Barringhaus:
Yeah, please. I'll send you guys my, uh, my referral code. You can go get a Whisper trial, you know.

Andrew Monaghan:
Uh, but no, really also cool. Yeah, it's amazing, right? You just, you just talk for like 5 minutes and then I'll just drop it right into the box for you. And then you, you hit submit and it just starts building you your app.

Joseph Barringhaus:
Is basically how it works, right? Well, for sure. That's exactly how it works. Yeah. It's, uh, think, think Siri, but 10 times better than Siri and way better.

Andrew Monaghan:
At formatting as well. Yeah, and then, you know, once you've done that though, what do you get back? Like what's the, you know, you said it took 2 weeks. I mean, I'm sure there's a bit of iteration and it's not gonna be perfect, it's AI, right? It's gonna get things a little bit wrong, then what?

Joseph Barringhaus:
Yeah, so 2 pieces to it. It depends if it's an internal tool or an external tool. If it's an internal tool that you're not putting sensitive data into or any type of data like that, it's not that big of a concern, right? Like the pricing calculator I mentioned, Sure, if you wanted to go and try and DDoS the site that we built it on and try and figure out how to actually, like what the URL string was for it, you could probably find it. I actually don't really care that much. So like, that's okay. But the majority of the things you're going to build, if it's internal facing, it's not that big of a deal. So like security that everyone is always terrified of using these tools. If you're not putting sensitive data in it, you can be a little more flexible with it.

Joseph Barringhaus:
I'll give you an example too. Our designer, who's a contractor for us, is an amazing designer. He went and built an internal tool for us that basically takes an image, a PNG that I upload, and our brand has a bunch of little particle dots in it, which is a pain in the ass to create anything with particles in it. But he built this little tool inside of, uh, v0. That was the one he used. He used v0 to create this little tool that when I put a PNG in, it gives me all of the dots back in the shape of the character before. And I can change the size of the dots, the shape of the dots, and how often they are and the color they are and all the above. Like that would have again taken him probably 5 hours to do and instead took him 5 minutes.

Joseph Barringhaus:
Uh, and so like the speed that you can create that kind of app, I could care less about it having any sort of security checks in place. Not a single one. Don't care. The flip side of that being I'm very security conscious when it comes to data that is any sort of PII or any sort of confidential information. So you should all have that in the back of your head of if it does have some sort of user data or something like that. Think about the end state, talk with your security team, especially your engineering team. I work at an AI company where I can go ask them questions like this and be like, help me build this thing the right way, which we did for something like the exploit. It's like, help us build this the right way and then go gut check it for me when it's done.

Joseph Barringhaus:
Let's make sure it was done right. Um, so I just think that's an important call out to put in the beginning. If you're a beginner, go use Lovable, v0, Base44, Bolt, or Replit. Like any of those are really good tools to get started on. Lovable has this thing called Lovable Missions, which are basically like little practice tests. And so they just came out with it for people that like have no clue how to go and create a prompt or vibe or anything like that. And so it'll basically give you the ability to go do practices, uh, without costing you any money because you don't get that many tokens with Lovable or anything like that when you're on the free plan. So it doesn't cost you, but you can go learn how to prompt.

Joseph Barringhaus:
And so we can go through the prompt basics in a second, but go try one of those tools that's very early on. And then again, go accelerate to your more intermediate styles of like, I did Lovable. Now I'm going to go save my Lovable code in GitHub. Now I'm going to go use Cursor to adjust the copy or the code that Lovable created originally. Now I'm going to go add a backend like Supabase or something like that. And so I think you get, you know, progressively stronger or stronger as you go. But the biggest thing here, again, like when you go to build, what's the one thing you want to create that you've never created? Like your job is to go think about that and then go just try and do it. I started with a personal app at an old company.

Joseph Barringhaus:
I led this training in an all-hands, and it was like, everyone's going to spend the hour right now in Lovable just building something, which is actually a really good challenge for any early stage team that is small enough that you can do something like that. We spent an hour where we all— I pulled Lovable up, I signed into my account, and I said, I'm going to go write a prompt, and so are y'all. And we all went and created stuff. The sales rep on the team who wasn't the most technical person in the world but was awesome was like, I'm going to go create a caffeine intake for Joseph. And so he went and created this spreadsheet of Texas caffeine intake and like created this where I can just go put how many cups of coffee I had in the day. And it told me how many milligrams of caffeine and how many Red Bulls I had and how much caffeine I had. And it's one of my favorite things that has ever been created. So I'm going to go send him a little thank you after this as well.

Joseph Barringhaus:
But I just, because he could, he went and created this thing. It's a, just challenge yourself to think outside the box. We talk about the props too.

Andrew Monaghan:
Yeah, that's a good point. I mean, you don't need to build the exploit, take 2 weeks to do it, and, you know, build something so big. So most of the things, like, I'd be thinking about how do I do something small just for fun and see how I do. And then if I hate the whole thing and it just bamboozles me in the brain, I might not do it again. But maybe I learned something and I'll try something. Oh, let me try this a little bit differently, right? I think getting going is going to be the thing that most people have to do, and then, you know, have the stamina to just keep going a little bit and and figure this whole world out. You talked about prompts a couple of times there, Joseph. Tell us why, why, why are prompts so important? What's a good structure to use for prompts?

Joseph Barringhaus:
Yeah, so my, the basics that I typically try to include, and I'll even include some mistakes I think that we made along the way. So the first one, context, like everyone always talks about context. There's never too much context to give to an LLM when you're creating something. And so give it the context. What are you building? Why are you building it? Who it's for? And then a really good example, what should it look like? The reason the exploit took 2 weeks was not because it didn't function how we wanted it to function. It was because we got a pretty good place, like the initial MVP after the first couple of prompts that George put in, the good bit of work that he put in came back. It was good, but like for something to be great, we have a really high bar for what's externally seen that's great. And so the external bar when you're showing something to the world has to be a lot higher and the prompts to create that is challenging.

Joseph Barringhaus:
Like you said a second ago, LLMs go off the rails all the time. And so like keeping it to where it's like, no, I want that button to be this color. For God's sake, give me this color button. Oh, you wanted red? I said blue, damn it. And so like you're going to give it the hex code now instead and tell it not to do that or whatever. So context, and again, like keep refining, but context is super important. The tone, are you looking for something fun, professional, minimal? Give examples of the sites or the apps that you really like that work well. You need to define the language that it should create.

Joseph Barringhaus:
The majority of tools you see that are like, that are, I would say vibe coded in a way, most of them, depending on the tool you're using, are using Next.js. If you don't know what that is, just say Next.js. And like when you're vibe coding, tell it you want it to create Next.js. Some of the tools like Lovable will only create one type. Um, but it could be like, I want it to be Python. I want it to be HTML only, which is, for example, your website is HTML only. It's like, depending on what you're building, you want to tell it what language to write the code in. Structuring, so if you're going to have multiple pages within an app, you want to make sure you have the structure of, well, if I click here, it does this thing.

Joseph Barringhaus:
If I click here, it does this thing. Because again, LLMs will hallucinate. If you don't describe how it should interact or what it should do, it will not do that thing. Or even worse, it'll come up with it on its own. You need to give it constraints. What not to use or allow. I don't want you to do this. I don't want you to allow somebody else to do this., and then give good examples like what is good, what is bad.

Joseph Barringhaus:
The George on my team here, one of my favorite things that he did, it actually taught me as well. This question that he ends almost every prompt with is ask me any questions to make sure you're 95% confident before proceeding. That has become part of my own mental model when I'm writing prompts as well as if you're not sure, ask because it will, it'll be like you didn't clarify what I should do with this button. You didn't tell me what the price if it's this many things is. It's like, oh, damn it. And so again, ask, then tell me, and then it'll get to a place where it kind of goes now.

Andrew Monaghan:
So those are the things to include. Yeah, that happened to me recently. I was trying to do something and I thought it was just going to give me a random thing back. It built this whole backend, I don't know, algorithm with whole different fields it needed and different terms and statistics I'd never heard before to even know whether they were relevant or not. And I just looked at it going, I don't understand any of this. I thought you were just going to give me a little random number generator between 1 and 100. And if I'd said to do that, that's what it would've given me. But it's not what I ended up with.

Joseph Barringhaus:
So the prompt process is important then.

Andrew Monaghan:
Yeah, it is very important. And it sounds like George has got his structure he likes a lot. You talked through some of it there.

Joseph Barringhaus:
Anything else to add to that? Yeah, there's this what not to do piece too. I think we talked about Whisper and how much I love Whisper and use Whisper. Don't do this where you go and record something in Whisper and that's your prompt. Like, don't word vomit dump. My, my tip for most people is start your prompt yourself with something like Whisper or writing it out and thinking about the things we just included, but don't word vomit that into whatever tool you're creating. Take that, go give it to another LLM, have that LLM restructure it for you in a format that makes sense. You probably want to use Markdown. If you don't know what Markdown is, Google it.

Joseph Barringhaus:
And honestly, or even ask ChatGPT to just give it to you in Markdown, which it can do as well. But you want to use something like a Markdown file that's easier for LLMs to understand and, uh, and utilize. So don't word vomit. Like, that's the biggest mistake that I think people make is like, if I just tell it everything, it'll figure it out. You have to structure it just like your brain and you have to structure things in little boxes.

Andrew Monaghan:
It has to do that too. Yeah. One of the things I've started doing is I'll, I'll do that, right? I'll take my word vomit. I'll go to, I think I used Claude. And I said, I need a product request, a PRD, product request document. I'm going to put it into Lovable or Bolt and it's going to, you know, develop me an app. Here's my thoughts so far, organize this as, as what Lovable will need, and then let me look at it. And then I start refining from there.

Joseph Barringhaus:
Right. That's a really, it's a really good workflow. I think that's like, that's the typical workflow I will suggest to people and just make sure you bring all of the things that we talked about and the things to include. Bring all of that into your Vomit, into ChatGPT, Claude, whatever. And you'll usually get a pretty good place. Just make sure you go through it again, because it's going to, again, it's going to come up with stuff that you don't need or don't care about. The hard part with like even the exploit that I know George spent a lot of time on is when you make one change, it can sometimes break the entire app, which is just like real-world applications. You change one line of code somewhere and the whole thing will break and your demo goes down and the demo gods are, you know, no longer with you kind of vibe.

Joseph Barringhaus:
And so like, keep an eye on the things that change when you do make a change. Um, my other suggestion, don't push something live without running it locally first. And again, if you don't know what running locally is, please don't try using a CLI or Cursor. Please go try Lovable or something first, but like run it locally first if you can, see how it works and interacts and do the thing you want, then go push it live. Ironically, you're probably still going to break stuff when you then go push it live and don't ask for a fix without clarifying where or how this goes back to why I said you need to understand how applications work and how structuring within an application generally works. I am not a developer. I will never claim to be a developer or an engineer, but I know enough to go find the thing inside of the repo if I really needed to. And so when you tell an LLM, hey, this thing isn't working, I need you to fix this thing.

Joseph Barringhaus:
If you just say this button's not working, what button? Where? How is it supposed to interact? What thing? And so then it's going to spend a lot of time trying to go find it. If you're using one of those tool free tools like Lovable or v0, you're actually going to burn tokens just trying to find it. Whereas if I tell you where to go fix the thing, I want you to go fix this. So that's my like, what not to do is don't ask for a fix without clarifying where or how, and don't focus on the front end or the back end only unless you're building a front end or a back end application only, which would be weird to build.

Andrew Monaghan:
Back end only, but that's an important one too. Last question about the whole process. So I, I've put it, what do you call it? You put it into GitHub. By a something something, you called it.

Joseph Barringhaus:
Yeah, into a, you put it into.

Andrew Monaghan:
A repo in GitHub, yeah. There you go. I got my code in a repo in GitHub. How do I go live, as you said? Do I press a button, it just magically appears, or do I have to go host it somewhere?

Joseph Barringhaus:
How does that work? Yeah, so I host a lot of the stuff that I build for my own personal use and even stuff that my wife and I use in Vercel. It's probably one of the more common ones. If you use something like Lovable or v0, uh, v0 is owned by Vercel, by the way, so kind of symbiotic there. But if you use something like Lovable or Base44, you can actually go live within one of those tools already. Like they're built to where you can even purchase a domain from within those tools and have the domain just live in Lovable. Um, there's nothing really wrong with doing that. You just have to decide that that's how you want to go create the app. And if you build in Lovable, it usually makes the most sense to just host it in Lovable and run it in Lovable.

Joseph Barringhaus:
Um, if you're going to take it outside of Lovable, this goes back to the languages that you need to create and use. If you take it from Lovable and try and go host in Vercel, you actually have to change some of the languages and libraries that are used to go from Lovable to then hosting somewhere else and hosting into Vercel. But Vercel, Lovable, v0, Base44, it can be pretty easy if you want it to be pretty easy. I've built my app in Lovable. Or whatever, and then I published while in Lovable or whatever. It can— they've made it to where it's dangerously easy to go create an application these days. And that's why I go back to the barrier is not the execution. The barrier is the idea.

Joseph Barringhaus:
If you have a good idea, you can execute on that idea in today's world.

Andrew Monaghan:
So let's, let's leave on that note, right? We've got to record this on the 13th of January. Believe it or not, it's only 2 months until RSA. At the end of March, middle end of March. Hopefully there's gonna be teams out there listening to this and go, you know what, we're gonna do something. We're gonna try and get our unfair share of attention to RSA by doing something really interesting. We're gonna 5-code some stuff and see what comes of it. Maybe nothing does, or maybe something does, who knows, right? But at least they're inspired to go off and do something a bit different. Joseph, thanks for joining us again.

Andrew Monaghan:
If someone wants to say, what do you mean by that? And can you send me something, what's.

Joseph Barringhaus:
The best way to do that? Yeah, shoot me a connection on LinkedIn and send me a message in there. I will either answer it or I will send you to other people that I have learned from, like some of the people I mentioned in today's podcast as well. It's a, it's a learner's world out there too, man. Like, there's so much content for you.

Andrew Monaghan:
To go learn these things now. Well, that's great, and hope to see.

Joseph Barringhaus:
You at RSA myself.

Andrew Monaghan:
Yes, sir.