Я в статье не имел в виду, что реализация перестала быть доказательством хорошей инженерной работы (поэтому и написал "хуже", но не перестала). Она по-прежнему важна, просто её вес как такого сигнала становится меньше.
Если получить хорошо выглядящий и технически корректный код стало дешевле, самого факта хорошей реализации уже недостаточно, чтобы судить обо всей работе инженера. Поэтому следующим абзацем я как раз расширяю картину: важно, правильно ли человек понял проблему, какой компромисс выбрал, учёл ли систему вокруг, безопасно ли выкатил изменение и получил ли нужный результат.
То есть код никуда не исчезает и хорошая инженерная работа тем более не становится ненужной. Просто смотреть приходится шире самой реализации.
Да, мне кажется, это важное уточнение. Ускорение написания кода само по себе ещё ничего не говорит об экономике всей разработки.
В статье я как раз поэтому не пытаюсь вывести один коэффициент «AI делает разработчиков на X% быстрее». Если выигрыш на реализации потом съедается дополнительной проверкой, интеграцией, эксплуатацией или стоимостью ошибок, то локальное ускорение мало что значит.
Мне поэтому интереснее следить именно за E2E: сколько в итоге стоит пройти путь от проблемы до работающего изменения в проде с учётом проверки, рисков и дальнейшей эксплуатации. Если там устойчивого выигрыша не появится, это действительно будет сильным аргументом против многих нынешних прогнозов.
Не хорошую инженерную работу стало сложнее доказать, а хорошая реализация сама по себе становится менее достаточным её доказательством.
Код может быть отлично написан, но решать не ту задачу, не учитывать ограничения системы или не давать нужного результата в проде. Поэтому для меня ценность инженера никуда не исчезает. Просто она всё меньше определяется только тем, насколько хорошо человек умеет превратить готовую задачу в код.
Наверное, как раз поэтому интереснее смотреть на более широкую зону ответственности - какую проблему инженер решает, какие решения принимает, что учитывает и к какому результату в итоге приводит изменение.
Я в статье не имел в виду, что реализация перестала быть доказательством хорошей инженерной работы (поэтому и написал "хуже", но не перестала). Она по-прежнему важна, просто её вес как такого сигнала становится меньше.
Если получить хорошо выглядящий и технически корректный код стало дешевле, самого факта хорошей реализации уже недостаточно, чтобы судить обо всей работе инженера. Поэтому следующим абзацем я как раз расширяю картину: важно, правильно ли человек понял проблему, какой компромисс выбрал, учёл ли систему вокруг, безопасно ли выкатил изменение и получил ли нужный результат.
То есть код никуда не исчезает и хорошая инженерная работа тем более не становится ненужной. Просто смотреть приходится шире самой реализации.
Да, мне кажется, это важное уточнение. Ускорение написания кода само по себе ещё ничего не говорит об экономике всей разработки.
В статье я как раз поэтому не пытаюсь вывести один коэффициент «AI делает разработчиков на X% быстрее». Если выигрыш на реализации потом съедается дополнительной проверкой, интеграцией, эксплуатацией или стоимостью ошибок, то локальное ускорение мало что значит.
Мне поэтому интереснее следить именно за E2E: сколько в итоге стоит пройти путь от проблемы до работающего изменения в проде с учётом проверки, рисков и дальнейшей эксплуатации. Если там устойчивого выигрыша не появится, это действительно будет сильным аргументом против многих нынешних прогнозов.
Привет! Я бы немного иначе сформулировал.
Не хорошую инженерную работу стало сложнее доказать, а хорошая реализация сама по себе становится менее достаточным её доказательством.
Код может быть отлично написан, но решать не ту задачу, не учитывать ограничения системы или не давать нужного результата в проде. Поэтому для меня ценность инженера никуда не исчезает. Просто она всё меньше определяется только тем, насколько хорошо человек умеет превратить готовую задачу в код.
Наверное, как раз поэтому интереснее смотреть на более широкую зону ответственности - какую проблему инженер решает, какие решения принимает, что учитывает и к какому результату в итоге приводит изменение.