Subida de archivos en Coderick AI: trae tu código y tus diseños directamente

ube un archivo HTML a Coderick y pídele lo que necesitas: en este ejemplo, añadir una sección de galería en carrusel a tu proyecto en segundos.

Crear con Coderick AI es realmente increíble. Describes lo que quieres y Coderick AI lo construye por ti. Esto funciona de maravilla cuando partes de una idea. Pero a veces no es así. A veces ya tienes algo creado en otro lugar que quieres utilizar como referencia o aprovechar dentro de tu proyecto.

Quizás maquetaste un diseño con Claude Design y lo quieres como página de inicio. Quizás un artefacto de Claude te dejó un componente muy cerca de lo que necesitabas y solo tienes que meterlo en un proyecto real y publicado. Quizás encontraste una plantilla HTML que casi es perfecta, y prefieres pasarle el archivo antes que describirla en tres párrafos.

Para eso está la subida de archivos en Coderick AI.

Construye sobre lo que ya tienes, no desde cero

Utiliza la función de carga de archivos como punto de partida y pídele a Coderick que trabaje a partir de ellos. Añade nuevas secciones a un diseño de página de inicio que hayas subido. Convierte una página única en un sitio web multipágina. Añade funcionalidades a un diseño estático.

Coderick construye sobre tu trabajo existente, añade nuevos elementos, mejora tu borrador y finaliza el proyecto, en lugar de empezar desde cero. Así ahorras tiempo y créditos, al mismo tiempo que aumentas el valor del trabajo que ya has realizado.

Coderick AI code files upload previews taking ready html file, updating its colors and adding the section to a real Coderick AI project

Mantén tus propios estilos

Puedes pedirle a Coderick que aplique directamente un archivo. El HTML que subas se convierte en la base de tu página de inicio. Los estilos que cargues se utilizan en todo el proyecto. Coderick lee el código fuente y lo reconstruye dentro de tu proyecto: tu estructura, tus estilos y tus elementos específicos.

Antes, tenías que describir con palabras cualquier trabajo previo que hubieras realizado: los espaciados, las columnas, los efectos hover o cualquier elemento visual que quisieras conservar. Y cualquiera que haya intentado describir detalles de diseño específicos a una IA sabe cómo suele acabar: obtienes algo que se parece en un 80% a lo que querías, y el 20% restante se convierte en un largo proceso de ajuste mediante prompts de seguimiento.

Lleva tu trabajo a producción más rápido

Subir tus archivos a Coderick AI te permite tener un proyecto funcional en línea mucho antes. Ahorras el tiempo que dedicarías a volver a describir mediante prompts algo que ya has creado y puedes invertirlo en transformar ese diseño en un sitio web o una aplicación web real y operativa.

Tipos de archivo compatibles con Coderick AI

Coderick AI acepta los tipos de archivo de texto que más probablemente ya tienes:

Tipo de archivoPara qué se suele usar
.htmlEstructura de páginas, landing pages, plantillas exportadas
.css, .scssEstilos, maquetación, sistemas de diseño
.js, .jsxComportamiento en JavaScript, elementos interactivos, componentes React
.ts, .tsxLógica en TypeScript, archivos frontend tipados, componentes React + TypeScript
.mdDocumentación, especificaciones, briefs de contenido, notas de proyecto

Puedes subir hasta 30 archivos a la vez, con un tamaño combinado de 500 kB. Las subidas de imágenes son independientes y admiten hasta 10 imágenes.

Cómo sacarle el máximo partido a la subida de archivos

La subida de archivos da a Coderick más con lo que trabajar. Cómo la uses determina el resultado.

Aun así, debes ser específico: «Aplica este diseño como página de inicio» siempre da mejor resultado que «usa este archivo». Coderick lee lo que subes, pero necesita que le digas dónde va el archivo y qué papel desempeña.

Sube juntos todos los archivos relevantes: Si tu diseño está repartido entre un archivo HTML y uno CSS, súbelos juntos. Coderick tiene más contexto cuando el panorama está completo.

Elimina de tus archivos los elementos innecesarios: Si puedes, revisa y elimina estilos sin usar, comentarios innecesarios o código auxiliar de otra herramienta. En definitiva, cualquier cosa que no quieras que Coderick interprete como intención. Una revisión rápida antes de subir hace que el primer resultado se acerque más al objetivo.

