Vibe coding vs. desarrollo profesional asistido por IA en salud: diferencias y límites

Crear una primera aplicación ya no requiere necesariamente meses de desarrollo. Con herramientas como ChatGPT o Claude es posible describir una idea, generar código, construir pantallas, conectar una base de datos y obtener en poco tiempo una versión que parece funcionar.

Eso ha abierto una oportunidad enorme para emprendedores, startups y organizaciones sanitarias. Hoy es mucho más fácil probar una idea antes de realizar una inversión mayor.

Sin embargo, utilizar IA para desarrollar no significa trabajar siempre de la misma manera. El vibe coding y el desarrollo profesional asistido por IA pueden apoyarse en herramientas similares, pero se diferencian en cómo se definen los requisitos, la arquitectura, las revisiones, las pruebas y la responsabilidad sobre el producto.

El problema aparece cuando una demo funcional se confunde con un producto preparado para usuarios reales.

Cuando hablamos de producción nos referimos al entorno real en el que una aplicación ya está desplegada y disponible para sus usuarios finales, a diferencia de los entornos de desarrollo o pruebas, donde el equipo construye y valida el producto antes de ponerlo en uso.

Una app creada mediante vibe coding puede ser un excelente punto de partida, pero llevarla a producción en salud exige revisar arquitectura, seguridad, tratamiento de datos, experiencia de usuario, integraciones, pruebas y posibles requisitos regulatorios.

No se trata de descartar el trabajo realizado ni de dejar de utilizar inteligencia artificial. Se trata de entender qué aporta cada forma de trabajo y cuándo un prototipo necesita evolucionar hacia un producto preparado para usuarios reales.

Qué es el vibe coding y dónde está su límite

El término vibe coding describe una forma de desarrollar software en la que gran parte de la programación se delega en herramientas de inteligencia artificial a través de instrucciones en lenguaje natural.

En lugar de escribir directamente cada componente, explicamos qué queremos conseguir:

• “Crea un registro de pacientes.”
• “Añade un formulario para introducir síntomas.”
• “Genera un dashboard con la evolución de cada usuario.”
• “Ahora permite que el profesional reciba una alerta cuando determinados valores superen un límite.”

La herramienta genera código, nosotros comprobamos el resultado y seguimos iterando.

Para experimentar es un cambio enorme. Permite construir una prueba de concepto, visualizar una idea y detectar rápidamente si un flujo tiene sentido.

En salud, por ejemplo, podemos tener en poco tiempo una primera versión de una app para registrar síntomas, realizar cuestionarios, gestionar citas o mostrar información a un profesional.

El límite aparece cuando evaluamos únicamente lo que vemos en pantalla.

Que una funcionalidad responda correctamente no nos dice si la arquitectura puede escalar, si los permisos están bien planteados, si los datos se almacenan correctamente o si el código seguirá siendo mantenible dentro de un año.

Y en un producto sanitario o relacionado con la salud, esas preguntas importan tanto como la funcionalidad visible.

Vibe coding y desarrollo profesional asistido por IA no son lo mismo

Este matiz es especialmente importante.

Utilizar inteligencia artificial para programar no convierte automáticamente un proyecto en vibe coding.

En GooApps® utilizamos IA dentro de nuestros procesos de desarrollo. La diferencia está en que la herramienta trabaja dentro de un sistema previamente definido: requisitos, documentación, arquitectura, estándares, pruebas y revisión humana.

Nuestro estándar de agentes backend y frontend, por ejemplo, utiliza documentación como fuente de verdad, asigna responsabilidades específicas a cada agente y establece puntos de validación antes de continuar con el desarrollo.

La diferencia puede resumirse así:

La IA puede estar presente en ambos casos. Lo que cambia es el método.

Por qué una app que funciona todavía puede no estar preparada para producción

Durante un prototipo trabajamos en un entorno relativamente controlado.

Sabemos qué información vamos a introducir, conocemos el recorrido correcto y normalmente utilizan la aplicación muy pocas personas.

En producción ya no controlamos las condiciones de uso de la misma manera.

Los usuarios dejan formularios a medias. Pierden la conexión. Utilizan dispositivos diferentes. Intentan recuperar contraseñas. Dos personas acceden a la vez al mismo registro. Una integración externa deja de responder. Aparecen datos que nadie había contemplado.

