Cómo se construye la escalera

Lo interesante es que quien construyó esa escalera no era un mal desarrollador. En el mundo antiguo, hasta el flujo más inocente — cargar un usuario y luego su avatar — acababa inevitablemente así:

func loadProfile(id: String,
                 completion: @escaping (Result<Profile, Error>) -> Void) {
    fetchUser(id) { result in
        switch result {
        case .success(let user):
            fetchAvatar(user.avatarURL) { avatarResult in
                switch avatarResult {
                case .success(let avatar):
                    completion(.success(Profile(user: user, avatar: avatar)))
                case .failure(let error):
                    completion(.failure(error))
                }
            }
        case .failure(let error):
            completion(.failure(error))
        }
    }
}

Veinte líneas para dos peticiones. La lógica real son tres palabras — coger usuario, coger avatar, combinar — y ni siquiera se ve en el código. Cada capa arrastra su propia gestión de errores, y si olvidas llamar a completion en una rama, la app se queda colgada en silencio. Ningún compilador te lo va a decir.

await: espera, pero sin bloquear

La misma función con async/await:

func loadProfile(id: String) async throws -> Profile {
    let user = try await fetchUser(id)
    let avatar = try await fetchAvatar(user.avatarURL)
    return Profile(user: user, avatar: avatar)
}

Donde ves await, la función se pausa sin bloquear el hilo; el sistema aprovecha para ejecutar otro trabajo. La gestión de errores pasó de los closures a throws: se acabó desenvolver Result a mano, se acabaron los completion olvidados. Si falta una rama, te enteras al compilar, no en producción.

No pongas en fila el trabajo independiente

En el código de arriba el avatar depende del usuario, así que esperar en orden es razonable. Pero hacer await de tres peticiones independientes una tras otra es puro desperdicio. async let las arranca todas a la vez:

func loadDashboard(for id: String) async throws -> Dashboard {
    async let profile = fetchProfile(id)
    async let feed = fetchFeed(id)
    async let badges = fetchBadges(id)

    return try await Dashboard(profile: profile,
                               feed: feed,
                               badges: badges)
}

El tiempo total ya no es la suma de las tres peticiones, sino la más lenta. En aquel proyecto heredado, este único cambio llevó la pantalla de inicio de 1,8 segundos a 700 milisegundos. Sin medirlo no lo habríamos creído.

Estado compartido: entra el actor

La parte de la concurrencia que de verdad quema son las condiciones de carrera (data races): dos tareas escribiendo en el mismo diccionario a la vez — a veces un crash, a veces datos corruptos en silencio. La respuesta de Swift es el actor: solo una tarea puede tocar su estado a la vez, y el compilador lo garantiza:

actor ImageCache {
    private var store: [URL: Image] = [:]

    func image(for url: URL) -> Image? {
        store[url]
    }

    func insert(_ image: Image, for url: URL) {
        store[url] = image
    }
}

// El acceso siempre pasa por await:
let cache = ImageCache()
await cache.insert(avatar, for: url)
let hit = await cache.image(for: url)

Antes montábamos esto con candados sobre una DispatchQueue y esperábamos que todo el mundo los usara bien. La esperanza no es una estrategia de concurrencia.

async/await no acorta el código; lo hace legible. La ganancia no está en las líneas — está en la cara de quien abra ese archivo dentro de seis meses.

Aquella función del 'no entrar' hoy tiene treinta líneas, y cada persona nueva del equipo la entiende a la primera. Todavía no hemos conocido a nadie que eche de menos la escalera de callbacks.

Cómo nace una fuga

Mira esta función — podría salir de un libro de texto:

void process() {
    Widget* w = new Widget();

    if (!w->init()) {
        return;            // fuga: nunca se llega al delete
    }

    w->run();
    delete w;
}

Si init() falla, delete no se ejecuta y el Widget queda huérfano en memoria. Si run() lanza una excepción, misma historia. El problema no es el descuido — es confiar a un humano la regla de 'limpia en cada ruta de salida'. Los humanos olvidan. Cuanto más crece el código, más olvidan.

RAII: deja que el objeto limpie