La subida de archivos es para los archivos concretos que quieres que Coderick lea como contexto dentro de un proyecto (todavía). No es una forma de importar un repositorio completo ni una carpeta de proyecto entera.

Ve a Coderick AI y carga lo que ya tengas creado: una exportación de Claude, una plantilla o un componente que hayas estado perfeccionando. A partir de ahí, deja que Coderick continúe construyendo sobre tu trabajo.

Storytelling que vende: identifica la herida de tu negocio y construye el relato que te diferencia

Seguramente llevas tiempo trabajando tu propósito de marca. Has definido tu misión, tu visión, tus valores. Sabes exactamente a quién ayudas y qué resultado logras.

El problema es que tu competencia también.

Esa fue la idea central que Rosa Morel, narratóloga, escritora y experta en brand storytelling, trajo a nuestro último webinar. El propósito es aspiracional y, por eso mismo, tiende a ser genérico e intercambiable. Dos empresas que venden lo mismo al mismo precio y con la misma calidad probablemente tienen el mismo propósito. Y en la era de la inteligencia artificial, donde cualquiera puede generar mensajes y contenidos en segundos, eso ya no alcanza. Lo que sí puede diferenciarte, lo que ninguna IA puede copiar y ningún competidor puede replicar, es tu herida fundacional.

Revive el webinar completo

¿Quieres escuchar a Rosa explicar todo esto en sus propias palabras? Incluye ejemplos en directo y las preguntas de la audiencia:

¿Qué es la herida fundacional de un negocio?

La herida fundacional es el momento clave que vivió tu yo pasado y que te empujó a emprender de la manera en que lo hiciste.

No es un trauma sin resolver. No es victimismo. Es el origen real de tu negocio: aquello que te dolió, te indignó o te faltó, y que convertiste en el motor de lo que hoy ofreces.

La diferencia con el propósito es fundamental:

  • El propósito es la conclusión de tu negocio. Es aspiracional y mira hacia adelante.
  • La herida es el origen. Es biográfica, específica y, por tanto, irreproducible.

Cuando la nombras bien, el cliente se reconoce en ella a modo de espejo. Ese reconocimiento, respaldado por la neurociencia, tiene una alta probabilidad de convertirse en confianza. Y la confianza, en ventas.

Como lo resumió Rosa en el webinar:

«Transformo tu herida en relato y tu relato en pasta.»

Los 5 arquetipos de herida fundacional

Rosa lleva años trabajando con emprendedores y ha identificado cinco heridas que se repiten como patrones. Pueden combinarse, pero siempre hay una principal.

Los 5 arquetipos de herida fundacional según el Método Morel: Rechazo, Abandono, Injusticia, Silencio y Jaula

A) Rechazo: En algún momento clave (infancia, primer trabajo, una relación) alguien importante te hizo sentir que no dabas la talla. Aprendiste a demostrar constantemente que eres válido. Hoy eso se traduce en perfeccionismo y en dar siempre más de lo esperado. Tu marca convierte a otros en suficientes.

B) Abandono: Alguien que debería haber estado no estuvo. Te dejaron resolver las cosas solo, te enseñaron que pedir ayuda era pedir demasiado. Por eso hoy eres el profesional que siempre está, que entrega más de lo que promete. Tu marca acompaña donde nadie acompañó.

C) Injusticia: Viviste en un sistema, una empresa o una norma donde las cosas se hacían mal y no podías decir nada. Te juraste que cuando pudieras lo harías distinto. Tienes el don de identificar patrones injustos donde otros solo ven malestar. Tu marca repara un sistema roto.

D) Silencio: Tu voz nunca contó. Te dijeron que exagerabas, te ignoraron, te callaron. Aprendiste a guardar tus ideas. Esa herida te llevó a buscar, en tu trabajo, la manera de poner palabras a lo que otros no saben decir. Tu marca pone palabras a lo que no se decía.

E) Jaula: Alguien (una familia, una pareja, una institución) decidió por ti cosas fundamentales durante mucho tiempo. Cuando pudiste elegir, dijiste: nunca más pido permiso. Es la más difícil de mostrar porque quienes la tienen raramente quieren mostrarse vulnerables. Tu marca devuelve la capacidad de elegir.

¿Con cuál te has identificado? El test del lead magnet al final de este artículo te ayuda a confirmarlo.

