Tutorial de Kimi Vibe Coding: crear un producto sin escribir código es más fácil, pero lanzarlo no lo es

Kimi ha convertido un flujo de trabajo que antes era técnico en uno conversacional, pero el cambio crea un nuevo conflicto entre construir rápidamente y lanzar de forma responsable. Este tutorial de Kimi vibe coding examina ese conflicto a través de un recorrido completo del producto, desde una especificación inicial hasta un despliegue público.

El cambio importante no es que un modelo de IA pueda generar una página de destino. Los agentes de programación ahora pueden inspeccionar archivos de proyecto, editar varios componentes, ejecutar comandos, realizar pruebas y ajustar sus planes tras los fallos. Kimi Code, Qwen Code y los servicios de programación basados en GLM incorporan ese flujo de trabajo dentro de terminales y entornos de desarrollo.

Eso coloca a quienes crean por primera vez en una posición inusual. Pueden producir más software antes de comprender los sistemas que hay debajo. Sin embargo, el alojamiento, la autenticación, las bases de datos, la seguridad, la configuración de dominios y las obligaciones regulatorias siguen comportándose como problemas de ingeniería.

Andrej Karpathy dio a esta práctica un nombre memorable en febrero de 2025. Su descripción enfatizaba aceptar los cambios generados y olvidar temporalmente que el código existía. Esa actitud funcionaba para proyectos experimentales de fin de semana, pero un producto público exige un estándar diferente.

La pregunta útil ya no es si una persona sin experiencia en programación puede crear una aplicación. Puede hacerlo. La pregunta más difícil es si puede comprender, probar, operar y recuperar la aplicación después de que un agente la cree.

Los agentes de programación de Kimi ahora manejan más que la generación de código

El cambio de asistente de chat a agente de programación modifica quién puede iniciar un proyecto de software, pero no elimina la responsabilidad del creador.

Un modelo de chat normalmente devuelve texto o muestras de código aisladas. Un agente de programación puede trabajar dentro de un proyecto, inspeccionar su estructura, modificar archivos, ejecutar comandos y observar el resultado. Este ciclo de retroalimentación permite que el sistema continúe después de la primera respuesta.

La distinción importa para un creador sin conocimientos técnicos. Copiar código entre un navegador y un editor exige saber dónde pertenece cada fragmento. Un agente puede localizar los archivos pertinentes y coordinar cambios en la interfaz, el servidor, la base de datos y la configuración.

Kimi describe su cliente de línea de comandos como un agente que puede leer y modificar código, buscar archivos, ejecutar comandos de shell y revisar su plan a partir de la retroalimentación. Su actual guía de Kimi Code también explica cómo el cliente puede generar un archivo AGENTS.md después de analizar un proyecto.

Ese archivo actúa como contexto operativo para el agente. Puede registrar la estructura del proyecto, los comandos de compilación, las convenciones y otras instrucciones que deben persistir entre tareas. El agente obtiene un mapa en lugar de tratar cada prompt como una solicitud aislada.

Qwen Code sigue un modelo similar. Su descripción general del agente describe una herramienta de terminal que convierte instrucciones de producto en código y admite el uso mediante scripts no interactivos. También puede conectarse a través de varias opciones de autenticación y proveedores de modelos.

Estos productos representan un cambio más amplio en la interfaz del desarrollo de software. El usuario describe comportamientos, restricciones y criterios de aceptación. El agente traduce esa intención en archivos, comandos y pruebas.

Sin embargo, el lenguaje natural no es una especificación completa. Una solicitud como «crear un portal de clientes» deja sin respuesta preguntas críticas. No dice nada sobre la recuperación de cuentas, los permisos de acceso, la retención de datos, los pagos fallidos, los registros de auditoría o la prevención de abusos.

Un ingeniero con experiencia detecta estas lagunas porque se parecen a fallos anteriores. Un principiante suele ver la interfaz visible y asumir que el sistema está casi terminado. Los agentes de programación reducen el tiempo de implementación, pero también pueden ocultar decisiones pendientes detrás de una pantalla pulida.

