На сцені Pragmatic Summit у залі, заповненому засновниками найгарячіших AI?стартапів, виходять двоє людей, які формували правила гри задовго до того, як «генеративний ШІ» став мейнстримом. Мартін Фаулер і Кент Бек — серед 17 авторів Agile?маніфесту, створеного близько 25 років тому, і автори ідей, що десятиліттями визначали практику розробки: рефакторинг, екстремальне програмування, тест?орієнтовану розробку.
Сьогодні вони говорять не стільки про минуле, скільки про те, як їхні особисті місії та професійні стратегії змінюються в епоху ШІ. Один свідомо відмовляється від книжок і будує незалежну публіцистичну платформу, інший формулює свою місію як «допомагати ґікам почуватися в безпеці» — і переносить її в нову реальність, де «ніхто більше не знає відповідей напевно».
25 років після Agile: довга тінь маніфесту
Agile?маніфест, підписаний 17 людьми в сніговому Юті приблизно чверть століття тому, став одним із найвпливовіших документів в історії розробки ПЗ. Серед підписантів — Мартін Фаулер і Кент Бек. Відтоді їхні ідеї — від гнучких процесів до рефакторингу й тест?орієнтованої розробки — стали частиною повсякденної мови інженерів.
Цей вплив відчувається й сьогодні, іноді в найнесподіваніших контекстах. Фаулер згадує розмову з інженером, який «штовхає межі» використання ШІ?агентів і дякує за 20 років пропаганди TDD: саме зараз, коли з’явився «великий потужний джин», уміння перевіряти, що система робить правильні речі, стає критично важливим. Автоматизовані тести, які колись здавалися «надмірною дисципліною», перетворюються на страховку проти помилок моделей, що генерують код і рішення.
Це показовий момент: практики, сформульовані в епоху до ШІ, не зникають, а отримують нове обґрунтування. Agile і TDD виявляються не просто «методологіями нульових», а інфраструктурою довіри — до власного коду, до командних процесів, а тепер і до поведінки ШІ?систем.
Водночас Бек чесно визнає: його найвідоміша ідея — тест?орієнтована розробка — завжди була поляризуючою. Він регулярно чує як «дякую за TDD, це змінило мою кар’єру», так і «TDD зруйнувало моє життя, собака пішла, дім згорів — і це твоя провина». Гіпербола в стилі розробників, але емоція реальна: TDD вимагає зміни мислення, і не всі готові чи хочуть проходити через цей злам.
Поляризація навколо TDD добре ілюструє ширшу закономірність: сильні ідеї в розробці рідко залишають когось байдужим. Вони або вбудовуються в повсякденну практику, або викликають спротив — але саме через це й мають шанс пережити кілька технологічних хвиль.
Мартін Фаулер: від книжок до незалежної платформи знань
Фаулер — автор однієї з найвпливовіших книжок у сучасній розробці, «Refactoring». Друга редакція вийшла приблизно за п’ять–шість років до цієї розмови. Після її завершення він опинився на роздоріжжі: продовжувати книжкову кар’єру чи змінити формат роботи з ідеями.
Вибір виявився радикальним. Замість нових книжок — кілька «напівнаписаних» рукописів, які так і не стали виданнями — Фаулер вирішує зосередитися на іншому: працювати з людьми, які «ще роблять справжню роботу на справжніх проєктах, пишуть справжній код», і допомагати їм публікувати власні ідеї та спостереження.
Ця зміна стратегії важлива з кількох причин.
По?перше, вона фіксує зсув від ролі «автора?одинака» до ролі куратора й редактора спільноти практиків. У світі, де технології змінюються швидше, ніж цикл підготовки книжки, знання дедалі частіше народжуються й оновлюються в режимі постійної публікації, а не «фінального тому».
По?друге, Фаулер свідомо обирає майданчик, який контролює сам: martinfowler.com. Це не просто персональний блог, а стратегічний актив. Він підкреслює, що сайт не належить жодній великій корпорації й не може бути «зачищений» без його рішення «продатися за великі гроші». У час, коли платформи змінюють алгоритми, закривають API й можуть одномоментно обнулити аудиторію, контроль над власним доменом стає не лише технічним, а й політичним вибором.
По?третє, зміна фокусу дозволяє йому зайняти позицію спостерігача й аналітика нової хвилі — зокрема ШІ. Фаулер не намагається виставити себе «головним користувачем» усіх нових інструментів. Натомість він уважно вивчає, як змінюються робочі процеси інших розробників, і документує ці зміни.
Його теперішній інтерес — деталі робочих потоків у світі, де в команді з’являється «джин» у вигляді ШІ?інструментів. Які саме розмови розробники ведуть із цим джином? Що шукають у згенерованому коді під час рев’ю? Які рішення все ще приймає людина, а які делегує моделі? Як змінюється «потік рішень» у команді, де частину кроків виконує ШІ?
Це не абстрактні роздуми, а спроба зафіксувати нову нормальність розробки. Якщо раніше Фаулер систематизував техніки рефакторингу, то тепер він фактично рефакторить саме поняття «робочий процес розробника» в епоху ШІ.
Незалежність проти хайпу: скепсис, цікавість і другий шанс для ШІ?інструментів
Фаулер не приховує: його ставлення до нових технологій завжди було сумішшю скепсису й цікавості. Він бачив занадто багато «чарівних еліксирів», які індустрія продавала як панацею, щоб беззастережно вірити в кожну нову хвилю. Приклад блокчейну для нього показовий: до цієї технології він був «надзвичайно скептичним» і так і не побачив достатньо сигналів, щоб змінити думку.
Але власний скепсис він теж ставить під сумнів. Якщо скептицизм «абсолютний і тотальний», каже Фаулер, він має поширюватися й на самого себе. Це означає: навіть коли перше враження негативне, варто залишити простір для перегляду позиції, якщо з’являться нові дані.
Історія з його першим досвідом використання AI?асистентів для коду добре це ілюструє. Приблизно за рік–півтора до цієї розмови він налаштував у Emacs «копілотоподібний» інструмент автодоповнення. Кілька днів експериментів закінчилися розчаруванням: іноді інструмент пропонував щось корисне, але «більшість часу видавав такий мотлох», що хотілося одразу натиснути Ctrl?K і видалити все. Якби на цьому він поставив крапку, ШІ міг би опинитися в тій самій категорії, що й блокчейн: «перемикач блазня» був би клацнутий у положення «ігнорувати».
Проте Фаулер продовжив «зондувати» середовище. Важливу роль зіграли зовнішні сигнали: блог Саймона Віллісона, де детально описувалися практичні кейси використання ШІ?інструментів, а також спостереження за колегами на кшталт Майка Мейсона й Біргітти Бьокелер, які навчалися працювати з цими засобами й отримували реальну користь.
Це повертає його до ще одного уроку з минулого: жоден інструмент не розкриває свій потенціал «із коробки». Так само, як у 90?х і 2000?х розробникам доводилося вчитися об’єктно?орієнтованому мисленню, сьогодні потрібно вчитися ефективно працювати з ШІ?асистентами. Сам факт наявності інструменту нічого не гарантує; потрібні нові навички, нові патерни взаємодії, нові критерії якості.
У цьому сенсі його незалежний сайт стає не просто архівом статей, а лабораторією, де фіксуються й аналізуються ці нові патерни. І саме незалежність від платформ і корпорацій дозволяє йому зберігати критичну дистанцію до хайпу, не втрачаючи при цьому відкритості до реальних змін.
Кент Бек: «допомогти ґікам почуватися в безпеці» в світі, де ніхто не знає відповідей
Якщо у Фаулера стратегія змінилася з «писати книжки» на «підсилювати голоси практиків», то в Бека змінилася рамка місії. Він формулює її максимально особисто: «Моя життєва місія — допомагати ґікам почуватися в безпеці у світі».
Ця фраза звучить майже терапевтично, але за нею стоїть конкретний досвід. Протягом приблизно 25 років у розробників було відчуття, що «відповіді відомі». Якщо в команді забагато багів — є перевірені рецепти: навчитися писати тести, змінити дизайн так, щоб тести було легко додавати, впровадити певні практики. Старші інженери могли буквально «натиснути play на диктофоні» й відтворити набір порад, які працювали знову й знову.
Сьогодні, на думку Бека, ситуація інша: «У цей момент ніхто не знає відповідей ні на що». Швидкість змін у сфері ШІ така, що досвід останніх 20 років більше не дає стабільних рішень. Розробники, які звикли «зазирнути в книжку» чи документацію й знайти готовий патерн, раптом опиняються в середовищі, де книжки ще не написані, а найкращі практики змінюються щотижня.
У цій реальності місія «допомогти почуватися в безпеці» набуває нового змісту. Безпека більше не означає «мати правильну відповідь», вона означає «уміти жити без неї». Бек бачить свою роль у двох вимірах.
Перший — особистий: задовольнити власну «ґікову цікавість», повернутися в режим дослідження й з’ясувати, що насправді можна робити з новими інструментами. Це не теоретичні вправи: він береться за «смішно амбітні» проєкти, працює над persistent Smalltalk, пише «бібліотечний» код на Rust, використовуючи ШІ, щоб розширити межі можливого. Частина цих спроб неминуче провалюється, і це для нього прийнятна ціна експерименту.
Другий — педагогічний: продемонструвати молодшим поколінням не лише «як користуватися інструментами», а й «як з’ясовувати, як ними користуватися». Це принципова різниця. За останні два десятиліття багато розробників звикли до моделі, де старші колеги чи книжки дають готові відповіді. У світі ШІ, де якість інструментів може змінюватися «з тижня в тиждень», стабільні відповіді про конкретні сервіси стають ненадійними.
Натомість критично важливим стає інше вміння: формулювати гіпотези про користь інструменту й перевіряти їх мінімальними експериментами. Бек описує це як питання: «Який найменший експеримент я можу провести, щоб до власного задоволення перевірити, чи правда ця заява?» Рівень «задоволення» у кожного свій, але сам підхід — мислити через маленькі валідаційні кроки — стає, на його думку, «у тисячу разів ціннішим», ніж ще рік тому.
Це, по суті, перенесення духу TDD на рівень технологічних рішень: не вірити жодній обіцянці без тесту, але й не відкидати її без спроби перевірки.
ШІ як «мікропроцесор у голові» і новий масштаб невідомого
І Фаулер, і Бек погоджуються: жоден попередній злам у їхній кар’єрі не зрівняється з ШІ за масштабом і швидкістю впливу. Фаулер згадує кілька попередніх хвиль — об’єктно?орієнтоване програмування, інтернет, Agile — і визнає, що всі вони були значущими, але ШІ — «на розмір більший» за будь?яку з них.
Є ще одна відмінність: раніше їм доводилося переконувати індустрію в важливості нових підходів. Навіть інтернет, як не дивно, спочатку сприймався не всіма як щось критичне. З Agile спротив був настільки сильним, що за ним можна було судити про глибину впливу. У випадку ШІ, каже Фаулер, ситуація інша: «тут майже немає суперечки щодо важливості». Ніхто не може «надягти шори» й удавати, що це не має значення.
Бек проводить історичну паралель із появою мікропроцесора Intel 4004. До нього комп’ютери були «великими коробками», які важко перемістити й ще важче купити вдруге. Коли в Кремнієвій долині, де його батько працював програмістом, з’явився 4004, реакція була: «Почекайте, це ж комп’ютер». Раптом стало можливим уявити пристрої й застосунки, які раніше не вкладалися в голову. Ті, хто зміг навчитися писати софт і проєктувати залізо навколо мікропроцесора, отримали доступ до «можливостей, які ми навіть не могли уявити».
ШІ, на думку Бека, викликає подібне «розширення уяви». Різниця в тому, що тепер мікропроцесор ніби з’явився «всередині» інженерного процесу: моделі можуть писати код, пропонувати архітектури, аналізувати логи. Це не просто новий тип заліза чи мережі, це новий тип співучасника в розробці.
Саме тому його власні проєкти сьогодні — «смішно амбітні». Він свідомо ставить планку вище, ніж здається реалістичною, і дивиться, що вийде, маючи поруч «джина». Частина задумів провалюється, але це, за його словами, «частина процесу». Важливіше те, що сама межа «уявного» посунулася.
Цей новий масштаб невідомого повертає нас до початкових місій обох інженерів. Agile?маніфест колись формулював цінності, які мали допомогти командам працювати в умовах змін і невизначеності. Сьогодні Фаулер і Бек, кожен по?своєму, намагаються оновити ці цінності для світу, де невизначеність стала нормою, а «відповіді» — тимчасовими гіпотезами.
Висновок: місії, що переживають технологічні хвилі
Історії Мартіна Фаулера й Кента Бека в епоху ШІ показують, що справжній вплив у технологіях рідко обмежується однією хвилею. Agile, рефакторинг, TDD — усе це народжувалося в конкретному історичному контексті, але виявилося достатньо гнучким, щоб бути переосмисленим у нових умовах.
Фаулер, відмовившись від книжок на користь незалежної платформи martinfowler.com і співпраці з активними практиками, фактично створює інфраструктуру для колективного осмислення змін у розробці. Його фокус на робочих потоках, рішеннях і «розмовах із джином» допомагає побачити, як саме ШІ вбудовується в повсякденну роботу інженерів.
Бек, формулюючи місію «допомагати ґікам почуватися в безпеці» й чесно визнаючи, що «ніхто більше не знає відповідей, як це було останні 20 років», переводить акцент із готових рецептів на навички дослідження. Його досвід із TDD — одночасно обожнюваною й ненавидимою практикою — нагадує, що сильні ідеї завжди розколюють спільноту, але саме вони дають інструменти для роботи з невідомим.
У світі, де ШІ сприймається як неминучий і масштабний злам, їхні нинішні стратегії — незалежна публіцистика, культивування скептичної цікавості, демонстрація процесу дослідження, а не лише результатів — можуть виявитися не менш важливими, ніж колись Agile?маніфест чи «Refactoring». Бо технологічні хвилі змінюються, а от місії, які допомагають інженерам зберігати професійну автономію й психологічну безпеку, мають шанс пережити ще не одну революцію.