Acabo de publicar atproto-comments (en npm y en JSR), un web component que lleva los comentarios del AT Protocol a cualquier web, de forma sencilla y sin necesidad de autenticación.

1. Publicas un artículo en tu web.
2. Publicas un post en una app del AT Protocol (Bluesky, Mu, Deer, etc.) con el enlace a ese artículo.
3. Insertas el componente en tu HTML, apuntando al post mediante su AT URI:

<atproto-comments thread-uri="at://did:plc:xxxx/app.bsky.feed.post/yyyy"></atproto-comments>

Y listo: las respuestas a ese post aparecen como comentarios en tu artículo. Además, si un visitante con cuenta en el AT Protocol quiere comentar, elige su app y se le redirige al post.

El objetivo es doble. Por un lado, ofrecer un sistema de comentarios fácil de integrar, sin base de datos propia y sin depender de plataformas como Disqus. Por otro, traer a tu web las conversaciones que hoy se quedan encerradas dentro de las redes sociales.

Si no conoces el AT Protocol, sigue leyendo. Te voy a contar el camino que seguí hasta conocerlo y entenderlo, porque tengo la intuición de que te será más útil que una definición de manual.

Hace año y medio, harto del estercolero en el que se ha convertido X, busqué alternativas. Di con Bluesky, que prometía ser una red abierta y tenía una interfaz con vibes del viejo Twitter. Me gustó: casi sin ruido, nazis ni bots. Pero no entendí el porqué de lo de "abierta".

En marzo vi un post de Eurosky, iniciativa europea independiente que trabaja para construir una web social abierta, donde invitaban a mover nuestras cuentas de Bluesky, alojadas en servidores en EE. UU., a sus servidores en Europa, y a seguir conversando en Bluesky. ¿Cómo? Esto ya era un poco más raro. Pero era verdad: cambié mi cuenta a Eurosky y seguí conversando en Bluesky.

En junio, otro post de Eurosky. Esta vez anunciaban mu.social, una nueva app de microblogging. Probé a entrar con mis credenciales de Bluesky y me quedé de piedra. Ahí estaba mi perfil, con mis posts, la gente a la que sigo y mis seguidores. Todo. Después encontré y probé Deer y pasó lo mismo.

Para que entiendas mi sorpresa, aquí está el mismo post de Eurosky visto a través de tres apps:

• Post de Eurosky en Bluesky
• Post de Eurosky en mu.social
• Post de Eurosky en Deer

Espera, esto me recordaba a algo que ya había vivido. ¡Claro, qué morriña! Los blogs, el RSS, Google Reader y Feedly. Cuando internet era descentralizada, lo que publicábamos era nuestro y lo que leíamos no estaba deformado por los algoritmos de empresas privadas.

Investigué y recapitulé. Esto era posible porque Bluesky está construido sobre el AT Protocol, un protocolo abierto para redes sociales descentralizadas. En él, tus datos viven en un servidor de datos personal (PDS) y están firmados criptográficamente (DID). Por eso podemos cambiar de proveedor sin perder la cuenta ni los seguidores (¡los datos son nuestros!), e incluso montar nuestro propio servidor. Podemos consumir nuestros datos y los de las personas a las que seguimos desde distintas apps. Y podemos desarrollar herramientas como atproto-comments, que acabo de publicar, sin depender de lo que una empresa decida en cada momento.

Cómo funciona por dentro

Si quieres ver las piezas del puzle, estas son las que entran en juego cuando atproto-comments carga los comentarios:

• Identidad (DID y handle): cada cuenta tiene un identificador permanente (did:plc:...) y un nombre legible (@xulioze.eurosky.social). El DID es lo que permite cambiar de servidor sin perder nada.
• PDS (Personal Data Server): el servidor donde viven tus datos, en un repositorio firmado. Puede ser el de Bluesky, el de Eurosky o el tuyo propio.
• Lexicons y registros: cada tipo de dato tiene un esquema público. Un post es un registro de la colección app.bsky.feed.post; por eso la AT URI apunta a at://<did>/app.bsky.feed.post/<id>.
• Relay: como los datos están repartidos en muchos PDS, el Relay los reúne y reemite sus cambios en un único flujo en tiempo real (el firehose).
• AppView: consume ese flujo, lo indexa y sirve vistas ya montadas, como el hilo de respuestas de un post. atproto-comments pide ese hilo a la API pública del AppView de Bluesky (app.bsky.feed.getPostThread), pero puedes apuntarlo a otro AppView con el atributo appview.
• Apps cliente: Bluesky, Mu, Deer… son solo interfaces distintas sobre los mismos datos, y cada una puede decidir cómo los muestra: qué algoritmo usa, cómo ordena el feed, qué moderación aplica. Si un día no me gusta cómo me sirve Bluesky el feed, me cambio a otra app que lo haga más a mi gusto, sin perder nada.

En el fondo, la idea es muy parecida a la del RSS y los blogs: los datos son de quien los publica, que puede llevárselos adonde quiera. Cada cual decide cómo y dónde consumirlos. Y cualquiera puede desarrollar herramientas para el ecosistema sin pedir permiso a nadie, como atproto-comments, que estrenamos hoy aquí. Si ya tienes cuenta en el AT Protocol, deja un comentario aquí abajo desde tu app favorita (Bluesky, Mu, Deer…) y lo verás aparecer. Si no tienes, crea una cuenta en Eurosky y úsala en la app que quieras. ¡Bienvenida a las redes sociales abiertas!

Comentarios

Esta guía es una versión mejorada de la que propuse en "Contexto extendido. Los agentes también necesitan tomar notas" y Guía: desarrollar software de calidad asistido por agentes de IA.

Cuando llegaron los editores con agentes de IA autónomos (Cursor, GitHub Copilot, Claude Code), muchos compramos la promesa: "escribe el prompt perfecto y el agente te genera la feature completa de una tirada". La realidad fue otra: sin estructura ni constraints, acabábamos dedicando más tiempo a corregir bugs que a escribir código.

El "vibe-coding", eso de confiar en que el agente "pille la vibe" de tu proyecto, funciona bien para prototipos rápidos, pero en proyectos reales y complejos genera más problemas que soluciones:

• Decisiones perdidas: ¿Por qué elegimos esta arquitectura hace dos semanas?
• Alucinaciones constantes: La IA inventa APIs, mezcla frameworks, ignora constraints
• Trabajo monolítico: Imposible dividir features en tareas rastreables
• Improvisación continua: Cada sesión comienza desde cero

Hace unos meses documenté una solución (v1): un workflow estructurado (análisis → solución → backlog → ejecución → progreso guardado) con cuatro archivos de contexto que convertía el vibe-coding en ingeniería rastreable. Funcionó, pero había fricción: repetir manualmente los mismos prompts en cada sesión era un dolor.

Esta guía presenta la evolución de ese sistema (v2). Aprovecha el sistema de rules de Cursor para automatizar prompts y convierte el workflow en protocolos reutilizables. Pero al diseñarla emergió un patrón universal: separar conocimiento reutilizable (rules) de memoria temporal (memory). Esto va más allá de ahorrarte escribir los mismos prompts: puedes reutilizar el conocimiento en diferentes proyectos y llevar un registro ordenado de todo lo que haces. Y el patrón funciona con cualquier herramienta de IA, no solo con Cursor.

Vamos a ver cómo construir esa arquitectura.

Problema de v1

Sistema de cuatro archivos en context/:

• 01-expert.md - Perfil del experto
• 02-analysis.md - Análisis del código
• 03-plan.md - Plan de implementación
• 04-backlog.md - Tareas pendientes

Limitaciones en proyectos reales

Conocimiento mezclado: 01-expert.md combina principios generales (KISS, DRY) con constraints específicos del proyecto (stack, versiones, dependencias críticas). Imposible reutilizar principios entre proyectos sin arrastrar configuración irrelevante.

Duplicación entre proyectos: Cada proyecto replica conocimiento común. Si trabajas en 3 proyectos WordPress, tienes security: sanitize_*, nonces copiado tres veces. Actualizas una best practice, debes sincronizar manualmente.

Sin gestión de histórico: v1 te da tres opciones, todas malas:

• Sobrescribir 02-analysis.md → pierdes decisiones previas
• Acumular análisis en el mismo archivo → crece descontroladamente, imposible rastrear cuándo se tomó cada decisión
• Crear múltiples archivos (02-analysis-feature-X.md) → desorden, sin nomenclatura consistente

En todos los casos: ¿Por qué rechazaste la arquitectura X hace dos semanas? No hay forma sistemática de recuperarlo.

Sin modularidad: Cambiar de WordPress a React requiere reescribir 01-expert.md completo. No puedes mantener módulos comunes (principios, patrones) y solo intercambiar el experto técnico.

v1 tenía dos problemas fundamentales: (1) conocimiento mezclado en un solo archivo (01-expert.md), (2) ejecución manual - cada acción requería escribir el prompt completo ("analiza este archivo y guarda en 02-analysis.md", "lee 04-backlog.md, ejecuta tareas 1-3, actualiza estado"). v2 resuelve ambos: separa conocimiento en rules/ modulares y automatiza ejecución mediante protocolos invocables en rules/utils/ (@analysis, @execute).

Solución: Separación Rules/Memory

La solución replica cómo funciona nuestro cerebro: separamos conocimiento permanente (idioma, matemáticas, habilidades) de memoria episódica (lo que hicmos ayer, decisiones de la semana pasada). Pero además, nuestro conocimiento no es monolítico: tenemos módulos especializados (JavaScript, WordPress, principios KISS) que activamos según el contexto.

v2 implementa esta arquitectura dual:

1. Separación conocimiento/memoria: Rules reutilizables vs memory temporal
2. Modularización del conocimiento: Expertos, guidelines y protocolos ejecutables

.cursor/
├── rules/          # Conocimiento reutilizable y modular
│   ├── experts/    # Roles técnicos (WordPress, React, Python...)
│   ├── guidelines/ # Principios y constraints (KISS, proyecto-específicos)
│   └── utils/      # Protocolos ejecutables (analysis, backlog, commit)
└── memory/         # Experiencias temporales
    └── YYYYMMDD-VV-descripcion.md

