Como eu acelerei o desenvolvimento frontend utilizando ferramentas de IA e o MCP do Figma

Ferramentas de IA aceleram muito o desenvolvimento frontend, mas só funcionam bem quando recebem contexto, limites e validação.

O ganho real não veio de pedir “crie uma tela”. Veio de organizar o fluxo:

instruções claras para o agente
integração com design via Figma MCP
mudanças pequenas
revisão humana
testes automatizados
validação visual com Playwright

O problema: IA sem contexto gera ruído

Um prompt assim normalmente gera dívida técnica:

Crie essa tela em React.

O resultado tende a vir com:

componentes grandes
CSS fora do padrão
nomes genéricos
regra de negócio misturada com UI
poucos testes
layout quebrando em estados reais

O que funcionou melhor foi tratar a IA como parte do fluxo de engenharia.

Codex com instruções do projeto

No Codex, usei um AGENTS.md para definir como o agente deve trabalhar no repositório.

Em vez de repetir regras em todo prompt, deixei o projeto explicar:

stack
estrutura de pastas
padrão de testes
comandos principais
regras de TypeScript
cuidados com integração
checklist antes de finalizar

No corpo do artigo, deixo só a ideia. O exemplo completo está no final: AGENTS.md exemplo.

Um prompt melhor para Codex fica assim:

Refatore este componente seguindo o AGENTS.md.
Mantenha o comportamento visual.
Adicione testes relevantes.
Rode lint e testes.

Isso muda bastante o resultado. O agente passa a respeitar o projeto em vez de inventar um padrão novo.

O mesmo conceito pode ser aplicado a outras ferramentas, como Claude, com alguns ajustes no arquivo de instruções. No Claude, por exemplo, eu usaria um CLAUDE.md mais focado em análise, revisão e tomada de decisão, enquanto no Codex o AGENTS.md fica mais direcionado à execução dentro do repositório.

Figma MCP no fluxo frontend

O MCP do Figma aproxima design e implementação.

Ele permite que o agente leia contexto do Figma, como:

estrutura da tela
nomes de layers
textos
medidas
componentes
variáveis
estilos

Isso ajuda muito em tarefas como:

Use o frame selecionado no Figma como referência e implemente a tela usando os componentes existentes do projeto.

O ponto importante: o MCP não substitui engenharia frontend. Ele reduz o atrito entre design e código.

Ainda é necessário:

adaptar ao design system do projeto
reaproveitar componentes existentes
validar responsividade
revisar acessibilidade
testar estados reais

Como configurar o MCP do Figma

A forma exata muda conforme o cliente, mas o fluxo geral é:

Instalar e abrir o Figma Desktop.
Abrir o arquivo de design.
Entrar em Dev Mode.
Ativar o Dev Mode MCP Server.
Configurar o cliente MCP para apontar para o servidor local.

O servidor local oficial do Figma usa HTTP, normalmente em:

http://127.0.0.1:3845/mcp

Exemplo genérico de configuração MCP:

{
  "mcpServers": {
    "figma-desktop": {
      "transport": "http",
      "url": "http://127.0.0.1:3845/mcp"
    }
  }
}

Depois disso, o agente pode receber prompts como:

Leia o frame selecionado no Figma e compare com a implementação atual.

ou:

Use o design selecionado como referência e implemente a tela mantendo os padrões do projeto.

Fluxo prático com Codex

O fluxo que mais funcionou foi:

1. Ler instruções do projeto
2. Inspecionar arquivos relevantes
3. Fazer mudança pequena
4. Adicionar ou ajustar testes
5. Rodar lint, testes e build
6. Revisar diff
7. Só então finalizar

IA acelera, mas testes e revisão seguram a qualidade.

Testes são o contrato

Sem testes, a IA acelera a entrega e também acelera regressões.

Usei diferentes camadas de teste.

Teste unitário

Para função pura:

it('formats currency', () => {
  expect(formatCurrency('10.5')).toBe('R$ 10,50')
})

Teste de componente

Para comportamento visível:

it('increments quantity', async () => {
  render(<QuantityStepper />)
  await user.click(screen.getByRole('button', { name: /aumentar/i }))
  expect(screen.getByRole('textbox')).toHaveValue('2')
})

