Давайте розглянемо історію народження Claude Code, переважно взяту з інтерв'ю з техноблогером Гергелем Оросом про ключового члена Claude Code. Claude Code справді вражає: річний дохід у 500 мільйонів доларів і 10-кратне збільшення обсягу користувачів за три місяці, і тепер є улюбленим інструментом Coding Agent для багатьох програмістів. Цей інструмент починався як маленька іграшка в командному рядку, яка показувала «яку пісню ви зараз слухаєте». 🧵

Гергей Орос взяв інтерв'ю у трьох основних учасників Claude Code: • Борис Черний, засновник (17 років досвіду, колишній головний інженер Meta) • Інженер 2 Сід Бідасарія (автор матеріалу Subagents) • та Кет Ву, менеджер продукту. Вони розповідали, як Claude Code пройшла шлях від прототипу до продукту, які технічні рішення вони приймали, і як невелика команда з десятка людей могла публікувати 5 PR на день. Це, мабуть, найближчий приклад до «інженерної команди, що орієнтується на ШІ» на даний момент. Вони використовують ШІ для написання коду, тестів, перевірок коду, усунення несправностей і навіть для розробки самого Claude Code. 90% коду пишеться самостійно. Я хочу розібратися з найцікавіших частин цього інтерв'ю, розповісти, як працює ця команда, чого можна навчитися, а що визначається їхніми особливими умовами і не може бути скопіювано. Нижче розділено на 7 коротких оповідань, кожне з яких можна читати окремо, і вони пов'язані між собою, щоб створити повну картину.

[1] Як пристрій-прослуховування може стати продуктом із річним доходом у 500 мільйонів доларів У вересні 2024 року Борис Черний щойно приєднався до Anthropic і написав іграшку для командного рядка, коли йому не було чим зайнятися. Що ця штука може робити? Він використовує AppleScript, щоб показати, яку пісню ви слухаєте, і змінювати пісню відповідно до ваших команд. Все просто. Сам Борис прокоментував: «Досить круте демо, але не цікаве. ”

Справжній поворот стався після того, як він закінчив розмову зі своєю колегою Кет Ву. Кет вивчала комп'ютерні можливості AI Agent, і під час розмови Борис придумав ідею: а що, як ми надамо цьому інструменту командного рядка більше дозволів? Наприклад, дозволити йому читати, записувати файли та виконувати команди?

Він намагався. Потім настає момент стати свідком дива. Борис додав оновлений інструмент у кодову базу Anthropic і поставив кілька запитань. Клод почав самостійно досліджувати файлову систему — читав файл, бачив імпортний оператор всередині, а потім читав посиланий файл, заглиблюючись шар за шаром, поки не знайшов відповідь. «Це мене потрясло», — згадує Борис, — «і я ніколи не користувався таким інструментом. ”

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

Борис почав працювати з цим інструментом щодня, а потім поділився ним із кількома колегами. Через два місяці, у листопаді, вони випустили збірку. Дані перебільшені: у перший день працюють 20% інженерів; 5-й день — 50%.

У цей час виникає цікава дискусія: чи варто його оприлюднювати зовнішньому світу? Причина опозиції дуже реальна: якщо ця річ справді така сильна, як ми думаємо, чи не було б добре залишити її як «секретну зброю»? Чому відмовлятися від конкурентної переваги? Зрештою, Anthropic вирішив опублікуватися. Логіка така: основна місія Anthropic — вивчати безпеку моделей, і найкращий спосіб вивчати безпеку — це реально використовувати ці інструменти. Тепер, коли Claude Code був внутрішньо перевірений для широкого використання, його випуск дасть більше уявлення про можливості та безпеку моделі.

У травні 2025 року Claude Code офіційно став публічним. Через три місяці використання зросло у 10 разів, а річний дохід перевищив 500 мільйонів доларів. Цікаво, що Boris спочатку призначався для програмістів — звідси й назва «Claude Code». Але одного дня він пройшов повз робочу станцію дата-сайентіста і побачив, що на іншому екрані працює Claude Code. "Чому ти це використовуєш?" "Я попросив його допомогти мені писати запити та візуалізувати." Зараз дата-сайентісти Anthropic мають таку роботу, а деякі водять кілька одночасно. Пристрій для прослуховування, оскільки йому надали кілька додаткових дозволів, став продуктом вартістю сотні мільйонів доларів. Це, мабуть, найкращий доказ «перевищення продукту»: можливості моделі завжди присутні, чекають, поки хтось її випустить.