La respuesta de C++ tiene un nombre que suena a burocracia — Resource Acquisition Is Initialization — pero la idea cabe en una frase: ata el recurso a la vida de un objeto. Cuando el objeto sale del ámbito, su destructor se ejecuta y libera el recurso. No importa cómo salgas: flujo normal, return temprano, excepción... el destructor corre siempre:

class FileHandle {
public:
    explicit FileHandle(const char* path)
        : file_(std::fopen(path, "r")) {}

    ~FileHandle() {
        if (file_) std::fclose(file_);
    }

    // Copia desactivada: dos objetos no deben cerrar el mismo archivo.
    FileHandle(const FileHandle&) = delete;
    FileHandle& operator=(const FileHandle&) = delete;

    std::FILE* get() const { return file_; }

private:
    std::FILE* file_;
};

Ya no existe la tarea de 'acordarse de cerrar el archivo'; en cuanto un FileHandle sale del ámbito, el archivo se cierra. std::lock_guard, std::vector, std::string — la biblioteca estándar está construida sobre este mismo patrón. Probablemente llevas años usando RAII sin ponerle nombre.

Punteros inteligentes: vivir sin new/delete

El mismo patrón viene preempaquetado para punteros: unique_ptr para propiedad única, shared_ptr para propiedad compartida.

#include <memory>

auto w = std::make_unique<Widget>();
if (!w->init()) {
    return;               // sin fuga; w se limpia solo
}
w->run();

// Propiedad compartida: el objeto se libera cuando se va el último dueño.
auto config = std::make_shared<Config>();
useConfig(config);

Toda la clase de errores del process() original — el delete olvidado, el doble delete, la fuga en la ruta de la excepción — desapareció con un cambio de una línea. ¿El coste en rendimiento? Cero para unique_ptr; el código compilado es idéntico al de un puntero crudo.

Una advertencia honesta: shared_ptr no lo cura todo. Su contador de referencias es atómico, así que no es gratis, y las referencias cíclicas — A sostiene a B, B sostiene a A — nunca dejan que el contador llegue a cero. Que tu opción por defecto sea unique_ptr; pasa a shared_ptr solo cuando la propiedad sea genuinamente compartida, y usa weak_ptr en el borde con riesgo de ciclo.

Si ves new y delete a pelo en código C++ moderno, o está pasando algo muy especial o hay un bug esperando. La experiencia dice: casi siempre lo segundo.

Volviendo a aquella sesión de valgrind a las dos de la madrugada: esa fuga la arreglamos a mano, porque la base de código no estaba lista para punteros inteligentes. Al mes siguiente pusimos la regla — el código nuevo no escribe new a pelo. No hemos vuelto a salir de cacería.

& da la dirección, * la sigue

int x = 42;
int *p = &x;          // p guarda la dirección de x

printf("%d\n", *p);   // 42 — el valor al que apunta p
*p = 7;               // x ahora vale 7; p apunta a ella

&x responde a '¿dónde vive x?'; *p responde a '¿qué hay en el sitio al que apunta p?'. Son inversos. Cuando escribes *p = 7 estás cambiando x directamente, porque ambos miran a la misma dirección.

El primer fruto real de esta idea son las funciones que pueden modificar variables de fuera. En C todo argumento se pasa por copia — pero pasa una dirección y la función alcanza el dato real:

void swap(int *a, int *b) {
    int tmp = *a;
    *a = *b;
    *b = tmp;
}

int i = 1, j = 2;
swap(&i, &j);         // i == 2, j == 1

Si alguna vez te has preguntado por qué scanf necesita &num: esa es la respuesta. Le das la dirección para que pueda escribir el valor leído en tu variable.

Arrays: parientes más cercanos de lo que parecen

El hecho que más sorprende a quien empieza con C: el nombre de un array, en la mayoría de contextos, se convierte en la dirección de su primer elemento. A esto se le llama 'decay':

int nums[3] = {10, 20, 30};
int *p = nums;              // igual que &nums[0]

printf("%d\n", *(p + 2));   // 30
printf("%d\n", p[2]);       // 30 — exactamente lo mismo

p[2] y *(p + 2) son dos escrituras de la misma expresión; los corchetes son solo un atajo. El matiz que se le escapa a la gente: p + 2 avanza dos int, no dos bytes. La aritmética de punteros tiene en cuenta el tamaño del elemento por ti.

