Штучний інтелект — це підсилювач, а не напрямок.

Автор статті, джерело: InfoQ

Штучний інтелект дозволяє писати код у 10 разів швидше, а потім? Більше коду означає довші компіляції, більш важкі тести, забиті рев’ю коду та кодову базу, яку ніхто не розуміє. Програмне забезпечення — це борг: чим швидше ви пишете, тим більше боргу накопичуєте.

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

На ключовій промові Google I/O 2026 Адам Бендер поставив питання, якого більшість ще не встигли обдумати: коли ШІ підніме швидкість генерації коду до рівня, який не зможе витримати існуючі інженерні процеси, що впаде першим у нашій екосистемі розробників? Він об’єднав усю промову концепцією, яку, можливо, ви ще не чули: програмна екологія — це дисципліна, що вивчає соціотехнічну екосистему виробництва програмного забезпечення як єдине ціле. Іншими словами, вам потрібно не лише дивитися на технології, а й на людей, культуру та неформальні правила всередині організацій. На основі відео цієї промови InfoQ структурував матеріал.

Основні ідеї такі:

• Штучний інтелект за замовчуванням не вирішує за вас жодних проблем. Якщо ваша практика добра, він її посилює. Але якщо вона недостатньо добра, він лише створює більше проблем.
• Те, що кожен є будівельником, дуже круто, поки тобі не доведеться підтримувати все, що всі побудували.
• Інженерна практика не є священною і незмінною. Практика змінюється, а принципи мають вирішальне значення.
• Як інженер-програміст на передовій, у цей критичний момент ви знаходитесь у центрі, що визначає, куди рухатиметься програмна інженерія. Від інструментів до робочих процесів, від інженерних практик до інженерної культури — якщо ви зможете розуміти системи, що працюють, ви знайдете важелі.

Що таке «система»

Ваша робота у 2026 році повністю відрізняється від того, як ви уявляли її у 2020 році. Якби я намагався пояснити тому 2020-річному мені, що відбувається сьогодні, я б не вірив. Змін багато — занадто багато, щоб з ними впоратися. Я не можу передбачити майбутнє, але вірю, що якщо уважно дослідити сьогоднішню екосистему програмного забезпечення, деякі відповіді ближчі, ніж ми думаємо.

Сьогодні я хочу поговорити з вами про одне слово: програмна екологія (Software Ecology). Звучить як те, що я вигадав на ходу, щоб вийти на сцену, але ні — це справжній термін. Перш ніж дати визначення, я хочу підготувати контекст і трохи глибше зануритися в системне мислення.

Система — це сукупність взаємопов’язаних елементів, які функціонують за певними правилами, утворюючи єдине ціле. Звучить абстрактно, але ви не є незнайомими з системами. Наприклад, кондиціонер: термостат, який знає бажану температуру, система опалення, вентиляції та кондиціонування, яка нагріває або охолоджує, кімната — і коли температура досягає потрібного рівня, сигнал зупиняється. Ось і система.

Якщо ви інженер-програміст, ви щодня працюєте з системами: проектуєте їх, створюєте та підтримуєте, і в цьому процесі ви, швидше за все, засвоїли один важливий урок: все взаємопов’язано.

Наступним є екосистема — це спеціальна система. Визначення трохи довге, але важливе: екосистема — це динамічна мережа взаємозалежних учасників, які разом із середовищем еволюціонують, що характеризується виникненням поведінки та децентралізованою автономністю. Простими словами: екосистема дуже складна, її компоненти глибоко пов’язані між собою, кожен компонент має власну автономність, здатний приймати рішення та діяти. І найважливіше: середовище є частиною системи, і ви не можете розділити їх.

Екосистема також є складною адаптивною системою, яка може зростати, змінюватися та еволюціонувати з часом. Вони також мають властивість, яка називається емерджентністю (Emergent Property) — це те, чого неможливо побачити, спостерігаючи окремі компоненти; поведінка виникає лише тоді, коли система цілком зібрана. Саме ця постійна зміна, постійне навчання та емерджентність роблять надзвичайно складним розуміння того, що саме відбувається в екосистемі.

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

Ви, ймовірно, вже стикалися з інтелектом соціотехнічних систем, не усвідомлюючи цього. Ви знаєте закон Конвей: технології, які створюють організації, відображають їхні внутрішні структури комунікацій. Простіше кажучи, якщо над одним компілятором працюють чотири команди, ви отримаєте чотирипрохідний компілятор — ось і все. Основне спостереження закону Конвей полягає в тому, що спосіб створення технологій нерозривно пов’язаний з організаційною структурою, яка її створює: саме організація формуюче те, що в кінцевому підсумку буде побудовано.

