La idea es sencilla: que tareas, proyectos, agentes, skills, automatizaciones, workspaces y decisiones vivan en un mismo sistema operativo de trabajo.

No quiero otro «chat con IA».

Quiero una herramienta donde pueda crear y priorizar tareas, lanzar automatizaciones con control, revisar qué agente hizo qué, mantener contexto y operar el día a día sin perderme entre herramientas.

El objetivo no es hacer algo llamativo, sino algo fiable: simple, rápido, robusto y predecible.

Pronto abriré una fase limitada para betatesters.

Me interesa explorar una pregunta: ¿Qué debería tener una plataforma para orquestar trabajo con IA de forma útil, segura y realmente operativa?

Google ha puesto nombre a una intuición que muchos creadores ya estaban sintiendo: vibe design. Con Stitch, Google Labs propone un canvas AI-native para crear interfaces de alta fidelidad a partir de lenguaje natural, imágenes, texto o código. La promesa es directa: describir una intención, una sensación o un objetivo de producto, y convertirlo en una interfaz editable.

Para quienes trabajan con WordPress, Bricks, Elementor o cualquier builder visual, esto no es una curiosidad externa: es una pista de hacia dónde va la interfaz de creación. Durante años, el builder visual ha sido una forma de acercar el diseño web a personas que no querían escribirlo todo desde cero. Ahora, herramientas como Stitch sugieren un paso más: no solo mover cajas y controles, sino conversar con el sistema.

La idea de vibe design no significa diseñar sin criterio. Significa empezar desde una dirección —«quiero una experiencia editorial, limpia, con sensación premium, para una comunidad de builders»— y dejar que la IA proponga estructuras, pantallas y variaciones. El reto ya no es producir una primera versión: el reto es saber juzgarla.

Aquí hay tres implicaciones para los builders visuales:

1. La primera versión será cada vez más barata. Crear un hero, una pantalla o un flujo base dejará de ser el cuello de botella. El valor estará en seleccionar, corregir y llevar esa propuesta a un sistema real.

2. El criterio visual pesará más, no menos. Cuando cualquiera pueda generar pantallas, la diferencia estará en la jerarquía, el ritmo, la tipografía, la densidad, la accesibilidad y la coherencia. La IA puede producir opciones; alguien tiene que dirigirlas.

3. Los builders tendrán que abrirse a flujos híbridos. Stitch no vive en el mismo espacio que Bricks, pero marca una expectativa: que una herramienta visual pueda entender intenciones, iterar y conectar con código. Los builders que sigan siendo solo paneles de controles se sentirán más lentos.

Para Flowtitude, el tema es especialmente interesante porque une IA, diseño, WordPress y productividad. La pregunta no es si Stitch reemplazará a Figma o a Bricks. La pregunta es qué partes del proceso visual se van a volver conversacionales.

El futuro cercano puede ser muy híbrido: pensar con prompts, estructurar con IA, refinar con criterio, convertir a componentes y publicar en un builder. En ese flujo, el creador no desaparece: cambia de posición. Pasa de ejecutor de pantallas a director de experiencia.

Pregunta para la comunidad: si pudieras pedirle a tu builder una interfaz por voz o texto, ¿qué parte del trabajo dejarías en manos de la IA y qué parte seguirías revisando tú?

Si has navegado los últimos meses por landings generadas con IA, habrás
notado un patrón: gradientes morados, bg-indigo-500, hero con dos
columnas, badges casi idénticos. Es el «Purple Problem» del que habla
Alan West en Dev.to: la IA no está rompiendo el diseño, está
clonando la misma estética una y otra vez.

El problema no es Tailwind. Tailwind solo es la herramienta más
disponible para los modelos. El problema es qué referencias
visuales aprendieron y qué tokens usan por defecto.

Tres ideas para escapar de eso sin renunciar a la velocidad de la IA:

1. Pasarle TU sistema visual antes de pedirle nada
   En vez de aceptar bg-indigo-500, define tus tokens (color, spacing,
   tipografía) y dale al modelo la paleta y el sistema antes de
   generar. La IA es buena copiando lo que le das, no lo que tú
   imaginas.

