プログラミングの尊厳は再構築されなければならない

要約

Knuthの理想から現実の乖離まで、プログラミングは40年で芸術からゴミに堕落した。Unix v6はわずか9,000行、今やボタン一つに500行――プログラミング精神は退化している；Boeing 737 Maxの悲劇は、コード品質が生命に関わることを警告する。私たちはプログラミングの本質に戻る必要がある――簡潔、明確、優雅。すべての真のプログラマーへ：SLAPSは革命ではなく回帰だ。構造への回帰、責任への回帰、私たちが最初に愛したコードの行への回帰。

前文の文脈

「ドキュメント・アズ・コード」はプログラミングパラダイムの革命的変革を示した――すべての行を手書きすることから、文書を使ってAIプログラミングを駆動することへ。しかし、プログラミングがこれほど「簡単」になったとき、私たちはより重要な何かを失ったのか？プログラミングの尊厳そのものについて話す時が来た。

1984年、Donald Knuthは言った：「プログラムは人間が読むために書かれ、たまたま機械が実行するだけだ。」

2024年、現実は：「プログラムは自分が読むために書かれ、他人が理解できなければなお良い。」

40年で私たちは何を失ったのか？

それは簡潔さへの執着、構造への敬意、同僚への礼儀だ。

芸術からゴミへ

Unix v6を覚えているか？オペレーティングシステム全体のカーネル、9,000行のコード。Dennis RitchieとKen Thompsonは最も簡潔な表現で、今日まで私たちに影響を与える傑作を作った。

今は？ボタンクリックイベントが500行になることがある。複雑だからではなく、「これが私をプロフェッショナルに見せる」からだ。

私はこのようなコードをあまりにも多く見てきた：

def calculate_sum(a, b):
    # 結果変数を初期化
    result = None
    # 入力パラメータをチェック
    if a is not None and b is not None:
        # 加算操作を実行
        try:
            # 堅牢性のために、確認する必要がある...
            if isinstance(a, (int, float)) and isinstance(b, (int, float)):
                # 可能なオーバーフローを考慮...
                # ここでさらにチェックを追加すべき...
                result = a + b
            else:
                raise TypeError("パラメータタイプエラー")
        except Exception as e:
            # エラー処理
            print(f"計算エラー: {e}")
            result = None
    return result

ただ加算を計算するだけなのに！？

プログラミング言語は世界で最も構造化された言語であり、大道は至って簡単だ。しかし、私たちは習慣的に簡単な問題を複雑にし、明確なロジックを曖昧にし、1行で解決できることを100行で書く。

なぜか？コードが複雑であればあるほど、「私だけがメンテナンスできる」からだ。

解決策から問題そのものへ

Boeing 737 Max、知っているか？346人の命。

事故調査は、重要な原因の1つがアウトソースされたコード品質の問題だったことを示した。プログラミングが「問題を解決する」から「問題を作る」に変わるとき、災害は避けられなくなる。

これは孤立した事例ではない。私たちの周りを見てください：

• 医療システムはコードが複雑すぎて誰も変更する勇気がないためにクラッシュする
• 銀行システムは歴史的負債が重すぎて変更できないためにダウンする
• 政府のウェブサイトは何層ものアウトソーシングのために遅延し、各層が「成分を追加」する

悪いコードのすべての行は、後世への犯罪だ。

すべてのコピー＆ペーストは、この業界の信用格付けを下げる。

すべてのゴミの山は、文明への裏切りだ。

尊敬されることから自己卑下の「コード農民」へ

「何をしていますか？」

「コード農民です。」

この自己卑下の背後には、業界全体の尊厳の低下がある。

「コード農民」の自己卑下は徐々に業界のデフォルトラベルになった。時間が経つにつれ、私たち自身でさえ忘れてしまった：コードは実際には言語の究極の形だ。

古典時代のどのプログラマーも尊敬される人物ではなかったか？彼らは64Kのメモリで完全なシステムを書き、すべてのコード行を深く考慮し、すべてのアルゴリズムが究極の優雅さを追求した。コードと構造に対する彼らの敬意は本能的だった。

Linus Torvaldsは言った：「Talk is cheap, show me the code.」しかし今、talkは増え、codeは悪化している。

なぜこうなっているのか？

プログラマー分野全体が沈んでいるからだ。障壁は下がったが、基準も下がった。コピー＆ペーストするだけでプログラマーだと言い、APIを呼び出すだけで素晴らしいと思う。

真のプログラマーはこのようには働かない。彼らは知っている：

• 簡潔さは美徳であり、怠惰ではない
• 可読性は責任であり、選択ではない
• 優雅さは追求であり、見せかけではない

潮が引いたとき、誰が裸で泳いでいるか？

今、AIが到来した。

あなたが要件をAIに投げると、それが10秒で書くコードは、あなたが3日間苦労したものよりも明確だ。あなたがまだ「堅牢性のために」15層目のtry-catchを追加しているとき、AIはすでに最も簡単な方法で問題を解決している。