La guía china obtenida de AIHOT refleja bien este nuevo flujo de trabajo. Presenta modelos nacionales, incluidos Kimi, GLM y Qwen, como vías accesibles desde una idea hasta un producto en línea. Su consejo más sólido aparece cerca del final: un creador puede evitar escribir código, pero no puede evitar comprender la arquitectura.

Esa distinción debe definir cualquier tutorial serio de Kimi vibe coding. El agente puede realizar tareas, mientras que el ser humano sigue siendo responsable de definir el sistema y juzgar si funciona.

Una especificación de producto debe preceder al primer prompt

Una idea vaga produce una demostración convincente, mientras que una especificación acotada da al agente la oportunidad de producir un producto operable.

El primer entregable no debe ser código. Debe ser una breve especificación de producto que abarque usuarios, tareas, datos, permisos, estados de fallo y criterios de éxito. Este documento se convierte en la referencia cuando el agente empieza a hacer suposiciones.

Empiece con un usuario y una tarea. «Los trabajadores autónomos necesitan convertir notas de reuniones en seguimientos para clientes» es más práctico que «crear una plataforma de productividad con IA». La declaración más acotada identifica una entrada, una transformación y una salida.

A continuación, defina el recorrido completo más pequeño. Un usuario crea una cuenta, importa una nota, revisa un seguimiento generado, lo edita y exporta el resultado. Cada paso debe incluir lo que ve el usuario y qué sucede cuando falla la acción.

Los datos merecen su propia sección. Enumere cada tipo de información que almacena la aplicación, de dónde procede, quién puede leerla y cuándo debe eliminarse. Los documentos sensibles requieren salvaguardas diferentes de los datos de catálogo públicos.

Los permisos también necesitan un lenguaje explícito. Un administrador, un usuario habitual y un visitante anónimo no deberían compartir las mismas capacidades. Si el producto admite equipos, especifique si los miembros pueden ver los registros de los demás y quién puede revocar el acceso.

Después, defina el sistema como varios componentes:

• La interfaz muestra pantallas, formularios, navegación y retroalimentación.

• El servicio de aplicación aplica las reglas de negocio y coordina las solicitudes.

• La base de datos almacena usuarios, registros, permisos y estado.

• La autenticación verifica la identidad y controla las sesiones.

• Los servicios externos proporcionan correo electrónico, pagos, inferencia de IA o almacenamiento de archivos.

• El alojamiento hace que la aplicación esté disponible y proporciona registros, redes y copias de seguridad.

Un principiante no necesita conocer cada detalle de implementación antes de empezar. Sí necesita reconocer estos componentes y preguntar dónde reside cada responsabilidad. De lo contrario, el agente puede combinar silenciosamente asuntos no relacionados en código frágil.

El modo de planificación es útil en esta etapa. En lugar de pedirle al agente que construya de inmediato, pídale que inspeccione la especificación, identifique las decisiones que faltan, proponga una arquitectura y divida el trabajo en hitos.

El plan del agente debe nombrar las principales entidades de datos, rutas, dependencias y estrategia de pruebas. También debe indicar las suposiciones. Las suposiciones ocultas se vuelven costosas una vez que varias funciones dependen de ellas.

Pida al agente que describa la arquitectura sin código. Si la explicación sigue siendo confusa, el producto no está listo para una implementación autónoma. Rehaga el plan hasta que pueda explicar el flujo de solicitudes en lenguaje sencillo.

Los prompts útiles definen evidencia, no entusiasmo. «Añade inicio de sesión» está incompleto. «Añade inicio de sesión por correo electrónico, rechaza sesiones expiradas, impide que los usuarios accedan a los registros de otra cuenta y escribe pruebas para estos casos» crea requisitos observables.

La misma disciplina se aplica al trabajo de interfaz. Describa los estados vacíos, los estados de carga, los errores de validación, las pantallas pequeñas, la navegación con teclado y las acciones destructivas. Un panel generado que solo maneja datos ideales sigue siendo una maqueta.