2. Pedir referencias concretas, no genéricas
   «Genérame un hero» termina en hero genérico. «Genérame un hero al
   estilo de Stripe pero con la jerarquía tipográfica de Linear»
   produce algo distinto. La especificidad cambia el resultado.

3. Iterar sobre la atmósfera, no sobre el componente
   Cuando un componente sale «demasiado IA», no lo retoques por
   parámetros. Cambia la atmósfera completa: más espacio negativo,
   tipografía más densa, paleta menos saturada. La diferencia
   visual sale del conjunto, no del botón.

Si estás trabajando con IA + Tailwind y notas que tus landings
empiezan a parecerse entre sí, mira primero qué tokens estás dando por
defecto. Ahí está el 80% del problema.

Cada semana sale una herramienta nueva que promete ser la pieza que
faltaba. La página de Product Hunt en Design Tools es un escaparate
casi infinito: Figma, Framer, Canva, Cursor, OpenAI, Tailwind CSS,
shadcn/ui...

Lo curioso es que cuando preguntas a gente que está construyendo de
verdad, el stack real suele ser bastante distinto al stack «ideal»
de las landings.

Así que abrimos hilo: ¿con qué estás trabajando hoy?

Cuéntalo en formato simple. Por ejemplo:

· Sistema visual / tokens:
· Diseño UI / wireframes:
· Prototipo interactivo:
· Generación de copy/contenido:
· Generación de imagen/asset:
· Implementación frontend:
· Asistente de código:

No buscamos respuestas perfectas. Buscamos lo que de verdad tienes
abierto a las 11:00 cuando estás trabajando un proyecto real.

Sirve para:

· Comparar criterios entre la comunidad

· Detectar herramientas útiles que están pasando inadvertidas

· Ver dónde la IA empieza a sustituir a una pieza tradicional y dónde
todavía no llega

Empiezo yo respondiendo en el primer comentario. Únete con el tuyo.

La oferta de bloques UI listos para copiar-pegar no para de crecer.
Solo en abril han salido referencias sólidas:

· shadcn-ui/ui 4.6.0 (28 abril) — sigue siendo el patrón que
copia medio internet

· magicuidesign/magicui actualizado el 23 abril

· Dev.to: 25+ UI blocks you can use in production (29 abril)

Para el trabajo del día a día son útiles. Aceleran landings, ahorran
horas y dan un punto de partida con buen acabado. Pero hay una pregunta
incómoda que merece la pena hacerse antes de pegar el siguiente bloque:

¿Estoy usando esto como inspiración o como dependencia?

Inspiración:

· Lo copio, lo entiendo, lo adapto a mi sistema

· Cambio tokens, espaciado, tipografía a los míos

· Reescribo el componente para que viva en mi librería

· Resultado: un componente mío con buena referencia detrás

Dependencia:

· Lo pego tal cual y lo dejo

· Mantengo el Inter ajeno, los slate-900 y los rounded-xl
por defecto

· Mi sitio acaba pareciéndose al de los demás

· Resultado: un patchwork de bloques con buen acabado individual y
poca identidad de conjunto

La diferencia no está en si copias o no copias. Está en si te llevas
el patrón o te llevas la decisión visual.

¿Cómo gestionas tú esa frontera? ¿Tienes una librería propia donde
caen los bloques tras pasar por tu sistema, o vives con la copia
directa? Cuéntalo.

La conversación sobre IA + Bricks ya no va de «imagina que algún día se
podrá». Va de qué hay disponible hoy y qué decisiones siguen siendo
nuestras.

En GitHub aparecen señales concretas:

· nerveband/agent-to-bricks — generación de elementos Bricks
asistida por IA (52 stars, «AI-powered element generation for Bricks
Builder»).

· wpgaurav/bricks-skills — skills para crear mejores layouts
apoyándose en herramientas de IA (39 stars).

