Хабр Курсы для всех
РЕКЛАМА
Большая витрина: от крупнейших школ до частных авторов. Сравнивайте по цене, длительности, формату и выбирайте самый подходящий курс!
Поток AI и ML доступен 24/7 благодаря поддержке друзей Хабра
Комментарии 6
сама реализация хуже работает как доказательство хорошей инженерной работы
И как теперь объяснить нужность и ценность хорошей инженерной работы?
Привет! Я бы немного иначе сформулировал.
Не хорошую инженерную работу стало сложнее доказать, а хорошая реализация сама по себе становится менее достаточным её доказательством.
Код может быть отлично написан, но решать не ту задачу, не учитывать ограничения системы или не давать нужного результата в проде. Поэтому для меня ценность инженера никуда не исчезает. Просто она всё меньше определяется только тем, насколько хорошо человек умеет превратить готовую задачу в код.
Наверное, как раз поэтому интереснее смотреть на более широкую зону ответственности - какую проблему инженер решает, какие решения принимает, что учитывает и к какому результату в итоге приводит изменение.
Погоди, в цитате буквально написано, что реализация была доказательством хорошей инженерной работы, а сейчас больше нет.
Поэтому я и спросил: а что теперь является доказательством хорошей инженерной работы? Или она больше не нужна?
Я в статье не имел в виду, что реализация перестала быть доказательством хорошей инженерной работы (поэтому и написал "хуже", но не перестала). Она по-прежнему важна, просто её вес как такого сигнала становится меньше.
Если получить хорошо выглядящий и технически корректный код стало дешевле, самого факта хорошей реализации уже недостаточно, чтобы судить обо всей работе инженера. Поэтому следующим абзацем я как раз расширяю картину: важно, правильно ли человек понял проблему, какой компромисс выбрал, учёл ли систему вокруг, безопасно ли выкатил изменение и получил ли нужный результат.
То есть код никуда не исчезает и хорошая инженерная работа тем более не становится ненужной. Просто смотреть приходится шире самой реализации.
Я не вижу исследований, которые показывают, что LLM реально дают экономический выигрыш на всей цепи внедрения (E2E) для Еnterprise систем даже если "код всё лучше пишут AI агенты". Не кусочек "написать код", а всё, включая работу в проде и цену рисков ошибки из-за написания без понимания (какового у LLM нет - это его неотъемлемое свойство).
Если экономического выигрыша так и не будет, то многое вернётся "на круги своя", и "старая" роль разработчика тоже никуда не денется (что не означает, что не обретёт новых черт). Разумеется, свою нишу LLM всё равно получат, но вот размер этой ниши будет определяться всё той же экономикой.
Да, мне кажется, это важное уточнение. Ускорение написания кода само по себе ещё ничего не говорит об экономике всей разработки.
В статье я как раз поэтому не пытаюсь вывести один коэффициент «AI делает разработчиков на X% быстрее». Если выигрыш на реализации потом съедается дополнительной проверкой, интеграцией, эксплуатацией или стоимостью ошибок, то локальное ускорение мало что значит.
Мне поэтому интереснее следить именно за E2E: сколько в итоге стоит пройти путь от проблемы до работающего изменения в проде с учётом проверки, рисков и дальнейшей эксплуатации. Если там устойчивого выигрыша не появится, это действительно будет сильным аргументом против многих нынешних прогнозов.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Что делает разработчика ценным, когда код всё лучше пишут AI‑агенты