Los creadores pueden conservar los requisitos, las notas de fuentes, las decisiones sobre modelos y las observaciones de pruebas dentro de un flujo de trabajo de IA. Este contexto se vuelve valioso cuando un agente pregunta por qué se tomó una decisión arquitectónica anterior.

Una especificación cambiará durante el desarrollo. Eso es normal. La regla importante es actualizar el documento fuente antes de pedirle al agente que implemente la nueva dirección.

El tutorial de Kimi Vibe Coding: del plan a una compilación funcional

El flujo de trabajo agéntico más seguro utiliza hitos pequeños y verificables en lugar de un único prompt que solicita una aplicación completa.

Crea el proyecto en un repositorio con control de versiones antes de que comience la implementación principal. El control de versiones registra los cambios como commits, lo que permite a quien desarrolla comparar revisiones y recuperar un estado anterior. El commit inicial debe contener la especificación y una estructura mínima del proyecto.

Pide al agente que proponga una pila tecnológica basada en la simplicidad operativa. La respuesta debe explicar por qué existe cada componente, cómo se desplegará y qué alternativas se descartaron. Evita elegir un framework solo porque el modelo lo generó primero.

El primer hito debe establecer la estructura de la aplicación. Incluye el comando de desarrollo, la configuración del entorno, la navegación básica, una comprobación de estado y un comando de pruebas. Ninguna funcionalidad de negocio debe avanzar hasta que otro entorno limpio pueda ejecutar esa estructura.

El segundo hito debe implementar el modelo de datos principal. Pide al agente que muestre las entidades, sus relaciones y las reglas de propiedad antes de generar migraciones. Una migración es un cambio controlado en la base de datos que puede aplicarse de forma coherente en todos los entornos.

Revisa el esquema en lenguaje sencillo. ¿Qué registro pertenece a qué usuario? ¿Qué ocurre cuando se elimina una cuenta? ¿Pueden dos registros hacer referencia accidentalmente a datos inexistentes? Las respuestas revelan si el modelo subyacente coincide con el producto.

El tercer hito añade autenticación y autorización. La autenticación responde quién es el usuario. La autorización responde qué puede hacer ese usuario. Muchas aplicaciones generadas implementan la primera mientras tratan la segunda como una cuestión de interfaz.

La autorización debe ser aplicada por el servidor en cada operación protegida. Ocultar un botón no es control de acceso. Un usuario malicioso o curioso puede enviar solicitudes sin utilizar la interfaz prevista.

El cuarto hito implementa un recorrido completo del producto. Resiste la tentación de añadir páginas de configuración, paneles de analítica o refinamientos visuales antes de que funcione la ruta principal. Un segmento vertical limitado expone los problemas de integración antes.

Después de cada tarea, exige al agente que resuma:

• Los archivos que modificó

• El comportamiento que añadió

• Las suposiciones que hizo

• Las pruebas que ejecutó

• Las pruebas que aún necesitan juicio humano

• Cualquier consecuencia de seguridad o despliegue

Ejecuta la aplicación después de cada hito. Prueba primero el comportamiento esperado y luego haz un uso indebido de ella. Envía formularios vacíos, entradas demasiado grandes, solicitudes duplicadas, sesiones caducadas, URL no válidas y el identificador de registro de otro usuario.

Cuando algo falle, informa del comportamiento observado en lugar de pedirle al agente que «arregle todo». Incluye el comando, el resultado esperado, el resultado real y la salida de registro pertinente. Los comentarios precisos ayudan al modelo a distinguir un defecto de un requisito malentendido.

No aceptes reescrituras amplias como respuesta predeterminada a un error local. Pide una explicación de la causa raíz y un parche mínimo. Los cambios grandes generados son más difíciles de revisar y pueden eliminar comportamientos que sí funcionan.

Haz un commit después de cada hito verificado. Utiliza descripciones que indiquen el cambio en el producto, no el historial de la conversación. Un historial limpio te permite volver a un estado conocido cuando un agente introduce varios errores relacionados.