Por qué esto importa más que nunca ahora

Con la inteligencia artificial, crear contenido es más fácil que nunca. Eso también significa que sonar igual que todos los demás es más fácil que nunca.

Si un agente de IA puede generar el mismo tipo de mensaje que tú, la única razón para elegirte es la identidad y la confianza. Y esas dos cosas solo se construyen a través del storytelling auténtico: una narrativa con un origen real, irrepetible, tuyo.

Rosa lo demostró con números concretos. Al lanzar su primera novela bajo pseudónimo, sin seguidores, sin publicidad pagada, incluyó en los agradecimientos un texto construido desde su herida de rechazo: su historia de acoso escolar y de refugiarse en los libros.

Tasa de conversión a reseña del 39.6% y 40.5% conseguida con storytelling auténtico

El resultado fue una tasa de conversión a reseña del 39,6% y 40,5% en sus dos primeros libros. La media del sector en Amazon es del 1 al 2%. Si llegas al 5%, ya es un resultado excepcional.

El storytelling bien construido desde tu herida no es sentimentalismo. Es la decisión de negocio más inteligente que puedes tomar.

Narrativa vs relato: no son lo mismo

Antes de lanzarte a contar historias, conviene entender la diferencia entre dos conceptos que se usan como sinónimos pero no lo son:

  • La narrativa de marca es el sistema completo: la visión del mundo, los conflictos que defines, los valores que defiendes, la transformación que prometes. Es el universo que sostiene todos tus mensajes.
  • El relato es una historia concreta dentro de ese sistema: el relato de origen, el relato de cliente, el relato de producto.

El error más común, que Rosa ha visto tanto en negocios unipersonales como en multinacionales con presencia en varios países, es crear relatos sin tener narrativa: publicar historias que no están conectadas entre sí, que no forman parte de un hilo coherente.

La herida fundacional es el punto de partida de esa narrativa. Sin ella, todo lo demás flota. Rosa trabaja estos elementos a través de su Método Morel de narrativa con 12 anclajes, que va desde la narrativa interna (quién eres) hasta la narrativa de atracción (lo que publicas).

Método Morel de narrativa con 12 anclajes: El Guion, La Herida, El Enemigo, La Creencia, El Arquetipo, El Origen, La Promesa, El Espejo, La Polarización, La Espiral, La Tensión y La Conexión

Preguntas durante el webinar:

¿Contar tu herida te convierte en víctima?

No, siempre que hables desde la cicatriz y no desde la herida abierta. No se trata de dramatizar ni de dar detalles que no tienen función dentro de tu narrativa de marca. Rosa lo explica así: si cuenta que sufrió acoso escolar, no entra en los detalles del acoso porque eso no le aporta nada al lector. Lo que sí cuenta es lo que ese momento le enseñó y cómo lo transformó. Las heridas que se usan en la narrativa de marca deben estar, al menos en parte, cicatrizadas. Una herida reciente y abierta no es material de marca, es material de terapia.


¿Con qué frecuencia hay que usar el storytelling en redes sociales?

Cuando tienes una narrativa de marca bien construida, el storytelling está presente en casi todo lo que publicas, no solo cuando compartes algo personal. Existen diferentes tipos de relato: el relato de origen, el relato de cliente, el relato de producto. Todos forman parte de la misma narrativa. Eso sí: cada publicación debe tener una función clara dentro de ese hilo. Publicar por llenar el calendario, sin saber qué objetivo tiene cada pieza, no es storytelling. Y recuerda: en tu narrativa de marca, el protagonista no eres tú, es tu cliente.


¿Hay que identificar la emoción que quieres generar antes de escribir, o se va encontrando en el camino?

Siempre antes. La emoción es lo más importante a definir antes de escribir cualquier texto, ya sea un post, una página de ventas o un email. Cuando sabes exactamente qué quieres provocar en el lector, el texto fluye con mucha más claridad y coherencia. Rosa aplica esto también en sus novelas: antes de escribir cada escena sabe qué emoción quiere generar: angustia, esperanza, tensión. Si no lo defines antes, el texto puede estar bien escrito pero no mover a nadie.

Descarga el test: encuentra tu herida fundacional

Rosa preparó para este webinar una guía de 14 páginas para ayudarte a identificar cuál de los cinco arquetipos es el tuyo y cómo empezar a transformarlo en relato de marca.

