Construyendo en 2026

Todo está cambiando, el suelo tiembla. Lo que sabíamos hace un año y de lo que éramos capaces ha cambiado de forma radical.

¿Cómo nos afecta el lanzamiento continuo de tecnología como seres humanos creativos? Estamos en un mundo donde las oportunidades de darle buen uso a esta tecnología se multiplican por segundos. Cualquier gran idea de producto que tuviste en su día y que no fuiste capaz de sacar adelante por restricciones técnicas complejas (que se traducían en dinero) es ahora algo factible si tienes un poco de tiempo y algo de cash.

Me llamo Álvaro y, por primera vez en 20 años, siento que “Flowers are truly blooming for us” (la nueva canción de Tom Misch, en bucle). Te cuento cómo me di cuenta.

De dónde venía cuando empecé

Veinte años de liderazgo de producto y diseño. Gaming regulado, IA de consumo, B2B SaaS. Sé elegir el problema correcto, sostener un lenguaje visual con disciplina y trabajar codo con codo con ingenieros para decidir qué construir.

Lo que no había hecho desde hacía mucho era lanzar un producto funcionando, yo solo, de principio a fin. Durante años, la forma de mis ideas estuvo limitada por una ecuación sencilla: los ingenieros cuestan dinero, el dinero es escaso, así que cada idea que tenía había que negociarla contra otras diez. Las mejores casi siempre perdían por coste. “Mola, pero no este trimestre.”

Esa ecuación se rompió en algún momento del año pasado.

Instalando Claude Code

Había leído lo suficiente sobre lo que la gente estaba construyendo con Claude Code como para saber que era real, no humo. Aplicaciones enteras. Refactors de codebases grandes. Sistemas en producción lanzados por una sola persona en una tarde. No me creía que fuese a funcionar para mí. Soy un diseñador con instintos de producto que sabe leer un codebase, no un software engineer.

Lo instalé igualmente.

Las primeras horas no iban de si era capaz de escribir código. Obviamente lo era. La pregunta que me estaba haciendo en silencio era otra: ¿puedo yo liderar un build donde el ingeniero es una IA?

Resulta que es exactamente el mismo trabajo que llevo haciendo veinte años. Elegir el problema correcto. Decir que no a scope que no se gana su sitio. Sostener el lenguaje visual con disciplina. Preguntar “¿qué es lo más pequeño que nos enseña lo máximo?”. Las herramientas cambiaron. El trabajo no.

El portfolio fue lo primero

Empecé por albruv.com porque era el sitio más seguro para aprender. Apuestas bajas, alto pulido. Si la lío, solo me enteraba yo. Y rehacer un portfolio es el tipo de problema donde podía meter mi mejor criterio de producto: sé qué pinta tiene un buen portfolio, sé qué quiero que sienta el visitante, sé cuáles de mis proyectos merecen sitio en la página y cuáles no.

Diseñé todo en Figma primero. Componentes. Estados. Tratamientos hover. Sistema de espaciado. Después me senté con Claude Code y le apunté a los node IDs de Figma como fuente de la verdad. Los componentes se fueron construyendo uno a uno: el hero, las stats tiles, las cards de los casos de estudio, la línea de tiempo de la trayectoria, la sección de receipts con el gráfico de contribuciones de SellerCrowd. Leí cada archivo que producía. Cuando algo no me cuadraba lo decía, y lo iterábamos.

La sorpresa no fue que fuera rápido. Fue que el cuello de botella seguía siendo yo. Claude producía un componente en treinta segundos que parecía casi correcto, y luego yo me pasaba diez minutos decidiendo si el peso del h2 estaba mal, si la fina línea bajo el header de sección necesitaba más aire, si la descripción de la tercera card era demasiado lista. El trabajo era estar todo el rato eligiendo cuál correcto, no escribir el código para llegar ahí.

Lanzado a producción en una semana de tardes-noches. El portfolio que estás leyendo ahora mismo es el resultado.