const: una promesa al compilador

Toda función que recibe un puntero recibe también el poder de modificar el dato. const es la forma de devolver ese poder:

void printName(const char *name) {
    // *name = 'X';  -> error de compilación
    printf("Hola, %s\n", name);
}

Una palabra clave diminuta haciendo dos trabajos: le garantiza a quien llama que no tocarás sus datos, y a ti te da un error de compilación si lo intentas por accidente. Un seguro gratis — sé generoso con él en tus firmas.

La mala fama de los punteros viene, creo, de la mala enseñanza. Lanzarse a la sintaxis antes de asentar el concepto de dirección — sin dibujar cajas y flechas — convierte los símbolos en magia sin sentido. En cambio, una vez que la idea de dirección encaja, los arrays, las cadenas, la memoria dinámica y las listas enlazadas se apilan ordenadamente sobre el mismo cimiento. No hay nada que temer; esto es el corazón de C.

Misma pregunta, dos respuestas distintas

El software al que estamos acostumbrados produce la misma salida para la misma entrada. Un modelo de lenguaje no — y en lugar de pelear contra eso, construyes la arquitectura a su alrededor. Regla número uno: nunca te fíes de la salida del modelo en crudo. Si esperas datos estructurados, valida contra un esquema y reintenta si no encaja:

const Invoice = z.object({
  vendor: z.string(),
  total: z.number().positive(),
  currency: z.enum(["TRY", "USD", "EUR"]),
});

async function extractInvoice(text: string) {
  for (let attempt = 1; attempt <= 3; attempt++) {
    const raw = await model.complete(prompt(text));
    const parsed = Invoice.safeParse(tryJson(raw));
    if (parsed.success) return parsed.data;
  }
  throw new ExtractionFailed();
}

Cuando tres intentos siguen sin encajar en el esquema, lo correcto es un error honesto al usuario — no aceptar datos malos en silencio. Un sistema capaz de decir 'no estoy seguro' gana mucha más confianza que uno que habla con seguridad sin tenerla.

El contexto vale más que el modelo

La frase que más oímos en los proyectos: '¿Y si ponemos un modelo más potente?' Normalmente no ayuda — porque lo que determina la calidad de la respuesta es, sobre todo, lo que le enseñas al modelo. En una arquitectura RAG la ingeniería de verdad vive en la capa de búsqueda: un sistema que no encuentra el documento correcto va a inventar, sea cual sea el modelo. No tiene otro material con el que trabajar.

Atiborrar la ventana de contexto tampoco es la solución. Diez documentos irrelevantes distraen al modelo e inflan la factura. En nuestras mediciones, dos párrafos relevantes ganaron sistemáticamente a veinte añadidos 'por si acaso'. Menos, pero certero, gana.

No cambies prompts a ciegas

Cambiaste tres palabras del prompt; ¿el sistema es mejor ahora? Sin mediciones, la respuesta honesta es 'ni idea'. Para cada flujo crítico mantenemos un conjunto de evaluación compilado de preguntas reales de usuarios — entradas y comportamientos esperados, un archivo corriente en control de versiones:

{
  "input": "¿Quién aprobó la factura de AWS del mes pasado?",
  "expect": {
    "must_cite_source": true,
    "must_not_contain": ["supongo", "probablemente"],
    "tool_called": "search_invoices"
  }
}

Cada vez que cambia el prompt o el modelo, el conjunto se ejecuta de nuevo; si la puntuación baja, el cambio no llega a la rama principal. Es el test de regresión del mundo LLM. Montarlo llevó medio día; a cambio, los despliegues dejaron de ser apuestas.

La factura de tokens y el vacío de tres segundos

En una demo nadie mira el coste; en producción cada petición es dinero real. El remedio más eficaz es el enrutamiento: manda la clasificación y los resúmenes cortos a un modelo pequeño, y reserva el grande para las preguntas de verdad difíciles. Esa única decisión recortó nuestra factura a más de la mitad. En cuanto a la latencia, el streaming no es negociable: si la primera palabra aparece a los 300 milisegundos, al usuario no le importa un total de tres segundos. Tres segundos mirando una pantalla en blanco, en cambio, son una eternidad.

