Tutorial de Vibe Coding com Kimi: Criar um Produto sem Escrever Código É Mais Fácil, mas Lançá-lo Não É

Kimi transformou um fluxo de trabalho antes técnico em um conversacional, mas a mudança cria um novo conflito entre criar rapidamente e lançar de forma responsável. Este tutorial de vibe coding com Kimi examina esse conflito por meio de uma jornada completa de produto, de uma especificação inicial a uma implantação pública.

A mudança importante não é que um modelo de IA pode gerar uma landing page. Agentes de programação agora podem inspecionar arquivos de projeto, editar vários componentes, executar comandos, rodar testes e ajustar seus planos após falhas. Kimi Code, Qwen Code e serviços de programação baseados em GLM colocam esse fluxo de trabalho dentro de terminais e ambientes de desenvolvimento.

Isso coloca quem cria pela primeira vez em uma posição incomum. Essas pessoas podem produzir mais software antes de compreender os sistemas por trás dele. Ainda assim, hospedagem, autenticação, bancos de dados, segurança, configuração de domínio e obrigações regulatórias continuam se comportando como problemas de engenharia.

Andrej Karpathy deu a essa prática um nome memorável em fevereiro de 2025. Sua descrição enfatizava aceitar alterações geradas e esquecer temporariamente que o código existia. Essa atitude funcionava para projetos experimentais de fim de semana, mas um produto público cria um padrão diferente.

A pergunta útil já não é se uma pessoa sem experiência em programação pode criar uma aplicação. Ela pode. A pergunta mais difícil é se ela consegue compreender, testar, operar e recuperar a aplicação depois que um agente a cria.

Os Agentes de Programação do Kimi Agora Fazem Mais do que Gerar Código

A mudança de assistente de chat para agente de programação altera quem pode iniciar um projeto de software, mas não remove a responsabilidade do criador.

Um modelo de chat normalmente retorna texto ou exemplos de código isolados. Um agente de programação pode trabalhar dentro de um projeto, inspecionar sua estrutura, modificar arquivos, executar comandos e observar o resultado gerado. Esse ciclo de feedback permite que o sistema continue após a primeira resposta.

A distinção importa para um criador sem conhecimento técnico. Copiar código entre um navegador e um editor exige saber onde cada fragmento pertence. Um agente pode localizar os arquivos relevantes e coordenar alterações na interface, no servidor, no banco de dados e na configuração.

Kimi descreve seu cliente de linha de comando como um agente capaz de ler e modificar código, pesquisar arquivos, executar comandos de shell e revisar seu plano com base no feedback. Seu atual guia do Kimi Code também explica como o cliente pode gerar um arquivo AGENTS.md após analisar um projeto.

Esse arquivo atua como contexto operacional para o agente. Ele pode registrar a estrutura do projeto, comandos de compilação, convenções e outras instruções que devem persistir entre tarefas. O agente obtém um mapa em vez de tratar cada prompt como uma solicitação isolada.

Qwen Code segue um modelo semelhante. Sua visão geral do agente descreve uma ferramenta de terminal que transforma instruções de produto em código e oferece suporte ao uso automatizado e não interativo. Ela também pode se conectar por meio de várias opções de autenticação e provedores de modelos.

Esses produtos representam uma mudança maior na interface do desenvolvimento de software. O usuário descreve comportamentos, restrições e critérios de aceitação. O agente traduz essa intenção em arquivos, comandos e testes.

No entanto, a linguagem natural não é uma especificação completa. Um pedido como “crie um portal do cliente” deixa questões críticas sem resposta. Ele não diz nada sobre recuperação de conta, permissões de acesso, retenção de dados, pagamentos com falha, logs de auditoria ou prevenção de abuso.

Um engenheiro experiente percebe essas lacunas porque elas se parecem com falhas anteriores. Um iniciante frequentemente vê a interface visível e presume que o sistema está quase pronto. Agentes de programação comprimem o tempo de implementação, mas também podem ocultar decisões inacabadas atrás de uma tela polida.