Але не лише структура впливає на екосистему розробників — цінності та культура також мають глибокий вплив. Екосистема, яку ви будуєте, — це те, що мотивує організація; ваша інженерна культура створює середовище навколо екосистеми розробників. Коли ви розумієте соціотехнічні системи, ви побачите їх у кожному кутку розробки програмного забезпечення: архітектура, культура аналізу інцидентів, перевірка коду, стратегії безпеки — вони повсюди. Те, що ми будуємо, та спосіб, яким ми обираємо будувати це, відображає те, що ми цінуємо. Якщо ми будемо достатньо уважними, можемо використати це розуміння, щоб посилити наші цінності та втілити їх у те, що ми створюємо.

Зараз я можу дати вам правильне визначення: програмна екологія — це дисципліна, що вивчає соціотехнічні екосистеми виробництва програмного забезпечення в цілому. Якщо попереднє звучало трохи абстрактно — не хвилюйтеся, тепер розглянемо реальний приклад.

Екосистема розробників Google

Я згадую Google, не тому що працюю там і хочу його хвалити, а тому що це екосистема розробників, яку я найкраще знаю. Моя мета — не казати вам, що ви повинні копіювати Google, бо це не принесе вам користі. Ви — інша компанія, на іншому етапі, з іншими компромісами. Багато рішень, які прийняв Google, були зумовлені конкретними потребами, які ми мали на той час, коли будували свою екосистему.

Кілька років тому ми написали книгу, яка в внутрішніх колах називалася «Книгою фламінго». У ній половина присвячена системам контролю версій і тестуванню, але вся перша частина розповідає про інженерну культуру. Багато людей питали, чому ми виділили стільки сторінок культурі — тому що, якщо ви не розумієте культуру Google, ви не зможете зрозуміти, чому ми зробили саме такі технічні рішення; це все взаємопов’язано.

У Google є кілька унікальних культурних рис. Ми глибоко орієнтовані на інженерію, і інженери завжди присутні при прийнятті важливих рішень; ми надзвичайно цінуємо прозорість, намагаючись зробити всі документи та код доступними для всіх; ми заохочуємо допомогу іншим — насправді, будь-хто, хто колись залишив Google, першим згадає про допомогливість колег; ми сприймаємо рев’ю коду як можливість для наставництва, а не як перевірку контрольних робіт; ми надзвичайно цінуємо стандартизацію; ми віримо у постійне вдосконалення; ми підтримуємо рев’ю інцидентів без покарання; ми віримо, що стійкість важливіша за героїзм, а автоматизація — краща за ручну працю. Звичайно, ми не завжди досягаємо всіх цих ідеалів, але це напрямок, до якого ми прагнемо в нашій культурі.

Щодо технічної сторони? Єдине сховище коду, де майже весь код знаходиться в одному репозиторії; розробка на основі головної гілки, де кожна зміна безпосередньо об’єднується з головною гілкою; під час збирання бінарного файлу майже кожен рядок коду компілюється з вихідного коду; єдина інструментальна ланцюжок збирання, якою користуються всі; глобальна платформа автоматизованого тестування, де всі тести запускаються в одному місці, щодня — мільярди тестових випадків; єдиний глобальний сигнал «останній зелений», за допомогою простого внутрішнього сайту я можу сказати вам стан будь-якого збирання; єдина обчислювальна середовище, тому ситуації типу «у мене на машині працює» практично неможливі; високо стандартизовані фреймворки для розробників та невелика група основних мов програмування.

Ця змішана культура та технологія сформували Google таким, яким він є сьогодні — ви не можете зрозуміти лише одну частину, ігноруючи іншу.

Поділена доля

Якщо б мені треба було вибрати принцип, що постійно незамітно керує нами, я б вибрав «Спільна доля (Shared Fate)». Він описує ступінь тісного зв’язку між екосистемою та її компонентами: у високоступеневій екосистемі зі спільною долею один компонент може впливати на всі інші. У розробницькій екосистемі спільна доля — це як технічний, так і соціальний вибір. Ви не можете досягти спільної долі лише шляхом того, щоб усі використовували однакові технології — вам також потрібно створити соціальний договір щодо того, як керувати цими технологіями.