[2] 90% коду написано нею — філософія технічного відбору Claude Code Claude Code має 90% власного коду. Звучить як трюк, але насправді це завдяки їхній технічній логіці прийняття рішень. Давайте спочатку розглянемо технологічний стек: TypeScript пише основну частину, React використовує фреймворк Ink як інтерфейс терміналу, open-source Yoga від Meta займається системою верстки, а Bun відповідає за створення та пакування. Чому варто обрати ці технологічні стеки? Тому що вони знаходяться «в межах розподілу». «Про розподіл» — це термін у сфері ШІ. Це означає, що модель бачила багато такого коду і добре з ним справляється. TypeScript і React — саме там, де Клод сильний. Якщо ви оберете непопулярний фреймворк, модель має «навчитися», і ефект буде скомпрометований. Цей вибір веде до чудового циклу: написати Claude Code з техностеком, у якому Клод добре розбирається, а потім писати більше Claude Code за допомогою Claude Code. 90% пишеш про себе, так це й виникло. Їхні архітектурні рішення однаково лаконічні. Claude Code працює локально. Немає контейнерів Docker, немає хмарних пісочниць — просто читання та запис файлів і виконання команд безпосередньо на комп'ютері.

Чому він так спроектований? Борис відповідає: «Кожного разу, коли ми приймаємо дизайнерське рішення, ми майже завжди обираємо найпростіше рішення. Працювати локально — найпростіша відповідь. ” Ця простота поширюється на всю філософію продукту: писати якомога менше бізнес-логіки і нехай модель буде головним героєм. «Можливо, це звучить трохи дивно», — сказав Борис, — «але ми хочемо, щоб користувачі відчували модель якомога «автентичніше». Багато продуктів на базі ШІ додають багато основ — додаткові елементи інтерфейсу, функції доступності — і в результаті модель обмежена. Ми хочемо зробити інтерфейс максимально компактним. ” Щоб не було просто, кожного разу, коли Claude випускає нову модель, вони значно оптимізують код. Наприклад, коли вийшла Claude 4.0, вони прибрали близько половини системних підказок, бо нова модель більше не потребувала цих «милиць». Кількість інструментів також оптимізується — видаліть, якщо можете, об'єднуйте, якщо можете. Всю архітектуру Claude Code можна узагальнити трьома аспектами: визначення інтерфейсу та відкриття інтерфейсу для модифікації моделі, відкриття інструментів для виклику моделі, а потім відкладання інформації. Звісно, простота не означає, що немає складних деталей. Система дозволів — це виняток. Адже виконувати команди ШІ на вашому комп'ютері — це ризиковано. Рішення Claude Code — запитати вас перед виконанням: чи хочете ви схвалити цю операцію? Ви можете схвалити лише цього разу, затвердити пізніше або відхилити. Система дозволів підтримує багаторівневу конфігурацію — для кожного проєкту, користувача, компанії. Teams можуть ділитися профілями, щоб додавати до білого списку популярні команди безпеки. Принципи, що лежать в основі цього дизайну дозволів, такі: Якщо ви почнете Claude Code, це нічого не змінить без вашої згоди. Але водночас необхідно надати користувачам можливість «делегування» — у випадку вашого довіри ви можете пропустити посилання на підтвердження. Просто, але не елементарно. Стриманість, але не відсутність функціональності.