No son herramientas masivas todavía, pero sí marcan dirección: la IA
ya entra al builder, no solo a generar texto o imágenes.

Lo útil para nosotros no es «usar IA en Bricks» en abstracto. Es saber
qué partes acepta delegar y cuáles no.

1. Sí merece delegar:

   · Estructura inicial de una sección a partir de un brief

   · Esqueleto de bloques repetitivos (cards, FAQs, listas)

   · Variantes de un componente que ya existe

   · Sugerencias de jerarquía cuando el contenido es muy denso

2. No merece delegar (todavía):

   · Decisiones de sistema visual (tokens, spacing, tipografía)

   · Coherencia entre plantillas globales

   · Optimización CSS y rendimiento

   · Lo que el cliente «querría parecer» — eso lo entiendes tú

3. La pregunta real: ¿la IA me da velocidad sin quitarme criterio? Si
   la respuesta es sí, encaja. Si me obliga a revisar tanto que el ahorro
   desaparece, es mejor no usarla en ese paso.

¿Has probado alguna de estas integraciones en proyectos reales? Lo que
funciona y lo que no, lo leemos.

Hay proyectos que empiezan con una idea simple y acaban con un CSS que nadie quiere tocar. No porque el código sea malo, sino porque cada capa fue creciendo sin una regla clara. Un día alguien metió un !important para salir del paso, otro día se duplicó una variable de color, otro se añadió una utility encima de un componente, y al cabo de seis meses cualquier cambio pequeño tarda una hora.

La solución no es escoger una metodología perfecta y defenderla como si fuera una identidad. BEM, Atomic, OOCSS, Utility-first… ninguna te salva sola. La solución es repartir responsabilidades: hay partes del sistema donde la velocidad importa más, y hay otras donde la consistencia y la previsibilidad son lo que mantienen vivo el proyecto.

Estas son cuatro decisiones que llevo aplicando en proyectos reales y que reducen el dolor cuando el CSS empieza a crecer.

1) Extraer color desde una referencia visual acelera las primeras decisiones.

Cuando una landing, una web o una pieza de marca parte de una imagen real (un mockup de cliente, una foto de producto, una referencia de Pinterest), una paleta bien extraída evita horas de ida y vuelta.

No se trata solo de sacar 5 HEX. Se trata de generar una base que funcione en:

• Color base (fondos, contenedores).
• Color de marca (1 o 2 acentos fuertes).
• Estados (success, error, warning, info — derivados, no inventados).
• Jerarquía tipográfica (texto principal, secundario, deshabilitado).

Herramientas útiles: el plugin de Figma Image Palette, Coolors para generar variaciones (tints/shades), o un script con culori o chroma.js para sacar la escala completa desde un color base. Si tienes Figma, Variables + Modes te permite definir la paleta una vez y reutilizarla en light/dark sin duplicar.

Regla práctica: nunca pegues un HEX directo en un componente. Aunque sea un MVP. El día que ese color cambie te lo agradecerás.

2) El CSS mantenible importa más cuando el proyecto crece.

En un proyecto pequeño, cualquier solución que funcione parece válida. Pero en cuanto aparecen más páginas, más componentes o más manos tocando el código, el coste real no es escribir CSS rápido — es volver a entenderlo.

Utility CSS (Tailwind, UnoCSS) sirve para avanzar con velocidad. Variables CSS, componentes reutilizables y convenciones claras sirven para que el sistema siga siendo consistente cuando ya no eres tú solo quien lo toca.

La combinación que mejor me funciona:

/* Tokens en :root o @theme — fuente única */
:root {
   --color-brand: oklch(0.65 0.18 250);
   --space-1: 0.25rem;
   --radius-card: 0.75rem;
}

/* Componentes que encapsulan decisiones */
.card {
   padding: var(--space-4);
   border-radius: var(--radius-card);
   background: var(--color-surface);
}

/* Utilities para variaciones contextuales */
<div class="card mt-6 lg:mt-8">...</div>

Tres preguntas que aplico antes de añadir CSS nuevo:

1. ¿Esta decisión existe ya como token o variable?
2. ¿Esto es estructural (componente) o puntual (utility)?
3. ¿En tres meses sabré por qué está aquí sin abrir Git blame?

Si las tres tienen respuesta clara, añade. Si no, para y refactoriza primero.

3) Cascade layers reducen peleas de especificidad.

@layer no es un adorno de modernidad. Es la herramienta más práctica que ha llegado a CSS en los últimos años para ordenar prioridades.

Cuando el proyecto crece, los parches empiezan a competir entre sí: este selector gana porque es más específico, este otro porque lo metieron al final, este tercero porque nadie quería tocar el anterior. Aparece el !important. Aparecen selectores con cuatro clases encadenadas. Aparece el miedo a borrar nada.

Con layers decides el orden de antemano:

@layer reset, base, components, utilities, overrides;
@layer base {
   body { font-family: system-ui; }
}
@layer components {
   .btn { padding: 0.5rem 1rem; }
}
@layer utilities {
   .mt-4 { margin-top: 1rem; }
}

Una declaración en utilities siempre vence a una en components, independientemente de la especificidad del selector. Eso significa que .btn con dos clases ya no le gana a .mt-4. Y los overrides quedan aislados en su propia capa, sin contaminar el resto.

Tailwind v4, Bootstrap 5.3+ y los frameworks modernos ya lo usan internamente. Si no lo aprovechas, estás peleando con las prioridades a mano.

4) Figma plugins y agentes están cambiando el handoff.

Ya no estamos solo en un flujo de diseño → entrega. Estamos en un flujo donde el sistema visual, el código y la iteración se mezclan más. Plugins como Locofy, Anima, Builder.io o Figma Make, y los nuevos servidores MCP de Figma, generan código a partir del diseño en segundos.

Eso no elimina la necesidad de criterio — la hace más importante. Cuanto más automatizado es el paso de diseño a implementación, más claro tiene que estar el sistema, porque la automatización amplifica lo que ya hay: si tu Figma usa colores sueltos y espaciados arbitrarios, el código generado heredará ese caos. Si tu Figma usa Variables, Auto Layout y componentes con variants, el código sale limpio.

Tres cosas que recomiendo si vas a apoyarte en estos flujos:

• Variables y tokens en Figma alineados con tu CSS. Mismo nombre, misma escala.
• Componentes con variants bien definidos, no frames sueltos copiados.
• Revisar siempre la salida. Los agentes generan rápido pero no entienden tu sistema completo. El review es donde aplicas criterio.

En resumen

Si trabajas con Tailwind, Bricks o CSS custom, la pregunta útil es esta: ¿esta decisión hace más fácil mantener el sistema dentro de tres meses?

Si la respuesta no es un sí claro, probablemente no compense.

Menos pelea de metodologías. Más sistema. Más CSS que aguante el tiempo.

Bricks acaba de publicar la versión 2.3.4, y en este caso no hablamos de una gran actualización con nuevas funciones, sino de una corrección puntual pero necesaria.

Esta versión soluciona un problema en el control de color, donde en algunos casos se mostraba el valor crudo del color en lugar del nombre de la variable CSS.

Puede parecer un detalle pequeño, pero para quienes trabajamos con sistemas visuales, variables, tokens de diseño o flujos más ordenados con Tailwind y Bricks, este tipo de correcciones ayudan a mantener una experiencia más clara y predecible dentro del builder.

Como siempre, antes de actualizar en proyectos importantes:

• revisa que tengas una copia de seguridad reciente;
• prueba primero en staging si el sitio es crítico;
• comprueba especialmente páginas donde uses variables CSS o controles de color personalizados.

No es una versión «grande», pero sí una de esas actualizaciones pequeñas que conviene aplicar para mantener el entorno de trabajo limpio y estable.

Cuando Anthropic anunció Claude Design el 17 de abril de 2026, era inevitable que las redes se llenaran de reacciones. Para algunos, era el siguiente gran salto en diseño asistido por IA. Para otros, otra muestra más de cómo las grandes compañías están aprendiendo a empaquetar como novedad ideas que ya llevaban tiempo circulando.