У Google спільна доля починається з єдиного сховища коду. Кожен рядок коду компанії, за винятком декількох винятків, таких як Android і Chrome, знаходиться в одному спільному сховищі. Усі зміни надходять безпосередньо в головну гілку, без розгалужень і версій — все зберігається в одному місці. Ця спільна доля дозволяє нам застосувати безпековий патч у одному файлі і бути впевненими, що протягом тижня всі програми компанії будуть виправлені. Виправлення десяти рядків коду для мільярдів рядків програмного забезпечення та систем — це наче суперздатність.

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

Масштабні зміни

Однією з найцікавіших виникаючих властивостей у нашому середовищі спільної долі є масштабні зміни. Зверніть увагу: ще до появи ШІ внутрішні інструменти Google дозволяли розробнику змінювати мільйони рядків коду — мільйони рядків, яких вони ніколи не читатимуть, ніколи більше не побачать і, можливо, взагалі не знають. Ми створили інструменти, які зробили це автоматичним, і сьогодні це саме так, і ми робимо це щонайменше останні п’ятнадцять років.

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

Але ключове те, що ви не зможете справді зрозуміти це, якщо не розумітимете культурні та технічні компоненти, які роблять масштабні зміни можливими. Що вам потрібно? Поширена культура тестування, де кожен пише тести. Єдина платформа тестування, де ви знаєте, де отримати результати. Спільні інструменти збирання, щоб ваша збірка давала той самий результат, що й моя. Стандартизовані бібліотеки, щоб під час заміни компонентів вам не доводилося стрибати з версії на версію, шукаючи ту, що підходить вам, а не мені. Стандартизоване рев’ю коду та прозорість сховища коду, щоб ви знали, який код треба змінити. Масштабні зміни — це найбільш повна реалізація ідеї Google «автоматизація переважає над ручною працею», і вони можливі лише за умови співпраці всього екосистеми. Ви не можете вказати на одну частину розробницького середовища і сказати: «ось чому це відбувається» — причина в тому, що всі частини з’єднані разом.

Ваша екосистема, ваші компроміси

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

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

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

10-кратний момент: кожен вузол під тиском

Час обговорити слона в кімнаті, який їсть токени: як виглядає екосистема розробників з пріоритетом на ІІ?

Звичайно, побудова абсолютно нової екосистеми з нуля — це чудово, але ніхто з вас не має такої можливості. Ви повинні продовжувати розробляти програмне забезпечення, одночасно замінюючи майже кожну його частину. Компанія очікує, що ви будете продовжувати створювати цінність, одночасно забезпечуючи відсутність проблем.

Тож задайте собі питання: наскільки добре ви розумієте сьогоднішню екосистему розробників? Чи здатні ви повністю її намалювати? Чи знаєте ви, де знаходяться всі компоненти — не лише технічні, а й соціальні? Чи можете ви перелічити, з чого складається ваша екосистема? Наскільки добре це розуміють інші в вашій організації? Які її переваги та недоліки? Де знаходяться обмеження? Де є обмеження, а де — свобода? Які у вас є варіанти вибору? Які виникаючі властивості ви спостерігали? Можливо, найважливіше: якщо ваша екосистема раптово зобов’язана буде обробляти за наступні 18 місяців у 10–15 разів більше коду, то що, на вашу думку, зламається першим?

Кожна екосистема розробників на Землі переживає глибоку трансформацію, можливо, вона ще не дійшла до кожного куточка, де ви знаходитесь, але вона вже на шляху — кожна екосистема розробників змушена буде зіткнутися з цим моментом зростання в 10 разів. Це неймовірна епоха, але й досить заплутана. Усі компроміси, які ми цілеспрямовано розвивали протягом останніх двадцяти п’яти років, будуть перебалансовані.

Швидке генерування коду в 10 разів та швидке інженерне розроблення — це дві різні речі. У Google ми часто кажемо, що інженерія — це програмування, інтегроване з часом. Але проблема в тому, що ми значно прискорюємо саме етап програмування, прискорюючи роботу кодової машини. Тож ми повинні знайти спосіб добре організувати інженерну роботу навколо цієї кодової машини, щоб справді доставити результат клієнтам. Ніхто не знає, наскільки далеко цей стрибок продуктивності зможе знести нас, але одне відомо напевно: ми починаємо рухатися вгору.

