I was “just” a CMS developer.
Then came AI

Sou programador e fiz CMS.

Passei boa parte dos últimos vinte anos a trabalhar com eles. CMS significava muitas vezes WordPress, e WordPress significava sites. É uma associação compreensível, mas conta apenas uma parte do trabalho.

Um título, uma fotografia e um botão «Publicar» podem ser tudo o que se vê. Por trás podem estar redações, traduções, permissões, integrações e anos de conteúdos que têm de sobreviver à atualização seguinte. Foi a trabalhar nestes problemas que mais aprendi.

Hoje, a IA permite a muitas mais pessoas construir uma aplicação, uma ferramenta de gestão ou até o seu próprio CMS. Acho isso entusiasmante. E reconheço nesses projetos muitos dos problemas em que trabalhámos durante anos.

Quanto mais fácil se torna gerar software, mais útil é saber o que esse software deve conseguir fazer ao longo do tempo. É dessa experiência que quero falar.

O software começa por quem o vai usar

Quem abre um CMS costuma ter um trabalho para terminar: publicar um artigo, atualizar um catálogo, organizar um evento. O nosso modelo de dados tem de encontrar esse trabalho. Um campo obrigatório pode fazer todo o sentido na base de dados e ser impossível de preencher quando alguém está apenas a esboçar um conteúdo. Mais cedo ou mais tarde escreverá «por definir», e a restrição terá produzido dados piores.

É uma lição de produto que se torna imediatamente arquitetura: distinguir um rascunho de um conteúdo publicável, pedir a informação no momento certo, tornar o erro compreensível e a recuperação possível.

No software empresarial, quem compra e quem usa são frequentemente pessoas diferentes. Um trabalhador pode ter de conviver durante anos com uma interface difícil. Nos produtos de consumo, mais fáceis de abandonar, a mesma dificuldade pode custar um cliente. Muitos CMS ficam entre os dois: ferramentas de trabalho para pessoas com competências, hábitos e paciência muito diferentes. Foram uma boa escola para conciliar estrutura e facilidade de utilização.

Essa familiaridade reconhece-se nas aplicações atuais. Um CRM, um sistema de gestão imobiliária, um painel administrativo: filtro informação, escolho como a apresentar, faço alguma coisa. Consulta, vista, ação. Tabela, calendário e kanban podem ser três formas de trabalhar sobre os mesmos dados.

Esta gramática também tem raízes nas bases de dados e nos sistemas de gestão. Os CMS praticaram-na durante anos junto de pessoas que precisavam dela diariamente sem conhecer chaves estrangeiras. Agora a IA permite gerar uma vista para uma única tarefa, talvez para durar dez minutos. Por baixo, o significado dos dados e as regras para os alterar têm de continuar reconhecíveis.

Anatomia de um CMS

Tomemos o Directus, porque trabalho com ele e posso observá-lo de perto. Dizer «uma base de dados com API e um painel» é tão correto como descrever um animal como algo com pele e órgãos. Para perceber o que compramos, reutilizamos ou pensamos reconstruir com IA, temos de separar as suas responsabilidades.

Começo pelo exterior. A pele é o Data Studio: formulários, vistas e painéis tornam o sistema utilizável. Mas esconder um campo no formulário não o protege no servidor. O esqueleto é o modelo de dados: tabelas e relações SQL, com os metadados que o Directus usa para descrever campos, interfaces e configurações. Cabe-nos definir o significado de «cliente», «projeto» ou «aprovado». Depois abrimos o coelho.

A distinção decisiva está entre o que o Directus sabe fazer e as decisões que nos cabe tomar. Oferece coleções, relações, permissões, versões e automatizações. Definir quem aprova uma despesa, quando um rascunho é publicável ou como reconhecer o mesmo cliente em dois sistemas exige um modelo do nosso trabalho. O produto fornece ferramentas para o expressar; a correção desse modelo continua a ser responsabilidade nossa.

Sigamos uma alteração concreta: um editor muda o preço de um produto. O Data Studio recolhe o valor; a API recebe o pedido; os serviços executam-no no contexto do utilizador e das permissões configuradas. A base de dados aplica as suas restrições. O histórico, se configurado, conserva a alteração. Um Flow pode iniciar a atualização de um catálogo externo. São responsabilidades diferentes: se o último serviço não responder, o preço guardado e o que aparece noutro lugar podem divergir. Precisamos de uma regra de recuperação e de uma forma de detetar isso.