O guia chinês obtido da AIHOT capta bem esse novo fluxo de trabalho. Ele apresenta modelos nacionais, incluindo Kimi, GLM e Qwen, como caminhos acessíveis de uma ideia a um produto online. Seu conselho mais forte aparece perto do fim: um criador pode evitar escrever código, mas não pode evitar compreender a arquitetura.

Essa distinção deve definir qualquer tutorial sério de vibe coding com Kimi. O agente pode executar tarefas, enquanto o humano continua responsável por definir o sistema e avaliar se ele funciona.

Uma Especificação de Produto Deve Vir Antes do Primeiro Prompt

Uma ideia vaga produz uma demonstração convincente, enquanto uma especificação delimitada dá ao agente a chance de produzir um produto operacional.

A primeira entrega não deve ser código. Deve ser uma breve especificação de produto que cubra usuários, tarefas, dados, permissões, estados de falha e critérios de sucesso. Esse documento se torna a referência quando o agente começa a fazer suposições.

Comece com um usuário e uma tarefa. “Freelancers precisam transformar anotações de reuniões em acompanhamentos para clientes” é mais acionável do que “crie uma plataforma de produtividade com IA”. A declaração mais restrita identifica uma entrada, uma transformação e uma saída.

Em seguida, defina a menor jornada completa. Um usuário cria uma conta, importa uma anotação, revisa um acompanhamento gerado, edita-o e exporta o resultado. Cada etapa deve incluir o que o usuário vê e o que acontece quando a ação falha.

Os dados merecem sua própria seção. Liste cada tipo de informação que a aplicação armazena, de onde ela vem, quem pode lê-la e quando deve ser excluída. Documentos sensíveis exigem proteções diferentes de dados públicos de catálogo.

As permissões também precisam de linguagem explícita. Um administrador, um usuário comum e um visitante anônimo não devem compartilhar as mesmas capacidades. Se o produto oferece suporte a equipes, especifique se os membros podem ver os registros uns dos outros e quem pode remover o acesso.

Em seguida, defina o sistema como vários componentes:

• A interface exibe telas, formulários, navegação e feedback.

• O serviço da aplicação aplica regras de negócio e coordena solicitações.

• O banco de dados armazena usuários, registros, permissões e estado.

• A autenticação verifica a identidade e controla sessões.

• Serviços externos fornecem e-mail, pagamentos, inferência de IA ou armazenamento de arquivos.

• A hospedagem disponibiliza a aplicação e fornece logs, rede e backups.

Um iniciante não precisa conhecer todos os detalhes de implementação antes de começar. Mas precisa reconhecer esses componentes e perguntar onde cada responsabilidade está localizada. Caso contrário, o agente pode combinar silenciosamente preocupações não relacionadas em código frágil.

O modo de planejamento é útil nesta etapa. Em vez de pedir ao agente que construa imediatamente, peça que ele inspecione a especificação, identifique decisões ausentes, proponha uma arquitetura e divida o trabalho em marcos.

O plano do agente deve nomear as principais entidades de dados, rotas, dependências e estratégia de testes. Ele também deve declarar as suposições. Suposições ocultas se tornam caras quando vários recursos dependem delas.

Peça ao agente que descreva a arquitetura sem código. Se a explicação continuar confusa, o produto não está pronto para implementação autônoma. Retrabalhe o plano até conseguir explicar o fluxo da solicitação em linguagem simples.

Prompts úteis definem evidências, não entusiasmo. “Adicione login” está incompleto. “Adicione login por e-mail, rejeite sessões expiradas, impeça usuários de acessar registros de outra conta e escreva testes para esses casos” cria requisitos observáveis.

A mesma disciplina se aplica ao trabalho de interface. Descreva estados vazios, estados de carregamento, erros de validação, telas pequenas, navegação por teclado e ações destrutivas. Um painel gerado que só lida com dados ideais continua sendo um mockup.