Y creo que ahí está el punto importante. Claude Design no parece una herramienta inútil. De hecho, probablemente tenga casos de uso bastante interesantes. El problema no es que no sirva. El problema es la narrativa: presentarlo como si estuviéramos ante una categoría completamente nueva, cuando muchas de sus ideas ya existen en herramientas como v0, Google Stitch, Figma Make, Bolt, Lovable o incluso en flujos técnicos alrededor de agentes y skills.

Qué promete Claude Design

Según Anthropic, Claude Design permite crear diseños, prototipos interactivos, presentaciones, páginas de aterrizaje, material de marketing y otros artefactos visuales trabajando con Claude en tiempo real.

La propuesta es atractiva: describes lo que necesitas, Claude genera una primera versión en un canvas y después puedes refinarla mediante conversación, comentarios sobre elementos concretos, edición directa o controles visuales creados por la propia IA.

También puede partir de prompts, imágenes, documentos, presentaciones, hojas de cálculo o una codebase. En la parte de salida, permite compartir el diseño dentro de la organización, guardarlo como carpeta o exportarlo a Canva, PDF, PPTX o HTML independiente. Además, incluye una función de handoff a Claude Code, donde Claude empaqueta el diseño para pasarlo a desarrollo con una instrucción.

Sobre el papel, suena potente. Y lo es. Pero no necesariamente porque sea nuevo.

No es humo, pero tampoco es una revolución aislada

La comparación inevitable es con v0 de Vercel.

Desde 2023, v0 permite describir una interfaz en lenguaje natural y obtener código basado en React, Tailwind CSS y shadcn/ui. No es exactamente lo mismo que Claude Design, pero sí trabaja sobre una idea muy parecida: pasar de intención a interfaz mediante IA.

También está Google Stitch, presentado como una herramienta para generar diseños UI y código frontend a partir de prompts de texto o imágenes, con iteración conversacional y exportación a CSS/HTML o Figma.

Luego tenemos Figma Make, que permite partir de una idea o de un archivo de diseño y generar una aplicación funcional mediante chat con IA dentro del ecosistema Figma.

Y si nos vamos al lado más «prompt-to-app», aparecen herramientas como Bolt.new y Lovable, orientadas a crear aplicaciones, webs o prototipos funcionales a partir de instrucciones en lenguaje natural.

Por eso conviene separar dos cosas: Claude Design puede ser una herramienta útil.

Pero la idea de generar diseño, prototipos, interfaces o incluso aplicaciones a partir de conversación con IA no es nueva.

El design system tampoco es la gran novedad

Otro punto importante es el del design system.

Anthropic presenta como una de las grandes fortalezas de Claude Design la posibilidad de construir un sistema de diseño para el equipo a partir de codebases, archivos de diseño, presentaciones u otras referencias. Claude puede extraer componentes reutilizables, colores, tipografía y patrones para usarlos como base en nuevos proyectos.

Eso es interesante. Pero tampoco es una idea nueva.

La conexión entre IA y sistemas de diseño lleva tiempo siendo una de las grandes obsesiones del sector. No basta con que una IA genere una pantalla bonita. Lo realmente útil es que genere algo coherente con los tokens, componentes, estilos, patrones y reglas visuales de un producto real. Y en ese terreno ya había mucho movimiento.

v0 permite trabajar con sistemas de diseño personalizados mediante Tailwind, shadcn/ui, variables CSS, globals.css, clases propias y registries. Figma Make también ha avanzado en esa dirección con los Make kits, pensados para enseñar a la IA cómo debe usar componentes, estilos, tokens y guías de un sistema de diseño.

Y si ampliamos el foco, todo el ecosistema alrededor de Tailwind, shadcn/ui, tokens de diseño y componentes reutilizables ya llevaba tiempo empujando hacia esa misma dirección: que el diseño no sea solo una colección de pantallas, sino un sistema trasladable a código, reutilizable y adaptable.