As fronteiras também contam quando estendemos a plataforma. A documentação dos serviços pede atenção ao contexto de autorização, chamado accountability: omiti-lo pode dar permissões administrativas ao serviço.³ E um campo oculto no Data Studio não substitui uma política sobre os dados.⁴ O valor da plataforma também depende do respeito pelas suas fronteiras.

Fora do animal ficam a operação e a manutenção: base de dados e armazenamento, segredos, cópias de segurança verificadas, monitorização, atualizações e compatibilidade dos clientes. Podemos delegar parte num serviço gerido, mas precisamos de saber quem a assegura. Migrar o esquema ou restaurar uma revisão resolve parte do problema, não um plano completo de recuperação.

As escolhas de licença também chamam a atenção para o custo do conjunto. O Directus adota hoje a MSCL, uma licença source-available: o código pode ser consultado; a utilização depende das condições aplicáveis.⁵ Quem avalia uma alternativa deve contar com o custo de manter, ao longo do tempo, as responsabilidades que assumir.

Facilidade de utilização, também fora do navegador

O mesmo cuidado deve chegar a quem trabalha com código, scripts e automatizações. A developer experience, ou DevEx, é outra forma de usabilidade: documentação clara, tipos explícitos, comandos previsíveis, erros compreensíveis. Permite ser preciso e repetir uma operação sabendo o que esperar.

No Directus, esse cuidado assume formas concretas. O SDK JavaScript e TypeScript oferece um cliente componível para API, autenticação e tempo real, com suporte para os tipos do próprio esquema.⁶ A CLI de sincronização de ambientes permite exportar esquema e configurações, examinar diferenças e aplicá-las a instâncias compatíveis, incluindo numa pipeline.⁷ O servidor MCP expõe dados e operações a assistentes de IA através do Model Context Protocol, respeitando as permissões da identidade com que se ligam.⁸

Isto dá liberdade real: usar o painel, escrever uma integração, executar um comando ou trabalhar com o próprio agente no próprio ambiente. Pode-se escolher a interação e encontrar o mesmo modelo de dados, com as autorizações exigidas por cada operação. A IA entra assim num sistema que já tem estrutura e regras.

Para mim, «bonito e cómodo» inclui software que uma pessoa possa orquestrar, também através do seu agente. Posso compor um fluxo, delegar etapas, verificar o resultado e intervir. A automatização torna-se uma forma de exercer mais controlo sobre o trabalho. Uma DevEx cuidada torna isso possível hoje.

«É só uma galeria de imagens»

Um pedido normal: a imagem principal de um artigo deve passar a ser uma galeria ordenada. Acrescentamos miniaturas ao formulário e a possibilidade de as arrastar. Parece uma tarde tranquila.

Mas o modelo passa de uma referência única para uma relação com várias imagens e uma ordem. Os artigos existentes têm de conservar a fotografia. API e templates precisam de compreender a nova estrutura. As permissões têm de deixar os editores gerir também a relação, sem abrir acessos indesejados aos ficheiros. Entretanto, os editores continuam a trabalhar.

Podemos avançar por etapas: acrescentar a relação, transformar referências existentes na primeira imagem de cada galeria, atualizar as leituras e retirar o campo antigo. Na transição, é também preciso decidir como tratar novas escritas: se alguém alterar a imagem antiga depois da migração inicial, essa mudança tem de chegar à galeria. Uma disponibilização compatível considera também o que acontece durante a sua execução.

Esquema, dados, ficheiros e código têm de funcionar em conjunto em cada fase da mudança. Podem evoluir em momentos diferentes, desde que exista um percurso que mantenha a compatibilidade.

Por isso, promover o esquema de desenvolvimento para produção e transferir conteúdos são operações distintas.⁹ Voltar ao código de ontem pode deixar o sistema avariado se entretanto transformámos os dados. E uma cópia de segurança da base, por si só, pode não chegar: se referir imagens já eliminadas do armazenamento, recuperámos referências a algo que deixou de existir.

