Podcast Episode 3: Risk, Cost or Apathy: What's Really Blocking Your Church's AI Adoption | Ep 220

Description

If you're a Rock Cast listener, chances are you're already an early adopter, and that puts you right where your church needs you: a step ahead. In this episode, the team unpacks the three biggest reasons people hesitate to adopt agentic AI, and why early adopters are the force multipliers who help others cross the chasm.Jon shares a version update Rock has been building towards for years: v19.4, complete with AI agents. He teases a new onboarding layer called Spark Connect which turns services like AI on without needing to become an AI genius.Even though Sam Altman and Elon Musk claim that AI hit the point of singularity, we talk about why that milestone still doesn't buy your church a single ounce of wisdom, especially when it comes to vibe coding your church's website.Visit the show notes to find all the resources talked about in this episode. Don't forget to join the new Rock Cast Rocket Chat Channel to see what other churches are saying about this episode.

Transcribed Content

Welcome back to ROTcast. Thanks guys for tuning in. This is an episode that's gonna speak directly to our audience of listeners, and those are the early adopters. So the goal of this episode is to equip our early adopters with the toolkit that they need to address the objections or the hesitancies of the majority or the late adopters so you can get your team onto the AI gentic bandwagon. John, do you wanna kick us off with a version update? Yes. So version updates. We've been very, very busy. So nineteen dot three is about ready to go out into, full release. It's been in alpha and beta for a bit, and so we're ready to release that. And '23 is gonna be right behind it. And so '23 is going to be just a couple bug fixes, but mainly, it's going to be the rollout of the AI stuff in '19 that we've been promising. So AI has been in '19. It's just been kinda hidden, and we've held back just a few little bits to keep it safe and and testable. And so we feel comfortable letting some early adopters play with it more. And I think I want to really stress is much of the AI tools have been done for a while. We've been testing them and doing a lot of things. What's really been holding us back though, is how do we onboard? How do we get people to get these tools turned on in their instances without having to be AI geniuses? And so we've created this new tool set that we call Spark Connect. It allows you to connect to these services, the first one being AI without having to go do a whole bunch of stuff. So Spark's taking all the burden off of that and trying to make it easy. If it was just for this one thing, think it's very important that we do this Spark Connect. But it's not just for this one thing. We're gonna have all kinds of new services that are coming out. Stuff that we've actually been wanting to do for five years, but we knew , Oh, we can't do that because it's an extra service. People are gonna have to provision it. So therefore we can't rely on it because we can't make sure that everybody goes and does 12 steps. So this is gonna really allow us to roll out a lot of new innovation without people having to do a lot of work. And so I think it's gonna be a game changer for Spark in a lot of ways. So a lot of our delay in getting the AI tools out was first of all, testing and guardrails and also for us to provision this new thing called Spark Connect. And it's really pretty fascinating how it all works, which I'm sure it's probably too nerdy to go into. But it's been a lot of work and it's gonna unlock a lot of stuff. So super excited about what's coming. Yeah. There's a lot to look forward there. Emily, can you maybe lead us into how we can get the majority on board with AgenTic AI? Sure. I mean, I think the first thing we should do is recognize that probably most of our listeners to this podcast already know that AI is important. It's kind of the way of the future. They're probably already at least dabbling in it in the agentic AI if they haven't already started incorporating it into their daily patterns and workflows. So some of the things we're gonna talk about is what do you do now if you're in that position inside your church? I just to say that you're actually in a great position because people that are first to, adopt something this or early adopters are actually in the position to be force multipliers. That means that they can be the individuals that help a whole organization adopt something, and they can help actually influence kind of the direction and some of the best practices and the energy behind it. I don't think AI is different than other technologies in the fact that it spreads kind of the same way. Right? It so it starts with a small group first. And if you've ever read Malcolm Gladwell's book, The Tipping Point, he calls those people connectors. So the connectors are the people that catch the vision first and then help bring the other people up alongside them. And I think that's the point where we are right now. The early adopters are in. Now it's easy to feel , oh, I understand this. So now this is normalized to me. Now it's easy. Right? Now I feel , oh, they can just, , figure it out themselves, and they'll come join me over here. But they probably won't be. So what you need to do now is look around you. Who's sitting next to you? And how can you help bring them along and get them there? If you remember in episode two sixteen, we talked about how the whole market moved from chat to a gen ticket with a big quick shift. Now we need to big quick shift to get everybody on board. Right? And that's that's the role of the people listening to this podcast for the most part. It's that encouragement and pulling them up. So probably we should first look at, , what might be holding back those people that are on your staff that are not early adopters, that are kind of maybe pushing back a little bit or maybe just, , not really recognizing the impact. And I think there's three big reasons people are not adopting AI today. One is maybe a risk aversion. Some people are naturally wired to risk aversion, but also inside the church world, sometimes people equate the role of stewardship with the role of being slower to, trust something with your resources. Right? And they might be cautious because they feel there's a potential, for, problems that could happen. Right? But I would say , what if you look at that from the other side? I think there's at least as much risk if you do nothing. Because the way we operate today is not gonna be the way we operate tomorrow. So this is the time that people have to step in and figure this out. The other thing from a whole organization perspective is your staff are already adopting things. If the organization doesn't get out in front of it, they're probably using tools you wouldn't be excited to learn they're using and doing things that maybe need some different direction. So the risk aversion is not really a great response. You need to start small and supervise, and then you can roll out from there. Start with something, , low stakes, but your your organization leadership needs to be involved in that. Another reason maybe your organization might not be quick to adopt it as a whole could be economic. , just a concern with how much is this gonna cost me, or even, , I don't wanna have to lay off staff. But we've as we've talked about before in other podcasts, I think we should, be looking at, , how do we, one, the time's already being spent. We're paying our staff to do things that we now can get done faster. And then that unlocks the capability of our staff to do the ministry work. So you don't have to be a staff of a 100 to operate a staff of a 100 anymore. So look at the opportunities in front of you. And honestly, I think probably most people fall into a category that's more , maybe a discomfort with the technology or even apathy. They're very busy. They have a lot to get done. They really just wanna, , knock those things out. We all know in the ministry world, you have about a million things coming at you on a given day. Their goal is really get those done and get home. And not in a bad way. They just know they have more to do in a day than they have time. So they're not looking for something else to learn or something else to do. And it really just means they haven't maybe caught the vision of how this could be such a game changer for them. Mhmm. From somebody who, probably doesn't really fall onto that early adopting side naturally, I'd say how our team planned out our use of AI and how we created basically a game plan to get started was so helpful. Mhmm. And it was fortunately around the time for me when I was hearing about Claude on different podcasts and different resources and then hearing how amazing and impactful it was and how it was such a game changer. But then it would have taken me so long to find the right resources or find the right videos or apply it to marketing or figure out how to use Cloud Code. That, I mean, that would have set me back a long time. I think if you go from early adopters to the next wave is people who are open and not resistant. I would start with them. I mean, don't go to the person who's never gonna use it. there's gonna be some people who are just There will be resistors. Either apathetic or resistant to change. Don't go to them first, but go to the people who are open, maybe not early adopters. But I think even in early adopters, I've been an early adopter my whole life. I think there's a tendency for us not to want to go back and help the next person. It's , I want to keep blazing the trail. if I go back, I'm actually wasting cycles on that. And I would say that's a mistake. The more you can bring your organization forward, it's actually going to push you forward a wave. So sometimes you have to go back. And especially in the church space, not only should you for the fact that it will be a wave that pushes you forward, but they deserve for us to go back and help them understand these things. Right. And you don't have to be in a top leadership level of your organization to help pull that off. Connectors are often people who've built trust and who demonstrate competence and who have a plan. I bet most of the senior leadership of churches would love someone on their staff to come and say, here's a plan I have to get staff up to this level, get them over the hump, and here's how I see this connecting to the vision of what it is we're trying to accomplish as a church. I really think it's the responsibility of the early adopters to go back. Because that's not built into early adopters. We wanna keep going forward and not , hey, why am I gonna waste an hour doing that when in that hour I could actually move forward myself? It's really saying, hey, I gotta take one for the team and not think of me, but we. Yeah. I think it's a responsibility and an opportunity that they can , help design the on ramp process for those other people. And I think they have a great, opportunity to make it more approachable and less scary or, , iron out those pitfalls that, , people are gonna stumble on. In general, I think the organization's gonna be the kind of place that, , is easier to work in for early adopters if they do take the time to go back and help the people around them. For sure. And I think that creates in one way, creates a wave. And I think in another way, it creates a ripple effect for other people to see the work that they're doing or hear how they're creatively using Claude, her co work. And then, I mean, that's how I learned. I heard of our team using Claude to do awesome things or creating awesome presentations. , that's even possible? It just blew my mind. Yeah. So, John, can you lead us into your segment on wisdom versus intelligence? And what does our people need to know about that? Yeah. So I think it's often that we look at AI and we just think how amazing it is. And I think it's even the more we go, the the more so it seems amazing. , so over the weekend, there's talk about online about how the two two major leaders of AI, Sam Altman and Elon Musk, both were in agreement that we've reached what they call the point of singularity. And what that means traditionally has been the point where AI helps make AI better. So to date, it's always been man making AI better. But when AI is smart enough to make itself better, it hits a point where it rapidly iterates so fast that the capabilities go straight up. Now there's some debate of what what these two are really considering singularity. Most would say, hey, you're using a broad a broad brush when you use the word singularity. There's still humans helping get these models better. So we're not fully at singularity. Think a majority of people would say that. But two leaders are saying that. So we're definitely hitting a point where the capabilities are getting more and more. And I don't think much of this we've even seen. There's a whole bunch of models that you kind of hear talked about that are in training. In fact, some of some of them have actually broken out. that's the new hot thing for this week is all the breakout stories, not just in the ones Hugging Face and OpenAI, but there's been several cases where people are starting to talk about model breakouts. It's become the new trend. Oh, wow. And that's just showing that there's models that we don't even know about. Official term for one of these models that OpenAI is talking about is Astra. So that's their their next one. So Sol, Terra, Luna are the ones we know about. Astra was just announced that it's back being tested. It's a little scary because Astra actually means the starry one, which if you draw some interesting parallels there, I'm not sure what to think of that either. OpenAI has a terrible marketing company or they're trying to tell us something here. But we see and hear about all these new things coming and all the new capabilities. And I think we can often be trying to figure out what the future holds. The one thing I've been thinking a lot about, and just really diving into researching and thinking, is that if you look at it at the surface, these models are amazing, and they represent an incredible level up in intelligence. AI has more intelligence than humans, by far. Why? Because they have access to everything humans have ever said. And they have access to compute that thinks faster than our human brains. It thinks faster. So, we have a point where we have another thing that has not infinite intelligence, but at the point where when they hit singularity, it will have near infinite intelligence, but it has zero wisdom and never will have wisdom. We have wisdom. And we know it'll never have wisdom because wisdom is a gift from God. The book of Proverbs tells us that wisdom isn't something. It's a gift that God has, and he has shared limited wisdom with us. Now, it can fake wisdom through compute and capacity and just raw, , compute power of intelligence. So, , let let's take an example of full self driving from Tesla. Amazing. It it can it can drive better than humans in most cases, in almost all cases. However, it runs into edge cases that a 14 year old who's never driven could say, no. You're supposed to do this. Duh. And it gets confused. And that's what we see today. And I think a lot of people look down on it because of that. Well, we're seeing edge, edge, edge cases. But someone with wisdom, a 14 year old who's never driven knows how to get out of those situations. Now, FSD will fix itself because we'll throw more data at it and create more intelligence. And so basically, the intelligence will get so good that it can do this and hit 99.999% of edge cases. But that's still intelligence. It's not wisdom. The kid who the 14 year kid has more wisdom than FSD. Another good example, and I heard this one and I had I had to go test it for myself, and it was actually true. If you go to these Frontier models today and you say, Hey, I need to wash my car. The car washes a block away. Should I walk or drive? I literally did this and it's amazing. It said, You should walk. It's only a block away. However, keep in mind, you also have to walk back home and it's 105 degrees out today. So it's kind of hot, which was true. They it somehow knew the weather. A lot of good facts. Great intelligence, right? Perfect intelligence. But the wisdom is I need the car to wash. So again, another example of how these models have great intelligence, but have no wisdom. And they're not going to because it's a gift from God. It'll synthesize that. Another good example is, , came out last week that this new OpenAI model is solving all of these unknown math problems. , well, that doesn't have a wisdom, how can it solve these math problems? Well, it just brings all of the compute that we give it. And it I mean, it costs I think every math problem was thousands of dollars of compute. And it brought just a ton of our current knowledge and just ramps the It's if you're trying to attack the castle wall and you just swarm the wall. It's kind of those virus movies, was it? Z and they hit the wall and they're just all crawling up each other over the wall. Well, it's , was that Oh my goodness. Was that an intelligent way to attack the castle? No. That was the swarm way. But it's effective. Eventually, you'll get through. A wise person may have taken three people, tungled under it, I think that's what we're going to see is we have to understand, we have something it doesn't. And so that kind of translates into the next piece here, which is, so what do we do with this knowledge? Well, we don't outsource our jobs to it. We don't outsource for sure our ministry to it. We definitely let it help us. Right? And I think right now, it's gonna be a phased approach. Right? As it gets more capabilities, we can probably trust it to do some more stuff. But where we are right now, it's amazing, but it's not it's not super amazing. Mhmm. I think sometimes we can, , do some one shot , oh, that's cool. And it blows us away, but there's still much more that we need to to engineer and really think through. So for instance, someone might say, Well, , I don't need to get someone to make my website. I can just vibe code it. And what I would say is if I was coaching that person today, I'd be , Yes, you can totally do that. I would limit that though right now to , do you need a landing page for camp? Do you need a landing page for a men's event? I would absolutely vibe code that. Hopefully, you have some branding guides. Hopefully, you have some stuff to ground it and keep it on brand. But for just a one event thing, I I yeah. I I think that's that's something you you could try. But when it comes to doing your core website, the one that everybody's gonna use that should be highly personalized, highly driven to getting people to take their next steps. That's one I probably wouldn't vibe code right now. Now, in a year, two years, I don't know, we don't know what the capabilities are going to be. It's still not going to have wisdom, so I still wouldn't outsource that part of it to it. But to do something strategic that, I would probably say, woah, I think that's that's going to get you might get a good looking result, but you're not going to get a very strategic result. And if the goal of your website is to answer that what your service times, cool. If your goal of your website is to move people forward in their walk with Christ, I don't think that's a good idea. So there's a there's a strategy part of that, but I think there's also a technology part of that. So right now, I think a lot people are are really excited about what they can do with this. And so they're doing things opening up the Rock API to let Vibe coding kick in and do That's not a bad thing. , don't hear me wrong. But be super careful. Do you understand the security concerns with doing that? Realize when you go to do that, from Rock's perspective, it has no idea who that person is. It just has an API key. And it's , well, this API key is allowed to do this stuff, so I'm gonna let you in. But it's kinda having someone at the castle gate who's blind and everybody's coming across the the drawbridge. It doesn't know. It doesn't care. It's everybody's the same. So that puts the responsibility on you, the VibeCoder, to make sure that security is now checking not just the authentication, but the authorization. , you gotta know the difference between those two words are very different. And making sure that you now control authorization. And I would say if you've done that, where is that API key where I'm sorry. Where is that API call coming from? The back end or the front end? And if you're not absolutely certain, that would be a major red flag. If that's coming from the front end, you have a huge problem. you've just bled access to that API Yikes. To anybody who can read JavaScript, which is a lot of people and every single AI. And all AI. Right. So AI, as it comes to cybersecurity, we've been talking about that for months. And it's gonna impact core developers a lot because that's gonna go find these really small but very important security issues. That's gonna help us find these teeny teeny tiny ones that probably no human would ever have found. And we're gonna use it for that. But it's also gonna have the reverse on Vibe coded stuff. It's gonna find trivially easy stuff at scale. And so that's it. And that's probably gonna be a bigger deal because it's harder to go do that. And it takes literally thousands of dollars of runtime to find these obscure little areas. But it'll take pennies to find, oh, the API keys numb by the JavaScript. And so this is the kind of stuff that you gotta be super careful about. Because when you if you if you don't know how your vibe coded is interacting with that API, I would be very, very, very concerned. That is a very huge security issue. And security is just one thing. Then you have performance. You have, , what what is another thing related to that same example, if you're using APIs in Rock from your Vibe coding this, are you doing a denial of service attack on on your Rock server? Do you have a cache layer for that information? Should you be caching that information? If not, you might be abusing the a the API. One of the things that we didn't do in Rock is we did not put a rate limiter on the API. Why didn't we do that? Usually, you put a rate limiter on it when the service is attacking your servers. if if Spark was hosting this, we'd absolutely have a rate limiter on this. , because we cannot have people abusing our compute. But because we've given you the compute, we were , well, what you're doing. So , be smart. So we didn't wanna handcuff you. Now we might have to at some point because this could get out of control. And there's been several cases I think we've all had where people came and said, hey, Rock doesn't scale. And it's , well, what are doing? Oh, you build that API? That just happened two weeks ago with a church where one of their arrest endpoints got away from them and caused a a service outage on a weekend. Oh, man. So, I mean, and it's not they weren't being careful. This is just natural stuff. Yep. But when you're vibe coding it, if you don't know how that's a what the performance characteristics are on that REST endpoint and what the surge traffic would be and you don't have a cache, I'd probably say , Hey, don't be vibe coding that kind of solution if you don't know the answers to those questions. I can see the direct correlation between vibe coding critical solutions and the lack of wisdom with AI. Because you've just increased your technical skill set when you vibe code something. But there is no layer of wisdom or strategy that's being, implemented by AI. So if you aren't implementing it yourself and if you don't have the the knowledge to match what the AI is putting out, you are potentially sacrificing the strategic wisdom and in this case, security. Yeah, and we're using the tools much the same way that some of the Vibe Coaters are, except we spend a vast majority of our time pre talking through, Okay, here's what I need. Oh, by the way, I'm gonna have to we're gonna have to cache this. My goal is to only have, , is basically to have no calls to to the back end from the front end, and that we'll make one one cache call and store it. , we spend 95% of our time writing these detailed specs based on our wisdom of how Mhmm. Architecture should be. And then at the very end, we say, okay, now create a plan. Now execute the plan. Whereas I think when I vibe coke, because I do vibe coke for hobby stuff, dude, I don't care. , I'm , go for it. , I'm and sometimes I'll be , okay, now you should probably catch that. But I'm not doing that. It's a different scale. It's a different strategy. It has no , if someone were to hack my hobby site, I don't care. every It has tons of PII in it, but it's all from people who are two generations removed and are not on the planet anymore. And I don't really have their social security numbers. So if someone hacked it, I'm , cool, I have a backup. I'll put it back and figure out how they did that. That said, I do probably put more time and thought into it than I'm probably leading on, but I'm in a different posture at home when I'm vibe coding. Yeah. And if anyone's listening to this podcast and they haven't heard previous podcasts, you've gone into a great deal of detail about the spec coding that the team is doing. So I would definitely go backward and look for some of that content. Yeah. The cool thing is , we're open source. if you wanna see our specs, they're in GitHub. Yeah. I say I would say that there are some projects we're working on though that are not in GitHub. They're our private repos that we're using for things the Spark Connected Services. There's a whole, , there's a whole monster of an application that's powering that. That's all private because it just doesn't need to be public. And the amount of time that went into writing the specs for that. And we just blew right past that at the beginning of this episode. But the innovation required just to get this onboarding in place, just to put that layer in place is incredible. And it's just very easy to gloss over the effort that it takes to do that. But that was a big deal. Yeah. I mean, it started out , oh, this will be easy. But every project, , it's , oh, okay. And actually, we have another little project that we'll be announcing at the conference that is another one of those private things that unlocks so much capabilities. And it took so much spec coding and planning. And And there's a lot of stuff we're working on in the long term future that we have not even written a line of code, but we've spent literally weeks writing specs. So, I think that's again, where the intelligence and the wisdom come together. We use the intelligence of the models to go do the work, but we use our wisdom to our arts and crafts, the vision and the blueprints. We literally call them blueprints. Makes sense. We have to have God given discernment apply to the solutions that we're putting out to lead people to Christ. Yeah. And trust me, the world is going to call the intelligence wisdom. They're going to conflate the two. You can't tell me that Sam Altman is not thinking that he's creating life. Because that's what evil is going to tell us, that we are gods, small g gods. But we're not. What we created was I I wish we could see what AI through God's lenses. Oh, that would be interesting. He's gonna be , Oh, that's so It's so cute. Look at that little it's I always say, he is so much greater than us. Right? But we're drawing, , we believe is the the Mona Lisa. And he puts it up on his refrigerator because he's a proud dad and it looks your kid's first drawing with marker. And he's isn't and he's proud. He's , look what you did. It's so cool. And we're , the Mona Lisa. And he's , yeah. He's , I'll put the little picture magnet on here. Remind me of who you are. I'm gonna show Moses when he when he comes over next time and he'll be so proud of it. But . Well, the whole subplot of the Bible is people trying to create gods, trying to become gods, trying to equal god. Right. This is one more chapter. Well, there's books on this too. Life three point o is a huge one where we're basically creating life. And you read it, it's hard. I mean, , it's literally hard not to laugh out loud because it's so silly and so hubris. But that's where we are. And we should be aware of that. Yeah. Well, I think we got some good content. And I think, I hope that we equipped our early adopters with some ways that they can counter any objections that they feel arise at their church. But I would love to hear from them of which ones they that they encounter the most, whether that's the risk aversion, whether that's technological discomfort or apathy, or any economic factors in there. But before we wrap up, I wanted to share a few announcements. The main one being that we have published our Rx schedule. So it's live. It's up there. You can see a lot more of this content on our website. AI will be a main talking piece, point of con point of content at our event. So bring your leaders, bring your staff, any of those late adopters to there, and then they can, hear and keep talking about this. So thank you guys for tuning in. We'll see you next time.