Forem: Lenin Uzcategui

Alerta para Desarrolladores: Trae IDE y el Riesgo Real con el Código de tus Clientes

Lenin Uzcategui — Wed, 18 Feb 2026 18:35:35 +0000

El IDE gratuito que te cuesta más de lo que crees

Imagina esto: estás trabajando en el sistema core de pagos de un banco. Tu IDE, de forma silenciosa y en segundo plano, está abriendo 500 conexiones a servidores en otro país, enviando 26 MB de datos que incluyen rutas completas de tus archivos, tiempos exactos de tu actividad, identificadores únicos de tu hardware — y todo esto justo cuando creías haberlo desactivado.

No es una película de espionaje. Es lo que documentaron investigadores independientes sobre Trae IDE, el nuevo IDE con IA de ByteDance (la empresa detrás de TikTok), en julio de 2025.

Este artículo no es un ataque a Trae ni a ByteDance. Es una llamada de atención al ecosistema de desarrollo de software sobre algo que debería ser innegociable: la privacidad del código de nuestros clientes.

¿Qué es Trae y por qué se volvió tan popular tan rápido?

Trae es un IDE basado en VS Code, desarrollado por ByteDance, que se lanzó ofreciendo algo que ningún competidor directo daba: acceso gratuito a modelos premium como Claude 3.7 Sonnet y GPT-4o, sin pagar suscripción.

Cursor cobra $20/mes para acceso a modelos de calidad. Trae lo daba gratis.

El resultado fue una adopción masiva, especialmente entre desarrolladores independientes y estudiantes. Y aquí está el problema clásico: cuando un producto es gratuito, la pregunta obligatoria es ¿cuál es el modelo de negocio real?

El escándalo que la comunidad no debería olvidar

Julio 2025 — Lo que los datos revelaron

Un investigador independiente realizó un análisis técnico detallado de Trae y lo que encontró fue alarmante:

Consumo de recursos fuera de lo normal: Trae lanzaba 33 procesos paralelos y consumía 5.7 GB de RAM cargando el mismo codebase que VSCode manejaba con apenas 9 procesos y 0.9 GB. Una diferencia de casi 6x en recursos para hacer el mismo trabajo.

La telemetría que se intensificaba al apagarla: El hallazgo más perturbador fue que al deshabilitar la telemetría desde los ajustes del IDE, el comportamiento no mejoraba — empeoraba. El sistema registró 500 conexiones de red en apenas 7 minutos, enviando 26 MB de datos. Cada paquete individual llegaba a los 53,606 bytes.

¿Qué contenían esos paquetes? Los payloads interceptados revelaban dos capas distintas de recolección:

Capa 1: Identificadores persistentes de hardware e información del perfil de usuario
Capa 2: Tiempos exactos de actividad, rutas completas del sistema de archivos, métricas detalladas de comportamiento incluyendo movimiento del mouse y estados de foco de ventana

Esto no es telemetría de diagnóstico. Esto es vigilancia comportamental granular.

La respuesta que hizo más ruido que la solución

Cuando el investigador reportó sus hallazgos en el servidor oficial de Discord de Trae, fue silenciado por 7 días. La razón: la palabra "tokens" estaba en una lista negra del bot de moderación del servidor.

La elección de silenciar una discusión técnica legítima sobre seguridad, en lugar de responder abiertamente, fue para muchos en la comunidad más reveladora que los propios datos técnicos.

La respuesta de ByteDance — ¿Suficiente?

Julio - Agosto 2025: Reconocimiento y parches parciales

ByteDance respondió reconociendo el problema, aunque con matices importantes. Explicaron que el toggle de telemetría en los settings solo controlaba la recolección a través del framework base de VS Code, pero que extensiones de terceros no respetaban ese control. Lanzaron actualizaciones de texto en la UI para ser más explícitos sobre la presencia de telemetría.

El investigador original actualizó su reporte reconociendo el avance, pero también confirmó que seguía pendiente una solución más profunda: un Privacy Mode dedicado, prometido para agosto.

Agosto - Septiembre 2025: Llega Privacy Mode