Os criadores podem manter requisitos, notas de origem, decisões de modelo e observações de teste dentro de um fluxo de trabalho de IA. Esse contexto se torna valioso quando um agente pergunta por que uma escolha arquitetural anterior foi feita.

Uma especificação mudará durante o desenvolvimento. Isso é normal. A regra importante é atualizar o documento-fonte antes de pedir ao agente que implemente a nova direção.

O tutorial de Kimi Vibe Coding: do plano à compilação funcional

O fluxo de trabalho agêntico mais seguro usa marcos pequenos e verificáveis em vez de um único prompt que pede uma aplicação inteira.

Crie o projeto em um repositório com controle de versão antes de começar a implementação principal. O controle de versão registra alterações como commits, permitindo que quem constrói compare revisões e recupere um estado anterior. O commit inicial deve conter a especificação e uma estrutura mínima do projeto.

Peça ao agente que proponha uma pilha de tecnologia com base na simplicidade operacional. A resposta deve explicar por que cada componente existe, como será implantado e quais alternativas foram rejeitadas. Evite escolher um framework apenas porque o modelo o gerou primeiro.

O primeiro marco deve estabelecer a estrutura da aplicação. Ele inclui o comando de desenvolvimento, a configuração de ambiente, a navegação básica, uma verificação de integridade e um comando de teste. Nenhum recurso de negócio deve avançar até que outro ambiente limpo consiga executar essa estrutura.

O segundo marco deve implementar o modelo de dados central. Peça ao agente que mostre as entidades, seus relacionamentos e regras de propriedade antes de gerar migrações. Uma migração é uma alteração controlada no banco de dados que pode ser aplicada de forma consistente entre ambientes.

Revise o esquema em linguagem simples. Qual registro pertence a qual usuário? O que acontece quando uma conta é excluída? Dois registros podem acidentalmente referenciar dados ausentes? As respostas revelam se o modelo subjacente corresponde ao produto.

O terceiro marco adiciona autenticação e autorização. A autenticação responde quem é o usuário. A autorização responde o que esse usuário pode fazer. Muitas aplicações geradas implementam a primeira enquanto tratam a segunda como uma preocupação da interface.

A autorização deve ser aplicada pelo servidor em toda operação protegida. Ocultar um botão não é controle de acesso. Um usuário mal-intencionado ou curioso pode enviar solicitações sem usar a interface pretendida.

O quarto marco implementa uma jornada completa do produto. Resista a adicionar páginas de configurações, painéis de análise ou refinamentos visuais antes que o caminho principal funcione. Uma fatia vertical estreita expõe problemas de integração mais cedo.

Após cada tarefa, exija que o agente resuma:

• Os arquivos que ele alterou

• O comportamento que ele adicionou

• As suposições que ele fez

• Os testes que ele executou

• Os testes que ainda precisam de julgamento humano

• Quaisquer consequências de segurança ou implantação

Execute a aplicação após cada marco. Tente primeiro o comportamento esperado e depois faça uso indevido dela. Envie formulários vazios, entradas grandes demais, solicitações duplicadas, sessões expiradas, URLs inválidas e o identificador de registro de outro usuário.

Quando algo falhar, relate o comportamento observado em vez de pedir ao agente para “consertar tudo”. Inclua o comando, o resultado esperado, o resultado real e a saída relevante do log. Um feedback preciso ajuda o modelo a distinguir um defeito de um requisito mal compreendido.

Não aceite reescritas amplas como resposta padrão para um bug local. Peça uma explicação da causa raiz e uma correção mínima. Grandes alterações geradas são mais difíceis de revisar e podem remover comportamentos que funcionavam.

Faça um commit após cada marco verificado. Use descrições que indiquem a mudança no produto, não o histórico da conversa. Um histórico limpo permite retornar a um estado conhecido quando um agente introduz vários erros conectados.

