Tres semanas, una aplicación: Lo que la IA puede construir para usted y lo que absolutamente no puede

Hace tres semanas tenía un backend .NET con quizá el 40% de los servicios cableados, un frontend Vue a medio terminar y un plan vago. Hoy Rasepi tiene un motor de traducción a nivel de bloque con gestión de glosarios y reglas de estilo, un sistema de puntuación de frescura con plantillas de caducidad y flujos de trabajo de revisión, búsqueda semántica impulsada por IA con RAG, un SDK de plugins completo con guardias de acción y canalización de eventos, edición colaborativa en tiempo real, un sitio web de marketing completo con páginas de precios, un portal de documentación para desarrolladores, un blog con 14 entradas, traducciones automáticas a 7 idiomas y un formulario de lista de espera que realmente envía correos electrónicos.

No lo hice solo. Tenía a Claude funcionando en VS Code todas las tardes durante horas y a veces incluso todo el día, y fue realmente transformador para las partes en las que podía ayudar. Pero hay un abismo entre "construir una aplicación" y "tener algo que realmente podrías vender a otro ser humano", y ese abismo está lleno de toneladas de páginas de configuración, configuración manual, ajustes de entregabilidad de correo electrónico y registros DNS. Claude no puede hablar con todos estos servicios todavía.

La gente rara vez habla de esa parte.

¿Podría haber hecho esto sin la IA?

Mire, tengo más de 30 años de experiencia construyendo software. ¿Podría haber construido todo esto sin Claude? Probablemente. Pero no en tres semanas. Ni por asomo. La IA aceleró todo lo que implica teclear código en archivos, y eso es una parte enorme de cualquier proyecto.

Pero aquí está lo que la gente pasa por alto cuando hablan de "codificación vibrante" y de construir aplicaciones enteras con IA: todavía necesita saber lo que está haciendo. Claude puede indicarle cada uno de los pasos necesarios para desplegar un Cloudflare Worker con una base de datos D1. Puede guiarle a través de la configuración de OpenIddict. Puede explicarle los registros DNS y la configuración SPF. El problema es que sus conocimientos suelen estar desfasados. Las plataformas actualizan sus cuadros de mando, mueven las configuraciones, dejan obsoletas las funciones, cambian el nombre de las cosas. Y Claude no lo sabe.

Ni siquiera utilizaba sólo una IA. En ocasiones, ChatGPT sabía más sobre servicios concretos, sobre todo cuando los datos de formación de Claude llevaban unos meses de retraso con respecto a la documentación de una plataforma concreta. Algunos días tenía ambas abiertas una al lado de la otra, cotejando sus sugerencias con lo que realmente veía en el cuadro de mandos.

Pero el punto más profundo es éste: para tener una aplicación vendible, es absolutamente necesario saber cómo funciona el alojamiento. Cómo funcionan los dominios. Cómo funcionan los certificados de firma de código. Cómo funcionan las bases de datos. Cómo funciona la entregabilidad del correo electrónico. Cómo funcionan realmente los flujos OAuth2, no sólo el código que los implementa. ¿Puede construir una aplicación sin esos conocimientos? Claro. ¿Le llevará a alguna parte? Probablemente no. Tendrá algo que se ejecuta en localhost y no impresiona a nadie fuera de su propia máquina.

El 80% que parecía magia

Permítame ser claro sobre lo que funcionó, porque realmente funcionó bien. Para producir interfaces de servicio, implementar controladores CRUD, escribir configuraciones EF Core y construir componentes Vue, Claude es absurdamente rápido.

He aquí un ejemplo. Cuando necesité añadir el sistema de gestión de glosarios, describí el requisito: glosarios tenant-scoped, importación/exportación CSV, CRUD de términos individuales y un mecanismo de sincronización con la API de glosarios de DeepL. Claude elaboró los modelos de entidad, la interfaz y la implementación del servicio, el controlador con los atributos de autorización adecuados y el almacén Pinia. Todo ello en unos 20 minutos. Me habría llevado casi un día escribir todo eso a mano.

El motor de traducción fue similar. La arquitectura a nivel de bloque con hashing de contenido SHA256, la detección de estancamiento, el orquestador que coordina entre servicios. Claude entendió el patrón después de que se lo explicara una vez y luego lo replicara de forma coherente en docenas de archivos. El sistema de puntuación de la frescura, los flujos de trabajo de revisión, la tubería de notificación de caducidad. Servicio tras servicio, conectados y funcionando.

