A maioria dos desenvolvedores de software, tech leads e engenheiros de DevOps começa a carreira como construtores.

Eles constroem sistemas, aplicativos, componentes, temas, padrões, módulos e pipelines. Otimizam layouts, corrigem casos extremos, mantêm a compatibilidade e levam os sistemas adiante um commit por vez. O trabalho é preciso, prático e profundamente técnico.

Mas, em algum momento, algo muda.

Os melhores profissionais não param de construir, mas passam a pensar em sistemas.

De construtor a pensador de sistemas

A mudança: da entrega às regras

Como construtor, o foco está na entrega: componentes, templates, páginas, funcionalidades, bibliotecas, aplicações.

Como pensador de sistemas, o foco passa para as regras: restrições, interações, ciclos de feedback.

Em vez de perguntar "Com que cara fica este componente?", quem pensa em sistemas faz outras perguntas: Que regras governam este componente? O que pode interagir com ele? Como ele se comporta diante de mudanças? Como a intenção sobrevive ao tempo?

Essa mudança leva naturalmente aos sistemas agênticos.

Quando o design deixa de ser estático

Os design systems modernos já codificam lógica: os tokens definem restrições, os componentes definem estrutura, os padrões definem comportamento.

Ainda assim, a maioria dos sistemas continua dependendo de uma pesada orquestração humana.

Os agentes de IA trazem um modelo diferente, em que os sistemas podem fazer cumprir as próprias regras, validar decisões continuamente, reagir ao contexto e se coordenar internamente.

É aqui que o design evolui da documentação para a lógica executável.

Para onde isso está indo

O foco agora é implementar essas ideias em sistemas reais e funcionais, não como experimentos, mas como alicerces.

1. Integração mais profunda de agentes de IA com ferramentas de design (Figma)

Rumo a design systems agênticos

As ferramentas de design não deveriam ser telas passivas.

O objetivo é integrar ao Figma agentes de IA que entendam design tokens e restrições de componentes, validem decisões em tempo real, traduzam a intenção de design em regras no nível do sistema e atuem como colaboradores, não como exportadores.

Isso leva o design para a montante, onde a intenção é preservada, e não inferida depois.

2. Gestão escalável de agentes de IA

Meta: 150 agentes, um por componente

Em vez de uma única IA de uso geral, as equipes estão migrando para muitos agentes especializados.

Cada componente ganha seu próprio agente, com responsabilidades definidas, limites claros e conhecimento dos componentes relacionados.

Isso espelha a forma como os sistemas saudáveis escalam: por meio de especialização, coordenação e contratos claros.

3. Agentes com habilidades, ferramentas e plugins de verdade

Os agentes precisam ser capazes de agir.

Isso significa equipá-los com habilidades (raciocínio sobre acessibilidade, validação de design, atenção ao desempenho), ferramentas (linters, executores de testes, APIs de design) e plugins (Storybook, Drupal, pipelines de CI, integrações com o Figma).

Um agente sem ferramentas é teórico. Um agente com ferramentas torna-se parte do próprio sistema.

4. Testes de aceitação funcionais automatizados mais inteligentes

Orientados por IA e cientes da intenção

O teste tradicional verifica a saída. O teste conduzido por agentes entende o comportamento.

O foco está em agentes de IA que raciocinam sobre jornadas de usuário, testes funcionais que entendem a intenção em vez de apenas seletores, sistemas que evoluem os testes junto com os componentes e na redução de testes frágeis, aumentando a confiança semântica.

O teste se torna mais uma camada de inteligência do sistema.

TDD e BDD na era da IA: por que os agentes de IA exigem 100% mais desenvolvimento orientado a testes

Por que isso importa

As equipes estão construindo sistemas que sobrevivem aos seus criadores, se adaptam continuamente e levam adiante decisões de design de longo prazo.

Nesse mundo, o controle manual não escala. Mas regras bem definidas escalam.

Designers, desenvolvedores e agentes de IA precisam operar dentro do mesmo arcabouço lógico: um único sistema compartilhado de restrições e intenção.

A transição de construtor para pensador de sistemas não significa abandonar a implementação. Trata-se de enxergar os sistemas como algo mais do que um conjunto de peças.

O próximo passo é projetar as regras que permitem aos sistemas raciocinar, se adaptar e evoluir.

Desenvolvedores de software, tech leads e engenheiros de DevOps que fazem essa mudança não estão apenas construindo: estão construindo as condições para que os sistemas se construam sozinhos.