Por tanto, Claude Design no inventa la integración entre IA y design systems.

Lo que hace es incorporarla dentro de su propio flujo: onboarding, lectura de assets, generación de un sistema visual, aplicación automática en nuevos diseños, colaboración y conexión con Claude Code.

Eso puede ser cómodo. Incluso puede ser muy potente si está bien resuelto.

Pero de nuevo estamos ante la misma idea de fondo: más que una innovación radical, Claude Design parece una integración oficial y bien empaquetada de tendencias que ya estaban en marcha.

El caso Huashu Design: una reacción posterior

El caso de Huashu Design también es interesante, pero hay que colocarlo bien.

No debería usarse como prueba de que Claude Design «ya existía antes». Todo apunta justo a lo contrario: Huashu Design parece posterior y está inspirado directamente en Claude Design.

Su interés está en otra parte: muestra lo rápido que la comunidad puede reinterpretar una idea lanzada por una gran compañía y llevarla a un formato más abierto, técnico o hackeable.

Claude Design lo convierte en un producto oficial, con interfaz, canvas, colaboración, exportaciones y conexión directa con Claude Code.

Huashu Design lo lleva en otra dirección: una skill HTML-native para Claude Code y otros agentes compatibles, pensada para crear prototipos, presentaciones, animaciones, infografías y revisiones de diseño desde un flujo más técnico.

Eso no convierte a Huashu Design en «el original». No lo es.

Pero sí refuerza una idea importante: cuando una herramienta de IA se basa en prompts, protocolos de trabajo, generación HTML y flujos de agente, la comunidad puede reinterpretar parte de esa experiencia con mucha rapidez.

Y eso abre una pregunta incómoda:

¿cuánto valor diferencial está realmente en Claude Design como producto, y cuánto está en el flujo de trabajo, el prompt, el sistema de diseño y la integración con Claude Code?

Entonces, ¿qué aporta realmente Claude Design?

Creo que Claude Design aporta valor en tres puntos concretos.

El primero es la integración. No es lo mismo tener un prompt suelto en Claude Code que tener una superficie dedicada para diseñar, comentar, iterar, compartir y exportar. Esa capa de producto importa, sobre todo para usuarios no técnicos.

El segundo es el handoff a Claude Code. Cuando un diseño está listo, Claude puede empaquetarlo para pasarlo a Claude Code con una instrucción. Esa conexión entre intención visual y ejecución técnica puede ser muy útil para equipos que ya trabajan con Claude Code.

El tercero es la orientación a equipos. Claude Design permite compartir diseños dentro de una organización, dar acceso de visualización o edición, y trabajar con Claude en conversaciones grupales sobre el mismo diseño.

Ahí sí hay una propuesta clara. Claude Design no gana por inventar el diseño con IA, ni por inventar la integración con design systems. Gana, si gana, por reducir fricción dentro de equipos que ya viven en Claude y quieren pasar de idea a prototipo, de prototipo a presentación y de presentación a código sin saltar entre tantas herramientas.

En resumen

Claude Design no es humo. Pero tampoco es tan novedoso como puede parecer por el ruido inicial.

Es una herramienta interesante, bien posicionada y probablemente útil para equipos que ya están dentro del ecosistema Anthropic. Su mayor valor está en tomar ideas que ya existían —generación de interfaces, uso de sistemas de diseño, exportaciones, colaboración y handoff a código— y reunirlas dentro de una experiencia oficial conectada con Claude y Claude Code.

La idea base ya estaba en el mercado. v0 lleva años generando interfaces con React, Tailwind y shadcn/ui. Google Stitch explora la generación de UI desde prompts, wireframes e imágenes, con exportación a código y Figma. Figma Make trabaja sobre prototipos funcionales dentro del ecosistema Figma. Bolt y Lovable empujan hacia el prompt-to-app. Y Huashu Design, aunque posterior e inspirado directamente en Claude Design, muestra lo rápido que la comunidad puede convertir una idea de producto cerrado en una skill abierta para agentes como Claude Code.