Una demo es el escaparate del camino feliz; un producto es la suma de los caminos infelices. Con los LLM, esa brecha es más ancha que nunca.

El abismo se puede cruzar. Validación de esquemas, contexto certero, un conjunto de evaluación y disciplina de costes — juntos convierten una demo hipnotizante en un producto fiable. En orden, y sin prisas.

LCP: cuándo 'llegó' la página

Largest Contentful Paint marca el momento en que aparece la pieza de contenido más grande — normalmente la imagen de cabecera o el titular. En aquel proyecto el culpable era una imagen de cabecera descubierta tarde: el navegador descargaba primero el CSS y solo entonces se enteraba de que la imagen existía. La cura es avisarle desde el principio:

<link
  rel="preload"
  as="image"
  href="/hero.avif"
  imagesrcset="/hero-800.avif 800w, /hero-1600.avif 1600w"
/>

Y luego está el clásico de las fuentes web: los sitios que ocultan el texto hasta que llega la fuente le enseñan al usuario una larga pantalla vacía. font-display: swap pinta primero con una fuente del sistema y cambia cuando aterriza la de marca:

@font-face {
  font-family: "Space Grotesk";
  src: url("/fonts/space-grotesk.woff2") format("woff2");
  font-display: swap;
}

Esos dos cambios, más convertir las imágenes a AVIF, llevaron el LCP de aquel sitio de 4,1 segundos a 1,9. Nada exótico — solo facilitarle el trabajo al navegador.

INP: he pulsado, ¿por qué no pasa nada?

Interaction to Next Paint mide el tiempo desde una interacción hasta la primera respuesta visible. El enemigo principal es el JavaScript que bloquea el hilo principal durante cientos de milisegundos: mientras el navegador está ocupado con una tarea larga, los clics hacen cola y la interfaz se siente congelada. La cura es trocear el trabajo:

async function processRows(rows) {
  for (const [i, row] of rows.entries()) {
    handle(row);
    if (i % 100 === 0) {
      // Deja respirar al navegador cada 100 filas:
      await new Promise((r) => setTimeout(r, 0));
    }
  }
}

Tosco pero eficaz: el bucle largo ahora cede el hilo principal periódicamente y los clics pendientes se procesan. Hay herramientas más elegantes — scheduler.yield(), Web Workers — pero el principio no cambia: el hilo principal pertenece al usuario; tú estás de visita.

CLS: iba a pulsarlo y se movió

Cumulative Layout Shift mide cuánto salta el contenido durante la carga. Todo el mundo lo ha vivido: el párrafo que estás leyendo se hunde porque un banner apareció tarde ahí arriba. La causa es casi siempre la misma — imágenes y embeds sin tamaño declarado. En CSS moderno el arreglo son dos líneas:

img {
  aspect-ratio: 16 / 9; /* el hueco se reserva antes de cargar la imagen */
  width: 100%;
  height: auto;
}

En cuanto el navegador conoce la proporción, reserva el sitio por adelantado; nada salta. Mismo principio para banners y anuncios dinámicos: reserva el área primero, coloca el contenido dentro después.

Los tests de laboratorio miden tu ordenador; el RUM mide el teléfono de tu usuario. A la hora de decidir, mira el segundo.

La lección que nos dejó aquel proyecto: el rendimiento no es una limpieza de primavera puntual — se gestiona como un presupuesto. Cada funcionalidad nueva gasta de él. Si mides continuamente, la deuda se ve antes de acumularse; si dejas de medir, vuelve con intereses.

El pantano de los booleanos

El ejemplo clásico, porque sigue en todas partes: tres campos sueltos — isLoading, isError, data. Tres campos te dan ocho combinaciones; tres tienen sentido. Un estado que está cargando y fallido a la vez no existe lógicamente — pero existe en el sistema de tipos, y un día aparece en producción. Modela el estado como una unión discriminada y las combinaciones absurdas se caen del lenguaje:

type State =
  | { status: "loading" }
  | { status: "error"; error: Error }
  | { status: "success"; data: User };