Teste de hook

Para estado reutilizável:

it('loads data', async () => {
  const { result } = renderHook(() => useItems())
  await waitFor(() => expect(result.current.isLoading).toBe(false))
})

Teste de API

Para contrato com backend:

it('parses response', async () => {
  mockFetch({ success: true, data: { id: '1' } })
  await expect(fetchItem('1')).resolves.toEqual({ id: '1' })
})

E2E com Playwright

Para fluxo real:

test('opens product detail', async ({ page }) => {
  await page.goto('/app')
  await page.getByRole('textbox', { name: /referência/i }).fill('ABC')
  await page.getByRole('button', { name: /realizar leitura/i }).click()
  await expect(page.getByRole('region', { name: /dados/i })).toBeVisible()
})

Teste de layout

Para proteger alinhamento e scroll:

const box = await page.locator('.content').evaluate((el) => ({
  clientHeight: el.clientHeight,
  scrollHeight: el.scrollHeight,
}))

expect(box.scrollHeight).toBeLessThanOrEqual(box.clientHeight + 1)

Teste de screenshot

Para telas visualmente sensíveis:

test('matches open form layout', async ({ page }) => {
  await page.setViewportSize({ width: 1456, height: 793 })
  await page.goto('/app')
  await page.getByRole('button', { name: /verificar/i }).click()
  await expect(page).toHaveScreenshot('form-open.png')
})

Esse teste pega regressões difíceis de cobrir só com assertions:

botão quebrando linha
texto saindo do container
painel desalinhado
scroll inesperado
espaçamento quebrado

O que mudou na prática

Com esse fluxo, o Codex virou uma ferramenta de engenharia, não só geração de código.

Ganhos principais:

menos tempo em boilerplate
refactors mais rápidos
testes criados junto com a alteração
design mais próximo da implementação
regressões visuais detectadas cedo
revisão mais objetiva
padrões documentados no repositório

Conclusão

Codex e MCP do Figma ajudam muito no desenvolvimento frontend.

Mas a aceleração sustentável vem da combinação:

contexto claro
instruções versionadas
mudanças pequenas
testes automatizados
validação visual
revisão humana

IA boa não substitui engenharia. Ela aumenta a velocidade de quem sabe definir limites e validar resultado.

AGENTS.md exemplo

# AGENTS.md

## Purpose

This project uses React, Vite and TypeScript with a focus on predictable, typed, testable and maintainable code.

## Language Rule

- All source code must be written in English.
- Use English for identifiers, file names, comments, constants and test names.
- User-facing UI copy may follow product requirements.

## Stack

- React
- Vite
- TypeScript
- ESLint
- Vitest + Testing Library
- Playwright

## Main Commands

- `npm run dev`
- `npm run build`
- `npm run lint`
- `npm run test`
- `npm run test:e2e`

Before closing a meaningful change, run at least `npm run lint` and the relevant test suite.

## Project Structure

- `src/app`: app composition and providers
- `src/pages`: route-level pages
- `src/features`: domain-specific modules
- `src/shared`: reusable UI, styles, config and utilities
- `src/test`: Vitest setup and helpers
- `e2e`: Playwright specs and page objects

## Core Conventions

- Prefer small, local and predictable changes.
- Prefer composition over premature abstraction.
- Keep business logic out of purely visual components.
- Avoid generic `utils.ts` dumping grounds.
- Use explicit names for files, functions, props and types.
- Do not introduce `any` unless there is a strong reason.

## React and TypeScript

- Use functional components.
- Keep components focused on one responsibility.
- Derive values from props and state instead of duplicating state.
- Use `useEffect` only for real side effects.
- Do not add `useMemo` or `useCallback` by default.

## Testing

- Test user-visible behavior, not implementation details.
- Prefer Testing Library queries by role, text or label.
- Add tests when fixing bugs or introducing meaningful flows.
- Keep unit, integration and E2E scopes separate.

## Checklist

- The change respects project boundaries.
- Types are clear.
- No redundant state was introduced.
- Relevant linting and tests were executed.