#3 - Vibecoding en un proyecto real: lo bueno y lo malo
Mi experiencia construyendo una app para iOS sin conocimientos previos, usando Codex y Claude Code
Uno de mis objetivos del 2025 era construir una app para iOS que me bloqueara las distracciones hasta completar una serie de tareas. Empecé en enero, pero por falta de tiempo y motivación lo dejé.
A final de año, con los avances de los LLMs, decidí darle otra oportunidad y empecé a construir Deep Focus utilizando principalmente Claude Code y Codex.
Desde el primer momento noté una mejora enorme en estas herramientas para este caso concreto. Lo que a principios de año les costaba, ahora lo resolvían en un prompt. Gracias a eso, conseguí publicar la app a finales de diciembre.
Pero no todo fue un camino de rosas. Surgieron muchos inconvenientes (y mucha deuda técnica) que también quiero contar aquí. No va a ser un post ni pro ni anti IA, simplemente una experiencia real construyendo un side project desde cero.
La IA acelera, y mucho
Esto es innegable. Los avances son increíbles, y gracias a ello pude crear una app sin tener experiencia previa en iOS. Sin la inteligencia artifical habría tenido que formarme bastante o seguir la documentación oficial paso a paso. Habría tardado horas en tener la pantalla de tareas básica.
Con Claude Code tenía una app de gestión de tareas funcionando en mi iPhone en cuestión de minutos. Es cierto que no era nada excesivamente complejo, pero el ahorro de tiempo fue enorme.
El primer problema: la tecnología elegida
Delegué en la IA la tecnología para este proyecto. Le dije que en principio quería sacarla para iOS, y si a la gente le gustaba me plantearía sacarla para Android más tarde. También añadí que no tenía experiencia desarrollando en iOS, pero que sí tenía experiencia con JS / TS y algo de react.
Teniendo eso en cuenta, la tecnología elegida fue React Native. Y al principio todo fue genial. Podía entender el código sin problema y hacer mis ajustes si era necesario. Probé a desplegarla en Android por curiosidad y funcionaba igual de bien.
El problema vino a la hora de desarrollar los widgets y el bloqueo de aplicaciones. Esta funcionalidad depende de lógica nativa, no se puede desarrollar únicamente en React Native.
Al principio pensé que sería necesaria poca lógica en Swift. Pero el respositorio tiene actualmente un 30% de código nativo. Si implemento soporte para Android (suponiendo los mismos porcentajes, por simplificar), tendría menos de un 50% del código en React Native.
Viéndolo con perspectiva, si hubiera sabido esto desde el principio habría desarrollado la app directamente en Swift. Me habría ahorrado muchos problemas y, sobre todo, la complejidad añadida de la comunicación entre React Native y código nativo.
Pero me fié a ciegas de la decisión de Claude Code, que a pesar de tener todos los requisitos y de comentarle las funcionalidades nativas que necesitaba, decidió tirar por el modelo híbrido.
En este caso es “solo” un side project y el impacto es limitado. Pero en una empresa, esto puede significar mucho tiempo y dinero invertido. La velocidad inicial puede acabar siendo pan para hoy y hambre para mañana.
Mi mayor sufrimiento: Live Activities y background jobs
Tras recibir feedback de varios usuarios, decidí implementar un modo Pomodoro en Deep Focus.
La idea era sencilla: implementar un temporizador en la app y utilizar Live Activities para que el usuario pudiera ver el tiempo que le quedaba desde fuera de la aplicación o la pantalla de bloqueo.
Yo no quería un simple icono de temporizador, como se ve en la anterior imagen. Quería poder pausar, reanudar y pasar a la siguiente fase directamente desde la Live Activity.
Claude Code implementó esta funcionalidad con pocos prompts. Y, al principio, parecía funcionar. Pero pronto me di cuenta de que era muy inestable. El botón de pausar a veces tenía efecto en la app, y a veces no, causando inconsistencias en el estado. Y esto era imposible de debuggear.
Ahí empezó una iteración de la cual no me siento muy orgulloso. Del estilo “pls fix make no mistakes”. Pasaron horas y horas, repartidas en varios días, y todo el código que la IA añadía no mejoraba la estabilidad del Live Activity.
La desesperación me llevó a la documentación oficial y a buscar problemas similares en Google. Para mi sorpresa, aprendí que las Live Activities no son realmente “Live”, y que 20-30 segundos después de que una app de iOS pase a background no se puede ejecutar código de manera fiable. Las tareas en background se ejecutan si el OS quiere, y no están garantizadas.
La inestabilidad que veía también era causada en parte por estar conectado al XCode, que mantiene la app “viva” más tiempo aunque esté en background. Al final, después de tanto trabajo, volví a la versión sin botones.
La IA como revisora
Como estaba en bucle con Claude Code, decidí probar con Codex. Le pedí que me revisara la implementación actual del Pomodoro e identificara la causa de los problemas que sufría.
Ahí es donde ví la primera señal de que quizás el problema no estaba en la implementación, si no en las limitaciones del sistema operativo. Codex mencionó varias restricciones de los background jobs de iOS que encajaban perfectamente con lo que estaba viendo. Como ya he comentado, investigando en internet confirmé esa hipótesis.
A partir de ahí empecé a utilizar Codex como “revisor” de todo lo que escribía Claude Code. Al principio pensé que no sería tan útil, pero me sorprendió la cantidad de problemas y mejoras que fue capaz de detectar!
El bias por añadir código sin parar
Los LLM (especialmente Opus 4.5) han llegado a un punto en el que pueden construir software bastante top desde cero. Incluso, por experiencia en mi trabajo, operan decentemente en proyectos enormes. Algo que no esperaba que sucediera tan rápido.
El mayor problema que les veo ahora es que siguen teniendo un bias enorme en añadir código. Y eso es un gran riesgo a largo plazo si vibecodeas al 100% tu sistema, al menos por ahora.
Problemas que se podrían arreglar eliminando o reutilizando código suelen acabar siempre con Claude Code añadiendo decenas o cientos de líneas.
Esto me causó muchos dolores de cabeza en Deep Focus. El más grave fue la inconsistencia del estado de la app: en lugar de mantener un único single source of truth, se fueron añadiendo múltiples stores que luego había que sincronizar. La situación empeoró según crecía la app, especialmente al introducir módulos nativos para el Shield, los widgets y las Live Activities.
Esto fue mi culpa, por optimizar el “avance”, en lugar de mirar a largo plazo. Podría haber hecho un mayor esfuerzo en definir bien la arquitectura y las reglas del proyecto para que Claude Code tuviera ese contexto presente desde el principio.
Dónde la IA realmente brilla para un backender
Si eres backender y tienes las skills de front oxidadas como yo, probablemente estarás de acuerdo conmigo. Sin duda, el punto donde más me ha ayudado la IA es en mejorar la interfaz de usuario y en crear assets “bonitos”, como el logo de la app y otras imágenes.
Es cierto que las interfaces generadas por IA suelen ser bastante genéricas, pero para un side project es más que suficiente para dejarlo en un estado aceptable.
El problema de añadir mucho código sigue estando presente. Los ficheros de la pantalla de tareas y del pomodoro superan ambos las 2000 líneas de código, y estoy seguro de que podrían ser mucho más simples. Pero es un lugar menos crítico, no es el core de la aplicación, por lo que decidí darle mucha más libertad a la IA en este aspecto.
He aprendido “poco”
La IA ha bajado una barbaridad la barrera de entrada para programar. Sin experiencia previa en iOS, y con conocimientos básicos de React Native pude publicar mi side project en tres o cuatro semanas.
El problema es que el proyecto se convierte en una “caja negra”, donde la interfaz principal es el LLM. En ese proceso he aprendido bastante poco realmente. Ahora sé cómo funciona iOS un poco mejor, pero simplemente porque me vi forzado a investigar yo mismo sin depender de la IA.
Ahora mismo no sería capaz de crear ni una app básica desde cero, y mucho menos hacerlo de forma nativa en Swift. Para balancear aprendizaje y velocidad, tendría que haber revisado todo el output generado y haber entendido todas las decisiones tomadas.
Para aprender algo desde cero sigo prefiriendo los métodos tradicionales: libros, vídeos, documentación oficial y crear cosas a mano. Eso, con el apoyo de la IA, va a potenciar mucho tus habilidades.
Conclusión: el vibecoding acelera, pero no es gratis
De este side project saco muchas cosas positivas y varias lecciones claras sobre cómo usar estas herramientas en proyectos que realmente importen.
La IA acelera un montón el desarrollo, sobre todo al principio. Reduce muchísimo la fricción para empezar algo desde cero y es un apoyo enorme en temas de UX y diseño, especialmente si vienes del backend. En ese sentido, vibecodear es casi adictivo. Yo me lo he pasado como un niño construyendo Deep Focus.
Pero esa velocidad tiene un coste. Vibecodear sin control introduce complejidad y deuda técnica muy rápido, especialmente cuando no conoces bien la plataforma en la que estás trabajando. Además, si delegas todas las decisiones en la IA, el aprendizaje real es bastante limitado. Avanzas, pero entiendes poco lo que estás construyendo.
Mi conclusión es que la IA acelera mucho, pero no sustituye entender el sistema que estás construyendo.
"pls fix make no mistakes" is such a familiar situation :D
No te asusta como avanza tan rápido? Crees que sucederá que la ia pueda escribir código y revisarse a si misma y seguir mejorando este código?
Se que ahora aún se ocupan ingenieros de software, pero ya he estado viendo post, especialmente sobre Claude code que hablan de como construye cosas y pasa test de calidad