Почему в больших компаниях хейтят ИИ для написания кода - мысли
За последний год я сам довольно много писал код с помощью Codex и Claude. И периодически сталкивался с тем, о чём Линус Торвальдс недавно говорил на Open Source Summit.
ИИ отлично умеет чинить конкретную ошибку. Показываешь ему баг, он находит проблемное место, переписывает несколько строк - и всё снова работает. Казалось бы "Красаучик, все бы так быстро баги правили! Погнали дальше."
А потом похожая ошибка вылезает в другом месте. Потому что ИИ исправил симптом, но не понял причину.
Торвальдс называет такие правки "бездумными временными заплатками". Они закрывают конкретную дыру, но сам тип проблемы остаётся и просто "ждёт в темном закоулке, чтобы дать вам 3.14..." (ладно, так Линус не говорил, это я сам придумал и приписал ему).
И дело не в том, что ИИ фигово пишет код. Пишет код он нормально (и главное быстро).
Проблема в том, что для нормального решения недостаточно увидеть кусок кода с ошибкой. Нужно понимать всю систему: почему она устроена именно так, какие решения принимались несколько лет назад, от каких ограничений отталкивались и что вообще должен был делать этот код.
Этого контекста часто нет ни в репозитории, ни в документации, ни в промпте. Он находится в головах людей, которые создавали систему, поддерживали её и много раз наблюдали, как она ломается в проде (дааааа, блин, криты на проде - любимая забава всех прогеров).
Поэтому Торвальдс говорит, что в пул-реквестах внимательнее читает объяснения, чем сами изменения в коде. По объяснению видно, действительно ли человек понял проблему или просто нашёл способ снова сделать тесты зелёными.
Объяснение - это проверка понимания. Идеальный код - всего лишь результат правильного понимания.
С помощью ИИ стало очень легко получить вроде бы правильный результат, не понимая, почему он правильный и какие последствия вызовет правка, которую клод только что внес. На небольшом личном проекте это обычно нестрашно: что-то сломалось - попросил ИИ починить ещё раз.
В большой компании всё иначе. Код живёт годами, проходит через десятки команд, обрастает зависимостями и становится фундаментом для следующих решений.
Если инженеры перестают понимать систему и просто принимают правдоподобные ответы модели, в коде постепенно появляется всё больше костылей. Каждый из них локально решает задачу, но глобально делает систему ещё менее понятной.
В какой-то момент архитектура превращается в говно, которое никто целиком не понимает, но все продолжают ускоренно достраивать с помощью ИИ.
Тесты пока зелёные, релизы выходят быстрее, в отчётах всё пока выглядит отлично - а вся система уже летит с обрыва прямиком в ад. Такие дела.
За последний год я сам довольно много писал код с помощью Codex и Claude. И периодически сталкивался с тем, о чём Линус Торвальдс недавно говорил на Open Source Summit.
ИИ отлично умеет чинить конкретную ошибку. Показываешь ему баг, он находит проблемное место, переписывает несколько строк - и всё снова работает. Казалось бы "Красаучик, все бы так быстро баги правили! Погнали дальше."
А потом похожая ошибка вылезает в другом месте. Потому что ИИ исправил симптом, но не понял причину.
Торвальдс называет такие правки "бездумными временными заплатками". Они закрывают конкретную дыру, но сам тип проблемы остаётся и просто "ждёт в темном закоулке, чтобы дать вам 3.14..." (ладно, так Линус не говорил, это я сам придумал и приписал ему).
И дело не в том, что ИИ фигово пишет код. Пишет код он нормально (и главное быстро).
Проблема в том, что для нормального решения недостаточно увидеть кусок кода с ошибкой. Нужно понимать всю систему: почему она устроена именно так, какие решения принимались несколько лет назад, от каких ограничений отталкивались и что вообще должен был делать этот код.
Этого контекста часто нет ни в репозитории, ни в документации, ни в промпте. Он находится в головах людей, которые создавали систему, поддерживали её и много раз наблюдали, как она ломается в проде (дааааа, блин, криты на проде - любимая забава всех прогеров).
Поэтому Торвальдс говорит, что в пул-реквестах внимательнее читает объяснения, чем сами изменения в коде. По объяснению видно, действительно ли человек понял проблему или просто нашёл способ снова сделать тесты зелёными.
Объяснение - это проверка понимания. Идеальный код - всего лишь результат правильного понимания.
С помощью ИИ стало очень легко получить вроде бы правильный результат, не понимая, почему он правильный и какие последствия вызовет правка, которую клод только что внес. На небольшом личном проекте это обычно нестрашно: что-то сломалось - попросил ИИ починить ещё раз.
В большой компании всё иначе. Код живёт годами, проходит через десятки команд, обрастает зависимостями и становится фундаментом для следующих решений.
Если инженеры перестают понимать систему и просто принимают правдоподобные ответы модели, в коде постепенно появляется всё больше костылей. Каждый из них локально решает задачу, но глобально делает систему ещё менее понятной.
В какой-то момент архитектура превращается в говно, которое никто целиком не понимает, но все продолжают ускоренно достраивать с помощью ИИ.
Тесты пока зелёные, релизы выходят быстрее, в отчётах всё пока выглядит отлично - а вся система уже летит с обрыва прямиком в ад. Такие дела.