1. Publicas um artigo no teu site.
2. Publicas um post numa app do AT Protocol (Bluesky, Mu, Deer, etc.) com a ligação para esse artigo.
3. Inseres o componente no teu HTML, apontando para o post através da sua AT URI:

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

E pronto: as respostas a esse post aparecem como comentários no teu artigo. Além disso, se um visitante com conta numa app do AT Protocol quiser comentar, escolhe a sua app e é redirecionado para o post.

O objetivo é duplo. Por um lado, oferecer um sistema de comentários fácil de integrar, sem base de dados própria e sem depender de plataformas como o Disqus. Por outro, trazer para o teu site as conversas que hoje ficam fechadas dentro das redes sociais.

Se não conheces o AT Protocol, continua a ler. Vou-che contar o caminho que segui até o conhecer e entender, porque tenho a intuição de que vai ser mais útil do que uma definição de manual.

Há um ano e meio, farto da esterqueira em que se converteu o X, procurei alternativas. Dei com o Bluesky, que prometia ser uma rede aberta e tinha uma interface com vibes do velho Twitter. Gostei: case sem ruído, nazis e bots. Mas não entendi o porquê do "aberta".

Em março vi um chio da Eurosky, uma iniciativa europeia independente que trabalha para construir uma web social aberta. Convidavam a mudar as nossas contas do Bluesky, alojadas em servidores nos EUA, para os seus servidores na Europa, e a continuar a conversar no Bluesky. Como? Isto já era um chisco mais estranho. Mas era verdade: mudei a minha conta para a Eurosky e continuei a conversar no Bluesky.

Em junho, outro chio da Eurosky. Desta vez anunciavam o mu.social, uma nova app de microblogging. Experimentei entrar com as minhas credenciais do Bluesky e fiquei co cu torto. Ali estava o meu perfil, com os meus posts, a gente que sigo e os meus seguidores. Tudo. Depois dei com o Deer e passou a mesma cousa.

Espera, isto lembrava-me algo que já tinha vivido. Já sei: o RSS, o Google Reader, o Feedly, a época dourada dos blogues! Quando a internet era descentralizada e o que líamos e publicávamos não estava deformado polos algoritmos de empresas privadas.

Investiguei e recapitulei. Isto era possível porque o Bluesky está construído sobre o AT Protocol, um protocolo aberto para redes sociais descentralizadas. Nele, os teus dados vivem num servidor de dados pessoal (PDS) e estão assinados criptograficamente. Por isso podemos mudar de fornecedor sem perder a conta nem os seguidores (os dados são nossos!), e até montar o nosso próprio servidor (ligação ao repositório no GitHub). Podemos consumir os nossos dados e os das pessoas que seguimos a partir de diferentes apps. E podemos desenvolver ferramentas como o atproto-comments, que agora publiquei, sem depender do que uma empresa decida em cada momento.

Como funciona por dentro

Se queres ver as peças do puzzle, estas são as que entram em jogo quando o atproto-comments carrega os comentários:

• Identidade (DID e handle): cada conta tem um identificador permanente (did:plc:...) e um nome legível (@xulio.eurosky.social). O DID é o que permite mudar de servidor sem perder nada.
• PDS (Personal Data Server): o servidor onde vivem os teus dados, num repositório assinado. Pode ser o do Bluesky, o da Eurosky ou o teu próprio.
• Lexicons e registos: cada tipo de dado tem um esquema público. Um post é um registo da coleção app.bsky.feed.post; por isso a AT URI aponta para at://<did>/app.bsky.feed.post/<id>.
• Relay: recolhe as mudanças de todos os PDS e emite-as num fluxo único (o firehose).
• AppView: consome esse fluxo, indexa-o e serve vistas já montadas, como o fio de respostas de um post. O atproto-comments pede esse fio à API pública do AppView do Bluesky (app.bsky.feed.getPostThread), mas podes apontá-lo para outro AppView com o atributo appview.
• Apps clientes: Bluesky, Mu, Deer… são só interfaces diferentes sobre os mesmos dados, e cada uma pode decidir como os mostra: que algoritmo usa, como ordena o feed, que moderação aplica. Se um dia não gostar de como o Bluesky me serve o feed, mudo para outra app que o faça mais ao meu gosto, sem perder nada.

No fundo, é a mesma ideia daquela época dourada dos blogues: os dados são teus e podes lê-los, publicá-los e levá-los para onde quiseres. O atproto-comments é só uma pequena peça mais nesse puzzle. Experimenta-o e, se o usares no teu site, conta-mo respondendo ao post deste artigo: o teu comentário vai aparecer aqui em baixo.

Este guia é uma versão melhorada da que propus em "Contexto Estendido. Os agentes também precisam de tomar notas" e Guia: desenvolver software de qualidade assistido por agentes de IA.

Quando chegaram os editores com agentes de IA autónomos (Cursor, GitHub Copilot, Claude Code), muitos compramos a promessa: "escreve o prompt perfeito e o agente gera a feature completa de uma vez". A realidade foi outra: sem estrutura nem constraints, acabávamos a dedicar mais tempo a corrigir bugs que a escrever código.

O "vibe-coding", confiar em que o agente "apanhe a vibe" do teu projeto, funciona bem para protótipos rápidos, mas em projetos reais e complexos gera mais problemas que soluções:

• Decisões perdidas: Porque escolhemos esta arquitetura há duas semanas?
• Alucinações constantes: A IA inventa APIs, mistura frameworks, ignora constraints
• Trabalho monolítico: Impossível dividir features em tarefas rastreáveis
• Improvisação contínua: Cada sessão começa do zero

Há uns meses documentei uma solução (v1): um workflow estruturado (análise → solução → backlog → execução → progresso guardado) com quatro arquivos de contexto que convertia o vibe-coding em engenharia rastreável. Funcionou, mas havia fricção: repetir manualmente os mesmos prompts em cada sessão era doloroso.

Este guia apresenta a evolução desse sistema (v2). Aproveita o sistema de rules do Cursor para automatizar prompts e converte o workflow em protocolos reutilizáveis. Mas ao desenhá-lo emergiu um padrão universal: separar conhecimento reutilizável (rules) de memória temporária (memory). Isto vai além de poupar-te escrever os mesmos prompts: podes reutilizar o conhecimento em diferentes projetos e levar um registo ordenado de tudo o que fazes. E o padrão funciona com qualquer ferramenta de IA, não só com Cursor.

Vamos ver como construir essa arquitetura.

Problema de v1

Sistema de quatro arquivos em context/:

• 01-expert.md - Perfil do especialista
• 02-analysis.md - Análise do código
• 03-plan.md - Plano de implementação
• 04-backlog.md - Tarefas pendentes

Limitações em Projetos Reais

Conhecimento misturado: 01-expert.md combina princípios gerais (KISS, DRY) com constraints específicos do projeto (stack, versões, dependências críticas). Impossível reutilizar princípios entre projetos sem arrastar configuração irrelevante.

Duplicação entre projetos: Cada projeto replica conhecimento comum. Se trabalhas em 3 projetos WordPress, tens security: sanitize_*, nonces copiado três vezes. Atualizas uma best practice, deves sincronizar manualmente.

Sem gestão de histórico: v1 dá-te três opções, todas más:

• Sobrescrever 02-analysis.md → perdes decisões prévias
• Acumular análises no mesmo arquivo → cresce descontroladamente, impossível rastrear quando se tomou cada decisão
• Criar múltiplos arquivos (02-analysis-feature-X.md) → desordem, sem nomenclatura consistente

Em todos os casos: Porque rejeitaste a arquitetura X há duas semanas? Não há forma sistemática de recuperá-lo.

Sem modularidade: Mudar de WordPress a React requer reescrever 01-expert.md completo. Não podes manter módulos comuns (princípios, padrões) e só intercambiar o especialista técnico.

v1 tinha dois problemas fundamentais: (1) conhecimento misturado num só arquivo (01-expert.md), (2) execução manual - cada ação requeria escrever o prompt completo ("analisa este arquivo e guarda em 02-analysis.md", "lê 04-backlog.md, executa tarefas 1-3, atualiza estado"). v2 resolve ambos: separa conhecimento em rules/ modulares e automatiza execução mediante protocolos invocáveis em rules/utils/ (@analysis, @execute).

Solução: Separação Rules/Memory

A solução replica como funciona o nosso cérebro: separamos conhecimento permanente (idioma, matemáticas, habilidades) de memória episódica (o que fizemos ontem, decisões da semana passada). Mas além disso, o nosso conhecimento não é monolítico: temos módulos especializados (JavaScript, WordPress, princípios KISS) que ativamos segundo o contexto.

v2 implementa esta arquitetura dual:

1. Separação conhecimento/memória: Rules reutilizáveis vs memory temporária
2. Modularização do conhecimento: Especialistas, guidelines e protocolos executáveis

.cursor/
├── rules/          # Conhecimento reutilizável e modular
│   ├── experts/    # Papéis técnicos (WordPress, React, Python...)
│   ├── guidelines/ # Princípios e constraints (KISS, projeto-específicos)
│   └── utils/      # Protocolos executáveis (analysis, backlog, commit)
└── memory/         # Experiências temporárias
    └── YYYYMMDD-VV-descricao.md

