¿Hasta dónde se puede desarrollar con vibe coding?
(github.com/delos-cresco)Es una retrospectiva centrada más en lo técnico y en el lado de la implementación que en el producto en sí.
Son opiniones completamente personales.
¡Tomen en cuenta que fue un proyecto desarrollado mientras aprendía durante el último año de universidad!
Por qué empecé este proyecto
- Desarrollar un producto con la mentalidad de crear una startup, desde la perspectiva de PM/PO
- Evaluar si realmente es posible desarrollar un MVP full-stack con Claude Code
- Resolver el problema de descubrir oportunidades de inversión en acciones
- Adoptar activamente productos comerciales y obtener insights en ese proceso
Cronograma del proyecto e información adicional
- Planeación + desarrollo: 1 mes
- Despliegue: 1 semana
- Operación: 2 meses
- Monto invertido
- Claude Code: 100 USD
- Cuenta de desarrollador de Apple: 100 USD
- AWS: aprox. 220 USD
- Managed DB: aprox. 300 USD
- Free tier: Datadog, Langfuse, Posthog
- Publicidad: 40,000 KRW
- Total: aprox. 1,000,000 KRW (de mi bolsillo..)
Proceso de desarrollo
Frontend
- Definición de design tokens
- Implementación de 3 páginas clave en Figma
- Aplicación de design tokens en Expo e implementación usando Figma MCP
- Se intentó usar Expo MCP, pero como no era estable, se depuró viendo directamente los resultados
- Generación de nuevas páginas sin wireframe en Figma usando prompts como “usa design tokens y toma prestado el concepto de diseño de otras páginas…”
Backend
- Se pidió desarrollar APIs a partir de los requisitos
- Se pidió crear también los endpoints necesarios con base en los requisitos del frontend
- Al usar Django, un stack genérico, fue posible desarrollar con Claude Code sin cuellos de botella en la implementación
AI
- Se pidió definir una arquitectura multiagente e implementarla con base en ella
- Para adaptarse a las especificaciones más recientes de LangChain y LLMOps, se adjuntaron enlaces web como referencia
- Se usaron prompts generados por un LLM para el propio servicio LLM
Observability
- Construcción inicial sobre ClickStack y posterior migración a Datadog
- Aplicación de logging y analytics después de desarrollar todo el sistema
Infra
- Al principio se quiso usar Pulumi, pero como Claude Code no lo manejaba bien, se prepararon archivos de despliegue generando scripts basados en AWS CLI
- Por costos, no se construyeron CI/CD ni Dev Server
Lista de tecnologías adoptadas
- Servicio: suscripciones/pagos, social login, dark mode
- Datos: recolección de datos basada en API, CDC, ETL
- AI: multiagente, Text-to-SQL, Agentic RAG, streaming por SSE, gestión de sesiones, retry, rate limit
- LLMOps: AB Test, Cloud Based Prompt Management (OTA Update), Synthetic Dataset, Evaluation
Insights
Implementación
- Con el plan de 100 USD de Claude Code durante aproximadamente 1 mes, pude crear por mi cuenta un producto de este volumen
- Implementé la UI definiendo solo el estándar de design tokens; si además hubiera implementado un design system y lo hubiera incorporado en Claude.md, habría sido posible desarrollar un frontend más rápido y estable
- La importancia del design system. Mejora muchísimo la productividad del desarrollo frontend. Es más rápido implementar primero y luego corregir que hacer Figma desde el inicio. De hecho, hay páginas implementadas que no existen en Figma.
- Definición de casos excepcionales. Es todavía más importante en apps móviles y sistemas de AI. Hay que planear e implementar casos que no sean happy path, como la gestión general de timeouts del sistema, políticas de background, recuperación de streaming y errores simples. A veces Claude Code implementa el manejo de errores por su cuenta, pero no los resuelve de manera realmente limpia integrando frontend y backend. Por eso, estas partes hay que pedirlas explícitamente a Claude Code para resolverlas.
- Prohibido hacer refactors grandes. Al inicio puse todo el código de React y CSS en un solo archivo del frontend, e intenté refactorizarlo para separarlo. El resultado fue un fracaso. Sí se separó, pero la UI terminó distinta a la original, y al final tuve que ir dividiéndolo poco a poco. Parece necesario pensar en la arquitectura del código desde el comienzo y, si se van a usar componentes, incluir esa información en el prompt para aprovecharlos bien.
- Uso de Claude.md. Después de desarrollar una funcionalidad, le pedía a Claude Code que agregara a Claude.md lo que valía la pena guardar con base en ese trabajo. Como el archivo fue creciendo, luego le pedí que dejara solo lo realmente necesario y eliminara el resto. Usar adecuadamente readme y claude.md ayuda a controlar el contexto del LLM. (era antes de que existieran skills)
- No utilicé subagentes. Como funcionaba bien sin ellos, no los usé. Simplemente pedía en modo Plan hasta concretar el diseño del desarrollo, y cuando ya era suficiente dejaba que el Agent desarrollara de forma autónoma.
- Conviene definir y comunicar de antemano los paquetes y tecnologías. Es mejor trabajar especificando con precisión Claude.md, el Readme o cierta spec, para evitar código duplicado o situaciones en las que se termine usando otro stack distinto. (¿Skills?)
Sistema de AI
- ReAct es lento. La UX es pésima. Aunque configuré la ejecución paralela de multiagentes, sigue siendo demasiado lento.
- UX. Para resolver la lentitud de las respuestas introduje una UX que muestra los pasos del multiagente, streaming, animaciones y renderizado dinámico de Markdown. Pero si una respuesta tarda 1 minuto, ¿de qué sirve?... (app B2C)
- Gestión de prompts y esquemas de herramientas basada en la nube. Es muy bueno poder aplicarlo en un entorno online. Ahora me parece indispensable y amo Langfuse.
- En Text-to-SQL hay que poner el esquema dentro del prompt. En ese momento consume demasiado contexto. Creo que podría resolverse con fine-tuning o RAG.
- Evaluación e iteration. Construí Synthetic Datasets por user persona y evalué con LLM-as-a-Judge. Quisiera automatizarlo, pero de nuevo, para hacerlo solo faltan recursos de desarrollo.
- Métricas de evaluación y rúbricas: son más problemáticas de lo que parecen. Creo que las métricas genéricas son cosas como DAU y MAU. Con ese tipo de métricas no se pueden obtener insights. Hay que definir métricas caso por caso para distinguir ejemplos de baja calidad, resolverlos y luego hacer iteration. Al final, se necesita un sistema que ayude a crear buenas métricas personalizadas. (¿y el multi-turn?..)
- El tier de OpenAI es más ajustado de lo que esperaba. En esos tiers bajos no se pueden usar buenos modelos en operación.
Infraestructura
- AWS es caro, Managed DB es caro. Son buenos, pero me arrepiento
- Clickhouse es muy caro, pero muy bueno. Al usar la versión managed es cómodo, especialmente porque incluso CDC viene de una vez. (¿de qué sirve que sea rápido si el LLM es lento?)
- Qdrant y Redis Cloud tampoco están mal. Toma poco tiempo montarlos y el costo también es bajo.
- Datadog. Es buenísimo. Eso sí, como iba a salir caro, solo usé el free tier. En especial, la función que reúne y notifica por separado los errores que ocurren es excelente. Lo usé poniendo el agente como sidecar en ECS.
Servicio
- Pagos y suscripciones. Consideré usar Toss Pay, pero no lo usé. Primero, porque hay que pagar una cuota anual, y además no hay documentación para React Native, así que el SDK deja mucho que desear. Me decepcionó bastante. Al final elegí Nice Payments. No tiene cuota anual y además tiene servidor de desarrollo, así que se pudo desarrollar sin mayor problema.
- Pagos de Apple. Aunque usé Nice Payments, hay un problema. La política de pagos de Apple es estricta. Durante el desarrollo en iOS hubo temas relacionados con las políticas de Apple, y fue necesario resolverlo tanto con documentación diversa como a nivel de UI. Siento que usar simplemente el sistema interno de pagos de Apple sería más tranquilo.
- Pago y suscripción (cobro automático) no son lo mismo. Para implementar el cobro automático se necesita infraestructura de scheduling y también poner atención a la seguridad para almacenar card keys. Al final lo implementé, pero fue más complicado de lo esperado. Me dieron ganas de probar Stripe.
- Push notifications. En Expo se pueden montar cómodamente. Al final hace falta un back office para enviar mensajes, pero creo que es una funcionalidad indispensable.
Algunas ideas
- Parece que va a crecer la importancia de los patrones de diseño de software y de la arquitectura.
- Me gustaría que creciera el interés de la gente en crear resultados que vayan más allá de toy projects usando coding agents.
- Evitemos el overengineering. Pero, para conseguir trabajo, ¿no hay que conocer también el overengineering? La próxima vez quizá sea mejor terminar todo con
docker-composeen una sola instancia… (¿con Supabase?) - La era del emprendimiento en solitario ya casi llegó. Pero creo que ganar dinero y construir algo son cosas distintas.
- Hacerlo solo no es divertido
- Linear también está bien para usarlo en lugar de Jira. Como es mi primera vez usándolo, todavía no entiendo bien cómo ver agrupados los tickets según su jerarquía.
Resultado
- El proyecto se cerró porque no pude sostener el costo de los servidores.
- Saldo: -100
Referencia
Hay contenido adicional a partir de la página 4.
8 comentarios
Saldo -100
jaja
Gracias por compartir contenido tan bueno.
Debe de ser una experiencia de más de un millón de wones. Yo también recuerdo que en mi último año de universidad no tenía mucha experiencia en proyectos. Es realmente impresionante que hayas logrado implementar algo así usando IA.
Compartir experiencias es muy divertido. Lo leí con mucho gusto. Resulta que incluso eras un compañero menor de mi alma mater, wow. Hoy en día, ¿de verdad en cuarto año también se animan a intentar este tipo de desafíos? Está increíble.
Tal vez fue algo sobreingenierizado con fines de aprendizaje, pero el costo da mucha pena.
Está muy bien hecho.
Últimamente, la calidad de los portafolios de los universitarios está impresionante. Cuando yo me gradué hace 20 años, siento que me gradué sin saber realmente nada; es admirable.
La IA elevó muchísimo el nivel general.
Ahora hasta parece que la mejor respuesta es simplemente contratar a alguien buena onda de verdad jajaja