Además, el producto debe poder actualizarse sin que cada modificación rompa otra funcionalidad.

Por eso existe una diferencia importante entre demostrar una idea y operar un producto.

Una demo responde principalmente a una pregunta:

¿Podemos hacer que esta idea funcione?

Un producto debe responder a varias más:

¿Está bien construido? ¿Puede utilizarse con seguridad? ¿Resuelve el problema correcto? ¿Puede mantenerse? ¿Puede integrarse? ¿Qué ocurre cuando algo falla?

Qué revisar antes de utilizar una app creada con IA en salud

La arquitectura y la mantenibilidad del código

Cuando desarrollamos mediante instrucciones sucesivas es fácil resolver necesidades de forma local.

Añadimos una pantalla. Después otra función. Luego pedimos corregir un error. Más tarde cambiamos la estructura de datos porque aparece una nueva necesidad.

Cada cambio puede funcionar por separado y, sin embargo, generar una arquitectura cada vez más difícil de entender.

Antes de continuar un prototipo conviene revisar cuestiones como:

• Organización del proyecto.
• Separación entre interfaz, lógica de negocio y datos.
• Dependencias utilizadas.
• Gestión de estados.
• Modelo de datos.
• APIs.
• Gestión de errores.
• Versionado.
• Cobertura de pruebas.
• Documentación.

La pregunta relevante no es si el código lo escribió una persona o una IA.

La pregunta es si otro equipo puede entenderlo, probarlo y evolucionarlo sin depender de la conversación en la que fue generado.

Seguridad y datos de salud

Aquí el margen de error es menor.

Una aplicación de salud puede gestionar síntomas, informes, medicación, fotografías, actividad física, resultados, conversaciones con profesionales o información procedente de dispositivos.

También puede almacenar datos identificativos junto a esa información.

Por eso no basta con proteger el acceso mediante usuario y contraseña.

Hay que revisar cómo se autentican los usuarios, qué permisos tiene cada perfil, dónde se almacenan las credenciales, cómo se protegen las APIs, qué información aparece en los logs, cómo se cifran las comunicaciones y qué ocurre con las copias de seguridad.

Además, las herramientas de programación asistida por IA actuales pueden tener capacidad para modificar archivos, ejecutar comandos, instalar dependencias o acceder a recursos del proyecto. OWASP recomienda establecer límites claros, revisar las acciones de los agentes y evitar introducir secretos o información sensible sin los controles adecuados.

La seguridad no debería aparecer como una revisión final. El Secure Software Development Framework de NIST plantea precisamente la integración de prácticas de seguridad dentro del propio ciclo de desarrollo.

La finalidad de la app puede tener implicaciones regulatorias

No todas las apps de salud son productos sanitarios.

Una aplicación orientada al bienestar general no tiene necesariamente las mismas obligaciones que una solución que realiza cálculos clínicos, genera información utilizada para diagnóstico o tratamiento o ayuda a tomar determinadas decisiones médicas.

Por eso una de las primeras preguntas debe ser:

¿Para qué se utilizará realmente este software?

En GooApps® contamos con una guía específica sobre regulación y normativa del software médico y las apps sanitarias. Como referencia institucional, la Comisión Europea actualizó en junio de 2025 la guía MDCG 2019-11 rev.1 para la cualificación y clasificación de software bajo MDR e IVDR.

La finalidad prevista condiciona decisiones posteriores sobre riesgos, validación, documentación y desarrollo.

Descubrirlo cuando el producto está terminado puede obligar a modificar decisiones tomadas muchos meses antes.

La experiencia de usuario debe probarse fuera del prototipo

Una IA puede generar una interfaz visualmente correcta y un recorrido aparentemente lógico.

Eso no demuestra que sea adecuado para el usuario real.

Una persona que registra síntomas puede encontrarse cansada, preocupada o con dificultades para comprender determinada información. Un profesional sanitario puede consultar la aplicación entre múltiples tareas y necesitar identificar un dato relevante en segundos.

En salud, el diseño de la experiencia de usuario en aplicaciones médicas implica entender:

• Quién utiliza la aplicación.
• En qué momento lo hace.
• Qué información necesita.
• Qué errores puede cometer.
• Qué consecuencias tiene una mala interpretación.
• Qué nivel de accesibilidad requiere.
• Qué información debe destacar y cuál puede esperar.