Проблема в тому, що спосіб, яким ми сьогодні розробляємо та доставляємо програмне забезпечення, не працюватиме при швидкості в 10 або 100 разів — щось має змінитися.

Давайте розпочнемо зі спрощеної діаграми екосистеми розробників. Що має змінитися у світі, де активність збільшилася в 10 разів?

Код надійшов до сховища

Пишіть вихідний код. Якщо кожен буде писати код у десять разів швидше, обсяг коду зросте у десять разів — і це не добре. Джефф Атвуд сказав, що програмне забезпечення — це борг. Тож 10-кратний код — це 10-кратний борг. І ви не можете просто роздати кожному токени й сказати: «Щасливо!» Я хочу, щоб ви інвестували після навчання: ви знаєте, де знаходяться ваші документи з інженерних практик? Знаєте, як їх розвивати? Про це можна подумати пізніше.

Побудова системи. Більше коду, більші системи — довший час компіляції. Я впевнений, що зараз ніхто в вашій компанії не скаржиться на повільну компіляцію. Але вгадайте що? Вони стануть ще повільнішими. І якщо агент керує величезним обсягом роботи, кількість компіляцій стрімко зростає. Компіляція — це не безкоштовно, ні за час, ні за обчислювальні ресурси. Ви, можливо, ніколи не звертали уваги, скільки часу витрачаєте на компіляцію, але при масштабі в 10 разів ви це обов’язково помітите.

Дизайн коду. Чи маєте ви відповідні навички агента, щоб сприяти роз’єднанню? Чи є у вас відповідний серверний фреймворк, щоб забезпечити швидке та безпечне поєднання різних можливостей? Чи знаєте ви, скільки способів розгортання веб-додатків використовується в вашій компанії? Скільки різних серверних фреймворків працює одночасно? Як ви керуєте повторним використанням компонентів, написаних агентом? Можливо, ви гадаєте, що це не має значення. Але якщо агент написав код, який легко писати, але важко підтримувати, не дивуйтесь — це поточний рівень стандарту. Агенти добре пишуть код, але не завжди думають про довгострокові наслідки. Цей код, я певен, не буде добре рефакторитися. Не проблема — цю частину ми вирішимо пізніше. Але справа в тому, що агенти виконують для нас величезний обсяг роботи, і ми щодня повинні знаходити найефективніші способи використання цих здібностей.

В певний момент ці агентні завдання можуть зробити ваші бінарні файли занадто великими, щоб їх можна було скомпілювати. Або занадто великими, щоб їх можна було завантажити на телефон. Ви коли-небудь запитували себе: який найбільший бінарний файл, який я можу скомпілювати? Я не знаю відповіді, але знаю, що в Google ми вже дотикаємося до меж — деякі бінарні файли вже настільки великі, що їх неможливо скомпілювати, і я впевнений, що ми це вирішимо. Але справа в тому, що масштаб має багато наслідків — вплив масштабу поширюється скрізь.

Можливо, ви працюєте зі стеком мікросервісів і думаєте: «Мої сервіси дуже маленькі, чому мені хвилюватися?» Але у мене є питання: 10-кратний обсяг мережевого трафіку, 10-кратна кількість сервісів, 10-кратний обсяг комунікацій — чи ви до цього готові? Ніхто не залишиться незатягненим — вплив масштабу повсюдний.

Ревізія коду. Припустімо, ви не можете надійно скомпілювати весь цей код, яким буде ваш процес ревізії коду? Усі стурбовані ревізією коду — із певною причиною. Ми нав’язуємо цьому дуже людському процесу величезний тиск, і в багатьох випадках він перетворюється на узький місце, а людям не подобається бути узьким місцем. Коли ви створюєте тиск, їхня поведінка стає дивною. У 10 разів більше коду — ви отримуєте або 10 разів більші зміни, або 10 разів більше змін. Чи зможе ваш технічний керівник підтримувати необхідну швидкість ревізії? Більшість технічних керівників не можуть навіть пройти через добовий обсяг коду п’яти 10-кратних розробників.

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

Економіка токенів. Токени дорогі, і деякі з вас це вже знають. У масштабі токени — це реальна витрата, яку потрібно враховувати. Що станеться, якщо кожен у компанії почне використовувати токени в 10 або 100 разів більше? Що, якщо ви випадково витратите весь місячний бюджет за один день? Якщо вам потрібно вирішити, куди вкладати токени перш за все, чи знаєте ви, куди варто інвестувати першим? Чи маєте ви взагалі видимість того, куди саме плинуть токени?

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