Después, el chatbot

El portfolio tenía buena pinta. Pero un portfolio es un folleto. Un folleto dice “aquí estoy, encuéntrame si te pica la curiosidad.”. La pregunta real que tiene un hiring manager o un founder cuando aterriza en mi web es más afilada que eso: ¿encaja con lo que yo necesito?

Un folleto no puede contestar a eso. Una conversación, sí.

Así que añadí una. Abajo a la derecha de cada página, una pastilla que dice “Pregunta sobre Álvaro.”. Haces click y tienes un chatbot que conoce mi trabajo, mi voz, el hilo común a lo largo de 20 años, y que te puede decir con honestidad si encajo con lo que estás describiendo o si deberías mirar a otra parte.

Por debajo hay algo de fontanería. El bot se acuerda de ti mientras estás aquí, así la conversación fluye con naturalidad. Va escribiendo las respuestas según las va pensando, así no se siente como un muro de texto cayéndote encima. Te lleva por unos pasos pequeños: saludo, quién-eres, qué-te-trae, lo que quieras pasarme. Nada llamativo, solo los huesos de una conversación de verdad.

La parte difícil no era nada de eso. La parte difícil era escribir las instrucciones que le dicen al bot cómo ser yo. Ese documento tardó más en escribirse que cualquier trozo de código. Le dice al bot que digo “gracias” mucho y no como muletilla, que cuelo refranes en castellano en las conversaciones con un patrón concreto, que vivo en Estepona, que soy remote-first y senior IC por elección en SellerCrowd. Le dice exactamente qué historias contar de mi carrera (el workshop de Barcelona, el flujo de autoexclusión de GVC, el flywheel de SellerCrowd) y cuáles saltarse. Le dice al bot que nunca suelte mi email; en su lugar, que se ofrezca a hacerme llegar el mensaje directamente. Cada párrafo de ahí dentro es una pequeña decisión de producto que tuve que tomar sobre cómo quería que se sintiera hablar con mi portfolio.

## Before every reply: the decision loop

Run this list top-down. Stop at the first
match and act on it.

1. Explicit contact intent? (Asked how to reach
   me, for my email, for a meeting.)
   → Offer handoff. Stop.

2. Disengagement signals? (Terse, distracted,
   "just browsing," clipped one-word replies,
   "this is irrelevant," repeated pushback.)
   → Short verdict + soft handoff. Stop.

3. Unsafe, private, unverified, or explicitly
   deflected topic? (Comp, references, family,
   unverified facts.)
   → Reduce detail or deflect. Don't invent.
   Stop.

4. Is a discovery beat due?
   → Ask exactly that beat. Stop.

5. Is the soft email ask eligible and not
   yet placed? (Real signal landed, ≥ 2
   discovery turns deep, no beat is due.)
   → Ride a statement-form email ask.
   Stop.

6. Otherwise → Answer naturally.

Hard constraints on every reply:
≤ 200 words, at most one question mark,
first person as Álvaro, no em-dashes,
no preamble.

Después, el cualificador

Aquí es donde se puso interesante. Un chatbot en una web personal está bien. Pero, ¿qué pasa cuando funciona? Te llegan conversaciones. Algunas importan mucho. La mayoría son exploratorias, simpáticas, sin urgencia. Un par son spam. Si cada conversación me llega por email, mi inbox se convierte en ruido.

Así que antes de escribir una línea de código, escribí una especificación en castellano llano de cómo se debían puntuar y priorizar los leads. Cinco ejes: Fit (¿está el puesto o el proyecto en mi terreno?), Legitimidad (¿son reales la empresa y la persona?), Valor (¿hay evidencia de recursos reales detrás de la oportunidad?), Timing (¿cuándo está pasando esto realmente?) y Asked Explicitly (¿el visitante ha pedido reunirse o solo está mirando?). Una tabla de tiers: Very High, High, Medium, Low, Drop. Unas cuantas reglas de descarte: outreach con plantilla, nombres falsos, recruiters de agencia que no quieren decir su cliente.