data ahora solo es alcanzable en la rama success. El código que intenta leerlo mientras carga ni siquiera compila; esa clase de bug muere en el editor, mucho antes de producción.

El bonus menos conocido de este patrón: combinado con switch, el compilador también caza las ramas que faltan:

function render(state: State) {
  switch (state.status) {
    case "loading":
      return spinner();
    case "error":
      return alert(state.error);
    case "success":
      return table(state.data);
    default: {
      const missing: never = state; // revienta aquí si se añade un estado
      return missing;
    }
  }
}

Seis meses después, cuando alguien añada { status: "empty" } a State, este switch dejará de compilar y cada sitio que necesite actualizarse se delatará solo. Tu lista de tareas la escribe el compilador.

Cuando todo es un string

Id de usuario: string. Email: string. Número de pedido: string... Cuando todos son el mismo tipo, nada te impide escribir sendEmail(user.id). Los tipos con marca (branded types) convierten esa confusión en un error de compilación:

type UserId = string & { readonly __brand: "UserId" };
type Email = string & { readonly __brand: "Email" };

function sendEmail(to: Email) {
  /* ... */
}

sendEmail(user.id); // error de compilación — un id no es un Email

En tiempo de ejecución son strings corrientes; el coste es cero. Pero en valores donde confundirse sale caro — dinero, fechas, unidades de medida — esta valla de coste cero evita accidentes reales. El Mars Climate Orbiter se perdió por una confusión entre unidades métricas e imperiales; un sistema de tipos bien planteado habría cazado ese error antes del lanzamiento.

Valida en la frontera, confía dentro

Los tipos solo valen dentro de tu propio código. Decirle as User al JSON que llega de una API no es un hecho — es un deseo. Haz validación en tiempo de ejecución en la frontera; dentro, confía en tus tipos con la conciencia tranquila:

const User = z.object({
  id: z.string(),
  name: z.string(),
  age: z.number().int().min(0),
});

const user = User.parse(await res.json()); // revienta aquí si no encaja

Así el fallo ocurre en la puerta por donde entran los datos, con un mensaje legible — no tres capas más abajo como 'undefined is not a function'.

as es una expresión de esperanza; parse es una prueba. Exige pruebas en la frontera.

Cuando empiezas a tratar los tipos como herramienta de diseño, pasa algo interesante: ves los huecos de tu diseño mientras modelas, antes de escribir código. El compilador te obliga a responder '¿qué pasa con este campo en aquel estado?'. Una definición de tipo que se siente mal al escribirla es, muy a menudo, el primer síntoma de una mala decisión de diseño.

El test de cinco minutos: suelta el ratón

La lectura más rápida del estado de tu sitio: guarda el ratón y navega solo con Tab, Enter y las flechas. ¿Ves dónde está el foco? ¿Llegas a todos los botones? ¿Puedes cerrar ese menú con Escape? Una interfaz que suspende este test está rota no solo para usuarios con discapacidad, sino para cualquiera que prefiera trabajar con el teclado.

El error que este test caza más a menudo es bien conocido: fabricar botones con divs.

<!-- Parece un botón, no hace nada del trabajo: -->
<div class="btn" onclick="save()">Guardar</div>

<!-- Teclado, foco, Enter, lector de pantalla — todo gratis: -->
<button type="button" onclick="save()">Guardar</button>

El primero funciona con ratón y ahí se acaba: no puede recibir foco, no oye Enter, nunca le dice a un lector de pantalla que es un botón. Podrías parchear todo eso con tabindex, role y keydown — pero ¿para qué? El elemento HTML correcto hace con cero líneas lo que cien líneas de parches ARIA no consiguen.

La estructura se cuenta, no se muestra

Quien usa un lector de pantalla no escanea la página con la vista; escucha, saltando entre encabezados y puntos de referencia (landmarks). Por eso <nav>, <main>, <header> y una jerarquía de encabezados sensata no son una estética de 'código limpio' — son un instrumento de navegación real. El texto alternativo es parte del mismo trabajo, y un oficio en sí mismo: 'gráfico' no aporta información; 'gráfico de líneas que muestra los ingresos subiendo un 20 por ciento en el último trimestre' sí. La regla es simple: no describas la imagen, transmite lo que dice.