SLAPSはプログラマーを置き換えることではなく、プログラミングを本質に戻すことを強制する。

これは閾値の再形成だ。人々をAIから遠ざけるのではなく、すべてのコード行を説明責任のあるものにする。

SLAPSフレームワークの下で：

• AIを騙すことはできない――構造が明確でなければ、それはまったく理解しない
• ゴミの山を積むことはできない――設計が不合理なら、AIは直接質問する
• 神秘的になることはできない――すべての決定には明確な理由が必要

これは「強制的な優雅さ」だ。明確で簡潔で保守可能な設計を書くか、AIがまったく実装を手伝わないか。

複雑さで仕事を維持するプログラマーは確かに運命づけられている。

しかし、これは悪いことではない――業界の自己浄化だ。

プログラミングを再び誇りに値する職業にする

私は真のプログラマーがAIを恐れるのではなく、それを受け入れると信じている。なぜならAIは彼らを「コード労働者」から「システム設計者」に戻すからだ。

考えてみてください：

• もはや構文の詳細に苦労する必要はなく、アーキテクチャ設計に集中できる
• もはや車輪を再発明する必要はなく、革新的思考に集中できる
• もはやデバッグ地獄にいる必要はなく、ビジネス価値に集中できる

これがプログラミングのあるべき姿だ。

プログラミングが本質に戻るとき、コードを書けない人もより良いシステムを作ることができる。なぜなら彼らには「プログラマーの悪習」がなく、ただ問題を解決したいだけで、スキルを見せびらかしたいわけではないからだ。

ビジネスに精通したプロダクトマネージャーは、SLAPSで10年の経験を持つ「コード農民」よりもうまくやるかもしれない。なぜなら彼らは「何が欲しいか」を知っていて、「どう書くか」に執着しないからだ。

プログラミングの新しい尊厳

未来は次のような人々に属する：

• 意図を明確に表現できる
• 簡潔さと優雅さを追求する
• 実際の問題を解決する
• コードと人々の両方を尊重する

未来のプログラマーが書くのはコードではなく契約；デバッグするのはバグではなくコンセンサス。

これはプログラマーの終末ではなく、プログラミングの再生だ。

SLAPSがすべてのコード行を意味のあるものにし、AIがコード品質のゲートキーパーになり、「ごまかし」がもはや不可能になるとき、プログラミングは再び尊敬される工芸になる。

私たちはゴミ山のコードを書ける人をもっと必要としない、私たちは「なぜ書くか」を理解する人が必要だ。

私たちはより複雑なフレームワークを必要としない、私たちはより明確な思考が必要だ。

私たちは後進性を保護する必要はない、私たちは進歩を受け入れる必要がある。

コードがもはや私利私欲の堀ではないとき、アイデアが真の競争力になる。

最後に

29年前、私はEditPlusでコードを一行ずつ入力した。インテリジェントなヒントなし、構文ハイライトなしだが、私はすべての行の意味を知っていた。

今日、AIが40分で1,150行の高品質なコードを書くのを見たとき、私はパニックにならず、安堵を感じた。このコードは私がずっと追求してきたものを体現しているからだ：明確な構造、簡潔なロジック、明確な意図。

これが多くのプログラマーを失業させると言う人もいる。そう、印刷機が写字生を失業させたように。しかし、印刷機は作家、編集者、出版社も作った。SLAPSは「コード労働者」を消滅させるが、「AIプロトコルアーキテクト」を作る。

プログラミングの尊厳は後進性を保護することで維持されるのではなく、進歩を受け入れることで再構築される。

コードを再び詩にし、プログラマーを再びエンジニアにし、プログラミングを再び世界を変える力にしよう。

真のハッカー精神はスキルにあるのではなく、意図にある。 AIに直面して、最も賢いアプローチは抵抗ではなく問うことだ：どうやってそれと共謀すべきか？

これが私たちがしていることだ。

すべての真のプログラマーへ：SLAPSは革命ではなく回帰だ。構造への回帰、責任への回帰、私たちが最初に愛したコードの行への回帰。

2025年6月、リスボン

著者について

Wang Xiao はAIプロトコル・アーキテクトであり、System and Freedom の著者、Danbing AI Protocol / SLAPS Framework の創作者、OathAI の発起人である。

彼の仕事は、人間-AI共創、プロトコル・ガバナンス、意味的アンカリング、長期的な知識継続性を中心とし、AI時代に人間の知識と協働構造をどのように保存し、較正し、継承できるかを探っている。

免責事項

本稿は、著者の個人的実践、研究、人間-AI協働経験に基づく現時点の観察と方法論的考察である。Danbing / SLAPS / OathAI に関連する方法は、現在も整理され発展している。実際の効果は、タスクの文脈、モデル能力、実行環境、投入度によって変わり得る。

本稿は、法律、投資、医療、職業、または技術実装に関する助言や保証を構成しない。読者がこれらの方法を実際のプロジェクトに適用する場合、自身の状況に基づいて独立に判断し、具体的な結果に責任を負う必要がある。