Vibe Coding 2.0 is here...

Video authored by the channel shown, not by IANIA; all rights belong to the creator. Transcript and summary generated automatically; the original-language content is preserved.

Original language: English

Original video: Vibe Coding 2.0 is here… · Channel: Wes Roth · 08:55 · Watch on YouTube

Topics: AI agents, Enterprise AI applications, Cybersecurity and software security, Software engineering with AI, AI governance and regulation

Summary

Wes Roth demonstrates building a customer support CRM with Superblocks, following a $249 refund request from an agent to a manager’s approval. The example highlights how different roles need different information and permissions, and why access rules must be enforced in the operation itself—not just by hiding interface controls. Security scans identify issues involving browser-supplied identity and refund amounts, while audit logs and a security center give IT visibility into app changes and vulnerabilities. The video also presents Superblocks’ deployment options and argues that enterprise AI app building requires oversight of access, sensitive actions, review, and deployment.

Key points

The CRM brings together customer details, tickets, orders, refund requests, and a history of what happened.
The example business rule is that support agents can request refunds, while managers make the decision.
The agent and manager need different information and actions for the same refund.
Superblocks apps use SSO login by default to identify the user and their group.
Hiding an approval button is not sufficient: the action that changes refund status must also verify that the user is a manager.
Automated security checks found browser-trusted identity information and a missing check against the original order total.
The demo’s approval flow still runs in the browser; a real rollout would also need server-side authorization.
The CRM’s business history is distinct from platform audit logs and the security center’s company-wide app visibility.
The video says Superblocks Cloud Prem runs in a company’s AWS account, with the app, data, and inference through Amazon Bedrock staying in that environment.
The video frames Superblocks as a middle ground between blocking AI-built apps and letting everyone ship without oversight.

Chapters

Start	Chapter	Summary
00:00	The risks of handing off an AI-built app	The video introduces a CRM scenario and the questions about refund permissions and accountability that arise when other people use an app.
01:03	Building the CRM around a refund workflow	The demo defines the support and manager roles, describes the data and process the CRM needs, and follows an agent’s request and a manager’s simulated approval.
04:12	Permissions and security checks	The video distinguishes app access from refund approval rules, explains why authorization must be enforced by the operation, and reviews issues found by automated scans.
06:18	Audit history, deployment, and enterprise oversight	The video separates business records from platform audit logs, describes the stated Cloud Prem deployment, and concludes with IT’s role in overseeing AI-built apps.

Quotes

Support can request a refund, and a manager makes the decision. — 02:05

Hiding an approve button is useful for the interface, but it isn’t the whole permission check. — 04:43

A clean-looking screen doesn’t tell you any of that. The scan does. — 05:47

You want both. — 06:49

The support team builds the app and IT still controls who uses it, what ships, and where it runs. — 08:24

Concepts and entities

Superblocks, Clark, Lovable, Amazon Bedrock, AWS, Wes Roth, customer relationship management system, SSO, cloud prem, audit logs, enterprise vibe coding

Full transcript (original language)

00:00 So, you build an app with AI. It looks good. You can search customers, open up a support ticket, and click a button to issue a refund. It works great. But, then you give it to someone else in the company. Can they issue every refund? Can they just approve their own request? And if somebody asks why $249 was refunded, where do you get that answer? Those questions are easy to miss when you are the person that built the app

00:31 and you are the only person using it. So, today we’re going to build a customer support CRM. That’s a customer relationship management system, an app that keeps all the customer details and the various support requests in one place. So, we’ll build that CRM and follow one refund through that entire process. The interesting thing that happens is when different people need different permissions. Thank you to Superblocks for sponsoring this video. Here’s what’s happening at a lot of companies right now. There’s 20 people

01:03 in one department that are building apps with AI tools, and IT has no idea that those apps exist. Superblocks is built for that. Anyone can build with AI, and IT can still see and control every single app that ships. Tools like Lovable are great at getting you that first version fast. The trouble starts when that app needs to run somewhere your company controls. With your logins and with your security team watching.

01:33 Here’s our example. Imagine a support team at a large retailer. A customer says their headphones arrived damaged. The support agent needs the order, the ticket, and the customer’s history all in one place. The manager needs enough information to decide whether or not to approve the refund. And IT needs to know who can open the app, who can change it, and what activity gets recorded. We’re going to be using a fictional customers and refunds through this demo, and the rule we’re choosing is simple. Support