De uma galeria chegámos à recuperação de desastres. Precisamos de saber que ficheiros guardar, que versões do código conseguem reabrir os dados e como reiniciar integrações sem repetir ações já executadas. Um email enviado ou uma operação num serviço externo não recuam juntamente com a base de dados.

É aqui que entra a oficina construída em redor do CMS: infraestrutura, pipelines CI/CD, observabilidade, exercícios de restauro. Serve para disponibilizar alterações numa ordem precisa, distinguir uma permissão errada de um serviço parado e verificar quanto trabalho poderíamos perder num incidente. Depois há as pessoas: quem aprova a mudança, quem intervém, quem conhece o motivo daquela regra estranha.

Na welance, a nossa cloud e os processos construídos à sua volta fazem parte desta experiência coletiva. Quem acompanhou CMS complexos traz frequentemente uma forma inteira de trabalhar, muito mais difícil de ver do que um ecrã.

A IA também pode ajudar a escrever migrações, testes e procedimentos de recuperação. A experiência permite reconhecer quais pedir e perceber se as provas demonstram aquilo que nos interessa. O protótipo mostra que algo pode funcionar; o trabalho seguinte estabelece em que condições continuará a fazê-lo.

O C significa conteúdo

Até aqui falei de artigos e fotografias. Mas conteúdo também pode ser um requisito, um imóvel, uma disponibilidade, uma decisão ou a relação entre um projeto e uma pessoa. Essa abertura sempre me interessou nos CMS.

Um sistema suficientemente flexível pode ser a base de uma gestão imobiliária, de um CRM ou de partes de um ERP. Já oferece um lugar para descrever entidades, relacioná-las, atribuir acessos e construir interfaces. Acrescenta-se o conhecimento do domínio: uma reserva deve impedir sobreposições mesmo perante dois pedidos simultâneos; uma decisão contabilística traz restrições que um artigo não tem.

Interessa-me o CMS precisamente como espaço para estas possibilidades. Muito do chamado «software de gestão» consiste em estruturar informação e permitir que as pessoas certas atuem sobre ela. Com a IA, surge um novo interlocutor capaz de ler, propor e operar. A qualidade da estrutura torna-se ainda mais importante.

Quando a memória se torna operacional

Uma memória partilhada torna-se operacional quando podemos seguir um dado até à sua fonte, uma decisão até aos seus motivos e uma ação até às regras que a autorizam.

O conhecimento torna-se racional na medida em que o podemos reconstruir e verificar. Um movimento registado, uma estimativa e uma conclusão do modelo devem continuar distinguíveis. As regras de cálculo e as ligações têm de poder ser inspecionadas. Esta base permite a pessoas diferentes, com agentes diferentes, trabalhar sobre os mesmos factos e discutir interpretações.

Vejo aqui uma ligação à LLM Wiki proposta por Andrej Karpathy: um modelo lê fontes e mantém conhecimento persistente através de sínteses e ligações atualizadas ao longo do tempo.¹¹ Num CMS podemos associá-lo a projetos, responsabilidades e estados: que requisito está aprovado, quem o pode alterar, que tarefa depende dele.

As fontes podem ser documentos, gravações ou fotografias. As ferramentas que as interpretam devem preservar a proveniência para permitir a uma pessoa verificar e corrigir a síntese. O modelo pode mudar; dados, decisões e relações devem poder permanecer. Nesse sentido, o sistema torna-se parte da inteligência da empresa.

Passar à ação exige autorizações precisas. Ler um requisito não dá automaticamente o direito de alterar o projeto ou enviar algo a um cliente. Cada conector deve verificar a ação pedida e usar credenciais adequadas no serviço externo. O MCP oferece uma forma comum de ligar ferramentas; a correspondência entre permissões de sistemas diferentes tem de ser concebida. Até uma síntese de documentos confidenciais deve respeitar essas fronteiras.¹²

É esta evolução que imagino com um AI Management System, ou AI MS: um sistema de gestão em que pessoas e agentes trabalham sobre a mesma memória operacional. Cada um interage à sua maneira, enquanto regras, responsabilidades e histórico permanecem verificáveis. É um nome de trabalho para uma direção promissora.

O CMS pode ser a peça a retirar