Para el sitio de marketing, Claude construyó páginas HTML enteras a partir de descripciones. "Una página de precios con un nivel gratuito, un nivel de equipo y un nivel de empresa. Fondo oscuro. Utilice el acento verde". Y simplemente... produjo una. Incluyendo puntos de ruptura responsivos y estados hover.

Esa es la parte mágica. Es real.

Domar la máquina

Pero no es como si simplemente hubiera tecleado "constrúyeme una aplicación" y me hubiera marchado. Trabajar con Claude es una habilidad propia, y pasé los primeros días haciéndolo mal.

El resultado inicial siempre está... bien. Técnicamente correcto, razonablemente estructurado, pero genérico. Claude escribe código como escribe prosa: competente, predecible y profundamente mediocre. Dejado a su aire, producirá la misma estructura de controlador que todo tutorial de framework utiliza. El mismo patrón de servicio. La misma disposición de componentes. Funciona, pero no es suyo.

Así que empieza a entrenarlo. No formalmente, no con ajustes finos, sino a través de la repetición y la corrección. "No, quiero la interfaz de servicio separada de la implementación". "Utilice siempre este patrón de atributo de autorización". "El contexto del inquilino procede del middleware, no del cuerpo de la solicitud". Vuelta tras vuelta tras vuelta. Algunos días me sentía como si estuviera programando en parejas con un junior muy entusiasta que no para de olvidar lo que decidimos ayer.

Y entonces algo hace clic. Después de suficientes correcciones, después de suficientes ejemplos en la base de código para que los lea, Claude empieza a acertar a la primera. Capta sus convenciones de nomenclatura. Sabe dónde coloca sus DTO. Sigue su patrón de gestión de errores sin que se lo pida. Esa transición de "molesto" a "productivo" llevó quizá cuatro o cinco días de trabajo constante.

Las entradas del blog fueron una historia similar. La voz de escritura por defecto de Claude es reconocible al instante. Ese estilo pulido, ligeramente distante y perfectamente estructurado que se lee como cualquier entrada de blog generada por IA que haya visto. Pasé por múltiples rondas construyendo una guía de estilo, alimentándola con ejemplos de cómo escribo realmente, señalando cada "vale la pena señalar" y cada guión em (en serio, la adicción al guión em es real). Finalmente construí todo un archivo de habilidades, un conjunto de instrucciones que Claude carga antes de escribir nada para el blog de Rasepi.

Este post, que conste, es de Claude. Con mis aportaciones, mis correcciones, mi dirección. Describí lo que quería decir, lo apunté en la guía de estilo y luego pasé tiempo yendo y viniendo hasta que la voz me pareció correcta. Ese es el flujo de trabajo real. No "AI lo escribe" y no "yo lo escribo". Es una conversación que produce algo que ninguno de los dos habría escrito solo.

También construí instrucciones personalizadas para el propio código base. Un archivo de instrucciones para el copiloto que explica la arquitectura, el sistema de traducción, las reglas de aislamiento de los inquilinos, las convenciones de codificación. Claude lo lee al inicio de cada sesión, y la diferencia es de la noche al día. Sin él, Claude adivina. Con él, Claude sabe.

La cuestión es: las ganancias de productividad son reales, pero no son gratuitas. Usted invierte tiempo por adelantado enseñando a la IA cómo trabaja, y esa inversión se amortiza con el paso de las semanas. Si se salta ese paso, pasará más tiempo corrigiendo los resultados de Claude que el que habría dedicado a escribir el código usted mismo.

Entonces necesita desplegar realmente la cosa

Aquí es donde cambia la historia.

Usted tiene una aplicación de trabajo en localhost. Hermosa. Ahora póngala en Internet. Haga que envíe correos electrónicos. Deje que la gente se registre. Acepte pagos eventualmente. Protéjalo de los robots. Dele un nombre de dominio que se resuelva correctamente.

Claude no puede ayudarle con nada de esto. La verdad es que no.

No quiero decir que produzca malas sugerencias. Quiero decir que fundamentalmente no puede interactuar con los sistemas que usted necesita configurar. Y en la configuración es donde usted pasa su tiempo, no escribiendo código.

Cloudflare: Un estudio de caso en "Averígüelo usted mismo"

El sitio de marketing de Rasepi funciona con Cloudflare Pages. La API de la lista de espera es un Trabajador de Cloudflare con una base de datos D1. Suena sencillo hasta que realmente tiene que configurarlo.