02:05 can request a refund, and a manager makes the decision. That’s our example business rule. I’m going to start by describing the process, because just seeing a customer table by itself doesn’t tell the AI how this team works. We need customers, tickets, orders, refund requests, and a history of what happened. We also need two different jobs inside the app. The person requesting the refund and the person reviewing it. Superblocks calls its AI assistant Clark. I’ll start in plan

02:38 mode, look at what it proposes, and then move into the build. Clark also pulls from our company’s knowledge base. Our design system lives there, so this CRM will look like every other internal app we have. Watch the questions that I’m trying to answer here. What information does each person need? And what should happen when they take an action? And notice Clark set up a post aggressive database as it built out the CRM. I didn’t file a ticket with anyone. Let’s follow the support agent’s side first.

03:09 Our customer is Avery Morgan, and the order is for $249. The ticket says that the headphones arrived damaged. The agent needs to understand the problem, add a note, and send a refund request with a reason. They shouldn’t have to hunt through three different screens just to understand what happened. Inside the app, I’ll switch between the agent’s view and the manager’s view, so you can see both sides of this refund. In a real rollout, of course, nobody picks their role. Every Superblocks app comes with

03:41 SSO login by default, so the app already knows who you are and which group you’re in. I’ll come back to why that matters. Now, let’s look at the manager’s job. It’s the same customer and the same request, but the manager needs a different set of actions. They need to review the reason, check the amount against the order, and record a decision. For example, we’re going to approve this simulated refund because the item arrived damaged. I want the result to stay connected to the original ticket. If another agent picks this up,

04:12 they should be able to understand what happened without having to ask everyone in a chat. Now, here’s the part I would care about before handing this to a real support team. We’ve walked through the interface. We still need to establish who is allowed to do each action. There are two levels to that. First, who can open the app and also who can edit or deploy it. That’s set with org and app permissions in Superblocks. Second, who can approve this particular refund? That’s a business rule that we build

04:43 into the app. It has to check who’s actually signed in. Hiding an approve button is useful for the interface, but it isn’t the whole permission check. The operation that actually changes the refund status needs to enforce that rule, too. The app needs to verify that you’re actually a manager before allowing you to approve the refund. And this is where I want the IT department involved. Set up the access properly, review all of the sensitive actions, and test the apps with the kinds of accounts

05:14 that people will actually be using. And there’s another question before release. What did the generated code actually do? Superblocks runs security checks automatically at build, at publish, and again in production. I didn’t have to ask an engineer to review anything. Let’s hit publish and see what it finds. The scan found two issues in the refund request. It was trusting identity information from the browser, and it wasn’t checking the refund amount against the original order total. I

05:47 clicked fix all and ran the checks again. The follow-up security agent report has one low severity advisory remaining. Our simulated approval flow still runs in the browser. For a real rollout, that decision needs server-side authorization too. For our CRM, the question is simple. Does the app check who’s allowed to approve the refunds and compare the amount with the original order? A clean-looking screen doesn’t tell you any of that. The scan does. I also want to separate two kinds of

06:18 history. Inside our CRM, we want the business record, the request, the amount, the reason, and the decision. At the platform level, IT gets two things. Audit logs record every change to the app, and in the security center, an admin sees every app in the company, who built it, and what vulnerabilities it has. It’s air traffic control for internal apps. Those answer a different set of questions about how this platform is being used and changed. Your app

06:49 keeps the business record. The platform keeps record of who built it, who shipped it, who changed it. You want both. The final question is where does all of this run? That matters once the records belong to real customers, and the prompts include actual company information. With cloud prem, Superblocks runs inside your company’s AWS account. Not connected to it, running in it. The app, the data, and

07:21 the inference through Amazon Bedrock all stay in your environment. This means that you own what you build. So, the conversation includes both the application and the AI process processing behind it. For an IT team evaluating this, those are practical questions. Which deployment are we using? Which systems will it connect to? And who controls the access? The refund request is a small example, but it’s a useful way to think about enterprise vibe coding. The support team knows the

07:53 workflow. AI can help turn that process into an application. Then, the people responsible for running it need a visibility into access, sensitive actions, review, and deployment. This is what I would look for before a useful demo becomes an application that entire departments rely on. Right now, most IT teams have two options with a vibe coding. Block it or just let everyone ship whatever they want and just hope.

08:24 Superblocks is the third option. The support team builds the app and IT still controls who uses it, what ships, and where it runs. If you are evaluating AI app building for your company, check out Superblocks using the link in the description and pinned comment. You can book a demo and bring a workflow like this one along with your data and permission requirements. Thank you so much to Superblocks for sponsoring this video and thank you for watching. My

08:55 name is Wes Roth. I will see you in the next