Vibe coding 2.0 chegou...

Vídeo de autoria do canal indicado, não da IANIA; todos os direitos pertencem ao criador. Transcrição, resumo e tradução gerados automaticamente; o conteúdo no idioma original é preservado na versão em idioma original.

Idioma original: inglês

Vídeo original: Vibe Coding 2.0 is here… · Canal: Wes Roth · 08:55 · Assistir no YouTube

Tópicos: Agentes de IA, Aplicações empresariais de IA, Cibersegurança e segurança de software, Engenharia de software com IA, Governança e regulação de IA

Resumo

Wes Roth demonstra a criação de um CRM de suporte ao cliente com IA, usando um fluxo de solicitação e aprovação de reembolsos para mostrar como diferentes pessoas precisam de permissões distintas. O vídeo destaca que a interface, por si só, não basta: as regras de autorização também precisam ser aplicadas às ações que alteram dados. A demonstração aborda verificações de segurança, logs de auditoria e controles de TI para supervisionar os aplicativos criados. Por fim, apresenta as opções de implantação do Superblocks, incluindo a execução no ambiente AWS da empresa.

Pontos-chave

O CRM reúne dados de clientes, pedidos, tickets, solicitações de reembolso e o histórico das decisões.
No fluxo demonstrado, agentes de suporte podem solicitar reembolsos, enquanto gerentes decidem se os aprovam.
Ocultar um botão de aprovação não é suficiente: a operação precisa verificar a identidade e as permissões de quem está conectado.
As verificações de segurança identificaram confiança em dados de identidade do navegador e falta de comparação com o valor original do pedido.
O fluxo de aprovação demonstrado ainda é executado no navegador; uma implantação real também precisaria de autorização no servidor.
O histórico de negócio do CRM e os logs de auditoria da plataforma respondem a perguntas diferentes e são ambos necessários.
O Superblocks oferece controles para que a TI acompanhe os aplicativos, seus criadores, alterações e vulnerabilidades.
Na opção cloud prem, o aplicativo, os dados e a inference pelo Amazon Bedrock ficam no ambiente AWS da empresa.

Capítulos

Início	Capítulo	Resumo
00:00	O desafio de transformar um app em ferramenta corporativa	A demonstração apresenta um CRM de suporte e o fluxo de reembolso, destacando a necessidade de permissões diferentes para agentes, gerentes e TI.
01:33	Planejamento e criação do CRM	Clark ajuda a definir os dados e as funções do aplicativo antes de acompanhar a solicitação de reembolso do agente e a decisão do gerente.
04:12	Permissões e verificações de segurança	O vídeo diferencia permissões da plataforma de regras de negócio e mostra problemas identificados nas verificações do aplicativo.
06:18	Histórico, auditoria e implantação	A demonstração separa os registros de negócio dos logs da plataforma e explica onde os dados e a inference podem ser executados.
07:53	TI como parte do vibe coding corporativo	O encerramento apresenta o Superblocks como uma alternativa que permite à equipe criar o app enquanto a TI mantém controle sobre uso, publicação e ambiente.

Citações

Se alguém perguntar por que foram reembolsados US$ 249, onde você encontra essa resposta? — 00:00

Esconder um botão de aprovação ajuda na interface, mas não é toda a verificação de permissões. — 04:43

O app mantém o registro de negócio. A plataforma registra quem o criou, publicou e alterou. — 06:49

A equipe de suporte cria o app e a TI ainda controla quem o usa, o que é publicado e onde ele é executado. — 07:53

Conceitos e entidades

Superblocks (empresa): Plataforma apresentada no vídeo para criar aplicativos com IA e permitir que a TI controle acesso, segurança e implantação.
Clark (ferramenta): Assistente de IA do Superblocks usado para planejar e construir o CRM da demonstração.
Lovable (ferramenta): Ferramenta citada como opção para criar rapidamente uma primeira versão de um aplicativo.
Amazon Bedrock (ferramenta): Serviço usado para a inference na opção de implantação do Superblocks dentro do ambiente AWS da empresa.
AWS (empresa): Ambiente de nuvem da empresa no qual o Superblocks pode executar o aplicativo, os dados e a inference.
Wes Roth (pessoa): Apresentador do vídeo, que demonstra o CRM e discute os controles necessários para aplicativos corporativos criados com IA.
customer relationship management system (conceito): Sistema que reúne informações de clientes e solicitações de suporte em um só lugar.
SSO (conceito): Mecanismo de login que permite ao aplicativo identificar a pessoa conectada e o grupo ao qual pertence.
cloud prem (conceito): Opção descrita no vídeo em que o Superblocks é executado dentro da conta AWS da empresa.
audit logs (conceito): Registros da plataforma que documentam alterações feitas nos aplicativos.
enterprise vibe coding (conceito): Uso de IA para transformar fluxos de trabalho em aplicativos, com supervisão de TI sobre acesso, ações sensíveis e implantação.

