O próximo salto da Engenharia de Software não será escrever mais código com IA. Será ensinar a IA exatamente o que construir.
Olá, Mentes Tech!
Nos últimos anos vimos uma explosão de ferramentas de IA para desenvolvimento.
- GitHub Copilot
- Cursor
- Claude Code
- Gemini CLI
- OpenAI Codex
A produtividade aumentou absurdamente.
Mas um novo problema apareceu.
Depois de alguns dias de desenvolvimento, ninguém mais sabe responder perguntas simples:
- Por que essa regra existe?
- Esse comportamento foi um requisito ou uma decisão da IA?
- Posso alterar essa função sem quebrar outra parte do sistema?
- Onde está documentada essa decisão?
Na prática, muitos projetos estão virando uma enorme coleção de prompts.
E prompts são difíceis de versionar, revisar e manter.
O problema não é gerar código
Gerar código nunca foi tão fácil.
O difícil continua sendo definir o que realmente precisa ser construído.
É exatamente por isso que o conceito de Spec-Driven Development (SDD) vem ganhando força.
Em vez de começar pelo código, começamos pela especificação.
Ideia
│
▼
Especificação
│
▼
Plano Técnico
│
▼
Tasks
│
▼
Implementação
A especificação deixa de ser apenas documentação.
Ela passa a ser a fonte oficial da verdade do projeto.
Qualquer agente de IA pode ler essa especificação e produzir resultados consistentes.
Conhecendo o GitHub Spec Kit
Recentemente a GitHub publicou o Spec Kit, um projeto Open Source que organiza exatamente esse fluxo.
A proposta é simples.
Em vez de escrever:
Faça uma API para analisar candles.
Você escreve uma especificação completa.
Depois ferramentas de IA geram:
- arquitetura
- plano técnico
- backlog
- tarefas
- código
- testes
Tudo baseado na mesma fonte.
Isso reduz ambiguidades e melhora muito a colaboração entre pessoas e agentes de IA.
Um exemplo prático
Imagine que queremos construir um sistema para análise de mercado financeiro.
Esse sistema recebe milhões de candles históricos e em tempo real e precisa gerar insights automaticamente.
Antes de pensar em Go, Python ou Rust, escrevemos a especificação.
market-insight-engine.spec.md
# Market Insight Engine
## Objetivo
Construir um mecanismo capaz de receber grandes volumes de candles
financeiros e gerar insights inteligentes sobre o comportamento
do mercado.
O sistema deve identificar padrões técnicos,
calcular indicadores e produzir hipóteses sobre
continuação ou reversão de tendência.
---
## Fontes de Dados
Suportar:
- CSV
- REST
- WebSocket
- Kafka
---
## Entrada
Cada candle deve possuir:
symbol
timeframe
timestamp
open
high
low
close
volume
---
## Timeframes
- M1
- M2
- M5
- M15
- H1
- D1
---
## Indicadores
Calcular automaticamente:
- VWAP
- EMA 9
- EMA 21
- EMA 200
- SMA 20
- ATR
- ADX
- RSI
- MACD
- Relative Volume
---
## Reconhecimento de Padrões
Detectar automaticamente:
- Breakout
- Fake Breakout
- Pullback
- Compressão
- Acúmulo
- Distribuição
- Gap
- Candle de Exaustão
---
## Inteligência
Cruzar indicadores para produzir hipóteses.
Exemplo
Se
Breakout
AND
ADX > 25
AND
Relative Volume > 2
Então
Trend Confidence = High
---
Outro exemplo
Se
RSI > 75
AND
Volume decrescente
Então
Possível exaustão compradora.
---
## API
POST /insights
Entrada
{
"symbol":"WIN",
"timeframe":"M2"
}
Resposta
{
"market":"Bullish",
"confidence":91,
"signals":[
"Breakout",
"ADX Rising",
"Relative Volume High"
],
"risk":"Low"
}
---
## Performance
Processar
10 milhões de candles
em menos de
30 segundos.
---
## Escalabilidade
Suportar processamento paralelo.
Permitir múltiplos workers.
---
## Observabilidade
Exportar
Prometheus
OpenTelemetry
Health Check
---
## Testes
Cobertura mínima
90%
---
## Segurança
Autenticação JWT
Rate Limit
Auditoria
Observe que até aqui não existe nenhuma decisão de implementação.
Não falamos sobre:
- linguagem
- banco de dados
- Kubernetes
- Docker
- Redis
- PostgreSQL
Primeiro definimos o comportamento esperado.
Depois escolhemos a tecnologia.
O que uma IA pode gerar a partir dessa especificação?
Um agente poderia criar automaticamente uma arquitetura como esta:
Kafka
│
▼
Candle Ingestion
│
▼
Indicator Engine
│
▼
Pattern Detector
│
▼
Insight Generator
│
▼
REST API
│
▼
Dashboard
Depois gerar um backlog.
Task 01
Criar parser de candles
Task 02
Implementar VWAP
Task 03
Implementar EMA
Task 04
Implementar ATR
Task 05
Implementar ADX
Task 06
Implementar Relative Volume
Task 07
Criar detector de Breakout
Task 08
Criar detector de Pullback
Task 09
Criar API REST
Task 10
Criar WebSocket
Task 11
Criar Dockerfile
Task 12
Criar Helm Chart
Task 13
Criar Pipeline GitHub Actions
Task 14
Criar testes automatizados
Perceba que todas essas tarefas nasceram da especificação.
Não de um prompt.
O verdadeiro ganho
O maior benefício não é produzir código mais rápido.
É produzir software consistente.
Imagine um projeto com:
- Cursor
- Claude Code
- GitHub Copilot
- Gemini
- Codex
Cada ferramenta possui comportamentos diferentes.
Mas todas conseguem seguir exatamente a mesma especificação.
Ela se torna um contrato entre humanos e IA.
Minha visão
Durante muitos anos o código foi considerado o ativo mais importante de um projeto.
Hoje começo a acreditar que isso está mudando.
O ativo mais valioso passa a ser a especificação.
Porque qualquer IA consegue gerar código.
Poucas conseguem descobrir sozinhas o que realmente precisa ser construído.
Acredito que veremos cada vez mais equipes versionando especificações da mesma forma que versionam código.
Talvez, em poucos anos, compartilhar um arquivo .spec.md seja tão comum quanto compartilhar um repositório Git.
E, sinceramente, acho que esse é um caminho muito mais sustentável para desenvolver software com IA.
Referências
- GitHub Spec Kit — https://github.com/github/spec-kit
- Spec-Driven Development — https://github.github.io/spec-kit/
- GitHub Next - https://githubnext.com/
Top comments (0)