Inicie uma nova sessão de agente quando o contexto se tornar confuso. Forneça à nova sessão a especificação, a arquitetura, o marco atual e o estado verificado do repositório. Conversas longas podem preservar suposições desatualizadas depois que o produto mudou.

Essa abordagem em etapas parece mais lenta do que a geração em uma única tentativa. Na prática, ela reduz o ciclo caro em que uma aplicação refinada desmorona durante a implantação. O objetivo não é o máximo de código gerado por prompt, mas o máximo de progresso verificado por alteração.

A implantação transforma uma demonstração em um sistema operacional

Entrar em operação adiciona responsabilidades de infraestrutura, identidade, regulamentação e recuperação que o agente de programação não pode assumir pessoalmente.

Uma aplicação local é executada em uma máquina sob condições favoráveis. Uma implantação pública recebe tráfego imprevisível, solicitações malformadas, varreduras automatizadas e dados reais de usuários. Esse ambiente muda o significado de “funcionando”.

Separe os ambientes de desenvolvimento e produção. O desenvolvimento é o espaço para experimentação. A produção é o sistema do qual usuários reais dependem. Eles não devem compartilhar o mesmo banco de dados, credenciais ou acesso administrativo irrestrito.

Armazene a configuração por meio de variáveis de ambiente ou de um serviço gerenciado de segredos. Nunca coloque senhas de banco de dados, chaves de API ou segredos de assinatura dentro de arquivos-fonte. Peça ao agente que examine o histórico do repositório em busca de credenciais acidentais antes do lançamento.

Escolha a hospedagem com base nos componentes da aplicação. Uma interface estática, um servidor de longa execução, uma tarefa agendada e um banco de dados relacional têm requisitos diferentes. O plano de implantação deve identificar como cada componente inicia, se comunica, registra erros e reinicia.

Um domínio adiciona outra camada. Seus registros DNS direcionam os usuários ao serviço de hospedagem, enquanto o TLS criptografa as conexões. O produto também precisa de uma estratégia para redirecionar formas alternativas de domínio e renovar certificados.

Produtos hospedados na China continental podem enfrentar obrigações adicionais de registro. As revisadas regras de registro ICP afirmam que serviços não comerciais de informação pela internet fornecidos dentro do país devem concluir os procedimentos de registro.

As regras também dizem que solicitações completas devem receber uma decisão de registro em até 20 dias úteis. Isso é um máximo regulatório, não uma promessa de que todo lançamento será concluído em um cronograma fixo. Quem constrói deve tratar o registro como uma frente de trabalho inicial.

A obrigação exata depende do serviço, do arranjo de hospedagem, do modelo de negócio e da jurisdição. Um agente de programação pode organizar os requisitos, mas não pode fornecer uma autorização jurídica oficial. Consulte o provedor relevante e assessoria jurídica qualificada quando o escopo for incerto.

A implantação também precisa de controles de migração do banco de dados. Faça backup dos dados de produção antes de aplicar uma alteração destrutiva. Teste a migração com dados representativos e documente como revertê-la.

Crie uma lista de verificação de lançamento que cubra sucesso da compilação, testes automatizados, verificações de segurança, migrações, configuração, monitoramento e reversão. Cada item deve produzir evidências, e não uma garantia verbal do agente.

Os logs devem responder o que falhou, quando falhou e qual operação foi afetada. Eles não devem expor senhas, tokens, documentos privados ou informações pessoais desnecessárias. Registrar mais dados não é automaticamente mais seguro.

O monitoramento deve cobrir disponibilidade básica, erros do servidor, latência, tarefas em segundo plano com falha e limites de armazenamento. Um alerta precisa de um responsável humano e de um caminho de resposta. Uma notificação que ninguém entende é apenas ruído adicional.

Os backups precisam de testes de restauração. Um trabalho de backup bem-sucedido prova que os dados foram copiados para algum lugar. Não prova que o produto pode se recuperar em um período aceitável.