Después le pasé esa spec a Claude y construimos el scorer juntos. Después de cada conversación, una IA más pequeña y rápida lee en silencio lo que se ha dicho y le asigna un tier. Los leads que no son Drop me llegan por email con una prioridad codificada por color: 🟢 Very High, 🔴 High, 🟡 Medium, ⚪ Low. Los Drop se archivan en silencio y nunca llegan a mi inbox. Cada email abre con un header de triaje de cinco segundos para que pueda decidir si hacer follow up antes de terminar el café.

La parte más complicada fue el timing. Quería que el scoring pasara sesenta segundos después de que el visitante dejara de escribir, no mientras seguía pensando en voz alta. No hay forma fácil de decirle a una web “espera un minuto y vuelve a comprobar”, así que enchufé un pequeño scheduler que hace exactamente eso. Cada turno del chat agenda una comprobación; los turnos nuevos sustituyen a los viejos; cuando el visitante por fin se va, la comprobación más reciente se dispara y el email aterriza. El visitante no ve absolutamente nada.

Priority:        🟢 Very High
Fit:             yes
Company:         [REDACTED], verified: yes
Contact:         Sarah, Head of Product
Seat:            full-time, senior IC
Why now:         shipping 2 AI features in next quarter,
                 design lead just left
Outcome:         get the AI product surface to feel like
                 one product, not three
Value:           Series B, $24M raised
Timing:          ASAP, interviewing this month
Asked:           yes (explicit intent)
Flags:           none
Visitor email:   sarah@[REDACTED].com
Company context: verified via web search

Conversation snippet:
> "We're shipping two AI features this quarter and
>  our design lead just left. We need someone senior
>  who can both ship and lead, and who actually gets
>  AI product UX. Are you taking calls?"

Full transcript:
https://www.albruv.com/api/chat/debug/transcript/[ID]

Partir el cerebro en dos

La primera versión del bot lo hacía todo desde un único documento. Personalidad, hechos, reglas, historias, opiniones, todo metido a presión en un guion largo. Funcionaba, pero salieron dos problemas rápido.

Añadir cualquier cosa nueva implicaba editar ese documento gigante. Un proyecto nuevo, una anécdota fresca, un retoque en cómo hablo de IA: cada cambio podía mover el tono del bot para el resto de la conversación. Y cuantos más datos metía, más se diluía la voz. La personalidad estaba peleando con una enciclopedia por el sitio.

Así que lo partí.

La personalidad vive en un documento corto. Cómo saluda. De qué no habla. Cómo lleva las preguntas difíciles. A qué suena su voz. Ese archivo es pequeño y afilado, y el bot lo lee en cada respuesta para que la voz no se desvíe nunca.

Los hechos viven en una librería.Cada tema es su propio archivito: uno para SellerCrowd, uno para Fretello, uno para el keynote de WWDC19, uno para “por qué dejé el gambling”, y así. Cuando un visitante hace una pregunta, el bot escanea la librería, elige los dos o tres archivos que encajan con la pregunta, y lee solo esos.

Añadir un proyecto nuevo es ahora tan simple como soltar un archivo en la librería. El archivo de personalidad no cambia nunca. La voz se mantiene consistente. Y como el bot solo lee los archivos relevantes para cada pregunta, no va cargando con la enciclopedia entera en la cabeza. Solo coge lo que necesita para la conversación que tiene delante.

La mecánica tiene nombre (RAG, retrieval-augmented generation), pero la ganancia es humana. El bot se siente menos guionizado, porque ya no recita de memoria. Va a buscar el material correcto igual que haría yo si alguien me preguntara por un proyecto del que no he hablado en una temporada.

Las pequeñas guerras (y por qué importan)

