За останні пів року один із найвідоміших інженерів сучасного вебу радикально змінив спосіб, у який пише код. Девід Хайнемайєр Ханссон (David Heinemeier Hansson, або DHH) — творець Ruby on Rails, автор Linux?дистрибутива Omachi та співзасновник 37signals (Basecamp, HEY) — ще зовсім недавно публічно скептично ставився до AI?інструментів програмування. Сьогодні він говорить про «agent?first» підхід, майже не набирає код руками і використовує агентів як основний інструмент побудови софту.
Ця трансформація не зруйнувала його ставлення до ремесла, естетики й якості — радше змінила саму «механіку» роботи: від ручного кодування до керування потужними інструментами, які виконують левову частку рутинної роботи. На тлі цього зсуву по?новому виглядають і Ruby on Rails, і Linux?дистрибутив Omachi, і сама культура розробки в 37signals.
Від скепсису до «agent?first»: що насправді змінилося
Ще шість місяців тому DHH публічно «бив» по можливостях AI?кодерів і принципово набирав увесь код сам. Зараз він описує власний перехід як «180?градусний розворот» за кілька тижнів зимових канікул — і водночас наполягає: його базові погляди не змінилися, змінилися інструменти.
Ключовий момент полягає в тому, що для нього програмування завжди було ремеслом, де естетика нерозривно пов’язана з правильністю. Він формулює це жорстко: «естетика — це правда». У математиці, фізиці, програмуванні — там, де рішення красиве, воно з великою ймовірністю ще й коректне. Цей критерій нікуди не зник із приходом AI?агентів. Змінилася роль людини: замість того, щоб власноруч «вибивати» кожен рядок, інженер стає диригентом, який задає напрям, перевіряє, відсіює й шліфує.
У 37signals це вже не теоретичний експеримент, а повсякденна практика. Один із найактивніших користувачів агентів у компанії, Джеремі, взявся за завдання, яке в «допоінтелектуальну» епоху навряд чи взагалі з’явилося б у беклозі: оптимізувати P1 — буквально найшвидші 1% запитів — зробити ще швидшими. Це не «пожежа» й не бізнес?критичний борг, а майже естетичне прагнення до досконалості продуктивності. Сам факт, що команда може дозволити собі такі проєкти, — прямий наслідок того, наскільки багато роботи тепер перекладається на агентів.
DHH визнає й темний бік цієї ефективності: коли за годину «нагляду» за агентами можна зробити стільки, скільки раніше займало день чи тиждень, це стає «інтоксикаційним». Люди, які пішли «all?in» в AI?воркфлоу, часто працюють більше, ніж будь?коли. Продуктивність зростає, але разом із нею — спокуса постійно запускати ще один експеримент, ще один агент, ще одну оптимізацію. Потрібно свідомо гальмувати, щоб не перетворити нові можливості на нескінченну гонку.
Сутність зсуву: не зміна цінностей, а зміна важелів. Там, де раніше майстерність проявлялася в тому, як саме ти пишеш код, тепер вона все більше проявляється в тому, як ти формулюєш завдання, оцінюєш результати агентів і приймаєш рішення, що варто довести до продакшну.
Ruby on Rails у новій реальності: токени, агенти й читабельність
Ruby on Rails народився як набір інструментів, які DHH створив для себе, коли в 2003 році будував Basecamp на Ruby, що тоді майже не мав веб?екосистеми. Він «подряпав власний свербіж», відкрив код — і фреймворк став одним із найвпливовіших у веб?розробці. Двадцять років потому Rails не просто живий: DHH досі «дуже сильно залучений» у його розвиток і бачить для нього нову хвилю популярності в епоху AI?агентів.
Причина — у тому, як великі мовні моделі працюють із кодом. Вони оперують токенами, і «вартість» кожної операції, як у грошах, так і в часі, залежить від того, скільки токенів потрібно для контексту. Rails виявляється «одним із найбільш токен?ефективних способів будувати веб?додатки». Конвенції, компактність, велика кількість «магії» й DSL?подібних конструкцій, які роками критикували за непрозорість, раптом стають перевагою: менше коду — менше токенів, менше навантаження на модель, швидше й дешевше генерування.
Це не лише про вартість. Поки що важливо, щоб агенти генерували код, який люди можуть прочитати й перевірити. DHH прямо говорить: можливо, через якийсь час агенти будуть писати машинний код чи асемблер, і людська читабельність перестане бути критерієм. Але сьогодні вона критична. Rails, із його виразністю та високим рівнем абстракції, дає змогу агентам продукувати код, який легко перевірити досвідченому розробнику.
У цьому сенсі Rails отримує друге дихання: фреймворк, який колись прискорив людей, тепер прискорює агентів, а ті, своєю чергою, прискорюють людей. Виникає новий трикутник: людина — фреймворк — агент. І в цьому трикутнику старі інженерні чесноти — смак, відчуття краси, вміння побачити «правильність» у структурі — стають не менш важливими, ніж раніше.
Omachi, Linux і агентний підхід до інфраструктури
Перехід DHH до «agent?first» мислення не обмежується кодом додатків. Він тісно пов’язаний із тим, як він працює з інфраструктурою — і тут у гру входить Omachi, його власний Linux?дистрибутив.
Близько двох років тому він повністю перейшов на Linux: спочатку Ubuntu, а потім вирішив «зробити власну систему з нуля», побудувавши її на базі Arch і Hyprland. Omachi почався як літній проєкт під час 24 Hours of Le Mans, де між заїздами багато «мертвого часу». Те, що стартувало як особистий експеримент, дуже швидко «злетіло»: за трохи більше ніж пів року дистрибутив зібрав близько 400 контриб’юторів, а десятки тисяч людей встановили його як щоденну систему.
Це класична для DHH історія: він створює «ідеальну систему для себе» — і виявляється, що існують тисячі людей із дуже схожими вподобаннями. Так було з Ruby on Rails, так із Omachi, так із іншими його проєктами на кшталт Kamal чи ініціативи «getting out of the cloud». Важливий момент: це не просто хобі. 37signals уже перевела більшість девелоперських машин на Linux, причому саме на власний дистрибутив. Компанія з першого дня деплоїть на Linux?сервери й залишається «Linux?шопом» на бекенді, тож зближення дев?середовища з продакшеном дає відчутну перевагу.
У цьому рішенні проглядається той самий агентний спосіб мислення, тільки на рівні організації: якщо ти створюєш інструмент, який реально працює, логічно максимально його використовувати. DHH як CTO прямо задає технічний курс: розробники вебу, Ruby й DevOps мають працювати на Linux, щоб бути ближче до продакшену й одночасно допомагати розвивати Omachi. «Відкритий вибір» ОС, який був на старті експерименту, поступився місцем стандартизації — так само, як нікому не дозволять у 37signals будувати новий сервіс на Django, коли вся компанія живе на Ruby on Rails.
У контексті AI?агентів це означає ще й інше: чим більш однорідне середовище, тим легше будувати поверх нього автоматизацію. Агенти краще працюють там, де інфраструктура передбачувана, інструменти стандартизовані, а «шум» від різних стеків мінімальний. Omachi стає не лише «ідеальним десктопом» для DHH, а й фундаментом для нових агентних воркфлоу в компанії.
Більше амбіцій, менше бар’єрів: як агенти змінюють масштаб ідей
Один із найцікавіших ефектів переходу до agent?first підходу — зміна того, які проєкти взагалі вважаються реалістичними. DHH прямо говорить: кількість внутрішніх ініціатив, за які 37signals береться зараз, «легіон», і значна частина з них раніше навіть не розглядалася б.
Це стосується не лише мікрооптимізацій на кшталт P1. Вся історія 37signals — це послідовність проєктів, які на старті виглядали або нішевими, або відверто божевільними. У 2003 році Basecamp був побічним продуктом веб?консалтингу, який раптом «вистрілив» настільки, що компанія за рік повністю відмовилася від послуг і стала продуктовою. Через 20 років Basecamp залишається найбільшим і найважливішим продуктом 37signals — приклад того, як «перша ідея» може виявитися найкращою в кар’єрі.
У 2020 році компанія запустила HEY — платний email?сервіс, який напряму конкурує з Gmail. Це ринок, де один гравець, за оцінкою DHH, обробляє 80–85% всього email?трафіку в США. Він сам користувався Gmail близько 17 років, із перших інвайтів, і за цей час накопичив довгий список речей, які його не влаштовували. HEY став спробою втілити ці думки в альтернативний продукт — із багатомільйонними інвестиціями в R&D і майже дворічною розробкою до запуску.
Тепер, коли в арсеналі є AI?агенти, планка «що ми можемо собі дозволити спробувати» піднімається ще вище. Там, де раніше довелося б рахувати кожен інженерний місяць, сьогодні можна доручити агентам значну частину чорнової роботи: дослідження варіантів реалізації, генерацію прототипів, навіть оптимізацію вже працюючих систем. Людський час звільняється для того, що DHH цінує найбільше: формування смаку, прийняття рішень, визначення того, що взагалі варто будувати.
Це не означає, що великі продукти на кшталт HEY раптом стануть «дешевими». Але означає, що внутрішні інструменти, експерименти з продуктивністю, нові дистрибутиви й фреймворки можуть з’являтися частіше й швидше. Агенти знижують вартість помилки: якщо щось не «злетіло», втрачені ресурси менші, ніж у світі, де кожен рядок коду писався вручну.
Краса, смак і ремесло в епоху AI: чому роль людей не зникає
На тлі розмов про те, що AI «з’їсть» професію програміста, позиція DHH виглядає помітно відмінною. Він не применшує потужність агентів, але постійно повертається до теми естетики й ремесла. Для нього краса в софті — не прикраса, а індикатор правильності. І саме тут, на його думку, роль людей може навіть посилитися.
По?перше, агенти не мають смаку. Вони можуть генерувати код, який компілюється й проходить тести, але не відчувають, чи є рішення елегантним, чи відповідає воно стилю системи, чи не створює воно «естетичного боргу», який через рік перетвориться на технічний. Це зона відповідальності інженерів, які «дбають про ремесло» — тих, хто здатен побачити в рішенні не лише функціональність, а й форму.
По?друге, дизайн і розробка в 37signals історично тісно переплетені. Компанія починалася як веб?дизайн?студія, і DHH неодноразово підкреслює важливість смаку й естетики в продуктах. У світі, де базову реалізацію дедалі частіше виконують агенти, саме «сильні думки» про те, як має виглядати й поводитися софт, стають конкурентною перевагою. Від дизайнерів і інженерів очікують не просто вміння «намалювати» чи «написати», а здатності задати високу планку й утримувати її, навіть коли інструменти дозволяють «зробити як?небудь» за хвилини.
По?третє, поки що агенти потребують людського контролю. DHH прямо визнає: сьогодні важливо, щоб люди могли читати й верифікувати код, який генерують моделі. Це означає, що досвідчені інженери, здатні швидко оцінити якість рішень, стають мультиплікаторами продуктивності: вони не просто пишуть код, а керують «роєм» агентів, які пишуть за них. У результаті їхній вплив на продукт зростає.
Це водночас створює виклики для молодших розробників, але ця тема виходить за межі конкретного фрагмента розмови. Важливо інше: у баченні DHH майбутнє програмування — не в тому, щоб замінити людей, а в тому, щоб підняти планку того, що вони можуть робити, коли рутинна частина роботи делегована машинам.
Висновок: нова роль інженера — диригент агентів і хранитель смаку
Історія Девіда Хайнемайєра Ханссона — це не лише історія Ruby on Rails, Basecamp, HEY чи Omachi. Це історія людини, яка послідовно ставиться до програмування як до ремесла, де краса й правильність нерозривні, і водночас не боїться радикально змінювати інструменти, коли з’являється щось справді корисне.
Перехід від «я набираю весь код сам» до «я майже не пишу код руками й працюю agent?first» не зруйнував його цінностей. Він змінив конфігурацію роботи: тепер інженер — це не стільки «машина для набору коду», скільки архітектор, редактор і диригент, який керує агентами, задає їм напрям, відсіює погані рішення й шліфує хороші до рівня, де естетика стає маркером істини.
У цьому світі фреймворки на кшталт Ruby on Rails отримують нове життя як токен?ефективні, читабельні й добре структуровані середовища для агентів. Власні інструменти, як Omachi, стають не просто особистими забавками, а стратегічною інфраструктурою, яка дозволяє будувати більш амбітні системи швидше й упевненіше. А компанії, що готові стандартизувати стек і мислити «agent?first», отримують змогу братися за проєкти, які ще вчора здавалися надто дорогими чи ризикованими.
Головне, що не змінюється в цій картині, — потреба в людях, які мають смак, відчуття краси й повагу до ремесла. Саме вони визначатимуть, які з нескінченних варіантів, що їх пропонують агенти, варто втілювати в життя. І саме від них залежить, чи стане нова ера AI?розробки часом швидкого, але посереднього софту, чи часом небаченої раніше якості, помноженої на небачену швидкість.