Claude nunca ha visto su panel de control de Cloudflare. Puede decirle "añadir un registro CNAME" pero no puede decirle cuál de las 14 pestañas contiene la configuración DNS para su dominio en particular. Los enlaces de base de datos D1 necesitan un ID de base de datos específico en su wrangler.toml. Los secretos de entorno pasan por wrangler secret put. CORS tiene que coincidir con sus orígenes desplegados reales, no con localhost. Turnstile necesita claves de otra sección del cuadro de mandos.

Pasé casi un día entero consiguiendo que el Worker verificara correctamente los tokens de Turnstile, aceptara los envíos de formularios, los almacenara en D1 y enviara correos electrónicos de confirmación. Claude me ayudó a escribir el propio código del Trabajador. ¿Pero el despliegue, la configuración del wrangler, la gestión de secretos, la depuración de la propagación DNS? Todo eso fui yo.

OAuth2: El laberinto de la configuración

La autenticación es el mejor ejemplo de la brecha entre "código" y "producto".

Claude puede escribirle absolutamente una integración OAuth2. Conoce la especificación OIDC, puede producir middleware, entiende las reclamaciones JWT. Para nuestro entorno dev tengo un DevAuthHandler que menta tokens con reclamos tenant_id y sub a partir de un simple patrón de cadena portadora. Claude lo escribió en minutos.

Pero la autenticación de producción significa OpenIddict, y OpenIddict significa averiguar las reivindicaciones sub, las reivindicaciones tenant_id, las URL de devolución de llamada, los orígenes de JavaScript, las URI de cierre de sesión y todos los demás tejemanejes que conlleva una configuración de identidad real. Y eso incluso antes de llegar a los proveedores externos.

Porque sus usuarios quieren iniciar sesión con Google, Microsoft o GitHub. Y Claude no puede iniciar sesión en ninguna de esas consolas de desarrollador por usted. No puede:

• Crear una aplicación OAuth en la consola de Google Cloud y generar un ID de cliente y un secreto
• Registrar una aplicación en el portal Entra de Microsoft y configurar las URI de redirección
• Configurar una aplicación GitHub OAuth y obtener las credenciales
• Configure las URL de devolución de llamada de cada proveedor para cada entorno que ejecute
• Cablee los ámbitos correctos, las pantallas de consentimiento y los puntos finales de token

Cada proveedor tiene su propio portal para desarrolladores, su propia terminología, su propio flujo para generar credenciales. Google lo llama "pantalla de consentimiento". Microsoft lo llama "registro de aplicaciones". GitHub lo llama "aplicaciones OAuth" (no confundir con "aplicaciones GitHub", que son algo totalmente distinto). Y cada una de ellas requiere que copie manualmente un ID de cliente y un secreto en su configuración.

Claude puede escribir la configuración del servidor OpenIddict, el middleware del proveedor externo, la lógica de transformación de reclamaciones. ¿Pero la generación real de credenciales, la navegación por el portal, la configuración de la URL específica del entorno? Eso es todo suyo, en un navegador, haciendo clic en los paneles.

Correo electrónico: Nunca es sólo "enviar un correo electrónico"

El código para enviar un correo electrónico a través de la API de reenvío es de unas 15 líneas. Claude lo escribió sin problemas. ¿Pero hacer que los correos electrónicos lleguen realmente a la bandeja de entrada de alguien? Eso requiere un dominio de envío verificado, registros DNS para SPF, DKIM y DMARC, esperar a la propagación y luego probar la entregabilidad porque Gmail y Outlook tienen sus propias opiniones sobre si su dominio es de confianza.

Y diseñar una plantilla de correo electrónico que no tenga un aspecto terrible en todos los clientes de correo electrónico. Outlook en Windows todavía utiliza el motor de renderizado de Word en 2026. Deje que eso se hunda.

La lista completa de cosas que hice sin IA

Echando la vista atrás a tres semanas de trabajo, empecé a llevar un recuento mental aproximado de lo que Claude construyó frente a lo que configuré a mano. La lista "a mano" es más larga de lo que esperaba:

Infraestructura de la nube:

• Configuración del proyecto Cloudflare Pages y configuración del dominio personalizado
• Despliegue de Cloudflare Worker y aprovisionamiento de la base de datos D1
• Registros DNS para el sitio de marketing, la API y el envío de correo electrónico
• Configuración de certificados SSL/TLS (en su mayor parte automática, pero depurar cuando no lo es es doloroso)
• Configuración del pipeline de construcción para el blog (Eleventy + traducción + generación de imágenes OG)