Antes de convidar usuários, crie uma rota de reversão. Isso pode significar restaurar a versão anterior, desativar um novo recurso ou reverter uma migração. A equipe deve saber qual ação se aplica a cada falha provável.

É aqui que a descrição “sem código” se torna enganosa. Quem constrói pode não digitar a implementação, mas ainda opera um sistema com responsabilidades técnicas e organizacionais.

Código gerado por IA precisa de proteção de ramificações e testes adversariais

A confiança de um agente não é evidência de que um produto seja seguro, correto ou esteja pronto para produção.

A Pesquisa de Desenvolvedores do Stack Overflow de 2025 encontrou uma clara lacuna de confiança em relação à saída de IA. Embora 84 por cento dos respondentes usassem ou planejassem usar ferramentas de IA, 46 por cento desconfiavam de sua precisão. Apenas 33 por cento expressaram confiança.

A mesma pesquisa de desenvolvedores constatou que 66 por cento ficaram frustrados com soluções de IA que estavam quase corretas. Outros 45 por cento identificaram a depuração demorada de código gerado como uma grande frustração.

Esses números não mostram que os agentes de programação não têm valor. Eles mostram por que a verificação deve acompanhar a adoção em escala. Uma geração mais rápida pode criar uma carga de revisão maior quando as mudanças se espalham por partes desconhecidas de um sistema.

Proteja a branch principal após a configuração inicial do projeto. A proteção de branch do GitHub pode exigir pull requests, verificações de status aprovadas, discussões resolvidas ou revisões aprovadas antes que uma alteração seja mesclada.

Um desenvolvedor solo ainda pode se beneficiar dessa estrutura. O agente trabalha em uma branch separada, as verificações automatizadas são executadas, e o desenvolvedor revisa o resumo antes de mesclar. A pausa cria uma fronteira entre geração e lançamento.

No mínimo, o pipeline automatizado deve instalar dependências a partir de um arquivo bloqueado, compilar a aplicação, executar testes e realizar verificações orientadas à segurança. Uma falha deve bloquear a mesclagem em vez de se tornar um aviso perdido nos logs.

Os testes devem operar em vários níveis:

• Testes unitários verificam regras de negócio isoladas.

• Testes de integração verificam a comunicação com bancos de dados e serviços externos.

• Testes de ponta a ponta exercitam jornadas completas do usuário.

• Testes de autorização confirmam que uma conta não pode acessar os dados de outra conta.

• Testes de migração verificam se alterações no esquema preservam os registros existentes.

• Testes manuais examinam a usabilidade, resultados ambíguos e comportamentos inesperados.

Peça ao agente para escrever testes antes de corrigir um defeito confirmado. O teste que falha registra o problema e reduz a chance de ele retornar. Em seguida, exija que o mesmo teste passe após o patch.

A segurança exige uma etapa separada de modelagem de ameaças. Um modelo de ameaças identifica ativos valiosos, possíveis atacantes, pontos de entrada expostos e usos indevidos prováveis. Ele transforma “torne isso seguro” em um conjunto de perguntas concretas.

O que acontece se um usuário modificar um identificador em uma solicitação? O conteúdo enviado pode executar código? URLs externas são buscadas pelo servidor? Tentativas repetidas de senha podem continuar sem limites? Rotas administrativas verificam funções no servidor?

A OWASP alerta que sistemas gerados por IA ou desenvolvidos por cidadãos podem reutilizar componentes vulneráveis e até fazer referência a pacotes inexistentes. Suas orientações sobre componentes não confiáveis recomendam tratar dependências geradas como itens que exigem verificação.

Inspecione cada nova dependência. Confirme que o pacote existe, vem do publicador esperado, recebe manutenção e atende a uma finalidade necessária. Um nome de pacote plausível não é prova de legitimidade.

