Criando um ambiente automatizado para enviar código frontend gerado por IA direto para produção
makedream2026年7月26日
0
Computing/Software
Comments (0)
Log in to leave a comment
No posts yet
makedreammakedreamLog in to leave a comment
No posts yet
Ao assistir aos vídeos de demonstração de ferramentas de IA, parece incrível: você clica em alguns botões, digita algumas frases e surge uma UI espetacular. O problema é a realidade. No momento em que você traz o código gerado pela IA para um projeto existente, todo o estilo se quebra e o gerenciamento de estado vira uma bagunça. Provavelmente todo mundo já passou pela experiência de gastar o dobro do tempo de desenvolvimento só tentando ajustar e consertar isso.
No fim das contas, para usar o código de IA sem dores de cabeça, é preciso amarrar a análise estática, a estruturação de estado e a validação visual em guardrails automatizados. Aqui está a configuração concreta para trazer esse código em um estado pronto para uso, sem precisar passar a noite em claro fazendo ajustes.
A IA costuma entender bem o contexto, mas de repente ignora os tokens do projeto. Ela começa a inserir valores arbitrários entre colchetes, como w-[327px], ou estilos inline com códigos hexadecimais por conta própria. O design system ruiu instantaneamente e a prioridade do CSS vira um nó.
Se um ser humano tentar encontrar e corrigir isso a olho nu, já é tarde demais. É preciso bloquear a entrada usando um Linter.
Instale os pacotes necessários no projeto.bash npm install -D eslint-plugin-tailwindcss @html-eslint/eslint-plugin
No arquivo eslint.config.mjs, adicione regras para capturar valores arbitrários entre colchetes e estilos inline como erros.
Registre npx eslint --fix nos scripts do seu Package e execute-o logo após receber o código.
Com essa estrutura, no momento em que um valor entre colchetes ou um estilo inline entra, o linter dispara um erro e força a substituição pela classe utilitária padrão mais próxima. Ao eliminar esse trabalho braçal, economizamos mais de 5 horas por semana que antes eram gastas ajustando estilos.
`javascript
// eslint.config.mjs
import eslintPluginTailwindcss from "eslint-plugin-tailwindcss";
import { defineConfig } from "eslint/config";
export default defineConfig([
{
plugins: {
tailwindcss: eslintPluginTailwindcss,
},
settings: {
tailwindcss: {
cssConfigPath: "./styles/tailwind.css",
},
},
rules: {
"tailwindcss/no-arbitrary-value": "error",
"tailwindcss/no-custom-classname": [
"error",
{ whitelist: ["custom-*"] },
],
"tailwindcss/classnames-order": "warn",
},
},
]);
`
| Regra de Linting | Método de verificação | Exemplo de bloqueio | Resultado da correção automática |
|---|---|---|---|
| @html-eslint/no-inline-styles | Bloqueia estilos inline JSX | <div style={{color: '#ff0a00'}}> |
<div className="text-destructive"> |
| tailwindcss/no-arbitrary-value | Bloqueia valores arbitrários entre colchetes | <button className="w-[327px]"> |
<button className="w-80"> |
| tailwindcss/no-custom-classname | Detecta nomes de classes não registrados | <div className="my-custom-card"> |
<div className="rounded-lg border bg-card shadow-sm"> |
Se você pedir à IA para criar um componente React, nove em cada dez vezes ela espalhará três ou quatro useState dentro de um único arquivo. Se chamadas de API assíncronas e tratamento de erros se misturarem a isso, uma bomba de renderização explodirá.
O estado da UI do cliente deve ser centralizado com Zustand, enquanto os dados do servidor devem ser separados com React Query. Para formulários de entrada, fixamos a estrutura usando a combinação de Zod e react-hook-form.
Instale as bibliotecas de dependência.bash npm install @tanstack/react-query zod react-hook-form @hookform/resolvers
No schema do prompt da IA, proíba o uso direto de fetch e faça com que ela defina os tipos primeiro usando o schema do Zod.
Conecte o zodResolver ao react-hook-form para automatizar a validação e estruture o código para chamar useMutation no momento do submit.
As re-renderizações desnecessárias desaparecem completamente. Falhas na validação de entrada nem chegam a entrar no componente.
`typescript
import { useForm } from 'react-hook-form';
import { zodResolver } from '@hookform/resolvers/zod';
import { z } from 'zod';
export const userProfileSchema = z.object({
username: z.string().min(2, { message: '이름은 최소 2자 이상이어야 합니다.' }),
email: z.string().email({ message: '올바른 이메일 형식이 아닙니다.' }),
role: z.enum(['admin', 'user'], { required_error: '역할을 선택하세요.' }),
});
export type UserProfileInputs = z.infer;
export function ProfileForm() {
const {
register,
handleSubmit,
formState: { errors },
} = useForm({
resolver: zodResolver(userProfileSchema),
});
const onSubmit = (data: UserProfileInputs) => {
// React Query Mutation 실행
};
return (
| Área | Anti-pattern da IA | Estrutura refinada | Vantagem |
|---|---|---|---|
| Estado do cliente | useState fragmentado | Store única no Zustand | Previne re-renderizações desnecessárias |
| Dados do servidor | fetch dentro de useEffect | Abstração com React Query | Caching automático e carregamento declarativo |
| Validação de formulário | Checagem manual com condicionais | Zod + react-hook-form | Type safety e automação da validação |
Olhar apenas para uma tela de desktop e pensar "Nossa, ficou ótimo" para depois abrir no celular e ver o layout completamente destruído é algo extremamente comum. De acordo com o relatório de acessibilidade web de 2025 da WebAIM, ocorrem em média mais de 51 erros de WCAG apenas na página principal dos 1 milhão de sites mais acessados. Quanto mais ao código recém-gerado por IA, nem se fala sobre quebras de responsividade.
Automatizando testes de regressão com Playwright e Pixelmatch, você não precisa ficar reduzindo a janela do navegador manualmente para checar tudo.
Instale as ferramentas de teste.bash npm install -D @playwright/test @axe-core/playwright
Adicione um script que percorre as viewports de mobile (375px), tablet (768px) e desktop (1440px) tirando screenshots.
Defina o limite de maxDiffPixelRatio em 0.02. Se ultrapassar esse valor, a imagem da diferença de pixels é reenviada para o prompt da IA para que ela reescreva as media queries.
Após rodar esse loop de testes de renderização, o tempo de inspeção manual da UI diminuiu mais de 80%.
`typescript
import { test, expect } from '@playwright/test';
const viewports = [
{ name: 'mobile', width: 375, height: 667 },
{ name: 'tablet', width: 768, height: 1024 },
{ name: 'desktop', width: 1440, height: 900 },
];
for (const vp of viewports) {
test(Responsive layout test - ${vp.name}, async ({ page }) => {
await page.setViewportSize({ width: vp.width, height: vp.height });
await page.goto('/render-test-harness');
await expect(page.locator('#ai-component-root')).toHaveScreenshot(
`component-${vp.name}.png`,
{
maxDiffPixelRatio: 0.02,
threshold: 0.2,
animations: 'disabled',
}
);
});
}
`
Por mais bem estruturado que seja o prompt, às vezes entra algum código lixo bizarro, assim como um ar-condicionado de IA falhando. É preciso impedir que códigos que quebram a tipagem ou não passam no lint logo antes do commit cheguem a entrar no seu espaço de trabalho do Git.
Configure os Git hooks com o Lefthook.
Instale o Lefthook no projeto e crie o arquivo lefthook.yml na raiz.bash npm install -D lefthook
Adicione os comandos de verificação do ESLint, Prettier e TypeScript na etapa de pre-commit.
Ative a opção stage_fixed: true para que as alterações corrigidas automaticamente sejam aplicadas diretamente ao commit.
Se houver erros de tipo corrigidos ou Props apagadas sem autorização, o commit é interrompido imediatamente. É a maneira mais garantida de encerrar a ineficiência de ter um desenvolvedor atuando manualmente como revisor de código para limpar os resíduos deixados pela IA.
`yaml
pre-commit:
commands:
eslint-autofix:
glob: ".{js,ts,jsx,tsx}"
run: npx eslint --fix {staged_files}
stage_fixed: true
prettier-format:
glob: ".{js,ts,jsx,tsx,css,json}"
run: npx prettier --write {staged_files}
stage_fixed: true
typescript-check:
glob: "*.{ts,tsx}"
run: npx tsc --noEmit
`