[3] 20 прототипів за два дні — як виглядає ітерація продукту в епоху ШІ Раніше, коли я робив прототипи продукту, міг зробити два за два дні, що вважалося ефективним. Борис зробив 20 за два дні. Це не перебільшення, а справжній запис його розробки функції списку справ у Claude Code. Він навіть ділився підказками та скріншотами кожного кроку. Давайте розглянемо, як ці 20 архетипів ітеруються. У першій версії він хотів, щоб список справ з'явився під найновішим викликом інструментів. Запит короткий: «Замість того, щоб з'являтися todo при введенні, показуйте фіксований список справ над вхідним полем із сірим заголовком '/todo (1 of 3)'». Після перегляду ефекту я був не дуже задоволений. У другій версії він відображається в рядку при кожному оновленні ToDo. Запит: «Замість того, щоб відображати список справ, відтворіть назву інструменту жирним заголовком, коли модель починає обробляти завдання.» Зберігайте дисплей прогресу як «крок 2 з 4». ” Все ще неправильно. У третьому та четвертому виданнях він намагався створити «інтерактивну пігулку» — маленький квадрат внизу екрану, на який можна клікнути, щоб побачити прогрес. "Додайте таблетку завдань під введення тексту, схожу на фонове завдання, з показом 'todos: 1 of 3'." Потім: «Зробіть цю таблетку інтерактивною, як пігулка для фонового квесту.» ” Це трохи цікаво, але недостатньо добре. У п'ятому та шостому виданнях він змінив свою думку: зробити «шухляду», яка висувається справа. "Відкрий попередні пігулки та назви, а натомість покажи список справ праворуч від входного вікна, по центру, розділений сірим роздільником." "Трохи нервово, можеш зробити з цього анімацію шухляди?" Виглядає круто, але його практичність викликає сумніви. У сьомому та дев'ятому виданнях він перемістив список справ над входним полем і експериментував із різними стилями урізання та заголовків. "Якщо їх більше п'яти, це показує '... та ще 4'", "Додайте сірий заголовок 'Todo:'". Відповідь — це все ближче і ближче. У десятому та двадцятому виданнях він почав розуміти, як поєднувати списки справ із анімаціями завантаження. Остаточне рішення — розмістити інформацію про прогрес поруч зі спінером (індикатором навантаження) для максимізації видимості. Після релізу користувачі повідомили, що хочуть побачити повний список справ. Тож додається ще одна ітерація: натисніть Ctrl+T, щоб розгорнути всі кроки. Це версія, яка зараз доступна онлайн.

Протягом усього процесу підказки Бориса були дивовижно короткими — здебільшого одне-два речення. Але кожна версія — це прототип, який реально можна запустити, а не статичний креслення, не PPT. Він може дійсно протестувати і підтвердити цю функцію, щоб переконатися, чи працює вона добре. Традиційний процес розробки продукту полягає в тому→ як ідея обговорення → малювання вайрфреймів → виконання високоякісного дизайну → розробки → тестування → запуску в ефір. Кожен крок потребує часу, і кожен може застрягти. Тепер потік стає таким: Ідея → Одне речення → виконуваний прототип → Якщо щось не так, повторіть це. Це насправді вимагає від розробників змінити своє мислення, щоб адаптуватися до цього процесу розробки. Раніше роль прототипів полягала в «перевірці ідей» — бо вартість прототипування була високою, і потрібно було ретельно обдумувати перед цим. Тепер прототипи стали «дослідженням можливостей» — оскільки вартість створення прототипів низька, їх можна спочатку зробити, а потім викинути. Борис казав, що при використанні Claude Code він часто пропускає етап малювання креслення і просто створює робочу версію, яка є більш інтуїтивною, ніж будь-що інше. Щоденний ритм роботи команди Claude Code такий: кожен інженер запускає близько 5 PR на день, 60-100 релізів внутрішньо на день і 1 зовнішній реліз на день. 5 особистих рекордів на день, що для більшості компаній немислимо. Uber переживає найінтенсивніший період реструктуризації, і непогано мати змогу досягати середнього розміру особистий рекорд щодня. Коли інструменти змінюються, змінюється ритм, і спосіб мислення має змінитися.

