🎯 Por que assistir — o ROI
Assista a isto se você precisa de um mapa estratégico claro para mitigar os riscos técnicos ocultos e evitar o colapso de projetos de tecnologia baseados em IA, garantindo a transição segura do ambiente local para produção com escalabilidade sob carga real de negócios. Este vídeo é o guia pragmático para líderes que lutam com a lacuna crítica entre a agilidade da prototipagem com IA e a complexidade real da sustentação em produção.
🌳 Ideia Central — a tese
A inteligência artificial, embora acelere radicalmente a geração de código, atua apenas como um executor operacional (“sargento”). O sucesso sustentável de uma aplicação em produção exige a liderança de um arquiteto humano (“general”) para gerenciar a complexidade submersa do “iceberg” da engenharia de software — incluindo resiliência, segurança, banco de dados escalável e infraestrutura —, sob risco de colapso catastrófico em cenários reais de uso.
⏳ Principais Momentos — a evidência
Princípio da Idempotência
Imagina que você quer deletar um usuário do banco. É, se você é deletar ele uma vez, você pode ficar lá deletando ele 50 vezes, o usuário já não existe mais. Então todas as outras chamadas, elas foram inúteis, vão dar erro
A idempotência é essencial para evitar o desperdício de recursos computacionais e inconsistências de dados. No design de APIs, garantir que uma operação possa ser repetida sem efeitos colaterais indesejados protege o sistema contra instabilidades causadas por reenvios de pacotes ou redes instáveis.
Mecanismo de Deduplicação
É o duplication aqui é detectar e ignorar requestes duplicados.
A deduplicação atua na camada de segurança e eficiência, identificando e descartando requisições idênticas enviadas em curto espaço de tempo. Em sistemas transacionais, a ausência de deduplicação pode resultar em cobranças duplicadas ou inserções repetidas que degradam a experiência do cliente e causam prejuízos operacionais imediatos.
Estratégia de Caching
conceito de cashing, né, que é guardar o resultado caro para reusar depois.
O cache é uma das ferramentas mais potentes para otimização de performance e controle de custos de infraestrutura. Ao salvar em memória temporária resultados de operações complexas, reduz-se drasticamente o gargalo nos bancos de dados relacionais e o custo de requisições de APIs pesadas.
Limitação de Taxa
Rate limit, limitar as requests por período de tempo.
O rate limit é uma barreira de defesa crucial contra abusos, raspagem de dados não autorizada e ataques de negação de serviço (DoS). Estabelecer limites de requisição por usuário ou IP preserva a integridade física dos servidores de aplicação, garantindo disponibilidade justa a todos os clientes.
Operações Atômicas
Atomic Operation. É ou tudo acontece ou nada acontece
Operações atômicas asseguram a consistência transacional do sistema através do conceito ACID, onde uma falha parcial resulta no rollback completo do estado. Em fluxos críticos como pagamentos ou movimentação de estoques, a atomicidade impede que falhas de rede deixem o sistema em estados híbridos e corrompidos.
Retry com Backoff
Então, ó, imagina que você tem um porteiro, o porteiro não atendeu, então você espera 1 segundo e aí você bate lá na porta do porteiro de novo. Ele não te atendeu, você espera dois, você espera quatro, você espera os outros. Sem backoff, você faz um DDOS na sua própria API.
Tentar novamente uma conexão falha sem um intervalo exponencial de espera (backoff) cria um comportamento de autodestruição, onde os próprios clientes derrubam o backend com um ataque DDoS involuntário. A resiliência requer inteligência na repetição, espaçando as tentativas para dar tempo de recuperação ao servidor.
Condições de Corrida
O que que é raise condition? É, dois processos disputando o mesmo recurso. Então, imagine ali que você tem uma aplicação ali que, cara, tem um ingresso e, cara, quem apertar primeiro aquele botão ali vai levar o ingresso. Tem o último, é o estoque ali, só tem esse ingresso.
As condições de corrida (race conditions) ocorrem quando a lógica de negócios falha ao gerenciar acessos concorrentes ao mesmo registro. Sem travas de exclusão mútua (locks) ou controle de transação no banco de dados, múltiplos clientes podem arrematar o mesmo recurso físico, criando crises severas de suporte e perdas financeiras.
Paginação de Dados
paginação. É você trazer os dados em pedaços e não trazer tudo
A paginação atua dividindo os payloads em blocos gerenciáveis, permitindo consultas rápidas e melhorando a percepção de performance da interface do usuário.
Validação e Sanitização
Validação e sanitização. Nunca confiar no input do usuário. Então, por exemplo, campo de idade recebendo um SQL injection. Então, você precisa validar tipo, tamanho, formato, sanitizar o HTML para evitar o XS
A premissa básica de segurança é nunca confiar nos inputs fornecidos pelos clientes. A validação de tipos de dados e a sanitização de payloads previnem ataques severos de injeção de código (SQL Injection, XSS) que podem expor dados confidenciais ou dar controle total do servidor a terceiros.
Observabilidade e Telemetria
uma última camada aqui muito importante que é a observabilidade, logs, métricas, traces para ver o que rola.
A observabilidade fornece visibilidade em tempo real sobre o comportamento interno do sistema. Sem logs estruturados, métricas de performance e rastreamento de requisições (traces), equipes de engenharia operam às cegas, sendo incapazes de diagnosticar gargalos ou falhas em microsserviços.
Testes de Carga
você tem que fazer teste de cargas no seu sistema. Que que é teste de carga, cara? Vou numa aplicação dessa aqui que é do Smith, é que é um SAS de agentes de A, o que que mais consome aqui? é os agentes buscando uma base reg, só que são vários agentes para vários clientes. Então o que que eu tenho que testar de carga aqui, que é o principal, é eu fazer 100 requisições no mesmo segundo.
Testes de carga simulam acessos simultâneos sob estresse para expor pontos de falha arquiteturais ocultos antes que atinjam o cliente final. Essa prática ajuda a prever o comportamento de gargalos críticos, como consultas simultâneas a bases RAG ou buscas pesadas de vetores em soluções de IA.
Auditoria de Segurança
auditoria de segurança. A IA, ela por padrão, ela quer te entregar o código mais rápido possível, eh, de um jeito que funciona.
Como a inteligência artificial visa à produtividade imediata, ela frequentemente gera códigos que contêm vulnerabilidades graves de segurança ou caminhos não autenticados. Auditorias de segurança periódicas de código são obrigatórias para identificar falhas introduzidas pela pressa da IA no desenvolvimento.
Banco de Produção
Banco de dados escalável. Primeira coisa que não tem nada a ver com com a parte de banco de dados escalável é se você conecta o seu agente de A diretamente no seu banco de dados de produção, você já tem a chave do fracasso prontinho para algum momento. Isso dá uma merda muito grande
Conectar agentes de inteligência artificial autônomos diretamente em bancos de dados de produção é um erro estratégico gravíssimo. Os agentes de IA podem, sob alucinação ou manipulação de prompts (prompt injection), executar exclusões massivas ou expor dados restritos, exigindo sempre camadas intermediárias de APIs controladas.
Estratégia de Migrações
Só que veja que quando você tá criando essa coluna e em produção, dependendo da hora que você tá criando, o seu sistema tiver com muita escrita, muitos pulings aqui conectados no seu banco de dados, enquanto está criando aquela coluna numa tabela gigantesca, o seu sistema ele trava por alguns segundos, minutos, e aí tudo para no seu sistema. Então você tem que ter uma estratégia até para executar essas migrations aqui.
Alterações de esquemas em bancos de dados volumosos podem bloquear tabelas inteiras, causando interrupções severas nos serviços corporativos. Estratégias de migrações online sem travamento, executadas em horários de baixo tráfego, garantem a evolução contínua da aplicação com risco zero para a operação comercial.
Revisões de Arquitetura
review de arquitetura, a mesma coisa. Você precisa de tempos em tempos dar um tapa na arquitetura.
A arquitetura de software tende a acumular débitos técnicos à medida que novas features são implementadas às pressas. Revisões regulares de arquitetura permitem simplificar o código, quebrar arquivos inchados e remodelar a estrutura para suportar com eficiência novos marcos de escala do negócio.
Monitoramento Contínuo
Monitoramento de infraestrutura. Você também tem que tá sempre ligado, mesmo que o seu sistema ele tá pequeno, mas quando você tá sempre observando ali, você já sabe, pô, hoje eu tô com 50 clientes aqui. A infra aqui tá, cara, o gráficozinho tá começando a ficar chegar no limite.
O monitoramento proativo de infraestrutura permite que gestores identifiquem tendências de consumo de memória e CPU antes que o sistema entre em colapso. Antecipar a necessidade de escalabilidade vertical ou horizontal evita perdas financeiras decorrentes de indisponibilidade em momentos críticos de tráfego.
💡 Conclusões — e daí?
- A Ilusão do Vibe Coding: A velocidade com que a inteligência artificial gera protótipos funcionais cria uma falsa percepção de prontidão comercial. Soluções que rodam em ambiente de desenvolvimento local cobrem apenas a superfície visível do software, mascarando problemas complexos de infraestrutura que causam interrupções críticas no primeiro pico de acessos em produção.
- Subordinação Estratégica da IA: As ferramentas generativas atuam como executores de alta performance (“sargentos”), mas são incapazes de planejar a longo prazo ou avaliar riscos sistêmicos. A liderança estratégica da arquitetura (“general”) deve ser desempenhada por engenheiros humanos experientes para evitar a introdução de falhas de segurança invisíveis.
- Fundação Essencial de Engenharia: Mecanismos como idempotência, deduplicação de chamadas, caches inteligentes, rate limiting e operações atômicas são prerrogativas obrigatórias para qualquer sistema comercial escalável. Negligenciar esses pilares em favor de entregas rápidas corrompe a confiabilidade das transações de negócios.
- Validação Proativa e Observabilidade: A resiliência de um produto digital depende de testes de carga contínuos e auditorias de segurança antes do go-live, combinados com ferramentas de observabilidade em produção. Antecipar-se aos erros por meio do rastreamento de anomalias com monitoramento contínuo protege a reputação do negócio e reduz custos operacionais de emergência.
🏢 Casos de Uso — onde aplicar
Em ambientes corporativos, a aplicação prática deste framework ocorre na governança de lançamentos de produtos digitais (Go-to-Production Checklist). Antes de aprovar o deploy de um novo microsserviço ou plataforma em produção, o CTO ou Diretor de Engenharia de uma empresa de tecnologia deve aplicar uma matriz de risco baseada no ‘iceberg’:
- Mitigação de Riscos de Agentes de IA: Auditar se algum fluxo automatizado possui privilégios diretos de escrita ou alteração no banco de dados de produção.
- Validação sob Estresse: Exigir relatórios de testes de carga que comprovem a capacidade de resposta sob concorrência intensa, avaliando o comportamento de caches e travas de transações (locks) para evitar condições de corrida (race conditions).
- Políticas de Resiliência de Rede: Validar se as chamadas de APIs externas utilizam mecanismos robustos de retry com backoff exponencial para prevenir quedas por sobrecarga interna.
🚧 Limitações — onde não aplicar
A rigidez arquitetural e o rigor de infraestrutura descritos não devem ser aplicados integralmente em MVPs (Minimum Viable Products) ou protótipos de validação inicial. Em startups em estágio de pré-seed ou validação de hipótese de produto (Product-Market Fit), o foco deve ser a velocidade de aprendizado e o feedback do cliente. Exigir redundância extrema, Kubernetes com auto-scaling e testes de carga massivos antes mesmo de ter usuários ativos gera um risco severo de over-engineering e esgotamento precoce de capital de giro (cash burn). A premissa de alta segurança e resiliência total assume que a aplicação já opera sob volume de transações comercialmente relevante, o que não reflete a realidade de ideias em fase de testes rápidos.
🏃 Na Prática — como agir
Regras de decisão:
- Se o código foi gerado majoritariamente por IA, então exija revisão arquitetural humana de resiliência e segurança antes de produção — a IA é “sargento” (executor), nunca “general” (arquiteto).
- Se o produto vai operar sob volume comercial real, então trate idempotência, rate limiting, cache e operações atômicas como pré-requisitos de deploy, não como melhorias opcionais.
- Se algum agente ou fluxo de IA tem privilégio direto de escrita no banco de produção, então revogue e force toda escrita por uma camada de aplicação com validação.
- Se uma chamada externa pode ser reenviada (rede instável, retries), então garanta idempotência + retry com backoff exponencial antes do go-live.
- Se você ainda está validando Product-Market Fit (MVP/pré-seed), então NÃO aplique rigor máximo de infraestrutura — priorize velocidade de aprendizado e evite over-engineering.
Trade-off — rigor de engenharia vs. velocidade:
| Contexto | O que priorizar |
|---|---|
| Pré-PMF, MVP, protótipo | Velocidade de aprendizado; infraestrutura mínima viável |
| Volume comercial / picos de acesso | Rigor: idempotência, rate limiting, testes de carga |
Checklist de Go-to-Production (rodar com o time antes de cada release):
- Mapear endpoints expostos e aplicar limite de requisições para proteger as APIs.
- Revisar chamadas externas para garantir idempotência e aplicar cache em consultas custosas.
- Executar testes de carga com o dobro da concorrência máxima esperada e observar o banco de dados sob estresse.
- Configurar rastreamento de erros em tempo real (ex: Sentry) e monitoramento de latência antes que falhas afetem o usuário.
📜 Transcrição
Introduction to the danger of Vibe Coders in Production
0:00 · Você entra no Cloud Code, no Codex, no Cursor e gera código com IA. E você consegue fazer isso rodar localmente, fica bonito, você corrige os bugs e até usa uma metodologia legal, spec driven, TDD e etc. Tudo parece funcionar muito bem, mas o problema é o que vem depois disso. Você tá olhando apenas a ponta do iceberg, o que está embaixo do iceberg, tem um monstro que vai engolir o seu projeto se você não tratar isso de forma correta.
0:27 · No momento que você manda o seu projeto pra produção e tem um acesso ali de 100 usuários simultâneos, a sua aplicação já cai. Se entrar muitos dados, o seu banco de dados explode e a sua aplicação fica super lenta. O cliente reclama que a aplicação tá quebrada e muitas vezes você vai precisar do cloud ou do Gemini para poder resolver um problema que muitas vezes não tem solução.
0:49 · E mesmo que se tivesse solução, você vai ter que confiar no seu agente para poder resolver esse problema e fazer um deploy enquanto seus clientes estão utilizando a sua solução. É como você querer consertar um avião voando e muitas vezes, si for uma falha de arquitetura ou de infraestrutura, você vai perder a sua aplicação e todos os seus clientes.
1:12 · Em uma analogia clara, a IA ela é apenas o sargento. Ela executa rápido e identifica oportunidades, mas quem decide a direção é o general. E o general só pode ser você. E se você não sabe o tamanho do iceberg que está por baixo da água, você não pode ser o general. É o mesmo que o general executar uma ordem para o sargento que nem ele mesmo sabe como resolver. E o que eu vou te mostrar hoje é uma fração desse iceberg, que é te mostrar o que fica ali por baixo dos panos quando você sobre uma aplicação pra produção.
1:41 · Tudo que está debaixo da linha da água que 90% dos vibe coders nem sabe que existe e quando souberem já vai ser tarde demais. Meu nome é Breno. Eu sou fundador da LOL, comunidade de inteligência artificial. Sou diretor de uma empresa de tecnologia e hoje tô aqui para passar o conhecimento para vocês.
2:00 · Então já deixa aí o seu like no vídeo, segue o canal, é muito importante para que a gente continue o nosso trabalho. O link da comunidade tá disponível na descrição desse vídeo. Se você quiser aprender a construir aplicações reais que vão pra produção, venha compartilhar aí o seu conhecimento conosco e nós também vamos compartilhar com vocês, beleza? Então bora pro vídeo. Então preparei aquela aulinha aqui pra gente não perder o costume. Então hoje a gente vai falar aqui do o mínimo que você precisa saber.
The Iceberg of Vibe Coders and the Hidden Concepts from the Masses
2:25 · Obviamente eu não vou conseguir cobrir tudo em um único vídeo porque realmente é algo muito extenso e também depende da sua realidade, de que aplicação que você tá construindo aí.
2:36 · Entao hoje vamos dar uma olhada aqui só no iceberg aqui do Vibe Coding, né? O que que a galera enxerga hoje aqui é isso aqui, ó. Nós temos aqui o nosso querido aqui Codex. né? Nós temos aqui cloud, gemin pilot, cursor antigravity, as ferramentas aí super base que é amplamente utilizado até até eu gosto muito do super base aí N8N Versel Rayway, outras aí VPS. A galera acha que bom, isso aqui é exatamente o que eu preciso para eu rodar uma aplicação.
3:08 · Isso é um grande problema. Hoje eu vi um vídeo, cara, infelizmente, de um cara que eu sempre fui fã aí, não quero expor nomes, mas eu eu sempre gostei dele. Ele era da área ali, ele é ele é do marketing digital, mas ele era mais da área de motivação e família ali. E eu tenho certeza que ele ajudou muita gente. E hoje ele tá ali divulgando ali, cara, um curso, prometendo que você vai construir um aplicativo e e vai ganhar 180.000 por ano, tantas pessoas, 9.000 por mês e tá com o maior especialista de a da América Latina.
3:38 · E, cara, fiquei decepcionado porque realmente e esses caras eles não vão te falar o que eu vou te falar aqui agora. Eh, e eu fiquei decepcionado com ele porque realmente muitas pessoas ali, os gurus ali estão surfando a onda da IA e estão botando muita gente e na cilada, né? Não vão mostrar aqui a parte ruim, né? A parte de quando você vai colocar isso em produção. Então, o que que é o principal problema desses caras aqui? Esses caras aqui, eles te vendem um sonho.
4:03 · O que que é o sonho? É você escrever um prompt ali, você pode se organizar, fazer algo organizado e você começa a ver ali a aplicação rodando localmente. Você entra aqui, você vê, cara, pô, dashboard ficou legal, o sistema tá rodando aqui bonitinho, tá tudo beleza, mas quando você vai colocar isso em produção, você não faz ideia do que que o que que é colocar alguma aplicação em produção.
4:28 · Você não testou massivamente o seu sistema, você não trabalhou ali teste de carga, você não sabe o que que vai acontecer com seu banco de dados. E aí muita gente vem aqui, ó, e conecta esse carinha aqui, ó, direto no banco de dados de produção, achando que, cara, não, o cloud vai resolver tudo para mim.
4:46 · E aí a gente vê as notícias ali, é, de que os LLMs aí estão apagando o banco de dados e de aplicações em produção.
4:53 · Agora, o que que a gente vai ver aqui, ó, o que que não é a ponta do iceberg, né? Então assim, aqui é o que o Vibe Coder vê e aqui é o que ele ainda não sabe. Então aqui, ó, I vou falar os nomes aqui e vamos ver que se você sabe alguma dessas coisas. Cubernets, ESS, auto scaling, HPA, queda, Service, Mesh, ISU, Load Balancer, Ninx, CDN, Cloud Flare, DDOS Protection, Replication, Read, Replicas, Backup. E aí aqui abaixo aqui nós temos Rabbit, Gameq, web sockets, long pulling, event streaming.
5:25 · Aqui a gente já vem para Open Telemetry, Matrix, Prometeu, são ferramentas de tracking, Grafana, é Centry, GitHubs.
5:34 · Isso tudo aqui é obviamente a gente não usa isso aqui in todas as aplicações, mas nas categorias de cada um desses nomes que eu te falei aqui, muito provavelmente ou obrigatoriamente você vai ter que ter aqui na categoria aqui de monitoramento. Algum deles você vai ter que ter. Se você tem uma aplicação em produção, se você precisa de algo de processamento, muito provavelmente você vai precisar de algo como Rabbit MQ.
5:58 · Isso são tudo é decisões é de infraestrutura. É arquitetura você monta e você tem decisões de infraestrutura, que é o que você vai fazer pro seu sistema ficar em pé, né? Pro seu sistema funcionar. É muito fácil você fazer o teste eh aí dessas aplicações eh no seu ambiente de teste, você pede para um amigo seu testar e ele faz lá um login, mas você não fez um teste ali. Se 20 usuários tá fazendo uma query pesada no seu banco de dados, é se isso vai interferir ou não.
6:29 · O que que você precisa de infraestrutura para poder rodar o seu sistema numa VPS que te atenda? Às vezes você tem uma VPS ali, tem uma máquina ali de 4 GB de RAM e você acha que aquela ali é o suficiente ou você não preparou o seu sistema para isso e no momento que você conseguir fazer sucesso ou entrar algumas centenas de clientes de usuários, eh, você vai ter um problema e muitas vezes esse problema não vai ser resolvido com um prompt.
6:56 · E isso que eu tô falando, si tiver um desenvolvedor aqui que tá me escutando, isso não é um problema dos vibe coders. Hoje várias startups, por ter esse ritmo acelerado, elas começam dessa forma e cara vai aos trancos e barrancos ali. Mas que o calo aperta, eles realmente t desenvolvedores lá dentro, desenvolvedores sior, que vão conseguir fazer essa escalabilidade, vão conseguir fazer a refatoração do sistema de uma forma que ele vai escalar e vai aguentar a carga com segurança.
7:25 · Então, entenda que a diferença dessas startups pro Vibe Coder que tá ali fazendo o sisteminha dele em casa é que esses caras tm desenvolvedores de verdade. E aí eu não sou contra os vibe coders, não, pelo contrário, eu sou a favor. A Ia veio para democratizar isso. Mas se você tá focado somente nesses caras aqui e acha que isso aqui é o suficiente para você ficar rico, você pode tirar o seu cavalinho da chuva que isso não vai acontecer.
7:52 · Eu respeito os vibe coders que tão sabem disso aqui, mas que estão estudando tudo isso aqui, ó, que estão estudando como realmente eu vou colocar um sistema em produção, porque hoje desenvolver um sistema, uma telinha, algo bonito ali, pode até seguir ali várias metodologias que eu mesmo falo nesse canal, mas quando você vai colocar uma solução em produção, vários conceitos devem ser levados em consideração e você tem que estudar todos eles.
8:18 · Então esse cara aí, o aspirante a desenvolvedor que realmente tá estudando para poder colocar as suas aplicações no ar, esses caras vão prosperar. Todo o resto, você pode ficar tranquilo, esses caras nem vão ser seus concorrentes. Eles não vão conseguir colocar nada em produção que dure muito tempo. Eles vão chegar até um certo ponto e a partir desse certo ponto não passa mais. Pra gente continuar, eu separei aqui alguns conceitos simples de de engenharia.
8:43 · Cara, nem é nem são conceitos eh puts, cara. vai abrir minha mente aqui, mas é o é o mais básico do básico que um desenvolvedor júnior sabe disso aqui e vocês têm que saber. Eu não vou conseguir dar todos os conceitos aqui, depois eu faço um vídeo é um pouco mais avançado, caso vocês queiram aí, deixa nos comentários, mas primeiro eu vou no básico do básico, beleza? Começar aqui com indepotência. Você pode rodar um resultado n vezes, mas o mesmo resultado vai ser o da primeira vez.
The Concept of Idempotence
9:14 · Então vai ser o mesmo resultado. É a mesma coisa, sabe? Quando você tá apertando o botão do elevador ali, você aperta aquele botão 50 vezes, mas isso não vai fazer o elevador andar mais rápido você ficar apertando aquele botão ali. Imagina que você quer deletar um usuário do banco. É, se você é deletar ele uma vez, você pode ficar lá deletando ele 50 vezes, o usuário já não existe mais. Então todas as outras chamadas, elas foram inúteis, vão dar erro. Então você tem que trabalhar esse conceito aqui em todo o seu sistema.
9:42 · Muitas vezes o seu sistema, se você olhar bem perto, ele fica repetindo várias ações que só deveria ter sido feito uma vez. E todas essas ações elas não estão gerando nenhum outro resultado. Já gerou o resultado e mas o seu sistema continua rodando n vezes aquilo ali. Beleza? Então aqui o inepotência, o end point ele é construído n vezes, mas ele vai gerar sempre o mesmo estado. Beleza? Aqui o duplication é até complementar aqui ao idem potente. É o duplication aqui é detectar e ignorar requestes duplicados.
The Concept of Deduplication in Applications
10:15 · O que que significa isso? Você imagina que você tem um aplicativo e o usuário vai usar ele, ele aperta o botão uma vez e ele faz alguma chamada aí eh no seu banco de dados, no seu backend, enfim, que seja o que for. Eh, imagina se o usuário apertar aquele botão ali quatro vezes, o que que acontece? Ele vai gerar quatro quatro vezes a mesma chamada.
10:34 · como que seu sistema vai se comportar, porque geralmente quando você tá testando, você aperta o botão uma vez, ah, funcionou, beleza, legal. E aí depois, e se o usuário apertar 10 vezes?
10:44 · Tem casos aqui que, cara, si o usuário clicar aqui em três vezes ali na hora de pagar, às vezes o aplicativo tá lento, você aperta pagar, não aconteceu nada, aperta pagar de novo, aperta pagar e aí vai duplicando pagamentos ali. Isso eu te falo que acontece até em grandes empresas, eh, que estão começando ali, lançam um e-commerce, algo desse sentido. Isso aqui acontece facilmente.
11:06 · E aí quando você vê a conta lá do usuário foi paga três vezes porque ele apertou no botão ali seguidamente, você não tratou isso. Então sem deduplicação, cobra as três vezes com um indepotência ke aqui você processa só a primeira delas, as outras você ignora. Ou você pode tratar isso no front end também aperta o botão uma vez, o botão ele bloqueia até que a request e que foi feita no seu back end responda pro front end. Isso aqui acontece demais. Então, algum desses conceitos aqui, com certeza, eh, vai vir a calhar para você.
11:37 · O seu sistema deve estar fazendo isso.
11:39 · Depois aqui nós temos o conceito de cashing, né, que é guardar o resultado caro para reusar depois. O Google ele não varre a internet toda vez.
The Concept of Caching in Applications
11:48 · Quando você faz aquela busca ali, tem muita coisa que já tá in cash, por isso que ele te retorna com tanta rapidez ali as buscas, os sites, o que que você quer buscar. Então um prompt casing aqui do cloud, ele evita você reprocessar um system prompt gigante. Imagina que você tem um um agente que ele tá rodando ali com Antropic, um modelo do cloud, e ele tem um system prompt gigantesco.
12:06 · Quando você manda a primeira mensagem ali para conversar com seu agente, é a antrópica, ela guarda isso num cash para evitar de que o cloud tenha que reprocessar toda aquela informação ali que você mandou na próxima interação toda de novo. Isso ajuda ali no processamento pro seu sistema ficar bem mais rápido.
12:24 · Então você precisa usar o cashing aqui, principalmente quando você tá fazendo queres no banco de dados, algo que seja extremamente pesado, que vários usuários fazem a mesma querer, aperta no mesmo botão de buscar ali, você tem que fazer o cash para poder retornar o resultado ali mais rápido pro usuário, sem implicar em fazer diversas requisições dentro do seu banco de dados. Isso vai te salvar um dia, principalmente quando o seu banco de dados começar a escalar. Esse outro aqui é padrão, ó. Rate limit, limitar as requests por período de tempo.
The Concept of Rate Limit in Applications
12:54 · E aí tem gente que limita por IP também. Tem várias formas de você trabalhar o rate limit, mas basicamente é, você precisa ter rate limits nos seus end points pro usuário ou um atacante ficar ali burdoando ali batendo na sua PI é diversas requisições por minuto, por segundo, te pode ser até um ataque.
13:15 · Então se você não limitar essas requests e começar a bloquear essas requests, é com rate limit, o seu sistema ele fica frágil. Agora imagina que é, cara, se você tem uma portaria aqui, ó, você pode deixar no máximo 10 pessoas por minuto no elevador. É só isso. Tá limitado, acima de 10 pessoas aqui por minuto.
13:34 · Espera mais 1 minuto e aí 10 pessoas depois podem subir aqui no elevador.
13:38 · Então não tem como eu te falar aqui o que é certo ou errado, né? Qual que é o rate limite correto? Você tem que ter o rate limite e aí depende muito da sua aplicação. Mas o exemplo seria a PI aqui limita 100 requisições por minuto pro usuário. Se estourou, meu amigo, vai tomar um erro aqui 429. Você não vai acessar e não vai ali arrebentar o seu servidor. Beleza? Então vamos pro próximo aqui. É Atomic Operation. É ou tudo acontece ou nada acontece. Então exemplo clássico de banco, né?
The Concept of Atomic Operation in Applications
14:05 · TED bancária, debitou da sua conta e credita na do amigo. Mas imagina que debitou da sua conta e falhou lá. Não, o dinheiro não foi pra outra conta. O que acontece? Faz um rollback, volta o dinheiro pra sua conta. Não existe isso aqui de ficar dinheiro do limbo. Se você não tratar essas operações atômicas, é, vai acontecer isso, principalmente quando você está se comunicando com o sistema terceiro. É, API falha, galera.
14:33 · API dá problema, em algum momento vai dar problema. Não existe sistema que fica 100%, nem a meta WhatsApp, Google fica, tem um uptime de 100%, então por que que você acha que em algum momento a sua PI não vai falhar? Se você não trabalhar isso aqui, em algum momento vai executar uma ação no seu sistema que não vai executar do lado de lá e você vai ficar com isso aqui no limbo, beleza? Retry e backf, tentar de novo, mas esperando mais.
15:00 · Então, ó, imagina que você tem um porteiro, o porteiro não atendeu, então você espera 1 segundo e aí você bate lá na porta do porteiro de novo. Ele não te atendeu, você espera dois, você espera quatro, você espera os outros. Sem backoff, você faz um DDOS na sua própria API. Então, perceba que se você tem aqui um end point dentro da sua aplicação, eh, e você bateu nele ali, por algum motivo não funcionou, porque eu acabei de dar um exemplo que API em algum momento vai dar algum problema, eh, você não pode ficar batendo infinitamente nela ali até dar certo.
The Concept of Retry and Backoff in Applications
15:33 · Então, você espera um pouco, você bate de novo. Você espera mais um pouco, você bate de novo. E isso é uma decisão aqui é de infraestrutura e arquitetural que você vai ter que ter para poder ter um guard rail aqui dentro do seu sistema.
15:45 · Beleza? O próximo aqui é Race Condition.
15:48 · Esse aqui é muito legal, cara. Quando você roda uma auditoria de segurança em sistemas de que foram feitos ali e com Vibe Code, com essas IA, em 99% das vezes vai ter race condition. O que que é raise condition? É, dois processos disputando o mesmo recurso. Então, imagine ali que você tem uma aplicação ali que, cara, tem um ingresso e, cara, quem apertar primeiro aquele botão ali vai levar o ingresso. Tem o último, é o estoque ali, só tem esse ingresso.
The Concept of Race Conditions and Why You Have This Problem
16:15 · E aí o ingresso, duas pessoas clicam ao mesmo tempo e elas levam sem o lock aqui, ó, ambas vão levar aquele ingresso. É, e isso é o que a gente chama ali de race condition. Consequentemente, você precisa resolver isso com lock ou transaction. Isso acontece demais, tá? O mesmo recurso é se duas pessoas clicarem ao mesmo tempo, ainda mais se a sua aplicação tiver em produção, tiver escalando, se você não tratou em algum momento alguma regra de negócio que isso aqui pode acontecer, você vai sofrer isso e você vai ter que resolver esse problema. Beleza?
16:45 · E o próximo aqui, ó, é paginação. É você trazer os dados em pedaços e não trazer tudo. É muito simples. Veja que o Google, ele não mostra ali 10 milhões de resultados quando você pesquisa algo.
The Concept of Pagination in AI Applications
16:59 · Ele te mostra a primeira página, depois ele te mostra a segunda, a terceira, a quarta página. E aí, dependendo da query, da chamada que você tá fazendo ali no seu banco de dados, se ela for muito pesada, você tem que limitar os resultados que você tá exibindo e paginar isso, senão o seu sistema vai ficar muito lento, em algum momento ele não vai nem rodar. Temporariamente a paginação ela resolve um problema de escalabilidade. E talvez se você nem construiu uma arquitetura muito bem feita, isso aqui pode acontecer até com pouquíssimos dados se você não trabalhar esse sistema de paginação.
17:30 · Então se você não faz uma paginação ali numa listagem de relatório, aqui é um sistema de logs, aqui é o sistema do Smith, aqui que é um SAS aqui, que é é um sistema de criação de agentes aqui que a gente construiu e a gente divide isso aqui dentro da comunidade. Então veja que aqui eu tô mostrando, ó, um de 15 de 100, ou seja, tá paginado. Eu só mostro 15 resultados de uma vez só. Quando eu vou pro próximo e aí vai aparecer aqui, depois eu vou pro próximo e vai aparecer mais 15. E aí por aí vai, galera. Assim que você consegue paginar e fazer um sistema desse performar. Beleza?
17:59 · Tem que tratar isso, senão quando seu sistema escalar, você vai ter que fazer isso de toda forma. Só que aí você já vai ter que resolver isso com o avião voando.
18:11 · Beleza? O próximo passo aqui, ó, é validation e sanitization. Validação e sanitização. Nunca confiar no input do usuário. Então, por exemplo, campo de idade recebendo um SQL injection. Então, você precisa validar tipo, tamanho, formato, sanitizar o HTML para evitar o XS. Muito simples, cara. Você tem que validar se tem um campo, vou dar um exemplo mais esdrúchulo aqui, que é mais difícil de acontecer, mas imagine que um campo de telefone você poder aceitar texto, não é só números.
The Concept of Validation and Sanitization in AI Applications
18:43 · Você não deu um lock naquele campo ali porque ele só recebe números. Se você não tratar isso, muitas vezes a sua IA vai errar. Talvez não telefone porque é algo muito simples, mas se você tem algum tipo de cadastro que precisa aceitar apenas números, mas que tá aceitando e texto, que pode aceitar até um SQL ali, toma um SQL injection ali, é, você não tá tratando o seu sistema da forma correta.
19:06 · É, isso aqui merece uma validação e uma sanitização aí dentro do seu sistema. E mais uma última camada aqui muito importante que é a observabilidade, logs, métricas, traces para ver o que rola. Então, se você não logar o seu sistema, não tem métricas, não entrar aqui, nós temos aqui Leng Smith para poder validar aqui os os agentes de A, o que que eles estão respondendo, como que você tá tratando isso aí, centre para poder você validar, logar os erros e você entra aqui, você precisa monitorar isso, você vai ter que monitorar isso.
The Concept of Observability and Tracking in Applications
19:41 · Não tem como você não monitorar uma aplicação sua que está em produção. Aí dentro de uma de uma VPS, de um Rayway, você precisa monitorar aqui o que que acontece no seu sistema, a memória que tá sendo utilizada, se você tá tendo algum pico aqui em alguma parte da aplicação que você precisa saber como resolver, porque às vezes o seu sistema tá num pico máximo, você precisa escalar
20:03 · e alugar temporariamente um pouco mais de servidor, melhorar a máquina que tá usando, porque claramente se você tá estourando o pico do seu servidor, é ou a sua aplicação ou ela tá travada ou ela tá super lenta e você vai ter que tratar isso. E aí para resolver isso, você precisa monitorar toda essa infraestrutura aqui. É mesmo dentro que seja rail, aqui é o railway, mas cara, independente de onde você sobe o seu sistema, independente de qual cloud, se é na WS, se é no Versel, você precisa monitorar.
20:31 · E se você não tem essas ferramentas de monitoramento, você simplesmente não vai nem conseguir pedir pro seu agente de entender qual é o problema que está dando. É a primeira coisa que você precisa é saber aonde procurar os logs, aonde quando deu erro, ter alertas desses erros. Tem que chegar um deu um erro no sistema, tem que chegar no mínimo um e-mail, um alerta, um alarme. Você precisa saber isso na hora.
20:58 · Você não pode esperar o seu cliente simplesmente te reclamar do problema que está dando, você já tem que saber. Então, cara, deu erro em produção às 3 da manhã, sem logs ali do centre. E aí tem Grafana, tem New Helic, tem N aqui que você pode utilizar. Não tô fazendo propaganda de nenhuma aqui, tá?
21:17 · Só para deixar claro. Tem que monitorar. Sem isso aqui você tá cego. Con o trace você vê onde travou, por e você vai saber exatamente até qual linha, onde olhar, qual é o problema e qual é o código que tá gerando aquele problema. É isso aqui, cara, é crítico. Se você tem um sistema em produção, se você não tem nada que esteja monitorando, meu amigo, o seu tempo está contado, beleza? E aí, pra gente finalizar o mínimo que você precisa, né, para colocar alguma coisa em produção. Coloquei aqui algo bem simples, tá? Isso aqui é o mínimo, tá?
21:50 · Depois que você desenvolveu e tá tudo funcionando maravilhosamente bem, aí você tá clicando nos botões, tudo tá se comportando, você tem que fazer teste de cargas no seu sistema. Que que é teste de carga, cara? Vou numa aplicação dessa aqui que é do Smith, é que é um SAS de agentes de A, o que que mais consome aqui? é os agentes buscando uma base reg, só que são vários agentes para vários clientes. Então o que que eu tenho que testar de carga aqui, que é o principal, é eu fazer 100 requisições no mesmo segundo.
The Minimum You Need to Know to Put an App into Production
22:21 · E os agentes todos têm que conseguir responder, tá? Respondendo múltiplos clientes. E você monitora quanto tempo demorou para os agentes responderem? O sistema conseguiu responder primeiro. O sistema deu conta do recado, ele conseguiu responder, ele consultou as bases regs lá, respondeu correto e ele conseguiu responder tudo que precisava. Se demorou 30 segundos cada agente para responder, beleza, demorou, mas o seu sistema aguentou 100 chamadas em um segundo.
22:45 · E aí você vai entender se você vai lateralizar sua arquitetura, se você vai ter que comprar mais servidor, se você vai ter que acelerar ali, se você vai ter que ter mais memória, mais pulling, você vai ter que tomar alguma decisão. Mas se você só testa o seu sistema apertando um botão aqui, esse botão funcionou e aí beleza, tá tudo OK, salvar alterações, beleza?
23:06 · Mas se você tem muitos usuários e 50 usuários aqui numa fração de segundos, todo mundo aperta o botão salvar alterações aqui. O que que acontece? Se o sistema aguenta, ele vai cair. Você tem que fazer testes de carga antes de colocar esse produção. E isso é um problema de arquitetura. Se você não fizer esse teste aqui e descobrir isso em produção, eh, veja que você já vai ter muitos usuários para poder ver um problema desse em produção. E aí você vai descobrir que vai ter ali, é um buraco no seu sistema que você vai ter que resolver enquanto todos esses usuários estão utilizando o seu sistema.
23:40 · Quando você tá aqui no ambiente de teste, cara, se travou e fodeu tudo, beleza, não tem ninguém te pagando para poder usar esse sistema. Agora, uma vez que tá em produção, você tem que resolver isso, você tem que resolver rápido e você não pode quebrar a sua aplicação. E muitas vezes isso aqui ele revela problemas estruturais que você tem que fazer um refectory muitas vezes gigantesco para poder resolver esse problema aqui. Beleza? O segundo aqui, cara, é o que os desenvolvedores falam demais, auditoria de segurança. A IA, ela por padrão, ela quer te entregar o código mais rápido possível, eh, de um jeito que funciona.
24:14 · Ela não tá preocupado com segurança, não tá preocupado se as rotas estão autenticadas, se os dados ali, senha, cookies, se isso tá encado, se tá usando um iron session. eh não tá preocupado com isso. Se você não rodar várias auditorias de segurança, eu falo várias mesmo, é você entrar num pipeline desse aqui, igual o do Lion Claw, eh, que já apresentei aqui em vários outros vídeos.
24:35 · Vou deixar os vídeos aqui, si vocês quiserem ver como funciona. Se você não entrar aqui, eh, e não rodar várias vezes esse tipo de auditoria de segurança, eh, você não vai conseguir fazer, eh, o seu sistema ficar realmente seguro, porque a cada vez que você roda uma auditoria, aí ela pega só um pouco, ainda mais se o sistema for muito grande, tem muita coisa que ela deixa passar, cara. Já achei aqui, eu pesquisei aqui uns 10 arquivos, já tem o suficiente. Roda lá, você acha que tá tudo certo, mas quando você roda de novo, ela vai lá e acha mais 15. E aí você roda de novo, ela vai acha mais 20.
25:04 · E você tem que ir rodando vários dessas auditorias, porque não tem como confiar 100% que o que a IA tá fazendo ali é 100% seguro. Então isso aqui é algo obrigatório antes de você colocar um sistema em produção. Beleza? Banco de dados escalável. Primeira coisa que não tem nada a ver com com a parte de banco de dados escalável é se você conecta o seu agente de A diretamente no seu banco de dados de produção, você já tem a chave do fracasso prontinho para algum momento. Isso dá uma merda muito grande.
25:31 · Então não conecte jamais o seu agente A diretamente no banco de dados de produção, beleza? E também, cara, tente colocar um banco de dados de teste lá no seu ambiente local e um banco de dados e em produção, totalmente separado. Por aqui você consegue fazer vários testes aqui, principalmente se a sua aplicação tá dando erro, sem ficar batendo aqui direto nesse banco e sujando esse banco de produção.
25:57 · Tudo que você tá construindo, você tem que testar aqui primeiro, principalmente porque você vai ter que fazer algo eh ao longo do da sua jornada, do seu sistema, que chama migrations, que em algum momento você vai criar ali uma nova funcionalidade que vai depender ali de uma nova coluna dentro daquela tabela e você vai ter que criar essa coluna.
26:18 · Só que veja que quando você tá criando essa coluna e em produção, dependendo da hora que você tá criando, o seu sistema tiver com muita escrita, muitos pulings aqui conectados no seu banco de dados, enquanto está criando aquela coluna numa tabela gigantesca, o seu sistema ele trava por alguns segundos, minutos, e aí tudo para no seu sistema. Então você tem que ter uma estratégia até para executar essas migrations aqui.
26:42 · Aqui eu já tô falando já é de uma aplicação que cresceu muito, mas muitas vezes é quando eu falo aqui em banco de dados escalável, a pessoa ela não pensa nisso é de que ela tá querendo gravar alguns dados que em pouco tempo a tabela vai ficar gigantesca. Por exemplo, os logs. Você grava log de tudo que acontece no seu sistema. Isso é legal, muito bom. Mas e aí? Passou 4 meses, a tabela tem 100 milhões de registros. E aí, como é que você faz? Você já aperta para consultar, já tá gastando eh uma consulta gigantesca dentro do seu banco de dados.
27:16 · Aquela tabela, ela vai continuar crescendo e aí se você precisar executar uma migration nela, você não consegue rodar enquanto o sistema tá rodando durante o dia. Você tem que rodar de madrugada. Então você tem que pensar em tudo isso. Antes de você colocar isso aqui em produção, você já tem que ter uma noção de que seu banco ele precisa ser escalável, senão a sua aplicação vai quebrar. Outro fato aqui também de banco de dados é você trabalhar aqui as indexações das tabelas.
27:40 · Você tá realmente trabalhando a indexação é da busca que você tá fazendo ou se você tá simplesmente confiando na query que o seu agente tá fazendo ali, que ele faz duas, três, quatro queres ali dentro da mesma tabela, buscando tudo e aí demora 10 segundos para trazer um resultado é com só você mexendo no sistema. Imagina quando tiver 100 pessoas fazendo essa mesma query. Pensa nisso, beleza? review de arquitetura, a mesma coisa. Você precisa de tempos em tempos dar um tapa na arquitetura. Nem sempre.
28:09 · E aí eu te falo que às vezes mesmo que você é um desenvolvedor experiente, desenvolvedores experientes fazem isso, o cara dá uma olhada, foi construindo, putz, isso aqui poderia ser melhor, poderia diminuir aqui o código aqui, tá com 5.000 linhas, poderia reduzir isso aqui, quebrar esses arquivos, eh dar uma refatorada aqui, diminuir esse código aqui em poucas linhas para poder ficar um negócio mais limpo, para poder ficar mais performático, para eu entender melhor esse código no futuro.
28:34 · Isso aqui tem que ser feito também de tempos em tempos, mas melhor é ser feito antes de você colocar pra produção. É você tentar subir o mais limpo possível, porque de acordo com o decorrer dos anos, é esse sistema, essa arquitetura aqui, ela vai inflar e você vai precisar ainda fazer esses reviews, mas vai ser muito menos trabalho. Beleza? Traqueamento de erros, eu nem vou repetir ali, que é essa parte do centre que eu mostrei aqui para vocês. Monitoramento de infraestrutura.
29:01 · Você também tem que tá sempre ligado, mesmo que o seu sistema ele tá pequeno, mas quando você tá sempre observando ali, você já sabe, pô, hoje eu tô com 50 clientes aqui. A infra aqui tá, cara, o gráficozinho tá começando a ficar chegar no limite.
29:19 · Você não pode simplesmente esperar o seu sistema crashar para depois você, putz, cara, tem que correr atrás aqui, pagar mais, pagar mais memória, colocar e, enfim, investir numa máquina melhor para você não pode esperar o seu sistema quebrar, você já tem que monitorar antes, porque isso aqui vai acontecer, seu sistema vai crashar se você simplesmente e não observar isso. Beleza? Isso aqui, tudo que eu falei, eu ainda não cobri 50% do que tá aqui, né? Já a gente falar de testes, eh, dis de como que você vai e subir os seus deploys.
29:50 · Não pode ser simplesmente, ah, resolver o problem aqui, deploy, resolve outro problema, deploy de novo. Enquanto isso, seus usuários, seus clientes estão lá e com seu sistema em produção e usando e você não pode ficar mais arriscando ficar quebrando o seu sistema em produção.
30:06 · Então, tem várias coisas aqui que eu poderia falar mais, mas sorte você já começar aprendendo esses conceitos aqui, eh, eu te garanto que quando a sua solução sair aí você tiver eh desenvolvendo aí com a sua, com o seu agente de a você já tem que estar preparado e estudar isso aqui e e implementar isso aqui dentro do seu código. Eu te garanto que vai te eliminar uma dor de cabeça enorme.
30:30 · Cuidado com os gurus, porque os gurus eles só estão querendo te ensinar esse cara aqui, ó. só estão querendo te ensinar isso aqui. Agora, essa parte aqui, ó, esses caras eles não vão te ensinar. E aí, aqui, amiga, aqui que mora o problema. É aqui que o seu sonho aí vai morrer se você não souber o que você tá fazendo. Beleza? Então, aqui eu acho que eu já dei aí o primeiro passo de um overview geral aqui para vocês de coisas que vocês precisam estudar aí.
30:56 · Eh, para colocar uma aplicação em produção, tem bastante coisa ainda que você vai precisar aprender. E veja que aqui eu nem entrei eh dentro do código mesmo de você ter que entender ali o que que uma função, o que que aquela função faz, o que que ela tá fazendo no código, você ler o código. Eu só falei de infra e arquitetura de sistemas que você precisa aprender para colocar em produção.
31:17 · E eu não tô dizendo que você vai ter que virar um Devops aqui amanhã, mas você precisa, pelo menos, saber que isso aqui existe, porque o dia que o seu projeto precisar escalar, si esse dia chegar, você não vai ser pego de surpresa e vai me agradecer por ter assistido esse vídeo, beleza? O link da comunidade tá disponível na descrição desse vídeo. Se você quiser aprender mais sobre desenvolvimento de aplicações utilizando inteligência artificial, venha compartilhar o seu conhecimento conosco e nós também vamos compartilhar com vocês. Vocês serão muito bem-vindos, beleza?
31:48 · Um forte abraço a todos e até mais.