Коротко
Опыт опытного разработчика показывает неприятный trade-off: код действительно можно выпускать быстрее, но вместе с этим исчезают понимание системы, обучение и ощущение авторства. Разбираем, почему роль «проверяющего AI» может оказаться хуже, чем медленная разработка руками.
Самая сильная претензия к AI-кодингу — не в том, что модели иногда ошибаются. Они действительно помогают выпустить нетривиальный проект быстрее, но цена может оказаться в другом: разработчик перестаёт быть человеком, который строит систему, и превращается в оператора очереди задач.
Именно это описывает автор Brett Codes — опытный инженер, который больше года использовал coding harnesses вроде Claude Code. В какой-то момент он связал Linear с Claude Code и получил работающий проект от начала до конца, почти не написав кода самостоятельно. Звучит как идеальная автоматизация, пока не задашь вопрос: что в этот момент осталось делать инженеру?
Ответ оказался не слишком вдохновляющим: смотреть на сгенерированный код, ловить отдельные ошибки и проверять результат. Автор пишет, что перестал понимать детали собственной системы без помощи AI, меньше заботился о качестве и больше не чувствовал связи с программой. Работа ускорилась, но из неё ушли обучение, рост и удовольствие от решения сложных задач.
Здесь важен не спор «AI пишет хороший код или плохой». Даже если код достаточно хорош, чтобы пройти тесты, разработчик может потерять главное — контекст и ответственность за продукт. А качество программного обеспечения, по мысли автора, определяется не количеством быстро добавленных функций, а тем, насколько люди действительно заботятся о том, что создают.
Проблема усугубилась тем, что чат-модель постепенно стала для автора универсальным советчиком: он спрашивал её о книгах, карьере, бизнес-идеях и здоровье. После случая с ненужной поездкой в отделение неотложной помощи он прекратил использовать AI для таких решений. Но с кодом остановиться оказалось сложнее: если инструмент доступен даже для мелочей, легко отдать ему почти всю работу.
Ограничения этого вывода тоже нужно проговорить. Это личный опыт одного разработчика, а не доказательство того, что AI-кодинг неизбежно вредит всем. Автор не приводит измерений производительности или качества программ. Его медицинская история показывает опасность некритичного доверия к чат-боту, но не позволяет делать выводы о каждой модели. Экологический ущерб, использование обучающих данных и влияние на рынок труда в тексте обозначены как серьёзные проблемы, но подробно не разобраны. Кроме того, отказ от AI может поставить под угрозу работу автора — он сам не знает, чем закончится это решение.
Практический вывод для команд неприятный: считать строки кода и закрытые тикеты недостаточно. Если AI забирает у разработчиков понимание системы, время на ревью и чувство авторства, рост скорости может оказаться не улучшением, а переносом издержек в будущее — на поддержку, качество и мотивацию людей.
Если бы от вас требовали выбирать между более высокой скоростью с AI и сохранением полного контроля над кодом, чем вы готовы пожертвовать? Источник: Hacker News - Newest: ""AI" "LLM""