[4] Переробив термінал командного рядка з інтегрованим ШІ Термінали командного рядка існують уже десятиліттями, чому їх потрібно переробляти саме зараз? Бо до LLM термінали не надто зосереджувалися на інтерактивному досвіді. Традиційний командний рядок — це питання і відповідь: ви вводите команду, вона повертає результат, і все готово. Жодного діалогу, жодного контексту, жодного зворотного зв'язку в очікуванні. Ти дивишся на миготливий курсор і не розумієш, що відбувається на задньому плані. Claude Code був першим продуктом, який справді потребував замислення про «термінальний UX». Вони додали кілька дрібних деталей, які виглядали непомітними, але при використанні відчувалися зовсім інакше. По-перше: контекстуальні підказки завантаження. Коли модель мислить, екран може генерувати релевантні підказки на основі поточного відображення завдання: наприклад, «читати структуру коду» або «думати про рішення». Це невеликий штрих, але він надає інструменту «індивідуальності». Ви відчуватимете, що вона працює наполегливо, а не застрягла. Борис каже, що востаннє бачив таку приємну маленьку взаємодію, коли Slack був новачком у процесі адаптації. По-друге: поради щодо навчання під час очікування. Коли Клод виконує довге завдання, внизу екрана з'являються поради, наприклад: «Ви можете натиснути Esc, щоб перервати поточне завдання» або «Спробуйте /help to see all the command». Командний рядок використовується для навчання командного рядка, що є простим і розумним. Третя історія ще більш захоплююча: рендерер Markdown. За день до релізу деякі інженери скаржилися, що вкладені списки некрасиві, а інтервали між абзацами неправильні. Проблема в рендерері Markdown. Борис спробував усі рендерери на ринку, і жоден із них не виглядав добре в терміналі. Тож він провів день, користуючись Claude Code, щоб написати парсер і рендерер Markdown з нуля. Так, за день до звільнення. Так, пишіть з нуля. Так, сам Клод Код. В результаті цей «поспішний» рендерер виглядає краще за всі готові рішення. Вони випустили його безпосередньо. Борис вважає, що жоден інший термінал зараз не має такої ж якості рендерингу Markdown. Ця історія ілюструє одну річ: коли у вас є достатньо хороший інструмент програмування ШІ, вартість «створення власних коліс» значно падає. Компроміс «просто використовуй» тепер може перетворитися на «тоді зроби краще». Стародавня інтерфейсна форма терміналу командного рядка відроджується з додаванням LLM. Термінал залишається тим самим, але через додавання ШІ нам потрібно серйозно подумати, як зробити так, щоб люди могли краще спілкуватися з ШІ в терміналі.

[5] ШІ пронизує кожне зв'язок — «комплексний ШІ» експеримент інженерної команди Інженерна команда Anthropic, мабуть, є одним із найекстремальніших способів застосування інструментів ШІ на сьогодні. Це не лише про написання коду, а про кожен аспект проєкту. Перевірка коду: Перший перегляд усіх PR виконує Claude Code, другий — інженери. Борис каже, що Claude Code може знайти багато проблем з першого проходження. Ця функція спочатку використовувалася лише внутрішньо, але пізніше її зробили публічною, щоб усі могли використовувати Claude Code для перевірки безпеки. Write tests: Тестовий набір Claude Code майже повністю написаний Claude Code. «Раніше, якщо хтось піднімав PR і не писав тест, я вагався щось сказати — це здавалося як «pick-and-point», — сказав Борис. Але тепер, з Клодом, написання тесту — це слово, яке підказує, і немає виправдання не писати його. ” Реагування на інциденти: Інженери Oncall просять Claude Code допомогти проаналізувати корінну причину (корінну причину проблеми). Він отримує релевантні обговорення зі Slack, журнали помилок із Sentry, дані з різних систем моніторингу та аналізує їх синтетично. Борис каже, що Claude Code знаходить Root Cause швидше, ніж людина в деяких сценаріях. Сортування проблем на GitHub: Коли з'являється нова проблема, Claude Code спочатку проводить аналіз, а потім інженер запитує, чи можна це реалізувати. Борис каже, що приблизно у 20%–40% випадків це можна зробити з першого разу. Діаграми та запити: Дані продукту зберігаються в BigQuery, і майже всі запити та візуалізації генеруються у Claude Code. Інженери навіть дозволяють безпосередньо виводити ASCII-діаграми.

