Девід Гайнемайєр Ханссон — творець Ruby on Rails і дистрибутива Linux Omarchy, співзасновник і CTO компанії 37signals (Basecamp, HEY). Близько шести місяців до цієї розмови він публічно критикував AI?інструменти для програмування в подкасті Лекса Фрідмана, наголошуючи, що воліє набирати весь код вручну. За кілька тижнів зимових канікул усе змінилося: Ханссон перейшов до AI?first, agent?first підходу до розробки й тепер стверджує, що майже не пише код сам, а радше керує агентами. Ця зміна не лише трансформувала його особистий робочий процес, а й помітно вплинула на те, як 37signals планує й реалізує інженерні проєкти.
Від скепсису до «AI?first»: розворот за кілька тижнів
Ще пів року тому позиція Девіда Гайнемайєра Ханссона щодо AI?інструментів для програмування була чіткою й публічно зафіксованою. У розмові з Лексом Фрідманом він різко оцінював можливості таких засобів і підкреслював, що воліє писати код сам, руками, без «підказок» моделей. Для людини, яка майже три десятиліття будує веб?софтуер — від перших проєктів у 1994?му до сьогодні — це виглядало як послідовна позиція майстра, що захищає ремесло.
Однак протягом кількох тижнів зимової перерви відбувся розворот на 180 градусів. Ханссон перейшов до AI?first, agent?first робочого процесу: тепер він не просто використовує штучний інтелект як допоміжний інструмент, а ставить його в центр розробки. Замість того, щоб набирати код рядок за рядком, він формулює завдання, контекст і обмеження, після чого AI?агенти генерують і змінюють код, а він виступає в ролі наглядача, редактора й арбітра якості.
Сам Ханссон підкреслює, що його базові цінності не змінилися. Він як і раніше розглядає розробку як ремесло, де естетика, ясність і краса рішення тісно пов’язані з його правильністю. Змінилося інше — інструментарій, який дозволяє ці цінності реалізовувати. Якщо раніше для цього потрібно було особисто писати кожну функцію, то тепер значну частину роботи виконують агенти, а людина зосереджується на постановці задачі, оцінці результату й корекції напрямку.
Цей перехід не був поступовим багатомісячним експериментом. Навпаки, він став концентрованим досвідом: кілька тижнів інтенсивного занурення, після яких новий спосіб роботи став основним. Для інженера, який створив один із найвпливовіших веб?фреймворків, це показовий сигнал: щось у можливостях сучасних AI?агентів перетнуло поріг, за яким їх ігнорувати вже складніше, ніж прийняти.
Agent?first замість «я все напишу сам»: як виглядає новий робочий процес
Сьогодні Девід Гайнемайєр Ханссон описує свій підхід до розробки як agent?first. Це означає, що вихідною точкою в роботі над фічею, оптимізацією чи експериментом стає не ручне написання коду, а постановка задачі для AI?агента.
Роль інженера в такій схемі зміщується з «автора коду» до «режисера процесу». Він визначає:
контекст — що це за система, які її обмеження, які частини коду вже існують;
ціль — що саме потрібно змінити або створити, які метрики важливі;
критерії якості — що вважати прийнятним рішенням, які компроміси неприпустимі.
Далі агенти генерують код, пропонують варіанти, вносять зміни у вже існуючі модулі. Людина читає, перевіряє, відхиляє, просить переробити, уточнює вимоги. За словами Ханссона, він тепер «ледве пише будь-який код руками» — основний час іде на нагляд за агентами й редагування їхніх результатів.
Це не означає відмову від глибокого розуміння системи. Навпаки, щоб ефективно керувати агентами, потрібно добре знати архітектуру, мати чітке відчуття «правильності» рішення й вміти швидко помічати приховані проблеми. Але сам процес перетворюється з послідовного набору символів у діалог — між інженером і моделлю, між різними агентами, між різними варіантами реалізації.
У цьому контексті особливо цікаво виглядає поєднання agent?first підходу з Ruby on Rails. Ханссон вважає, що сьогодні фреймворк переживає певний ренесанс саме завдяки своїй «токен?ефективності» й придатності до роботи з агентами. Rails дозволяє описувати веб?додатки компактно, з високим рівнем абстракції, а це означає менше токенів для моделі, менше «шуму» в контексті й простіший для читання й верифікації код. Поки що це має значення: агенти генерують код, який люди все ще читають і перевіряють.
Ханссон не виключає, що в майбутньому агенти зможуть працювати на рівні машинного коду чи асемблера, і тоді людська верифікація відійде на другий план. Але в поточній точці розвитку технологій саме поєднання компактних, виразних інструментів на кшталт Rails із agent?first підходом дає відчутний ефект.
Більше амбіцій, менше бар’єрів: як 37signals використовує агентів
Перехід до agent?first підходу в 37signals не обмежився особистим робочим процесом CTO. Компанія все активніше використовує AI?агентів для дослідження ідей і побудови софту, при цьому декларуючи збереження тих самих стандартів якості й ремесла, які були до появи цих інструментів.
Один із показових прикладів — внутрішні оптимізаційні проєкти. Ханссон описує, як один із інженерів компанії, Джеремі, став «одним із найагент?прискореніших людей» у команді. Він узявся за завдання, яке в традиційній парадигмі розробки навряд чи взагалі потрапило б у план: оптимізувати P1 — тобто зробити ще швидшими найшвидші 1% запитів у системі.
У класичному підході до продуктивності команди зазвичай фокусуються на «вузьких місцях» — найповільніших запитах, найпроблемніших ділянках. Ідея витрачати ресурси на те, щоб прискорити вже й так найшвидші 1% запитів, виглядає майже екстравагантною. Вона потребує багато часу, глибокого аналізу, численних експериментів з мікрооптимізаціями. У звичайному режимі така ініціатива часто не проходить через фільтр пріоритизації: занадто дорого щодо очікуваного виграшу.
Але в умовах, коли один інженер може за годину нагляду за агентами досягати ефекту, який раніше вимагав би днів або тижнів роботи, подібні проєкти раптом стають реалістичними. AI?агенти можуть швидко перебирати варіанти, пропонувати зміни, тестувати гіпотези, а людина зосереджується на виборі найкращих рішень і контролі за тим, щоб оптимізація не зламала інші частини системи.
Цей приклад добре ілюструє одну з ключових змін, які Ханссон бачить у поточному моменті: AI не просто прискорює виконання вже запланованих задач, а розширює простір того, що взагалі вважається доцільним робити. З’являються проєкти, які раніше навіть не розглядалися б — не через відсутність ідей, а через обмеженість часу й людських ресурсів.
При цьому 37signals не декларує зниження планки якості. Навпаки, компанія продовжує підкреслювати важливість естетики, ясності й «красивих» рішень у коді. AI?агенти в такій моделі — не заміна ремеслу, а інструмент його масштабування. Вони дозволяють тим самим людям із тими самими стандартами зробити більше, спробувати сміливіші ідеї, зайти глибше в оптимізацію.
Інфлексійна точка для старших інженерів — і нові виклики для молодших
Девід Гайнемайєр Ханссон описує поточний момент як інфлексійну точку для програмної інженерії. На його думку, AI суттєво змінює те, як старші інженери можуть підходити до розробки. Люди з великим досвідом, глибоким розумінням систем і сильним відчуттям якості отримують потужний мультиплікатор продуктивності.
Якщо раніше сеньйор, який добре знає домен і кодову базу, був обмежений власною пропускною здатністю — кількістю годин, які він може провести за клавіатурою, — то тепер він може керувати «флотом» агентів. Кожен із них виконує частину роботи: генерує код, пропонує рефакторинги, аналізує продуктивність. Роль сеньйора зміщується в бік стратегічного мислення, постановки задач, архітектурних рішень і контролю якості.
Це, за спостереженнями Ханссона, має і психологічний ефект. Коли за годину нагляду за агентами можна досягти відчутного результату, це стає «інтоксикаційним» відчуттям ефективності. Багато тих, хто «all?in» в AI?інструментах, працюють більше, ніж будь?коли, саме тому, що бачать прямий, швидкий вплив своєї роботи. Сам Ханссон визнає, що відчуває це на собі: можливість бути настільки результативним за одиницю часу провокує працювати інтенсивніше.
Однак цей же зсув створює виклики для молодших розробників. Ханссон прямо говорить про «нерівномірний вплив» AI: він підсилює старших інженерів, але ускладнює шлях для джуніорів. Якщо значна частина «рутинної» роботи — написання нескладних модулів, типових CRUD?операцій, базових тестів — переходить до агентів, молодшим фахівцям стає складніше отримати той самий досвід, на якому традиційно будувалося зростання.
У класичній моделі кар’єри джуніор починає з простих задач, поступово набирає «м’язову пам’ять» коду, вчиться бачити патерни, розуміти архітектуру. Тепер частину цього шляху може «перестрибувати» AI, виконуючи роботу швидше й, часто, достатньо якісно для продакшну. Виникає питання: де і як молодий інженер має набиратися практики, якщо значну частину базових задач компанія раціонально віддає агентам?
Ханссон не пропонує простих відповідей, але чітко фіксує проблему. Поточна хвиля AI?інструментів не є нейтральною щодо всіх рівнів досвіду. Вона створює нові можливості для тих, хто вже має глибоке розуміння ремесла, і водночас піднімає планку входу для тих, хто тільки починає. Це не означає, що шлях закритий, але він стає іншим — із більшим акцентом на здатність формулювати задачі, розуміти системи цілісно й критично оцінювати результати роботи агентів.
Ремесло, естетика й AI: чому стандарти якості не зникають
Попри радикальну зміну інструментарію, Девід Гайнемайєр Ханссон послідовно підкреслює: для нього програмування залишається ремеслом, де естетика — не прикраса, а критерій істинності. Він формулює це майже як аксіому: коли щось красиве, воно з великою ймовірністю правильне. На його думку, це працює в математиці, фізиці й у розробці програмного забезпечення.
У такій картині світу AI?агенти — лише новий інструмент у руках майстра. Вони можуть генерувати код, але не визначають, що вважати хорошим кодом. Цю роль зберігає за собою людина, яка має смак, досвід і здатність відрізнити елегантне рішення від тимчасового «хака».
37signals, яка ще з початку 2000?х будувала свій бренд на поєднанні функціональності й виразного дизайну (Basecamp, а пізніше HEY), переносить цей підхід і в епоху AI. Компанія не сприймає агентів як привід знизити вимоги до читабельності, ясності чи архітектурної цілісності. Навпаки, саме тому, що агенти можуть швидко генерувати велику кількість коду, зростає важливість чітких стандартів і людського нагляду.
У цьому сенсі agent?first підхід не суперечить ремісничому баченню, а радше змінює масштаб. Якщо раніше майстер міг особисто «відшліфувати» обмежений обсяг коду, то тепер він може застосовувати свій смак і критерії якості до значно більшого масиву роботи, виконаної агентами. Ключовим стає не те, хто набрав символи, а те, хто визначив, яким має бути результат і що вважати прийнятним.
Це також пояснює, чому Ханссон не вважає, що «зрадив» своїм попереднім переконанням, коли перейшов від скепсису до активного використання AI. Його базові принципи — цінність ремесла, важливість естетики, прагнення до простоти й ясності — залишилися незмінними. Змінилося лише ставлення до того, чи можуть сучасні інструменти допомогти ці принципи реалізовувати ефективніше.
Висновок: AI як новий рівень важеля для тих, хто вже вміє будувати
Історія розвороту Девіда Гайнемайєра Ханссона — від публічної критики AI?інструментів до майже повної відмови від ручного написання коду — показова не лише тому, що йдеться про творця Ruby on Rails. Вона ілюструє ширший зсув у програмній інженерії: AI?агенти перестають бути «цікавою іграшкою» й стають реальним важелем, який змінює економіку часу й амбіцій.
Для таких компаній, як 37signals, це означає можливість братися за проєкти, які раніше не проходили б через фільтр здорового глузду, — на кшталт оптимізації найшвидших 1% запитів. Для старших інженерів — шанс масштабувати свій вплив, працюючи не стільки руками, скільки головою. Для молодших — нову, складнішу траєкторію входу в професію, де базові задачі дедалі частіше виконують агенти.
При цьому ключові питання залишаються тими самими: що вважати хорошим софтом, як поєднати красу й функціональність, як будувати системи, які витримують час. Відповіді на них, принаймні поки що, дають не моделі, а люди, які вміють бачити в коді не лише інструкції для машини, а й прояв ремесла.
AI?агенти, у цій картині, — не кінець професії розробника, а новий рівень інструменту. І від того, як інженери навчаться ними користуватися — як режисери, а не як пасивні спостерігачі, — залежить, чи стане поточна інфлексійна точка справжнім стрибком уперед для галузі.