How AI will change software engineering (Рубрика Engineering)

Посмотрел интересное интервью Martin Fowler о том, что реально меняется для инженеров и тимлидов из‑за LLM и coding‑агентов. Мартин давал интервью Гергели Орошу в рамках подкаста Pragmatic Engineer. Сам разговор получился плотным (в самый раз для просмотра на 2x скорости) и ключевыми тезисами были следующие

🤖 AI - крупнейший сдвиг в разработке со времён высокоуровневых языков Фаулер ставит нынешнюю волну ИИ в один ряд с переходом от ассемблера к Fortran/C: это новая парадигма работы с кодом, а не “ещё один инструмент в IDE”.

🎲 Код становится недетерминированным - нужно мыслить “допусками” LLM не гарантирует одинаковый результат на один и тот же запрос. Фаулер предлагает заимствовать из классической инженерии мышление про допуски и запас прочности: заранее решать, где вариативность допустима, а где нужна жёсткая детерминированность и дополнительные проверки (особенно в безопасности).

👩‍💻****Тесты важнее, чем когда‑либо Тесты теперь страхуют и людей, и модель. Любой сгенерированный LLM код должен проходить такой же, а лучше - более жёсткий, набор автотестов, статического анализа и quality‑checks. Без этого “ускорение” от ИИ превращается в отложенный технический долг. На эту тему рекомендую почитать книгу "AI Engineering" и конкретно главы "Evaluation Methodology" и "Evaluate AI Systems", что я уже разбирал в подкасте с обзором книги

🤖 AI + детерминированные инструменты > AI в одиночку Один из ключевых паттернов: LLM генерирует черновой код, а предсказуемые инструменты делают массовые и безопасные трансформации - миграции, рефакторинги, форматирование.

👾 LLM особенно полезны для легаси и рефакторинга AI показывает отличные результаты в рефакторинге старых монолитов, демонстрируя понимание странных зависимостей, генерируя первые варианты рефакторинга и миграций (например, на новый фреймворк или архитектурный паттерн). Но именно люди решают, куда систему развивать и какой “целевой дизайн” считать приемлемым.

💯 Vibe coding - режим прототипов, а не продакшена Vibe coding - это создание решения, когда вы в основном говорите с агентом/IDE, почти не читая получившийся код. Это даёт огромную скорость для прототипов и одноразовых проектов, но переносить такой код в прод без ревью и тестов - гарантированные баги, уязвимости и проблемы с поддержкой.

📚 Список ключевых навыков инженера не поменялся Несмотря на хайп вокруг ИИ, по мнению Фаулера, всё ещё решают: понимание домена, умение строить абстракции и архитектуру, делать осознанные trade-offs коммуницировать с бизнесом и командой. LLM усиливают сильных инженеров, но не подменяют сами навыки.

🔁 Agile по‑прежнему про обратную связь и обучение - просто цикл стал быстрее Основные принципы Agile (короткие итерации, работа с заказчиком, постоянное обучение) остаются валидными. LLM‑инструменты лишь ускоряют цикл “придумал → набросал → проверил → переписал”, но не заменяют живую обратную связь, парное программирование и ретро.

🧠 ИИ не отменяет необходимость самому учиться программировать Фаулер подчёркивает: разработка - это всегда процесс обучения. Если постоянно “аутсорсить” мышление ИИ, не формируется внутренняя модель системы, и команда быстро прилетает в maintenance‑cliff: код есть, понимания нет. Инструменты могут ускорять, но не могут “выучить за вас”.

🚀 Совет тимлидам: начинайте с низкорисковых сценариев Внедрять ИИ лучше начать с документации, тестов, сниппетов, миграций и работы с легаси, а не с критических бизнес‑флоу. Параллельно вкладываться в автотесты, observability и инженерную культуру - тогда выгода от ИИ не будет одноразовым “демо‑эффектом”.

🌱 Совет джунам: не становитесь просто “операторами промптов” Для начинающих разработчиков ИИ - отличный репетитор: можно просить объяснить незнакомый код, показать альтернативные решения, придумать упражнения. Но если ограничиться промптами и никогда не разбираться в том, что под капотом, - роста до middle/senior не будет. Нужны свои попытки, ошибки и рефакторинги.

#Architecture #Software #AI #Engineering #ML #Data #SystemDesign