Tu agente puede construirte auth. Y ese es el problema.

Es viernes a las 5pm. Le pasás a tu agente las credenciales OAuth de Google y GitHub y le decís: "agregame login social". A las 7pm hay un commit verde, el flujo funciona, y tu landing tiene tres botones nuevos. Sentís que ganaste el día.

Lo que tu agente no te dijo es que acaba de escribir, dentro de tu repo, un sistema de identidad en miniatura. Y desde ahora ese sistema es tuyo: tuyo cuando Google rote un scope, tuyo cuando aparezca passkeys, tuyo cuando el primer cliente serio te pida SAML, tuyo cuando audit te pida un log que no sabés dónde vive.

Este artículo es sobre cuándo eso es exactamente lo que querés, y cuándo es la deuda técnica más cara que vas a contraer este año. La regla aplica a auth, pero es la misma para billing, observabilidad, email transaccional y casi cualquier capa que evolucione por presión externa.

El código invisible que tu agente acaba de escribir

Cuando un agente te "implementa login social", lo que hizo concretamente es generar el callback OAuth, decidir un formato de sesión, escribir lógica para refrescar tokens, decidir qué pasa si el mismo email viene de dos proveedores distintos, montar un flujo de recovery, y dejar el almacenamiento de usuarios en la base de datos que ya tenías a mano.

Nada de eso se ve en la demo del viernes. La demo solo muestra "click en botón → entra al producto". Pero detrás de ese click, tu repo creció en varias capas que ahora son responsabilidad tuya:

• Capa de proveedores: integración OAuth contra Google, GitHub, Microsoft, Apple, lo que sea. Cada uno con sus quirks y sus deprecaciones.
• Capa de identidad: cómo se modela un usuario, cómo se vinculan dos cuentas que son la misma persona, qué pasa con un email no verificado, qué hacés con duplicados.
• Capa de sesión: tokens, refresh, rotación, revocación, expiración, dispositivos múltiples.
• Capa de operación: audit logs, rate limiting en endpoints de auth, manejo de incidentes, recovery cuando un usuario pierde acceso.

El agente las generó en una tarde porque cada una, aislada, es código de manual. El problema es que la combinación de las cuatro es donde vive la dificultad real, y esa combinación quedó en tu repo sin nadie que la mantenga aparte de vos y del agente que vuelvas a llamar.

Principio: Un agente no resuelve auth. Te transcribe auth. La diferencia se nota cuando algo cambia.

El día 1 sale gratis. El problema es el día 400

La pregunta correcta no es "¿cuánto tarda en salir?". La pregunta correcta es "¿cuánto cuesta mantener esto durante el año que viene?". Y esa pregunta nadie te la hace cuando ves el commit verde del viernes.

Te la hacés sola cuando, ocho meses después, el proveedor cambia un scope y la mitad de tus usuarios no puede entrar el lunes. Te la hacés cuando aparece passkeys y tu producto compite con uno que ya lo soporta. Te la hacés cuando un atacante encuentra un CVE en la librería que tu agente usó, y tenés que entender el código que tu agente escribió hace seis meses para parchearlo.

Lo que distingue una buena decisión de arquitectura no es la velocidad del primer commit. Es el costo amortizado sobre los siguientes 24 meses. Y para capas que evolucionan por presión externa —deprecaciones de proveedores, CVEs, regulación, expectativas del usuario— el costo amortizado de mantenerlas vos siempre es más alto que el de delegarlas a alguien cuyo trabajo es justamente eso.

Principio: El precio de la infraestructura no se paga el día 1. Se paga durante los 400 días siguientes.

El test del segundo proveedor

Hay un momento muy específico en el que se rompe la simetría. El primer login social es trivial: pegás credenciales, el agente arma el callback, listo. El segundo es donde aparece la complejidad real.

El usuario que entró ayer con Google entra hoy con GitHub. ¿Es la misma persona o es otro usuario? Si es la misma, ¿cómo lo sabe tu sistema? Si los dos proveedores devuelven emails distintos, ¿cuál guardás como "el" email? Si uno devuelve email no verificado y el otro sí, ¿qué hacés con el flujo de recovery?

Esa decisión —account linking— no es una feature. Es una política. Y una política mal elegida abre puertas: si un atacante puede registrar una cuenta con un email que tu usuario legítimo todavía no verificó, y después tu usuario hace OAuth con ese mismo email, te acaban de robar la cuenta. Es un patrón conocido y se llama account takeover via unverified email. Lo conocés vos cuando lo leés en una postmortem ajena.

Cuando el agente te configura el primer proveedor, no toma esa decisión. Cuando configurás el segundo, alguien tiene que tomarla. Y si esa persona sos vos sin contexto, vas a elegir mal.

Principio: El primer proveedor es código. El segundo es política. Las políticas no se delegan a quien no va a estar cuando exploten.

El test del cliente enterprise

El otro punto donde se rompe es el primer cliente que paga en serio. Ese cliente —cualquier banco, cualquier fintech, cualquier empresa de más de 200 personas— te va a pedir tres cosas que tu agente no construyó: SAML para que su Active Directory autentique a sus empleados, SCIM para provisionar y desprovisionar usuarios automáticamente, y aislamiento real entre sus datos y los de tus otros clientes.

