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:

Download the MP3 audio here.

• Need help with your company’s data and analytics? Let us know!


• Join our free Slack group for marketers interested in analytics!

[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