Tradução completa (pt-BR)

00:00 Então, você cria um aplicativo com IA. Ele parece bom. Dá para pesquisar clientes, abrir um chamado de suporte e clicar em um botão para emitir um reembolso. Funciona muito bem. Mas aí você entrega o aplicativo para outra pessoa da empresa. Essa pessoa pode emitir qualquer reembolso? Pode simplesmente aprovar a própria solicitação? E, se alguém perguntar por que foram reembolsados US$ 249, onde você encontra essa resposta? É fácil deixar essas perguntas passarem despercebidas quando você é a pessoa que criou o aplicativo

00:31 e a única pessoa que o utiliza. Então, hoje vamos criar um CRM de suporte ao cliente. Isso é um sistema de gerenciamento de relacionamento com o cliente, um aplicativo que reúne em um só lugar todos os detalhes dos clientes e as várias solicitações de suporte. Vamos criar esse CRM e acompanhar um reembolso ao longo de todo o processo. O interessante é o que acontece quando pessoas diferentes precisam de permissões diferentes. Obrigado à Superblocks por patrocinar este vídeo. Veja o que está acontecendo agora em muitas empresas. Há 20 pessoas

01:03 em um departamento criando aplicativos com ferramentas de IA, e a equipe de TI nem sabe que esses aplicativos existem. A Superblocks foi criada para isso. Qualquer pessoa pode criar com IA, e a equipe de TI ainda pode ver e controlar cada aplicativo que é lançado. Ferramentas como Lovable são ótimas para criar rapidamente uma primeira versão. O problema começa quando esse aplicativo precisa ser executado em um ambiente controlado pela sua empresa. Com os seus logins e sob a supervisão da sua equipe de segurança.

01:33 Este é o nosso exemplo. Imagine uma equipe de suporte em uma grande rede varejista. Um cliente diz que os fones de ouvido chegaram danificados. O agente de suporte precisa ter o pedido, o chamado e o histórico do cliente em um só lugar. O gerente precisa de informações suficientes para decidir se aprova ou não o reembolso. E a equipe de TI precisa saber quem pode abrir o aplicativo, quem pode alterá-lo e quais atividades são registradas. Vamos usar clientes e reembolsos fictícios nesta demonstração, e a regra que vamos escolher é simples. O suporte

02:05 pode solicitar um reembolso, e um gerente toma a decisão. Essa é a regra de negócio do nosso exemplo. Vou começar descrevendo o processo, porque ver apenas uma tabela de clientes não explica à IA como essa equipe trabalha. Precisamos de clientes, chamados, pedidos, solicitações de reembolso e um histórico do que aconteceu. Também precisamos de duas funções diferentes dentro do aplicativo: a pessoa que solicita o reembolso e a pessoa que o analisa. A Superblocks chama seu assistente de IA de Clark. Vou começar no modo de planejamento

02:38 , analisar o que ele propõe e depois passar para a criação. Clark também consulta a base de conhecimento da nossa empresa. Nosso sistema de design está lá, então este CRM vai ter a mesma aparência que todos os outros aplicativos internos que temos. Veja quais perguntas estou tentando responder aqui. De quais informações cada pessoa precisa? E o que deve acontecer quando ela realiza uma ação? E observe que Clark configurou um banco de dados PostgreSQL ao criar o CRM. Não precisei abrir um chamado para ninguém. Vamos acompanhar primeiro o lado do agente de suporte.

03:09 Nossa cliente é Avery Morgan, e o pedido é de US$ 249. O chamado informa que os fones de ouvido chegaram danificados. O agente precisa entender o problema, adicionar uma observação e enviar uma solicitação de reembolso com um motivo. Ele não deveria ter que procurar em três telas diferentes só para entender o que aconteceu. Dentro do aplicativo, vou alternar entre a visualização do agente e a do gerente, para que você veja os dois lados desse reembolso. Em uma implementação real, é claro, ninguém escolhe a própria função. Todos os aplicativos da Superblocks vêm com

03:41 login SSO por padrão, então o aplicativo já sabe quem você é e a qual grupo pertence. Já volto ao motivo de isso ser importante. Agora, vamos ver o trabalho do gerente. É o mesmo cliente e a mesma solicitação, mas o gerente precisa de um conjunto diferente de ações. Ele precisa analisar o motivo, conferir o valor em relação ao pedido e registrar uma decisão. Por exemplo, vamos aprovar este reembolso simulado porque o produto chegou danificado. Quero que o resultado continue vinculado ao chamado original. Se outro agente assumir o caso,