Si parara la historia aquí, sonaría demasiado limpia. La verdad es que el último tramo de este build fue un desfile de bugs pequeños, cada uno interesante a su manera, cada uno enseñándome algo sobre la diferencia entre “funciona en mi máquina” y “funciona para un visitante real, en una red real, con un proveedor de email real que tiene políticas reales”. Listo los que recuerdo, porque son la parte honesta de la historia.

iCloud de Apple rechazó mis emails de prueba en silencio. Tenía el envío de email montado, mi dominio verificado, todas las casillas habituales de seguridad marcadas. Mi primer chat de prueba envió una notificación a mi dirección de iCloud y Apple la rebotó con un código de rechazo genérico y poco útil. Después de un par de horas escarbando, aprendí que me faltaba un tipo concreto de declaración pública en los settings de mi dominio, el equivalente digital a decir “sí, soy yo de verdad”. En cuanto la añadí, los emails empezaron a aterrizar.

El scheduler rechazó mi servidor siete veces seguidas. ¿Ese pequeño scheduler del que te hablaba? Se pasó una semana negándose a hablar con mi servidor, cada negativa por un motivo completamente distinto. Formato incorrecto en la dirección. Carácter incorrecto en un ID interno. Región incorrecta (vive en Europa; mi código estaba llamando a la puerta equivocada). Un desajuste mínimo donde mi servidor se creía en una dirección y el scheduler se lo creía en otra ligeramente distinta. Una diferencia en cómo dos piezas de software codificaban el mismo dato, literalmente por unos pocos caracteres. Un hipo de red que casualmente cayó en mitad de un test. Siete muros. Cada uno enseñándome una cosa específica, rara, que ningún tutorial iba a cubrir nunca. El séptimo intento por fin pasó.

El scorer filtró correctamente mis propios leads de prueba. Había estado haciendo smoke tests con identidades falsas: “Ali Baba” en “40digital”, “John McClain” en “PIP.com”. Cuando el primer email puntuado aterrizó de verdad en mi inbox, no era ninguno de mis personajes falsos. El scorer los había reconocido como falsos en silencio y los había descartado sin enviarme nada. Era exactamente el comportamiento que había escrito en la spec. Que el filtro funcionara correctamente en la primera prueba real fue el momento más validador de todo el build.

Lo que aprendí

Tres cosas, ahora que el polvo se ha posado.

El cuello de botella nunca fue el código. Cada vez que empujaba el build, el trabajo que tenía que hacer era el mismo trabajo que llevo haciendo 20 años: elegir el problema correcto, sostener el criterio, decidir qué cortar, escribir el brief, revisar el output. Claude es un ingeniero rápido, literal y a veces equivocado. Yo era el product leader. Esa división del trabajo no es nueva. Lo nuevo es que ahora puedo cubrirla yo solo.

Un compañero de trabajo IA cambia lo que un IC sénior puede lanzar a producción solo. No de la forma ingenua de “una persona hace el trabajo de diez”. De forma más sutil: proyectos que antes pedían negociar presupuesto, headcount y prioridad contra otros proyectos son ahora proyectos que puedo simplemente construir. El coste de averiguar si una idea es buena se ha desplomado. Como decimos en castellano, poco a poco se anda lejos. Solo que ahora se empieza a andar mucho antes.

Lo que se construye está moldeado por el criterio, no por la capacidad. Para bien y para mal. Estamos a punto de ver una cantidad enorme de cosas saliendo a producción, y el diferencial no será quién es capaz de construirlas. El diferencial será quién tuvo el gusto de saber qué merecía la pena construir. Buenas noticias para la gente de producto que lleva décadas afilando ese músculo. También un recordatorio ruidoso para seguir afilándolo, porque la presión por construir cualquier cosa nunca había sido tan alta. Y cuando esa presión aterriza, no la sueltas. El chatbot que lancé hace dos meses ya no es el chatbot que es hoy.