Por eso el diseño debe contrastarse con usuarios representativos y no solo evaluarse desde el equipo que ha creado el producto.

Las integraciones cambian la complejidad del proyecto

Muchas demos funcionan de forma independiente.

Pero una aplicación real puede necesitar conectarse con:

• Sistemas de gestión clínica.
• Plataformas de cita.
• CRM.
• Servicios de identidad.
• Herramientas de comunicación.
• Wearables o dispositivos médicos.
• Sistemas de analítica.
• Pasarelas de pago.
• Plataformas internas de la organización.

En ese momento ya no basta con que una API “responda”.

Hay que definir autenticación, sincronización, gestión de errores, trazabilidad, formatos de intercambio y qué sistema actúa como fuente de verdad para cada dato.

Y eso debe diseñarse antes de empezar a encadenar conexiones.

Producción también significa saber qué hacer cuando algo falla

Esta parte suele quedar fuera del prototipo.

¿Qué ocurre si una integración deja de responder durante tres horas?

¿Y si una actualización genera un error?

¿Quién recibe una alerta cuando el servidor supera un determinado nivel de carga?

¿Cómo restauramos los datos?

¿Podemos volver a la versión anterior?

¿Cómo sabemos qué estaba haciendo un usuario cuando se produjo una incidencia?

Un producto no está preparado para producción solo porque funcione cuando todo va bien.

También debe estar preparado para detectar, contener y resolver los problemas cuando algo va mal.

¿Tienes una primera versión y no sabes si está preparada para producción?

Revisa tu proyecto

Qué parte de un prototipo creado con IA puede aprovecharse

Llegados a este punto aparece una preocupación bastante lógica:

¿Hay que empezar otra vez desde cero?

No necesariamente.

El valor de un prototipo no está solo en su código.

Durante su creación probablemente ya se han tomado decisiones, descartado funcionalidades y aprendido cosas sobre el producto que antes no estaban claras.

Puede haberse avanzado en:

• Flujos de navegación.
• Prioridades funcionales.
• Estructura inicial de pantallas.
• Hipótesis de negocio.
• Necesidades de usuarios.
• Integraciones necesarias.
• Modelo inicial de información.

También puede existir código perfectamente reutilizable.

La decisión debe tomarse después de analizar el proyecto.

En una auditoría de código podemos encontrarnos con tres escenarios:

Código que puede mantenerse

Los componentes tienen suficiente calidad, están bien estructurados y pueden incorporarse al producto definitivo con cambios menores.

Código que merece la pena refactorizar

La funcionalidad es válida, pero necesita reorganización, mejores pruebas, cambios de arquitectura o correcciones antes de continuar.

Código que resulta más eficiente sustituir

Mantenerlo generaría más coste y riesgo que reconstruir esa parte siguiendo una arquitectura adecuada.

Ninguna de estas situaciones implica que el prototipo haya sido una pérdida de tiempo.

Su función era precisamente ayudar a validar la idea y reducir incertidumbre.

Cómo pasar del prototipo a un producto preparado para crecer

En GooApps® planteamos los proyectos desde una visión que conecta producto, tecnología y contexto sectorial.

Cuando ya existe una primera versión, el proceso no empieza necesariamente desde cero. Empieza entendiendo qué tenemos delante.

Discover: entender qué se ha construido y para qué

Antes de corregir código necesitamos comprender el producto.

Analizamos el problema que intenta resolver, quiénes son los usuarios, cómo funciona actualmente el proceso, qué se ha validado y qué decisiones todavía están abiertas.

También identificamos desde el principio necesidades de integración, seguridad o regulación que puedan condicionar el producto.

El objetivo es evitar el error más costoso: mejorar técnicamente una solución que está resolviendo mal el problema.

Define: convertir prompts y decisiones dispersas en un producto definido

En muchos prototipos creados con IA existe mucho conocimiento, pero está repartido.

Parte está en el código. Parte, en conversaciones con ChatGPT o Claude. Parte, en la cabeza de la persona que lo creó.

Hay que convertir ese conocimiento en requisitos y decisiones explícitas.

Definimos, entre otros aspectos:

• Funcionalidades.
• Roles.
• Flujos.
• Arquitectura.
• Modelo de datos.
• Integraciones.
• Requisitos de seguridad.
• Criterios de aceptación.
• Estrategia de pruebas.
• Roadmap.

A partir de aquí dejamos de preguntarle a la IA qué debería construir el producto y empezamos a utilizarla para ayudarnos a construir lo que hemos decidido.

Develop: utilizar IA dentro de un proceso controlado

La inteligencia artificial sigue teniendo mucho sentido durante el desarrollo.

Puede acelerar generación de código, documentación, tests, análisis o determinadas tareas repetitivas. En nuestro trabajo de IA aplicada a QA, por ejemplo, el foco está en ampliar cobertura y estandarizar la calidad sin perder validación humana.

Pero la IA trabaja dentro de una arquitectura y unas reglas.

En GooApps® hemos desarrollado precisamente un estándar de agentes backend y frontend basado en contexto persistente, documentación compartida, especialización de roles y validaciones humanas y técnicas.

La diferencia no está en dejar de utilizar IA.

Está en pasar de improvisar con IA a desarrollar con IA.

Deliver: preparar el producto para lo que ocurre después del lanzamiento

Publicar la app no termina el proyecto.

Empieza una etapa nueva.

Un producto en uso necesita monitorización, analítica, gestión de errores, actualizaciones de dependencias, soporte, mantenimiento y nuevas versiones.

También empieza a generar algo que ningún prototipo puede proporcionar: comportamiento real de usuarios reales.

Esos datos permiten comprobar dónde abandonan, qué funciones utilizan, qué procesos generan problemas y qué partes del producto aportan más valor.

Ahí comienza la evolución basada en evidencia.

Checklist antes de llevar una app de salud a producción

Antes del lanzamiento deberíamos ser capaces de responder con claridad a estas preguntas:

Producto

• ¿Sabemos exactamente qué problema resuelve?
• ¿Están definidos los usuarios y sus distintos roles?
• ¿Hemos probado los recorridos principales con usuarios representativos?
• ¿Tenemos claro qué funcionalidades entran en esta versión y cuáles no?
• ¿Sabemos cómo mediremos si el producto funciona?

Tecnología

• ¿Existe una arquitectura definida y comprensible?
• ¿Otro desarrollador puede incorporarse al proyecto?
• ¿Conocemos todas las dependencias?
• ¿Hay control de versiones?
• ¿Existen entornos separados de desarrollo, pruebas y producción?
• ¿Hay pruebas suficientes sobre las funciones relevantes?

Datos y seguridad

• ¿Sabemos qué datos recogemos y por qué?
• ¿Está definido dónde se almacenan?
• ¿Los permisos cambian correctamente según el rol?
• ¿Los secretos y credenciales están protegidos?
• ¿Tenemos trazabilidad sobre las acciones relevantes?
• ¿Existe un procedimiento de copia y recuperación?
• ¿Se ha revisado la seguridad del producto?

Contexto sanitario

• ¿Está claramente definida la finalidad de la solución?
• ¿Hemos analizado si puede existir consideración como software de producto sanitario?
• ¿Genera recomendaciones, alertas o información que pueda influir en decisiones clínicas?
• ¿Hemos identificado los riesgos asociados a esas funciones?
• ¿La documentación necesaria se está generando durante el desarrollo?

Operación

• ¿Sabemos cómo detectar una incidencia?
• ¿Existe monitorización?
• ¿Hay un responsable cuando algo falla?
• ¿Podemos desplegar una nueva versión de forma controlada?
• ¿Existe un plan de mantenimiento?

Si muchas de estas respuestas dependen todavía de revisar los prompts originales o de volver a preguntarle a la IA cómo funciona la aplicación, aún queda trabajo antes de producción.

Cuándo tiene sentido pedir una revisión especializada

No todos los proyectos necesitan el mismo nivel de intervención.

Si estamos creando una herramienta interna para explorar una idea y solo utiliza datos ficticios, el vibe coding puede cumplir perfectamente su función.

La situación cambia cuando el proyecto empieza a asumir responsabilidades reales.

Por ejemplo, cuando:

• Va a utilizarlo un paciente o un profesional.
• Recoge datos personales o sanitarios.
• Se conecta con sistemas de terceros.
• Necesita varios roles y permisos.
• Genera alertas o recomendaciones.
• Debe publicarse en tiendas de aplicaciones.
• Forma parte de un proceso asistencial.
• Necesita soporte y continuidad.
• Se quiere presentar a una clínica, hospital o inversor.
• El equipo ya no sabe con seguridad qué hace parte del código.

En ese momento, el valor de contar con un partner especializado no consiste únicamente en añadir desarrolladores.

Consiste en mirar el producto completo.

Tecnología, sí.

Pero también negocio, usuarios, procesos, seguridad, datos, integración y conocimiento del sector.

La IA puede acelerar el desarrollo. El criterio sigue marcando la diferencia

El vibe coding ha cambiado radicalmente la distancia entre una idea y una primera versión.

Y eso es positivo.

Podemos experimentar antes, probar más alternativas y validar conceptos con una inversión inicial menor.

El error sería pedirle a esa primera versión algo para lo que todavía no ha sido preparada.

En salud, convertir un prototipo en un producto implica mucho más que conseguir que todas las pantallas funcionen. Hay que pensar en personas, datos, arquitectura, seguridad, integración, mantenimiento y, cuando corresponda, regulación.

No hay que elegir entre desarrollar con inteligencia artificial o desarrollar profesionalmente.

Podemos hacer ambas cosas.

En GooApps® utilizamos la IA como una herramienta para acelerar el trabajo dentro de procesos, estándares y decisiones que siguen bajo responsabilidad del equipo.

Si ya has construido una primera versión con ChatGPT, Claude u otra herramienta, el siguiente paso puede no ser empezar de nuevo.

Puede ser entender qué tienes, qué merece la pena conservar y qué necesita cambiar para convertirlo en un producto preparado para crecer.

Preguntas frecuentes

¿Puede publicarse en App Store o Google Play una app desarrollada mediante vibe coding?

El hecho de haber utilizado IA para generar código no impide por sí mismo publicar una aplicación. Lo importante es que el producto cumpla los requisitos técnicos, de privacidad, seguridad y contenido de cada tienda. En las apps de salud existen además obligaciones específicas. Google Play exige una declaración sobre funcionalidades de salud y determinadas medidas de transparencia y privacidad para este tipo de aplicaciones.

¿Qué documentación debería preparar si quiero que otro equipo continúe una app creada con IA?

Cuanta más información exista, menor será el coste de reconstruir el contexto. Conviene aportar el repositorio, tecnologías utilizadas, instrucciones de despliegue, modelo de datos, servicios externos, APIs, variables de entorno, decisiones de arquitectura, funcionalidades conocidas, incidencias pendientes y cualquier documentación generada durante el proyecto. También resultan útiles las conversaciones o prompts que expliquen decisiones que no aparecen documentadas en el código.

¿Cómo se calcula el coste de llevar un prototipo creado con IA a producción?

No depende únicamente del número de pantallas o líneas de código. Primero hay que determinar cuánto puede reutilizarse. El coste puede variar considerablemente según la calidad de la arquitectura, deuda técnica, backend, seguridad, integraciones, UX, infraestructura, pruebas y posibles requisitos regulatorios. Por eso una auditoría inicial suele ser más útil que intentar presupuestar directamente una reconstrucción completa.

¿Puedo contratar una revisión técnica sin comprometerme a rehacer toda la aplicación?

Sí. De hecho, separar diagnóstico y desarrollo puede ser una buena forma de tomar decisiones. Una auditoría permite identificar riesgos, deuda técnica y prioridades, y clasificar qué elementos pueden mantenerse, cuáles deberían refactorizarse y cuáles conviene sustituir. A partir de esa información puede definirse un roadmap antes de decidir el alcance de una siguiente fase.

¿Qué debo preparar antes de solicitar una auditoría de una app creada con ChatGPT o Claude?

Lo más útil es disponer del código fuente o acceso al repositorio, una versión ejecutable si existe, una descripción breve del objetivo del producto, los usuarios previstos, tecnologías utilizadas, servicios de terceros, tipo de datos tratados y las funcionalidades que se consideran terminadas. No es necesario tener documentación perfecta: precisamente una parte de la auditoría puede consistir en reconstruir y ordenar ese contexto.

¿Ya tienes un prototipo creado con IA?

Conoce nuestros servicios