Autenticación y seguridad:

• Registro de aplicaciones y generación de credenciales OAuth de Google, Microsoft y GitHub
• Configuración de OpenIddict con reclamaciones correctas, URL de devolución de llamada, orígenes JS y URI de cierre de sesión
• Configuración de la protección contra bots Turnstile (claves del sitio, claves secretas, configuración del panel de control)
• Configuración de la política CORS entre los orígenes frontend, API y Worker

**Correo electrónico

• Configuración de la cuenta de reenvío y de la clave API
• Registros DNS SPF, DKIM, DMARC
• Pruebas de entregabilidad del correo electrónico y solución de problemas
• Pruebas de plantillas en clientes de correo electrónico

Integraciones de terceros:

• DeepL Gestión de cuentas y claves API
• Configuración de Google Analytics con integración del consentimiento de cookies

**Alojamiento Azure

• Instalación y configuración de Azure App Service para el backend .NET
• Aprovisionamiento de la base de datos Azure SQL, reglas de cortafuegos y cadenas de conexión
• Configuración y conexión de Azure Cache para Redis
• Aprovisionamiento de recursos Azure OpenAI para incrustaciones y RAG

**Despliegue

• Configuración de Docker para el backend .NET
• Gestión de variables de entorno en tres objetivos de despliegue diferentes
• Cadenas de conexión de bases de datos para diferentes entornos

Y, sinceramente, probablemente me estoy olvidando de algunas cosas. Cada servicio de terceros tiene su propio panel de control, su propio modelo de credenciales, su propia calidad de documentación (que varía enormemente) y sus propias peculiaridades.

Por qué esto importa más de lo que la gente piensa

Aquí está la dimensión que se pierde en cada conversación sobre el desarrollo asistido por IA: Las herramientas de IA tienen cero contexto sobre su infraestructura.

Su código base vive en archivos que una IA puede leer. Su configuración de Cloudflare no. La configuración de su aplicación Google OAuth no. Sus registros DNS no. Su estado de verificación de dominio Resend no. Toda la superficie operativa de un producto real es invisible para las herramientas de IA, y esa superficie es enorme.

Escribir código es la parte fácil de la ingeniería de software, y cada día es más fácil. La parte difícil es lo que se hace con ese código. Operarlo, comprenderlo cuando algo se rompe a las 2 de la madrugada, ampliarlo cuando cambian los requisitos y gobernarlo a lo largo de todo su ciclo de vida. La IA agiliza la parte fácil. No hace nada por la parte difícil.

El sitio de marketing merece su propia sección

Construí todo el sitio de marketing de Rasepi en unos cuatro días. Página de inicio, página de precios, formularios de registro y contacto con protección contra bots, política de privacidad, cuatro páginas de profundización en las características. Claude hizo probablemente el 70% del HTML/CSS.

Pero luego necesitaba que existiera realmente en Internet. El blog se ejecuta en Eleventy con un proceso de construcción de 8 pasos: traducir las entradas a través de DeepL, construir el sitio, traducir las páginas HTML estáticas, copiar los activos compartidos, generar imágenes OG a partir de SVG, generar versiones de audio, gestionar los manifiestos de audio, producir un mapa del sitio multilingüe. Claude ayudó a escribir piezas de ese pipeline, pero conseguir que todo funcionara junto con las rutas de archivo correctas y los ajustes de despliegue de Cloudflare Pages adecuados nos llevó un día entero de prueba y error.

¿Y el sitio de documentación para desarrolladores? Ese es un proyecto separado de Cloudflare Pages con su propio dominio, su propia configuración de compilación y sus propios activadores de despliegue. Otro panel de control, otro conjunto de variables de entorno, otra ronda de DNS.

El patrón que sigo viendo

Para cualquier característica dada, Claude maneja alrededor del 80% del trabajo por volumen. Líneas de código, archivos creados, problemas resueltos. Pero el 20% restante es trabajo de configuración totalmente manual: hacer clic a través de paneles web, copiar claves entre servicios, depurar problemas de integración que sólo aparecen en entornos desplegados.

Y ese 20% lleva al menos tanto tiempo como el otro 80%. A veces más.

Pero esto es lo que ha cambiado en comparación con cómo solía funcionar el desarrollo en solitario: antes, o escribías código o hacías la configuración. Nunca ambas cosas. Si pasabas un día configurando los webhooks de Stripe y probando los flujos de pago en su panel, ese era un día en el que escribías cero código de aplicación. Su proyecto simplemente dejaba de avanzar en un frente mientras usted trabajaba en el otro.