Por eso, la pregunta real no es si Claude Design funciona. Probablemente funcione.

La pregunta es otra:

¿aporta suficiente valor diferencial frente a lo que ya existe como para justificar el coste, la dependencia del ecosistema Anthropic y el cambio de flujo de trabajo?

Para algunos equipos, la respuesta será sí.

Para otros, Claude Design será simplemente otro ejemplo de una tendencia cada vez más común: grandes compañías empaquetando como producto oficial ideas que la comunidad y otros competidores ya venían explorando desde hace tiempo.

Y eso no lo hace irrelevante. Pero sí obliga a rebajar un poco el entusiasmo.

Llevo varios meses usando Claude Code como herramienta principal para desarrollo.

Empecé con la cuenta Pro.
Luego pasé a Max de 100 $/mes.
Y cuando parecía que todo fluía bien, subí a Max de 200 $ para tener más margen y trabajar con menos fricción.

Durante un tiempo, la sensación fue muy buena.

Pero en las últimas semanas algo cambió.

No hablo de una mala respuesta puntual, ni de un día raro, ni de que un modelo se equivoque de vez en cuando. Eso entra dentro de lo normal.

Hablo de empezar a notar una sensación repetida:

más consumo, más lentitud, más vueltas para llegar al mismo resultado y más momentos en los que tenía que pelearme con la herramienta en lugar de avanzar con ella.

Y cuando una herramienta que usas todos los días empieza a generar esa sensación, toca parar y revisar.

Con la llegada de Opus 4.7, muchos hemos notado algo parecido. Hay análisis comparando Opus 4.6 y Opus 4.7 en sesiones reales de Claude Code que apuntan en la misma dirección:

• Más coste en condiciones normales.
• Mucho más coste usando modos de razonamiento intensivo.
• Mayor latencia.
• Más tokens de salida.
• Y, en algunos casos, resultados que no justifican ese aumento.

Traducido al trabajo diario:

Le explicas algo varias veces y no termina de retenerlo.
Pierde contexto antes de lo esperado.
Hace cambios que no le has pedido.
Se atasca en detalles que antes resolvía con más limpieza.
Y cuando miras el consumo acumulado, cuesta entender cómo has llegado ahí tan rápido.

Lo más frustrante no es solo pagar más.

Lo frustrante es sentir que la herramienta ha dejado de ayudarte con la misma claridad que antes.

Y ojo: esto no va de atacar a Anthropic ni de decir que Claude Code sea una mala herramienta. No lo es. De hecho, me ha dado muy buenos resultados durante meses.

Pero sí creo que hay que decir algo con honestidad:

cuando una herramienta deja de encajar con tu flujo real de trabajo, hay que aceptarlo.

No puedes construir tu día a día dependiendo de un único modelo, un único proveedor o una única forma de trabajar.

Menos aún cuando tu productividad, tus proyectos y tus clientes dependen de que las cosas funcionen de forma estable.

Cada vez tengo más claro que el camino no es casarse con una herramienta.

El camino es construir un flujo multimodelo.

Un modelo para planificar.
Otro para revisar.
Otro para escribir código.
Otro para documentar.
Otro local para tareas concretas.
Y herramientas que permitan orquestar todo eso sin perder el contexto del proyecto.

Lo que me llevo de este mes es bastante claro:

1. Pagar más no siempre significa trabajar mejor.
2. Un modelo puede empeorar para tu caso de uso aunque siga siendo muy potente.
3. El contexto enorme no sirve de mucho si el modelo se pierde en mitad del proceso.
4. Depender de un solo proveedor es cómodo, pero también frágil.
5. Cambiar de herramienta no es un fracaso; a veces es simplemente una decisión profesional.

No dejo Claude Code porque «sea malo».

Simplemente he dejado de usarlo como centro absoluto de mi flujo de trabajo.

Y si estás notando lo mismo, no eres el único.

Quizá no necesitas abandonar una herramienta. Pero sí necesitas dejar de depender solo de ella.