Hay un momento que pilla a mucha gente que construyó algo con IA. La app funciona. Los usuarios dependen de ella. Y te das cuenta de que tienes miedo de cambiarla, porque no entiendes del todo cómo funciona y no tienes forma de saber si un cambio rompió algo hasta que te lo dice un usuario. Así que paras. Evitas los archivos peligrosos. Añades features por los bordes en vez de arreglar el núcleo, porque tocar el núcleo se siente como desactivar una bomba que no montaste.
Quiero replantear ese miedo por completo, porque casi todo el consejo lo trata como un defecto de carácter que hay que superar. No lo es. El miedo es preciso. Es una señal exacta sobre el estado real de tu código, y si lo sigues en vez de pelearlo, te entrega el plan exacto para arreglar la cosa que te da miedo.
El miedo dice la verdad
Empieza por tomarte el miedo en serio como dato. Tienes miedo de cambiar el código porque dos cosas son ciertas: no puedes predecir del todo qué hará un cambio, y no tienes forma independiente de atraparlo si el cambio está mal. Las dos son hechos reales sobre tu proyecto, no sentimientos sobre tu competencia.
Vale la pena detenerse ahí, porque las reacciones habituales son las dos equivocadas. Una es anular el miedo y cambiar las cosas igualmente, que es cómo publicas la regresión que temías. La otra es obedecer el miedo y congelarte, que es cómo el proyecto muere despacio mientras construyes solo en los rincones seguros. El miedo no te pide que seas más valiente ni más cuidadoso. Señala una cosa que falta, y el arreglo es construir la cosa que falta.
Lo que falta tiene nombre. Es la red de seguridad: la capacidad de hacer un cambio y saber, antes que un usuario, si rompiste algo. Tienes miedo porque no la tienes. Así que constrúyela.
El miedo es un mapa
Aquí está la parte que convierte la ansiedad en un plan. El miedo no está repartido de forma uniforme. Hay archivos que editarás encantado y archivos a los que no te acercarás. Esa distribución es un mapa, y es más precisa que cualquier auditoría que pudieras correr.
El código que tienes miedo de tocar es precisamente el código que sostiene peso y está desprotegido. Importa, o no tendrías miedo, y no tiene red, o no tendrías miedo. Los archivos que editas sin pensarlo dos veces o no importan o ya están a salvo. Así que el miedo ya ha hecho tu priorización por ti. Ha dibujado una línea roja alrededor de exactamente los caminos que necesitan red primero, y ha dejado todo lo demás sin marcar.
Es la misma conclusión a la que llego desde la otra dirección cuando escribo sobre cuándo añadir tests y arquitectura: inviertes en los caminos que sostienen peso y cambian. El miedo es solo esa señal, sentida en vez de razonada. Fíate. Donde más miedo te dé hacer un cambio es donde va la red primero.
Tejer la red: tres hebras
Una red de seguridad para código que no escribiste del todo y no entiendes del todo tiene tres hebras, y las añades en este orden.
Recupera la spec. No puedes cambiar con seguridad un comportamiento que no sabes enunciar. Así que antes de tocar un camino peligroso, haz que el sistema te diga qué hace ahora mismo: las entradas que acepta, las salidas que produce, las reglas que aplica, los casos límite que maneja. No escribes una spec para trabajo nuevo. Recuperas la spec que ya está implícita en código que funciona. Eso es lo que marca la diferencia entre editar a ciegas y editar con intención.
Fíjala con tests de caracterización. Una vez que puedes enunciar lo que hace el código, bloquéalo con tests que afirmen exactamente eso. Los tests de caracterización no comprueban que el código sea correcto en algún sentido ideal. Comprueban que sigue haciendo lo que hacía antes de tu cambio. Ese es el miedo exacto que intentas matar: no “¿es bueno este código?” sino “¿lo acabo de romper?”. Los tests de caracterización responden a esa pregunta automáticamente, cada vez, y eso es lo que te deja hacer el cambio que estabas evitando.
Exige evidencia en cada cambio. La red solo aguanta si de verdad se comprueba. Un agente que informa de “hecho” sin correr los tests te ha dado una red sin cuerda. Así que la tercera hebra es una regla: nada está hecho hasta que existe la evidencia de que los tests corrieron y pasaron contra el cambio real. Es la idea entera de hecho significa hecho, aplicada a tu propio miedo. La razón de que no confíes en “funciona” es que te han quemado afirmaciones sin prueba detrás. La prueba es lo que reconstruye la confianza.
Por qué el código construido con IA lo necesita más
Puede que notes que son técnicas viejas. Los tests de caracterización preceden a los agentes en décadas. La razón de que importen más ahora es que la IA cambió la proporción entre el código que escribiste y el código que posees.
Ahora puedes poseer un código grande que apenas leíste, producido más rápido de lo que pudiste revisarlo. Es una situación genuinamente nueva, y es la razón de que el miedo sea tan común ahora y fuera más raro antes. Cuando escribías cada línea, la comprensión venía gratis. Cuando la escribe un agente, la comprensión es lo que te saltaste, y el miedo es la factura. Es una cara concreta de la deuda del vibe coding: la comprensión que nunca construiste, cobrando intereses en forma de miedo cada vez que necesitas tocar el núcleo.
También conecta con la seguridad. Los caminos que tienes miedo de tocar son a menudo los mismos donde se esconden los agujeros que deja el vibe coding, porque el código sin tocar y sin examinar es justo donde sobrevive una entrada sin validar o un secreto filtrado. Construir la red te obliga a leer por fin esos caminos, y así el miedo resulta ser protector en vez de solo incómodo.
De congelado a en movimiento
El punto final no es la ausencia de miedo. Es un proyecto donde las partes peligrosas tienen red y las seguras no la necesitan, para que puedas volver a moverte. Esto es buena parte de lo que de verdad hace falta para llegar del vibe coding a producción: no valentía, sino un código que te avisa cuando lo has roto.
Dónde encaja PaellaDoc
Las tres hebras, spec recuperada, tests de caracterización y evidencia, comparten un problema: solo ayudan si persisten y siguen unidas al código que cubren. Una spec recuperada en un chat que cerraste ya no está. La evidencia que no guardaste es un recuerdo.
PaellaDoc está hecho para mantener esa red en su sitio. Lee tu código existente y lo convierte en un modelo sobre el que puedes razonar, da a la spec recuperada y al contrato de aceptación un hogar junto al código que describen, y guarda la evidencia de cada cambio para que “pasó” sea un hecho en registro, no una afirmación que tengas que creer a ciegas. El miedo se desvanece no porque te hayas vuelto más valiente, sino porque lo que te faltaba por fin existe.
Preguntas frecuentes
¿Tener miedo de cambiar mi propio código es señal de que hice algo mal? No. Es una señal exacta de que un camino que sostiene peso no tiene red. La respuesta correcta no es forzar el miedo ni congelarte, sino construir la red donde el miedo apunta.
¿Qué es un test de caracterización? Un test que fija lo que el código hace ahora, en vez de lo que idealmente debería hacer. En proyectos construidos con IA rara vez tienes una spec limpia, así que fijas primero el comportamiento existente, lo que te deja cambiar el código y ver de inmediato si alteraste algo.
¿Por dónde empiezo si me da miedo el código entero? Empieza donde el miedo es más agudo. Los caminos que menos quieres tocar son los que sostienen peso y están desprotegidos. Recupera su comportamiento, fíjalo con tests y exige evidencia en los cambios, y luego avanza hacia fuera.