Con Claude, eso ya no es cierto. Mientras yo estaba en las profundidades del salpicadero de Stripe averiguando los puntos finales de los webhooks y los tipos de eventos, Claude estaba construyendo la siguiente interfaz de servicio. Mientras yo estaba haciendo clic a través de la configuración de la pantalla de consentimiento OAuth de Google por tercera vez porque me equivoqué con los ámbitos, Claude estaba escribiendo componentes Vue. Mi cabeza estaba en la tierra de la configuración, pero la base de código seguía creciendo. Eso es genuinamente nuevo. Un desarrollador en solitario puede ahora moverse en dos frentes a la vez, y esa podría ser la mayor diferencia práctica que la IA supone para los equipos pequeños.

Dicho esto, cuando se escribe código con la ayuda de la IA, se entra en un bucle de retroalimentación muy estrecho. Escribir, probar, corregir, iterar. Cuando está depurando por qué su Cloudflare Worker devuelve errores CORS sólo en producción, está mirando capturas de pantalla del panel de control, leyendo publicaciones en foros de la comunidad y probando cambios de configuración aleatorios con la esperanza de que alguno de ellos funcione.

Lo que hay que cambiar

No creo que se trate de una limitación permanente. La pieza que falta es obvia: las herramientas de IA deben poder interactuar con las API de servicios y cuadros de mando de terceros. No sólo escribir código que los llame, sino configurarlos realmente.

Algo de esto está empezando a suceder. Están apareciendo servidores MCP (Model Context Protocol) para diversos servicios. Anthropic está pensando claramente en el uso de herramientas como un concepto de primera clase. Pero no estamos ni cerca del punto en el que pueda decir "configure mi Cloudflare Worker con una base de datos D1, configure el dominio personalizado y añada protección Turnstile" y que realmente suceda.

Hasta entonces, la historia honesta de construir un producto con IA es esta: La IA es un acelerador increíble para escribir código de aplicación. Pero un producto vendible es sólo la mitad del código de la aplicación. La otra mitad es la infraestructura, las integraciones de terceros, los conductos de despliegue, la entregabilidad del correo electrónico, la configuración del dominio y la configuración de la seguridad. Y para todo eso, está usted solo.

(Ésta es, por cierto, una de las razones por las que estamos construyendo Rasepi como una plataforma alojada y no sólo distribuyendo código abierto. Conseguir que el software de documentación funcione no es tan difícil. ¿Conseguir que funcione de forma fiable, con autenticación, correo electrónico y alojamiento adecuados? Ese es el producto).

Si está a punto de probar esto

Algunas cosas prácticas que aprendí y que podrían ahorrarle tiempo:

• Comience con la infraestructura, no con el código. Configure primero su alojamiento, su proveedor de autenticación, su servicio de correo electrónico y sus dominios personalizados. Consiga desplegar un "hola mundo" en producción antes de escribir una sola línea de código de aplicación real. El número de problemas que sólo salen a la superficie en entornos desplegados es deprimente.

• Mantenga un documento de credenciales. Tendrá claves de API, ID de cliente, URL de devolución de llamada, ID de base de datos y claves secretas dispersas en 8 cuadros de mando diferentes. Yo utilizo un archivo local cifrado. Puede utilizar 1Password o lo que sea. Simplemente tenga un único lugar.

• Presupueste el doble de tiempo para "la última milla" de lo que piensa. Si Claude le ayuda a construir la función en 2 horas, presupueste otras 2 horas como mínimo para desplegarla, configurar las integraciones y probarla en producción.

• Acepte que algunos días serán todo trabajo de tablero. Hubo días completos en los que escribí esencialmente cero código pero hice progresos críticos: registrar aplicaciones OAuth a través de tres proveedores, configurar el correo electrónico, depurar DNS. Esos días parecen menos productivos pero no lo son.

Tres semanas sigue siendo salvajemente rápido para lo que he construido. No me quejo de Claude. Permitió que un solo desarrollador construyera algo que normalmente llevaría a un equipo pequeño la mayor parte de un año. Pero a la historia que se cuenta en el ciclo del bombo de la IA (prompt, code, ship, done) le falta toda la sección intermedia en la que se hace realidad.

La aplicación es la parte fácil. Hacerla real es el trabajo.