Гідність програмування потребує відновлення

——Написано для тих, хто досі поважає код

Анотація

Від ідеалу Кнута до відхилення від реальності, за 40 років програмування з мистецтва перетворилося на сміття. Unix v6 лише 9000 рядків, зараз одна кнопка — 500 рядків, дух програмування деградує; трагедія Boeing 737 Max попереджає, що якість коду пов'язана з життям. Нам потрібно повернутися до сутності програмування — лаконічність, ясність, елегантність. Всім справжнім програмістам: SLAPS — це не революція, а повернення. Повернення до структури, до відповідальності, до тих рядків коду, які ми спочатку любили.

Контекст попередніх розділів

"Документ як код" показав революційну зміну парадигми програмування — від написання кожного рядка коду вручну до використання документів для керування програмуванням AI. Але коли програмування стає таким "легким", чи втрачаємо ми щось важливіше? Час поговорити про гідність самого програмування.

1984 року Дональд Кнут сказав: "Програми пишуться для людей, а машини їх виконують між іншим."

2024 року реальність така: "Програми пишуться для себе, краще, щоб інші не розуміли."

За 40 років що ми втратили?

Це одержимість лаконічністю, це повага до структури, це пристойність перед колегами.

Від мистецтва до сміття

Пам'ятаєте Unix v6? Все ядро операційної системи — 9000 рядків коду. Денніс Рітчі та Кен Томпсон найлаконічнішим виразом створили шедевр, що впливає досі.

А зараз? Подія кліку однієї кнопки може мати 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

Просто щоб порахувати суму!

Мова програмування — найструктурованіша мова у світі, великий шлях простий. Але ми звично ускладнюємо прості проблеми, розмиваємо чітку логіку, перетворюємо те, що можна вирішити одним рядком, на сотню.

Чому? Бо чим складніший код, тим більше "тільки я можу підтримувати".

Від рішення до самої проблеми

Boeing 737 Max, знаєте? 346 життів.

Розслідування аварії показало, що однією з важливих причин була проблема якості аутсорсингового коду. Коли програмування з "вирішення проблем" перетворюється на "створення проблем", катастрофа неминуча.

Це не поодинокий випадок. Подивіться навколо:

• Медична система падає, бо код занадто складний, ніхто не наважується змінювати
• Банківська система падає, бо історичний борг занадто важкий, змінити неможливо
• Урядовий сайт гальмує, бо шар за шаром аутсорсингу, кожен шар "додає приправи"

Кожен рядок поганого коду — це злочин проти нащадків.

Кожне копіювання-вставка знижує кредитний рейтинг галузі.

Кожна гора лайна — це зрада цивілізації.

Від поваги до самоіронії "кодера"

"Чим ти займаєшся?"

"Кодер."

За цією самоіронією — занепад гідності всієї галузі.

Самоіронічний термін "кодер" поступово став стандартним ярликом галузі, з часом навіть ми самі забули: код насправді є крайньою формою мови.

Хто з програмістів класичної епохи не був об'єктом поваги? Вони писали повні системи з 64К пам'яті, кожен рядок коду був глибоко обдуманий, кожен алгоритм прагнув граничної елегантності. Їхня повага до коду та структури була інстинктивною.

Лінус Торвальдс сказав: "Talk is cheap, show me the 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 хвилин пише 1150 рядків високоякісного коду, я не панікую, навпаки, відчуваю полегшення. Тому що цей код втілює те, чого я завжди прагнув: чітка структура, лаконічна логіка, зрозумілий намір.

Хтось каже, що це призведе до безробіття багатьох програмістів. Так, як друкарський верстат призвів до безробіття переписувачів. Але друкарський верстат також створив письменників, редакторів, видавців. SLAPS змусить зникнути "робітників коду", але створить "архітекторів протоколів AI".

Гідність програмування не підтримується захистом відсталості, а відновлюється через прийняття прогресу.

Нехай код знову стане поезією, нехай програмісти знову стануть інженерами, нехай програмування знову стане силою, що змінює світ.

Справжній дух хакера не в майстерності, а в намірі. Перед обличчям AI найрозумніше — не опір, а питання: як мені з ним співпрацювати?

Це і є те, що ми маємо робити.

────────────────────────────────────────────────

Всім справжнім програмістам: SLAPS — це не революція, а повернення. Повернення до структури, до відповідальності, до тих рядків коду, які ми спочатку любили.

Wang Xiao Червень 2025, Лісабон

────────────────────────────────────────────────

Про автора

Wang Xiao — архітектор AI-протоколів, автор System and Freedom, творець Danbing AI Protocol / SLAPS Framework та ініціатор OathAI.

Його робота зосереджена на співтворенні людини й AI, протокольному врядуванні, семантичному якоруванні та довгостроковій безперервності знання, досліджуючи, як людське знання й структури співпраці можуть зберігатися, калібруватися й успадковуватися в епоху AI.

Застереження

Це есе відображає поточні спостереження й методологічні міркування автора, засновані на особистій практиці, дослідженні та досвіді співпраці людини й AI. Методи, пов'язані з Danbing / SLAPS / OathAI, і далі впорядковуються та розвиваються. Їхні практичні ефекти можуть відрізнятися залежно від контексту завдання, можливостей моделі, середовища виконання та рівня залучення.

Це есе не є юридичною, інвестиційною, медичною, професійною чи технічною гарантією впровадження. Читачі, які застосовують ці методи в реальних проєктах, мають самостійно судити відповідно до власної ситуації й відповідати за конкретні результати.