El color no puede hablar solo

Si marcaste los campos inválidos del formulario solo con rojo, para un usuario daltónico no marcaste nada — y eso es uno de cada doce hombres, no un error de redondeo. El color siempre necesita un segundo canal: un icono, una etiqueta, un patrón. El contraste tampoco se negocia; ese elegante texto gris claro desaparece en la pantalla de un móvil a mediodía.

Del movimiento se habla menos, pero para algunos usuarios no es cuestión de comodidad — es salud: los grandes parallax y las transiciones aparatosas pueden provocar náuseas físicas reales en personas con trastornos vestibulares. Respetar al usuario que pidió a su sistema reducir el movimiento es una media query:

@media (prefers-reduced-motion: reduce) {
  *,
  *::before,
  *::after {
    animation-duration: 0.01ms !important;
    transition-duration: 0.01ms !important;
  }
}

Los subtítulos se inventaron para usuarios sordos; hoy todos vemos vídeos con ellos en el metro. Lo que se diseña para la restricción se vuelve más claro para todos.

Desde aquel test de usuarios, la regla del equipo es: cada componente nuevo se prueba con teclado antes del merge, cada imagen llega con su texto alternativo, cada color se elige con su contraste. Sobre el papel parece trabajo extra; en la práctica, al lado del coste de arreglarlo después, hacerlo bien desde el principio sale casi gratis.

No lo rastrees todo en profundidad

Por defecto, Vue hace reactivo cada nivel de un objeto. Ponerle un rastreador a cada uno de 5.000 puntos de un gráfico solo quema memoria — total, nunca mutas esos puntos uno a uno. Si reemplazas los datos en bloque, con rastrear la referencia basta:

import { shallowRef } from "vue";

const points = shallowRef<Point[]>([]);

// Reemplaza en bloque cuando llegan datos nuevos — un solo disparo:
async function refresh() {
  points.value = await fetchPoints();
}

La regla en la práctica: si reasignas en lugar de mutar, usa shallowRef. En nuestro panel fue la mayor ganancia individual; la memoria bajó a ojos vista y el tirón en las actualizaciones grandes desapareció.

computed gordo, cadena perezosa

El segundo culpable era un computed gigante que lo hacía todo: filtrar, ordenar, agrupar, sumar — todo en uno. Cualquier dependencia que se moviera relanzaba la cadena entera. Lo partimos:

// Antes: todo en un computed, todo se rehace con cualquier cambio.
// Después: cada eslabón corre solo cuando cambia su propia entrada.
const filtered = computed(() => rows.value.filter(matches(query.value)));
const sorted = computed(() => sortBy(filtered.value, sortKey.value));
const total = computed(() => sum(sorted.value, "amount"));

Cuando cambia la clave de ordenación, el filtrado ya no se repite; solo se recalculan sorted y lo que viene después. Los computed pequeños son más rápidos y más legibles — de todos modos nadie sabía qué pasaba dentro del gigante.

v-memo: potente, pero afilado

El toque final: v-memo en las filas de la tabla. Una fila se salta el re-render mientras sus dependencias no cambien:

<tr
  v-for="row in rows"
  :key="row.id"
  v-memo="[row.id === selectedId, row.updatedAt]"
>
  ...
</tr>

Al cambiar la selección, de las 5.000 filas solo se redibujan dos — la que estaba seleccionada y la nueva. Pero seamos honestos: v-memo es un cuchillo afilado. Si te dejas algo en la lista de dependencias, le has dicho a Vue 'no actualices nunca esta fila' y la interfaz se queda obsoleta en silencio. Nosotros lo usamos solo sobre un cuello de botella medido — nunca 'por si acaso'.

Mide primero, optimiza después — pero una vez medido, tampoco te cortes. La optimización a ojo crea más problemas de los que resuelve.

El resultado: el primer pintado se redujo a la mitad, las congelaciones al escribir desaparecieron y el código quedó más legible que antes. Esa es la parte satisfactoria del trabajo de rendimiento — con el diagnóstico correcto, el arreglo suele ser cuestión de unas pocas líneas.

Decisiones, no valores