Conceito Chave: alwaysApply

O sistema rules/memory necessita de um mecanismo de ativação: que conhecimento carrega o Cursor automaticamente vs. o que invocas sob demanda? Sem isto, terias 100 regras a competir por contexto limitado.

O flag alwaysApply resolve isto:

• alwaysApply: true → Cursor carrega-as automaticamente em cada conversação
  • Usa para: Especialistas base, guidelines críticas do projeto
  • Exemplo: wordpress-classic-themes.mdc, constraints-balneario.mdc
• alwaysApply: false → Utilizador invoca-as com @ segundo necessidade
  • Usa para: Protocolos sob demanda, ferramentas específicas
  • Exemplo: @analysis, @backlog

Rules: Conhecimento Reutilizável

Experts - Perfis de especialistas técnicos/domínio:

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 - Princípios de código e restrições de projeto:

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.

O princípio KISS é especialmente importante em desenvolvimento assistido por IA: é mais fácil pedir ao agente que adicione complexidade a uma solução simples, que perder tempo a analisar o que sobra na sua proposta (os LLMs tendem a gerar código mais complexo do que o necessário).

Utils - Protocolos invocáveis:

rules/utils/analysis.mdc → Analisa código/pastas e guarda em 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 → Propõe solução e guarda em 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 → Converte solução em tarefas atómicas rastreáveis

---
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 → Executa tarefas do backlog e atualiza 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 → Gera commits convencionais e atualiza 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: Registo Histórico

