Опытный тимлид признал: идеи, которые он годами считал плохими, теперь работают
Bad ideas that aren't bad anymore
Автор с 15-летним стажем рассказывает, как в его команде перестали ревьюить пул-реквесты друг друга: Claude пишет код, человек проверяет, а CI и Greptile ловят ошибки. Разделение на изолированные потоки работы больше не плодит «силосы знаний», потому что Claude за минуты вводит в курс дела. Глубокую экспертизу в конкретном фреймворке он теперь считает менее ценной, чем инженерное чутьё и продуктовое мышление.
Когда я думаю о том, почему это работает, то понимаю: то, от чего защищало код-ревью, по-прежнему защищено. Просто теперь автор — Claude, а ревьюер — человек, который ведёт задачу.
- sn
Я principal engineer. Код-ревью по-прежнему важны для production-софта.
Может, ты считаешь, что я недостаточно жёстко вайб-кожу, и если бы я лучше использовал ИИ, код-ревью были бы не нужны. Не согласен — и инженеры, и LLM всё ещё добавляют ненужную сложность или выбирают неверные абстракции так, что это создаст проблемы в будущем, не продумывают все крайние случаи и выбирают неправильную обработку ошибок. Они добавляют то, что кажется им хорошей идеей, и не придерживаются спецификации.
Если моя компания перестанет делать код-ревью для важного софта, я уволюсь.
Инженерам, не находящимся в стартапной гонке, стоит стремиться использовать LLM, чтобы писать код лучше, а не быстрее. Быстрее — это просто создаёт технический долг и повышает ваши долгосрочные издержки.
- ro_sharp
Почему так много людей думают, что код-ревью в первую очередь связаны с недоверием или поиском ошибок?
ИМХО, они в первую очередь про обеспечение общего понимания и согласия — не только насчёт того, как всё меняется сейчас, но и как это будет меняться в будущем.
- xg15
Общая тема всех этих разных примеров, похоже, такая: «Раньше нам приходилось быть осторожными, чтобы дать каждому члену команды набрать опыт и экспертизу в нашей кодовой базе и избежать динамики, которая могла бы сформировать разрозненные знания. Теперь это уже не важно, потому что каждый может просто попросить Claude всё ему объяснить».
Честно говоря, я не так уверен в этом. В краткосрочной перспективе это работает, да. Но в долгосрочной это может быть так, как если бы у вас были очень хорошие книги, но ноль практического опыта с вещью. Мы все знаем, что книжные знания отличаются от приобретённого опыта.
- kbiessy
Я собираюсь поговорить о пункте из этого списка, который знаю лучше всего. «Создавать вместо покупки» — вот что я бы поставил под сомнение.
Стоимость написания инструмента в основном исчезла, с этим я согласен. Стоимость владения им, думаю, не сильно изменилась. Если я посмотрю на программный стек пары небольших компаний, которые знаю, то кастомные инструменты — это те, что в итоге причиняют больше всего боли. Никто не помнит, что это было сделано на заказ, пока не сломается вызов API или не уйдёт человек, который это построил. Думаю, стоимость поддержки особенно высока.
Сборка за один день не решает долгосрочную поддержку и не даёт функциональных знаний. Думаю, универсалы много выиграют от ИИ, но в будущем всё ещё будет огромная роль у экспертов, которые направляют и поддерживают софт.
- ahartmetz
>Внедрение языка или инструмента, который никто в команде не знает [больше не плохая идея]
ОК, теперь я уверен, что этот парень гонит.