Найбільше мене здивувало відродження TDD (тест-орієнтованої розробки). TDD — це стара концепція: спочатку пишіть тести, потім код, який проходить тести. Теоретично це добре — змушує спочатку подумати, чого ти хочеш. Але на практиці більшість вважає його надто повільним і громіздким, тому цей метод поступово маргіналізований за останні десять років. Але Борис казав, що після використання Claude Code він зробив багато TDD: "Я почну з того, що попрошу модель написати тест і скажу, що тест зараз провалиться, не намагайся його пройти. Потім я попросив його написати код для реалізації функції і дати тесту пройти, але не змінювати сам тест. ” "Коли модель має чітку мету для ітерацій — наприклад, юніт-тест чи мок — вона працює дуже добре." Він конкретно зазначив, що Claude 4.0 — це перша серія моделей, яка дозволяє моделям писати більшість тестів. Попередні версії могли написати частину, але вимагали багато людського втручання. Також з'явилася нова концепція: мульти-клаудинг. Це означає одночасно запускати кілька екземплярів коду Клод, що дозволяє їм паралельно виконувати різні завдання. Сід каже, що часто так робить — запускає кілька агентів під час зустрічей і повертається пізніше, щоб побачити результати. Anthropic виявив, що 25% підписників Max (преміум-користувачів, які коштують $100-$200 на місяць) щодня мультиклаудують. Це цікава зміна. Програмування завжди було «однопоточною» діяльністю: можна робити лише одну річ одночасно і перемикатися лише тоді, коли код переглядається або розгортається. Але тепер «паралельне програмування» стало можливим — ви можете просувати кілька напрямків одночасно. Звісно, тут багато невідомого: чи справді паралельна робота ефективніша, чи вона просто відчувається ефективнішою? Які типи завдань підходять для паралелізму? Чи виникне проблема, якщо кожен агент отримує менше уваги? Ці питання ще не мають відповіді. Але у нас є новий інструмент для експериментів. Нарешті, поговоримо про одну справу. Компанія планувала провести міграцію фреймворку, і оцінювали, що це займе два інженерні роки — два роки для одного інженера або два з половиною місяці для десяти інженерів. Вони використовували Claude Code, і один інженер зробив це за два тижні. Борис казав, що раніше ставився скептично до таких тверджень, але подібні історії чули надто багато разів.

[6] Триденний хакатон — як народилася функція Subagents Натхнення для цієї функції в Subagents походить із допису на Reddit. Дехто каже, що він відкривав п'ять екземплярів Claude Code одночасно, встановлював різні ролі для кожного екземпляра, а потім використовував файлову систему для спілкування між собою. Коли Сід Бідасарія побачив цей пост, його перша реакція була: Цей геймплей класний, але користувачі не повинні так кидати гру. Ми повинні зробити це вбудованою функцією продукту. Так сталося, що компанія провела триденний внутрішній хакатон, і Сід вирішив використати ці три дні для цього. У перший день команда з ентузіазмом розробила різноманітні складні топології агентів: комунікація через шину повідомлень між агентами, асинхронний режим, взаємодії багато до багатьох...... Картина прекрасно намальована, а концепція просунута. Наступного дня вони зрозуміли, що це здається неможливим. Проблема не в технічній реалізації — можна створювати складні шаблони. Проблема в тому, що користувачі не можуть це зрозуміти. Інтерфейс Claude Code — це простий термінал, як допомогти користувачам зрозуміти такі складні режими спілкування агентів у такому простому інтерфейсі? Вони вирішили почати спочатку і повернутися до фундаментального питання: яка найпростіша форма, яку може використовувати середній розробник? Вони встановили собі два обмеження: По-перше, не вигадуйте нічого нового. Використовуйте лише ті можливості, які вже має Claude Code — команду "/" та .md-файли. По-друге, не спілкуйтеся між агентами. Перейдіть до простого патерну оркестрації: є головний агент, який може викликати дочірнього агента, і дочірній агент повертає результат після виконання завдання — і все. Вони також поспілкувалися з дослідницькою командою Anthropic. Дослідники працюють над багатоагентними патернами, але висновок полягає в тому, що досі невизначено, чи працюють складні топології агентів. Це додає їм впевненості: оскільки навіть дослідницька команда каже, що складність не обов'язково є хорошою, краще зробити просту версію. Наприкінці третього дня вони зробили робочу версію. Користувачі можуть визначати ролі та можливості підагентів у .md-файлах (наприклад, «фронтенд-агенти: з використанням React 19 і Next.js»), Claude Code викликає їх за потреби, або користувач може запускати їх вручну. Після хакатону, після невеликого доопрацювання, рубрика запускається. Тепер можна визначити різних ексклюзивних субагентів: бекенд-агенти з експертизою аудиту безпеки, фронтенд-агенти, знайомі з конкретними фреймворками, та QA-агенти, які спеціалізуються на написанні тестів...... Вони можуть працювати паралельно у фоновому режимі, кожен виконує свою власну роль. Багато команд вагатимуться скасовувати свої складні плани на хакатоні, адже вони цілий день малюють і обговорюють, і мають почуття. Вміти визнати, що «цей шлях не працює», повалити його і почати з нуля, потрібна мужність і віра в «простоту». Простота — це не лінь. Найпростіше — знайти форму, яку користувач справді може використовувати, серед численних можливостей.