Тестування та контроль версій

Ви коли-небудь стежили, скільки обчислювальних ресурсів споживає ваша тестова інфраструктура? У Google я ніколи не був задоволений швидкістю своїх тестів.

Кожна зміна, що потрапляє до системи контролю версій, повинна бути протестована. Але крім цього, агенти також люблять запускати тести, бо тести показують їм, наскільки добре вони впоралися. Тому агенти створюють додатковий обсяг роботи, і мені доводиться робити більше. Отже, 10-кратне збільшення кількості комітів плюс уся робота, виконана агентами, зараз споживає скільки обчислювальних ресурсів для тестування?

Насправді ситуація може бути гіршою. Ми спостерігали в Google, що зі зростанням кодової бази граф залежностей зростає квадратично, а не лінійно. Тож, якщо кодова база збільшилася в 10 разів, кількість тестів, які вам потрібно запустити, може зростати не в 10, а в 100 або навіть 1000 разів. Це буде дуже цікавий виклик, і в певний момент це перетвориться на рядок у вашому бюджеті. Якщо зараз ви не турбуєтесь про витрати на обчислювальні ресурси для тестування, це мене турбує більше, бо це означає, що, ймовірно, у вас взагалі недостатньо тестів, і агенти працюють у вашій кодовій базі без безпечної мережі.

Припустимо, що проблеми з компіляцією та тестуванням вирішені, тепер розглянемо систему контролю версій. Більшість популярних систем контролю версій не оптимізовані для продуктивності — вони оптимізовані для консистентності та порядку. Це їхнє основне завдання — зберігати повну історію, а не працювати з максимальною швидкістю. Скільки комітів за хвилину може обробити ваша система контролю версій? Я гарантую, що значно менше, ніж ви уявляєте. Вона не масштабується до швидкості, яку вам потрібно — у 10 разів вище. Коли ви востаннє думали про продуктивність системи контролю версій? Якщо ви не розробляєте Git, то, ймовірно, ніколи. Чесно кажучи, якщо ви змушені обговорювати продуктивність системи контролю версій, це означає, що щось серйозно пішло не так. Ми на самому дні користувацького досвіду розробників, але ось наслідок системних змін: вони знаходять кожен куток вашої системи і кажуть: «Ей, ти звертаєш увагу?» — бо прийшла річ, яку ви не передбачили.

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

Список неочікуваних подій

До цього моменту ми розглядали лише ті відносно легко виявляні ємнісні вузли, де береться число і множиться на 10, а потім запитується, чи буде краще чи гірше, а також багато неочікуваних викликів.

Перевірка стратегії. Сьогодні ваша перевірка, швидше за все, складається з багатьох юніт-тестів та деяких інтеграційних тестів. Але у світі з 10-кратним кодом та 10-кратними сервісами інтеграційні тести стануть найважливішою частиною стратегії якості. Скільки з вас задоволені своєю поточною схемою інтеграційних тестів? Я теж не задоволений. Інтеграційні тести дуже складні, і зараз у мене немає інструментів, які дозволили б мені робити інтеграційні тести так, як я хочу.

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

Надзвичайно велика зміна. Звичайно, захопливо перебудовувати все, міняти мови та фреймворки. Але чи маєте ви робочі процеси та соціальні угоди, які дозволяють людям керувати конфліктами злиття з десятками тисяч, сотнями тисяч, мільйонами рядків? Мабуть, ні. Якщо кожен у компанії зможе вносити надзвичайно великі зміни, нам знадобляться нові стратегії робочих процесів.

Війна агентів. Один агент вносить зміни, інший агент прибігає і каже: «Ні, мені це не подобається, я зроблю іншу зміну». Це виглядає смішно, поки ти не усвідомлюєш, що платиш токени за обидві сторони.

Ритм випуску. Скільки разів на день ви випускаєте оновлення для клієнтів? Щодня? Це досить добре. Якщо ні, то ось проблема: ви отримаєте в 10 разів більше програмного забезпечення, яке все ж потрібно кудись дістати. Якщо ви не випускаєте щодня, кожна зміна стає набагато більшою. Мої друзі з SRE скажуть вам, що дуже великі зміни — це жахливо. Не робіть цього. Але код все ж потрібно розгортати, щоб він мав цінність, тому ви можете намагатися випускати частіше — це добре, і друзі DORA будуть задоволені. Але на певному етапі вигода починає зменшуватися: випуск раз на секунду, швидше за все, не принесе вам значної користі. Код все одно зростатиме, і вам потрібно зрозуміти, куди його розмістити, щоб не створювати більше ризиків.