Inicia una sesión nueva del agente cuando el contexto se vuelva confuso. Proporciona a la nueva sesión la especificación, la arquitectura, el hito actual y el estado verificado del repositorio. Las conversaciones largas pueden conservar suposiciones desactualizadas después de que el producto haya cambiado.

Este enfoque por etapas parece más lento que la generación de una sola vez. En la práctica, reduce el costoso ciclo en el que una aplicación pulida se derrumba durante el despliegue. El objetivo no es la máxima producción de código por prompt, sino el máximo progreso verificado por cambio.

El despliegue convierte una demostración en un sistema operativo

Poner algo en marcha añade responsabilidades de infraestructura, identidad, regulación y recuperación que el agente de programación no puede asumir personalmente.

Una aplicación local se ejecuta en una máquina bajo condiciones favorables. Un despliegue público recibe tráfico impredecible, solicitudes malformadas, análisis automatizados y datos reales de usuarios. Ese entorno cambia el significado de «funcionar».

Separa los entornos de desarrollo y producción. El desarrollo es el espacio para experimentar. Producción es el sistema del que dependen los usuarios reales. No deben compartir la misma base de datos, credenciales ni acceso administrativo sin restricciones.

Almacena la configuración mediante variables de entorno o un servicio gestionado de secretos. Nunca coloques contraseñas de bases de datos, claves de API o secretos de firma dentro de archivos de código fuente. Pide al agente que examine el historial del repositorio en busca de credenciales accidentales antes del lanzamiento.

Elige el alojamiento según los componentes de la aplicación. Una interfaz estática, un servidor de ejecución prolongada, una tarea programada y una base de datos relacional tienen requisitos diferentes. El plan de despliegue debe identificar cómo se inicia, se comunica, registra errores y se reinicia cada componente.

Un dominio añade otra capa. Sus registros DNS dirigen a los usuarios hacia el servicio de alojamiento, mientras que TLS cifra las conexiones. El producto también necesita una estrategia para redirigir formas alternativas del dominio y renovar certificados.

Los productos alojados dentro de China continental pueden enfrentarse a obligaciones adicionales de registro. Las normas revisadas de China sobre registro ICP establecen que los servicios no comerciales de información por internet prestados dentro del país deben completar los procedimientos de registro.

Las normas también indican que las solicitudes completas deberían recibir una decisión de registro en un plazo de 20 días hábiles. Ese es un máximo regulatorio, no una promesa de que cada lanzamiento terminará en un calendario fijo. Quienes desarrollan deben tratar el registro como una línea de trabajo temprana.

La obligación exacta depende del servicio, la modalidad de alojamiento, el modelo de negocio y la jurisdicción. Un agente de programación puede organizar los requisitos, pero no puede proporcionar una autorización legal con autoridad. Consulta al proveedor pertinente y a asesores jurídicos cualificados cuando el alcance sea incierto.

El despliegue también necesita controles de migración de bases de datos. Haz una copia de seguridad de los datos de producción antes de aplicar un cambio destructivo. Prueba la migración con datos representativos y documenta cómo revertirla.

Crea una lista de verificación de lanzamiento que cubra el éxito de la compilación, las pruebas automatizadas, las comprobaciones de seguridad, las migraciones, la configuración, la monitorización y la reversión. Cada elemento debe producir evidencia, en lugar de una garantía verbal del agente.

Los registros deben responder qué falló, cuándo falló y qué operación se vio afectada. No deben exponer contraseñas, tokens, documentos privados ni información personal innecesaria. Registrar más datos no es automáticamente más seguro.

La monitorización debe cubrir la disponibilidad básica, los errores del servidor, la latencia, las tareas en segundo plano fallidas y los límites de almacenamiento. Una alerta necesita un responsable humano y una vía de respuesta. Una notificación que nadie entiende solo es ruido adicional.