A objeção mais forte à minha tese é que a IA pode tornar dados e regras mais importantes e o CMS que os reúne menos necessário. As responsabilidades da prancha anatómica podem ser reorganizadas. As competências descritas pertencem à engenharia de software. Tê-las aprendido com CMS não prova que um CMS continue a ser a melhor escolha.

Se construir ferramentas específicas fica mais barato, muda a vantagem de nos adaptarmos a uma plataforma generalista. Pode ser preferível uma pequena aplicação feita para o nosso trabalho a um CMS cheio de extensões. SDK, CLI e MCP também apoiam essa alternativa: tornam cada produto acessível e componível sem lhe atribuir necessariamente um papel central.

O modelo comum também tem um custo. Um projeto para quem planeia o trabalho e uma encomenda para quem fatura podem ter fronteiras diferentes. O domain-driven design trata precisamente essa pluralidade, delimitando modelos e explicitando relações.¹³ Forçá-los numa estrutura única pode criar traduções frágeis, cópias desatualizadas e um ponto por onde todas as mudanças têm de passar.

Uma alternativa sensata conserva os sistemas de referência nos seus domínios e liga-os por contratos explícitos. O agente coordena operações; os serviços continuam a aplicar as próprias regras. O CMS pode ficar onde é necessário aos editores ou sair totalmente desse fluxo. Tenho de considerar essa possibilidade também para não reconhecer no futuro sobretudo a ferramenta que conheço melhor.

Para mim, o CMS merece esse lugar quando relações, permissões e processos editoriais partilhados são uma parte substancial do trabalho. Se exigir duplicar regras já fiáveis noutros lugares e manter sincronizações contínuas, a vantagem pode desaparecer. O teste concreto é imaginar que o retiramos: que responsabilidades reconstruiríamos, que integrações eliminaríamos e quanto mais difícil seria perceber ou recuperar de um erro? A melhor escolha reduz o trabalho total mantendo as garantias necessárias.

As ferramentas que gostaria de usar amanhã

Esta perspetiva influencia as ferramentas que me interessam. Gosto da abordagem do Railway, com serviços e ambientes visíveis no projeto. O Lovable parte da construção da aplicação e também oferece um backend gerido com base de dados, autenticação e armazenamento.¹⁴ São formas diferentes de tornar acessível um sistema que continua a ter dependências por baixo.

Prefiro plataformas que tornem essas dependências compreensíveis e nos ajudem a geri-las. Imagino a construção conversacional como uma capacidade de uma plataforma mais ampla que acompanha o software depois da primeira disponibilização.

Gostaria de pedir «transforma esta imagem numa galeria» e ver que dados mudarão, como serão tratados os existentes, que serviços estarão envolvidos e onde será necessária aprovação. Também quero saber como recuperar se algo correr mal. Desenhar componentes numa tela é um bom início; o valor está em gerir a mudança que os atravessa.

O próximo CMS pode nascer daqui ou da evolução das ferramentas atuais. Importa-me que uma pessoa possa escolher a sua interface e o seu agente, continuando numa base partilhada. A diferença estará na capacidade de acompanhar uma mudança desde a intenção de quem a pede até às consequências no sistema.

Viva o CMS

No mundo dos CMS também há muito trabalho feito por inércia: instalar um tema, acumular plugins e entregar sem perguntar como o sistema se vai aguentar. Ter trabalhado com CMS não é, por si só, um sinal de cuidado ou competência. A facilidade de começar pode incentivar tanto a curiosidade como a preguiça.

Ao olhar para o que construímos hoje com IA, dou sobretudo por mim a reconhecer algo que sempre foi óbvio: bom software é bom software. Reconhece-se pelo que faz por quem o utiliza e pela forma como resiste ao tempo e à mudança. Os nomes, as siglas e a tecnologia do momento dizem pouco por si só.

A quem hoje constrói o seu sistema de gestão com IA deixaria quatro perguntas, as mesmas que continuaria a fazer a mim próprio:

• Que regras têm de continuar válidas enquanto o sistema muda?
• Quem pode agir, sobre que dados e com que consequências?
• O que tentámos realmente recuperar depois de um erro?
• O que saberá quem chegar depois de nós?

Os CMS foram o contexto em que aprendi a fazer estas perguntas. Levo comigo o que aprendi, incluindo quando isso me ajuda a escolher outra arquitetura.

CMS is dead. Long live the CMS.