← 목록

Pare de escrever prompts. Comece a escrever especificações.

devto 2026-07-09 원문 보기 ↗

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.

A produtividade aumentou absurdamente.

Mas um novo problema apareceu.

Depois de alguns dias de desenvolvimento, ninguém mais sabe responder perguntas simples:

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:

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:

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:

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