SiteGround corrigió 5 vulnerabilidades críticas del kernel de Linux en 48 horas, sin tiempo de inactividad

Un desarrollador trabaja en una computadora portátil que muestra código fuente del kernel con iconos de seguridad incluyendo un escudo un candado y un símbolo de parche superpuestos en color verde

Las últimas semanas han sido intensas para quienes se dedican a administrar servidores Linux. Entre finales de abril y mediados de mayo, investigadores de seguridad revelaron cinco graves vulnerabilidades del kernel, cada una de las cuales otorgaba a cualquier usuario conectado acceso root completo a la máquina. Varias de ellas incluían código de explotación funcional publicado desde el primer día.

SiteGround aplicó correcciones para todas ellas en nuestra infraestructura de hosting sin reiniciar ningún servidor y sin interrumpir el servicio de ningún cliente.

¿Qué habría significado esto para tus sitios web?

En pocas palabras: si alguna de estas vulnerabilidades se hubiera explotado en un servidor antes de ser parcheada, un atacante que ya tuviera incluso el más mínimo acceso (un plugin de WordPress comprometido, una contraseña FTP filtrada, un script vulnerable) podría haber escalado desde una sola cuenta con privilegios limitados dentro de un sitio hasta obtener el control total del servidor subyacente. A partir de ahí, el procedimiento habitual: leer los archivos de otros usuarios, instalar puertas traseras persistentes, obtener credenciales y penetrar aún más en la red.

Estos no son riesgos teóricos. Existía código de explotación público para cada una de estas vulnerabilidades. Copy Fail, en particular, se estaba utilizando activamente a los pocos días de su divulgación.

¿Qué sucedió realmente?

En orden aproximado, esto es lo que afectó al mundo Linux:

29 de abril, se reveló la vulnerabilidad Copy Fail (CVE-2026-31431): un script de Python de 732 bytes podía convertir a cualquier usuario normal en root en prácticamente todas las distribuciones de Linux lanzadas desde 2017. Sin trucos de sincronización ni conjeturas, solo un fallo lógico en el subsistema criptográfico del kernel. CISA la añadió a su lista de vulnerabilidades explotadas activamente en cuestión de días.

7 de mayo, se reveló la vulnerabilidad Dirty Frag (falla xfrm/ESP, CVE-2026-43284): una vulnerabilidad en el código de red IPsec ESP del kernel que permitía a un atacante escribir datos arbitrarios en la copia en memoria de archivos del sistema de solo lectura. A menudo se la conoce como “Copy Fail 2”.

7 de mayo, se reveló la vulnerabilidad Dirty Frag (falla RxRPC, la segunda parte de la cadena): un fallo relacionado en el módulo de red RxRPC del kernel. En combinación con la vulnerabilidad xfrm/ESP mencionada anteriormente, otorga a un usuario normal acceso root completo.

13 de mayo: Fragnesia / Copy Fail 3.0 (CVE-2026-46300) revelada: el tercer error en tres semanas, de la misma familia que Dirty Frag, también en el subsistema IPsec del kernel. Se publicó una prueba de concepto funcional el mismo día.

14 de mayo: fallo en ssh-keysign / chage pidfd revelado y parcheado por Linus Torvalds: un tipo diferente de error, no una escalada de root, pero permitía que cualquier usuario sin privilegios leyera archivos propiedad de root como /etc/shadow  (los hashes de contraseñas) y claves de host SSH.

Cómo lo solucionamos sin interrupciones del servicio

Las cuatro decisiones que tomamos sobre cómo opera SiteGround hicieron que esto fuera manejable, y teniendo en cuenta lo que está por venir, las cuatro van a ser aún más importantes, no menos.

Monitoreamos constantemente el panorama de amenazas. Nuestro equipo de seguridad monitoriza las listas de correo del kernel, las fuentes CVE y los canales de divulgación las 24 horas del día. Nos enteramos de Copy Fail el mismo día de su divulgación, de Dirty Frag el mismo día de su lanzamiento y de Fragnesia a las pocas horas de que se publicara la prueba de concepto. No hay nada que sustituya a la vigilancia en tiempo real: para cuando estas noticias llegan a los principales medios tecnológicos, el código de explotación suele llevar ya varios días circulando. A medida que el descubrimiento impulsado por IA acelera el ritmo de divulgación, este tipo de monitorización constante se vuelve esencial, no opcional.