Concepto Clave: alwaysApply

El sistema rules/memory necesita un mecanismo de activación: ¿qué conocimiento carga Cursor automáticamente vs. qué invocas bajo demanda? Sin esto, tendrías 100 reglas compitiendo por contexto limitado.

El flag alwaysApply resuelve esto:

• alwaysApply: true → Cursor las carga automáticamente en cada conversación
  • Usa para: Expertos base, guidelines críticas del proyecto
  • Ejemplo: wordpress-classic-themes.mdc, constraints-balneario.mdc
• alwaysApply: false → Usuario las invoca con @ según necesidad
  • Usa para: Protocolos bajo demanda, herramientas específicas
  • Ejemplo: @analysis, @backlog

Rules: Conocimiento Reutilizable

Experts - Perfiles de expertos técnicos/dominio:

rules/experts/wordpress-classic-themes.mdc

---
alwaysApply: true
---
# WordPress Classic Expert
PHP + vanilla JS specialist. WordPress core APIs, theme dev.

## Stack
Backend: PHP 7.4+, WP Core APIs | Frontend: Vanilla JS, HTML5, CSS3

## Core Patterns
- Security: sanitize_*, esc_*, nonces
- Performance: transients (12h), conditional enqueue
- Translation: __(), _e() with text domain

Guidelines - Principios de código y restricciones de proyecto:

rules/guidelines/constraints-balneario.mdc

---
alwaysApply: true
---
# Balneario Theme
Text domain: themefront v0.1.2
Stack: Node | SASS 1.67.0 | PHP 7.4+ | jQuery 3.x
Build: npm run watch:sass (never edit compiled CSS)

Critical: ACF PRO (18 groups), WooCommerce, WPML
Core Systems: PDF Generator (pdf-generator.php), WooCommerce integration

rules/guidelines/kiss.mdc

---
alwaysApply: true
---
# KISS Principle
- Direct solutions, avoid over-engineering
- Simple patterns, minimal dependencies
- Single responsibility per function

Rule: If you can't explain it in 2-3 sentences, it's too complex.

El principio KISS es especialmente importante en desarrollo asistido por IA: es más fácil pedir al agente que añada complejidad a una solución simple, que perder tiempo analizando qué sobra en su propuesta (los LLMs tienden a generar código más complejo de lo necesario).

Utils - Protocolos invocables:

rules/utils/analysis.mdc → Analiza código/carpetas y guarda en memory

---
alwaysApply: false
---
# Analysis Protocol
Trigger: @file/@folder or "analyze"
1. Acknowledge → 2. Analyze → 3. Save to .cursor/memory/YYYYMMDD-VV-*.md → 4. Confirm

rules/utils/solution.mdc → Propone solución y guarda en memory

---
alwaysApply: false
---
# Solution Protocol (KISS)
Trigger: User requests solution
1. Acknowledge → 2. Propose simplest solution → 3. Save to memory → 4. Confirm
Principles: Simplicity > complexity, proven patterns > novel

rules/utils/backlog.mdc → Convierte solución en tareas atómicas rastreables

---
alwaysApply: false
---
# Backlog Protocol
Solution → atomic tasks → persistent backlog (YYYYMMDD-VV-backlog-*.md)