Las copias de seguridad necesitan pruebas de restauración. Un trabajo de copia de seguridad exitoso demuestra que los datos se copiaron en algún lugar. No demuestra que el producto pueda recuperarse dentro de un período aceptable.

Antes de invitar a usuarios, crea una ruta de reversión. Esto puede significar restaurar la versión anterior, desactivar una nueva función o revertir una migración. El equipo debe saber qué acción se aplica a cada fallo probable.

Aquí es donde la descripción «sin código» se vuelve engañosa. Quien desarrolla puede no escribir la implementación, pero aun así opera un sistema con responsabilidades técnicas y organizativas.

El código generado por IA necesita protección de ramas y pruebas adversariales

La confianza de un agente no es evidencia de que un producto sea seguro, correcto o esté listo para producción.

La encuesta de desarrolladores de Stack Overflow de 2025 encontró una clara brecha de confianza respecto al resultado de la IA. Aunque el 84 por ciento de las personas encuestadas utilizaba o planeaba utilizar herramientas de IA, el 46 por ciento desconfiaba de su precisión. Solo el 33 por ciento expresó confianza.

La misma encuesta de desarrolladores descubrió que el 66 por ciento se sentía frustrado por soluciones de IA que eran casi correctas. Otro 45 por ciento identificó la depuración lenta del código generado como una frustración importante.

Estas cifras no demuestran que los agentes de programación carezcan de valor. Demuestran por qué la verificación debe escalar con la adopción. Una generación más rápida puede crear una mayor carga de revisión cuando los cambios se extienden por partes desconocidas de un sistema.

Protege la rama principal después de la configuración inicial del proyecto. La función de GitHub de protección de ramas puede exigir solicitudes de extracción, comprobaciones de estado aprobadas, discusiones resueltas o revisiones aprobatorias antes de fusionar un cambio.

Un creador individual aún puede beneficiarse de esta estructura. El agente trabaja en una rama separada, se ejecutan comprobaciones automatizadas y el creador revisa el resumen antes de fusionar. La pausa crea un límite entre la generación y el lanzamiento.

Como mínimo, la canalización automatizada debe instalar dependencias desde un archivo bloqueado, compilar la aplicación, ejecutar pruebas y realizar comprobaciones orientadas a la seguridad. Un fallo debe bloquear la fusión en lugar de convertirse en una advertencia enterrada en los registros.

Las pruebas deben funcionar en varios niveles:

• Las pruebas unitarias verifican reglas de negocio aisladas.

• Las pruebas de integración verifican la comunicación con bases de datos y servicios externos.

• Las pruebas de extremo a extremo ejercitan recorridos completos de usuarios.

• Las pruebas de autorización confirman que una cuenta no puede acceder a los datos de otra cuenta.

• Las pruebas de migración verifican que los cambios de esquema preserven los registros existentes.

• Las pruebas manuales examinan la usabilidad, los resultados ambiguos y el comportamiento inesperado.

Pide al agente que escriba pruebas antes de corregir un defecto confirmado. La prueba que falla captura el problema y reduce la posibilidad de que vuelva. Luego exige que la misma prueba se apruebe después del parche.

La seguridad requiere una revisión independiente de modelado de amenazas. Un modelo de amenazas identifica activos valiosos, posibles atacantes, puntos de entrada expuestos y usos indebidos probables. Convierte «hazlo seguro» en un conjunto de preguntas concretas.

¿Qué sucede si un usuario modifica un identificador en una solicitud? ¿Puede el contenido cargado ejecutar código? ¿El servidor obtiene URL externas? ¿Los intentos repetidos de contraseña pueden continuar sin límites? ¿Las rutas administrativas verifican los roles en el servidor?

OWASP advierte que los sistemas generados por IA o desarrollados por ciudadanos pueden reutilizar componentes vulnerables e incluso hacer referencia a paquetes inexistentes. Sus directrices sobre componentes no confiables recomiendan tratar las dependencias generadas como elementos que requieren verificación.

Inspecciona cada nueva dependencia. Confirma que el paquete exista, provenga del publicador esperado, reciba mantenimiento y cumpla un propósito necesario. Un nombre de paquete plausible no prueba su legitimidad.