04:12 ele deve conseguir entender o que aconteceu sem precisar perguntar a todo mundo em um chat. Agora, esta é a parte que eu consideraria antes de entregar o aplicativo a uma equipe de suporte de verdade. Percorremos a interface. Ainda precisamos definir quem tem permissão para realizar cada ação. Há dois níveis nisso. Primeiro, quem pode abrir o aplicativo e também quem pode editá-lo ou fazer o deploy. Isso é definido com as permissões da organização e do aplicativo na Superblocks. Segundo, quem pode aprovar este reembolso específico? Essa é uma regra de negócio que criamos

04:43 dentro do aplicativo. Ele precisa verificar quem realmente está conectado. Ocultar um botão de aprovação é útil para a interface, mas não basta para verificar as permissões. A operação que realmente altera o status do reembolso também precisa aplicar essa regra. O aplicativo precisa verificar se você é mesmo um gerente antes de permitir que aprove o reembolso. E é aqui que quero envolver o departamento de TI. Configure corretamente o acesso, revise todas as ações sensíveis e teste os aplicativos com os tipos de conta

05:14 que as pessoas realmente vão usar. E há outra pergunta antes do lançamento. O que o código gerado realmente fez? A Superblocks executa verificações de segurança automaticamente durante a criação, a publicação e novamente em produção. Não precisei pedir a um engenheiro que revisasse nada. Vamos clicar em publicar e ver o que a verificação encontra. A análise encontrou dois problemas na solicitação de reembolso. Ela confiava nas informações de identidade recebidas do navegador e não comparava o valor do reembolso com o total do pedido original. Eu

05:47 cliquei em corrigir tudo e executei as verificações novamente. O relatório de acompanhamento do agent de segurança ainda aponta um aviso de baixa gravidade. Nosso fluxo de aprovação simulado ainda é executado no navegador. Para uma implementação real, essa decisão também precisa de autorização no servidor. No nosso CRM, a pergunta é simples: o aplicativo verifica quem tem permissão para aprovar os reembolsos e compara o valor com o pedido original? Uma tela com aparência impecável não revela nada disso. A análise, sim. Também quero separar dois tipos de

06:18 histórico. Dentro do nosso CRM, queremos o registro comercial: a solicitação, o valor, o motivo e a decisão. No nível da plataforma, a equipe de TI recebe duas coisas. Os logs de auditoria registram cada alteração no aplicativo e, no centro de segurança, um administrador vê todos os aplicativos da empresa, quem os criou e quais vulnerabilidades eles têm. É o controle de tráfego aéreo dos aplicativos internos. Esses recursos respondem a outro conjunto de perguntas sobre como a plataforma está sendo usada e alterada. Seu aplicativo

06:49 mantém o registro comercial. A plataforma registra quem o criou, quem o lançou e quem o alterou. Você precisa dos dois. A pergunta final é: onde tudo isso é executado? Isso importa quando os registros pertencem a clientes reais e os prompts incluem informações reais da empresa. Com o Cloud Prem, a Superblocks é executada dentro da conta AWS da sua empresa. Não conectada a ela, mas dentro dela. O aplicativo, os dados e

07:21 a inference por meio do Amazon Bedrock permanecem no seu ambiente. Isso significa que você é dono do que cria. Portanto, a conversa inclui tanto o aplicativo quanto o processamento de IA por trás dele. Para uma equipe de TI que esteja avaliando isso, essas são perguntas práticas. Qual implantação vamos usar? A quais sistemas ela vai se conectar? E quem controla o acesso? A solicitação de reembolso é um exemplo pequeno, mas é uma maneira útil de pensar em vibe coding empresarial. A equipe de suporte conhece o

07:53 workflow. A IA pode ajudar a transformar esse processo em um aplicativo. Depois, as pessoas responsáveis por operá-lo precisam ter visibilidade sobre o acesso, as ações sensíveis, a revisão e o deploy. É isso que eu procuraria antes que uma demonstração útil se torne um aplicativo do qual departamentos inteiros dependam. Neste momento, a maioria das equipes de TI tem duas opções com vibe coding: bloquear ou simplesmente deixar todo mundo lançar o que quiser e torcer para dar certo.

08:24 A Superblocks é a terceira opção. A equipe de suporte cria o aplicativo, e a equipe de TI continua controlando quem o usa, o que é lançado e onde ele é executado. Se você está avaliando a criação de aplicativos com IA para a sua empresa, confira a Superblocks pelo link na descrição e no comentário fixado. Você pode agendar uma demonstração e trazer um workflow como este, junto com seus dados e requisitos de permissões. Muito obrigado à Superblocks por patrocinar este vídeo e obrigado a você por assistir. Meu

08:55 nome é Wes Roth. Vejo você no próximo vídeo

Transcrição original

[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