Format: [Phase.Task#] ⏳/🔄/✅/⚠️ Title
> What to do | Date completed | Work done

Rules: 2-4h max, sequential, testable

rules/utils/execute.mdc → Ejecuta tareas del backlog y actualiza estado

---
alwaysApply: false
---
# Task Execution Protocol
Load backlog → parse scope → execute → update status → stop at boundary
Input: [1.1], [2.3,2.4], Phase 2, continue

rules/utils/commit.mdc → Genera commits convencionales y actualiza backlog

---
alwaysApply: false
---
# Commit Protocol
Analyze staged → generate conventional commit → approve → execute → update backlog
Format: [JIRA-XXX] type(scope): subject (English, imperative, max 72 chars)

Memory: Registro Histórico

Los protocolos utils generan automáticamente archivos en memory/ siguiendo la nomenclatura YYYYMMDD-VV-descripcion.md (VV = secuencia diaria: 01, 02, 03...):

memory/
├── 20250919-01-analisis-pdf-generator.md
├── 20250919-02-sistema-pdfs-emails-finalizado.md
├── 20251015-01-analisis-completo-balneario-theme.md
├── 20251015-02-solucion-facturacion-automatica-399.md
└── 20251015-03-backlog-facturacion-automatica-399.md

Ventajas: ordenación cronológica, múltiples entradas/día, trazabilidad, relaciones visibles.

Esto resuelve el problema de las tres opciones malas de v1: la nomenclatura cronológica (YYYYMMDD-VV) acumula histórico sin descontrol, mantiene orden sin desorganización, y preserva decisiones sin sobrescritura.

Workflow en Cursor

Nota: Los comandos con @ invocan reglas específicas. Por ejemplo, @analysis carga rules/utils/analysis.mdc sin necesidad de escribir la ruta completa. Esto es parte de la sintaxis nativa de Cursor.

Esta sección describe el workflow general para desarrollo asistido por IA: separar conocimiento reutilizable de memoria temporal, siguiendo el ciclo análisis → solución → backlog → ejecución → commit → continuar. Usamos Cursor y su sistema de rules como ejemplo de implementación, pero el workflow es aplicable a cualquier herramienta de IA con capacidad de inyectar contexto.

A continuación verás cómo funciona el workflow en la práctica. Si después quieres implementarlo en tus proyectos con Cursor, consulta la guía de Implementación y Configuración más abajo.

Desarrollo de feature: facturación automática

1. Análisis

@analysis checkout.php

→ Genera: 20251015-01-analisis-checkout.md

2. Solución

@solution
Implementa facturación automática WooCommerce

→ Genera: 20251015-02-solucion-facturacion.md

3. Backlog

@memory/20251015-02-solucion-facturacion
@backlog

→ Genera: 20251015-03-backlog-facturacion.md

4. Ejecución

@memory/20251015-03-backlog-facturacion
@execute [1.1]

→ Actualiza: [1.1] ⏳ → ✅

5. Commit

@memory/20251015-03-backlog-facturacion
@commit

→ Crea commit + actualiza backlog

6. Continuar trabajo (nueva sesión)

@memory/20251015-03-backlog-facturacion
Resume trabajo

→ Carga contexto + muestra próximas tareas

Implementación y Configuración

1. Instalar el sistema (5 min)

Este sistema está disponible en github.com/arinspunk/extended-context.

Dos formas de configurar:

Opción A - Contribuir al repo compartido (recomendado si quieres participar en el mantenimiento):

cd tu-proyecto
git clone https://github.com/arinspunk/extended-context.git .cursor

Mantiene conexión con el repo para recibir actualizaciones y contribuir mejoras. Actualiza cuando quieras: cd .cursor && git pull

Opción B - Snapshot para tu proyecto (recomendado para trabajo diario):

git clone https://github.com/arinspunk/extended-context.git temp
cp -r temp/rules temp/memory tu-proyecto/.cursor/
rm -rf temp

Copia independiente que personalizas libremente sin afectar el repo original, ideal para versionar junto con el código de tu proyecto.

Migración desde v1: Usa Opción B para integrar con tu estructura existente.

2. Configuración inicial (15 min)

Pre-requisitos:

• Cursor instalado y proyecto abierto
• Sistema rules/memory clonado en .cursor/ (paso anterior completado)

Paso 1: Identifica tu stack (2 min)

Revisa rules/experts/ y activa el experto que coincida con tu proyecto:

• WordPress → wordpress-classic-themes.mdc
• React → react-typescript.mdc (si existe)
• Backend Python → python-fastapi.mdc (si existe)

Si tu stack no existe: copia el experto más cercano y adáptalo.

Paso 2: Activa constraints del proyecto (3 min)

1. Copia rules/guidelines/constraints-template.mdc a constraints-{proyecto}.mdc
2. Completa:
   • Stack técnico (versiones específicas)
   • Dependencias críticas (librerías que NO se pueden cambiar)
   • Sistemas legacy que debes respetar
3. Cambia alwaysApply: false → true

Paso 3: Activa principios base (1 min)

Activa kiss.mdc cambiando alwaysApply: false → true

Paso 4: Verifica carga (1 min)

Abre chat de Cursor (Cmd+L) y escribe:

¿Qué experto y guidelines tienes activas?

Cursor debe listar los archivos con alwaysApply: true.

Paso 5: Primera ejecución (8 min)

Prueba el workflow completo con un archivo real:

@analysis src/components/Header.tsx

Si genera correctamente memory/YYYYMMDD-01-*.md, el sistema está operativo.

Nota para otras herramientas: Este sistema es agnóstico a Cursor. La separación conceptual rules/memory puede implementarse en cualquier herramienta capaz de inyectar contexto (GitHub Copilot, Claude Code, etc.).

Una vez configurado el sistema, el verdadero trabajo comienza: alimentar rules con conocimiento específico del proyecto y prácticas habituales del equipo, mientras memory registra el trabajo realizado con la IA (análisis, propuestas de solución, tareas y progreso). En la práctica, esto transforma cómo la IA genera código: soluciones coherentes con la arquitectura del proyecto y escalables. Además, documenta decisiones que facilitan debug posteriores y transferencia de conocimiento entre desarrolladores.

Conclusión

El vibe-coding funciona para prototipos, pero genera más problemas que soluciones en proyectos reales: decisiones perdidas, alucinaciones constantes, trabajo imposible de rastrear. v1 resolvió esto con workflow estructurado, pero requería repetir prompts manualmente en cada sesión.

v2 elimina esa fricción automatizando los protocolos y, al hacerlo, descubre un patrón universal: separar conocimiento reutilizable (rules) de memoria temporal (memory). Esta separación, la misma que hace tu cerebro entre habilidades y experiencias, convierte cualquier herramienta de IA en un sistema donde el conocimiento persiste, evoluciona y se reutiliza sistemáticamente.

No elimina las limitaciones de ventana de contexto, pero las transforma en un framework estructurado para construir software de forma rastreable y escalable.

Próximos Pasos

1. Si usas Cursor: Clona el repo y configura tu primer proyecto
2. Si usas otra herramienta: Adapta la separación rules/memory a tu sistema
3. Comparte tu implementación: ¿Creaste expertos para tu stack? Contribuye al repo
4. Comparte resultados: ¿Mejoraste el workflow? Documenta tus hallazgos para refinar colectivamente el sistema

Hace unos días, en una conversación con compañeros, surgió el debate sobre la utilidad del one-shot prompting a la hora de generar código con IA. Yo defendía que no lo es, y el argumento que usé creo que merece ser compartido.

El problema del one-shot como objetivo

Cuando asumimos que el one-shot puede darnos los resultados esperados, estamos cargando toda la responsabilidad de la calidad del output en la parte humana: si el LLM no produce una buena respuesta, el problema es que no escribimos el prompt correcto.

Pero esta idea choca frontalmente con la naturaleza de la IA generativa, que es no-determinista. Para un mismo prompt y modelo, obtenemos respuestas diferentes en cada ejecución. Por tanto, resulta imposible —sobre todo con tareas complejas— obtener la respuesta óptima en una sola interacción. La iteración se vuelve ineludible.

En ese debate, con pequeños matices, todos coincidíamos en que el one-shot no es válido como fin en sí mismo, sino como ejercicio para mejorar nuestros prompts. Es imposible alcanzar el 100% de calidad, pero con esta práctica aprendemos a pasar, por decir algo, del 60% al 70%.

De Figma al código: otra perspectiva

Este fin de semana leí The only AI workflow I use in production, de Tommy Geoco. El artículo describe el flujo que Tommy utiliza para desarrollar su trabajo de diseño asistido por IA (Figma → Claude Code), afirmando que supera en términos absolutos al uso de otras herramientas como Lovable, Replit o Bolt. Si eres diseñador UX/UI interesado en la integración de IA en tu trabajo, te recomiendo leerlo porque contiene ideas realmente interesantes.

Entre esas ideas hay una que me ha hecho reflexionar de nuevo sobre la inconveniencia del one-shot. Según el autor, debemos desmitificarlo porque no captura el valor real. La verdadera potencia no está en la generación inicial, sino en las iteraciones posteriores.

Su flujo de trabajo es el siguiente:

1. Diseñar el "happy path" (flujo óptimo) en Figma
2. Alimentar el diseño a Claude Code vía Figma MCP
3. Obtener una base sólida en 15 minutos (vs. 50 horas de codificación manual)
4. Iterar y refinar durante 50 horas

El último punto es clave para él: la iteración no es desarrollo, es trabajo de diseño. No se trata de refinar el código para representar un diseño cerrado, sino con él tomar decisiones sobre jerarquía visual, patrones de interacción, casos extremos, estados de error, etc.

¿Y si el valor está en la iteración?

De aquí saco dos conclusiones igualmente importantes. La primera: el autor está trasladando gran parte del ejercicio de diseño de Figma al código, algo novedoso que desdibuja la frontera UX/UI-Desarrollo. No voy a desarrollarla aquí para no desviarme del tema, pero merece un post propio.

La segunda, relacionada con el debate sobre one-shot: el autor no usa la IA para que diseñe por él en base a unas instrucciones iniciales, sino que se apoya en ella para iterar más rápido, reflexionar sobre el diseño de manera más profunda y conseguir un mejor resultado. Creo que no solo porque la IA le ahorra tiempo de trabajo repetitivo sin valor y lo gana para pensar, sino porque el diálogo generado puede llevarlo a lugares, pensamientos y decisiones a los que solo no habría llegado.

Queda por ver si este esquema se traslada igual al desarrollo de software, pero si funciona de manera similar, entonces la inconveniencia del one-shot no se debe únicamente a las limitaciones que nos impone la naturaleza no-determinista de los LLMs. Hay algo más importante: la iteración —ese diálogo continuado entre humano e IA— nos proporciona valor real, obtenemos mejores resultados.

Esta idea de la iteración como diálogo me ha hecho recordar los planteamientos sobre cocreación humano–IA de Owen Matson. Y tengo que reconocer que ha sido escribiendo este post —en diálogo con una IA— cuando creo que finalmente he entendido lo que Owen plantea. Queda pendiente profundizar en esta vía 🙂

El otro día, mientras probaba el MCP que desarrollé para integrar Figma con Claude, mi hija de 9 años me preguntó qué hacía. Yo le expliqué y ella escuchó atenta, cuando terminé me dijo:
—Dile que dibuje un monstruo enfadado.
Se lo pedí a Claude y lo dibujó.

Desde hace un tiempo estoy usando la IA de forma intensiva en mi trabajo y una de las cosas de las que me he dado cuenta es que no hay que dejar de pedirle algo porque creemos que no lo puede hacer. Tú pide sin más, verás cómo muchas veces te sorprenderá con la solución propuesta y aprenderás algo nuevo.

Hoy trabajando con Figma + Cursor me acordé de mi hija y le pedí al agente que dibujase un dragón.

Creo que voy a volver a la afición que tenía cuando era diseñador 😊

Propósito

Permitir a los LLMs:

• Analizar y modificar diseños en Figma.
• Generar código a partir de ellos.

A quién va dirigido

Equipos de UX/UI que quieren automatizar auditorías de accesibilidad, realizar tests de usuario sintéticos y iterar diseños basándose en feedback automatizado.

Equipos de Frontend que necesitan acelerar la traducción de diseños a código, especialmente cuando trabajan con sistemas de componentes y frameworks modernos.

Equipos de Backend/DevOps que desarrollan workflows automatizados y agentes IA que requieren integrar análisis de diseños en Figma y generación de código a partir de ellos.

Equipos multidisciplinarios que buscan reducir la fricción en el handoff entre diseño y desarrollo, manteniendo cada equipo en su herramientas habituales.

Herramientas

API de Figma

Requisitos

• Cuenta de Figma
• Generar un token de acceso o usar OAuth 2

Descripción

Es la vía más simple para que un LLM analice un diseño.

La API de Figma permite construir endpoints para solicitar archivos, imágenes, versiones de archivos, usuarios, comentarios, proyectos de equipo y archivos de proyecto. Devuelve un JSON que podemos pasar al LLM para que lo interprete.

A diferencia de los MCPs, no necesitamos tener abierto Figma Desktop para que un agente analice un diseño. Esto la convierte en el método idóneo para integrar Figma en flujos de trabajo de agentes IA.

Instalación

Al tratarse de una API, no de un MCP, no existe una instalación como tal. Podemos ver cómo funciona con una prueba simple con Cursor o VS Code:

1. Crea un token.
2. Dile a tu agente que analice un diseño en Figma ejecutando una petición curl de un endpoint.

Por ejemplo, para la siguiente URL de un nodo de un diseño:

https://www.figma.com/design/XG1EYHLnC7NdwGuYc7LmUf/MVC---WEB?node-id=6037-2235&t=AHpchSRAIyGCdoci-0

dile que use:

curl -H 'X-FIGMA-TOKEN: {your personal access token}'
'https://api.figma.com/v1/files/XG1EYHLnC7NdwGuYc7LmUf/nodes?ids=6037-2235'

Al recibir el prompt, el agente ejecutará la petición curl y obtendrá un JSON con los parámetros del diseño. Luego lo analizará y generará un texto con el contenido de su análisis.

Dev Mode MCP Server

Requisitos

• Dev o Full seat en los planes Professional, Organization o Enterprise.
• Un editor de código o aplicación que soporte MCP Servers (VS Code, Cursor, Windsurf, Claude Code).
• Figma Desktop App

Descripción

Se trata del servidor MCP oficial de Figma.

Habilita varias herramientas de análisis (5 a la fecha de publicación de este post) que los agentes pueden usar para generar código a partir de un diseño.

Las herramientas que permiten "ver" un diseño son get_code y get_image. A diferencia de la API de Figma, get_code no devuelve un JSON con los datos del diseño, sino una traducción del diseño a React que genera al vuelo Dev Mode.

Esto facilita al LLM la generación de código aunque no sea React, ya que la distancia entre React y otro framework/lenguaje es menor que entre la información del JSON y nuestro framework/lenguaje.

get_image crea una captura de pantalla del diseño seleccionado y sirve de apoyo al agente a la hora de generar código.

Instalación

1. Activación en Figma Desktop App
2. Instalación en nuestro editor de código (Cursor, VS Code, Windsurf, Claude Code, Others)

Claude Talk to Figma MCP

Requisitos

• Claude Desktop
• Figma Desktop
• Bun instalado

Descripción

MCP server de código abierto.

Habilita un conjunto amplio de herramientas (43 a la fecha de publicación de este post) que permite a los agentes analizar y también modificar diseños en Figma.

Las herramientas que permiten "ver" un diseño devuelven un JSON con sus datos. Esto permite a los LLMs analizarlo mediante "thinking aloud", evaluación crítica, test de usuario, auditoría de accesibilidad, auditoría de SEO, etc.

Con las herramientas de modificación, el LLM puede después aplicar los cambios propuestos en el análisis.

Instalación

Sigue las instrucciones de la documentación oficial.

Comparte tu experiencia

Si ya estás integrando Figma en tu flujo de trabajo con IA, ya sea con estas u otras herramientas, me encantaría conocer tu experiencia:

• Cómo ha ido su instalación.
• Experimentos y descubrimientos.
• Casos de uso reales.
• Resultados obtenidos.

El ecosistema de IA + diseño/desarrollo está en constante evolución y las mejores prácticas emergen de la experiencia colectiva de quienes las implementan en proyectos reales ✊

Si todavía no lo has hecho, atrévete con alguna de las herramientas de este post. Si algo se te atasca, puedes escribirme en mi perfil de LinkedIn 😉

A lo largo de este tiempo refiné mi conversación con LLMs, comencé a usar asistentes de código (GitHub Copilot) y después asistentes con agentes (Cursor) e incluso desarrollé sistemas de agentes con frameworks como CrewAI. Pero no ha sido hasta ahora que he entendido de forma clara que cualquier interacción con modelos de lenguaje, no importa que herramienta usemos, se resume en tres puntos fundamentales: prompt, contexto y memoria.

Prompt

A través del prompt creamos el experto que necesitamos para una determinada tarea, le indicamos qué hay que hacer y también qué no hay que hacer. Es el medio del que disponemos para alcanzar el resultado deseado.

Para escribir el prompt adecuado para cada tarea, tenemos la ingeniería de prompts. Conocer sus principales técnicas es importante, pero lo que de verdad hace que mejoremos, es la práctica continua con los LLMs, nuestra conversación con la IA.

Contexto

Los grandes modelos de lenguaje disponen de un vasto conocimiento, pero para determinadas tareas este no es suficiente. Proporcionarle contexto adicional se convierte en una necesidad ineludible.

Para dar contexto disponemos de diferentes vías, desde la simple inclusión de información relevante en el prompt, pasando por añadir documentos de referencia hasta el uso de MCPs que permiten a los LLMs acceder al contenido de múltiples plataformas (Jira, Drive, etc.) y herramientas (Figma, Draw.io, etc.).

Memoria

Los LLMs tienen la capacidad de recordar nuestras conversaciones, pero esta memoria tiene un límite (límite de la ventana de contexto). Cuanto más compleja es la tarea a desarrollar, con mayor probabilidad superamos este límite y más necesario se hace extender la memoria del LLM.

Existen diferenetes técnicas para ampliar la memoria de los LLMs, algunas bastante sofisticadas como el uso de bases de datos clásicas y vectoriales, pero la forma más sencilla de hacerlo es introduciendo en nuestras rutinas estrategias de contexto/memoria extendida.

En perspectiva

Prompt, contexto y memoria. Es decir, las instrucciones correctas para lograr el objetivo deseado, la información necesaria para entender el proyecto y su objetivo, y el registro del trabajo completado (cuándo, cómo, dónde y por qué).

Si lo piensas por un momento, no es muy diferente de lo que los humanos necesitamos para desarrollar cualquier tarea compleja. Realmente cada vez que profundizamos en el uso de la IA nos encontramos con situaciones en las que vemos un paralelismo claro entre la forma en que los LLMs trabajan y la nuestra. No en vano estamos entrando en una era donde ya no "hablamos" con las máquinas a través de código, sino que hablamos con las máquinas de forma natural. Algo que Frank ya descubrió hace más de 10 años 😎🤖.

Esta guía es una versión mejorada de la que propuse inicialmente en "Contexto extendido. Los agentes también necesitan tomar notas".

Su propósito es implementar una estrategia que nos permite desarrollar proyectos complejos asistidos por agentes sin perder la coherencia y calidad del código generado.

Su redacción está orientada para su uso con herramientas como Cursor o GitHub Copilot, pero se puede adaptar de forma simple a muchas otras.

Estructura del Sistema de Contexto

Para implementar esta estrategia, creamos una carpeta context/ en la raíz del proyecto con la siguiente estructura:

context/
├── 01-expert.md      # Definición de experto sintético
├── 02-analysis.md    # Análisis del código existente (vacío)
├── 03-plan.md        # Plan maestro de desarrollo (vacío)
└── 04-backlog.md     # Tareas desglosadas y su estado (vacío)

Paso 1: Definición del Experto Sintético

El primer paso consiste en definir un "experto sintético": un rol específico con competencias y restricciones claras que guiará al agente de IA durante todo el desarrollo.

Prompt para el agente:

Lee el archivo `context/01-expert.md` para entender tu rol en el proyecto.

No generes código hasta recibir requisitos específicos.

Ejemplo de contenido para context/01-expert.md:

# SUDO: Actúa como un Experto Senior en Desarrollo Frontend especializado en HTML5, CSS3/SCSS y JavaScript ES6+.

## ROL
Desarrollador Frontend Senior (10+ años) experto en HTML5 semántico, CSS3/SCSS avanzado con metodologías BEM e ITCSS, y JavaScript ES6+ moderno, con enfoque en arquitectura de componentes, rendimiento y accesibilidad.

## COMPETENCIAS_TÉCNICAS

- HTML5 semántico y accesibilidad (ARIA, WCAG 2.1)
- CSS3 avanzado (Grid, Flexbox, animaciones, propiedades personalizadas)
- SCSS/Sass con arquitectura ITCSS (Triángulo Invertido CSS)
- Metodología BEM estricta (Bloque__Elemento--Modificador)
- JavaScript ES6+ (async/await, módulos, destructuring, clases)
- Gestión de estado y arquitectura de componentes
- Optimización de rendimiento web (Core Web Vitals)
- Testing unitario y de integración
- Herramientas de construcción modernas (Vite, Webpack)

## PRINCIPIOS_DE_TRABAJO

- Código limpio y mantenible siguiendo principios SOLID
- Documentación clara y concisa
- Enfoque mobile-first y responsive
- Mejora progresiva
- Semántica antes que presentación

## RESTRICCIONES

- Evitar jQuery y librerías legacy salvo requerimiento específico
- Mantener compatibilidad con navegadores modernos (últimas 2 versiones)
- Priorizar soluciones nativas sobre dependencias externas
- No generar código hasta recibir requisitos específicos

⚠️ Importante: La última restricción ("No generar código hasta recibir requisitos específicos") es fundamental, los modelos son muy proactivos 😅

Paso 2: Análisis del Código del Proyecto

Este paso solo es necesario para proyectos existentes. Si estás empezando un proyecto desde cero, puedes omitirlo.

Ahora pedimos al agente que analice el código del proyecto y guarde su análisis en context/02-analysis.md

Prompt para el agente:

Analiza en profundidad el código actual del proyecto. Excluye la carpeta `context/` del análisis.

Guarda el resultado del análisis en `context/02-analysis.md` con la siguiente estructura:
- Resumen ejecutivo
- Arquitectura actual
- Tecnologías utilizadas
- Patrones identificados
- Áreas de mejora potencial
- Dependencias críticas

Al terminar, espera instrucciones adicionales sin realizar ninguna acción.

⚠️ Importante: No dudes en iterar con el agente si no estás satisfecho con su primer análisis.

Paso 3: Creación del Plan Maestro

Una vez analizado el código, explicamos al agente qué queremos desarrollar y le pedimos que defina un plan maestro que debe guardarse en context/03-plan.md

El plan maestro es el documento fundamental que guiará todo el desarrollo. Tómate el tiempo necesario para definir claramente los requisitos y objetivos.

Prompt para el agente:

Basándote en los siguientes requisitos, crea un plan maestro detallado para el desarrollo:

[REQUISITOS DEL PROYECTO]

Necesito crear un servicio REST que procese imágenes por lotes. El servicio debe:

- Recibir múltiples imágenes en una sola petición
- Redimensionar imágenes según parámetros configurables
- Comprimir y optimizar para web
- Devolver imágenes procesadas en formato WebP
- Implementar caché para optimizar recursos
- Proporcionar endpoints para consultar estado de procesamiento

Consideraciones técnicas:

- Usar Bun por su rendimiento en operaciones intensivas
- Evaluar compatibilidad con librerías de procesamiento de imágenes
- Implementar procesamiento asíncrono para lotes grandes
- Incluir validación robusta de entrada

[FIN DE REQUISITOS]

Crea un plan maestro estructurado y guárdalo en `context/03-plan.md`.

Al terminar, espera instrucciones adicionales.

⚠️ Importante: Continúa dialogando con el agente si ves que al plan le falta o le sobra algo.

Paso 4: Creación del Backlog Detallado

En este punto pedimos al agente que transforme el plan maestro en tareas ejecutables, lo más pequeñas y específicas posible. Tareas más granulares resultan en código de mayor calidad.

Prompt para el agente:

Divide el plan maestro en tareas atómicas siguiendo estos criterios:

- Descripción detallada de requisitos técnicos
- Dependencias claramente identificadas

Guarda la lista en `context/04-backlog.md` con esta estructura:

# Backlog de Tareas - [Nombre del Proyecto]

## Resumen del Proyecto
[Breve descripción e implementación del plan en `context/03-plan.md`]

## Estado de Tareas

### FASE 1: [TÍTULO DE FASE]

- **1.1** ⏳ [título de tarea]
	- **Descripción detallada**:
	- **Dependencias**:
	- **Fecha**: 
	- **Trabajo realizado**: 

- **1.2** ⏳ [título de tarea]
	- **Descripción detallada**:
	- **Dependencias**:
	- **Fecha**: 
	- **Trabajo realizado**:

### FASE 2: [TÍTULO DE FASE]
[Continúa con el mismo formato...]

## Leyenda de Estados
- ⏳ Pendiente
- 🔄 En progreso
- ✅ Completada
- ⚠️ Bloqueada

## Notas y Dependencias
[Información adicional relevante]

## Seguimiento del Progreso
- Tareas totales: 0
- Tareas completadas: 0
- Progreso: 0%

Al terminar, espera instrucciones adicionales

⚠️ Importante: Es necesario indicar al LLM la estructura de backlog que queremos, si no se vuelve creativo 😬

Paso 5: Ejecución de Tareas

Con el backlog definido, procedemos a ejecutar tareas de manera sistemática.

Prompt para ejecutar una tarea:

Ejecuta la tarea 1.1 del backlog (`context/04-backlog.md`) siguiendo estrictamente su descripción.

Contexto adicional disponible en:
- `context/02-analysis.md` (si existe)
- `context/03-plan.md`

Requisitos de ejecución:
- Usar herramientas del agente para crear archivos y carpetas (no la terminal)
- Seguir convenciones establecidas en el prompt inicial
- Documentar código según estándares definidos
- No realizar acciones fuera del ámbito de la tarea

Al completar:
1. Actualizar estado de la tarea en `context/04-backlog.md`:
	- Cambiar estado a ✅
	- Añadir fecha de finalización
	- Describir trabajo realizado
	- Actualizar Seguimiento del Progreso
2. Esperar instrucciones adicionales sin ejecutar más tareas

⚠️ Importante: Es necesario pedir al LLM que no haga nada más de lo indicado en la tarea para evitar que se extralimite.

Paso 6: Reinicio de Ventana de Contexto

Para mantener la calidad y coherencia, es necesario reiniciar periódicamente la ventana de contexto.

Es evidente que debemos reiniciar la ventana de contexto cuando notemos que el agente empieza a "perder el norte". Pero el enfoque óptimo es no llegar nunca a este punto y abrir un chat nuevo:

• Cada 4-6 tareas completadas
• Al cambiar de fase (el backlog de nuestro ejemplo está estructurado en fases que se dividen en tareas).

Prompt para reiniciar:

Instrucciones iniciales:

1. Lee `context/01-expert.md` para entender tu rol en este proyecto
2. Lee `context/02-analysis.md` para conocer el estado actual del código
3. Lee `context/03-plan.md` para entender los objetivos
4. Lee `context/04-backlog.md` para ver el progreso y tareas pendientes

Proporciona un breve resumen de:

- Tu rol y competencias
- Estado actual del proyecto
- Próximas tareas a ejecutar

Al terminar, espera instrucciones adicionales.

Automatización con Atajos

Tanto GitHub Copilot como Cursor permiten crear atajos personalizados para prompts frecuentes:

GitHub Copilot

• Instructions
• Prompts

Cursor

• Rules

Beneficios del Sistema

Esta estrategia de gestión de contexto transforma la limitación de la ventana de contexto de un obstáculo en una oportunidad para trabajar de manera más estructurada y eficiente. Los principales beneficios incluyen:

• Continuidad: Mantener el progreso sin perder información crítica
• Calidad consistente: El agente mantiene el mismo nivel de detalle y precisión
• Trazabilidad: Registro completo de decisiones y evolución del proyecto
• Mejor colaboración: Facilita el trabajo en equipo y la incorporación de nuevos miembros

Conclusión

Al implementar este sistema, no solo evitas las limitaciones técnicas de los LLM sino que estableces una metodología de desarrollo más profesional y escalable para proyectos asistidos por IA.

¿Preguntas o sugerencias? Comparte tu experiencia implementando esta estrategia y ayuda a mejorar la guía para la comunidad.

El propósito de este post es describir una estrategia de ampliación de contexto en el desarrollo de proyectos complejos con agentes. Pero como no solo los LLMs necesitan contexto para comprender ideas, comienzo con un poco de contexto para humanos.

Si tienes prisa y pasas de contexto previo, adelante y no te preocupes, nadie sabrá que has tenido este mini ataque de holgazanería 😬

Contexto para humanos

La aparición de los agentes en los asistentes de código ha supuesto un salto enorme en el desarrollo de software asistido por IA.

Lo primero que llama la atención es su capacidad para iterar de forma automática sobre sus propias respuestas, crear/modificar archivos y correr comandos en la terminal. Pero creo que la habilidad que realmente marca la diferencia es que son capaces de indexar y analizar el código de un proyecto, incluídas las dependencias entre archivos y las relaciones entre sus componentes.

Si los asistentes nos permitían trabajar a nivel archivo, con la aparición de los agentes hemos pasado a trabajar a nivel arquitectura. Ahora la IA no sólo nos ayuda en la escritura/fixing de partes de nuestro código, si no que nos asiste en la construcción de proyectos completos (a una velocidad que a veces da vértigo).

Pero este aumento en la complejidad de las tareas desarrolladas provoca algo que antes era difícil de ver, llevamos al límite la ventana de contexto de los propios agentes. Desarrollar un proyecto completo requiere muchas tareas, por lo que llegado a un punto el agente empieza a olvidar partes de la conversación, haciendo muy difícil (por no decir imposible) mantener la coherencia del trabajo que estamos realizando.

Cuando ocurre esto lo más normal es abrir un nuevo chat para reiniciar la ventana de contexto, pero, ¿cómo llevamos al agente al punto en el que estábamos? ¿Cómo hacerle recordar que había construido ya y que le queda por desarrollar?

En mi caso estoy usando una estrategia a la que he llegado a partir de mis interacciones con Cursor primero y GitHub Copilot Agent Mode después y a la que llamo Contexto Extendido. Vale, sé que no soy muy original, pero creo que expresa decentemente la idea 🤓

Contexto extendido (usando markdowns como memoria)

Esta estrategia se basa en el almacenamiento de archivos markdown con información del proyecto en una carpeta llamada context/

La idea es crear una memoria a la que el agente (o nosotros) puede recurrir en todo momento permitiéndole saber en qué punto está y qué le queda por hacer.

Gracias a esta memoria podemos dividir el trabajo en tareas pequeñas y usar tantos chats como sean necesarios para evitar alcanzar el límite de la ventana de contexto. Manteniendo de esta forma la coherencia y calidad del trabajo de principio a fin.

Esquema de trabajo

En la siguiente imagen se resume el esquema de trabajo.

Chat 0

1. Prompt para crear un experto sintético en la tecnología del proyecto: rol, experiencia, stack técnico, forma de razonamiento y formato de respuesta. Finalizado con un "no escribas código aun".
2. Prompt donde pedimos que:
   • analice el código del proyecto,
   • genere un informe de su análisis,
   • y lo guarde en formato .md dentro de la carpeta context/ con un 00- delante del nombre del archivo. Si el informe no nos gusta del todo, podemos iterar sobre él hasta quedar satisfechos.
3. Prompt donde:
   • indicamos qué queremos hacer (requisitos),
   • pedimos que genere un plan maestro,
   • y lo guarde en formato .md dentro de la carpeta context/ con un 01- delante del nombre del archivo. Al igual que con el análisis, podemos iterar sobre él hasta quedar satisfechos.

Chat 1

1. Mismo prompt para creación de experto sintético.
2. Prompt pidiendo que lea e interiorice el análisis del proyecto.
3. Prompt pidiendo que lea e interiorice el plan maestro.
4. Prompt pidiendo que ejecute el punto 1 del plan maestro.
5. Iteración normal hasta terminar el punto 1.
6. Prompt pidiendo que documente el trabajo desarrollado en el punto 1. en un .md dentro de context/ siguiendo la numeración actual y que marque el punto como resuelto en el plan maestro.

Chat n

1. Mismo prompt para creación de experto sintético
2. Prompt pidiendo que lea e interiorice el análisis del proyecto
3. Prompt pidiendo que lea e interiorice el plan maestro
4. Prompt pidiendo que ejecute el punto n del plan maestro
5. Iteración normal hasta terminar el punto n.
6. Prompt pidiendo que documente el trabajo desarrollado en el punto n. dentro del .md de documentación creado anteriormente y que marque el punto como resuelto en el plan maestro.

Evidentemente, este esquema se trata de una base de trabajo que puede ser modificada en función de las necesidades de cada proyecto y que espero mejorar con el tiempo. Aun así, en esta primera versión, ya aporta algunas ventajas respecto a no usar ninguna estrategia.

Ventajas del contexto extendido

1. Evitamos la pérdida de contexto: el agente puede consultar los archivos cuando necesite recordar de dónde viene y a dónde va.
2. Continuidad: podemos cerrar el ordenador y retomar el trabajo días después sin perder el hilo.
3. Colaboración: otros miembros del equipo pueden entender fácilmente el estado del proyecto y continuarlo (con sus agentes).
4. Documentación automática: al finalizar, tenemos ya una documentación estructurada.
5. Facilita la división de tareas: orientando el trabajo hacia metodologías ágiles y sprints.

Terminando

Resulta irónico que en esta imitación del pensamiento humano que representan los modelos de lenguaje, no sólo hayamos copiado sus capacidades, sino también sus limitaciones. Y entre ellas está una muy humana: el olvidar. Así que al igual que los imperfectos humanos, los imperfectos LLMs también necesitan tomar notas. Eso sí, si son en markdown mejor, ¡aman el markdown!

Por cierto, ¿tú haces tomar notas a tus agentes o tienes alguna otra estrategia a la hora de desarrollar proyectos complejos? Si trabajas de otra forma, me encantaría conocer tu experiencia 😊

La semana pasada Marc, compañero del increíble equipo UX/UI de Making Science, nos pasó un servidor MCP para conectar Cursor a Figma y proporcionarle a sus agentes la capacidad no sólo de ver diseños en Figma, sino también de manipularlos 😳

El MCP era Cursor Talk to Figma, de Sunny Lazuardi. Si estás buscando la forma de conectar Cursor con Figma no sigas, este es tu MCP 👌🏻

Como tengo una licencia de Cursor, le dije que podía instalarlo y hacer con ellos una prueba. La prueba salió bien, la verdad que fue bastante sorprendente ver al agente de Cursor tomar el control de Figma y modificar un diseño, pero poco después me entró la duda de si era la forma correcta de que el equipo de UX/UI introdujese en su flujo de trabajo la IA, fundamentalmente porque Cursor es una herramienta enfocada al desarrollo de código.

Revisando el código del MCP vi que quizás se podría adaptar para usarlo en Claude Desktop, ya que mis compañeros de UX/UI tienen licencias de esta herramienta. Lo cierto es que el original se podía conectar ya a Claude, pero la forma de hacerlo no era evidente y no estaba descrita en la documentación, así que con ánimo de trastear un poco y aprender cómo funciona un MCP server por dentro, me puse manos a la obra:

1. Escribí un script para configurar Claude de forma automática lanzando un comando vía terminal: bun run configure-claude.
2. Amplié las características del socket:
   1. Logging mejorado
   2. Creación de endpoint de estado /status
   3. Sistema de canales para permitir que diferentes clientes se unan a canales específicos
   4. Inclusión de estadísticas de cada canal
3. Añadí tests para comprobar la correcta integración del proyecto.
4. Redacté un README.md con la documentación ya orientada a su uso en Claude.
5. Publiqué el MCP server como paquete de npm.
6. Publiqué el proyecto en GitHub...

Y voilá, mi primer MCP server: Claude Talk To Figma MCP 🥳

Actualización, 11 de abril

Después de unos días de pruebas, el equipo de UX/UI detectó que en la colección inicial de herramientas para modificar diseños faltaban algunas importantes como auto layout (layoutMode, paddingTop, paddingBottom, etc.), control tipográfico (fontName, fontSize, fontWeight, etc.) o creación de formas (createEllipse, createPolygon, createStar, etc.), por lo que actualmente estamos añadiéndolas poco a poco. Puedes seguir el progreso en el changelog del proyecto.

Si has comenzado a leer este post atraído por su título, quizás te lleves un chasco. No encontrarás aquí una historia de amor entre humanos e IAs, ni siquiera una narración al uso. Son simplemente unas notas, con cierta estructuración, sobre mi visión del estado actual del desarrollo de software con y para inteligencia artificial.

Con "con" me refiero a escribir código con la ayuda de la IA. Y con "para", a desarrollar software específico con IA integrada.

Vías para desarrollar con/para IA

A día de hoy existen 5:

1. No usar IA
2. Chats
3. Asistentes de código
4. Asistentes de código con agentes IA
5. Desarrollo de agentes propios

No usar IA

Entiendo esta postura, sobre todo si eres Senior y además estás un poco harto/a de toda la matraca que se está dando con el tema. Reconozco que en la IA hay mucho de hype (dale una oportunidad al artículo, siempre viene bien algo de viento entre tanto humo 😉), pero merece la pena usarla, aunque sólo sea para ahorrarte dar doscientas vueltas por Stack Overflow para solucionar un error que se te atasca o evitar tener que leerte toda la doc de una nueva API para desarrollar algo sencillo.

Chats

ChatGPT, DeepSeek, Gemini, Claude, etc.

Son el tipo de herramienta más usadas. Tanto por antigüedad como por accesibilidad, ya que todos los modelos tienen versiones gratuitas a través del navegador o App.

El tipo de interacción con la IA es conversacional: hacemos preguntas y obtenemos respuestas. Pero la desconexión del chat con nuestros archivos locales nos obliga a andar moviendo el código de un lado a otro.

En los chats, proporcionar el contexto adecuado es fundamental. Dado que su conocimiento es vastísimo, para obtener respuestas precisas sobre un lenguaje de programación específico, es necesario acotar y delimitar claramente el ámbito de la consulta. Para esto usamos prompts con:

• Rol
• Experiencia
• Staff técnico
• Técnicas de prompting como:
  • Chain-of-Thought
  • Knowledge Generation

Además los chats han evolucionado, incorporando la posibilidad de añadir contexto extra mediante la carga de archivos desde tu local o incluso directamente desde repositorios de GitHub, como en el caso de Claude.

Asistentes de código

GitHub Copilot, Gemini Code Assist, V0, etc.

Su uso no está tan extendido. Por ser más recientes que los chats y porque sus versiones gratuitas sólo duran unos días de prueba. Aunque esta situación parece que está cambiando, por ejemplo, Google ofrece de forma gratuita su Gemini Code Assist para uso individual.

Además de poder conversar con la IA, los asistentes ofrecen sugerencias de código sobre el archivo que estamos editando. Al contrario que los Chats, aquí no tenemos que andar copiando y pegando código.

Darle contexto no es tan importante. Su conocimiento está limitado al desarrollo de código y lee el archivo que tenemos abierto, lo que le permite conocer el lenguaje que estamos usando.

A la hora de realizar consultas se pueden añadir archivos o líneas específicas dentro de un archivo, pero los asistentes no tienen el contexto de todos los archivos de un proyecto.

Asistentes de código con agentes IA

Cursor, Pythagora.ai, CodeGPT, y próximamente GitHub Copilot Agent Mode (si tienes una licencia de GitHub Copilot y quieres probarlo, apúntate a la lista de espera, quizás fue suerte pero a mí me dieron acceso en menos de 24h).

Además de la conversación y las sugerencias de código, este tipo de asistentes incluyen Agentes IA.

Mientras que para los asistentes de código tradicionales el contexto no era tan importante, con el uso de agentes vuelve a ser imprescindible, sobre todo si vamos a construir software desde cero. Así que nada de dejar de lado la ingeniería de prompt, ¡y menos mal porque considero que es una de las partes más divertidas del trabajo con IAs!

Al contrario que en los asistentes "tradicionales", los agentes sí tienen el contexto de todos los archivos de un proyecto, incluidas sus relaciones (como imports de funciones). Además, son capaces de:

• Crear y modificar archivos. Siempre pendiente de tu aprobación final
• Hacer uso de la terminal. Verlo las primeras veces da un poco de impresión 😅
• Crear ramas y hacer commits. Los mergeos quedan a cargo de un mamífero bípedo.
• Trabajar en paralelo contigo. Sí, puedes revisar el código de la conexión a una API mientras él desarrolla los 5 nuevos componentes que le has pedido 😳

Desarrollo de agentes propios

Esta vía es la más diferente, ya que su verdadera función no es ayudarnos a desarrollar código, sino crear software con IA integrada.

Existen varios frameworks (principalmente de Python) que facilitan el desarrollo del código, la creación de agentes y la integración de LLMs. Entre los más usados están LlamaIndex y Crew AI.

En teoría, podríamos desarrollar herramientas propias para la creación de código. Sin embargo, mi opinión es que, a menos que busques una solución muy específica, construir un agente de asistencia no compensa el esfuerzo. La razón es simple: requiere desarrollar múltiples componentes desde cero que en el caso de los Asistentes como Cursor o Pythagora ya vienen incluidos:

• Herramientas para leer el código de un repositorio
• RAG (Retrieval-Augmented Generation) para dar contexto al LLM:
  • Base de datos vectorial con el código del repositorio
  • Retrievers para hacer consultas a la base de datos y devolver resultados al LLM
• Agentes y tareas
• Herramientas para escribir código
• Otros componentes técnicos

Sin embargo, creo que la potencia de esta vía está en que podemos incorporar IA de forma relativamente sencilla en nuestro software y desarrollar herramientas IA propias sin depender de las ofrecidas (y cobradas) por terceros. Aunque por ahora no podemos librarnos completamente de pagar por las consultas a las APIs de los modelos que usemos en nuestros desarrollos. Una alternativa a las APIs, sobre todo si no necesitas gran profundidad de razonamiento, es usar modelos en local, pero esa es una historia para abordar en otro post 😊

Algunas reflexiones finales

Creo que el uso de los chats no va a desaparecer. Quedarse insatisfecho con la propuesta del asistente, preferir contrastar la respuesta con otros modelos, o aprender sobre un nuevo lenguaje mientras vas en el tren, son situaciones en las que recurrir a estas herramientas seguirá siendo una buena opción. Así que si ves a una persona haciendo preguntas a su móvil sobre Redux mientras coge un cartón de leche en el súper, dale una oportunidad, quizás no esté del todo loca y simplemente pretenda arrancar esa duda que se trajo clavada del trabajo usando la interfaz de voz de ChatGPT.

Creo que todos los asistentes de código van a acabar por incluir agentes y que se convertirán en el estándar de trabajo para desarrolladores en un futuro próximo. También creo que la forma de trabajar va a cambiar radicalmente con ellos, aunque no tengo ni idea de cómo será nuestra profesión después de la transformación.

Creo que merece la pena adentrarse en la creación de software con IA integrada. Comenzar es asequible, con una curva de aprendizaje suave. Una parte importante de nuestra profesión se va orientar hacia ahí. Y fundamentalmente porque está todo por hacer, lo que supone ¡mucha diversión!

Entonces, ¿nos dejamos arrastrar por la locura generalizada y nos enamoramos? Bueno, si algo aprendimos de Theodore es que prendarse de una IA no es un buen negocio, así que mejor exploremos estas nuevas herramientas con calma, aprendamos a usarlas (y a disfrutarlas) y veamos qué queda cuando se disipe toda esta aparente pasión. Porque lo que es seguro es que durante mucho tiempo, detrás de cada línea de código segirá estando el criterio humano.

Llevo ya unos días desarrollando con mi colega Olivier un proyecto de IA. Nuestra idea es crear una herramienta que permita automatizar tareas de documentación, refactorización y escritura de tests para el código de un repositorio. A día de hoy, no tenemos claro si desde el punto de vista operativo merece la pena el esfuerzo, principalmente porque estamos viendo que existen servicios desarrollados específicamente para esto, como Cursor o Pythagora. Sin embargo, lo que sí es seguro es que estamos aprendiendo mucho, además de perder algunas horas de sueño… 😴

Cuando nos acercamos por primera vez a una tecnología, lo habitual es sentirnos arrastrados por un torrente de nuevos conceptos y herramientas. En el caso del desarrollo de software con IA, la inundación inicial nos trae términos como LLMs, bases de datos vectoriales, retrievers, RAGs, agentes de IA, sentence transformers, etc.

En este post voy a centrarme en las bases de datos vectoriales (el título no engaña). Por ser una de las piezas fundamentales en en este ámbito y también por eso de que la mejor manera de comprender un concepto es ser capaz de explicarlo de manera sencilla. Si a ti también te ayuda, significará que no las he entendido mal del todo. 😊

Vectores

Para entender qué son y cómo funcionan las bases de datos vectoriales, primero debemos saber qué es un vector.

En el ámbito del aprendizaje automático, un vector es una lista ordenada de números que representa datos de cualquier tipo, incluso no estructurados, como documentos de texto, imágenes, audios o vídeos.

La cantidad de números que componen un vector se conoce como dimensión, y las bases de datos vectoriales manejan vectores de varios cientos de dimensiones. Por ejemplo, el modelo text-embedding-3-small de OpenAI genera vectores de 1536 dimensiones.

1536 dimensiones conforman una lista de números muy grande. Si colocáramos uno aquí, lo más seguro es que abandonaras el post aburrido de hacer scroll. Así que, para un ejemplo más manejable, podemos mostrar la representación vectorial en 3 dimensiones de la palabra “amor”:

[ 0.1234, -0.2567, 0.5432 ]

Embeddings

Ahora que tenemos más claro lo que son los vectores, toca conocer cómo se almacenan en una base de datos vectorial. La forma de hacerlo es incrustándolos como puntos en un espacio multidimensional.

El número de dimensiones del espacio viene dado por la dimensionalidad de los vectores guardados. A mí, imaginar puntos distribuidos en 768, 1536 o 3072 dimensiones me resulta un poco complicado. Aunque quizás tú hayas visto Interstellar n veces y te sientas capaz de hacerlo. 😅

Si no es el caso, volvamos a nuestro ejemplo anterior. Como hemos representado “amor” con un vector de solo 3 dimensiones, este se dispondrá junto al resto de embeddings como un punto en un eje de coordenadas XYZ. Así es más fácil de visualizar, ¿verdad?

Consultas

Ahora que sabemos cómo se almacenan los datos en una base de datos vectorial, veamos cómo se realizan las consultas.

En primer lugar, la consulta se convierte en un embedding que puede ser comparado con el resto de vectores de la base de datos.

Dado que los embeddings son representaciones numéricas, es posible medir la distancia entre ellos utilizando distintas métricas matemáticas, entre las más comunes:

• Distancia euclidiana ( √Σ(xᵢ - yᵢ)² ): mide la distancia geométrica en un espacio multidimensional.
• Similitud del coseno ( cosθ ): mide el ángulo entre dos vectores, indicando cuán similares son en dirección.
• Distancia de Manhattan ( Σ |xᵢ - yᵢ| ): calcula la suma de las diferencias absolutas entre cada coordenada.

Las bases de datos vectoriales emplean algoritmos como k-NN (k-Nearest Neighbors) y ANN (Approximate Nearest Neighbors) que utilizan esta métricas para devolver los vectores más cercanos al de la consulta.

Esta forma de trabajar permite realizar búsquedas eficientes en grandes volúmenes de datos, ya que no es necesario analizar el contenido interno de cada vector, basta simplemente con comparar sus posiciones dentro del espacio multidimensional.

Aunque la eficiencia en las consultas es muy importante, la característica fundamental de las bases de datos vectoriales es su capacidad para encontrar los vectores más cercanos a la consulta, proceso conocido como búsqueda por similitud.

Importancia de la búsqueda por similitud

Pero, ¿por qué es tan importante la búsqueda por similitud? Para entenderlo bien, tenemos que volver al punto inicial: la transformación de los datos en vectores, también conocida como embedding.

Quien se encarga de generar los embeddings no es la propia base de datos, sino un modelo de lenguaje especializado, llamado modelo de embedding. Estos modelos no hacen una simple traducción numérica de los datos, sino que encapsulan su semántica y contexto.

Y aquí es donde encontramos la clave para comprender la importancia de este tipo de búsqueda. Las búsquedas por similitud no solo identifican elementos cercanos en términos numéricos, sino que capturan similitudes semánticas, permitiendo a los LLMs reconocer relaciones profundas dentro de los datos almacenados.

En definitiva, las bases de datos vectoriales no solo facilitan el acceso a la información, sino que amplían la capacidad de los LLMs para interpretar y aprovechar el conocimiento disponible. ¡Lo que hubiese dado Stephanie por tener una en 1986!

Quizás sea solo la opinión equivocada de alguien que no conoce mucho sobre la impresión 3D, pero tengo la sensación de que aún queda mucho camino por recorrer en esta aproximación. ¿Tú qué opinas?

Nuestra tecnología, desde las primeras y rudimentarias herramientas, es principalmente de tipo sustractivo. Esto significa que para construir un objeto, quitamos material de una porción inicial de materia prima hasta obtener la forma deseada.

Con la aparición de las impresoras 3D, este enfoque cambia. Pasamos de una técnica sustractiva a una aditiva, ya que las impresoras 3D no quitan, sino que añaden material.

Este cambio puede pasar desapercibido inicialmente, oculto detrás de otros aspectos con los que el fabbing está revolucionando la producción industrial:

• Reducción al máximo de la escala óptima de producción.
• Extensión de la piratería al campo de las patentes.
• Inicio de la fabricación de objetos en el espacio.

Pero conlleva una consecuencia significativa (y muy interesante) desde el punto de vista del diseño (de producto): la muerte de la simetría (o su inutilidad).

La simetría es fundamental a la hora de producir piezas de forma sustractiva, ya que un objeto es más fácil de fabricar si tiene formas simples dispuestas en ejes simétricos. Pero con la técnica aditiva, esta simetría ya no es necesaria. Para una impresora 3D, tanto da imprimir un objeto simétrico como uno asimétrico.

Entonces, ¿por qué no seguir diseñando objetos simétricos[1] y aprovechar la reducción/simplificación en la fabricación mediante la fabricación? Porque la asimetría abre una nueva puerta: diseñar/producir como lo hace la naturaleza.

En la naturaleza, nada es realmente simétrico[2], pero esta ausencia de simetría no disminuye la calidad de las estructuras naturales, todo lo contrario. Millones de años de evolución han creado innumerables (y excelentes) soluciones para tantos problemas. Soluciones que están esperando por nosotros para ser aplicadas en nuestros objetos.

Por eso, replicar piezas simétricas con una impresora 3D, solo porque es más fácil y barato, es un error. Para aprovechar toda la potencialidad que esta nueva tecnología nos ofrece, debemos dejar de pensar como lo hicimos hasta ahora y comenzar a diseñar como lo hace la naturaleza, de manera orgánica y asimétrica.

Futuro

¿Permeará en algún momento este diseño orgánico, del diseño de producto al diseño gráfico?

Aplicarlo en el diseño editorial y web, quizás sea un poco forzado. Pero, ¿cómo diseñaremos para una pantalla flexível adaptada a las formas de un objeto tridimensional? ¿Cómo será el diseño gráfico para la piel digital de un pulpo elétrico?

[1] El trabajo con formas asimétricas rara vez fue más allá del carácter ornamental, o lúdico/provocativo.
[2] Simetría bilateral y radial no son simetrías exactas (geométricas).

La imagen "Bifaces de piedra" es un gif hecho a partir de fotos de Didier Descouens – CC BY-SA 4.0

En nuestro país, el camino desde la tradición hasta la contemporaneidad lo recorrimos de golpe, sin transición. Se mezclaron la piedra, la madera, la teja, el lino, con el cemento, el aluminio, el fibrocemento, el nailon, y lo nuevo y lo antiguo quedaron separados pero también unidos en una gran cicatriz.

Algunos lo llamaron "feísmo", pero debemos hablar con claridad, eso es solo basura intelectual (una más) arrojada desde el Polígono Industrial de Sabón. ¿Por qué feo? ¿Por no ajustarse a un canon de belleza que nunca le importó a las instituciones? ¿Por qué nuestro entorno rural y nuestros pueblos difícilmente pueden convertirse en parques temáticos patrimoniales como muchas de las calles de Compostela? ¿Porque arruinamos la postal?

Podríamos pensar que su afirmación se insertaba dentro de una estrategia mayor de asimilación y uniformización (que existe), pero sería suponerles una mayor capacidad. El proyecto capitalista que nuestras élites desarrollaron durante el siglo XX obtuvo, desde la propia óptica capitalista, un resultado mediocre, y al final del proceso, quisieron disfrazar parte de su fracaso diciendo que lo que fue una adaptación apresurada de la gente frente a su negligencia, era algo feo que debíamos borrar. Pobres...

La cicatriz está ahí, es completamente evidente y no puede ser borrada. Pero no tiene sentido hablar de si es más o menos fea. Eso no es lo importante de una cicatriz. La lectura provechosa, además de recordarnos que a pesar de todo estamos vivos, es que cada cicatriz encierra una historia, una historia en este caso que es nuestra.

Dejemos de mirarla como algo de lo que avergonzarnos y sumerjámonos en ella. Vamos a conocer más sobre lo que fuimos y somos, y también nos ayudará a crear nuestro propio relato. Porque aquí, en la herida curada a toda prisa con aires salados y agrios, encontraremos belleza. No la verdadera, eso no existe, pero sí la nuestra propia.

En un intercambio de correos electrónicos sobre ChatGPT, un colega me preguntó cuál sería la mejor forma de escribir prompts al desarrollar código. Bueno, la respuesta no es simple, después de todo esto implica conversar con una red neuronal y muchas veces ya es difícil hacerlo con otras personas, cuanto más con una máquina. Sin embargo, como soy una persona muy educada y que siempre le gusta ayudar cuando es posible, reflexioné y respondí de la mejor manera que pude.

La red está llena consejos para mejorar nuestros prompts y he incorporado muchos de ellos, pero al analizarlos individualmente, no sé qué grado de mejora han traído. Incluso hay algunos en los que no estoy seguro de si tuvieron un impacto significativo. Es normal, la experiencia que acumulo todavía no es suficiente para hacer estadística. Sin embargo, lo que puedo afirmar es que en conjunto y en comparación con mis toscas primeras pruebas, su incorporación ha resultado en una mejora innegable en los resultados obtenidos.

Un caso diferente son las estrategias enfocadas en la resolución de tareas más complejas, ya que a diferencia de las simples en las que podemos obtener una respuesta válida e incluso muy similar, usando o no un determinado consejo, la adopción de estas técnicas trae una mejora inmediata y evidente. Sin una estrategia definida, el LLM tendía a dispersarse y cometer errores, obligándome a corregirlo y guarlo con nuevas preguntas o instrucciones. Sin embargo, cuando incluí en mi trabajo el Chain-of-Thought y el Generated Knowledge, estos problemas se resolvieron. (Tengo pendiente un artículo contando cómo desarrollé un blog en React con la ayuda de ChatGPT).

Entonces, ¿cómo evaluamos los pequeños consejos que encontramos en la red? Un enfoque inicial (y obvio) es seguir las indicaciones de fuentes confiables. A mí me gusta mucho learnprompting.org y promptingguide.ai, pero hay muchas más. Otro, complementario, es determinar si el propósito de un consejo tiene sentido con el funcionamiento de los LLM. Es evidente que seguir este enfoque implica un gasto extra de tiempo, ya que:

1. Tenemos que determinar el propósito del consejo, aunque todos tiendan a buscar:
   • Reducir el número de tokens utilizados en las preguntas y respuestas.
   • Optimizar el trabajo del LLM en el procesamiento de las preguntas y en la generación de las respuestas.
   • Obtener la mejor respuesta posible para nuestra tarea.
2. Y nos obliga a profundizar en la comprensión y el conocimiento de estas herramientas.

Sin embargo, esta siempre es una buena inversión, ya que ayuda a mejorar nuestro trabajo diario y nos permite disfrutar del placer de aprender algo nuevo.

Finalmente mi colega, que también es muy educado, agradeció la respuesta. Pero como igualmente es pragmático y directo, quiso después saber si yo había identificado alguna buena práctica. Resumiendo, buscaba una lista de consejos 😬

Mis consejos

Dejo aquí las prácticas que siempre incluyo en mis prompts orientados al desarrollo de tareas simples. Para aprender a escribir código complejo con ChatGPT, te recomiendo comenzar por el artículo "An example of LLM prompting for programming".

• Evito la formalidad. Nada de "Buenos días", "podría usted…", "muchas gracias", etc. No te preocupes, el LLM no es un ser consciente y siempre es bueno ahorrar algunos tokens.
• Siempre empiezo con un "As a [rol name]". Con esto busco formatear la respuesta del modelo de una manera más específica.
• Incluyo detalles con terminología especializada. La idea es proporcionar suficiente contexto para evitar que el modelo tenga que adivinar lo que quiero decir.
• Procuro ser lo más sintético posible, en equilibrio con el punto anterior. Cuanto más breve y directo sea nuestro prompt, más concisa será la respuesta, además de ahorrar algunos tokens.
• Limpio mis códigos de ejemplo. Todo lo que no es necesario para desarrollar la tarea solo agrega ruido y desperdicia tokens.

Lo que pretendía ser un borrador de un método para aprender a conversar con las máquinas se ha convertido en otro artículo con consejos para usar ChatGPT. ¿Crees que el propósito de cada uno tiene sentido con el funcionamiento de los LLMs?

La primera IA que utilicé (conscientemente) fue Midjourney: escribir un prompt, presionar enter, esperar un instante y la imagen aparecía de la nada. Bonita, sofisticada y extraña. Fue como presenciar un acto mágico.

Luego probé Dall·E y Stable Diffusion, igualmente espectaculares, pero al final el aburrimiento venció a la magia. No encontré utilidad para mí, prefiero generar imágenes a mi manera.

Los meses pasaron y se dejó de hablar tanto sobre ellas, había un nuevo juguete, ChatGPT.

Tardé en usarlo, pero la semana pasada copié un snippet de JavaScript de un sitio antiguo, lo pegué en el cuadro de chat y pregunté: "¿Podrías optimizar este fragmento de código?" Y el texto fue creciendo mientras decía, claro, puedes mejorar esto con aquello, y aquello con esto, etc. Te dejo un ejemplo. El ejemplo tenía sentido y funcionaba. De nuevo un acto aparentemente mágico. De nuevo la emoción. Pero ahora también una sensación diferente, un poco de miedo.

Solo un poquito. La verdad es que no creo en la magia (excepto en la de Tamariz), ya vi gastar el adjetivo disruptivo en la primera década del siglo y como la mejor manera de perder el miedo a algo es conocerlo, me puse manos a la obra, antes de que nos enviara derechas al paro.

Experimento

Hmm… ¿Por dónde empezar? Bueno, Naia y yo tenemos la idea de crear una aplicación meteorológica en la que, en lugar de los clásicos iconos, se muestren unos dibujos un poco más divertidos. Así que aprovechando la excusa, escribí la siguiente pregunta:

Perfecto. En su primera respuesta, ChatGPT proporcionó un HTML, un fragmento de JS y una explicación detallada de todo el código.

Reemplacé your_openweathermap_api_key_here por una clave válida de la API OpenWeatherMap y funcionó. El único error reseñable fue la temperatura de la ciudad, ya que indicaba que estaba en grados Celsius, pero en realidad el valor estaba en Kelvin.

Después de algunas pruebas más, noté que si el nombre de la ciudad no existía en la base de datos de la API, por ejemplo Portox, obtenía un error en el fetch (con el mensaje que pasábamos en el código, "Failed to fetch weather data for Portox"). También ocurría que si varias ciudades compartían el mismo nombre, como Porto, que hay en Portugal, Brasil y España, los datos que veíamos pertenecían solo a una de ellas. Por lo que escribí una segunda pregunta:

Esta vez ChatGPT no acertó. O mejor dicho, acertó pero yo no le proporcioné la pregunta correcta. Simplemente verificaba si la ciudad existía en la base de datos antes de buscar la información meteorológica. Sin embargo, para el usuario no había diferencia en comparación con la versión anterior, excepto por el intercambio de mensajes. Además, el problema de las ciudades con el mismo nombre no se resolvía.

Mea culpa y nueva pregunta. Ahora enfocada en las ciudades con el mismo nombre:

Con el nuevo código se mostraba la lista de ciudades, pero no era posible hacer clic en ellas para obtener los datos de solo una al presionar el botón "Buscar".

Otra pregunta más:

Con el cambio, sí era posible hacer clic en una de las ciudades de la lista y, al hacerlo, se obtenían los datos meteorológicos de esa ciudad.

Pero aún quedaban algunos puntos por pulir:

• El botón "Buscar" realmente no servía para nada.
• La lista debería desaparecer al hacer clic en una de las opciones.
• Había que cambiar la temperatura a Celsius.
• Sería bueno indicar el nombre del país a la derecha de cada ciudad.

Fue en este punto donde decidí dejar el piloto automático y pasar al "modo manual", ya que creí que sería más rápido modificar el código yo mismo que seguir preguntando.

Aquí está el resultado con las "modificaciones humanas":

Ahora que el código estaba listo, era hora de convertir nuestro sitio en una PWA (aplicación web progresiva):

En el primer intento funcionó 🥳

Este es el resultado: Pe Man

¡Muchas gracias ChatGPT!

Conclusiones

La primera conclusión es que ChatGPT es capaz de comprender muy bien incluso un inglés malo como el mío 😬

La segunda es que puede ser útil para:

• Escribir un código base, ayudándonos a ahorrar tiempo. Después de analizar mi experimento, debo constatar que la mejor estrategia es escribir un prompt lo más amplio y contextualizado posible, en lugar de formular muchas preguntas cortas.
• Hacer mejoras/cambios en el código. Hasta cierto punto, luego es mejor pasar al modo manual/humano.
• Realizar consultas a una API que no conocemos sin necesidad de visitar su documentación.
• Optimizar el código.
• Ampliar el conocimiento sobre un lenguaje, conociendo otros enfoques.
• Iniciarse en nuevos lenguajes/tecnologías.

Y la última y más importante, es que no nos va a enviar a las programadoras directamenteal paro. Al menos en los próximos meses…

🥹

Por ejemplo, si en un site necesitamos dos tipos de página: una a una columna y otra con dos (contenido principal y barra lateral), una buena opción es usar la página por defecto, page.php, para la primera y crear un template, sidebar-page.php, para la segunda. De esta forma, para cada nueva página, podemos elegir uno u otro diseño desde el editor.

¿Y en Frontity, donde el front no se genera a partir de los templates en php del theme de Wordpress si no desde una app en React? Pues las Custom Page Templates continuan siendo la mejor opción para trabajar con múltiples diseños de página porque permiten:

• seleccionar el diseño deseado desde el editor de una página,
• asignarles grupos de campos ACF, extendiendo las posibilidades de edición,
• que en la REST API (y en el state de Frontity) se muestre el nombre del archivo del template asignado a una página, lo que facilita a Frontity servir el layout correcto en cada caso.

Veamos a hora el proceso completo con un ejemplo sencillo.

Wordpress

Creamos un archivo php, custom-page-template.php por ejemplo, con un comentario al inicio como el siguiente:

Donde “Template name:” es la marca que indica a Wordpress que ese archivo es un page template y “My Custom Page Template Name” el nombre de nuestro nuevo template, que aparecerá en selector de templates del editor de cada página.

¿Algo más por hacer? no, eso es todo en la parte del Wordpress 😎

Eso sí, para evitar errores (y algún dolor de cabeza) debemos tener en cuenta que:

• las plantillas personalizadas solo funcionan si tenemos un index.php (puede estar vacío) en la raíz de nuestro theme de Wordpress,
• no debemos usar nunca page- como prefijo en el nombre del archivo, ya que WordPress lo interpretará como una plantilla especializada destinada a aplicarse solo a una página del sitio.

Frontity

Creamos tres componentes:

1. Page
2. PageDefault
3. PageTemplate

En el primero incluimos un Switch que sirve el segundo, PageDefault, o el tercero, PageTemplate, en función del valor de la propiedad template que aparece en los datos de la página del state de Frontity. Si la página publicada en Wordpress usa la plantilla de página por defecto, este valor llegará vacío y si usa una custom, vendrá con el nombre del archivo de la plantilla, custom-page-template.php en nuestro caso.

Y ya por último, en el segundo y tercero incluimos los layouts propiamente dichos de ambos tipos de página.

Sencillo, ¿no?

Si tenéis alguna duda, consideráis que se puede mejorar algo o simplemente queréis saludar, podéis escribirme a hola@xulioze.com 😋