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.
Referências
- Figma Dev Mode MCP Server: https://developers.figma.com/docs/figma-mcp-server/local-server-installation/
- Guia do Figma MCP Server: https://help.figma.com/hc/en-us/articles/32132100833559-Guide-to-the-Figma-MCP-server