Trae lanzó Privacy Mode, disponible para todos los usuarios incluyendo el plan gratuito. Con él activado, la telemetría de analytics y mejora de producto se deshabilita.

Trae comunicó oficialmente: "Privacy Mode está completamente soportado en Trae IDE para usuarios Free y Pro. Tus conversaciones se mantienen privadas cuando lo necesitas."

Suena bien. Pero hay que leer la letra chica.

Lo que Privacy Mode no resuelve — La letra chica que importa

Los Términos de Servicio hablan por sí solos

Los ToS actualizados de Trae indican que pueden usar el contenido del usuario para "proveer, mantener, desarrollar y mejorar sus Servicios… entrenar sus modelos… y mantener los Servicios seguros."

La aclaración de Trae es que el código en texto plano se elimina después de procesarse — pero los embeddings y la metadata se retienen. Un embedding es una representación matemática del código que puede contener su semántica, su estructura, sus patrones. No es el código literalmente, pero sí una huella profunda de él.

Lo que la Política de Privacidad no dice

La Política de Privacidad actualizada el 21 de agosto de 2025 no enumera los endpoints específicos de telemetría que siguen activos, ni ofrece una matriz clara de qué se puede desactivar y qué no. La opacidad sigue siendo parte del diseño.

La comparación que lo dice todo

Microsoft, en su política para GitHub Copilot, se compromete públicamente a que los datos de código de usuario no se usan para entrenar modelos base. Es un compromiso claro, auditado y vinculante.

ByteDance no ha hecho un compromiso público equivalente para Trae. No porque sea imposible hacerlo — sino porque no lo han hecho.

Los tiempos de retención

Los datos personales se retienen 5 años después de terminar el servicio. Los datos no personales se retienen indefinidamente.

El escenario que todo equipo debería imaginar

Eres un desarrollador trabajando para un banco. Tu cliente te ha dado acceso al repositorio que contiene la lógica de procesamiento de transacciones, los algoritmos de detección de fraude, las integraciones con sistemas de pagos internacionales. Código que vale millones. Código que, si se filtrara, podría comprometer la seguridad financiera de miles de personas.

Abres Trae. Activas el modo agente SOLO, que planea y ejecuta tareas de forma autónoma navegando tu codebase. SOLO lee múltiples archivos, genera contexto, hace llamadas a la API.

Todo ese contexto — las rutas de archivos, la estructura del proyecto, los patrones del código, potencialmente fragmentos completos de lógica de negocio — viaja a servidores de ByteDance para ser procesado.

Privacy Mode activado. Pero embeddings retenidos. Metadata retenida. Datos no personales retenidos indefinidamente.

¿Cuántos contratos de confidencialidad acabas de violar sin saberlo?

El estado real en Febrero 2026

Aspecto	Estado
Privacy Mode disponible	✅ Sí, para Free y Pro
Telemetría completamente desactivable	⚠️ Parcialmente — telemetría básica permanece
Uso del código para entrenar modelos	⚠️ Los ToS lo permiten (código plano se borra, embeddings se retienen)
Compromiso público explícito de no entrenar con tu código	❌ No existe de ByteDance
Datos personales retenidos	⚠️ 5 años post-servicio
Datos no personales retenidos	⚠️ Indefinidamente

Resumen honesto: ByteDance movió el nivel de riesgo de inaceptable a manejable con condiciones. Eso no es lo mismo que resolverlo.

¿Qué debería exigir la comunidad de desarrollo?

La presión colectiva funciona. Las empresas cambian sus políticas cuando el costo reputacional supera el beneficio de mantenerlas. Esto es lo que deberíamos exigir como estándar mínimo a cualquier IDE con IA:

1. Compromiso público y vinculante de no entrenar con código de usuario, con auditoría independiente anual, igual o más sólido que el de Microsoft para Copilot.

2. Un Privacy Mode que sea verdaderamente total, no parcial. Si está activado, cero telemetría, sin excepciones para "monitoreo de funcionalidad".