Lo que un sistema de diseño estandariza de verdad no son los colores — son las decisiones: ¿cuántas variantes necesita un botón? ¿Cuándo lleva sombra una tarjeta? ¿Cuándo se usa el color de error — y más importante, cuándo no? Una paleta elegida antes de responder esas preguntas es una bonita colección de colores, nada más. Los valores son la salida de las decisiones, no la entrada.

Tres capas: crudo, semántico, componente

Nuestra arquitectura de tokens tiene tres capas, y los componentes nunca miran valores crudos — solo roles semánticos:

// 1) Valores crudos — sin significado, solo constantes:
@berry-500: #ff3d77;
@ink-900: #0a0a10;

// 2) Roles semánticos — 'para qué sirve este valor':
@color-danger: @berry-500;
@surface-base: @ink-900;

// 3) Tokens de componente — un uso concreto:
@button-danger-bg: @color-danger;

A primera vista parece una indirección innecesaria — hasta que llega la primera petición de tema. Tema oscuro, tema blanco de marca, alto contraste: todos salen cambiando solo la segunda capa, sin tocar una línea de código de componentes. En el momento en que escribes #ff3d77 dentro de un componente, esa flexibilidad se ha ido; el valor ya vive ahí y no viaja.

Resiste la inflación de variantes

En el lado de los componentes el principio es el mismo: un Button ofrece 'primario, secundario, peligro' — no 'botón azul, botón rojo'. El diseñador dice 'esta acción es destructiva', el desarrollador elige la variante danger; de qué color sea es asunto interno del sistema, no de la página.

Mantener bajo el número de variantes es una batalla consciente. Cada variante nueva es otra superficie que testear, documentar y mantener coherente. Aquellos 14 botones de nuestro primer sistema nos dieron la lección: todo lo que se añade 'por si acaso' se convierte en el rincón del sistema que antes se pudre.

La única regla dura

La regla que lleva dos años manteniendo vivo el sistema cabe en una frase: ningún valor que no esté en el diseño entra en el código, ningún componente que no esté en el código entra en el diseño. Ambos lados beben de la misma fuente de tokens. La regla a veces molesta — la tentación de 'es cosa de dos minutos, lo escribo a mano y ya' no muere nunca — pero son exactamente esos trabajos de dos minutos los que matan los sistemas. El CSS de caso especial es la primera señal de podredumbre; deja entrar uno y vendrán más.

Un sistema de diseño no es un proyecto — es un acuerdo. Los proyectos terminan; un acuerdo vive mientras ambas partes lo honren.

Nuestro segundo sistema lleva seis meses creciendo sin una sola línea de CSS de caso especial. Abrir una página nueva ya no significa escribir CSS; significa componer piezas existentes. Y todo lo que aprendimos del naufragio del primero sostiene a este segundo — que quizá sea el verdadero primer paso para construir un sistema de diseño: estrellar uno.

No reinventes el muelle

Las animaciones de muelle (spring) de iOS son producto de más de una década de ajuste fino. Una animación con la duración correcta pero la curva equivocada deja en el usuario una sensación de 'algo raro' que no sabe explicar. Teniendo la de verdad a mano, no hay motivo para dibujar curvas a mano:

withAnimation(.spring(response: 0.35, dampingFraction: 0.8)) {
    isExpanded.toggle()
}

Dos parámetros, y la animación habla el idioma de la plataforma. La respuesta háptica vive en la misma categoría de victoria barata: un toquecito en el momento justo — sensoryFeedback(.success, trigger:) — le da a una acción la sensación de que 'ha pasado de verdad'. Esto no es decoración; son los ladrillos de la confianza del usuario.

Mantén las vistas tontas

El único principio al que nos aferramos con fuerza en la arquitectura: las vistas son tontas. No saben de lógica de negocio; reciben datos y dibujan. La gestión de estado vive en la capa de contenedores, la navegación en la suya:

struct AvatarView: View {
    let user: User

    var body: some View {
        HStack(spacing: 12) {
            Circle()
                .fill(.pink.gradient)
                .frame(width: 44, height: 44)
            Text(user.name)
                .font(.headline)
        }
    }
}

