#ai #architecture #longread

🧠 ШІ не замінить розробників. Але змінить те, за що їм платять.
Сьогодні в розмові з колегою сформулював думку, яка вже певний час крутилася в голові і, здається, досить точно описує те, що зараз відбувається з нашою професією.

ШІ не прибирає складність системи, але суттєво спрощує її реалізацію.

Сильний інженер із ШІ вже сьогодні здатен самостійно реалізувати те, для чого раніше знадобилася б ціла команда.

Але тут виникає цікавий парадокс: що краще ШІ вміє писати код, то ціннішими стають інженери та архітектори, які розуміють, що саме він пише і які наслідки це матиме.

Адже написати код і спроєктувати систему — це зовсім різні компетенції.
ШІ може за хвилини згенерувати тисячі рядків коду, реалізувати API, написати тести, налаштувати інтеграції.
Але хто визначить межі відповідальності компонентів?
Хто вирішить, де потрібна абстракція, а де вона лише ускладнить систему?
Хто забезпечить слабку зв'язаність, розширюваність і можливість змінювати поведінку без переписування половини проєкту?
І найголовніше — хто зрозуміє, що запропоноване рішення взагалі неправильне, навіть якщо воно чудово працює?

Нещодавно натрапив на цікаві думки кількох відомих інженерів та архітекторів програмного забезпечення.
Unmesh Joshi у дискусії LLMs and the what/how loop за участю Martin Fowler та Rebecca Parsons висловлює думку:
«Головний виклик розробки програмного забезпечення — створювати системи, здатні переживати зміни».

Martin Fowler у тій самій дискусії наголошує:
«Щоб спростити внесення змін, нам потрібно керувати когнітивним навантаженням».

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

А дядько Боб (Robert C. Martin) пішов ще далі.
У розмові про інженерію в епоху ШІ він розповідає, що дедалі менше читає згенерований агентами код, натомість контролює результат через архітектурні обмеження, статичний аналіз, тести та перевірки залежностей.

Фактично він переходить від контролю кожного рядка до контролю властивостей системи.

І ось тут, на мою думку, ми підходимо до найцікавішого.

Раніше значна частина цінності розробника полягала у здатності реалізувати рішення. Тепер сама реалізація поступово стає дешевшою, але вартість помилкового рішення нікуди не зникає. Навпаки, ШІ дозволяє масштабувати не лише правильні рішення, а й помилки.

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

Тому я не вірю, що майбутнє розробки за людьми, які просто навчилися правильно формулювати промпти.
Воно за інженерами, які розуміють принципи проєктування, вміють декомпозувати складні системи, визначати контракти, контролювати залежності та перевіряти не лише працездатність, а й якість рішень.

ШІ може зробити сильного інженера значно продуктивнішим. Але він не перетворює автоматично слабкого інженера на сильного.

І наостанок висновок, який я сформулював на базі тієї думки:
Можливо, найбільша іронія нашої епохи в тому, що фундаментальні принципи проєктування стають ціннішими саме тоді, коли писати код стає дедалі менш необхідно.

Бо відповідальність за систему все одно залишається за інженером.