Внутрішній API. Я постійно кажу своїм колегам: ваші всі API раптово стали публічними. Агент не буде з вами консультуватися — він знайде API і викличе його безпосередньо. Він використає все, до чого має доступ — я це гарантуємо. Якщо ви ніколи не захищали внутрішні інтерфейси та внутрішні набори даних так, як публічні API, агент знайде те, чого ви не бажаєте, щоб він знайшов.

Парадокс Джевонса. Джевонс стверджував, що чим дешевшим та ефективнішим є ресурс, тим більше ми його використовуємо. Вибух токенів — це живий приклад. Ми впроваджуємо їх увесь час, що змінює те, як ми працюємо і як ми мислимо про працю. Ми починаємо цінувати раніше невидиму продуктивну працю — як це вплине на нашу поведінку? Я ще не знаю.

Відкат. Ви знаєте, чому відкат сьогодні в основному здійсненний? Тому що ви випускаєте програмне забезпечення трохи повільніше, ніж потрібно для виявлення проблем у виробничому середовищі. Якби ви могли випускати настільки швидко, що не змогли б виявити жодних проблем, яким був би ваш підхід до відкату? Кожен відкат мав би мати справу з купою взаємно суперечливих змін, накопичених зверху. Тож просто швидше випускати — цього недостатньо; ви повинні розглядати всю систему, включаючи відкат як важливий аварійний клапан. До речі, вам слід обережно вибирати, де розміщувати токен-движок. Якщо ваш процес відкату залежить від агента, який має достатньо токенів, а хтось раніше вичерпав бюджет токенів цього агента, що зараз перешкоджає вам виконати відкат — це, мабуть, не дуже добре.

Кожен є будівником. Ви, напевно, думали про створення альтернативи інструменту, який вам не подобається в компанії. Тепер помножте це на кожного співробітника та кожен інструмент. Що відбувається з соціальною структурою компанії, коли кожен використовує абсолютно різні інструменти? Якщо вам пощастило мати єдину базу даних, де вся інформація збирається в одному місці, то все добре. Але якщо ні? Те, що кожен є будівником — це круто, поки вам не доведеться підтримувати все, що всі побудували.

Інтенсивний курс з технічного лідерства. На те, щоб стати технічним лідером, потрібно стільки часу, бо треба накопичити інтуїцію, здатність до судження та професійні навички, щоб приймати рішення, бо коли ви керуєте командою, ваші помилки мають набагато більші наслідки, ніж коли ви дієте самотужки. Що піде не так, коли новачок потрапляє в середовище, де можна викликати п’ятдесят агентів, але не має жодної інтуїції чи здатності до судження? Як я можу навчити за шість місяців того, що вимагає десяти років досвіду? Я не знаю.

Увага людини — це найцінніший ресурс, який у нас є. Зараз шуму дуже багато, багато агентів і багато речей борються за нашу увагу, і ми повинні знайти спосіб керувати цим. Раніше ми користувалися тим, що наша здатність створювати проблеми не перевищувала нашої здатності вкладати увагу, але зараз це вже не так.

Це звучить багато, тому що в системі все взаємопов’язано. Всі виклики, про які я згадав раніше, неможливо вирішити, дивлячись лише на один вузол системи — ви повинні розглядати всю систему.

Щоб адаптуватися до розробки агентів, ми всі повинні навчитися системно мислити постійно. Коли ви думаєте про системи, ось на чому варто зосередитися: як речі збільшуються, як ефекти змінюються з часом, у якому напрямку тече причинно-наслідкова зв’язність, які вузли спілкуються з усіма сусідами, як виглядає емерджентність і що це за речі, які з’являються нізвідки. Які механізми стимулів? Включаючи соціальні та технічні, ємність, петлі зворотного зв’язку та обмеження — це інструменти системного аналізу.

Здається складно, але вам дійсно потрібно задати лише два питання: чому (Why?), і що, якщо (What if?)? Чому у нас так мало інтеграційних тестів? Що, якби у нас було більше інтеграційних тестів, ніж одиничних? Чому ми використовуємо саме ці мови? Що, якби всі коди написав AI?

