A Dignidade da Programação Precisa Ser Reconstruída

Resumo

De ideal de Knuth à desvio da realidade, a programação degenerou de arte para lixo ao longo de 40 anos. Unix v6 tinha apenas 9.000 linhas, agora um botão leva 500 linhas—o espírito da programação está a degenerar; a tragédia do Boeing 737 Max avisa que a qualidade do código diz respeito à vida. Precisamos de voltar à essência da programação—simplicidade, clareza, elegância. Para todos os verdadeiros programadores: SLAPS não é revolução, é retorno. Retorno à estrutura, à responsabilidade, àquelas linhas de código que inicialmente amámos.

Contexto Anterior

"Documentação como Código" demonstrou a transformação revolucionária dos paradigmas de programação—de escrever cada linha à mão a usar documentos para conduzir a programação de IA. Mas quando a programação se torna tão "fácil", estamos a perder algo mais importante? É hora de falar sobre a dignidade da própria programação.

1984, Donald Knuth disse: "Os programas devem ser escritos para as pessoas lerem, e apenas incidentalmente para as máquinas executarem."

2024, a realidade é: "Os programas são escritos para eu próprio ler, melhor se os outros não conseguirem compreender."

O que perdemos em 40 anos?

É a obsessão com simplicidade, respeito pela estrutura, decência para com os pares.

De Arte a Lixo

Lembra-se do Unix v6? Todo o kernel do sistema operativo, 9.000 linhas de código. Dennis Ritchie e Ken Thompson criaram uma obra-prima que nos influencia até hoje com a expressão mais concisa.

Agora? Um evento de clique de botão pode ser escrito em 500 linhas. Não por causa da complexidade, mas porque "isto faz-me parecer profissional".

Vi demasiado código assim:

def calculate_sum(a, b):

\# Inicializar variável de resultado

result = None

\# Verificar parâmetros de entrada

if a is not None and b is not None:

\# Executar operação de adição

try:

\# Para robustez, precisamos garantir...

if isinstance(a, (int, float)) and isinstance(b, (int, float)):

\# Considerando possível overflow...

\# Deveria adicionar mais verificações aqui...

result = a + b

else:

raise TypeError("Erro de tipo de parâmetro")

except Exception as e:

\# Tratamento de erro

print(f"Erro de cálculo: {e}")

result = None

return result

Apenas para calcular adição!?

As linguagens de programação são as linguagens mais estruturadas do mundo, o caminho é supremamente simples. Mas habitualmente complicamos problemas simples, obscurecemos lógica clara, escrevemos cem linhas para o que uma linha pode resolver.

Porquê? Porque quanto mais complexo o código, mais "só eu posso mantê-lo".

De Solução a Problema Em Si

Boeing 737 Max, conhece? 346 vidas.

A investigação mostrou que uma causa importante foram problemas de qualidade de código terceirizado. Quando a programação se transforma de "resolver problemas" para "criar problemas", o desastre torna-se inevitável.

Isto não é um caso isolado. Olhe à nossa volta:

• Sistemas médicos falham porque o código é demasiado complexo, ninguém ousa mudá-lo
• Sistemas bancários falham porque a dívida histórica é demasiado pesada, não pode ser mudada
• Websites governamentais atrasam porque camada após camada de terceirização, cada camada "adicionando ingredientes"

Cada linha de código mau é um crime contra a posteridade.

Cada copiar-colar reduz a classificação de crédito desta indústria.

Cada montanha de merda é uma traição à civilização.

De Respeitado a Agricultor de Código Auto-depreciativo

"O que faz?"

"Agricultor de código."

Por trás desta auto-depreciação está a degradação da dignidade de toda uma indústria.

O termo auto-depreciativo "agricultor de código" tornou-se gradualmente o rótulo padrão da indústria. Com o tempo, até nós próprios esquecemos: o código é na verdade a forma suprema de linguagem.

Que programador da era clássica não era uma figura respeitada? Escreveram sistemas completos com memória de 64K, cada linha de código cuidadosamente considerada, cada algoritmo perseguindo elegância suprema. O seu respeito pelo código e estrutura era instintivo.

Linus Torvalds disse: "Falar é barato, mostre-me o código." Mas agora, falar está a aumentar, o código está a piorar.

Porque está isto a acontecer?

Porque todo o campo de programadores está a afundar. O limiar baixou, mas também os padrões. Ousa chamar-se programador apenas copiando e colando, pensa que é fantástico apenas chamando APIs.

Verdadeiros programadores não fariam as coisas desta forma. Eles sabem:

• Simplicidade é virtude, não preguiça
• Legibilidade é responsabilidade, não escolha
• Elegância é busca, não pretensão

Quando a Maré Baixa, Quem Está a Nadar Nu?

Agora, a IA chegou.

Quando lança requisitos à IA, o código que escreve em 10 segundos é mais claro do que aquele sobre o qual agonizou durante 3 dias. Quando ainda está a adicionar a 15ª camada de try-catch "para robustez", a IA já resolveu o problema da forma mais concisa.

SLAPS não está a tentar substituir programadores, mas a forçar a programação de volta à sua essência.

