Коли дослідник Кембриджського університету та автор «Designing Data‑Intensive Applications» Мартін Клеппман говорить про майбутнє інженерії, він постійно повертається до однієї теми: межі абстракцій. У світі, де більшість бекендів живе в керованих хмарах, а код усе частіше генерують великі мовні моделі, спокуса «не думати про нижні шари» здається природною. Але чи не втрачають команди при цьому здатність розуміти, як насправді працюють їхні системи — і що робити, коли все ламається?
Клеппман, чия книга вже дев’ять років є настільним посібником для розробників великих бекенд‑систем, у розмові в подкасті The Pragmatic Engineer окреслює нову лінію розлому: між комфортом високорівневих сервісів і необхідністю зберігати глибоку інженерну компетенцію. Ця напруга сьогодні проявляється не лише в інфраструктурі хмар, а й у тому, як ми інтегруємо LLM у розробку.
Коли абстракції корисні, а коли — небезпечні
Сучасна інженерія програмного забезпечення тримається на абстракціях. Від керованих баз даних до безсерверних платформ — усе це дозволяє командам зосередитися на бізнес‑логіці, не занурюючись у деталі реплікації, відмовостійкості чи файлових систем.
Клеппман прямо формулює питання, яке багато хто відчуває інтуїтивно: чи не зникає в інженерів мотивація розуміти нижні шари, коли все «і так працює» завдяки хмарним сервісам і фреймворкам? Якщо кожен новий проєкт стартує з готових керованих компонентів, чи буде хтось у команді здатен пояснити, що відбувається, коли ці компоненти починають поводитися нетипово?
Водночас він не романтизує «героїчну» низькорівневу інженерію. Для розробників, які будують переважно бізнес‑логіку, цілком прийнятно не думати щодня про те, як влаштовані протоколи консенсусу або внутрішні алгоритми зберігання даних. Ключова умова — в організації має існувати хтось, хто цим володіє, і структура відповідальності, яка не дозволяє цю компетенцію розмити.
Інакше зручність перетворюється на пастку: команда звикає до того, що «база сама масштабується», «черга сама відновлюється», «кластер сам перерозподіляє навантаження», але в критичний момент ніхто не розуміє, де саме проходять межі цих обіцянок.
Зручність проти контролю: не лише про продуктивність і рахунки в хмарі
Традиційно дискусія про використання керованих сервісів і високорівневих абстракцій зводилася до трьох параметрів: продуктивність, вартість і доступність. Чи варто йти в мультизону, мульти‑регіон або навіть мульти‑хмару? Скільки додаткових обчислювальних ресурсів і людських зусиль коштує підвищена відмовостійкість?
Клеппман додає до цього ще один, менш очевидний, але дедалі важливіший вимір — організаційні знання. Коли команда повністю покладається на «чорні скриньки» у вигляді керованих сервісів, вона поступово втрачає здатність діагностувати глибокі проблеми на рівні надійності.
Це не означає, що потрібно відмовлятися від хмари чи повертатися до bare metal. Але означає, що вибір між «зробити самим» і «взяти готове» — це не лише про те, скільки коштуватиме інстанс чи скільки мілісекунд додасться до латентності. Це ще й про те, чи залишиться в компанії хтось, хто розуміє, як поводиться система під час часткових відмов, нетипових навантажень або ланцюгових збоїв.
Коли виникає складний інцидент, саме цей прошарок знань визначає, чи зможе команда вийти за межі поверхневих метрик і дашбордів, зрозуміти кореневу причину і запобігти повторенню. Якщо ж усе тримається на припущенні, що «постачальник усе зробить правильно», організація втрачає не лише контроль, а й здатність навчатися на власних помилках.
LLM не скасовують системне мислення — вони підвищують ставки
Поява великих мовних моделей додає до цієї картини ще один рівень абстракції. Тепер інженер може не просто викликати керований сервіс, а й доручити моделі написати значну частину коду, який цей сервіс використовує. Здається, що це ще один крок до світу, де «деталі не мають значення».
Клеппман пропонує протилежний погляд: LLM роблять формальне міркування про коректність систем важливішим, а не менш важливим. Якщо код створюється «у великих обсягах» напівавтоматично, зростає ризик появи тонких, малопомітних помилок, які не виявляються простим тестуванням.
Мовні моделі добре відтворюють шаблони, але не мають вбудованого розуміння інваріантів системи, гарантій узгодженості чи властивостей відмовостійкості. Вони можуть згенерувати код, який виглядає правдоподібно, проходить базові тести, але порушує критичні припущення про поведінку розподіленої системи в рідкісних, але неминучих сценаріях.
У такому середовищі глибоке розуміння нижніх шарів стає не опцією для «ентузіастів системного програмування», а необхідною противагою. Хтось має вміти поставити правильні запитання до згенерованого коду: які тут інваріанти? Що станеться при частковій втраті мережі? Чи можливі гонки? Чи зберігається узгодженість даних при повторних спробах?
Без цього LLM перетворюються на прискорювач не лише продуктивності, а й технічного боргу.
Формальна верифікація як відповідь на зростаючу складність
Клеппман пов’язує зростання складності розподілених систем і хмарної інфраструктури з дедалі більшою потребою у формальних методах. Якщо раніше формальна верифікація часто сприймалася як академічна розкіш, то в епоху AI‑асистованої розробки вона починає виглядати як практичний інструмент безпеки.
Аргумент простий: коли код генерується швидко і в великих обсягах, традиційні механізми контролю якості — рев’ю, тестування, інтеграційні тести — не завжди встигають за темпом змін. Особливо це стосується розподілених протоколів, механізмів реплікації, складних схем кешування і всього, що пов’язано з узгодженістю та відмовостійкістю.
Формальні методи — від специфікацій до машинно перевірюваних доказів — дозволяють зафіксувати очікувану поведінку системи в термінах властивостей, а не лише реалізацій. У поєднанні з LLM це відкриває цікаву, хоча й непросту перспективу: моделі можуть допомагати писати код, але коректність цього коду має перевірятися інструментами, які не покладаються на статистичні припущення.
Клеппман підкреслює, що LLM не зменшують потребу в таких підходах, а навпаки, підсилюють її. Коли людина пише код повільніше, вона, принаймні теоретично, має більше шансів помітити логічні суперечності. Коли ж код з’являється за секунди, єдиний реалістичний спосіб утримати якість — підняти рівень формальності в описі того, що система «має робити» і «ніколи не повинна робити».
Це особливо актуально для інфраструктури, яка підтримує AI‑навантаження: від векторних індексів до розподілених сховищ, що обслуговують моделі. Помилки в цих шарах можуть проявлятися не як очевидні падіння, а як тонкі зсуви в якості результатів, які важко відстежити без чітко сформульованих властивостей системи.
Від MapReduce до векторних індексів: абстракції змінюються, фундаментальні питання — ні
Друга, суттєво оновлена редакція «Designing Data‑Intensive Applications», що вийшла приблизно через дев’ять років після першої, сама по собі є відображенням зміни абстракцій. Клеппман спільно з Крісом Ріккоміні прибрав із книги розділи про MapReduce, який він безапеляційно називає мертвим: «ніхто більше цим не користується». Натомість з’явилися розширені розділи про системи, що підтримують AI‑навантаження, зокрема про векторні індекси.
Це показовий зсув. Колись MapReduce був головною абстракцією для обробки великих обсягів даних. Сьогодні його місце займають інші моделі й сервіси, а векторні індекси стають базовим будівельним блоком для пошуку по ембедінгах і семантичного пошуку в AI‑системах.
Але попри зміну інструментів, фундаментальні питання залишаються тими самими. Як система поводиться при часткових збоях? Які гарантії узгодженості вона дає? Як вона масштабується між зонами доступності, регіонами, хмарами? Які інваріанти мають зберігатися, щоб результати були коректними, а не лише «достатньо хорошими»?
Саме тут і проявляється головна думка Клеппмана: абстракції можуть змінюватися, але потреба в глибокому розумінні нижніх шарів нікуди не зникає. Вона лише змінює форму — від MapReduce до векторних індексів, від ручного коду до LLM‑генерації, від локальних дата‑центрів до мульти‑регіональних хмар.
Хто має «володіти» глибиною: нова роль системних інженерів
Якщо прийняти, що не кожен розробник має бути експертом із розподілених систем, постає питання: хто тоді відповідає за те, щоб у компанії зберігалося це знання?
Клеппман фактично описує модель, у якій існує чіткий розподіл ролей. Є інженери, які працюють переважно з бізнес‑логікою і можуть спиратися на високорівневі абстракції, не занурюючись у деталі. І є ті, хто відповідає за інфраструктуру, формалізацію інваріантів, вибір між мультизоною, мульти‑регіоном чи мульти‑хмарою, за розуміння компромісів між доступністю, затримками, вартістю і складністю експлуатації.
У такій моделі ключовим стає не те, щоб «усі знали все», а те, щоб організація як ціле не втрачала здатності мислити на нижчих рівнях. Це означає інвестувати в людей, які можуть читати й писати формальні специфікації, розуміють протоколи, здатні моделювати відмови й аналізувати рідкісні, але критичні сценарії.
LLM у цьому контексті можуть стати корисним інструментом, але не заміною. Вони можуть допомагати з рутинними завданнями, генерацією шаблонів, навіть із початковими варіантами специфікацій. Але остаточне розуміння того, що система робить і чому вона поводиться саме так у граничних випадках, залишається за людьми, які володіють нижніми шарами.
Висновок: абстракції — це не втеча від складності, а спосіб її організувати
Сучасна інженерія немислима без абстракцій. Вони дозволяють будувати складні системи швидше, безпечніше й дешевше, ніж будь‑коли раніше. Але абстракції не скасовують складність — вони лише приховують її за зручними інтерфейсами.
Мартін Клеппман пропонує дивитися на це тверезо. Для більшості розробників нормально не знати деталей кожного протоколу чи алгоритму. Ненормально — коли в організації взагалі немає людей, які ці деталі розуміють, а критичні рішення приймаються на основі маркетингових обіцянок і поверхневих метрик.
У світі, де LLM можуть генерувати код швидше, ніж ми встигаємо його осмислити, а хмарні провайдери пропонують усе нові рівні «керованості», питання не в тому, щоб відмовитися від абстракцій. Питання в тому, щоб не втратити здатність ставити до них правильні запитання — і мати в команді тих, хто здатен на них відповісти.
Джерело
Повна розмова: Designing Data-intensive Applications with Martin Kleppmann — The Pragmatic Engineer