← Using AI at Work: AI in the Workplace & Generative AI for Business Leaders
Using AI at Work: AI in the Workplace & Generative AI for Business Leaders
101: How to Audit Your Dev Partner in the Age of AI with Matt Strippelhof
00:48:45
Loading summary
Transcript92 lines
- [00:00]
A
Forever. CIOs have been saying buy, don't build, but that's changing.
- [00:04]
B
If I'm not a technical person, like what are some of the foundational things that I should at least be conversationally aware of when I'm approaching developers for some stuff for our company?
- [00:14]
A
The conversation when you're evaluating vendors for software engineering projects should really start with what's your experience been like using AI in your software development life cycle over the last year? Tell me that story, how it's impacting the way that you do things and let them respond. And if they're getting excited and their energy's coming up and they're talking about the wins and efficiency gains, that's probably your guy.
- [00:37]
B
What's your thoughts on the CTO leading like a generative AI effort within the company?
- [00:42]
A
If that effort is specific to affecting or improving the bottom line for that department, then they should be in charge of that.
- [00:49]
B
There's a lot of tools out there. What's leading the list for you as far as the tech stack or the tools that are available for somebody like me?
- [00:56]
A
Well, one of my favorites is Google Firebase Studio for generating clickable prototypes. We're all still trying to figure out how of the code we can trust.
- [01:05]
C
Matt Strippelhoff is a technology leader at Red Hawk Technologies where he helps mid market companies gain predictable scalable software development and technical support through an award winning fixed fee service model. Welcome to Using AI at Work. I'm your host Chris Daigle. Each week we'll be learning how today's business owners, entrepreneurs and ambitious professionals are getting more done with smart use of tomorrow's tech.
- [01:29]
B
Let's get started.
- [01:31]
C
Right now every business leader is asking the same question. What are we going to do about AI? If this is you, chiefaiofficer.com has the answer. We give you a simple path forward where we provide executive and team training so your people know exactly how to safely use generative AI in their day to day. We also manage the deployment and implementation to make sure tools actually get adopted and deliver results. And we'll also guide company wide transformation so AI becomes part of your operating system, not just another shiny object. The companies that act now will increase productivity, cut costs and grow faster than their competitors. Those that wait will get left behind. So if you want to make AI work in your business, visit chiefaiofficer.com and see how we're helping companies of all sizes finally get results from AI.
- [02:17]
B
Hey everybody. Welcome to another episode of Using AI at Work. My name is Chris Daigle and I'm the host and our guest today is Matt Strippelhoff, the CEO and CRO of Red Hawk Technologies. And today. You know, Matt and I had the opportunity to connect a few weeks back before the interview. And based on the conversation we had, I'd like the conversation today to be for us to be able to access Matt's expertise and find out how do we audit our dev partner in the age of AI. Now, what I mean about that is like, just like an attorney, the pricing model is going to have to change. If we just saw the story that came out with the big law firm that, you know, $3,000 an hour law firm, and they got busted using CLAUDE or Chat GPT to write up their brief referencing hallucinated case law, right? Now, obviously that's a poor use of the tool, but we know that that generative AI is being introduced into the legal environment. And this whole idea about paying a lawyer by the hour when maybe they're not using the hour, maybe they're using five minutes because they've built something in the models that's something that we're all used to. Now, if you're a business owner and you're exploring generative AI, the reality is there's going to be the access to be able to get bespoke custom software created for you quickly and easily. Maybe not replacing Salesforce, but small applications to start for sure. That's already on the table. So if you don't know how to do this, how do you make sure that when you're talking to potential developers to create these things that you're not in the attorney situation where they're like, oh, yeah, it's going to be 50 hours of development, but they're actually using tools that you and I have access to. So that's kind of the theme. I'd like to take it in, Matt, but before we go there, why don't you tell everybody about why you're the guy to talk about this?
- [04:13]
A
Well, I've been in this line of work for 25 years and started Red Hawk Technologies 18 years ago. And all we do is custom software engine. And we developed our first AI model and solution for one of our clients five years ago. But this rapid evolution of Claude Code Base 44, all these tools, lovable. Everything everybody's hearing about today, man, we are diving in hard on that all in the past 18 months, year or so, and it's amazing what can be done. And we're using those tools to rapidly develop solutions for our clients today. And it's affecting how we do everything.
- [04:48]
B
So was I off when I was doing the comparison between like this legal bottle of bill by the hour as compared to dev? Is that what's happening?
- [04:56]
A
Well, I think there's certainly some risk, but you know, it's always going to come down to trust and transparency from the vendors that you're working with. And I think it's going to be imperative for people to ask the question of how and what tooling are you going to use to produce this solution for me and how does that impact the contract? So I think these conversations need to happen very early. Very early. You want to find out later that, you know, they, they start adopting tools after they form the contract and now maybe they're not such a trusted vendor and they're not being transparent and they're thinking about how much margin they're going to lose because they, they, you agree to a schedule based on time and materials and all of a sudden they're delivering at a much rapid, much faster pace. And now if they're greedy, they're thinking about, well, can I still get away with billing what we agreed to? You know, but, but you know, the description you're providing is like, well, maybe they're, maybe they're misrepresenting their time entries. You know, that's where you got to watch out. I don't think there's, gosh, I hope there's not a lot of that going on. I know for sure it's not happening here. You know, our approach is we're letting the customers know what the tooling is that we're going to use. In fact, we started applying a surcharge to our contracts to cover the cost of using these tools because it's not free and it's not even a fixed cost. It's not like it's a license per seat, per developer like other software engineering tools have been historically. No, this is a utilization fee and the more we use it for you, the more it's going to cost us. So we just pass that cost along as a surcharge and we still track our time entries in a very transparent manner, provide that detail to our customers with our invoicing. But yeah, I think there's certainly a lot of talk about moving toward value based pricing because everybody's trying to figure out how to use this.
- [06:43]
B
Yeah. So an environment of misaligned incentives. That seems like a tricky place to be. I know that you guys, as you just admitted, you guys are kind of changing up the, what that billable experience looks like for your clients. But why isn't the industry itself kind of starting to self correct on this? Or is it.
- [07:09]
A
Well, two thoughts that I have on that. One is we're all still trying to figure out how much of the code we can trust and value that's being generated, how to make sure there's quality control on that, and then we're measuring throughput to see how much faster we're actually accomplishing our objectives. But oftentimes we're estimating based on our traditional approach to software engineering, because that's the devil we know. And when we're asked to forecast work, the engineers who, you know, we've got people on Our team with 15, 18 years of experience have been with us the whole time. With the tooling largely being adopted in the last six to nine months, it's really hard to, hard to use, hard to estimate differently. We're still learning how to estimate differently. So that's part of the challenge that's happening right now. And so a customer might agree to a scope that's estimated traditional way. And then all of a sudden you kind of have that challenge where it's like, okay, we agreed to a fee schedule, getting there faster. We didn't know how to anticipate that. We also have charges associated with using these tools based on utilization. How is that handled? And if it's not in your contract language, it's really hard to account for late in the game.
- [08:27]
B
So I can tell you that my experience has been when I've, you know, I'm a light vibe coder, let's say, I've built apps for our organization and mechanisms we use in marketing and things like that. And a lot of times when I'm working with the models, it'll give me an estimate. It'll say, hey, this is a lot of work. This will take two to three hours. And I'm thinking. But then I realized it's basing that on its training data. Training data is decades of humans saying, oh, that type of development project will take X number of hours. So the models are going and they're like, they're looking for a reference. They're like, oh, he's asked me to do this based on what's in my training data. It looks like that's going to take two to three hours. But the reality is it's like, ding, it's done like five minutes later or whatever. So one of the things that you've brought up that I think is important for the listener, if I'm going to be investing in a development team, I'm going to look for AI capabilities for sure because I'm going to hope as a business owner that that gives me some pricing leverage a little bit. Right. Maybe I'm not paying the full dev price, but if I'm not a technical person, like what are some of the foundational things that I should at least be conversationally aware of when I'm approaching developers for some stuff for our company?
- [09:46]
A
The conversation when you're evaluating vendors for software engineering projects should really start with what's your experience been like using AI in your software development life cycle over the last year? Tell me that story. Help me understand how it's impacting the way that you do things and let them respond. Ask more and more clarifying questions based on that conversation. And if they're getting excited and their energy's coming up and they're talking about the winds and yeah, that's my guy. If you see gains then you're probably, yeah, that's probably your guy. It's like, okay, they're really going to take advantage of this because they're passionate about it. They're not trying to disguise anything. They're being transparent. And eventually you have to develop some level of trust because it always is going to ultimately come down to trust. But I think get them to tell you their story about their experience with the tooling and how it's impacting them.
- [10:35]
B
Yeah, so we've got, I got a couple of interests. One of those interests is some software and I've got a very capable developer who didn't have a strong technical background but has spent the past two years deep in these vibe engineering, vibe coding tools. Smart guy. But he's doing amazing things and we raised a little money. He said we need to bring on some more developers so we can move faster. And, and I let him vet those people because he's the guy that can ask the questions. Everybody said they were AI enabled and AI capable. Once he brought them in, their self interpretation of an AI capable, like I'm an AI capable dev. Right. Their self interpretation was no match for what he was expecting. So I can say that in our own experience it's been hit or miss finding folks who have the traditional experience. For sure they could, you know, if I gave them half million dollars in six months, they could build the thing. But are. So I think that's something that, that from my own experience, I would also say watch out because they may be using the tools, quote unquote. But are they using the tools the way that Matt's team is Using the tools. Right. As a. So as how might one, how might have I have avoided hiring those people in the first place and then having to fire them a few weeks later?
- [12:05]
A
If you have a specific methodology and combination of tooling that you're passionate about, using your lead engineer, for example.
- [12:12]
B
Okay.
- [12:13]
A
Then the Q and A process during the hiring should be more tightly aligned with that desired throughput and utilization. I think that's part of the process. In addition, as we've been expanding our team and growing, in fact, what's happening right now that my team is doing is our AI czar. The most passionate developer on our team has been with us for over 12 years who's an early adopter in all these platforms. He has multiple agents doing coding at night all the time. Like this is the guy. Like he's my version of your guy, right?
- [12:47]
B
Yeah.
- [12:48]
A
And he's also passionate about teaching, which is fortunate for us.
- [12:51]
B
Awesome.
- [12:51]
A
And so we, we charged him with producing an educational program. It literally is a multi week boot camp and we're taking all of our engineers, we have close to 50 people on the team. They're all going through this boot camp now so we can all start rowing in the same direction. So we have early adopters, power users, and then we have people, some legacy team members, been with us for a long time, OGs, who are still kind of falling back into the way of doing things that they trust and know they can have quality throughput and they're not adopting quickly enough. So I think there's also a need to realize that anybody building a team, you got to have a champion, somebody passionate about educating that's going to decide what your standard is and then you got to be willing to educate.
- [13:39]
B
So this is good because the perspective you just shared is there may be listeners that have, they've got their own team, they're not necessarily looking at vendors. And if that's the case, what Matt just described, 100%, if you've got that person who's doing this in their free time because they're just so enthusiastic about using it, if they can tell others what they're doing, that enthusiasm will catch on and your development team will be enhanced for sure. Now in the pre interview there was, you made a comment, there was something along the lines of like if your dev team isn't using cursor or similar tools in 2026, they're either lying to you or they're behind. Right. And I thought that that was what's the incentive for a developer to not like own up to or embrace, hey, I'm using AI for all my stuff. Is there a stigma? Because again, think about who's buying this stuff. Is there a stigma to it? Are people concerned about maybe risk of somebody using AI on my code or what do you think?
- [14:47]
A
Well, I'll answer that question from the perspective of the engineers and the first part of the question is what's the incentive for them to do so or admit that they are not doing so? One way or the other, it's going to come down to individuals and style of work. They know they're being held accountable for their performance. Performance historically for an engineer is the quality of the code that's generated. If AI is generating the code, then there's some anxiety that comes with this about how am I, how's my performance going to be measured when now I'm the orchestrator, I'm not generating the code. So I think that creates some anxiety and some challenges and maybe that might incent some people to be less willing to dive in headlong. They may be saying that they're using it, but they're not really embracing it like your power users. And you might notice that through a difference in throughput, or they might be on the other end of the spectrum where they're using the heck out of it, but they're concerned about the quality because they're not taking the time to really evaluate the pull request. So they might be a little less genuine about some Q and A around the quality throughput and they might say, you know, they might change. There's. There's so much psychology in this, Chris. There's so much to unpack there. It's really hard to give you a real clean answer. But, yeah, it's a challenge. You're now trusting AI to do work that you were measured, that you are continuing to be measured on.
- [16:12]
B
I guess it's like same thing if I had somebody producing content about my industry or whatever, you hope that you hope it's good enough to pass. So one of the other areas that we talked about, and this is something that comes up a lot because we go into companies, we don't do the technical side so much, but we do the training and use case and I mean use policies and pilot project identification and xyz. And we always look for that internal person who's going to be the executive sponsor or whatever, right? Like somebody that we know that if their team isn't quite getting traction or they're not showing up to meetings or whatever, then we can go to Daddy and he can Go and crack the whip on his own team or her own team. Right. And the first question is, who should that be? Now, a lot of companies that aren't necessarily, like, all in on AI yet they assume, oh, this is a technology, it should be our cto. What's your thoughts on the CTO leading like a generative AI effort within the company?
- [17:20]
A
If that effort is specific to affecting or improving the bottom line for that department, then they should be in charge of that. If it is an AI.
- [17:31]
B
Let me clarify.
- [17:33]
A
Yeah, go for it.
- [17:33]
B
When you, when you say they, you mean like, if my department is operations.
- [17:38]
A
Yes.
- [17:39]
B
I should be in charge of the orchestration of the oversight of generative AI in my department.
- [17:45]
A
Yes.
- [17:45]
B
Is that what you're saying?
- [17:46]
A
Okay, yes. Now, from a cybersecurity acceptance use policy, all of that stuff is bigger than one department. Obviously. I think that does kind of fall in the room of your CISO or your CTO in terms of policy enforcement, technology adoption, releasing, managing, licensing, things like that. But the owner of that pilot program needs to be the one who is also accountable for the performance of that body of work. In other words, if it's operations, to your point, and your pilot program is about improving throughput, reducing the time from opportunity to cash, for example, and maybe there's some AI involved that's handling communication between an ERP and a CRM platform to pull that off. If their metric in the business is how well they're performing in that area, they need to be the ones who own that program. Ultimately, it's not about the tooling. Right. It's about. It's about business impact.
- [18:37]
B
So the mistake that a business decision maker could make would be, this is technology, therefore we've got a tech department, let's let them handle it. But the tech department isn't going to have the context relative to the process that is getting AI iFied or the workflow that's being. And that's why it makes sense for the head of that department who does have domain knowledge, subject matter expertise, and outside of the security side of things, for sure. Totally. Like, you don't want your COO making those calls. Right. That's the tech team for sure. How should they. First off, I guess I don't know if you're seeing this in a lot of other companies, but is there friction between the CTO or the tech department thinking that, hey, I should own this because it is a technology? Are you hearing about this?
- [19:27]
A
Yes, I am hearing about this. And the friction typically comes into play if the project gets Sponsorship before the CTO is involved in the conversation. Because now they're in this. How do I de risk?
- [19:40]
B
Yes.
- [19:40]
A
Where this is going and it's gonna, and it's unexpected. And now you've just come in and you've just basically dumped a bunch of work on their desk and they have to figure out how to make sure this gets done in a secure way, that that creates friction. No doubt about it. I think they need to be at the table at the same time when they're evaluating what programs to invest in.
- [19:59]
B
Great tip. Because using AI, there's risk and it's not the tech. Sure. But it's the user. That is 77% of employees are, you know, uploading company secrets into the models. Not, not intentionally, but they just, they don't know. Right. Yeah. So I think that's a really good point to bring the CTO in as early as you can. Not to say, hey, buddy, do you have time to do this? But hey, we need your perspective on this. I love it. I think that's great. Okay. There was a comment that you made about funding someone's learning curve and calling it a project. And which, which we experienced that with that. Right. Like, like they said, hey, I'm a developer, I've got. And they had built projects, they built it in the industries that we were targeting and those sorts of things. Great. But when it came to using AI, there was most definitely some, I'll learn, you know, I'll figure it out as I go kind of thing. And we were paying for that learning curve. Outside of maybe some of the suggestions that you made earlier about how to vet and pre vet some of these candidates, how do I make sure, or is it okay that I'm paying for that? I mean, if the developer is like, this is awesome, I've got an opportunity to learn. I mean, they're gonna do better at it than I would. Is it a bad thing that they're learning on my dime with AI? Hmm.
- [21:27]
A
From the client's perspective, they're always going to feel like I should not be paying to educate your team. I'm paying a premium. Developing software is not an expensive, inexpensive endeavor. You're going to make it an investment and you. And you really need it to pay off in the long run. So what we've done to kind of address a lot of that, especially in the past, gosh, the past year, more so than any time prior, is we'll agree to value based pricing on the pilot portion of these programs just to help de risk that for everybody. You know, and we're moving more and more in that direction. And so what you'll start to see a lot from the industry, and we've been doing this for a while now, is. Okay, let's talk about your vision. We're going to take our best technical bas, we're going to do a deep dive and put together a clear project requirements document to start to kind of go back to like waterfall methodologies in some ways. So we're gathering as much as we can, documenting that, providing that as a markdown file to the AI tooling so that we've got really good context. Now, that's all for rate, because that's consulting and that's what we've been doing for a really long time. As soon as we start saying, for this clickable prototype, phase one, here's the fixed fee, we would. We can all align on that, the values there. You're comfortable with it, we're comfortable with it. Then we may choose, with their clarity, they're going to have no knowledge about this. We want to explore Firebase Studio for the clickable prototype on this project. For you, when you win or lose, that's on us. Your fee doesn't change. We're going to explore base 44. Win, lose, the onus is on us. Okay.
- [23:03]
B
Yes.
- [23:03]
A
So then that gives us a way to make sure that we still at least have some cash flow coming in. We can, we can take the risk as a business knowing that there's going to be some educational costs, but it's not going to be passed to the customer because we're all comfortable with the fee schedule.
- [23:18]
B
Yeah.
- [23:19]
A
Now, when you look at MCP servers with tools that are, you know, combine those with tools like cloud code, Cursor and others, well, now all of a sudden you've got all this knowledge and expertise that's provided in an MCP server. So it's not really a learning curve at that point as long as they develop their skills in using the products. In fact, the opposite is often true. They don't have to have deep technical knowledge of the API endpoints in dynamic CRM any longer because the MCP server provides all the context. Their expertise really should be residing with or using the appropriate selection and combination of agents and tools and skills.
- [23:56]
B
Right.
- [23:56]
A
You look at cloud code, you have all these different skills. That's where their expertise and knowledge really needs to reside. Now, not so much deep technical knowledge and upskilling on API endpoints and documentation.
- [24:07]
B
So that's a completely different. So one of the, one of the Reference points we share with like executives, at least on the knowledge work side, not the technical stuff, is we say that, that the paradigm of learning has changed. Right. Like I used to, if I wanted to be the expert in something, I went to school, I went to, you know, I got my, my college degree, I got an advanced degree, I went and maybe did some additional like specialized skill training so that at some point in the future, if somebody said, hey, Chris, you're the expert on this, what do you think I was expected to be able to like on demand, recall this information. Right. Today, as a knowledge worker, I don't have to go, oh, well, we need to schedule the, the, the expert to come in here. Oh, wait a minute. Hey, Chad, gbt act like the, Right, like there's that. And it sounds like with the MCPS and things like that, it's just you want, you don't want somebody who's never done, who's never worked in a development environment before. Of course, but they don't necessarily, because the way you just explained that to me, if I was a buyer, I'd say, oh, yeah, that makes perfect sense. Because I understand what you're saying. Right. But with the mcps. So that's like the, that's like the developer's equivalent of what I've been telling executives about using the models. You need to, you need to know how to use them. You don't need to have the information, you just need to know how to use the models to get the, to apply the information. Okay.
- [25:28]
A
Yeah. And you have to, you have to have, you have to bring the appropriate context into that conversation because it's only going to work with what you provide it. That's where a lot of expertise comes into play. You know, it's what are the watch outs? But you know, if you got 10, 15, 20 years of experience engineering, you're going to know that there's some challenges and you're going to cycle through the planning phase with Claude code saying, dig deeper, think about this. And it's going to say, oh, it's going to be very nice. It'll compliment you. Even that's a good idea. Let me do this. And it'll come back and say, oh, I found some gaps in the plan. So you still need really good, experienced engineers to get high value out of these solutions.
- [26:05]
B
You used the term earlier, the orchestrator, and I know that it was in reference to the agents, but it's more than that. It's orchestrating the entire process. But you can't lead the orchestra if You've never played the instrument. I mean, I guess you could, but I'd rather somebody who was familiar with had done it, had gotten their hands dirty.
- [26:27]
A
Before you got to know music theory, you gotta, at least you gotta have rhythm.
- [26:34]
B
So there was something else that came up in our conversation. You had mentioned that you had built an AI agent that does the work that a junior developer used to do.
- [26:42]
A
Yes.
- [26:43]
B
So what does that mean? A question that I get from a lot of people is what this means for my industry. Let's say it's the attorney. Well, as an attorney, there's a path. You graduate law school, you do, you know, you do the crap work and you do the long hours and then you get, you become the person who is the partner. Right. But if we remove those people, those junior developers, does that disrupt the. I mean, it certainly disrupts the existing paradigm, but does it disrupt the end result of me having senior developers if I don't like, if there's not, if I'm not bringing in these juniors anymore?
- [27:20]
A
It's a fantastic question that we have not found an answer to as of yet. It's, I think right now we're in that disruptive stage. And you're right. The traditional paradigm of journeyman to craftsman is, is no longer the pathway, it's got to change. And I firmly believe that in our education system needs to focus more on logic and reason education in those areas because the teaching, the tools, the tools are changing faster than we've ever seen. But if they've got a really strong foundation in logic and reason and then from there it's experience. And so we need our best knowledge workers to be able to assist with training this next generation of developers. But they're not going to be teaching them the tools, they're going to be teaching them how to think. But it's a tough one. I don't know how to unpack that. I really don't. We're still in it.
- [28:15]
B
Yeah. I think every industry is, you know, with, with this, at least it might, you might get the result faster. But with some more traditional industries, like it might be a five to 10 years before they realize, hey, wait a minute, we don't have anybody to take over when the boss is retiring or whatever.
- [28:32]
A
Yeah.
- [28:33]
B
So what we're finding is that a lot of companies that we're talking to, they're. Somebody's experimenting with something and it might be replit, it might be base 44, it might be cursor, it might be. But a lot of it tends to be Claude Code everybody's hearing about Claude. Code for maybe there's companies that before they, they engage with a professional development environment like what you've got, you guys have. They knew that there was some low hanging fruit. Maybe they had a couple of people that they were like, why don't we experiment our way to this small widget that we know would help in, you know, customer service or an accounting or whatever. What would you recommend to them? The, the DIYers, the home brewers. What a. There's a lot of tools out there. What's, what's leading the list for you as far as the, the tech stack or the tools that are available for somebody like me?
- [29:30]
A
Somebody like you? Well, you're fairly technical. Do you want to. Are we talking about someone who's fairly technical home brewers?
- [29:35]
B
No, I say homebrew, like literally like a home brewer. But I forget that there is a, a homebrew application that I've encountered. Yeah. So that was an accident. More like just the, probably the, the average listener to this, which is they're using it, they're getting wins from it and they want to be part of the, either the champion or part of that championing. Championing action in their organization for AI. And maybe they feel like, like I would love to be able to show the rest of the team some demonstrations of what's possible because the, the rest of the team doesn't know. So I want to get, maybe marketing had a couple ideas and I think that we could build something. I, I saw a TikTok reel or something where somebody had built something, but that individual wants to get some tools in the hands of their fellow enthusiasts who might be the builder, quote unquote. What are some of the tools out there that you think are the best and which ones should they probably avoid? Either because it's too technical or because it's over promised.
- [30:43]
A
Well, one of my favorites is Google Firebase Studio for generating clickable prototypes. But even before you get to that prototype, if they really want to have a fun, fast experiment, I would advise them. Well, first they have to have an idea, right. Generally there's going to be some concept that they want to explore. Bring the other subject matter expert, whoever you think might benefit from it in your department or another department in for an hour long brainstorm session. Use whatever AI agent you want to capture that transcript and ask a lot of clarifying questions. Then use AI to generate it could be ChatGPT, use that to generate a high level project requirements document focused on outputting a prd. But when you do that drop in the URL address to Firebase Studio's documentation, which is available publicly. So you just got to find that URL. So what you're doing is you're providing enough context that it understands what you want to have in that prd. Clickable prototype only. No backend, no database. Here's the documentation about the tool I want to use. Give me a prd, then take that prd. And I like to use Gemini because it has a lot of deep knowledge around, because obviously it's a Google family product. I'll have it generate the sequence of prompts for me. It'll give me the first prompt to set the projects up so that I can get to the clickable prototype I want. Here's a PRD for context. It'll give you your starting prompt. Then tell it to give me the sequence of prompts so I can generate the clickable prototype. Now, if you want to be a little bit more sophisticated with it, vibe with ChatGPT and provide it your, your brand guidelines and have it create a design standard markdown file because you provide, provide that as context, then it's going to be designed to match your brand on top of it. Now, don't be afraid to fail. That clickable product type might. It's not going to be 100%, you know, knock it out of the, out of the park first pass when you drop those in, if it's a little clunky or a little weird, tell it to export the code it generated, go back into Gemini, pump it in there and say, I had these problems with it. Give me another sequence of prompts and let's try again. Delete that project and do another one. Do another clickable prototype with a more improved sequence of. It's a lot of fun.
- [33:01]
B
So you're kind of having them not necessarily play against each other, but you're, you're not just sticking in, oh, I'm in Gemini. I'm going to build this thing. You're, you're bouncing around and getting the best of what the different models are able to do. Collaborating. You're orchestrating the different models working together for the solution. Yes, I like it. So I've been doing that with, you know, sometimes on strategic stuff or like, hey, the marketing messaging or whatever, but I haven't thought to do it with the vibing and for the listeners. Listen, like, I am not. I took, I think I even dropped out. I took like a class on coding in 1990 something. Right. So I'm not a tech person by any stretch. But I know, I know the outcomes that I want from my business or a client's business, and I know how to explain them well enough. And I've created this discipline or this habit of, oh, let me go to the models and not sitting there going, how do I do this? Oh, let me ask the models, how do I do this? Right. So I want, I want you to think if you're, if what you're hearing from Matt right now is you're like, well, that's a little over my head. Is not. It might be today, but if you were to sit down and with something like an arrangement, what he just, what he just talked about, I think you'd surprise yourself with. Now, is it something you're going to go and, you know, ship, sell to people tomorrow? No, but I think you'd be surprised with how quickly you can come up with something that is going to break. Probably. But you built that with your thought and these models doing the heavy lifting. And this goes back to that, that, you know, new way of learning. Right. You don't, you don't need to crack open the, the book about coding when you've got the model sitting there. So how are you guys using this, obviously in the development side of things for clients? I get it. But how have you introduced some of this operationally into what you're doing at Red Hawk?
- [35:05]
A
Well, great question. So we were looking at enterprise level ERP solution, professional service organizations, ERPs, everybody knows what those are, or at least I would assume for us it's managing our resources, our individual developers, their skill sets, and then clients contracts. All of this information has to be orchestrated. So basically the short story is we created our own custom ERP using this software development lifecycle that I've been kind of describing. And it's amazing what we've got in there. We actually included Gemini out of the box because of the tooling that we chose as an AI agent inside of the erp. And there's a view for me as CEO, I can navigate to a screen. It's called Hawkeye, affectionately because our business is Red Hawk Technologies. But I can put in a couple parameters and it will give me a current state of the business using natural language and processing all of my project managers agendas and minutes following meetings, sentiment throughout the organization based on meetings. So I get a state of the business and financial data because we have all our clients and contracts data in there and we're continuing to develop it. Now we have a specific product team that's helping us advance it fractionally. Within our organization because we're getting so much value for it. So for our organization alone, we're moving away from SaaS. We're creating our own SaaS solutions. Yes.
- [36:34]
B
Okay.
- [36:34]
A
And it's awesome. I think customers are going to start. Well, we're seeing it with our existing customers, but I think businesses in general will start to evaluate the old concept of buy versus build forever. CIOs been saying buy, don't build.
- [36:50]
B
Yeah, yeah, yeah.
- [36:52]
A
But that's, that's changing. Actually. We helped a customer recently do a gap analysis comparing the plan that they asked us to put together for them to seven industry leading platforms that they were evaluating. And we're looking at, I won't, you know, we're looking at 20%, 25% savings, total cost of ownership over three years to build something bespoke for them. Yeah, yeah, they own it forever. They're not paying. And as they, they're looking at doubling their, their fleet. They double their fleet, they double their licensing costs with any one of those seven platforms. Yes.
- [37:31]
B
So in your case with this state of the business tool, you said that you guys are productizing this and you're going to offer this as a service to your clients or.
- [37:40]
A
Well, the erp. The erp, we are considering white labeling, but it's going to be for our use only. There is, and this kind of goes back to your statement, your question about having AI do the work of junior engineers. So I want to unpack that because we do have a product that's already available now that is handling the software bill of materials management, detecting the vulnerabilities, which you'll recognize the language. Maybe not all the listeners do, but there's common vulnerabilities and exposures. The acronym is cve. Those are published at National Institute Science and Technology which is funded by the federal government, other institutions. So what that is, is software today is a series of building blocks like Legos, frameworks and packages. Nobody's writing your date selection device and you know, you buy airline tickets. That's a, that's a plugin. Right. Or it's a package, you know, so those things will ultimately have vulnerabilities that are detected and you have to patch them. So we have an agentic workflow now that handles the bill of materials. CV detection updates all those packages all automatically and then notifies the engineering team that they need to review the quality of that before it's published.
- [38:53]
B
Wow.
- [38:53]
A
And that's a subscription now that we have several customers paying us for. But we went one better, Chris and You'll appreciate this. And this is doing the work of senior engineers. One of the biggest challenges we have in the industry is keeping up with deep systematic technical documentation. We're developing, supporting and maintaining software. People will add comments, they might be good at it, they might not be good at it, but having really detailed documentation has always been a challenge out of the same platform. And this is fully agentic. Every time that there's a pull request or we can also set a schedule, all the repos are evaluated and that deep systematic technical documentation is generated as a markdown file for context for AI tooling to help us support and maintain these software products. So it's, that's how we're using it to change the way that we operate.
- [39:48]
B
So I want to kind of like move back towards the pricing conversation because yeah, as a listener, if they're out there and they are wanting to move forward with this new paradigm of billing, like even engage with Red Hawk, let's say, what should they expect the, the more traditional developers to say if they say, oh well, we got this, we got a 25 savings from Red Hawk as compared to what you guys would charge us with your, you know, established. What, what do you expect that counterparty to say to the potential buyer like when they hear that we're going to have it built ourselves and do something like this?
- [40:36]
A
I think our competitors who are not adopting rapidly enough. Well, there's two types of competitors. There are studios that will do project based work. They might still charge time and materials to do that project based work. But then there are much larger software consultancies that have a staff augmentation model and they're selling you butts and seats. They're the ones I think that are probably going to be a little bit more challenged because they're typically, it's up to the client to get value from the team. You'll describe what you want them to develop and they're going to say, well, you need a technical business analyst, you need a front end developer, a back end developer, a cloud engineer, and they'll tell you everybody that's going to be on that team. Then they'll show you the talent that they have and they'll give you different rates for every one of those people and you're going to look at a minimum X number of months or even a year, year and a half commitment and you're just paying for that team to be at your beck and call. So that's interesting. That's still time and materials. I think what they would say is well, I'm not sure other than this is the way that we sell and I can offer you this type of contract. I'm not sure how they would counter what we're doing.
- [41:45]
B
You're so there's no obvious like oh, they're going to say you can't trust AI to do it. They're not going to, there's, there's nothing that you're hearing your, your clients as they're out there shopping, coming back and saying, oh well, they said this, they
- [41:58]
A
might provide some, some examples out there that, to try and frighten them all. Scary stories. And there are scary stories. But you know what, there's always been scary stories in tech and even in traditional software engineering. So yeah, I think that they would, they would likely throw out some examples of things gone wrong. But you know what, that gives the customer an opportunity to ask more clarifying questions about how you prevent those types of issues from occurring. So hopefully you want them to circle back.
- [42:23]
B
Silver lining.
- [42:24]
A
Silver lining. Yeah.
- [42:26]
B
Yeah. So if they are approaching and, and they're ready to do some development, the client or the prospect, what would they expect if they encountered organization like Red Hawk when it came to that and how you would, how you would position this value based as compared to, well, you know, we've been working with the same tech vendor forever. They say they could do this too. What is that part of the conversation going to look like with them versus you?
- [42:59]
A
We're going to look at the opportunity of the solution they want to build and go through an early and this is typical with most organizations, but we're going to try to evaluate and understand the requirements as much as we can in the early in these conversations
- [43:19]
B
so
- [43:19]
A
that we can get to a value based pricing model for that clickable prototype. Because really what we want to do is start with that front end user experience first that can be vetted with the stakeholders. Then we can refine it before we do the back end build. Then we reestimate a rough order of magnitude budget for the actual development work because we'll give you the two different fees that we think you're going to look at. Right. You're going to encounter is applicable prototypes first. That's fixed. What comes next we're going to offer, and this is unique to Red Hawk because we offer a software development as a managed service so we can be your fractional DevOps team long term and you can amortize that investment out over that long term contract. So we're operating like an msp.
- [44:03]
B
Yeah, yeah.
- [44:04]
A
Not only we're going to build this solution for you in the next few months. We're on the hook to support it, maintain it, make sure it's operational, it doesn't have bugs, you don't have cybersecurity issues. That's why we have products like the Redhawk software comp analysis solution I was telling you about because it helps all of us if we're on the hook for how this thing performs after delivery. That's great. The competitors out there are still going to be largely either project based or time and materials either way. But they're thinking about new build deployment. Maybe there'll be a hosting fee. They'll most likely offer you a support maintenance agreement which will look like time and materials. Call us if you need us. And those are just basic service level agreements which I call break fix agreements because you won't call them because you don't want to pay them until something happens. So you're just waiting for something to go wrong. And now everybody's in this really difficult situation. Right. So that's a break fix contract breaks the you got to break and fix the relationship and it's not good. So our software development is a managed service model, accounts for all of those things and our customers can see total cost of ownership over multiple years. And from a business owner's perspective, if you're thinking about building something meaningful, you're going to think first capital expense. At some point that expense goes away. It's an add back and then. But you still want to know what your operating costs are going to look like for having that software in your IT portfolio. The way we work, we can answer all of those questions.
- [45:37]
B
Interesting. Well, I'll tell you, this is a perfect time because as I mentioned there's one of those software projects I've got on the side that's actually getting some traction. Nice. It's going to be time to bring on some more people. So the timing has been perfect for me. Very helpful to understand dynamic and I achieved the goal. I wanted the listener who is going to be encountering AI enabled or at least claiming AI enablement in these development environments to so I There's a saying I heard in finance, you're either at the table or you're on the table. Right. And I want my clients to be the ones that are at the table and not have a very expensive learning curve because they go there and they end up overpaying for something or they end up getting less than they were expecting. So Matt, thank you for kind of being that helping us find out how to audit our dev partners in the age of AI. But if people want to find out more about this model that you guys are doing and the way that you guys work, what's the next steps, they
- [46:47]
A
can certainly visit the Red hawk Technologies website, redhawk-tech.com and feel free to look me up by name on LinkedIn. I'm always happy to take a conversation and just share a little bit more insight. Educating and sharing knowledge is a passion of mine, so I'm always happy to have a conversation.
- [47:04]
B
Thank you for that. Yeah, and we're going to have that in the show notes for everybody as well. So this has been great. And thank you, Matt. I know that you guys are obviously busy with 50 devs and AI speeding up the velocity of everything for everybody, but I appreciate you taking the time and sharing this with our audience.
- [47:22]
A
It's my pleasure, Chris. Really enjoyed it.
- [47:24]
B
Thanks man. So if you got something out of this episode or any episode, the best way that you could say thank you would be to pass this episode or any of our episodes along to somebody, you know who's on the AI journey so that they can plug into the conversations that we're having here. And I just want to say thank you for listening to this episode and being a supporter. As of this recording, we've broken 250,000 downloads of the podcast, which is a lot. We've exceeded 100 episodes of the podcast, which is a lot. And I just want to thank everybody who has been there for the journey, both the guests and the listeners. So thanks everybody. We'll see you next week with another exciting episode of Using AI at Work.
- [48:07]
C
Thanks for tuning in to Using AI at Work. Don't forget to subscribe for more conversations about how to use AI at work and especially special thank you to our sponsor, Chief AI Officer for empowering businesses with AI education and training. Visit their website for a free AI Readiness Assessment and AI Strategy Guide to help you get started using AI at work. That's www.chiefai officer.com. follow us on Twitter at the handle using AIATWork and visit www.usingaiatwork.com for free resources to help you harness AI in your role.