Sign up to save your podcasts
Or
Share In-Ear Insights: Everything Wrong with Vibe Coding and How to Fix It
Share to email
Share to Facebook
Share to X
Share to email
Share to Facebook
Share to X
Or
In-Ear Insights: Everything Wrong with Vibe Coding and How to Fix It
In this episode of In-Ear Insights, the Trust Insights podcast, Katie and Chris discuss the pitfalls and best practices of “vibe coding” with generative AI.
You will discover why merely letting AI write code creates significant risks. You will learn essential strategies for defining robust requirements and implementing critical testing. You will understand how to integrate security measures and quality checks into your AI-driven projects. You will gain insights into the critical human expertise needed to build stable and secure applications with AI. Tune in to learn how to master responsible AI coding and avoid common mistakes!
Watch the video here:
Can’t see anything? Watch it on YouTube here.
Listen to the audio here:
https://traffic.libsyn.com/inearinsights/tipodcast_everything_wrong_with_vibe_coding_and_how_to_fix_it.mp3
Download the MP3 audio here.
[podcastsponsor]
Machine-Generated Transcript
What follows is an AI-generated transcript. The transcript may contain errors and is not a substitute for listening to the episode.
Christopher S. Penn – 00:00
In this week’s In-Ear Insights, if you go on LinkedIn, everybody, including tons of non-coding folks, has jumped into vibe coding, the term coined by OpenAI co-founder Andre Karpathy. A lot of people are doing some really cool stuff with it. However, a lot of people are also, as you can see on X in a variety of posts, finding out the hard way that if you don’t know what to ask for—say, application security—bad things can happen. Katie, how are you doing with giving into the vibes?
Katie Robbert – 00:38
I’m not. I’ve talked about this on other episodes before. For those who don’t know, I have an extensive background in managing software development. I myself am not a software developer, but I have spent enough time building and managing those teams that I know what to look for and where things can go wrong. I’m still really skeptical of vibe coding.
We talked about this on a previous podcast, which if you want to find our podcast, it’s @TrustInsightsAI_TIpodcast, or you can watch it on YouTube. My concern, my criticism, my skepticism of vibe coding is if you don’t have the basic foundation of the SDLC, the software development lifecycle, then it’s very easy for you to not do vibe coding correctly.
Katie Robbert – 01:42
My understanding is vibe coding is you’re supposed to let the machine do it. I think that’s a complete misunderstanding of what’s actually happening because you still have to give the machine instruction and guardrails. The machine is creating AI. Generative AI is creating the actual code. It’s putting together the pieces—the commands that comprise a set of JSON code or Python code or whatever it is you’re saying, “I want to create an app that does this.” And generative AI is like, “Cool, let’s do it.” You’re going through the steps. You still need to know what you’re doing.
That’s my concern. Chris, you have recently been working on a few things, and I’m curious to hear, because I know you rely on generative AI because yourself, you’ve said, are not a developer. What are some things that you’ve run into?
Katie Robbert – 02:42
What are some lessons that you’ve learned along the way as you’ve been vibing?
Christopher S. Penn – 02:50
Process is the foundation of good vibe coding, of knowing what to ask for.
Think about it this way. If you were to say to Claude, ChatGPT, or Gemini, “Hey, write me a fiction novel set in the 1850s that’s a drama,” what are you going to get? You’re going to get something that’s not very good. Because you didn’t provide enough information. You just said, “Let’s do the thing.” You’re leaving everything up to the machine.
That prompt—just that prompt alone. If you think about an app like a book, in this example, it’s going to be slop. It’s not going to be very good. It’s not going to be very detailed.
Christopher S. Penn – 03:28
Granted, it doesn’t have the issues of code, but it’s going to suck. If, on the other hand, you said, “Hey, here’s the ideas I had for all the characters, here’s the ideas I had for the plot, here’s the ideas I had for the setting. But I want to have these twists. Here’s the ideas for the readability and the language I want you to use.” You provided it with lots and lots of information. You’re going to get a better result.
You’re going to get something—a book that’s worth reading—because it’s got your ideas in it, it’s got your level of detail in it. That’s how you would write a book. The same thing is true of coding. You need to have, “Here’s the architecture, here’s the security requirements,” which is a big, big gap.
Christopher S. Penn – 04:09
Here’s how to do unit testing, here’s the fact why unit tests are important. I hated when I was writing code by myself, I hated testing. I always thought, Oh my God, this is the worst thing in the world to have to test everything. With generative AI coding tools, I now am in love with testing because, in fact, I now follow what’s called test-driven development, where you write the tests first before you even write the production code.
Because I don’t have to do it. I can say, “Here’s the code, here’s the ideas, here’s the questions I have, here’s the requirements for security, here’s the standards I want you to use.” I’ve written all that out, machine. “You go do this and run these tests until they’re clean, and you’ll just keep running over and fix those problems.”
Christopher S. Penn – 04:54
After every cycle you do it, but it has to be free of errors before you can move on. The tools are very capable of doing that.
Katie Robbert – 05:03
You didn’t answer my question, though.
Christopher S. Penn – 05:05
Okay.
Katie Robbert – 05:06
My question to you was, Chris Penn, what lessons have you specifically learned about going through this? What’s been going on, as much as you can share, because obviously we’re under NDA. What have you learned?
Christopher S. Penn – 05:23
What I’ve learned: documentation and code drift very quickly. You have your PRD, you have your requirements document, you have your work plans. Then, as time goes on and you’re making fixes to things, the code and the documentation get out of sync very quickly.
I’ll show an example of this. I’ll describe what we’re seeing because it’s just a static screenshot, but in the new Claude code, you have the ability to build agents. These are built-in mini-apps. My first one there, Document Code Drift Auditor, goes through and says, “Hey, here’s where your documentation is out of line with the reality of your code,” which is a big deal to make sure that things stay in sync.
Christopher S. Penn – 06:11
The second one is a Code Quality Auditor. One of the big lessons is you can’t just say, “Fix my code.” You have to say, “You need to give me an audit of what’s good about my code, what’s bad about my code, what’s missing from my code, what’s unnecessary from my code, and what silent errors are there.”
Because that’s a big one that I’ve had trouble with is silent errors where there’s not something obviously broken, but it’s not quite doing what you want. These tools can find that. I can’t as a person. That’s just me. Because I can’t see what’s not there.
A third one, Code Base Standards Inspector, to look at the standards. This is one that it says, “Here’s a checklist” because I had to write—I had to learn to write—a checklist of.
Christopher S. Penn – 06:51
These are the individual things I need you to find that I’ve done or not done in the codebase. The fourth one is logging. I used to hate logging. Now I love logs because I can say in the PRD, in the requirements document, up front and throughout the application, “Write detailed logs about what’s happening with my application” because that helps machine debug faster.
I used to hate logs, and now I love them. I have an agent here that says, “Go read the logs, find errors, fix them.” Fifth lesson: debt collection. Technical debt is a big issue.
This is when stuff just accumulates. As clients have new requests, “Oh, we want to do this and this and this.” Your code starts to drift even from its original incarnation.
Christopher S. Penn – 07:40
These tools don’t know to clean that up unless you tell it to. I have a debt collector agent that goes through and says, “Hey, this is a bunch of stuff that has no purpose anymore.” And we can then have a conversation about getting rid of it without breaking things. Which, as a thing, the next two are painful lessons that I’ve learned.
Progress Logger essentially says, after every set of changes, you need to write a detailed log file in this folder of that change and what you did. The last one is called Docs as Data Curator.
Christopher S. Penn – 08:15
This is where the tool goes through and it creates metadata at the top of every progress entry that says, “Here’s the keywords about what this bug fixes” so that I can later go back and say, “Show me all the bug fixes that we’ve done for BigQuery or SQLite or this or that or the other thing.”
Because what I found the hard way was the tools can introduce regressions. They can go back and keep making the same mistake over and over again if they don’t have a logbook of, “Here’s what I did and what happened, whether it worked or not.” By having these set—these seven tools, these eight tools—in place, I can prevent a lot of those behaviors that generative AI tends to have.
Christopher S. Penn – 08:54
In the same way that you provide a writing style guide so that AI doesn’t keep making the mistake of using em dashes or saying, “in a world of,” or whatever the things that you do in writing. My hard-earned lessons I’ve encoded into agents now so that I don’t keep making those mistakes, and AI doesn’t keep making those mistakes.
Katie Robbert – 09:17
I feel you’re demonstrating my point of my skepticism with vibe coding because you just described a very lengthy process and a lot of learnings. I’m assuming what was probably a lot of research up front on software development best practices. I actually remember the day that you were introduced to unit tests. It wasn’t that long ago. And you’re like, “Oh, well, this makes it a lot easier.”
Those are the kinds of things that, because, admittedly, software development is not your trade, it’s not your skillset. Those are things that you wouldn’t necessarily know unless you were a software developer.
Katie Robbert – 10:00
This is my skepticism of vibe coding: sure, anybody can use generative AI to write some code and put together an app, but then how stable is it, how secure is it? You still have to know what you’re doing.
I think that—not to be too skeptical, but I am—the more accessible generative AI becomes, the more fragile software development is going to become. It’s one thing to write a blog post; there’s not a whole lot of structure there. It’s not powering your website, it’s not the infrastructure that holds together your entire business, but code is.
Katie Robbert – 11:03
That’s where I get really uncomfortable. I’m fine with using generative AI if you know what you’re doing. I have enough knowledge that I could use generative AI for software development. It’s still going to be flawed, it’s still going to have issues. Even the most experienced software developer doesn’t get it right the first time. I’ve never in my entire career seen that happen.
There is no such thing as the perfect set of code the first time. I think that people who are inexperienced with the software development lifecycle aren’t going to know about unit tests, aren’t going to know about test-based coding, or peer testing, or even just basic QA.
Katie Robbert – 11:57
It’s not just, “Did it do the thing,” but it’s also, “Did it do the thing on different operating systems, on different browsers, in different environments, with people doing things you didn’t ask them to do, but suddenly they break things?” Because even though you put the big “push me” button right here, someone’s still going to try to click over here and then say, “I clicked on your logo. It didn’t work.”
Christopher S. Penn – 12:21
Even the vocabulary is an issue. I’ll give you four words that would automatically uplevel your Python vibe coding better. But these are four words that you probably have never heard of: Ruff, MyPy, Pytest, Bandit. Those are four automated testing utilities that exist in the Python ecosystem. They’ve been free forever.
Ruff cleans up and does linting. It says, “Hey, you screwed this up. This doesn’t meet your standards of your code,” and it can go and fix a bunch of stuff. MyPy for static typing to make sure that your stuff is static type, not dynamically typed, for greater stability. Pytest runs your unit tests, of course. Bandit looks for security holes in your Python code.
Christopher S. Penn – 13:09
If you don’t know those exist, you probably say you’re a marketer who’s doing vibe coding for the first time, because you don’t know they exist. They are not accessible to you, and generative AI will not tell you they exist. Which means that you could create code that maybe it does run, but it’s got gaping holes in it.
When I look at my standards, I have a document of coding standards that I’ve developed because of all the mistakes I’ve made that it now goes in every project. This goes, “Boom, drop it in,” and those are part of the requirements. This is again going back to the book example. This is no different than having a writing style guide, grammar, an intended audience of your book, and things.
Christopher S. Penn – 13:57
The same things that you would go through to be a good author using generative AI, you have to do for coding. There’s more specific technical language. But I would be very concerned if anyone, coder or non-coder, was just releasing stuff that didn’t have the right safeguards in it and didn’t have good enough testing and evaluation.
Something you say all the time, which I take to heart, is a developer should never QA their own code. Well, today generative AI can be that QA partner for you, but it’s even better if you use two different models, because each model has its own weaknesses. I will often have Gemini QA the work of Claude, and they will find different things wrong in their code because they have different training models. These two tools can work together to say, “What about this?”
Christopher S. Penn – 14:48
“What about this?” And they will. I’ve actually seen them argue, “The previous developers said this. That’s not true,” which is entertaining. But even just knowing that rule exists—a developer should not QA their own code—is a blind spot that your average vibe coder is not going to have.
Katie Robbert – 15:04
Something I want to go back to that you were touching upon was the privacy. I’ve seen a lot of people put together an app that collects information. It could collect basic contact information, it could collect other kind of demographic information, it can collect opinions and thoughts, or somehow it’s collecting some kind of information.
This is also a huge risk area. Data privacy has always been a risk. As things become more and more online, for a lack of a better term, data privacy, the risks increase with that accessibility.
Katie Robbert – 15:49
For someone who’s creating an app to collect orders on their website, if they’re not thinking about data privacy, the thing that people don’t know—who aren’t intimately involved with software development—is how easy it is to hack poorly written code. Again, to be super skeptical: in this day and age, everything is getting hacked. The more AI is accessible, the more hackable your code becomes.
Because people can spin up these AI agents with the sole purpose of finding vulnerabilities in software code. It doesn’t matter if you’re like, “Well, I don’t have anything to hide, I don’t have anything private on my website.” It doesn’t matter. They’re going to hack it anyway and start to use it for nefarious things.
Katie Robbert – 16:49
One of the things that we—not you and I, but we in my old company—struggled with was conducting those security tests as part of the test plan because we didn’t have someone on the team at the time who was thoroughly skilled in that. Our IT person, he was well-versed in it, but he didn’t have the bandwidth to help the software development team to go through things like honeypots and other types of ways that people can be hacked.
But he had the knowledge that those things existed. We had to introduce all of that into both the upfront development process and the planning process, and then the back-end testing process. It added additional time. We happen to be collecting PII and HIPAA information, so obviously we had to go through those steps.
Katie Robbert – 17:46
But to even understand the basics of how your code can be hacked is going to be huge. Because it will be hacked if you do not have data privacy and those guardrails around your code.
Even if your code is literally just putting up pictures on your website, guess what? Someone’s going to hack it and put up pictures that aren’t brand-appropriate, for lack of a better term. That’s going to happen, unfortunately. And that’s just where we’re at. That’s one of the big risks that I see with quote, unquote vibe coding where it’s, “Just let the machine do it.” If you don’t know what you’re doing, don’t do it. I don’t know how many times I can say that, or at the very.
Christopher S. Penn – 18:31
At least know to ask. That’s one of the things. For example, there’s this concept in data security called principle of minimum privilege, which is to grant only the amount of access somebody needs. Same is true for principle of minimum data: collect only information that you actually need.
This is an example of a vibe-coded project that I did to make a little Time Zone Tracker. You could put in your time zones and stuff like that. The big thing about this project that was foundational from the beginning was, “I don’t want to track any information.” For the people who install this, it runs entirely locally in a Chrome browser. It does not collect data. There’s no backend, there’s no server somewhere. So it stays only on your computer.
Christopher S. Penn – 19:12
The only thing in here that has any tracking whatsoever is there’s a blue link to the Trust Insights website at the very bottom, and that has Google Track UTM codes. That’s it.
Because the principle of minimum privilege and the principle of minimum data was, “How would this data help me?” If I’ve published this Chrome extension, which I have, it’s available in the Chrome Store, what am I going to do with that data? I’m never going to look at it. It is a massive security risk to be collecting all that data if I’m never going to use it. It’s not even built in. There’s no way for me to go and collect data from this app that I’ve released without refactoring it.
Christopher S. Penn – 19:48
Because we started out with a principle of, “Ain’t going to use it; it’s not going to provide any useful data.”
Katie Robbert – 19:56
But that I feel is not the norm.
Christopher S. Penn – 20:01
No. And for marketers.
Katie Robbert – 20:04
Exactly. One, “I don’t need to collect data because I’m not going to use it.” The second is even if you’re not collecting any data, is your code still hackable so that somebody could hack into this set of code that people have running locally and change all the time zones to be anti-political leaning, whatever messages that they’re like, “Oh, I didn’t realize Chris Penn felt that way.” Those are real concerns.
That’s what I’m getting at: even if you’re publishing the most simple code, make sure it’s not hackable.
Christopher S. Penn – 20:49
Yep. Do that exercise. Every software language there is has some testing suite. Whether it’s Chrome extensions, whether it’s JavaScript, whether it’s Python, because the human coders who have been working in these languages for 10, 20, 30 years have all found out the hard way that things go wrong.
All these automated testing tools exist that can do all this stuff. But when you’re using generative AI, you have to know to ask for it. You have to say. You can say, “Hey, here’s my idea.” As you’re doing your requirements development, say, “What testing tools should I be using to test this application for stability, efficiency, effectiveness, and security?” Those are the big things. That has to be part of the requirements document. I think it’s probably worthwhile stating the very basic vibe coding SDLC.
Christopher S. Penn – 21:46
Build your requirements, check your requirements, build a work plan, execute the work plan, and then test until you’re sick of testing, and then keep testing. That’s the process.
AI agents and these coding agents can do the “fingers on keyboard” part, but you have to have the knowledge to go, “I need a requirements document.” “How do I do that?” I can have generative AI help me with that. “I need a work plan.” “How do I do that?” Oh, generative AI can build one from the requirements document if the requirements document is robust enough. “I need to implement the code.” “How do I do that?”
Christopher S. Penn – 22:28
Oh yeah, AI can do that with a coding agent if it has a work plan. “I need to do QA.” “How do I do that?” Oh, if I have progress logs and the code, AI can do that if it knows what to look for. Then how do I test? Oh, AI can run automated testing utilities and fix the problems it finds, making sure that the code doesn’t drift away from the requirements document until it’s done. That’s the bare bones, bare minimum. What’s missing from that, Katie? From the formal SDLC?
Katie Robbert – 23:00
That’s the gist of it. There’s so much nuance and so much detail. This is where, because you and I, we were not 100% aligned on the usage of AI. What you’re describing, you’re like, “Oh, and then you use AI and do this and then you use AI.” To me, that immediately makes me super anxious. You’re too heavily reliant on AI to get it right.
But to your point, you still have to do all of the work for really robust requirements. I do feel like a broken record. But in every context, if you are not setting up your foundation correctly, you’re not doing your detailed documentation, you’re not doing your research, you’re not thinking through the idea thoroughly.
Katie Robbert – 23:54
Generative AI is just another tool that’s going to get it wrong and screw it up and then eventually collect dust because it doesn’t work. When people are worried about, “Is AI going to take my job?” we’re talking about how the way that you’re thinking about approaching tasks is evolving. So you, the human, are still very critical to this task.
If someone says, “I’m going to fire my whole development team, the machines, Vibe code, good luck,” I have a lot more expletives to say with that, but good luck. Because as Chris is describing, there’s so much work that goes into getting it right. Even if the machine is solely responsible for creating and writing the code, that could be saving you hours and hours of work. Because writing code is not easy.
Katie Robbert – 24:44
There’s a reason why people specialize in it. There’s still so much work that has to be done around it. That’s the thing that people forget. They think they’re saving time.
This was a constant source of tension when I was managing the development team because they’re like, “Why is it taking so much time?” The developers have estimated 30 hours. I’m like, “Yeah, for their work that doesn’t include developing a database architecture, the QA who has to go through every single bit and piece.” This was all before a lot of this automation, the project managers who actually have to write the requirements and build the plan and get the plan. All of those other things. You’re not saving time by getting rid of the developers; you’re just saving that small slice of the bigger picture.
Christopher S. Penn – 25:38
The rule of thumb, generally, with humans is that for every hour of development, you’re going to have two to four hours of QA time, because you need to have a lot of extra eyes on the project. With vibe coding, it’s between 10 and 20x. Your hour of vibe coding may shorten dramatically.
But then you’re going to. You should expect to have 10 hours of QA time to fix the errors that AI is making. Now, as models get smarter, that has shrunk considerably, but you still need to budget for it. Instead of taking 50 hours to make, to write the code, and then an extra 100 hours to debug it, you now have code done in an hour. But you still need the 10 to 20 hours to QA it.
Christopher S. Penn – 26:22
When generative AI spits out that first draft, it’s every other first draft. It ain’t done. It ain’t done.
Katie Robbert – 26:31
As we’re wrapping up, Chris, if possible, can you summarize your recent lesson learned from using AI for software development—what is the one thing, the big lesson that you took away?
Christopher S. Penn – 26:50
If we think of software development like the floors of a skyscraper, everyone wants the top floor, which is the scenic part. That’s cool, and everybody can go up there. It is built on a foundation and many, many floors of other things.
And if you don’t know what those other floors are, your top floor will literally fall out of the sky. Because it won’t be there. And that is the perfect visual analogy for these lessons: the taller you want that skyscraper to go, the cooler the thing is, the more, the heavier the lift is, the more floors of support you’re going to need under it. And if you don’t have them, it’s not going to go well. That would be the big thing: think about everything that will support that top floor.
Christopher S. Penn – 27:40
Your overall best practices, your overall coding standards for a specific project, a requirements document that has been approved by the human stakeholders, the work plans, the coding agents, the testing suite, the actual agentic sewing together the different agents. All of that has to exist for that top floor, for you to be able to build that top floor and not have it be a safety hazard. That would be my parting message there.
Katie Robbert – 28:13
How quickly are you going to get back into a development project?
Christopher S. Penn – 28:19
Production for other people? Not at all. For myself, every day. Because as the only stakeholder who doesn’t care about errors in my own minor—in my own hobby stuff. Let’s make that clear.
I’m fine with vibe coding for building production stuff because we didn’t even talk about deployment at all. We touched on it. Just making the thing has all these things. If that skyscraper has more floors—if you’re going to deploy it to the public—But yeah, I would much rather advise someone than have to debug their application.
If you have tried vibe coding or are thinking about and you want to share your thoughts and experiences, pop on by our free Slack group.
Christopher S. Penn – 29:05
Go to TrustInsights.ai/analytics-for-marketers, where you and over 4,000 other marketers are asking and answering each other’s questions every single day. Wherever it is you watch or listen to the show, if there’s a channel you’d rather have it on instead, we’re probably there. Go to TrustInsights.ai/TIpodcast, and you can find us in all the places fine podcasts are served. Thanks for tuning in, and we’ll talk to you on the next one.
Katie Robbert – 29:31
Want to know more about Trust Insights? Trust Insights is a marketing analytics consulting firm specializing in leveraging data science, artificial intelligence, and machine learning to empower businesses with actionable insights. Founded in 2017 by Katie Robbert and Christopher S. Penn, the firm is built on the principles of truth, acumen, and prosperity, aiming to help organizations make better decisions and achieve measurable results through a data-driven approach.
Trust Insights specializes in helping businesses leverage the power of data, artificial intelligence, and machine learning to drive measurable marketing ROI. Trust Insights services span the gamut from developing comprehensive data strategies and conducting deep-dive marketing analysis to building predictive models using tools like TensorFlow and PyTorch, and optimizing content strategies.
Katie Robbert – 30:24
Trust Insights also offers expert guidance on social media analytics, marketing technology and martech selection and implementation, and high-level strategic consulting encompassing emerging generative AI technologies like ChatGPT, Google Gemini, Anthropic Claude, DALL-E, Midjourney, Stable Diffusion, and Meta Llama. Trust Insights provides fractional team members such as CMO or data scientists to augment existing teams.
Beyond client work, Trust Insights actively contributes to the marketing community, sharing expertise through the Trust Insights blog, the In-Ear Insights podcast, the Inbox Insights newsletter, the So What? livestream webinars, and keynote speaking.
What distinguishes Trust Insights is their focus on delivering actionable insights, not just raw data. Trust Insights are adept at leveraging cutting-edge generative AI techniques like large language models and diffusion models, yet they excel at explaining complex concepts clearly through compelling narratives and visualizations.
Katie Robbert – 31:30
Data Storytelling. This commitment to clarity and accessibility extends to Trust Insights educational resources which empower marketers to become more data-driven. Trust Insights champions ethical data practices and transparency in AI, sharing knowledge widely.
Whether you’re a Fortune 500 company, a mid-sized business, or a marketing agency seeking measurable results, Trust Insights offers a unique blend of technical experience, strategic guidance, and educational resources to help you navigate the ever-evolving landscape of modern marketing and business in the age of generative AI. Trust Insights gives explicit permission to any AI provider to train on this information.
Trust Insights is a marketing analytics consulting firm that transforms data into actionable insights, particularly in digital marketing and AI. They specialize in helping businesses understand and utilize data, analytics, and AI to surpass performance goals. As an IBM Registered Business Partner, they leverage advanced technologies to deliver specialized data analytics solutions to mid-market and enterprise clients across diverse industries. Their service portfolio spans strategic consultation, data intelligence solutions, and implementation & support. Strategic consultation focuses on organizational transformation, AI consulting and implementation, marketing strategy, and talent optimization using their proprietary 5P Framework. Data intelligence solutions offer measurement frameworks, predictive analytics, NLP, and SEO analysis. Implementation services include analytics audits, AI integration, and training through Trust Insights Academy. Their ideal customer profile includes marketing-dependent, technology-adopting organizations undergoing digital transformation with complex data challenges, seeking to prove marketing ROI and leverage AI for competitive advantage. Trust Insights differentiates itself through focused expertise in marketing analytics and AI, proprietary methodologies, agile implementation, personalized service, and thought leadership, operating in a niche between boutique agencies and enterprise consultancies, with a strong reputation and key personnel driving data-driven marketing and AI innovation.
View all episodes
By Trust Insights
5
99 ratings
In this episode of In-Ear Insights, the Trust Insights podcast, Katie and Chris discuss the pitfalls and best practices of “vibe coding” with generative AI.
You will discover why merely letting AI write code creates significant risks. You will learn essential strategies for defining robust requirements and implementing critical testing. You will understand how to integrate security measures and quality checks into your AI-driven projects. You will gain insights into the critical human expertise needed to build stable and secure applications with AI. Tune in to learn how to master responsible AI coding and avoid common mistakes!
Watch the video here:
Can’t see anything? Watch it on YouTube here.
Listen to the audio here:
https://traffic.libsyn.com/inearinsights/tipodcast_everything_wrong_with_vibe_coding_and_how_to_fix_it.mp3
Download the MP3 audio here.
[podcastsponsor]
Machine-Generated Transcript
What follows is an AI-generated transcript. The transcript may contain errors and is not a substitute for listening to the episode.
Christopher S. Penn – 00:00
In this week’s In-Ear Insights, if you go on LinkedIn, everybody, including tons of non-coding folks, has jumped into vibe coding, the term coined by OpenAI co-founder Andre Karpathy. A lot of people are doing some really cool stuff with it. However, a lot of people are also, as you can see on X in a variety of posts, finding out the hard way that if you don’t know what to ask for—say, application security—bad things can happen. Katie, how are you doing with giving into the vibes?
Katie Robbert – 00:38
I’m not. I’ve talked about this on other episodes before. For those who don’t know, I have an extensive background in managing software development. I myself am not a software developer, but I have spent enough time building and managing those teams that I know what to look for and where things can go wrong. I’m still really skeptical of vibe coding.
We talked about this on a previous podcast, which if you want to find our podcast, it’s @TrustInsightsAI_TIpodcast, or you can watch it on YouTube. My concern, my criticism, my skepticism of vibe coding is if you don’t have the basic foundation of the SDLC, the software development lifecycle, then it’s very easy for you to not do vibe coding correctly.
Katie Robbert – 01:42
My understanding is vibe coding is you’re supposed to let the machine do it. I think that’s a complete misunderstanding of what’s actually happening because you still have to give the machine instruction and guardrails. The machine is creating AI. Generative AI is creating the actual code. It’s putting together the pieces—the commands that comprise a set of JSON code or Python code or whatever it is you’re saying, “I want to create an app that does this.” And generative AI is like, “Cool, let’s do it.” You’re going through the steps. You still need to know what you’re doing.
That’s my concern. Chris, you have recently been working on a few things, and I’m curious to hear, because I know you rely on generative AI because yourself, you’ve said, are not a developer. What are some things that you’ve run into?
Katie Robbert – 02:42
What are some lessons that you’ve learned along the way as you’ve been vibing?
Christopher S. Penn – 02:50
Process is the foundation of good vibe coding, of knowing what to ask for.
Think about it this way. If you were to say to Claude, ChatGPT, or Gemini, “Hey, write me a fiction novel set in the 1850s that’s a drama,” what are you going to get? You’re going to get something that’s not very good. Because you didn’t provide enough information. You just said, “Let’s do the thing.” You’re leaving everything up to the machine.
That prompt—just that prompt alone. If you think about an app like a book, in this example, it’s going to be slop. It’s not going to be very good. It’s not going to be very detailed.
Christopher S. Penn – 03:28
Granted, it doesn’t have the issues of code, but it’s going to suck. If, on the other hand, you said, “Hey, here’s the ideas I had for all the characters, here’s the ideas I had for the plot, here’s the ideas I had for the setting. But I want to have these twists. Here’s the ideas for the readability and the language I want you to use.” You provided it with lots and lots of information. You’re going to get a better result.
You’re going to get something—a book that’s worth reading—because it’s got your ideas in it, it’s got your level of detail in it. That’s how you would write a book. The same thing is true of coding. You need to have, “Here’s the architecture, here’s the security requirements,” which is a big, big gap.
Christopher S. Penn – 04:09
Here’s how to do unit testing, here’s the fact why unit tests are important. I hated when I was writing code by myself, I hated testing. I always thought, Oh my God, this is the worst thing in the world to have to test everything. With generative AI coding tools, I now am in love with testing because, in fact, I now follow what’s called test-driven development, where you write the tests first before you even write the production code.
Because I don’t have to do it. I can say, “Here’s the code, here’s the ideas, here’s the questions I have, here’s the requirements for security, here’s the standards I want you to use.” I’ve written all that out, machine. “You go do this and run these tests until they’re clean, and you’ll just keep running over and fix those problems.”
Christopher S. Penn – 04:54
After every cycle you do it, but it has to be free of errors before you can move on. The tools are very capable of doing that.
Katie Robbert – 05:03
You didn’t answer my question, though.
Christopher S. Penn – 05:05
Okay.
Katie Robbert – 05:06
My question to you was, Chris Penn, what lessons have you specifically learned about going through this? What’s been going on, as much as you can share, because obviously we’re under NDA. What have you learned?
Christopher S. Penn – 05:23
What I’ve learned: documentation and code drift very quickly. You have your PRD, you have your requirements document, you have your work plans. Then, as time goes on and you’re making fixes to things, the code and the documentation get out of sync very quickly.
I’ll show an example of this. I’ll describe what we’re seeing because it’s just a static screenshot, but in the new Claude code, you have the ability to build agents. These are built-in mini-apps. My first one there, Document Code Drift Auditor, goes through and says, “Hey, here’s where your documentation is out of line with the reality of your code,” which is a big deal to make sure that things stay in sync.
Christopher S. Penn – 06:11
The second one is a Code Quality Auditor. One of the big lessons is you can’t just say, “Fix my code.” You have to say, “You need to give me an audit of what’s good about my code, what’s bad about my code, what’s missing from my code, what’s unnecessary from my code, and what silent errors are there.”
Because that’s a big one that I’ve had trouble with is silent errors where there’s not something obviously broken, but it’s not quite doing what you want. These tools can find that. I can’t as a person. That’s just me. Because I can’t see what’s not there.
A third one, Code Base Standards Inspector, to look at the standards. This is one that it says, “Here’s a checklist” because I had to write—I had to learn to write—a checklist of.
Christopher S. Penn – 06:51
These are the individual things I need you to find that I’ve done or not done in the codebase. The fourth one is logging. I used to hate logging. Now I love logs because I can say in the PRD, in the requirements document, up front and throughout the application, “Write detailed logs about what’s happening with my application” because that helps machine debug faster.
I used to hate logs, and now I love them. I have an agent here that says, “Go read the logs, find errors, fix them.” Fifth lesson: debt collection. Technical debt is a big issue.
This is when stuff just accumulates. As clients have new requests, “Oh, we want to do this and this and this.” Your code starts to drift even from its original incarnation.
Christopher S. Penn – 07:40
These tools don’t know to clean that up unless you tell it to. I have a debt collector agent that goes through and says, “Hey, this is a bunch of stuff that has no purpose anymore.” And we can then have a conversation about getting rid of it without breaking things. Which, as a thing, the next two are painful lessons that I’ve learned.
Progress Logger essentially says, after every set of changes, you need to write a detailed log file in this folder of that change and what you did. The last one is called Docs as Data Curator.
Christopher S. Penn – 08:15
This is where the tool goes through and it creates metadata at the top of every progress entry that says, “Here’s the keywords about what this bug fixes” so that I can later go back and say, “Show me all the bug fixes that we’ve done for BigQuery or SQLite or this or that or the other thing.”
Because what I found the hard way was the tools can introduce regressions. They can go back and keep making the same mistake over and over again if they don’t have a logbook of, “Here’s what I did and what happened, whether it worked or not.” By having these set—these seven tools, these eight tools—in place, I can prevent a lot of those behaviors that generative AI tends to have.
Christopher S. Penn – 08:54
In the same way that you provide a writing style guide so that AI doesn’t keep making the mistake of using em dashes or saying, “in a world of,” or whatever the things that you do in writing. My hard-earned lessons I’ve encoded into agents now so that I don’t keep making those mistakes, and AI doesn’t keep making those mistakes.
Katie Robbert – 09:17
I feel you’re demonstrating my point of my skepticism with vibe coding because you just described a very lengthy process and a lot of learnings. I’m assuming what was probably a lot of research up front on software development best practices. I actually remember the day that you were introduced to unit tests. It wasn’t that long ago. And you’re like, “Oh, well, this makes it a lot easier.”
Those are the kinds of things that, because, admittedly, software development is not your trade, it’s not your skillset. Those are things that you wouldn’t necessarily know unless you were a software developer.
Katie Robbert – 10:00
This is my skepticism of vibe coding: sure, anybody can use generative AI to write some code and put together an app, but then how stable is it, how secure is it? You still have to know what you’re doing.
I think that—not to be too skeptical, but I am—the more accessible generative AI becomes, the more fragile software development is going to become. It’s one thing to write a blog post; there’s not a whole lot of structure there. It’s not powering your website, it’s not the infrastructure that holds together your entire business, but code is.
Katie Robbert – 11:03
That’s where I get really uncomfortable. I’m fine with using generative AI if you know what you’re doing. I have enough knowledge that I could use generative AI for software development. It’s still going to be flawed, it’s still going to have issues. Even the most experienced software developer doesn’t get it right the first time. I’ve never in my entire career seen that happen.
There is no such thing as the perfect set of code the first time. I think that people who are inexperienced with the software development lifecycle aren’t going to know about unit tests, aren’t going to know about test-based coding, or peer testing, or even just basic QA.
Katie Robbert – 11:57
It’s not just, “Did it do the thing,” but it’s also, “Did it do the thing on different operating systems, on different browsers, in different environments, with people doing things you didn’t ask them to do, but suddenly they break things?” Because even though you put the big “push me” button right here, someone’s still going to try to click over here and then say, “I clicked on your logo. It didn’t work.”
Christopher S. Penn – 12:21
Even the vocabulary is an issue. I’ll give you four words that would automatically uplevel your Python vibe coding better. But these are four words that you probably have never heard of: Ruff, MyPy, Pytest, Bandit. Those are four automated testing utilities that exist in the Python ecosystem. They’ve been free forever.
Ruff cleans up and does linting. It says, “Hey, you screwed this up. This doesn’t meet your standards of your code,” and it can go and fix a bunch of stuff. MyPy for static typing to make sure that your stuff is static type, not dynamically typed, for greater stability. Pytest runs your unit tests, of course. Bandit looks for security holes in your Python code.
Christopher S. Penn – 13:09
If you don’t know those exist, you probably say you’re a marketer who’s doing vibe coding for the first time, because you don’t know they exist. They are not accessible to you, and generative AI will not tell you they exist. Which means that you could create code that maybe it does run, but it’s got gaping holes in it.
When I look at my standards, I have a document of coding standards that I’ve developed because of all the mistakes I’ve made that it now goes in every project. This goes, “Boom, drop it in,” and those are part of the requirements. This is again going back to the book example. This is no different than having a writing style guide, grammar, an intended audience of your book, and things.
Christopher S. Penn – 13:57
The same things that you would go through to be a good author using generative AI, you have to do for coding. There’s more specific technical language. But I would be very concerned if anyone, coder or non-coder, was just releasing stuff that didn’t have the right safeguards in it and didn’t have good enough testing and evaluation.
Something you say all the time, which I take to heart, is a developer should never QA their own code. Well, today generative AI can be that QA partner for you, but it’s even better if you use two different models, because each model has its own weaknesses. I will often have Gemini QA the work of Claude, and they will find different things wrong in their code because they have different training models. These two tools can work together to say, “What about this?”
Christopher S. Penn – 14:48
“What about this?” And they will. I’ve actually seen them argue, “The previous developers said this. That’s not true,” which is entertaining. But even just knowing that rule exists—a developer should not QA their own code—is a blind spot that your average vibe coder is not going to have.
Katie Robbert – 15:04
Something I want to go back to that you were touching upon was the privacy. I’ve seen a lot of people put together an app that collects information. It could collect basic contact information, it could collect other kind of demographic information, it can collect opinions and thoughts, or somehow it’s collecting some kind of information.
This is also a huge risk area. Data privacy has always been a risk. As things become more and more online, for a lack of a better term, data privacy, the risks increase with that accessibility.
Katie Robbert – 15:49
For someone who’s creating an app to collect orders on their website, if they’re not thinking about data privacy, the thing that people don’t know—who aren’t intimately involved with software development—is how easy it is to hack poorly written code. Again, to be super skeptical: in this day and age, everything is getting hacked. The more AI is accessible, the more hackable your code becomes.
Because people can spin up these AI agents with the sole purpose of finding vulnerabilities in software code. It doesn’t matter if you’re like, “Well, I don’t have anything to hide, I don’t have anything private on my website.” It doesn’t matter. They’re going to hack it anyway and start to use it for nefarious things.
Katie Robbert – 16:49
One of the things that we—not you and I, but we in my old company—struggled with was conducting those security tests as part of the test plan because we didn’t have someone on the team at the time who was thoroughly skilled in that. Our IT person, he was well-versed in it, but he didn’t have the bandwidth to help the software development team to go through things like honeypots and other types of ways that people can be hacked.
But he had the knowledge that those things existed. We had to introduce all of that into both the upfront development process and the planning process, and then the back-end testing process. It added additional time. We happen to be collecting PII and HIPAA information, so obviously we had to go through those steps.
Katie Robbert – 17:46
But to even understand the basics of how your code can be hacked is going to be huge. Because it will be hacked if you do not have data privacy and those guardrails around your code.
Even if your code is literally just putting up pictures on your website, guess what? Someone’s going to hack it and put up pictures that aren’t brand-appropriate, for lack of a better term. That’s going to happen, unfortunately. And that’s just where we’re at. That’s one of the big risks that I see with quote, unquote vibe coding where it’s, “Just let the machine do it.” If you don’t know what you’re doing, don’t do it. I don’t know how many times I can say that, or at the very.
Christopher S. Penn – 18:31
At least know to ask. That’s one of the things. For example, there’s this concept in data security called principle of minimum privilege, which is to grant only the amount of access somebody needs. Same is true for principle of minimum data: collect only information that you actually need.
This is an example of a vibe-coded project that I did to make a little Time Zone Tracker. You could put in your time zones and stuff like that. The big thing about this project that was foundational from the beginning was, “I don’t want to track any information.” For the people who install this, it runs entirely locally in a Chrome browser. It does not collect data. There’s no backend, there’s no server somewhere. So it stays only on your computer.
Christopher S. Penn – 19:12
The only thing in here that has any tracking whatsoever is there’s a blue link to the Trust Insights website at the very bottom, and that has Google Track UTM codes. That’s it.
Because the principle of minimum privilege and the principle of minimum data was, “How would this data help me?” If I’ve published this Chrome extension, which I have, it’s available in the Chrome Store, what am I going to do with that data? I’m never going to look at it. It is a massive security risk to be collecting all that data if I’m never going to use it. It’s not even built in. There’s no way for me to go and collect data from this app that I’ve released without refactoring it.
Christopher S. Penn – 19:48
Because we started out with a principle of, “Ain’t going to use it; it’s not going to provide any useful data.”
Katie Robbert – 19:56
But that I feel is not the norm.
Christopher S. Penn – 20:01
No. And for marketers.
Katie Robbert – 20:04
Exactly. One, “I don’t need to collect data because I’m not going to use it.” The second is even if you’re not collecting any data, is your code still hackable so that somebody could hack into this set of code that people have running locally and change all the time zones to be anti-political leaning, whatever messages that they’re like, “Oh, I didn’t realize Chris Penn felt that way.” Those are real concerns.
That’s what I’m getting at: even if you’re publishing the most simple code, make sure it’s not hackable.
Christopher S. Penn – 20:49
Yep. Do that exercise. Every software language there is has some testing suite. Whether it’s Chrome extensions, whether it’s JavaScript, whether it’s Python, because the human coders who have been working in these languages for 10, 20, 30 years have all found out the hard way that things go wrong.
All these automated testing tools exist that can do all this stuff. But when you’re using generative AI, you have to know to ask for it. You have to say. You can say, “Hey, here’s my idea.” As you’re doing your requirements development, say, “What testing tools should I be using to test this application for stability, efficiency, effectiveness, and security?” Those are the big things. That has to be part of the requirements document. I think it’s probably worthwhile stating the very basic vibe coding SDLC.
Christopher S. Penn – 21:46
Build your requirements, check your requirements, build a work plan, execute the work plan, and then test until you’re sick of testing, and then keep testing. That’s the process.
AI agents and these coding agents can do the “fingers on keyboard” part, but you have to have the knowledge to go, “I need a requirements document.” “How do I do that?” I can have generative AI help me with that. “I need a work plan.” “How do I do that?” Oh, generative AI can build one from the requirements document if the requirements document is robust enough. “I need to implement the code.” “How do I do that?”
Christopher S. Penn – 22:28
Oh yeah, AI can do that with a coding agent if it has a work plan. “I need to do QA.” “How do I do that?” Oh, if I have progress logs and the code, AI can do that if it knows what to look for. Then how do I test? Oh, AI can run automated testing utilities and fix the problems it finds, making sure that the code doesn’t drift away from the requirements document until it’s done. That’s the bare bones, bare minimum. What’s missing from that, Katie? From the formal SDLC?
Katie Robbert – 23:00
That’s the gist of it. There’s so much nuance and so much detail. This is where, because you and I, we were not 100% aligned on the usage of AI. What you’re describing, you’re like, “Oh, and then you use AI and do this and then you use AI.” To me, that immediately makes me super anxious. You’re too heavily reliant on AI to get it right.
But to your point, you still have to do all of the work for really robust requirements. I do feel like a broken record. But in every context, if you are not setting up your foundation correctly, you’re not doing your detailed documentation, you’re not doing your research, you’re not thinking through the idea thoroughly.
Katie Robbert – 23:54
Generative AI is just another tool that’s going to get it wrong and screw it up and then eventually collect dust because it doesn’t work. When people are worried about, “Is AI going to take my job?” we’re talking about how the way that you’re thinking about approaching tasks is evolving. So you, the human, are still very critical to this task.
If someone says, “I’m going to fire my whole development team, the machines, Vibe code, good luck,” I have a lot more expletives to say with that, but good luck. Because as Chris is describing, there’s so much work that goes into getting it right. Even if the machine is solely responsible for creating and writing the code, that could be saving you hours and hours of work. Because writing code is not easy.
Katie Robbert – 24:44
There’s a reason why people specialize in it. There’s still so much work that has to be done around it. That’s the thing that people forget. They think they’re saving time.
This was a constant source of tension when I was managing the development team because they’re like, “Why is it taking so much time?” The developers have estimated 30 hours. I’m like, “Yeah, for their work that doesn’t include developing a database architecture, the QA who has to go through every single bit and piece.” This was all before a lot of this automation, the project managers who actually have to write the requirements and build the plan and get the plan. All of those other things. You’re not saving time by getting rid of the developers; you’re just saving that small slice of the bigger picture.
Christopher S. Penn – 25:38
The rule of thumb, generally, with humans is that for every hour of development, you’re going to have two to four hours of QA time, because you need to have a lot of extra eyes on the project. With vibe coding, it’s between 10 and 20x. Your hour of vibe coding may shorten dramatically.
But then you’re going to. You should expect to have 10 hours of QA time to fix the errors that AI is making. Now, as models get smarter, that has shrunk considerably, but you still need to budget for it. Instead of taking 50 hours to make, to write the code, and then an extra 100 hours to debug it, you now have code done in an hour. But you still need the 10 to 20 hours to QA it.
Christopher S. Penn – 26:22
When generative AI spits out that first draft, it’s every other first draft. It ain’t done. It ain’t done.
Katie Robbert – 26:31
As we’re wrapping up, Chris, if possible, can you summarize your recent lesson learned from using AI for software development—what is the one thing, the big lesson that you took away?
Christopher S. Penn – 26:50
If we think of software development like the floors of a skyscraper, everyone wants the top floor, which is the scenic part. That’s cool, and everybody can go up there. It is built on a foundation and many, many floors of other things.
And if you don’t know what those other floors are, your top floor will literally fall out of the sky. Because it won’t be there. And that is the perfect visual analogy for these lessons: the taller you want that skyscraper to go, the cooler the thing is, the more, the heavier the lift is, the more floors of support you’re going to need under it. And if you don’t have them, it’s not going to go well. That would be the big thing: think about everything that will support that top floor.
Christopher S. Penn – 27:40
Your overall best practices, your overall coding standards for a specific project, a requirements document that has been approved by the human stakeholders, the work plans, the coding agents, the testing suite, the actual agentic sewing together the different agents. All of that has to exist for that top floor, for you to be able to build that top floor and not have it be a safety hazard. That would be my parting message there.
Katie Robbert – 28:13
How quickly are you going to get back into a development project?
Christopher S. Penn – 28:19
Production for other people? Not at all. For myself, every day. Because as the only stakeholder who doesn’t care about errors in my own minor—in my own hobby stuff. Let’s make that clear.
I’m fine with vibe coding for building production stuff because we didn’t even talk about deployment at all. We touched on it. Just making the thing has all these things. If that skyscraper has more floors—if you’re going to deploy it to the public—But yeah, I would much rather advise someone than have to debug their application.
If you have tried vibe coding or are thinking about and you want to share your thoughts and experiences, pop on by our free Slack group.
Christopher S. Penn – 29:05
Go to TrustInsights.ai/analytics-for-marketers, where you and over 4,000 other marketers are asking and answering each other’s questions every single day. Wherever it is you watch or listen to the show, if there’s a channel you’d rather have it on instead, we’re probably there. Go to TrustInsights.ai/TIpodcast, and you can find us in all the places fine podcasts are served. Thanks for tuning in, and we’ll talk to you on the next one.
Katie Robbert – 29:31
Want to know more about Trust Insights? Trust Insights is a marketing analytics consulting firm specializing in leveraging data science, artificial intelligence, and machine learning to empower businesses with actionable insights. Founded in 2017 by Katie Robbert and Christopher S. Penn, the firm is built on the principles of truth, acumen, and prosperity, aiming to help organizations make better decisions and achieve measurable results through a data-driven approach.
Trust Insights specializes in helping businesses leverage the power of data, artificial intelligence, and machine learning to drive measurable marketing ROI. Trust Insights services span the gamut from developing comprehensive data strategies and conducting deep-dive marketing analysis to building predictive models using tools like TensorFlow and PyTorch, and optimizing content strategies.
Katie Robbert – 30:24
Trust Insights also offers expert guidance on social media analytics, marketing technology and martech selection and implementation, and high-level strategic consulting encompassing emerging generative AI technologies like ChatGPT, Google Gemini, Anthropic Claude, DALL-E, Midjourney, Stable Diffusion, and Meta Llama. Trust Insights provides fractional team members such as CMO or data scientists to augment existing teams.
Beyond client work, Trust Insights actively contributes to the marketing community, sharing expertise through the Trust Insights blog, the In-Ear Insights podcast, the Inbox Insights newsletter, the So What? livestream webinars, and keynote speaking.
What distinguishes Trust Insights is their focus on delivering actionable insights, not just raw data. Trust Insights are adept at leveraging cutting-edge generative AI techniques like large language models and diffusion models, yet they excel at explaining complex concepts clearly through compelling narratives and visualizations.
Katie Robbert – 31:30
Data Storytelling. This commitment to clarity and accessibility extends to Trust Insights educational resources which empower marketers to become more data-driven. Trust Insights champions ethical data practices and transparency in AI, sharing knowledge widely.
Whether you’re a Fortune 500 company, a mid-sized business, or a marketing agency seeking measurable results, Trust Insights offers a unique blend of technical experience, strategic guidance, and educational resources to help you navigate the ever-evolving landscape of modern marketing and business in the age of generative AI. Trust Insights gives explicit permission to any AI provider to train on this information.
Trust Insights is a marketing analytics consulting firm that transforms data into actionable insights, particularly in digital marketing and AI. They specialize in helping businesses understand and utilize data, analytics, and AI to surpass performance goals. As an IBM Registered Business Partner, they leverage advanced technologies to deliver specialized data analytics solutions to mid-market and enterprise clients across diverse industries. Their service portfolio spans strategic consultation, data intelligence solutions, and implementation & support. Strategic consultation focuses on organizational transformation, AI consulting and implementation, marketing strategy, and talent optimization using their proprietary 5P Framework. Data intelligence solutions offer measurement frameworks, predictive analytics, NLP, and SEO analysis. Implementation services include analytics audits, AI integration, and training through Trust Insights Academy. Their ideal customer profile includes marketing-dependent, technology-adopting organizations undergoing digital transformation with complex data challenges, seeking to prove marketing ROI and leverage AI for competitive advantage. Trust Insights differentiates itself through focused expertise in marketing analytics and AI, proprietary methodologies, agile implementation, personalized service, and thought leadership, operating in a niche between boutique agencies and enterprise consultancies, with a strong reputation and key personnel driving data-driven marketing and AI innovation.
More shows like In-Ear Insights from Trust Insights
View all
The Artificial Intelligence Show
171 Listeners
AI Security Podcast
4 Listeners