3. Publicación de los endpoints activos de telemetría con documentación clara de qué datos viajan a cada uno y bajo qué condiciones.

4. Términos de retención de embeddings y metadata que sean razonables, limitados y auditables — no "indefinidamente".

5. Transparencia ante reportes de seguridad, no silenciamiento. Un servidor de Discord que banea la discusión de "tokens" cuando un investigador reporta un hallazgo legítimo es una señal de alerta enorme.

La regla práctica más importante

Antes de usar cualquier IDE con IA en un proyecto de cliente, hazte esta pregunta:

¿Si este código apareciera mañana en un repositorio público o en el dataset de entrenamiento de un modelo de IA, habría consecuencias legales, reputacionales o de seguridad para mi cliente o para mí?

Si la respuesta es sí, ese IDE no debería tener acceso a ese codebase. Sin importar cuánto cueste la alternativa. Sin importar qué tan bueno sea el Privacy Mode. Sin importar las promesas del marketing.

La confidencialidad del código de un cliente no es un feature opcional. Es una obligación profesional y, en muchos sectores, legal.

Conclusión — La privacidad del código no debería ser un privilegio de pago

Trae ofrece algo genuinamente atractivo: modelos de IA de calidad sin costo. Eso es valioso, especialmente para desarrolladores que están aprendiendo o en proyectos personales sin código sensible.

Pero el sector del desarrollo de software necesita establecer una norma clara: ningún IDE debería tener acceso ambiguo al código de clientes, independientemente de su precio. La transparencia y los compromisos verificables no deberían ser características premium.

Compartir este tipo de análisis, hacer preguntas difíciles en público, y exigir respuestas claras de las empresas es la única forma en que la industria avanza hacia estándares más honestos.

Si usas Trae para proyectos personales o de aprendizaje, adelante — es una herramienta poderosa. Pero si tienes código de clientes en tu máquina, esta es tu alerta.

¿Trabajas con clientes en sectores regulados como banca, salud o fintech? Comparte este artículo con tu equipo. Las decisiones sobre herramientas de desarrollo son decisiones de seguridad.

Publicado: Febrero 2026 | Categoría: Seguridad, Herramientas de Desarrollo, IA

Audiencia: Desarrolladores freelance, equipos de software, CTOs, equipos de seguridad

Tags: #Seguridad #DesarrolloDeSoftware #TraeIDE #ByteDance #PrivacidadDelCódigo #IAParaDevs #CursorVsTrae #DataPrivacy

Custom Elements: The Superpower of Svelte 5

Lenin Uzcategui — Fri, 16 May 2025 15:57:41 +0000

Svelte 5 and the Future of Truly Reusable Web Components

In today's web development ecosystem, framework fragmentation can be a headache. Can you imagine creating components that work equally well in React, Vue, Angular, or even plain HTML? With Svelte 5 and Web Components technology, this isn't just possible—it's surprisingly simple.

The Challenge

Modern frontend development is based on reusable components. However, these components often remain "trapped" within the ecosystem for which they were created. A button made in React will hardly work in a Vue application without significant modifications.

In this article, we'll explore how to create truly framework-agnostic components using Svelte 5 and Storybook 8+. Our example will be a fully customizable Alert component that will work in any framework or environment—in some cases directly, in others with minimal modifications.

What's the Problem?

Imagine this situation: your company has several teams working on different projects. Team A uses React, team B uses Vue, and new project C is being developed with Svelte.

If each team creates their own components from scratch:

Effort is duplicated
Visual and behavioral inconsistencies emerge
Maintenance becomes a nightmare
The learning curve multiplies

Furthermore, if tomorrow they decided to migrate to another framework, they would have to rewrite all the components. This represents an enormous cost in time and resources.

How to Solve It: Web Components with Svelte 5

The magic of our solution lies in the combination of Svelte 5 with Web Components (or Custom Elements) and their documentation in Storybook 8+.

The Alert component in Svelte
Documentation with Storybook
Detailed documentation with MDX (to be covered in another post...)

Let's look at the code for our Alert.svelte component:

Breaking down the code:

The magic is in this line: This directive converts our Svelte component into a Web Component that can be used in any framework or plain HTML. When you compile this component, Svelte generates a JavaScript file that, when included in any project, registers the custom element which you can use like any other HTML tag.

The rest of the code consists of the $props() directive, which automates reactivity. This reactive directive allows you to declare and destructure all the properties that the component can receive from the outside, assigning them default values, very similar to a React prop. Then there are a couple of functions: getIconSVG() to get the corresponding icon from the svgIcons object, and finally the closeAlert() function to close the notification dialog box.

Let's look at the HTML code of the component:

The structure of a Svelte component consists of the JavaScript/TypeScript script that provides functionality, the HTML which is the rendering template, and the associated style either in CSS within the same file or using tailwindcss among others. The Shadow DOM will always ensure that the CSS belongs exclusively to the defined component. In this case, it's omitted. Basically, we have a dialog tag whose style varies depending on the type of icon (info, warn, error, success, dark, default), which provides the appropriate style. Inside, there are the title and description props that will be displayed in the notification, as seen in the following image:

Documenting with Storybook

The configuration of Storybook version 8+ in a Svelte v5 project created via Vite is actually automatic, but you can refer to the official documentation for installation at StoryBook Docs, Installation. What we have then is a file with the extension Alert.stories.js, which tells the project and StoryBook where the component comes from and how to render it and add component variations. It's also possible to include a table of properties that can be modified live to observe the component's behavior, as shown in the example code.

The heart of our file begins with export default {...}. This is like the main menu of a restaurant: it tells Storybook all the basic information about our component. The title is super important—it's like your home address but for Storybook. In this case, we're saying: "Hey, place this component in the 'Garnet UI Library' folder, inside 'Notification Components', and call it 'Alert'". When you open Storybook, you'll see exactly that folder structure in the left sidebar menu. Inside that export default, we find argTypes. This section is like the instruction manual for our component.

Each property here defines:

What type of control Storybook will display (checkbox for booleans, text field, selector, etc.)
A friendly description so other developers understand what it's for
Default values and additional configuration

The table part is like adding a detailed price tag—it shows technical information in Storybook's properties table. Then we have parameters, which are like the extra menu configuration; Here we're saying: "The general description of the component is this" and "when showing examples, give them a height of 150px". It's like giving additional instructions to the chef on how to present the dish. In this case, the chef is Storybook.

Now come the most interesting parts: the stories. Each export const is like a visual example of our component in a specific situation:

render: This is the function that says "this is how I want to display my component". In Svelte, we use this standard pattern.
args: These are the specific ingredients for this version of the component. Here we're saying: "Show an alert of type 'info', with this title, this description, etc."

Each story (Default, Warn, Error, etc.) shows a different variant of the same component, like photos of the same furniture in different colors so the client can choose.

In Summary

The Storybook file is like an interactive catalog for our Alert component:

First, we define where to find it in the menu (title)
Then we explain all its customizable options (argTypes)
We add extra configuration if needed (parameters)
And finally, we show practical examples of all its variants (stories)

This way, any developer using our component can:

See how it looks in different states
Play with its properties to see how it changes
Read the documentation to understand how to use it

And all this without having to read a single line of the component's internal code. It's like test-driving a car without needing to understand how the engine works!

What Makes These Components Framework-Agnostic?

The key to understanding why our component is agnostic lies in Web Components (or Custom Elements) technology. Web Components are a set of standard web technologies that allow creating custom, encapsulated, and reusable HTML elements. When Svelte compiles a component with the customElement directive, it generates a Web Component that:

Encapsulates its style and functionality: Styles defined within the component don't affect the rest of the page.
Exposes a clear API: The component can be used through standard HTML attributes.
Is compatible with any framework or pure HTML: It doesn't depend on Svelte to function, meaning in the Svelte framework it would be native and used without modifications, and in frameworks that support web components like Astro, SolidJS, among others, the modifications are minimal or none.

In frameworks that have their own engine, their lifecycle is different, especially those using a reconciliation algorithm for their Virtual DOM; more code needs to be created to adapt the requests or states specific to the framework regarding the functionality established in the Web Component.