Esta é remodelação de limiar. Não manter pessoas fora da IA, mas tornar cada linha de código responsável.

Sob o SLAPS framework:

• Não pode enganar a IA—se a estrutura não for clara, não compreenderá
• Não pode empilhar montanhas de merda—se o design for irracional, a IA questionará diretamente
• Não pode ser misterioso—cada decisão precisa de raciocínio claro

Isto é "elegância forçada". Ou escreve designs claros, concisos e manuteníveis, ou a IA não o ajudará a implementá-los.

Aqueles programadores que dependem da complexidade para manter os seus empregos estão de facto condenados.

Mas isto não é mau, é a auto-purificação da indústria.

Deixar a Programação Tornar-se uma Carreira Orgulhosa Novamente

Acredito que verdadeiros programadores não temerão a IA mas abraçá-la-ão. Porque a IA transforma-os de "trabalhadores de código" de volta em "designers de sistemas".

Pense nisso:

• Não mais obcecar sobre detalhes de sintaxe, focar no design arquitetural
• Não mais reinventar rodas, focar no pensamento inovador
• Não mais cair no inferno da depuração, focar no valor de negócio

Isto é como a programação deveria ser.

Quando a programação regressa à sua essência, aqueles que não conseguem escrever código podem criar melhores sistemas. Porque não têm "maus hábitos de programador", apenas querem resolver problemas, não exibir habilidades.

Um gestor de produto proficiente em negócios pode fazer melhor com SLAPS do que um "agricultor de código" com 10 anos de experiência. Porque sabem "o que querem", não obcecam sobre "como escrever".

A Nova Dignidade da Programação

O futuro pertence àqueles que:

• Conseguem expressar claramente intenção
• Perseguem simplicidade e elegância
• Resolvem problemas reais
• Respeitam tanto código como pessoas

Futuros programadores escrevem não código mas contratos; depuram não bugs mas consenso.

Isto não é o dia do juízo final dos programadores, é o renascimento da programação.

Quando SLAPS torna cada linha de código significativa, quando a IA se torna o guardião da qualidade do código, quando "enganar" já não é possível, a programação tornar-se-á novamente um ofício respeitável.

Não precisamos de mais pessoas que escrevem código de montanha de merda, precisamos de pessoas que compreendem "porquê escrever".

Não precisamos de mais frameworks complexos, precisamos de pensamento mais claro.

Não precisamos de proteger o atraso, precisamos de abraçar o progresso.

Quando o código já não é um fosso para interesse próprio, o pensamento torna-se verdadeira competitividade.

Finalmente

Há 29 anos, digitei código linha por linha com EditPlus. Sem sugestões inteligentes, sem realce de sintaxe, mas sabia o significado de cada linha.

Hoje, quando vejo a IA escrever 1.150 linhas de código de alta qualidade em 40 minutos, não estou em pânico mas aliviado. Porque este código incorpora o que sempre persegui: estrutura clara, lógica concisa, intenção clara.

Alguns dizem que isto fará muitos programadores ficarem desempregados. Sim, como a impressão fez os escribas ficarem desempregados. Mas a impressão também criou escritores, editores, editoras. O SLAPS fará os "trabalhadores de código" desaparecer mas criará "arquitetos de protocolo de IA".

A dignidade da programação não é mantida protegendo o atraso mas reconstruída abraçando o progresso.

Deixar o código tornar-se poesia novamente, deixar os programadores tornarem-se engenheiros novamente, deixar a programação tornar-se a força que muda o mundo novamente.

O verdadeiro espírito hacker não está em truques mas em intenção.
Face à IA, a resposta mais inteligente não é resistência mas perguntar: Como posso conspirar com ela?

Isto é o que estamos a fazer.

Para todos os verdadeiros programadores: SLAPS não é revolução, é retorno. Retorno à estrutura, à responsabilidade, àquelas linhas de código que inicialmente amámos.

Junho de 2025, Lisboa

Sobre o Autor

Wang Xiao é arquiteto de protocolos de IA, autor de System and Freedom (Sistema e Liberdade), criador do Danbing AI Protocol / SLAPS Framework e iniciador do OathAI.

O seu trabalho concentra-se em co-criação humano-IA, governação de protocolos, ancoragem semântica e continuidade de conhecimento de longo prazo, explorando como o conhecimento humano e as estruturas colaborativas podem ser preservados, calibrados e herdados na era da IA.

Aviso

Este ensaio reflete observações e reflexões metodológicas atuais do autor com base em prática pessoal, investigação e experiência de colaboração humano-IA. Os métodos relacionados com Danbing / SLAPS / OathAI continuam a ser organizados e desenvolvidos. Os seus efeitos práticos podem variar conforme o contexto da tarefa, a capacidade do modelo, o ambiente de execução e o nível de compromisso.

Este ensaio não constitui aconselhamento jurídico, de investimento, médico, profissional ou garantia de implementação técnica. Leitores que apliquem estes métodos em projetos reais devem fazer julgamentos independentes de acordo com as suas próprias circunstâncias e assumir responsabilidade pelos resultados concretos.