«Чому» — це свердло, яке використовується, щоб глибоко проникнути в суть системи і зрозуміти, як вона працює. Ви всі добре вмієте задавати питання «чому», але «а якщо» — це складніша частина. «А якщо» може викликати страх, якщо вимагає від вас відмовитися від практик, які ви раніше вважали чудово спроектованими. Що, якщо не тестувати? Що, якщо взагалі не писати тести? Не заходьте занадто далеко. Але якщо ви дозволите цьому статися, «а якщо» також може бути досить захопливим.

Штучний інтелект — це підсилювач, а не напрямок

Штучний інтелект — це підсилювач. Ця ідея походить від моїх друзів із DORA, які у своєму звіті про розробку ШІ за минулий рік виявили зв’язок між командами, які справді зрозуміли суть: вони з’ясували, як зробити ШІ підсилювачем.

Штучний інтелект може дати вам більше: більше тестів, більше документації, більше коду, але й більше хаосу. Збільшення — це амплітуда, а не напрямок. Штучний інтелект не цікавиться, куди поділися ці речі — він просто дає вам більше. Справжнє відкриття DORA полягає в тому, що команди з міцними базовими навичками здатні спрямувати ефект збільшення у корисному напрямку.

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

Але навіть якщо базові навички міцні, ми вже на порозі справжньої подорожі. Я припускаю, що до 2030 року наша сьогоднішня екосистема розробників здасться нам такою ж віддаленою, як 2001 рік здається нам сьогодні. У 2001 році ми ще випускали програмне забезпечення на CD-ROM, а до 2030 року ми можемо бути на такій самій відстані.

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

По-перше, потужність інфраструктури. Якщо ви не знаєте, скільки ресурсів у вас є, ви не можете розгорнути ШІ чи обчислювальні ресурси; вам знадобиться добрий спосіб відстежувати це.

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

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

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

Ви також повинні прийняти один факт: інженерні практики не є священними. Практики змінюються, а принципи — це те, що має значення. Сказати це легко, а зробити — важко; якщо ви ніколи не думали про те, чому ваша команда тестує програмне забезпечення саме таким чином або чому процес випуску працює саме так, ви не зможете його еволюціонізувати. Розуміння принципів надасть вам сили та впевненості, щоб пройти цей момент зростання в 10 разів.

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

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

Багато наших програмних систем дуже хрупкі: одна погана рядок коду або неправильний прапор конфігурації може зруйнувати систему з мільйоном рядків, і ця хрупкість змушує вас добре подумати перед внесенням змін. Але щодо ШІ у мене є дуже захоплива ідея: постійно оновлюване, майже інтерактивне архітектурне простір, до якого я можу звертатися з питаннями. Що станеться, якщо ми перемістимо цю ємність на східне узбережжя? Що відбудеться, якщо зростання користувачів раптово зросте на 40%? Для системи навіть середнього розміру сьогодні це функціонально майже неможливо — занадто багато змінних. Але ШІ може розуміти дуже великі набори даних, і я вважаю, що тут є щось, що варто дослідити.

Мені подобається це питання, тому що ми зосереджені не лише на тому, щоб зробити машини з кодом працювати швидше, а питаемо: як глибше зрозуміти те, що ми вже створили?

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

Досвідчені інженери, ставайте наставниками. Знайдіть тих, хто застряг, і допоможіть їм. Якщо ви вже розумієте робочий процес розробки ШІ — поділіться цим з іншими, це не є чимось цінним таємним. Технічні лідери, ви повинні брати участь і допомагати визначати напрямок розвитку програмної інженерії у вашій компанії. Якщо вам байдуже якість програмного забезпечення або проектування ПЗ — використовуйте свій голос, щоб захищати це. Ви, присутні тут, — це ті, хто має це зробити. Ваші боси, ймовірно, цього не зроблять.

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

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

Незалежно від того, як це виглядає на поверхні, трансформація з використанням ШІ — це не лише сфера керівництва компаній. Як інженер-програміст на передовій, ви перебуваєте в центрі того, що вирішить, куди рухатиметься програмна інженерія. Від інструментів до робочих процесів, від інженерних практик до інженерної культури — якщо ви зможете розуміти системи, що функціонують, ви знайдете важелі. У вас більше автономії, ніж ви думаєте — скористайтеся нею, щоб створити майбутнє для вашої організації, вашої команди та себе.