Создатель Ruby on Rails Дэвид Хайнемайер Ханссон (DHH) на прошлой неделе вызвал немало шума своими заявлениями во время кейноута на Rails World, когда рассказал, что в его компании 37signals ручное написание кода фактически умерло.
Это особенно примечательно потому, что именно 37signals создала Ruby on Rails и известна своей инженерной культурой, особенно высоким качеством кода. Кроме того, это прибыльная компания, существующая уже 27 лет. Несмотря на всё это, DHH вызвал бурную реакцию разработчиков, заявив:
«В 37signals пару недель назад мы приняли решение, которое однозначно означает: мы закончили писать код вручную. Мы буквально отказались от идеи, что в рамках обычной работы по созданию продуктов будем писать код руками.
Ручное написание кода в 37signals теперь считается исключительной ситуацией. Это как увидеть баг в Sentry: здесь что-то пошло не так; почему агент не смог создать то, что мы хотели? Ладно, возможно, какое-то время мы ещё что-то подправим за ИИ, но затем мы починим машину, починим фабрику и снова запустим процесс. Это просто признание того, что уже происходит».
DHH сравнил взросление ИИ-инструментов, которые стали очень сильны в программировании, с тем, как появление фотографии повлияло на ремесло живописи:
24 ноября 2025 года мы получили Kodak Brownie нашей эпохи. Мы получили Opus 4.5. ИИ-технологию, доступную в оболочке, которой многие могли позволить себе пользоваться и впервые почувствовать, каково это — создавать программное обеспечение в паре с новой формой интеллекта. Для меня это была переломная точка. Было всё до 24 ноября и всё после. Думаю, именно эту дату будущие учебники истории будут отмечать как точку перегиба в эпохе агентов.
Он рассказал, как 37signals приняла будущее, в котором ручного кодинга почти не осталось:
- Переход к нативным мобильным приложениям вместо web. Как известно, 37signals долго была скептически настроена к нативным iOS- и Android-приложениям и предпочитала web-версии. С появлением ИИ компания делает ставку на то, что небольшая команда сможет намного проще создавать нативные приложения, и уже работает над новыми.
- Перенос backend-сервисов на Rust вместо Ruby. Причина — производительность и то, что агенты уже достаточно хорошо пишут код Rust. Особенно примечательно слышать такое от создателя Ruby on Rails!
- Ruby on Rails остаётся для web-приложений. 37signals не отказывается от RoR, но только потому, что подход Ruby on Rails «convention over configuration» делает фреймворк удобным для работы агентов.
В завершение DHH рассказал, что больше даже не считает себя профессиональным программистом:
«Я ушёл на пенсию как профессиональный программист. Думаю, это произошло где-то четыре-пять месяцев назад, может быть, в марте. Я четверть века оттачивал код руками и любил каждую минуту. На это не стоит смотреть с сожалением; на это нужно смотреть с радостью и просто принять, что всё закончилось.
Ручное написание кода больше не является экономически продуктивной деятельностью для подавляющего большинства программистов в подавляющем большинстве компаний. По другую сторону находится новая профессия — профессиональный создатель вещей, который направляет интеллект, ещё совсем недавно существовавший только в научной фантастике.
Нам придётся пересмотреть почти всё, что мы знаем об архитектуре программного обеспечения. Очень долго нашим главным инструментом были абстракции. В эпоху агентов абстракции уже не имеют того же смысла. Мы использовали их в том числе для того, чтобы не повторяться; а теперь стоимость повторения практически упала до нуля».
Стоит отметить, что DHH выбрал довольно провокационную тему для кейноута на конференции, которую посещают инженеры, лично и профессионально погруженные в ремесло создания программного обеспечения!
Упадок ручного кодинга предсказывали давно
В первом выпуске The Pragmatic Engineer в этом году, 6 января, я писал:
«Когда ИИ будет писать почти весь код, что произойдёт с программной инженерией? Это уже не гипотетический вопрос, а мегатренд, который готов обрушиться на технологическую индустрию. (…)
Плохая новость в том, что изменения, вероятно, будут очень быстрыми. Прошёл едва год с тех пор, как идея Claude Code возникла в голове Бориса Черного, а такие инструменты, как OpenCode, Codex, Factory, Amp, Cursor и всё более способные агенты, уже меняют сам способ написания программ. Изменения всегда были частью работы в технологиях, но я не припомню, чтобы они происходили настолько быстро и одновременно по всей индустрии!»
Я пришёл к выводу, что эти изменения уже надвигаются, основываясь на собственном опыте разработки с Opus-4.6 и GPT-5.2, а также на разговорах с опытными инженерами, которые по вполне понятным причинам долго сопротивлялись ИИ-хайпу, но в итоге признали, что ИИ теперь во многих случаях способен генерировать достаточно хороший код.
Тогда я сделал несколько прогнозов о том, что произойдёт, когда ИИ-агенты начнут создавать большую часть кода для инженеров:
- Более неряшливый код
- Слабые практики software engineering начнут причинять боль быстрее
- Спрос на «кодеров», которые не являются software engineers, снизится
- Work-life balance инженеров станет хуже
- Junior-инженерам придётся очень быстро становиться senior
- Образование в computer science станет всё более обязательным для новых сотрудников
- Произойдёт огромный взрыв количества кода и программного обеспечения, за которые кому-то придётся отвечать
Пока всё это выглядит как довольно хаотичный переход, и мы, инженеры, оказываемся ответственными за гораздо больший объём кода, который не писали сами, но который всё равно работает в продакшене.
Не только инженеры переходят на агентов
В конце января я поделился подробным разбором довольно близкой мне истории: стартап из 30 человек и 15 инженеров моего брата Craft Docs, резко повернул в сторону ИИ и создал собственную AI-оболочку для неинженеров — Craft Agents — за две недели до выхода Claude Cowork и за несколько месяцев до запуска ChatGPT Work.
Craft воздерживалась от использования ИИ, когда это не приносило ощутимой пользы, однако после выхода новых моделей в ноябре 2025 года выяснилось, что большие языковые модели (LLM) полезны не только для написания кода, но и для задач, не связанных с инженерной работой, — например, для службы поддержки клиентов. В подробном разборе я приводил такие примеры использования вне разработки, которые, разумеется, помогли реализовать инженеры:
- Автоматическая сортировка отчетов об ошибках агентами
- Добавление обогащённых данных во все рабочие процессы
- «Навыки» для поддержки клиентов, например обработка feature requests
- Маркетинговая команда создаёт сайты без разработчиков
- HR автоматизирует рутинную работу
- Финансовый департамент автоматизирует персональные рабочие процессы
Craft Docs, похоже, рано поймала тренд, подключив к одной AI-оболочке и инженеров, и неинженеров. Теперь есть признаки, что другие компании делают то же самое: в OpenAI неинженерные подразделения, такие как finance, recruitment и legal, перешли на Codex в июне 2026 года:
Неинженерные команды перешли на использование AI-оболочки OpenAI, Codex, которая теперь переименована в ChatGPT Work. Источник: Inside OpenAI’s software factory
В каком-то смысле даже утешительно знать, что быстро меняются инструменты и рабочие процессы не только в разработке ПО: то же самое происходит практически со всеми функциями в технологических компаниях.
Сейчас всё очень хаотично
Буквально в прошлые выходные эмоциональный пост анонимного инженера из Big Tech задел многих людей в индустрии. Инженер под ником voxium написал:
«Состояние инженерии сейчас ужасное. Прошло полмесяца с тех пор, как я начал работать на новой позиции в большой компании.
Здесь никто ничего не знает. Спецификации, код, тесты, PRD, тикеты, решения по этим тикетам, отчёты и всё остальное — всё делается Claude Code. Никому в моей команде это не нравится.
Их заставляют выпускать как можно больше. Я неоднократно слышал от высшего руководства, что отправка кода больше не является узким местом, так почему же мы работаем медленно?
Люди работают по 12–13 часов в день просто для того, чтобы нажимать Enter. Никто ничего не читает. Люди в корпорации сами уже почти ничего не делают.
Все, буквально все — от инженера L1 до L7 — делают одно и то же. Разговаривают с Claude.
Нет никакого чувства победы. Никто не исправляет баги. На самом деле никто уже не думает. Всё делают LLM. Это ужасно высасывает душу.
Честно говоря, я бы даже не возражал, если бы нам хотя бы давали время проверить код и понять, что куда идёт. Но нет, цель — просто выпускать. Неважно, что произойдёт».
Этот пост ощущается правдивым, потому что подобное действительно происходит во многих местах с активным использованием ИИ: инженеры фактически «отдают мышление на аутсорс» LLM и в итоге перестают заботиться почти обо всём, кроме самого факта отправки чего-нибудь в прод.
Качество падает
С начала года качество программного обеспечения ухудшается практически повсюду, и значительная часть этого связана с чрезмерной зависимостью от ИИ или, если точнее, с передачей ИИ мышления и принятия решений. В июле я перенёс свой видеоподкаст с платформы Spotify после серии необъяснимых сбоев, а инженерная команда Spotify, казалось, вообще не испытывала особой ответственности или желания устранить первопричины проблемы.
Только на этой неделе Uber выпустила в продакшен новую функцию в приложении Uber Eats — новый способ выбора дополнений к заказу еды — и, судя по всему, вообще без нормального QA:
Uber Eats на этой неделе, когда я пытался заказать бургер. Сможете заметить две очевидные неряшливые ошибки на этой странице?
В новом селекторе дополнений Uber Eats я сразу заметил три бага:
- «Выберите до 999». Ни один инженер, дизайнер или PM не проверил, что произойдёт, если ресторан не укажет число разрешённых топингов или укажет абсурдно большое значение. Максимальное количество добавок, которое можно было выбрать на экране, составляло шесть, а не 999, поэтому я даже не мог выбрать опцию «999 булочек» для своего бургера.
- Неряшливое переполнение. Во времена моей работы в Uber существовало простое правило: текст никогда не должен вылезать за границы, даже после локализации.
Basilcummaynaise— базиликовый майонез по-нидерландски — нарушил это правило, но всё равно попал в прод. - Функциональные баги в селекторе. Изначально я пытался сделать заказ в любимом мексиканском заведении: боул без риса или булгура в качестве основы. Есть варианты выбрать
rice,bulgurилиnothing, но выборnothingпочему-то считается дополнительным гарниром, и приложение вообще не позволяет заказать боул без основы.
Я пользуюсь Uber Eats много лет, и это был первый случай, когда увидел настолько неряшливый релиз функции. Предполагаю, что разработчики и PM, работавшие над ней, просто «выключились», перестали нормально заниматься QA и решили, что агент сам обо всём позаботится. Я не вижу другого объяснения тому, как три бага были выпущены для всех пользователей и, по-видимому, никто их не заметил до моей публикации. К чести команды Uber Eats, они связались со мной и сейчас разбираются со всеми тремя проблемами.
Программная инженерия станет важнее, чем когда-либо
Лично я уже прошёл стадии шока и скорби из-за того, что агенты забирают на себя сам процесс написания кода. Сначала я предполагал, что эти изменения уменьшат объём работы инженеров. Но, вопреки ожиданиям, похоже, работы становится только больше:
- Нам нужно лучше понимать свойства LLM. LLM кажутся привычными, потому что умеют генерировать текст так, как раньше это могли только люди. Но они менее надёжны, всё ещё склонны к галлюцинациям, страдают от capability gaslighting (ИИ ведёт себя так, будто не умеет что-то делать, хотя на самом деле умеет) и множества других проблем. Кроме того, они могут быть дорогими и медленными.
- Нужно проектировать новые системы. Агентные «программные фабрики» теперь могут генерировать код на основе входных данных. Но как этот код валидировать? Насколько автоматизированным может быть обнаружение дефектов и других проблем? Это совершенно новая область, и нам придётся создавать новые типы систем, часто используя старые идеи. Один пример — программная фабрика OpenAI, другой — внутренняя coding-оболочка Inspect компании Ramp.
- Недетерминированные LLM могут генерировать детерминированный код. Область, которая, как мне кажется, пока недостаточно исследована и недооценена, — использование LLM для того, чтобы заменить последующее применение LLM в агентных «программных фабриках» детерминированным кодом, который сами модели генерируют. Например, вместо дорогого и медленного AI code review для каждого pull request может ли ИИ генерировать линтеры, которые находят большинство типовых проблем? Если это возможно, сложные правила линтинга будут работать быстрее, надёжнее и дешевле, чем вызовы LLM.
Новые категории систем и продуктов будут создавать инженеры, которые действительно понимают LLM и AI engineering. Сейчас большая часть венчурного финансирования направляется в AI-компании, потому что ИИ создаёт новые бизнес-модели, новые источники выручки и разрушает «традиционное» программное обеспечение. Кто бы ещё недавно мог подумать, что компании будут тратить десятки тысяч долларов на одного инженера в год на ИИ-инструменты? Или что категория AI inference providers станет настолько огромной, хотя два года назад её практически не существовало?
Эта технологическая трансформация перестроит части tech-индустрии: победители наверняка выиграют очень много, а команды и компании, выбравшие бездействие, рискуют проиграть более быстрым конкурентам. И во многих отношениях это отличная новость для нас, разработчиков, которые продолжают следить за технологиями. Компании сейчас активно инвестируют в инновации и готовы платить на верхнем уровне рынка инженерам, которые могут помочь им создавать AI-продукты или становиться AI-native.