How to Use Our Component in Different Environments?

Once compiled, our component can be used like this:

In plain HTML:

In React:

In Vue.js:

In SolidJS:

It's that simple! Web Components are used like any standard HTML tag in both frameworks. However, as I mentioned before, if a component has more complex functional logic, for example, returning a state that needs to be obtained to perform other logic, in these types of scenarios is where the use in React and Vue.js becomes complicated since you need to add functionalities compatible with their engines, as the philosophy of state management is specific to each engine.

Advantages of Web Components with Svelte

Write once, use everywhere: The same component works in any framework or without a framework.
Optimized performance: Svelte compiles the code to highly efficient vanilla JavaScript.
Real encapsulation: Styles and functionalities don't interfere with the rest of the application.
Easy maintenance: A single component to maintain instead of multiple implementations.
Long-term compatibility: By following web standards, components are more resistant to changes in frameworks.
Reduced size: Svelte generates very compact code, resulting in lighter components.

Disadvantages

Browser support: Although most modern browsers support Web Components, there may be issues in older browsers.
Custom Elements limitations: Some advanced functionalities specific to each framework may not be available.
Initial learning curve: Understanding Svelte's mental model and Web Components takes time.
Less mature ecosystem: Compared to React or Vue, the Svelte and Web Components ecosystem is more recent.

How to Overcome Web Components Disadvantages

Browser support Solution: Use polyfills for compatibility with older browsers.

Custom Elements limitations Solution: Design a clear event API and use standard communication patterns.

Less mature ecosystem Solution: Leverage existing libraries and contribute to the ecosystem.

Share your components as open source to enrich the ecosystem
Join communities like Web Components Community Group
Implement good testing and documentation practices for your components

Ease of Implementation by Framework

From easiest to most difficult:

Vanilla HTML: Simply import the script and use the component.
Svelte: Native compatibility and perfect integration.
Astro: Excellent support for Web Components.
SolidJS: Natively supports Web Components.
Vue: Good integration with Custom Elements.
React: Requires some adjustments to handle events and properties.

Why Architects Should Consider This Solution

As a software architect or technical leader, there are powerful reasons to consider Web Components in Svelte:

Visual and functional consistency: Ensures that all teams use the same components, regardless of the framework.
Technical debt reduction: Less duplicate code means fewer bugs and easier maintenance.
Technological flexibility: Teams can change frameworks without needing to rewrite the basic components.
Team scalability: Different teams can work on different parts of the application using different technologies while maintaining a coherent user experience.
Future-proof: Being based on web standards, these components are more likely to remain relevant in the future.

Conclusion

The combination of Svelte 5 and Web Components represents a revolutionary approach to user interface development. It allows creating truly agnostic components that work in any environment, reducing duplication of efforts and ensuring a consistent user experience. Additionally, incorporating Storybook as a documentation tool significantly elevates the value of these components. By documenting each variant, property, and possible behavior, Storybook not only facilitates the use of components for other developers but also serves as a visual and functional source of truth. This living documentation allows teams to test, visualize, and understand how components work without needing to read their internal code, accelerating adoption and reducing the learning curve. Ultimately, a well-documented agnostic component with Storybook becomes a high-value asset that transcends frameworks and teams, materializing the true potential of reuse in modern frontend development.

Although it's not the perfect solution for all use cases, it's a powerful option that architects and developers should seriously consider, especially in organizations with multiple teams or projects using different technologies.

What did you think of this article on Svelte 5 and Web Components? We'd love to hear about your experience implementing these solutions in your projects. Have you found other advantages or challenges not mentioned? This agnostic component approach is revolutionizing the way we build interfaces, and we've barely scratched the surface. In upcoming articles, we'll delve into topics such as advanced documentation integration in Storybook, Web Component performance in large-scale applications, and how to build complete design systems with this architecture. We'll also explore npm deployment and how to perform tests in Storybook. Stay connected to discover how to take your components to the next level, and don't hesitate to share this article with other developers interested in building more efficient and coherent interfaces!