*[Enwl-misc] Для инженеров: Следующее поколение разработчиков программного обеспечения будет архитекторами, а не кодерами.
ecology
Крейг Адам
23 сентября 2025 г.
Следующее поколение разработчиков программного обеспечения будет архитекторами, а не кодерами.
Нажмите Enter или щелкните, чтобы просмотреть изображение в полном размере.
Фото Энгина Акьюрта на Unsplash
Маятник качается
Разработка программного обеспечения всегда отличалась крайностями. Вначале мы всё планировали. Спецификации были священны. Архитектурные схемы существовали раньше, чем каждая строчка кода. И каждое изменение ощущалось как управление грузовым судном — медленное, бюрократическое и подробнейшим образом документированное.
Затем появился Agile, и маятник резко качнулся в другую сторону. Мы приняли скорость, итерации и несовершенство. «Рабочее ПО вместо исчерпывающей документации» стало боевым кличем нового поколения. Быстрая выдача стала важнее, чем сделать всё правильно с первого раза. И, справедливости ради, этот сдвиг открыл дорогу колоссальной производительности. Он навсегда изменил культуру разработки ПО.
Сейчас мы вступаем в новую эру — эпоху инструментов искусственного интеллекта, способных генерировать код по предложению. Такие инструменты, как GitHub Copilot и Claude Code, меняют само понятие разработчика. Речь уже не только о написании кода, но и о проектировании среды, в которой он пишется.
А этот маятник? Он снова качнулся в обратную сторону.
Не полностью к водопадной модели, а к более осознанной практике. Где дизайн и документация снова важны — не для стажёра или следующего инженера, а для машины, которая сгенерирует следующие 10 000 строк кода. Мы уходим от эпохи «вибрационного кодера» — тех, кто подсказывает и отправляет, не понимая последствий, — и вступаем в мир, где продуманная архитектура, управляемая человеком, становится краеугольным камнем высококачественного программного обеспечения.
Когда-то я работал под руководством технического директора, который был искренне поражен тем, как мало внимания уделяется предварительному обдумыванию при разработке нашего программного обеспечения. В команде из более чем сотни разработчиков он попросил меня решить обманчиво простую задачу: заставить людей тратить больше времени на обдумывание, прежде чем начать печатать. В то время это могло показаться чем-то вроде движения против течения Agile. Но, глядя на то, куда движется отрасль сейчас — когда ИИ генерирует большую часть кода, а разработчики переходят на функции системного проектирования и контроля, — думаю, он бы испытал облегчение. Маятник наконец-то качнулся обратно в сторону преднамеренности.
Потому что, если мы позволим машинам вибрировать без ограничений, мы погрязнем в технологическом долге. Если мы разработаем системы, в которых они будут работать, мы сможем масштабироваться быстрее и эффективнее, чем когда-либо прежде.
Кодирование вибрации и инжиниринг подсказок
«Просто почувствуйте это».
Эта фраза, популяризированная Андреем Карпати, — это краткое обозначение нового поколения разработки программного обеспечения, где инструменты ИИ выполняют основную работу. Нужен компонент React? Запросите подсказку. Интеграция с API? Запросите подсказку. CRUD с пагинацией, обработкой ошибок и состоянием загрузки? Один хороший запрос может решить 80% проблемы.
Это и есть кодинг в атмосфере: сочетание подсказок на естественном языке, ИИ-инструментов и быстрой итерации. Это ощущается как магия. И для некоторых разработчиков, особенно новичков, это единственный способ кодирования.
Привлекательность очевидна. Кодирование в стиле Vibe устраняет трудности. Оно избавляет от шаблонного кода. Оно увеличивает скорость работы. Вы можете создать прототип за полдня, на что ещё несколько лет назад у команды ушли бы дни.
Но вот в чем проблема: код, написанный со скоростью мысли, имеет тенденцию стареть, как молоко, а не как вино.
Кодирование в стиле Vibe способствует поверхностному пониманию. Оно ставит во главу угла то, что выглядит сейчас, а не то, что будет актуально через полгода. Архитектурные решения принимаются неявно, согласно модели. Шаблоны внедряются без проверки. И вскоре вы оказываетесь в ловушке сгенерированной сложности, которую никто до конца не понимает, даже тот, кто её разработал.
При ответственном использовании виброкодирование — это суперспособность. Безрассудное использование — билет в один конец в ад технологического долга.
Решение не в том, чтобы сбавлять обороты, а в том, чтобы сменить руководителя. Нам не нужно больше виброкодеров. Нам нужны люди, думающие о системе, в которой работает ИИ. Нам нужны архитекторы, способные использовать мощь виброкодирования, не будучи им захваченными.
Проектирование фреймворков вместо функций
Работа по написанию отдельных функций автоматизируется. Это не просто предположение — всё происходит в реальном времени. ИИ может генерировать корректный резолвер TypeScript, схему GraphQL или виджет Flutter за считанные секунды. Результат? Тактический уровень разработки становится общедоступным.
Но стратегический уровень — это все еще во многом человеческая игра.
Современные разработчики программного обеспечения уже не просто строители; они становятся архитекторами. Не в смысле раздувания корпоративного титула, а в буквальном смысле: их работа заключается в проектировании структур, в которых создаётся программное обеспечение. Это означает курирование библиотек, соблюдение границ и определение шаблонов, которые позволяют коду, сгенерированному ИИ, легко интегрироваться и масштабироваться.
Именно здесь живет ориентированная на будущее разработка — не в цикле, который отображает компонент, а в решениях о том, каким должен быть этот компонент, как он взаимодействует с остальной частью системы и почему он вообще существует.
Сдвиг едва заметный, но мощный:
Вместо того чтобы спрашивать: «Какой наилучший способ реализовать эту конечную точку?», мы спрашиваем: «Какой контракт будет самым чистым для этой части системы?»
Вместо «Как исправить эту ошибку?» спрашивается «Как полностью предотвратить этот класс ошибок с помощью структуры?»
Вместо того чтобы тратить часы на рефакторинг файлов, мы создаем ограничения, которые изначально предотвращают появление плохих шаблонов.
В этой новой парадигме наиболее ценными разработчиками являются не те, кто пишет больше всего кода, а те, кто пишет лучшие системы для работы кода. Фреймворки, каркасы, шаблоны и защитные барьеры, которые позволяют ИИ эффективно работать, не создавая беспорядка.
Задача не в том, чтобы перепрограммировать машину, а в том, чтобы передумать.
Нажмите Enter или щелкните, чтобы просмотреть изображение в полном размере.
Фото Александра Пеллаеса на Unsplash
Новая аудитория
В старом мире мы писали чистый код и подробную документацию для будущих разработчиков. Вы хотели, чтобы ваш будущий коллега по команде — или вы сами — могли разобраться в этом, не вырывая на себе волосы. Хорошие комментарии, чёткая структура, логичные названия.
Теперь следующим «разработчиком» станет ИИ.
Этот сдвиг меняет всё. Вместо того, чтобы писать для начинающего разработчика, который только набирает обороты, мы пишем для модели, способной сгенерировать 500 строк кода за несколько секунд, — но только если мы дадим ей прочную основу. ИИ — это машина, сопоставляющая шаблоны. Он рассуждает не как человек. Он не просит пояснений. Он делает ровно то, чему его учат ваша структура, наименования и примеры — независимо от того, имели ли вы это в виду.
Это означает, что наши системы должны быть понятны машинам. Нам необходимо:
Предсказуемые закономерности — чтобы ИИ мог видеть, как выглядит «правильно».
Жесткие ограничения — чтобы не зайти на опасную территорию.
Специально подобранные примеры — потому что то, что вы показываете ИИ, становится тем, что он повторяет.
Чистые абстракции — не только для людей, но и для жадных до токенов моделей, пытающихся рассуждать на основе файлов.
Подумайте об этом так: мы уже не просто пишем код, мы проектируем обучающие данные для нашего будущего второго пилота. Каждая хорошая функция, каждый правильно обозначенный тип, каждая тщательно прописанная граница — это своего рода «хлебные крошки», которым будет следовать модель, заполняя пробелы.
Это не просто хорошая инженерная гигиена — теперь это основа скорости.
Так что да, мы по-прежнему заботимся об именах, единообразии и интерфейсах. Но не только потому, что это помогает людям освоиться. Теперь это помогает нашим коллегам-машинам создавать следующие 100 функций, не создавая хаоса.
Стать участником
Вот настоящая работа завтрашних разработчиков: не просто заставить что-то работать, а сделать это очевидным, воспроизводимым и расширяемым с помощью машин.
Новый манифест
На протяжении двух десятилетий Agile-манифест определял принципы разработки программного обеспечения. Его принципы избавили нас от раздутых спецификаций и 18-месячных каскадных графиков. Мы перестали писать документы в Word и начали выпускать MVP. Это был огромный шаг вперёд.
Но мы перестарались.
Agile научил нас ценить «работающий софт выше исчерпывающей документации». Это было справедливо — до тех пор, пока работающий софт не стал синонимом «просто сделай это». В эпоху вайб-кодинга и подсказок с помощью ИИ этот принцип начинает давать сбои.
Потому что программное обеспечение может работать… но не всегда это понятно.
Теперь, когда ИИ генерирует всё больше и больше кодовой базы, маятник снова качнулся. Мы заново открываем ценность старых вещей: документации, спецификаций, ограничений. Но не потому, что они нужны людям, а потому, что они нужны нашим коллегам по ИИ.
Основные ценности Agile не являются недействительными, но некоторые из них требуют переосмысления. В новом мире:
Мы можем ценить комплексную структуру больше, чем работающее программное обеспечение , поскольку программное обеспечение, которое работает сегодня, но выходит из строя завтра, является обузой.
Мы можем ценить организованные системы больше, чем людей и взаимодействия , — потому что люди все больше становятся машинами.
Мы можем ценить реагирование на контекст больше, чем реагирование на изменения , потому что именно стабильность и повторяемость, а не хаос, обеспечивают быструю итерацию.
Это не возврат к бюрократии. Это появление новой гибкости: основанной на продуманных ограничениях, прочной архитектурной структуре и оптимизируемых машинами каркасах.
Подумайте об этом так: в 2005 году узким местом была скорость. В 2025 году узким местом станет направление.
Agile помог нам двигаться вперёд. Теперь нам нужна карта.
Нажмите Enter или щелкните, чтобы просмотреть изображение в полном размере.
Фото Альдебарана С. На Unsplash
Следующее поколение
Если сегодня вы старший разработчик или технический руководитель, ваша роль уже меняется — даже если ваша должность еще не изменилась.
Вы больше не просто пишете функции. Вы определяете среду, в которой эти функции создаются. Это означает владение архитектурой, внедрение шаблонов и проектирование систем, которые направляют не только участников команды, но и, всё чаще, ИИ-команд.
Чтобы эффективно руководить в этой новой ситуации, вот на чем следует сосредоточиться:
1. Думайте системно, а не фрагментарно
Уметь хорошо писать код уже недостаточно. Нужно формировать системы:
Где проходит эта граница?
Какие решения необходимо принять один раз и закодировать?
Какие абстракции сократят отток клиентов с течением времени?
Кодовые базы сейчас растут быстрее, чем когда-либо. Слабая структура приводит к быстрому коллапсу.
2. Создавайте ограждения, а не просто элементы
Задавайте шаблоны, которым смогут безопасно следовать как люди, так и машины. Используйте типы, линтеры, наборы тестов и схемы не только для обеспечения корректности, но и для передачи намерений .
Если невозможно обеспечить поведение посредством автоматизации, обеспечивайте его с помощью понятных и воспроизводимых структур. Фреймворков, а не только библиотек.
3. Подбирайте примеры, как библиотекарь
Инструменты ИИ основаны на распознавании образов. Удачные примеры приводят к хорошим результатам. Плохие же лишь усугубляют путаницу.
Ваша кодовая база теперь — среда обучения. Наведите порядок! Устраните противоречащие стили. Документируйте намерения, когда это важно. Относитесь к этому так, как будто готовите обучающие данные — ведь в каком-то смысле так и есть.
4. Владейте уровнем обзора
ИИ может генерировать функциональный код. Но чего он пока не может, так это принимать продуманные архитектурные компромиссы.
Это ваша работа. Проверяйте код на согласованность, а не только на правильность. Ищите закономерности, которые создают долгосрочную сложность. Будьте хранителем качества, а не просто сторожем для ошибок.
5. Не будьте гениальным разработчиком
Самый умный человек в комнате — не тот, кто решает больше всего проблем, а тот, кто не допускает их возникновения.
Лидерство в этом контексте означает создание систем, масштабируемых за пределами ваших индивидуальных усилий. Это означает запрограммировать суждения в систему, а не держать их запертыми в голове.
Следующее поколение разработчиков будет оцениваться не по тому, насколько быстро они могут поставлять код, а по тому, насколько хорошо они создают системы, которые позволяют другим поставлять код безопасно, устойчиво и разумно.
TL;DR
Будущее разработки программного обеспечения не будет определяться тем, кто печатает быстрее всех. Эта гонка уже закончилась — и победили машины.
Но мы не без работы. Просто теперь мы играем по-другому.
Самые ценные разработчики следующего десятилетия будут не программистами, гонящимися за сиюминутной скоростью. Они будут проектировщиками долгосрочных систем — архитекторами, способными использовать всю мощь ИИ, сохраняя при этом ясность, целостность и направление.
Маятник снова качнулся. От перегруженных документацией спецификаций к хаосу «просто отправьте», а теперь к новому центру: продуманному проектированию систем, оптимизированных не только для людей, но и для взаимодействия с ИИ. Мы не собираемся возвращаться к старому. Мы движемся к чему-то более сложному и мощному, потому что это позволяет нам масштабироваться, не теряя контроля.
В этом новом мире скорость по-прежнему важна. Но направление важнее. Структура важнее. Принципы важнее.
Итак, да — отправляйте быстро. Но делайте это с умом. Создавайте долговечные системы. И пишите для следующего поколения программистов: не для стажёров, не для коллег, а для интеллектуальных машин, которые изо всех сил стараются следовать вашему примеру.
Будущее программного обеспечения не просто написано. Оно спроектировано.
Программная инженерия
Крейг Адам
Ecological North West Line * St. Petersburg, Russia
Independent Environmental Net Service
Russian: ENWL (North West), ENWL-inf (FSU), ENWL-misc (any topics)
English: ENWL-eng (world information)
Send information to en...@enw.net.ru
Subscription,Moderator: en...@enw.net.ru
Archive: http://groups.google.com/group/enwl/
New digests see on https://ecodelo1.livejournal.com/
(C) Please refer to exclusive articles of ENWL
-------------------------------------