Contamos con ingenieros disponibles las 24 horas del día, los 7 días de la semana. Los parches críticos del kernel no esperan al horario laboral, y nosotros tampoco. Para cada una de estas vulnerabilidades, desarrollamos, probamos e implementamos parches en toda nuestra infraestructura en un plazo de 48 horas desde su divulgación pública, generalmente mucho antes de que la mayoría de las distribuciones hubieran lanzado sus paquetes oficiales.

Utilizamos la aplicación de parches al kernel en tiempo real. Esta es la parte más importante para ti. La aplicación tradicional de parches al kernel requiere un reinicio, lo que implica tiempo de inactividad para todos los servicios que se ejecutan en la máquina. La aplicación de parches en tiempo real aplica la solución al kernel en ejecución en memoria, por lo que la vulnerabilidad se corrige sin reiniciar nada. Tus sitios web, bases de datos, correo electrónico y sesiones SSH siguieron funcionando durante todos estos ciclos de parches. Cuando aumenta la frecuencia de los parches, también aumenta el costo de “simplemente reiniciar el servidor”; la aplicación de parches en tiempo real es lo que mantiene ese costo en cero para ti.

Mantenemos nuestros kernels optimizados. Una de las principales razones por las que estos errores son peligrosos es que el código vulnerable viene habilitado por defecto en la mayoría de las distribuciones. Copy Fail residía en la interfaz criptográfica del kernel AF_ALG. Dirty Frag y Fragnesia residían en los módulos esp4, esp6 y rxrpc, código de red IPsec y AFS que la gran mayoría de los servidores web jamás utilizarán. No cargamos módulos del kernel que no necesitamos. Esto significa que una parte importante de la superficie de ataque para estas vulnerabilidades simplemente no existía en nuestras máquinas, lo que nos da margen de maniobra para aplicar la solución adecuada.

El factor IA: y por qué esto es solo el principio

Un detalle en la divulgación de Copy Fail merece especial atención. El error no fue descubierto por un investigador humano que analizó el código durante semanas. Fue detectado por una herramienta de auditoría de código con IA (Xint Code) en aproximadamente una hora de escaneo del subsistema criptográfico del kernel de Linux. El mismo escaneo también reveló “otros fallos de alta gravedad, aún en proceso de divulgación coordinada”, lo que significa que hay más divulgaciones en curso.

Esto supone un cambio radical en la forma de detectar vulnerabilidades. Durante años, el principal obstáculo para descubrir errores críticos del kernel era el número limitado de expertos dispuestos a dedicar meses a leer el código fuente del kernel. Ese obstáculo ha desaparecido. Las herramientas de auditoría con IA ahora pueden escanear subsistemas completos a velocidad de máquina y están encontrando fallos que han permanecido en kernels estables durante casi una década.

En la práctica, esto significa que la frecuencia de divulgación de vulnerabilidades graves seguirá aumentando. Tres exploits universales de acceso root local en tres semanas no son una casualidad, sino un anticipo. Los ciclos de parcheo reactivos que funcionaban cuando se detectaba un fallo crítico del kernel cada seis meses ya no serán efectivos cuando se detecte uno cada dos semanas. La capacidad de detectar, reaccionar y parchear en cuestión de horas, en lugar de días, ya no es un lujo, sino el requisito fundamental para la seguridad.

Conclusión

Linux está atravesando un período inusualmente difícil en cuanto a la seguridad del kernel: tres exploits universales de root local en tres semanas no es normal, y la situación no mejora. Con herramientas de auditoría basadas en IA que ahora escanean el kernel a una velocidad inalcanzable para cualquier equipo humano, prevemos que la tasa de descubrimiento de vulnerabilidades graves seguirá acelerándose. Los errores que han permanecido latentes en kernels estables durante años están saliendo a la luz, subsistema por subsistema.

Lo que podemos prometer es que la forma en que gestionamos estas vulnerabilidades es la misma que utilizamos para todas las vulnerabilidades graves: monitorizar con antelación, aplicar parches rápidamente, solucionar problemas en tiempo real y minimizar la superficie de ataque desde el principio. Tus sitios web permanecen operativos. Los exploits no. Y a medida que la frecuencia de los ataques aumente, esto será aún más importante.