- Uma linguagem de programação de próxima geração baseada em LLM que pode reduzir a base de código em 5 a 10 vezes
- Em vez de código, os desenvolvedores escrevem specs concisas, e o código é gerado automaticamente com o comando
codespeak build
- Quando a spec muda, o sistema converte a diferença da spec (diff) em diferença de código e a aplica
- Também oferece suporte a projetos mistos, com código escrito manualmente e código gerado, e casos reais em open source mostram melhora na taxa de aprovação dos testes
- Foca em engenharia em equipe para lidar com software complexo, buscando um ambiente de desenvolvimento mais amigável para humanos por meio de manutenção centrada em specs
Visão geral do CodeSpeak
- CodeSpeak é uma linguagem de programação de próxima geração movida por LLM que tem como objetivo reduzir a base de código em 5 a 10 vezes
- Segundo a descrição no site, a frase “Shrink your codebase 5–10x” destaca essa eficiência
- A linguagem é uma ferramenta para construir sistemas de nível de produção, projetada para projetos de longo prazo e não apenas protótipos simples
- O público principal são equipes de engenheiros que desenvolvem software complexo, com foco em desenvolvimento colaborativo, e não em programação experimental centrada em desenvolvedores individuais
Desenvolvimento baseado em specs
- O núcleo do CodeSpeak é a filosofia “Maintain Specs, Not Code”
- Em vez de código, os desenvolvedores escrevem specs concisas, e o código é gerado automaticamente com o comando
codespeak build
- Quando a spec é modificada, o sistema converte automaticamente a mudança na spec (diff) em mudança no código (diff)
- Essa abordagem enfatiza que manter e gerenciar specs é mais fácil para humanos do que manter código
Suporte a projetos mistos
- CodeSpeak oferece suporte a projetos em que código manual e código gerado coexistem
- Como exemplo, é apresentado um caso que faz fork do repositório MarkItDown da Microsoft
- Há também um guia tutorial para trabalhar com projetos mistos em etapas
Recurso de conversão de código → spec (planejado)
- O CodeSpeak está preparando um recurso que analisa código existente e o converte em specs
- Isso permitirá substituir partes do código existente por specs 5 a 10 vezes menores
- A proposta reforça que a manutenção de specs é mais amigável para humanos do que a manutenção de código
Estudos de caso reais (Case Studies)
- O CodeSpeak testou a conversão de código de vários projetos open source em specs
- Suporte a legendas WebVTT no yt-dlp: 255 LOC → 38 LOC, redução de 6,7x, 37 testes adicionados
- Gerador de SSN italiano no Faker: 165 LOC → 21 LOC, redução de 7,9x, 13 testes adicionados
- Detecção automática de encoding no beautifulsoup4: 826 LOC → 141 LOC, redução de 5,9x, 25 testes adicionados
- Conversor EML→Markdown no markitdown: 139 LOC → 14 LOC, redução de 9,9x, 27 testes adicionados
- Em cada caso, a taxa de aprovação dos testes foi mantida ou melhorada, mostrando a eficácia da abordagem baseada em specs
Resumo
- CodeSpeak é uma linguagem de programação de IA centrada em specs que combina geração automática de código com eficiência de manutenção
- Geração de código baseada em LLM, sincronização entre spec e código e suporte a projetos mistos são seus principais diferenciais
- Casos reais demonstram redução de código e melhora nos testes, apontando potencial para aumentar a produtividade da engenharia de software em equipe
4 comentários
Não sei se chamar isso de linguagem é só para gerar polêmica ou se simplesmente chegamos a uma era assim.
> Como Joel Spolsky disse em uma palestra em Yale, tentativas de “gerar programas a partir de especificações (spec)” sempre fracassaram
> Se a especificação for detalhada o suficiente para definir completamente o programa, então escrever essa especificação em si já é tão difícil quanto programar o próprio programa
Concordo com o princípio, mas também me parece óbvio que, como na prova de Gödel de que completude não existe em primeiro lugar, a crítica a essa tentativa parece partir da suposição de que existiria um produto completo.
Isso lembra MDD (Model Driven Dev.).
Comentários do Hacker News
Como Joel Spolsky disse em uma palestra em Yale, as tentativas de “gerar programas a partir de especificações (spec)” sempre fracassaram
Se a especificação for detalhada o suficiente para definir completamente o programa, então escrever essa especificação já é tão difícil quanto programar o próprio programa
Link da palestra original
Hoje já é possível gerar programas mesmo com prompts incompletos, e há valor em pesquisar formas sistemáticas de lidar com prompts
A escalabilidade está migrando de adicionar funcionalidades para definir restrições de comportamento e invariantes estruturais
Algo como “1. receber informações do usuário, 2. enviar uma requisição HTTP, 3. reportar se houver erro”,
mas, nesse caso, acho que escrever um script é muito mais rápido e determinístico
Isso não é uma nova linguagem, mas sim um workflow e um conjunto de ferramentas para desenvolvimento baseado em LLM
Em vez de código, mantém-se arquivos de especificação em Markdown, e o
codespeakmodifica o código com base no diff da especificaçãoA vantagem é que os prompts ficam versionados junto com o código; a desvantagem é que a especificação não consegue refletir todos os detalhes do código
Estão experimentando uma ferramenta chamada
codespeak takeover, que converte código em especificação e tenta refletir os prompts de sessões de agenteIsso é descrito como uma mudança do “modo sprint” de curto prazo para o “modo maratona” de longo prazo
Link para o blog relacionado
A ideia é simples demais, qualquer um pode reimplementar rapidamente, e uma versão open source deve substituir isso em breve
Sugere-se uma política para permitir “mudanças triviais”
No geral, a ideia de um compilador incremental de pseudocódigo é interessante
Daqui a 5 anos, provavelmente não escreveremos código desse jeito, e uma especificação técnica em inglês comum deve bastar
Essa abordagem é mais uma ferramenta que mapeia especificações para código do que uma linguagem
Mas os modelos são não determinísticos, então a mesma especificação pode gerar resultados diferentes a cada vez
Especificações são, por natureza, resumos com grande perda de informação, então em codebases grandes é difícil manter consistência
O que eu gostaria de ver é um pipeline verificável que vá de especificação em texto → especificação formal (formal spec) → código
O importante não é o código em si, mas a consistência do comportamento resultante
Quanto mais abstrata a especificação em relação ao código, mais implementações diferentes se tornam possíveis, então a deterministicidade continua sem garantia
Acho que testes automatizados deveriam cumprir o papel de especificação real
Com a seed fixada, seria possível obter a mesma saída para a mesma entrada
Cursor e Antigravity são otimizados para “vibe coding” centrado no humano, enquanto o Kiro é especializado em desenvolvimento baseado em especificação centrado em agentes
Ele usa formatos estruturados como EARS e INCOSE, e gera verificação automática de consistência e testes baseados em propriedades (PBT)
Se a especificação for sólida, a implementação praticamente vem junto
Estou executando vários agentes CLI em paralelo para obter resultados de alta qualidade
O problema de uma linguagem formal de prompts não é a ambiguidade, mas sim a falta de capacidade do modelo de compreender o contexto
O mesmo prompt pode produzir resultados diferentes dependendo do contexto
Formalizar o prompt não adianta se o modelo entende mal a codebase
Como os modelos são otimizados para linguagem conversacional, parece melhor usar linguagem formal só quando necessário, em vez de escrever diretamente nela
Expressa o desejo simples de poder transmitir intenções ao computador de forma determinística e formal
Esse conceito parte de uma premissa que entende mal a estrutura interna dos LLMs
Segundo pesquisas recentes, os LLMs possuem uma etapa separada de processamento entre codificação e decodificação,
e, depois do treinamento, a linguagem em si talvez nem seja tão importante
Link para a pesquisa relacionada
O objetivo é ajudar humanos a expressarem com clareza o que querem
Não sei se realmente precisamos desse tipo de ferramenta
Basta escrever a especificação em Markdown diretamente e pedir ao agente para gerar o código
No “Prerequisites” do tutorial, diz que é necessária uma chave de API da Anthropic
Pode ser apenas uma medida temporária por estar em alfa, mas fico me perguntando por que usar API é necessário
Parece que também daria para injetar prompts diretamente em uma sessão como o Claude Code
Link de referência
Achei interessante porque esse projeto é muito parecido com a especificação de linguagem para executor de LLM em que estou trabalhando
Meu projeto AIL define e executa cadeias de prompts com base em YAML
A ideia central é ter um “motor de refinamento de prompts” que converta a linguagem natural do usuário em comandos estruturados
Por exemplo, ele analisa a intenção do usuário, divide em etapas e otimiza conforme os padrões modernos de prompt engineering
Com esse tipo de interceptor, seria possível um fluxo como “transforme o que eu acabei de dizer no formato do CodeSpeak”
É uma ideia realmente muito legal, e quero explorá-la a fundo