Usa un archivo de bloqueo de dependencias y evita paquetes innecesarios. Menos dependencias reducen el número de componentes externos que pueden fallar, cambiar de propietario o introducir vulnerabilidades.

El código de autenticación generado merece un escrutinio especial. El almacenamiento de contraseñas, la gestión de sesiones, los flujos de restablecimiento, la configuración de cookies y las comprobaciones de autorización contienen detalles sensibles para la seguridad. Prefiere implementaciones establecidas y documentadas en lugar de lógica personalizada.

Nunca uses datos reales de clientes durante las pruebas iniciales. Genera registros sintéticos que se parezcan a la estructura necesaria sin exponer información personal. Limita el acceso a producción incluso cuando solo una persona opere el proyecto.

Las funciones de IA crean riesgos adicionales. Si el contenido del usuario entra en un prompt de modelo, trata ese contenido como no confiable. Puede intentar anular instrucciones, revelar contexto oculto o activar herramientas no deseadas.

Un agente con acceso a archivos y comandos también tiene privilegios locales importantes. Revisa las acciones solicitadas, restringe las credenciales y evita conceder acceso a producción durante el desarrollo habitual. La comodidad no debe eliminar los límites operativos.

Un fundador no técnico debe organizar una revisión independiente antes de lanzar un producto que gestione dinero, información de salud, documentos confidenciales o datos de identidad sensibles. El agente que generó el código no debe ser el único revisor de su propio trabajo.

Qué deben vigilar los creadores después del lanzamiento

La prueba decisiva de la programación por vibras no es si un agente puede publicar la versión uno, sino si el humano puede operar la versión dos.

La primera señal es la fiabilidad de los cambios. Haz seguimiento de la frecuencia con la que una función solicitada supera las pruebas, llega a producción y permanece activa sin reversión. Las reversiones frecuentes sugieren que la arquitectura o el proceso de verificación no pueden respaldar la velocidad del agente.

La segunda señal es la responsabilidad ante incidentes. Cuando aparece una alerta, el creador debe identificar el componente afectado, inspeccionar los registros relevantes y explicar la ruta del fallo. La dependencia total de la respuesta de otro agente deja al producto sin un diagnóstico responsable.

La tercera señal es la portabilidad entre modelos. Kimi, Qwen, GLM y otros sistemas de programación seguirán cambiando sus clientes, modelos, métodos de autenticación y límites. Un repositorio con documentación clara y herramientas estándar puede moverse entre agentes más fácilmente.

La portabilidad entre modelos no significa que todos los agentes produzcan código idéntico. Significa que los requisitos, la arquitectura, los comandos y las pruebas del proyecto son lo bastante explícitos para que otra herramienta o ingeniero pueda continuar el trabajo.

Los creadores también deben vigilar la brecha entre el resultado visible y la calidad operativa. Las nuevas pantallas de interfaz son fáciles de demostrar. Menores tasas de error, migraciones más seguras, una recuperación más rápida y permisos más claros son menos visibles, pero más importantes.

Por ello, este tutorial de programación por vibras con Kimi termina con una definición diferente de éxito. El éxito no es llegar a una URL activa sin tocar un lenguaje de programación. Es llegar a un sistema activo cuyo comportamiento, datos, riesgos y ruta de recuperación puedas explicar.

Comienza con un recorrido de usuario y escribe sus requisitos antes de abrir el agente de programación. Haz que el agente planifique, implemente un hito y proporcione evidencia de las pruebas. Confirma solo cambios verificados y luego crea controles de implementación y recuperación antes de invitar a usuarios reales.

Si no puedes explicar dónde se verifica la identidad, dónde residen los datos o cómo se revierte un lanzamiento fallido, pausa el lanzamiento. Pide al agente que trace esos sistemas hasta que las respuestas sean claras. La programación por vibras puede reducir el costo de implementación, pero no puede transferir la responsabilidad del producto a un modelo.