[7] Якою буде інженерна команда в майбутньому? Деякі можна використовувати як довідник, а деякі не можна скопіювати Борис сказав: «Програмування тепер таке веселе. Останній раз я так почувався, коли вперше писав код на графічному калькуляторі в середній школі. Те чарівне відчуття, якого я давно не відчував, але тепер воно повернулося. ” Сід відчуває схоже: «Є дві речі, які мене захоплюють. По-перше, це швидкість, з якою ми випускаємо, іноді здається, що це надто швидко. Друга — це багато експериментального простору: хоча попередня робота була швидкою, те, що я робив, було більш рутинним, і, знаючи відповідь, це було просто виконання. Тепер усе інакше: модель змінюється кожні три місяці, і нам доводиться постійно переосмислювати, як ми все робимо. ” Ці почуття дуже реальні й заразні. Але перш ніж говорити про «майбутнє інженерних команд», не забуваймо про специфіку Anthropic. По-перше, Anthropic — це дослідницька лабораторія, а не компанія з виробництва продуктів. Її основна місія — досліджувати безпеку та можливості ШІ, а продукт — це засіб, а не мета. Це означає, що вони мають набагато вищу толерантність до «швидких експериментів», ніж середня компанія. По-друге, їхній основний продукт — це сама модель Клода. Claude Code — це лише «оболонка» моделі. Тож «видалення коду, щоб модель могла більше працювати» — це природний вибір для них, але для інших компаній це може означати передачу основної бізнес-логіки чорній скриньці. По-третє, усі працівники мають необмежений доступ до Claude, включно з найдорожчою моделлю Opus. У більшості компаній плата за підписку на ШІ — це бюджетний пункт, за який потрібно боротися, і ним не можуть користуватися всі. По-четверте, у команді лише десяток людей, і процес мінімальний. Вони майже не використовують прапорці функцій, бо вони «занадто повільні». Це немислимо для продукту з великою базою користувачів і високою вартістю помилок. Тож копіювати команду Claude Code напряму не завжди реалістично для більшості команд. Але є речі, з яких можна навчитися. Мислення швидкого прототипування: Навіть якщо ви не можете робити 10 прототипів на день, чи можна змінити з «один раз на два тижні» на «три на тиждень»? Інструменти змінилися, і очікування щодо «наскільки швидким має бути прототип» слід оновити. Огляд коду за допомогою ШІ: Нехай ШІ робить перший огляд, а людина — другу. Цей процес не залежить від необмеженого доступу до API, який більшість команд можуть спробувати. Відродження TDD: Якщо писати тести стає достатньо просто, «немає часу писати тести» більше не є виправданням. Це може бути недорогим способом покращити якість коду. Цінність інженерів, орієнтованих на продукт, посилюється: у команді Claude Code немає дизайнерів чи менеджерів проєкту, лише кілька інженерів, орієнтованих на продукт. Інструменти ШІ значно розширили можливості цього «full-stack talent».

Звісно, є речі, які інструменти не замінять. Борис зміг вибрати найкращий із двадцяти архетипів, бо був осудливим — він знав, що «відчувається правильно», а що просто «виглядає добре». Цей смак — результат 17-річного досвіду в розробці програмного забезпечення, а не те, що може дати ШІ. Команда склала складний план у перший день, а наступного дня могла безжально скасувати і почати все спочатку, що теж є людським судженням. Знати, коли видаляти код, а коли його зберігати, те саме, що стосується цієї архітектурної інтуїції. ШІ робить виконання швидшим, але не робить «знання, що робити» простішим. Натомість, через зниження вартості виконання рішення «що робити» стало важливішим — можна швидко зробити 20 версій, але потрібно знати, яка з них правильна. Як виглядатиме програмна інженерія через кілька років? Ніхто не може точно передбачити. Але сьогоднішня команда Claude Code може стати певною репетицією на завтра для багатьох — швидші ітерації, менше «руху цегли», більше судження та прийняття рішень. Інструменти змінюються. Що залишається незмінним — це те, що остаточне рішення все ще приймають люди.