El beneficio cotidiano de esta separación aparece en las previews: una vista tonta se puede previsualizar sola, sin arrancar la app. Nos sentamos con la diseñadora mirando la misma pantalla y zanjamos el debate de 'este hueco, ¿4 u 8?' sobre el código, al momento. Las previews se convirtieron en nuestro documento de diseño vivo; la brecha del '¿será igual de verdad?' entre Figma y el código se cerró.

Saber dónde está la frontera

SwiftUI ha madurado, pero no es el arma de todas las batallas. Editores de texto que exigen control milimétrico, interfaces de cámara, comportamientos de scroll muy particulares — ahí seguimos bajando a UIKit y tendiendo el puente con UIViewRepresentable. No hay derrota en ello; el oficio está precisamente en saber dónde trazar la línea. La postura dogmática de 'todo tiene que ser SwiftUI' es la manera más fiable de convertir una tarea simple en una epopeya.

La pregunta ya no es '¿puede hacerlo SwiftUI?' — es '¿dónde se hace más limpio?'

Donde estamos hoy: la sensación nativa sale casi gratis, y el esfuerzo se invierte en tus propias decisiones de producto. Un equipo de una sola persona que respete los detalles puede lanzar algo con calidad de App Store en semanas. '¿No habría funcionado Flutter?' Habría funcionado. Pero la diferencia se siente en esos primeros tres segundos que los usuarios no saben poner en palabras.

La comodidad del cambio atómico

La promesa real de un monorepo es una palabra: atomicidad. Renombra un campo en el esquema de la API y el código web y móvil que lo consume se actualiza en el mismo pull request. Lo que se rompa está ahí mismo, en el diff, delante de tus ojos. En repositorios separados el mismo trabajo se convierte en el baile de versiones: publica el paquete, súbelo en tres repositorios, mantén una tabla de qué versión es compatible con cuál. En un solo repositorio, la rama principal es coherente consigo misma en todo momento — para nosotros, esa fue la frase que zanjó el debate de arquitectura.

El montaje: menos de lo que crees

Nuestra receta es pnpm workspaces + Turborepo; el núcleo son dos archivos pequeños:

# pnpm-workspace.yaml
packages:
  - "apps/*" # web, mobile, api
  - "packages/*" # compartido: ui, config, api-client

{
  "tasks": {
    "build": {
      "dependsOn": ["^build"],
      "outputs": ["dist/**"]
    },
    "test": { "dependsOn": ["build"] }
  }
}

^build significa: antes de compilar un paquete, compila aquello de lo que depende. Turborepo deduce el grafo de tareas y sirve de caché todo lo que no ha cambiado. A medida que el repositorio crece, esa caché vale oro — el repositorio triplicó su tamaño y nuestra CI sigue siendo más rápida que el primer día.

El asunto de verdad: disciplina de capas

La mala noticia: las herramientas no te van a salvar. Donde colapsan los monorepos no es en lo técnico sino en lo disciplinario — las fronteras se difuminan, todo el mundo mete la mano en todos los paquetes, y seis meses después sostienes una maraña de dependencias del tamaño de un repositorio. Nuestra regla es unidireccional: las apps pueden depender de los paquetes; los paquetes de las apps, jamás. Y la regla se la confiamos al lint, no a las personas:

{
  "rules": {
    "import/no-restricted-paths": ["error", {
      "zones": [
        { "target": "./packages", "from": "./apps" }
      ]
    }]
  }
}

Automatizada la prohibición, se acaba también el debate: una violación es una marca roja en la CI, no una diferencia de opiniones en la code review. La gente gasta su energía en el trabajo, no en recordar reglas.

Cuando el repositorio crezca, añade automatización, no reglas. Una regla que imponen las herramientas es permanente; una que la gente recuerda dura hasta que esa persona se va de vacaciones.

Una nota al pie honesta: un monorepo no es gratis. La CI cuesta esfuerzo de montar, el historial de git se abarrota y, mal configurado, todos acaban esperando a todos. Para productos que no comparten contrato y viven vidas separadas seguimos recomendando repositorios separados. Pero desde aquel bug de tres días en producción, no nos cabe en la cabeza que código que habla el mismo contrato viva en casas distintas.