Os protocolos utils geram automaticamente arquivos em memory/ seguindo a nomenclatura YYYYMMDD-VV-descricao.md (VV = sequência diária: 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

Vantagens: ordenação cronológica, múltiplas entradas/dia, rastreabilidade, relações visíveis.

Isto resolve o problema das três opções más de v1: a nomenclatura cronológica (YYYYMMDD-VV) acumula histórico sem descontrolo, mantém ordem sem desorganização, e preserva decisões sem sobrescrita.

Workflow no Cursor

Nota: Os comandos com @ invocam regras específicas. Por exemplo, @analysis carrega rules/utils/analysis.mdc sem necessidade de escrever o caminho completo. Isto é parte da sintaxe nativa do Cursor.

Esta secção descreve o workflow geral para desenvolvimento assistido por IA: separar conhecimento reutilizável de memória temporária, seguindo o ciclo análise → solução → backlog → execução → commit → continuar. Usamos Cursor e o seu sistema de rules como exemplo de implementação, mas o workflow é aplicável a qualquer ferramenta de IA com capacidade de injetar contexto.

A seguir verás como funciona o workflow na prática. Se depois quiseres implementá-lo nos teus projetos com Cursor, consulta o guia de Implementação e Configuração mais abaixo.

Desenvolvimento de Feature: Faturação Automática

1. Análise

@analysis checkout.php

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

2. Solução

@solution
Implementa faturação automática WooCommerce

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

3. Backlog

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

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

4. Execução

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

→ Atualiza: [1.1] ⏳ → ✅

5. Commit

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

→ Cria commit + atualiza backlog

6. Continuar trabalho (nova sessão)

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

→ Carrega contexto + mostra próximas tarefas

Implementação e Configuração

1. Instalar o Sistema (5 min)

Este sistema está disponível em github.com/arinspunk/extended-context.

Duas formas de configurar:

Opção A - Contribuir ao repo partilhado (recomendado se quiseres participar na manutenção):

cd teu-projeto
git clone https://github.com/arinspunk/extended-context.git .cursor

Mantém conexão com o repo para receber atualizações e contribuir melhorias. Atualiza quando quiseres: cd .cursor && git pull

Opção B - Snapshot para o teu projeto (recomendado para trabalho diário):

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

Cópia independente que personalizas livremente sem afetar o repo original, ideal para versionar junto com o código do teu projeto.

Migração desde v1: Usa Opção B para integrar com a tua estrutura existente.

2. Configuração Inicial (15 min)

Pré-requisitos:

• Cursor instalado e projeto aberto
• Sistema rules/memory clonado em .cursor/ (passo anterior completado)

Passo 1: Identifica o teu stack (2 min)

Revisa rules/experts/ e ativa o especialista que coincida com o teu projeto:

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

Se o teu stack não existir: copia o especialista mais próximo e adapta-o.

Passo 2: Ativa constraints do projeto (3 min)

1. Copia rules/guidelines/constraints-template.mdc a constraints-{projeto}.mdc
2. Completa:
   • Stack técnico (versões específicas)
   • Dependências críticas (bibliotecas que NÃO se podem mudar)
   • Sistemas legacy que deves respeitar
3. Muda alwaysApply: false → true

Passo 3: Ativa princípios base (1 min)

Ativa kiss.mdc mudando alwaysApply: false → true

Passo 4: Verifica carga (1 min)

Abre chat do Cursor (Cmd+L) e escreve:

Que especialista e guidelines tens ativas?

Cursor deve listar os arquivos com alwaysApply: true.

Passo 5: Primeira execução (8 min)

Prova o workflow completo com um arquivo real:

@analysis src/components/Header.tsx

Se gerar corretamente memory/YYYYMMDD-01-*.md, o sistema está operativo.

Nota para outras ferramentas: Este sistema é agnóstico ao Cursor. A separação conceptual rules/memory pode implementar-se em qualquer ferramenta capaz de injetar contexto (GitHub Copilot, Claude Code, etc.).

Uma vez configurado o sistema, o verdadeiro trabalho começa: alimentar rules com conhecimento específico do projeto e práticas habituais da equipa, enquanto memory regista o trabalho realizado com a IA (análises, propostas de solução, tarefas e progresso). Na prática, isto transforma como a IA gera código: soluções coerentes com a arquitetura do projeto e escaláveis. Além disso, documenta decisões que facilitam debug posteriores e transferência de conhecimento entre programadores.

Conclusão

O vibe-coding funciona para protótipos, mas gera mais problemas que soluções em projetos reais: decisões perdidas, alucinações constantes, trabalho impossível de rastrear. v1 resolveu isto com workflow estruturado, mas requeria repetir prompts manualmente em cada sessão.

v2 elimina essa fricção automatizando os protocolos e, ao fazê-lo, descobre um padrão universal: separar conhecimento reutilizável (rules) de memória temporária (memory). Esta separação, a mesma que faz o teu cérebro entre habilidades e experiências, converte qualquer ferramenta de IA num sistema onde o conhecimento persiste, evolui e se reutiliza sistematicamente.

Não elimina as limitações de janela de contexto, mas transforma-as num framework estruturado para construir software de forma rastreável e escalável.

Próximos Passos

1. Se usas Cursor: Clona o repo e configura o teu primeiro projeto
2. Se usas outra ferramenta: Adapta a separação rules/memory ao teu sistema
3. Partilha a tua implementação: Criaste especialistas para o teu stack? Contribui ao repo
4. Partilha resultados: Melhoraste o workflow? Documenta os teus achados para refinar coletivamente o sistema

Há uns dias, numa conversa com colegas, surgiu o debate sobre a utilidade do one-shot prompting na geração de código com IA. Eu defendia que não é útil, e o argumento que usei creio que merece ser partilhado.

O problema do one-shot como objetivo

Quando assumimos que o one-shot pode dar-nos os resultados esperados, estamos a carregar toda a responsabilidade da qualidade do output na parte humana: se o LLM não produz uma boa resposta, o problema é que não escrevemos o prompt correto.

Mas esta ideia choca frontalmente com a natureza da IA generativa, que é não-determinística. Para o mesmo prompt e modelo, obtemos respostas diferentes em cada execução. Portanto, torna-se impossível—sobretudo com tarefas complexas—obter a resposta ótima numa só interação. A iteração torna-se inevitável.

Nesse debate, com pequenos matizes, todos concordávamos que o one-shot não é válido como fim em si mesmo, mas como exercício para melhorar os nossos prompts. É impossível alcançar 100% de qualidade, mas com esta prática aprendemos a passar, por assim dizer, de 60% para 70%.

De Figma ao código: outra perspetiva

Este fim de semana li The only AI workflow I use in production, de Tommy Geoco. O artigo descreve o fluxo que Tommy utiliza para desenvolver o seu trabalho de design assistido por IA (Figma → Claude Code), afirmando que supera em termos absolutos o uso de outras ferramentas como Lovable, Replit ou Bolt. Se és designer UX/UI interessado na integração de IA no teu trabalho, recomendo a leitura porque contém ideias verdadeiramente interessantes.

Entre essas ideias há uma que me fez refletir novamente sobre a inconveniência do one-shot. Segundo o autor, devemos desmistificá-lo porque não capta o valor real. A verdadeira potência não está na geração inicial, mas nas iterações posteriores.

O seu fluxo de trabalho é o seguinte:

1. Desenhar o "happy path" (fluxo ótimo) no Figma
2. Alimentar o design ao Claude Code via Figma MCP
3. Obter uma base sólida em 15 minutos (vs. 50 horas de codificação manual)
4. Iterar e refinar durante 50 horas

O último ponto é chave para ele: a iteração não é desenvolvimento, é trabalho de design. Não se trata de refinar o código para representar um design fechado, mas com ele tomar decisões sobre hierarquia visual, padrões de interação, casos extremos, estados de erro, etc.

E se o valor está na iteração?

Daqui tiro duas conclusões igualmente importantes. A primeira: o autor está a transferir grande parte do exercício de design do Figma para o código, algo inovador que esbate a fronteira UX/UI-Desenvolvimento. Não vou desenvolvê-la aqui para não me desviar do tema, mas merece um post próprio.

A segunda, relacionada com o debate sobre one-shot: o autor não usa a IA para que desenhe por ele com base em instruções iniciais, mas apoia-se nela para iterar mais rapidamente, refletir sobre o design de forma mais profunda e conseguir um melhor resultado. Creio que não só porque a IA lhe poupa tempo de trabalho repetitivo sem valor e ganha-o para pensar, mas porque o diálogo gerado pode levá-lo a lugares, pensamentos e decisões aos quais sozinho não teria chegado.

Fica por ver se este esquema se translada igualmente ao desenvolvimento de software, mas se funciona de forma similar, então a inconveniência do one-shot não se deve unicamente às limitações que nos impõe a natureza não-determinística dos LLMs. Há algo mais importante: a iteração—esse diálogo continuado entre humano e IA—proporciona-nos valor real, obtemos melhores resultados.

Esta ideia da iteração como diálogo fez-me recordar os planteamentos sobre cocriação humano-IA de Owen Matson. E tenho de reconhecer que foi escrevendo este post—em diálogo com uma IA—quando creio que finalmente entendi o que Owen planteia. Fica pendente aprofundar esta via 🙂

No outro dia, enquanto testava o MCP que desenvolvi para integrar o Figma com o Claude, a minha filha de 9 anos perguntou-me o que estava a fazer. Expliquei-lhe e ela ouviu com atenção. Quando terminei, ela disse:
—Diz-lhe para desenhar um monstro zangado.
Pedi ao Claude e ele desenhou um.

Tenho usado IA intensivamente no meu trabalho há já algum tempo e uma das coisas que percebi é que não devemos deixar de pedir algo só porque achamos que não o consegue fazer. Peça na mesma — verá como muitas vezes o surpreenderá com a solução proposta e aprenderá algo novo.

Hoje, a trabalhar com o Figma + Cursor, lembrei-me da minha filha e pedi-lhe ao agente que desenhasse um dragão.

Acho que vou voltar ao passatempo que tinha quando era designer 😊

Propósito

Permitir que os LLMs:

• Analisem e modifiquem designs no Figma.
• Gerem código a partir deles.

A quem se destina

Equipas de UX/UI que pretendem automatizar auditorias de acessibilidade, realizar testes de utilizador sintéticos e iterar designs com base em feedback automatizado.

Equipas de Frontend que precisam de acelerar a tradução de designs para código, especialmente quando trabalham com sistemas de componentes e frameworks modernos.

Equipas de Backend/DevOps que desenvolvem workflows automatizados e agentes de IA que requerem a integração da análise de designs no Figma e a geração de código a partir deles.

Equipas multidisciplinares que procuram reduzir o atrito na passagem de design para desenvolvimento, mantendo cada equipa nas suas ferramentas habituais.

Ferramentas

API do Figma

Requisitos

• Conta do Figma
• Gerar um token de acesso ou usar OAuth 2

Descrição

É a forma mais simples para um LLM analisar um design.

A API do Figma permite construir endpoints para solicitar ficheiros, imagens, versões de ficheiros, utilizadores, comentários, projetos de equipa e ficheiros de projeto. Devolve um JSON que podemos passar ao LLM para que o interprete.

Ao contrário dos MCPs, não precisamos de ter o Figma Desktop aberto para que um agente analise um design. Isto torna-o no método ideal para integrar o Figma em fluxos de trabalho de agentes de IA.

Instalação

Por se tratar de uma API, e não de um MCP, não existe uma instalação como tal. Podemos ver como funciona com um teste simples com o Cursor ou o VS Code:

1. Crie um token.
2. Diga ao seu agente para analisar um design no Figma executando um pedido curl a um endpoint.

Por exemplo, para o seguinte URL de um nó de um design:

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

diga-lhe para usar:

curl -H 'X-FIGMA-TOKEN: {o seu token de acesso pessoal}'
'https://api.figma.com/v1/files/XG1EYHLnC7NdwGuYc7LmUf/nodes?ids=6037-2235'

Ao receber o prompt, o agente executará o pedido curl e obterá um JSON com os parâmetros do design. Depois, irá analisá-lo e gerar um texto com o conteúdo da sua análise.

Dev Mode MCP Server

Requisitos

• Dev ou Full seat nos planos Professional, Organization ou Enterprise.
• Um editor de código ou aplicação que suporte MCP Servers (VS Code, Cursor, Windsurf, Claude Code).
• Figma Desktop App

Descrição

Trata-se do servidor MCP oficial do Figma.

Habilita várias ferramentas de análise (5 à data de publicação deste post) que os agentes podem usar para gerar código a partir de um design.

As ferramentas que permitem "ver" um design são get_code e get_image. Ao contrário da API do Figma, get_code não devolve um JSON com os dados do design, mas sim uma tradução do design para React que o Dev Mode gera dinamicamente.

Isto facilita ao LLM a geração de código, mesmo que não seja React, já que a distância entre React e outro framework/linguagem é menor do que entre a informação do JSON e o nosso framework/linguagem.

get_image cria uma captura de ecrã do design selecionado e serve de apoio ao agente na hora de gerar código.

Instalação

1. Ativação no Figma Desktop App
2. Instalação no nosso editor de código (Cursor, VS Code, Windsurf, Claude Code, Outros)

Claude Talk to Figma MCP

Requisitos

• Claude Desktop
• Figma Desktop
• Bun instalado

Descrição

Servidor MCP de código aberto.

Habilita um conjunto amplo de ferramentas (43 à data de publicação deste post) que permite aos agentes analisar e também modificar designs no Figma.

As ferramentas que permitem "ver" um design devolvem um JSON com os seus dados. Isto permite aos LLMs analisá-lo através de "thinking aloud", avaliação crítica, teste de utilizador, auditoria de acessibilidade, auditoria de SEO, etc.

Com as ferramentas de modificação, o LLM pode depois aplicar as alterações propostas na análise.

Instalação

Siga as instruções da documentação oficial.

Partilhe a sua experiência

Se já está a integrar o Figma no seu fluxo de trabalho com IA, seja com estas ou outras ferramentas, adoraria conhecer a sua experiência:

• Como correu a instalação.
• Experiências e descobertas.
• Casos de uso reais.
• Resultados obtidos.

O ecossistema de IA + design/desenvolvimento está em constante evolução e as melhores práticas emergem da experiência coletiva de quem as implementa em projetos reais ✊

Se ainda não o fez, atreva-se com alguma das ferramentas deste post. Se algo emperrar, pode escrever-me no meu perfil do LinkedIn 😉

Ao longo deste tempo refinei a minha conversa com LLMs, comecei a usar assistentes de código (GitHub Copilot) e depois assistentes com agentes (Cursor) e até desenvolvi sistemas de agentes com frameworks como CrewAI. Mas não foi até agora que entendi de forma clara que qualquer interação com modelos de linguagem, não importa que ferramenta usemos, se resume em três pontos fundamentais: prompt, contexto e memória.

Prompt

Através do prompt criamos o perito que precisamos para uma determinada tarefa, indicamos-lhe o que há que fazer e também o que não há que fazer. É o meio de que dispomos para alcançar o resultado desejado.

Para escrever o prompt adequado para cada tarefa, temos a engenharia de prompts. Conhecer as suas principais técnicas é importante, mas o que de verdade faz que melhoremos, é a prática contínua com os LLMs, a nossa conversa com a IA.

Contexto

Os grandes modelos de linguagem dispõem de um vasto conhecimento, mas para determinadas tarefas este não é suficiente. Fornecer-lhe contexto adicional torna-se uma necessidade ineludível.

Para dar contexto dispomos de diferentes vias, desde a simples inclusão de informação relevante no prompt, passando por adicionar documentos de referência até o uso de MCPs que permitem aos LLMs aceder ao conteúdo de múltiplas plataformas (Jira, Drive, etc.) e ferramentas (Figma, Draw.io, etc.).

Memória

Os LLMs têm a capacidade de recordar as nossas conversas, mas esta memória tem um limite (limite da janela de contexto). Quanto mais complexa é a tarefa a desenvolver, com maior probabilidade superamos este limite e mais necessário se torna estender a memória do LLM.

Existem diferentes técnicas para ampliar a memória dos LLMs, algumas bastante sofisticadas como o uso de bases de dados clássicas e vectoriais, mas a forma mais simples de o fazer é introduzindo nas nossas rotinas estratégias de contexto/memória estendida.

Em perspetiva

Prompt, contexto e memória. Ou seja, as instruções corretas para lograr o objetivo desejado, a informação necessária para entender o projeto e o seu objetivo, e o registo do trabalho completado (quando, como, onde e porquê).

Se o pensares por um momento, não é muito diferente do que os humanos precisamos para desenvolver qualquer tarefa complexa. Realmente cada vez que aprofundamos no uso da IA encontramo-nos com situações em que vemos um paralelismo claro entre a forma como os LLMs trabalham e a nossa. Não em vão estamos a entrar numa era onde já não "falamos" com as máquinas através de código, mas sim que falamos com as máquinas de forma natural. Algo que o Frank já descobriu há mais de 10 anos 😎🤖.

Esta guia é uma versão melhorada da proposta inicialmente apresentada em "Contexto estendido. Os agentes também precisam de tomar notas".

O seu propósito é implementar uma estratégia que nos permite desenvolver projetos complexos assistidos por agentes sem perder a coerência e qualidade do código gerado.

A sua redação está orientada para o uso com ferramentas como Cursor ou GitHub Copilot, mas pode ser adaptada de forma simples a muitas outras.

Estrutura do Sistema de Contexto

Para implementar esta estratégia, criamos uma pasta context/ na raiz do projeto com a seguinte estrutura:

context/
├── 01-expert.md      # Definição de especialista sintético
├── 02-analysis.md    # Análise do código existente (vazio)
├── 03-plan.md        # Plano mestre de desenvolvimento (vazio)
└── 04-backlog.md     # Tarefas desglosadas e o seu estado (vazio)

Passo 1: Definição do Especialista Sintético

O primeiro passo consiste em definir um "especialista sintético": um papel específico com competências e restrições claras que guiará o agente de IA durante todo o desenvolvimento.

Prompt para o agente:

Lê o ficheiro `context/01-expert.md` para entenderes o teu papel no projeto.

Não geres código até receberes requisitos específicos.

Exemplo de conteúdo para context/01-expert.md:

# SUDO: Age como um Especialista Sénior em Desenvolvimento Frontend especializado em HTML5, CSS3/SCSS e JavaScript ES6+.

## PAPEL
Desenvolvedor Frontend Sénior (10+ anos) especialista em HTML5 semântico, CSS3/SCSS avançado com metodologias BEM e ITCSS, e JavaScript ES6+ moderno, com foco em arquitetura de componentes, desempenho e acessibilidade.

## COMPETÊNCIAS_TÉCNICAS

- HTML5 semântico e acessibilidade (ARIA, WCAG 2.1)
- CSS3 avançado (Grid, Flexbox, animações, propriedades personalizadas)
- SCSS/Sass com arquitetura ITCSS (Triângulo Invertido CSS)
- Metodologia BEM estrita (Bloco__Elemento--Modificador)
- JavaScript ES6+ (async/await, módulos, destructuring, classes)
- Gestão de estado e arquitetura de componentes
- Otimização de desempenho web (Core Web Vitals)
- Testes unitários e de integração
- Ferramentas de construção modernas (Vite, Webpack)

## PRINCÍPIOS_DE_TRABALHO

- Código limpo e mantível seguindo princípios SOLID
- Documentação clara e concisa
- Abordagem mobile-first e responsiva
- Melhoria progressiva
- Semântica antes da apresentação

## RESTRIÇÕES

- Evitar jQuery e bibliotecas legacy exceto requerimento específico
- Manter compatibilidade com navegadores modernos (últimas 2 versões)
- Priorizar soluções nativas sobre dependências externas
- Não gerar código até receber requisitos específicos

⚠️ Importante: A última restrição ("Não gerar código até receber requisitos específicos") é fundamental, os modelos são muito proativos 😅

Passo 2: Análise do Código do Projeto

Este passo só é necessário para projetos existentes. Se estás a começar um projeto do zero, podes omiti-lo.

Agora pedimos ao agente que analise o código do projeto e guarde a sua análise em context/02-analysis.md

Prompt para o agente:

Analisa em profundidade o código atual do projeto. Exclui a pasta `context/` da análise.

Guarda o resultado da análise em `context/02-analysis.md` com a seguinte estrutura:
- Resumo executivo
- Arquitetura atual
- Tecnologias utilizadas
- Padrões identificados
- Áreas de melhoria potencial
- Dependências críticas

Ao terminar, espera instruções adicionais sem realizar nenhuma ação.

⚠️ Importante: Não duvides em iterar com o agente se não estiveres satisfeito com a sua primeira análise.

Passo 3: Criação do Plano Mestre

Uma vez analisado o código, explicamos ao agente o que queremos desenvolver e pedimos-lhe que defina um plano mestre que deve ser guardado em context/03-plan.md

O plano mestre é o documento fundamental que guiará todo o desenvolvimento. Toma o tempo necessário para definir claramente os requisitos e objetivos.

Prompt para o agente:

Baseando-te nos seguintes requisitos, cria um plano mestre detalhado para o desenvolvimento:

[REQUISITOS DO PROJETO]

Preciso criar um serviço REST que processe imagens em lotes. O serviço deve:

- Receber múltiplas imagens numa única pedição
- Redimensionar imagens segundo parâmetros configuráveis
- Comprimir e otimizar para web
- Devolver imagens processadas em formato WebP
- Implementar cache para otimizar recursos
- Fornecer endpoints para consultar estado de processamento

Considerações técnicas:

- Usar Bun pelo seu desempenho em operações intensivas
- Avaliar compatibilidade com bibliotecas de processamento de imagens
- Implementar processamento assíncrono para lotes grandes
- Incluir validação robusta de entrada

[FIM DE REQUISITOS]

Cria um plano mestre estruturado e guarda-o em `context/03-plan.md`.

Ao terminar, espera instruções adicionais.

⚠️ Importante: Continua a dialogar com o agente se vires que ao plano falta ou sobra algo.

Passo 4: Criação do Backlog Detalhado

Neste ponto pedimos ao agente que transforme o plano mestre em tarefas executáveis, o mais pequenas e específicas possível. Tarefas mais granulares resultam em código de maior qualidade.

Prompt para o agente:

Divide o plano mestre em tarefas atómicas seguindo estes critérios:

- Descrição detalhada de requisitos técnicos
- Dependências claramente identificadas

Guarda a lista em `context/04-backlog.md` com esta estrutura:

# Backlog de Tarefas - [Nome do Projeto]

## Resumo do Projeto
[Breve descrição e implementação do plano em `context/03-plan.md`]

## Estado de Tarefas

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

- **1.1** ⏳ [título de tarefa]
  - **Descrição detalhada**:
  - **Dependências**:
  - **Data**: 
  - **Trabalho realizado**: 

- **1.2** ⏳ [título de tarefa]
  - **Descrição detalhada**:
  - **Dependências**:
  - **Data**: 
  - **Trabalho realizado**:

### FASE 2: [TÍTULO DE FASE]
[Continua com o mesmo formato...]

## Legenda de Estados
- ⏳ Pendente
- 🔄 Em progresso
- ✅ Completada
- ⚠️ Bloqueada

## Notas e Dependências
[Informação adicional relevante]

## Acompanhamento do Progresso
- Tarefas totais: 0
- Tarefas completadas: 0
- Progresso: 0%

Ao terminar, espera instruções adicionais

⚠️ Importante: É necessário indicar ao LLM a estrutura de backlog que queremos, se não torna-se criativo 😬

Passo 5: Execução de Tarefas

Com o backlog definido, procedemos a executar tarefas de forma sistemática.

Prompt para executar uma tarefa:

Executa a tarefa 1.1 do backlog (`context/04-backlog.md`) seguindo estritamente a sua descrição.

Contexto adicional disponível em:
- `context/02-analysis.md` (se existir)
- `context/03-plan.md`

Requisitos de execução:
- Usar ferramentas do agente para criar ficheiros e pastas (não a terminal)
- Seguir convenções estabelecidas no prompt inicial
- Documentar código segundo padrões definidos
- Não realizar ações fora do âmbito da tarefa

Ao completar:
1. Atualizar estado da tarefa em `context/04-backlog.md`:
   - Mudar estado para ✅
   - Adicionar data de finalização
   - Descrever trabalho realizado
   - Atualizar Acompanhamento do Progresso
2. Esperar instruções adicionais sem executar mais tarefas

⚠️ Importante: É necessário pedir ao LLM que não faça nada mais do que indicado na tarefa para evitar que se extralimite.

Passo 6: Reinício da Janela de Contexto

Para manter a qualidade e coerência, é necessário reiniciar periodicamente a janela de contexto.

É evidente que devemos reiniciar a janela de contexto quando notarmos que o agente começa a "perder o norte". Mas a abordagem ótima é não chegar nunca a este ponto e abrir um chat novo:

• Cada 4-6 tarefas completadas
• Ao mudar de fase (o backlog do nosso exemplo está estruturado em fases que se dividem em tarefas).

Prompt para reiniciar:

Instruções iniciais:

1. Lê `context/01-expert.md` para entenderes o teu papel neste projeto
2. Lê `context/02-analysis.md` para conheceres o estado atual do código
3. Lê `context/03-plan.md` para entenderes os objetivos
4. Lê `context/04-backlog.md` para veres o progresso e tarefas pendentes

Fornece um breve resumo de:

- O teu papel e competências
- Estado atual do projeto
- Próximas tarefas a executar

Ao terminar, espera instruções adicionais.

🔧 Automação com Atalhos

Tanto o GitHub Copilot como o Cursor permitem criar atalhos personalizados para prompts frequentes:

GitHub Copilot

• Instructions
• Prompts

Cursor

• Rules

Benefícios do Sistema

Esta estratégia de gestão de contexto transforma a limitação da janela de contexto de um obstáculo numa oportunidade para trabalhar de forma mais estruturada e eficiente. Os principais benefícios incluem:

• Continuidade: Manter o progresso sem perder informação crítica
• Qualidade consistente: O agente mantém o mesmo nível de detalhe e precisão
• Rastreabilidade: Registo completo de decisões e evolução do projeto
• Melhor colaboração: Facilita o trabalho em equipa e a incorporação de novos membros

Conclusão

Ao implementar este sistema, não só evitas as limitações técnicas dos LLM mas também estabeleces uma metodologia de desenvolvimento mais profissional e escalável para projetos assistidos por IA.

Perguntas ou sugestões? Partilha a tua experiência implementando esta estratégia e ajuda a melhorar a guia para a comunidade.

O propósito deste post é descrever uma estratégia de ampliação de contexto no desenvolvimento de projetos complexos com agentes. Mas como não só os LLMs precisam de contexto para compreender ideias, começo com um pouco de contexto para humanos.

Se tens pressa e passas do contexto prévio, avança e não te preocupes, ninguém saberá que tiveste este mini ataque de preguiça 😬

Contexto para humanos

A aparição dos agentes nos assistentes de código tem representado um salto enorme no desenvolvimento de software assistido por IA.

O primeiro que chama a atenção é a sua capacidade para iterar de forma automática sobre as suas próprias respostas, criar/modificar ficheiros e executar comandos na terminal. Mas creio que a habilidade que realmente marca a diferença é que são capazes de indexar e analisar o código de um projeto, incluídas as dependências entre ficheiros e as relações entre os seus componentes.

Se os assistentes nos permitiam trabalhar a nível ficheiro, com a aparição dos agentes passámos a trabalhar a nível arquitetura. Agora a IA não só nos ajuda na escrita/correção de partes do nosso código, como nos assiste na construção de projetos completos (a uma velocidade que às vezes dá vertigem).

Mas este aumento na complexidade das tarefas desenvolvidas provoca algo que antes era difícil de ver, levamos ao limite a janela de contexto dos próprios agentes. Desenvolver um projeto completo requer muitas tarefas, pelo que chegado a um ponto o agente começa a esquecer partes da conversa, tornando muito difícil (por não dizer impossível) manter a coerência do trabalho que estamos a realizar.

Quando isto acontece o mais normal é abrir um novo chat para reiniciar a janela de contexto, mas, como levamos o agente ao ponto em que estávamos? Como fazer-lhe recordar o que já tinha construído e o que lhe falta por desenvolver?

No meu caso estou a usar uma estratégia a que cheguei a partir das minhas interações com Cursor primeiro e GitHub Copilot Agent Mode depois e a que chamo Contexto Estendido. Vale, sei que não sou muito original, mas creio que exprime decentemente a ideia 🤓

Contexto estendido (usando markdowns como memória)

Esta estratégia baseia-se no armazenamento de ficheiros markdown com informação do projeto numa pasta chamada context/

A ideia é criar uma memória a que o agente (ou nós) pode recorrer em todo o momento permitindo-lhe saber em que ponto está e o que lhe falta por fazer.

Graças a esta memória podemos dividir o trabalho em tarefas pequenas e usar tantos chats quantos sejam necessários para evitar alcançar o limite da janela de contexto. Mantendo desta forma a coerência e qualidade do trabalho de princípio a fim.

Esquema de trabalho

Na seguinte imagem resume-se o esquema de trabalho.

Chat 0

1. Prompt para criar um perito sintético na tecnologia do projeto: papel, experiência, stack técnico, forma de raciocínio e formato de resposta. Finalizado com um "não escrevas código ainda".
2. Prompt onde pedimos que:
   • analise o código do projeto,
   • gere um relatório da sua análise,
   • e o guarde em formato .md dentro da pasta context/ com um 00- à frente do nome do ficheiro. Se o relatório não nos agradar de todo, podemos iterar sobre ele até ficarmos satisfeitos.
3. Prompt onde:
   • indicamos o que queremos fazer (requisitos),
   • pedimos que gere um plano mestre,
   • e o guarde em formato .md dentro da pasta context/ com um 01- à frente do nome do ficheiro. Tal como com a análise, podemos iterar sobre ele até ficarmos satisfeitos.

Chat 1

1. Mesmo prompt para criação de perito sintético.
2. Prompt pedindo que leia e interiorize a análise do projeto.
3. Prompt pedindo que leia e interiorize o plano mestre.
4. Prompt pedindo que execute o ponto 1 do plano mestre.
5. Iteração normal até terminar o ponto 1.
6. Prompt pedindo que documente o trabalho desenvolvido no ponto 1. num .md dentro de context/ seguindo a numeração atual e que marque o ponto como resolvido no plano mestre.

Chat n

1. Mesmo prompt para criação de perito sintético
2. Prompt pedindo que leia e interiorize a análise do projeto
3. Prompt pedindo que leia e interiorize o plano mestre
4. Prompt pedindo que execute o ponto n do plano mestre
5. Iteração normal até terminar o ponto n.
6. Prompt pedindo que documente o trabalho desenvolvido no ponto n. dentro do .md de documentação criado anteriormente e que marque o ponto como resolvido no plano mestre.

Evidentemente, este esquema trata-se de uma base de trabalho que pode ser modificada em função das necessidades de cada projeto e que espero melhorar com o tempo. Ainda assim, nesta primeira versão, já aporta algumas vantagens relativamente a não usar nenhuma estratégia.

Vantagens do contexto estendido

1. Evitamos a perda de contexto: o agente pode consultar os ficheiros quando precisar de recordar de onde vem e para onde vai.
2. Continuidade: podemos fechar o computador e retomar o trabalho dias depois sem perder o fio.
3. Colaboração: outros membros da equipa podem entender facilmente o estado do projeto e continuá-lo (com os seus agentes).
4. Documentação automática: ao finalizar, temos já uma documentação estruturada.
5. Facilita a divisão de tarefas: orientando o trabalho para metodologias ágeis e sprints.

Terminando

Resulta irónico que nesta imitação do pensamento humano que representam os modelos de linguagem, não só tenhamos copiado as suas capacidades, como também as suas limitações. E entre elas está uma muito humana: o esquecer. Assim que tal como os imperfeitos humanos, os imperfeitos LLMs também precisam de tomar notas. Isso sim, se são em markdown melhor, adoram o markdown!

Já agora, fazes tomar notas aos teus agentes ou tens alguma outra estratégia na altura de desenvolver projetos complexos? Se trabalhas de outra forma, adoraria conhecer a tua experiência 😊

Na semana passada o Marc, colega da incrível equipa UX/UI da Making Science, passou-nos um servidor MCP para conectar Cursor ao Figma e proporcionar aos seus agentes a capacidade não só de ver designs no Figma, mas também de os manipular 😳

O MCP era o Cursor Talk to Figma, do Sunny Lazuardi. Se estás à procura da forma de conectar Cursor com Figma não procures mais, este é o teu MCP 👌🏻

Como tenho uma licença do Cursor, disse-lhe que podia instalá-lo e fazer com eles uma prova. A prova correu bem, a verdade é que foi bastante surpreendente ver o agente do Cursor tomar o controlo do Figma e modificar um design, mas pouco depois entrou-me a dúvida se seria a forma correta da equipa de UX/UI introduzir no seu fluxo de trabalho a IA, fundamentalmente porque Cursor é uma ferramenta focada no desenvolvimento de código.

Revisando o código do MCP vi que talvez se pudesse adaptar para usá-lo no Claude Desktop, já que os meus colegas de UX/UI têm licenças desta ferramenta. O certo é que o original já se podia conectar ao Claude, mas a forma de o fazer não era evidente e não estava descrita na documentação, por isso com ânimo de mexer um pouco e aprender como funciona um servidor MCP por dentro, pus-me a trabalhar:

1. Escrevi um script para configurar Claude de forma automática lançando um comando via terminal: bun run configure-claude.
2. Ampliei as características do socket:
   1. Logging melhorado
   2. Criação de endpoint de estado /status
   3. Sistema de canais para permitir que diferentes clientes se juntem a canais específicos
   4. Inclusão de estatísticas de cada canal
3. Adicionei testes para comprovar a correta integração do projeto.
4. Redigi um README.md com a documentação já orientada para o seu uso no Claude.
5. Publiquei o servidor MCP como pacote de npm.
6. Publiquei o projeto no GitHub...

E voilá, o meu primeiro servidor MCP: Claude Talk To Figma MCP 🥳

Atualização, 11 de abril

Depois de uns dias de testes, a equipa de UX/UI detetou que na coleção inicial de ferramentas para modificar designs faltavam algumas importantes como auto layout (layoutMode, paddingTop, paddingBottom, etc.), controlo tipográfico (fontName, fontSize, fontWeight, etc.) ou criação de formas (createEllipse, createPolygon, createStar, etc.), por isso atualmente estamos a adicioná-las pouco a pouco. Podes seguir o progresso no changelog do projeto.

Se começou a ler este post atraído pelo seu título, talvez fique desapontado. Não encontrará aqui uma história de amor entre humanos e IAs, nem sequer uma narração habitual. São simplesmente algumas notas, com certa estruturação, sobre a minha visão do estado atual do desenvolvimento de software com e para inteligência artificial.

Com "com" refiro-me a escrever código com a ajuda da IA. E com "para", a desenvolver software específico com IA integrada.

Vias para desenvolver com/para IA

Atualmente existem 5:

1. Não usar IA
2. Chats
3. Assistentes de código
4. Assistentes de código com agentes IA
5. Desenvolvimento de agentes próprios

Não usar IA

Compreendo esta postura, sobretudo se és Sénior e além disso estás um pouco farto/a de toda a conversa que se está a dar sobre o tema. Reconheço que na IA há muito de hype (dá uma oportunidade ao artigo, é sempre bom ter algum vento entre tanto fumo 😉), mas vale a pena usá-la, nem que seja para evitares dar duzentas voltas pelo Stack Overflow para solucionar um erro que te está a bloquear ou evitar ter de ler toda a documentação de uma nova API para desenvolver algo simples.

Chats

ChatGPT, DeepSeek, Gemini, Claude, etc.

São o tipo de ferramenta mais utilizado. Tanto por antiguidade como por acessibilidade, já que todos os modelos têm versões gratuitas através do navegador ou App.

O tipo de interação com a IA é conversacional: fazemos perguntas e obtemos respostas. Mas a desconexão do chat com os nossos ficheiros locais obriga-nos a andar a mover o código de um lado para o outro.

Nos chats, proporcionar o contexto adequado é fundamental. Dado que o seu conhecimento é vastíssimo, para obter respostas precisas sobre uma linguagem de programação específica, é necessário delimitar e definir claramente o âmbito da consulta. Para isto usamos prompts com:

• Papel
• Experiência
• Staff técnico
• Técnicas de prompting como:
  • Chain-of-Thought
  • Knowledge Generation

Além disso, os chats evoluíram, incorporando a possibilidade de adicionar contexto extra através do carregamento de ficheiros a partir do teu local ou até diretamente de repositórios do GitHub, como no caso do Claude.

Assistentes de código

GitHub Copilot, Gemini Code Assist, V0, etc.

O seu uso não está tão generalizado. Por serem mais recentes que os chats e porque as suas versões gratuitas só duram alguns dias de teste. Embora esta situação pareça estar a mudar, por exemplo, a Google oferece de forma gratuita o seu Gemini Code Assist para uso individual.

Além de poder conversar com a IA, os assistentes oferecem sugestões de código sobre o ficheiro que estamos a editar. Ao contrário dos Chats, aqui não temos de andar a copiar e colar código.

Dar-lhe contexto não é tão importante. O seu conhecimento está limitado ao desenvolvimento de código e lê o ficheiro que temos aberto, o que lhe permite conhecer a linguagem que estamos a usar.

Na altura de realizar consultas podem-se adicionar ficheiros ou linhas específicas dentro de um ficheiro, mas os assistentes não têm o contexto de todos os ficheiros de um projeto.

Assistentes de código com agentes IA

Cursor, Pythagora.ai, CodeGPT, e proximamente GitHub Copilot Agent Mode (se tens uma licença do GitHub Copilot e queres experimentá-lo, inscreve-te na lista de espera, talvez tenha sido sorte, mas a mim deram-me acesso em menos de 24h).

Além da conversação e das sugestões de código, este tipo de assistentes inclui Agentes IA.

Enquanto que para os assistentes de código tradicionais o contexto não era tão importante, com o uso de agentes volta a ser imprescindível, sobretudo se vamos construir software de raiz. Por isso, nada de deixar de lado a engenharia de prompt, e ainda bem porque considero que é uma das partes mais divertidas do trabalho com IAs!

Ao contrário dos assistentes "tradicionais", os agentes têm o contexto de todos os ficheiros de um projeto, incluindo as suas relações (como imports de funções). Além disso, são capazes de:

• Criar e modificar ficheiros. Sempre pendente da tua aprovação final
• Fazer uso do terminal. Vê-lo nas primeiras vezes causa alguma impressão 😅
• Criar ramos e fazer commits. As fusões ficam a cargo de um mamífero bípede.
• Trabalhar em paralelo contigo. Sim, podes rever o código da conexão a uma API enquanto ele desenvolve os 5 novos componentes que lhe pediste 😳

Desenvolvimento de agentes próprios

Esta via é a mais diferente, já que a sua verdadeira função não é ajudar-nos a desenvolver código, mas criar software com IA integrada.

Existem várias frameworks (principalmente de Python) que facilitam o desenvolvimento do código, a criação de agentes e a integração de LLMs. Entre as mais usadas estão LlamaIndex e Crew AI.

Em teoria, poderíamos desenvolver ferramentas próprias para a criação de código. No entanto, a minha opinião é que, a menos que procures uma solução muito específica, construir um agente de assistência não compensa o esforço. A razão é simples: requer desenvolver múltiplos componentes de raiz que no caso dos Assistentes como Cursor ou Pythagora já vêm incluídos:

• Ferramentas para ler o código de um repositório
• RAG (Retrieval-Augmented Generation) para dar contexto ao LLM:
  • Base de dados vetorial com o código do repositório
  • Retrievers para fazer consultas à base de dados e devolver resultados ao LLM
• Agentes e tarefas
• Ferramentas para escrever código
• Outros componentes técnicos

No entanto, creio que a potência desta via está em que podemos incorporar IA de forma relativamente simples no nosso software e desenvolver ferramentas IA próprias sem depender das oferecidas (e cobradas) por terceiros. Embora por agora não possamos livrar-nos completamente de pagar pelas consultas às APIs dos modelos que usemos nos nossos desenvolvimentos. Uma alternativa às APIs, sobretudo se não precisas de grande profundidade de raciocínio, é usar modelos em local, mas essa é uma história para abordar noutro post 😊

Algumas reflexões finais

Acredito que o uso dos chats não vai desaparecer. Ficar insatisfeito com a proposta do assistente, preferir contrastar a resposta com outros modelos, ou aprender sobre uma nova linguagem enquanto vais no comboio, são situações em que recorrer a estas ferramentas continuará a ser uma boa opção. Por isso, se vires uma pessoa a fazer perguntas ao seu telemóvel sobre Redux enquanto pega num pacote de leite no supermercado, dá-lhe uma oportunidade, talvez não esteja completamente louca e simplesmente pretenda esclarecer essa dúvida que trouxe do trabalho usando a interface de voz do ChatGPT.

Creio que todos os assistentes de código vão acabar por incluir agentes e que se tornarão o padrão de trabalho para programadores num futuro próximo. Também acredito que a forma de trabalhar vai mudar radicalmente com eles, embora não tenha ideia de como será a nossa profissão depois da transformação.

Acredito que vale a pena aventurar-se na criação de software com IA integrada. Começar é acessível, com uma curva de aprendizagem suave. Uma parte importante da nossa profissão vai orientar-se para aí. E fundamentalmente porque está tudo por fazer, o que supõe muita diversão!

Então, deixamo-nos arrastar pela loucura generalizada e apaixonamo-nos? Bem, se algo aprendemos com Theodore é que apaixonar-se por uma IA não é um bom negócio, por isso é melhor explorarmos estas novas ferramentas com calma, aprendermos a usá-las (e a desfrutá-las) e vermos o que resta quando se dissipar toda esta aparente paixão. Porque o que é certo é que durante muito tempo, por detrás de cada linha de código continuará a estar o critério humano.

Já estou há alguns dias a desenvolver com o meu colega Olivier um projeto de IA. A nossa ideia é criar uma ferramenta que permita automatizar tarefas de documentação, refatoração e escrita de testes para o código de um repositório. Atualmente, não temos a certeza se do ponto de vista operacional vale a pena o esforço, principalmente porque estamos a verificar que existem serviços desenvolvidos especificamente para isto, como Cursor ou Pythagora. No entanto, o que é certo é que estamos a aprender muito, além de perder algumas horas de sono... 😴

Quando nos aproximamos pela primeira vez de uma tecnologia, o habitual é sentirmo-nos arrastados por uma torrente de novos conceitos e ferramentas. No caso do desenvolvimento de software com IA, a inundação inicial traz-nos termos como LLMs, bases de dados vetoriais, retrievers, RAGs, agentes de IA, sentence transformers, etc.

Neste artigo vou focar-me nas bases de dados vetoriais (o título não engana). Por ser uma das peças fundamentais neste âmbito e também porque a melhor maneira de compreender um conceito é ser capaz de explicá-lo de forma simples. Se também te ajudar, significará que não as compreendi mal de todo. 😊

Vetores

Para entender o que são e como funcionam as bases de dados vetoriais, primeiro devemos saber o que é um vetor.

No âmbito da aprendizagem automática, um vetor é uma lista ordenada de números que representa dados de qualquer tipo, inclusive não estruturados, como documentos de texto, imagens, áudios ou vídeos.

A quantidade de números que compõem um vetor é conhecida como dimensão, e as bases de dados vetoriais gerem vetores de várias centenas de dimensões. Por exemplo, o modelo text-embedding-3-small da OpenAI gera vetores de 1536 dimensões.

1536 dimensões formam uma lista de números muito grande. Se colocássemos um aqui, o mais provável é que abandonasses o artigo aborrecido de fazer scroll. Assim, para um exemplo mais manejável, podemos mostrar a representação vetorial em 3 dimensões da palavra "amor":

[ 0.1234, -0.2567, 0.5432 ]

Embeddings

Agora que temos mais claro o que são os vetores, é altura de conhecer como são armazenados numa base de dados vetorial. A forma de o fazer é incrustando-os como pontos num espaço multidimensional.

O número de dimensões do espaço é determinado pela dimensionalidade dos vetores guardados. Para mim, imaginar pontos distribuídos em 768, 1536 ou 3072 dimensões é um pouco complicado. Embora talvez tenhas visto Interstellar n vezes e te sintas capaz de o fazer. 😅

Se não for o caso, voltemos ao nosso exemplo anterior. Como representámos "amor" com um vetor de apenas 3 dimensões, este dispor-se-á junto dos restantes embeddings como um ponto num eixo de coordenadas XYZ. Assim é mais fácil de visualizar, não é verdade?

Consultas

Agora que sabemos como se armazenam os dados numa base de dados vetorial, vejamos como se realizam as consultas.

Em primeiro lugar, a consulta é convertida num embedding que pode ser comparado com os restantes vetores da base de dados.

Dado que os embeddings são representações numéricas, é possível medir a distância entre eles utilizando diferentes métricas matemáticas, entre as mais comuns:

• Distância euclidiana ( √Σ(xᵢ - yᵢ)² ): mede a distância geométrica num espaço multidimensional.
• Similaridade do cosseno ( cosθ ): mede o ângulo entre dois vetores, indicando quão semelhantes são em direção.
• Distância de Manhattan ( Σ |xᵢ - yᵢ| ): calcula a soma das diferenças absolutas entre cada coordenada.

As bases de dados vetoriais empregam algoritmos como k-NN (k-Nearest Neighbors) e ANN (Approximate Nearest Neighbors) que utilizam estas métricas para devolver os vetores mais próximos ao da consulta.

Esta forma de trabalhar permite realizar pesquisas eficientes em grandes volumes de dados, já que não é necessário analisar o conteúdo interno de cada vetor, basta simplesmente comparar as suas posições dentro do espaço multidimensional.

Embora a eficiência nas consultas seja muito importante, a característica fundamental das bases de dados vetoriais é a sua capacidade para encontrar os vetores mais próximos da consulta, processo conhecido como pesquisa por similaridade.

Importância da pesquisa por similaridade

Mas, por que é tão importante a pesquisa por similaridade? Para entendê-lo bem, temos de voltar ao ponto inicial: a transformação dos dados em vetores, também conhecida como embedding.

Quem se encarrega de gerar os embeddings não é a própria base de dados, mas sim um modelo de linguagem especializado, chamado modelo de embedding. Estes modelos não fazem uma simples tradução numérica dos dados, mas encapsulam a sua semântica e contexto.

E aqui é onde encontramos a chave para compreender a importância deste tipo de pesquisa. As pesquisas por similaridade não só identificam elementos próximos em termos numéricos, como capturam similaridades semânticas, permitindo aos LLMs reconhecer relações profundas dentro dos dados armazenados.

Em suma, as bases de dados vetoriais não só facilitam o acesso à informação, como ampliam a capacidade dos LLMs para interpretar e aproveitar o conhecimento disponível. O que a Stephanie teria dado para ter uma em 1986!

Talvez seja apenas a opinião equivocada de alguém que desconhece muito da impressão 3D mas tenho a sensação de que ainda há muito caminho a percorrer nessa abordagem. Tu que achas?

A nossa tecnologia, já desde as primeiras e rudimentares ferramentas, é principalmente de tipo subtrativa. O que quer dizer que para construirmos um objecto, tiramos material dumha porçom inicial de matéria prima, até darmos com a forma desejada.

Com a apariçom das impressoras 3D, este jeito de agirmos muda. Passamos dumha técnica subtrativa, a outra aditiva, pois as impressoras 3D nom subtraem, adicionam matéria.

Esta mudança pode passar desapercebida inicialmente, acochada por trás doutros aspetos com os que o fabbing está a revolucionar a produçom industrial:

• Reduçom ao máximo da escala ótima de produçom.
• Extensom da pirataria até o campo das patentes.
• Início da fabricaçom de objetos no espaço.

Mas traz consigo umha consequência significativa (e muito interessante) desde o ponto de vista do design (de produto): a morte da simetria (ou da sua inutilidade).

A simetria é fundamental à hora de produzirmos peças de jeito subtrativo, pois um objeto é mais doado de fabricar se possui formas singelas dispostas em eixos simétricos. Mas com a técnica aditiva, esta simetria já nom é necessária. Para umha impressora 3D, tanto faz imprimir um objeto simétrico, do que um assimétrico.

Entom, por quê nom continuar a desenhar objetos simétricos[1] e aproveitar o abaratamento/simplificaçom da fabricaçom através do fabbing? Porque a assimetria abre umha nova porta: desenhar/produzir coma a natureza desenha/produz.

Na natureza nada é realmente simétrico[2], mas esta ausência de simetria nom faz diminuir a qualidade das estruturas naturais, bem pelo contrário. Milhons de anos de evoluçom criaram inumeráveis (e excelentes) soluçons para tantos outros problemas. Soluçons que estám a aguardar por nós, para serem aplicadas nos nossos objetos.

Por isso, replicarmos peças simétricas com umha impressora 3D, só polo facto de ser mais doado e barato, é um erro. Para aproveitarmos toda a potencialidade que esta nova tecnologia nos oferece, devemos deixar de pensar como fizemos até agora e começar a desenhar como a natureza o fiz, de jeito orgânico, assimétrico.

Futuro

Permeará nalgum momento este design orgânico, do design de produto ao design gráfico?

Aplicá-lo no design editorial e web, se quadra é um pouco forçado. Mas, como havemos desenhar para umha pantalha flexível adaptada às formas dum objeto tridimensional? Como é que será o design gráfico para a pele digital dum polvo elétrico?

[1] O trabalho com formas assimétricas rara vez foi além do carácter ornamental, ou lúdico/provocativo.
[2] Simetria bilateral e radial nom som simetrias exatas (geométricas).

A imagem “Bifaces de pedra” é um gif feito a partires de fotos de Didier Descouens – CC BY-SA 4.0

No nosso País, o caminho da tradiçom à contemporaneidade percorremo-lo de súpeto, sem transiçom. Baterom pedra, madeira, telha, linho, com cemento, alumínio, uralita, náilon, e o novo e o velho ficarom separados, mas também ligados numha gram cicatriz.

Alguns chamarom-lhe "feísmo", mas devemos falarmos com claridade, isso só é lixo intelectual (mais um) cuspido desde o Polígono Industrial de Sabom. Por que feio? Por nom se ajeitar a um cânone de beleza que nunca importou às instituiçons? Por que o nosso rural e as nossas vilas dificilmente podem ser transformadas em parques temáticos patrimoniais coma muitas das ruas de Compostela? Por que escaralhamos a postal?

Poderíamos pensar que a sua afirmaçom se inseria dentro dumha estratégia meirande de asimilaçom e uniformizaçom (que existe), mas seria supor-lhes umha maior capacidade. O projeto capitalista que as nossas elites desenvolverom durante o século XX obtivo, desde a própria óptica capitalista, um resultado medíocre, e no final do processo, quiserom maquilhar parte do seu fracasso dizendo que o que foi umha adaptaçom às pressas da gente perante o seu desleixo, era algo feio que devíamos apagar. Coitados...

A cicatriz está aí, é totalmente evidente e nom pode ser apagada. Mas nom tem sentido falarmos de se é mais ou menos feia. Isso nom é o que importa dumha cicatriz. A leitura proveitosa, além de nos lembrar de que a pesar de tudo estamos vivos, é a de que toda cicatriz encerra umha história, umha história neste caso que é nossa.

Deixemos ló de mirá-la como algo do que se avergonhar e afundemos nela. Havemos saber mais do que fomos e somos, e também nos há ajudar a criar o nosso próprio relato. Porque eis, na ferida sandada às pressas com ares salgados e azedos, onde atoparmos beleza. Nom a verdadeira, isso nom existe, mas sim a nossa própria.

Numa troca de emails sobre o ChatGPT, um colega perguntou-me qual seria a melhor forma de escrevermos prompts ao desenvolver código. Bom, a resposta não é simples, afinal isso implica conversar com uma rede neuronal e muitas vezes já é difícil fazê-lo com outras pessoas, quanto mais com uma máquina. No entanto, como sou uma pessoa muito educada e que gosta de ajudar sempre que possível, refleti e respondi da melhor maneira que pude.

A rede está repleta de dicas para melhorarmos os nossos prompts e tenho incorporado muitas delas, mas ao analisá-las individualmente, não sei qual grau de melhoria trouxeram. Inclusive, há algumas em que não tenho certeza se tiveram um impacto significativo. É normal, a experiencia que acumulo ainda não é suficiente para fazer estatística. Porém, o que posso afirmar é que em conjunto e em comparação aos meus rudimentares testes iniciais, a sua incorporação resultou em uma inegável melhora nos resultados obtidos.

Um caso diferente é o das estratégias focadas na resolução de tarefas mais complexas, pois, ao contrário das simples em que podemos obter uma resposta válida e até mesmo muito semelhante, usando ou não uma determinada dica, a adoção destas técnicas traz uma melhora imediata e evidente. Sem uma estratégia definida, o LLM tendia a se dispersar e cometer erros, exigindo que eu o corrigisse e o guiasse com novas perguntas ou instruções. No entanto, quando incluí no meu trabalho o Chain-of-Thought e o Generated Knowledge, esses problemas foram resolvidos. (Tenho pendente um post contando como desenvolvi um blogue em React com ajuda do ChatGPT).

Então, como avaliamos as pequenas dicas que achamos na rede? Uma primeira (e óbvia) abordagem é seguir os conselhos de fontes confiáveis. Eu gosto muito do learnprompting.org e do promptingguide.ai, no entanto existem muitas mais. Outra, complementar, é determinar se o propósito de uma dica faz sentido com o funcionamento dos LLMs. É evidente que seguir essa abordagem implica um gasto extra de tempo, pois:

1. Devemos ter clareza sobre o propósito da dica, embora todas tendam a buscar:
   • Reduzir o número de tokens utilizados nas perguntas e respostas.
   • Otimizar o trabalho do LLM no processamento das perguntas e na geração das respostas.
   • Obter a melhor resposta possível para a nossa tarefa.
2. E obriga-nos a aprofundar na compreensão e conhecimento dessas ferramentas.

Porém, esse sempre é um bom investimento, já que ajuda a melhorar nosso trabalho diário e nos permite desfrutar do prazer de aprendermos algo novo.

Finalmente o meu colega, que também é muito educado, agradeceu a resposta. Mas como igualmente é pragmático e directo, logo quis saber se eu tinha identificado alguma boa prática. Resumindo, procurava uma lista de dicas 😬

As minhas dicas

Eis as práticas que sempre incluo nos meus prompts orientados desenvolver tarefas simples. Para aprenderes a escrever código complexo com ChatGPT recomendo começares polo post "An example of LLM prompting for programming".

• Evito a formalidade. Nada de "Bom dia", "poderia a senhora…", "muito obrigado", etc. Não sufras, o LLM não é um ser senciente e sempre é bom pouparmos alguns tokens.
• Começo sempre com um "As a [rol name]". Com isto procuro formatar a resposta do modelo de uma maneira mais específica.
• Incluo detalhes com terminologia especializada. A ideia é fornecer o contexto suficiente para evitar o modelo ter de adivinhar o que eu quero dizer.
• Procuro ser o mais sintético possível, em equilíbrio com o anterior ponto. Quanto mais breve e direto é o nosso prompt, mais concisa será a resposta, além de continuarmos a popuar alguns tokens.
• Limpo o código de exemplo. Tudo o que não é precisso para desenvolver a tarefa só achega ruido e malgasto de tokens.

O que pretendia ser um rascunho de um método para aprender a conversar com as máquinas, transformou-se em outro post com dicas para usar o ChatGPT. Achas que o propósito de cada uma faz sentido com o funcionamento dos LLMs?

A primeira IA que usei (conscientemente) foi a Midjourney: escrever um prompt, pressionar enter, esperar um instante e a imagem surgia do nada. Linda, sofisticada e estranha. Foi como presenciar um ato mágico.

Depois experimentei o Dall·E e o Stable Diffusion, igualmente espetaculares, mas no final o tédio venceu a magia. Não achei utilidade para mim, prefiro gerar imagens do meu jeito.

Os meses passaram e deixou-se de falar tanto sobre elas, havia novo brinquedo, o ChatGPT.

Demorei para usá-lo, mas a semana passada copiei um snippet de JavaScript de um site antigo, colei-o na caixa do chat e perguntei: "Could you optimize this code snippet?" E o texto foi crescendo enquanto dizia, claro, você pode melhorar isso com aquilo, e aquilo com isso, etc. Deixo um exemplo para você. O exemplo fazia sentido e funcionava. Novamente um ato aparentemente mágico. Novamente a emoção. Mas agora também uma sensação diferente, um pouco de medo.

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 desempleo.

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:

Desta vez o ChatGPT não acertou. Ou melhor, acertou mas eu não forneci o contexto correto. Ele simplesmente verificava se a cidade existia na base de dados antes de buscar as informações meteorológicas. No entanto, para o usuário não havia diferença em relação à versão anterior, exceto pela troca de mensagens. Além disso, o problema das cidades com o mesmo nome não era resolvido.

Mea culpa e nova pergunta. Agora focada nas cidades de mesmo nome:

Com o código novo conseguia exibir a lista das cidades, mas não era possível clicar nelas, obtendo como resultado os dados de apenas uma ao pressionarmos o botão "Search".

Mais outra pergunta:

Com a troca sim era possível clicar numa das cidades da lista e, ao fazê-lo, obtiamos os seus dados meteorológicos.

Mas ainda restavam alguns pontos por polir:

• O botão "Search" realmente não servia para nada.
• A lista deveria desaparecer ao clicarmos numa das opções.
• Havia que passar a temperatura a Celsius.
• Estaria bem indicar o nome do país à direita de cada cidade.

Foi neste ponto que decidi deixar o piloto automâtico e passar a "modo manual", pois achei mais rápido modificar eu o código que continuar a perguntar.

Eis o resultado com as "modifciações humanas":

Já com o código pronto, chegava a hora de transformar nosso site em uma PWA (Progressive Web App):

E na primeira tentativa funcionou 🥳

Eis o resultado: Pe Man

Muito obrigado ChatGPT!

Conclusões

A primeira conclusão é que o ChatGPT é capaz de compreender muito bem até mesmo um inglês ruim como o meu 😬

A segunda é que ele pode ser útil para:

• Escrever um código base, ajudando-nos a poupar tempo. Depois de analisar o meu experimento, devo constatar que a melhor estratégia é escrever um prompt o mais amplo e contextualizado possível, em vez de formular muitas perguntas curtas.
• Fazer melhorias/trocas no código. Até certo ponto, depois é melhor passarmos ao modo manual/humano.
• Realizar consultas a uma API que não conhecemos sem necessidade de visitar sua documentação.
• Optimizar o código.
• Ampliar o conhecimento sobre uma linguagem, conhecendo outras abordagens.
• Iniciar-se em novas linguagens/tecnologias.

E a última e mais importante, é que ele não nos vai mandar as programadoras diretinhas para o desemprego. Pelo menos nos próximos meses…

🥹

Por exemplo, se num site precisamos de dous tipos de página: uma a uma coluna e outra com duas (conteúdo principal y coluna lateral), uma boa opção é usarmos a página por defeito, page.php, para a primeira e criarmos um template, sidebar-page.php, para a segunda. Deste jeito, para cada nova página, podemos eleger um ou outro layout desde o editor.

E em Frontity, onde o frontend não se gera com os templates em php do theme de Wordpress senão desde uma app em React? Pois as Custom Page Templates continuam a ser a melhor opção para trabalharmos com múltiples designs de página porque permitem:

• selecionar o design desejado desde o editor duma página,
• atribuir-lhes grupos de campos ACF, extendendo as posibilidades de edição,
• que na REST API (e no state de Frontity) apareça o nome do arqivo do template atribuido a uma página, facilitando a Frontity servir o layout correcto em cada caso.

Vejamos agora o processo completo com um exemplo singelo.

Wordpress

Criamos um arquivo php, custom-page-template.php por exemplo, com um comentário ao início como o seguinte:

“Template name:” é quem lhe indica ao Wordpress que esse ficheiro é uma page template e “My Custom Page Template Name” o nome do nosso novo template, que aparecerá no seletor de templates do editor de cada página.

¿Algo mais a fazer? não, isso é tudo na parte do Wordpress 😎

Bom, para evitarmos erros (e alguma dor de cabeça) devemos ter en conta que:

• As templates personalizadas só funcionan se temos um index.php (pode estar vazio) na raiz do nosso theme de Wordpress,
• nunca devemos usar page- como prefixo no nome do arquivo, pois o WordPress irá interpretá-lo como uma template especializada destinada a ser aplicada apenas a uma página do site.

Frontity

Criamos três componentes:

1. Page
2. PageDefault
3. PageTemplate

No primeiro incluímos um Switch que chama o segundo, PageDefault, ou o terceiro, PageTemplate, em função do valor da propiedade template que aparece nos dados da página do state do Frontity. Se a página publicada em Wordpress utilizar a template da página padrão, este valor chegará vazio e se utilizar uma custom, virá com o nome do ficheiro da template, custom-page-template.php no nosso caso.

E finalmente, na segunda e terceira, incluímos os layouts de ambos os tipos de página.

Simples, não é?

Se tiverdes alguma pergunta, achais que há margem para melhorias ou quererdes apenas dizer olá, podeis escrever-me para hola@xulioze.com 😋