Cada una de esas tres cosas, sola, es un proyecto. SAML implica entender XML signing, certificados, metadata exchange y un protocolo que tiene 20 años de complejidad acumulada. SCIM implica un endpoint REST con un schema específico que tiene que sobrevivir a actualizaciones. Multi-tenant aislado físicamente —no por una columna tenant_id— implica repensar cómo se almacenan los usuarios desde el día uno.

Si llegaste hasta acá con el código que el agente escribió en una tarde, no estás reescribiendo un módulo. Estás reescribiendo el corazón de tu producto, mientras tenés que cerrar al cliente que va a pagar lo que cierra tu runway.

Principio: Si tu producto va a tocar enterprise alguna vez, asumí que va a tocarlo antes de lo que pensás. Diseñá para eso desde el día uno o no diseñes para eso nunca.

Cuándo sí pedírselo a tu agente, cuándo no

Esto no es un argumento absoluto contra dejar que un agente construya. Es un argumento contra delegar capas que el agente no va a mantener. La diferencia es la heurística:

• SÍ pedírselo al agente cuando: es un side-project, un proof-of-concept, una herramienta interna, una feature aislada cuyo costo de reescritura es bajo. Cuando el peor caso es "lo tiramos y empezamos de nuevo".
• NO pedírselo al agente cuando: la capa va a evolucionar sin que vos quieras (nuevos proveedores, nuevas regulaciones, nuevos protocolos), cuando los errores son costosos (auth, billing, datos personales), cuando vas a tener clientes que te van a pedir cosas que hoy no existen en tu cabeza.

Una manera más corta de decirlo: pedíselo al agente cuando el código que va a escribir podría no estar en tu repo en seis meses. No se lo pidas cuando ese código va a estar en producción durante años, porque entonces lo vas a mantener vos.

Principio: Un agente es bueno construyendo lo que vos podés tirar. Es malo construyendo lo que vos vas a heredar.

El patrón se repite más allá de auth

Auth es el ejemplo más visible, pero la regla aplica a cualquier capa que cumpla tres condiciones: evoluciona por presión externa, los errores son costosos, y los requerimientos crecen con el cliente. Lo mismo pasa con:

• Billing: tu agente puede integrarte cobros con tarjeta en una tarde. Cuando llegue el primer cliente con impuestos por jurisdicción, suscripciones con prorateo, dunning automático, métricas de MRR/ARR y un CFO que pide reporting, vas a entender por qué existen plataformas dedicadas.
• Observabilidad: logs en archivos planos funcionan hasta que necesitás correlacionar trazas entre servicios, alertar antes de que se rompa algo, y guardar 90 días sin que tu disco explote.
• Email transaccional: sendmail en tu servidor funciona hasta que el primer cliente reporta que tus emails caen en spam, y descubrís que la deliverability tiene 15 años de complejidad de DNS, reputación, bounce handling y feedback loops.
• Búsqueda: LIKE '%foo%' sobre tu base funciona hasta los 100k registros. Después aprendés qué es BM25, sinónimos, stemming en español y cuándo conviene un índice externo.

En cada caso, la trampa es la misma: el agente te resuelve la versión simple en una tarde y vos asumís —sin querer— que la versión compleja también va a ser tuya cuando llegue.

Principio: Cualquier capa que vaya a tener requisitos que hoy no podés enumerar, no debería vivir en tu repo.

Cuando el agente opera el servicio en lugar de reescribirlo

Si llegaste hasta acá y tu reacción es "esto es demasiado, yo quiero enfocarme en mi producto, no en infraestructura de identidad", esa reacción es completamente válida. Es la reacción correcta para casi cualquier founder que está construyendo un SaaS B2B con horizonte de crecimiento.

Existen plataformas que abstraen toda esta complejidad como un servicio externo, y donde tu agente —el mismo al que ibas a pedirle que escribiera el callback OAuth— configura el servicio con una llamada API o por MCP en treinta segundos, sin escribir nada en tu repo. Una de esas plataformas, pensada para que un agente la opere de punta a punta y para que cada cliente tuyo viva en su propia instancia aislada, es Prysm:ID. La idea no es que sea la única opción —existen Auth0, Clerk, WorkOS, Supabase Auth y varias más, cada una con sus trade-offs—. La idea es que cualquiera de ellas es preferible a tener un sistema de identidad emergente dentro de tu repo, escrito por un agente que no va a estar cuando se rompa.

Checklist antes del próximo viernes

Antes de pedirle a tu agente que te implemente la próxima capa de infraestructura, pasá la pregunta por este filtro:

1. ¿Esta capa va a evolucionar por presión externa que yo no controlo?
2. ¿Un error acá es solo molesto, o es caro y visible?
3. ¿Mis clientes van a pedirme requisitos sobre esto que hoy no puedo enumerar?
4. ¿El código que se escriba hoy va a seguir en producción dentro de 18 meses?
5. ¿Yo tengo el contexto para mantenerlo, o lo voy a heredar?

Si respondiste sí a tres o más, esa capa no debería vivir en tu repo. Pedile al agente que integre el servicio externo, no que reescriba el servicio. Es el mismo agente, la misma velocidad del día 1, y un día 400 que se parece bastante al día 1.

El trabajo difícil de un founder técnico no es escribir código. Es decidir qué código vale la pena escribir.