Use um arquivo de bloqueio de dependências e evite pacotes desnecessários. Menos dependências reduzem o número de componentes externos que podem falhar, mudar de proprietário ou introduzir vulnerabilidades.

O código de autenticação gerado merece atenção especial. Armazenamento de senhas, tratamento de sessões, fluxos de redefinição, configurações de cookies e verificações de autorização contêm detalhes sensíveis à segurança. Prefira implementações estabelecidas e documentadas em vez de lógica personalizada.

Nunca use dados reais de clientes durante os testes iniciais. Gere registros sintéticos que se assemelhem à estrutura necessária sem expor informações pessoais. Limite o acesso à produção mesmo quando apenas uma pessoa opera o projeto.

Recursos de IA criam riscos adicionais. Se o conteúdo do usuário entrar em um prompt de modelo, trate esse conteúdo como não confiável. Ele pode tentar substituir instruções, revelar contexto oculto ou acionar ferramentas não intencionais.

Um agente com acesso a arquivos e comandos também possui privilégios locais significativos. Revise as ações solicitadas, restrinja credenciais e evite conceder acesso à produção durante o desenvolvimento comum. A conveniência não deve apagar as fronteiras operacionais.

Um fundador sem perfil técnico deve providenciar uma revisão independente antes de lançar um produto que lida com dinheiro, informações de saúde, documentos confidenciais ou dados de identidade sensíveis. O agente que gerou o código não deve ser o único revisor de seu próprio trabalho.

O que os desenvolvedores devem acompanhar após o lançamento

O teste decisivo para o vibe coding não é se um agente consegue publicar a versão um, mas se o humano consegue operar a versão dois.

O primeiro sinal é a confiabilidade das mudanças. Acompanhe com que frequência um recurso solicitado passa nos testes, chega à produção e permanece ativo sem reversão. Reversões frequentes sugerem que a arquitetura ou o processo de verificação não consegue suportar a velocidade do agente.

O segundo sinal é a responsabilidade por incidentes. Quando surge um alerta, o desenvolvedor deve identificar o componente afetado, inspecionar os logs relevantes e explicar o caminho da falha. A dependência total da resposta de outro agente deixa o produto sem um diagnóstico responsável.

O terceiro sinal é a portabilidade entre modelos. Kimi, Qwen, GLM e outros sistemas de programação continuarão mudando seus clientes, modelos, métodos de autenticação e limites. Um repositório com documentação clara e ferramentas padrão pode passar entre agentes com mais facilidade.

Portabilidade entre modelos não significa que todos os agentes produzem código idêntico. Significa que os requisitos, a arquitetura, os comandos e os testes do projeto são explícitos o suficiente para que outra ferramenta ou engenheiro possa continuar o trabalho.

Os desenvolvedores também devem acompanhar a lacuna entre a saída visível e a qualidade operacional. Novas telas de interface são fáceis de demonstrar. Taxas de erro menores, migrações mais seguras, recuperação mais rápida e permissões mais claras são menos visíveis, mas mais importantes.

Este tutorial de vibe coding com Kimi, portanto, termina com uma definição diferente de sucesso. Sucesso não é chegar a uma URL ativa sem tocar em uma linguagem de programação. É chegar a um sistema ativo cujo comportamento, dados, riscos e caminho de recuperação você consegue explicar.

Comece com uma jornada de usuário e escreva seus requisitos antes de abrir o agente de programação. Faça o agente planejar, implementar um marco e fornecer evidências dos testes. Faça commit apenas de alterações verificadas e, em seguida, crie controles de implantação e recuperação antes de convidar usuários reais.

Se você não consegue explicar onde a identidade é verificada, onde os dados ficam ou como uma versão com falha é revertida, pause o lançamento. Peça ao agente que mapeie esses sistemas até que as respostas fiquem claras. O vibe coding pode reduzir o custo da implementação, mas não pode transferir a responsabilidade pelo produto para um modelo.