Чет Виндовая часть с Pivoxy сложная: 1. Тунели устойчиво держит ggrandes/jentunnel: Manage SSH Tunnels made easy - пользуюсь 2 года без нареканий 2. Для винды есть проксирование приложений через Proxifier (ключи спокойно ищутся в яндекс поиске) либо ProxiFyre (OSS). Проксирую claude (через ssh) и python целиком через условно другую умную проксю _ray. На мой взгляд так удобнее.
А с ревью это очень близко к обычному процессу парного программирования.
Я думаю, что более близко к приемке решения у специалиста, который каждый раз меняется, если его строго не инструктировать. Меняется уровень результата - то джун, то мидл, то сеньёр. Меняется стиль ответа. Поэтому если проводить аналогию с парным программированием - то это парное программирование с N программистов, половину из которых можешь встретить в первые. В этом, как мой опыт показывает, сложность :)
Привет! 1. Старайся дорабатывать те вопросы с которыми работаешь. Под дорабатывать - это имеется ввиду работать над ними, пока что-то не осядет в голове, т.е. до какой-то точки, когда мозг начинает отрабатывать информацию и в голове начинает запускаться свой процесс мышления/оценки, восприятия. 2. Перепроверяй информацию по источникам, делай свои зарисовки того как должно быть ли как может быть. А далее спрашивай у AI альтернативы или опции и проси ссылки (если это платный в виде Claude, то даст нормально) и смотри обзоры там. 3. Если запутался по AI т.к. сам не знаешь нужных слов, то дешевле по времени - это банально прочитать документацию на библиотеку или продукт, изучить концепцию. А когда изучена концепция, - есть нужные слова/экспертиза и понимание - уже можно трясти нейронку далее в этом направлении. Часто разброс терминов вводит ее в ступор и необходимость генерации чего-то по середине, что просто убивает ум.
+ Выбери пару тем или направлений, по которым хочешь специализироваться в первую очередь. Это поможет не перегрузиться всем и вся. Наш мозг все таки весьма ограничен. А как освоишь их, бери следующие темы. AI же м.б. поможет закрывать быстро вопросы по которым не специализируешься, выделяя время.
Автор в статье прав про экспертизу. Ну или покупай токенов мешок и иди по Spec-driven development, когда даже уже и код не читают на выходе. Спека + тесты и вперед. Я в целом из разработка после столкновения с Claude-code опять стал возвращаться к системному анализу и проектированию, проджектированию продуктов и услуг. С этим, в т.ч. с постановками задачи, у нейронки пока тяжело. Но здесь уже нужно хорошо понимать рынок, человека, процессы, экономику, технологии и т.п. AI здесь пока как помощник, не более.
М.б. попробуйте Claude Pro и Claude-code. Я заметил, что бесплатные модели все таки весьма сильно недорабатывают. Claude работает несколько минут. Качество выше (пользуюсь re-search'ами, анализом кода и т.п.). По шаблонам (наработанным паттернам) пишет хорошо, хотя местами тоже ленится... Ну понятно, что нужна экспертиза чтобы со всем этим работать, как Вы написали.
"Зачем мне тратить три часа на поиск нормальной статьи про pytest, если я за 10 секунд могу спросить у AI и получить ответ?" - на практике все равно приходишь к необходимости, что все результаты Claude должны быть со ссылками на статьи. Все таки когда читаешь написанное экспертами или даже AI, но проверенное экспертами, - понимание быстрее выстраивается и мозг легче отрабатывает human-to-human связь чисто генетически или исторически (мы привыкли передавать знания от человека к человеку).
"Но у меня простой вопрос: у кого-то вообще есть хоть один стабильно успешный кейс внедрения такого инструмента в продакшене? Не демо, не PoC, не презентация для C-level, а реальная работающая система. " - в Claude-code заявлено, что 80% кода агента (это успешный продукт) пишет сам Claude. В Pro лицензии на это просто не хватит токенов. Но в целом мульти-агентская схема с ролями при достаточных бюджетах на токены позволяет сильно сокращать штат разработки. Увы, - реальность.
Но так то полезная статья, хотя и слегка эмоциональная.
К Сlick претензий нет, пользуюсь, удобно. Есть группы, вложенная структура команд, опции, флаги, аргументы и т.п. + расширения вида click_log и указанного ниже Trogon и м.б. что еще.
Коллега написал про ООП, забыв про ООА и ООD. Также коллега ничего не сказал о DDD. OO подход в разработке (работе с требованиями, проектировании, программировании) - это активная история 90-х и 2000-х. Я в этом время стартовал свою проф. деятельность. В основе лежит восприятие человеком внешнего мира. ОО базировалось на теории типов, теории категорий, теории множеств и в целом дополняло имеющуюся на тот момент реляционную теорию с теми же корнями. А использование Xerox объектов для организации кода - лишь проявление общего подхода применительно к UI слою и немного сомнительно что Xerox был первым в ООП, учитывая наличие реляционной теории до из 70-х. Последняя с основой в теории множеств, повторюсь, как и ОО.
Ключевое в ОО подходе - это восприятие мира человеком и коммуникация человеком информацией о мире. Было декларировано, что восприятие объектно (мы воспринимаем объекты), и коммуницируем мы информацией об объектах (говоря о собаке соседа) и абстрактно об их классах (говоря о собаках в целом). А так как машина предназначена для человека, то отражения (подчеркну) отражения объектов реального мира в структуру программ (мы называем это моделью предметной области) - хороший способ их [программ] организации (о чем собственно и пишут в комментариях).
А далее выяснилось, что много предметных областей, которые существуют только в рамках компьютерных вычислений. Например - окошки, формочки и т.п. Но они то же perceivable (воспринимаемы как объекты) и хорошие кандидаты на классы.
NB: Статья чуток поверхностная и тема ОО не раскрыта даже на 10%. Scrum нет нужды оценивать, так опять же нужно было углубиться в инженерный процесс как основу и его приложения в различных контекстах (это не простая тема). Scrum - это упрощение реального процесса, организационный framework, усреднение индивидов до team collaboration (недостатков), с заявленной потенциальной пользой от возникающей синергии и накатки одного и того же процесса (выгоды). Но тут пусть другие. Не люблю Scrum.
Чет Виндовая часть с Pivoxy сложная:
1. Тунели устойчиво держит ggrandes/jentunnel: Manage SSH Tunnels made easy - пользуюсь 2 года без нареканий
2. Для винды есть проксирование приложений через Proxifier (ключи спокойно ищутся в яндекс поиске) либо ProxiFyre (OSS). Проксирую claude (через ssh) и python целиком через условно другую умную проксю _ray. На мой взгляд так удобнее.
Я думаю, что более близко к приемке решения у специалиста, который каждый раз меняется, если его строго не инструктировать. Меняется уровень результата - то джун, то мидл, то сеньёр. Меняется стиль ответа. Поэтому если проводить аналогию с парным программированием - то это парное программирование с N программистов, половину из которых можешь встретить в первые. В этом, как мой опыт показывает, сложность :)
Тут спор с коллегой не имеет смысла :). Поддержу Вашу точку зрения.
Привет!
1. Старайся дорабатывать те вопросы с которыми работаешь. Под дорабатывать - это имеется ввиду работать над ними, пока что-то не осядет в голове, т.е. до какой-то точки, когда мозг начинает отрабатывать информацию и в голове начинает запускаться свой процесс мышления/оценки, восприятия.
2. Перепроверяй информацию по источникам, делай свои зарисовки того как должно быть ли как может быть. А далее спрашивай у AI альтернативы или опции и проси ссылки (если это платный в виде Claude, то даст нормально) и смотри обзоры там.
3. Если запутался по AI т.к. сам не знаешь нужных слов, то дешевле по времени - это банально прочитать документацию на библиотеку или продукт, изучить концепцию. А когда изучена концепция, - есть нужные слова/экспертиза и понимание - уже можно трясти нейронку далее в этом направлении. Часто разброс терминов вводит ее в ступор и необходимость генерации чего-то по середине, что просто убивает ум.
+ Выбери пару тем или направлений, по которым хочешь специализироваться в первую очередь. Это поможет не перегрузиться всем и вся. Наш мозг все таки весьма ограничен. А как освоишь их, бери следующие темы. AI же м.б. поможет закрывать быстро вопросы по которым не специализируешься, выделяя время.
Автор в статье прав про экспертизу. Ну или покупай токенов мешок и иди по Spec-driven development, когда даже уже и код не читают на выходе. Спека + тесты и вперед. Я в целом из разработка после столкновения с Claude-code опять стал возвращаться к системному анализу и проектированию, проджектированию продуктов и услуг. С этим, в т.ч. с постановками задачи, у нейронки пока тяжело. Но здесь уже нужно хорошо понимать рынок, человека, процессы, экономику, технологии и т.п. AI здесь пока как помощник, не более.
М.б. попробуйте Claude Pro и Claude-code. Я заметил, что бесплатные модели все таки весьма сильно недорабатывают. Claude работает несколько минут. Качество выше (пользуюсь re-search'ами, анализом кода и т.п.). По шаблонам (наработанным паттернам) пишет хорошо, хотя местами тоже ленится... Ну понятно, что нужна экспертиза чтобы со всем этим работать, как Вы написали.
"Зачем мне тратить три часа на поиск нормальной статьи про pytest, если я за 10 секунд могу спросить у AI и получить ответ?" - на практике все равно приходишь к необходимости, что все результаты Claude должны быть со ссылками на статьи. Все таки когда читаешь написанное экспертами или даже AI, но проверенное экспертами, - понимание быстрее выстраивается и мозг легче отрабатывает human-to-human связь чисто генетически или исторически (мы привыкли передавать знания от человека к человеку).
"Но у меня простой вопрос: у кого-то вообще есть хоть один стабильно успешный кейс внедрения такого инструмента в продакшене? Не демо, не PoC, не презентация для C-level, а реальная работающая система. " - в Claude-code заявлено, что 80% кода агента (это успешный продукт) пишет сам Claude. В Pro лицензии на это просто не хватит токенов. Но в целом мульти-агентская схема с ролями при достаточных бюджетах на токены позволяет сильно сокращать штат разработки. Увы, - реальность.
Но так то полезная статья, хотя и слегка эмоциональная.
К Сlick претензий нет, пользуюсь, удобно. Есть группы, вложенная структура команд, опции, флаги, аргументы и т.п. + расширения вида click_log и указанного ниже Trogon и м.б. что еще.
Коллега написал про ООП, забыв про ООА и ООD. Также коллега ничего не сказал о DDD. OO подход в разработке (работе с требованиями, проектировании, программировании) - это активная история 90-х и 2000-х. Я в этом время стартовал свою проф. деятельность. В основе лежит восприятие человеком внешнего мира. ОО базировалось на теории типов, теории категорий, теории множеств и в целом дополняло имеющуюся на тот момент реляционную теорию с теми же корнями. А использование Xerox объектов для организации кода - лишь проявление общего подхода применительно к UI слою и немного сомнительно что Xerox был первым в ООП, учитывая наличие реляционной теории до из 70-х. Последняя с основой в теории множеств, повторюсь, как и ОО.
Ключевое в ОО подходе - это восприятие мира человеком и коммуникация человеком информацией о мире. Было декларировано, что восприятие объектно (мы воспринимаем объекты), и коммуницируем мы информацией об объектах (говоря о собаке соседа) и абстрактно об их классах (говоря о собаках в целом). А так как машина предназначена для человека, то отражения (подчеркну) отражения объектов реального мира в структуру программ (мы называем это моделью предметной области) - хороший способ их [программ] организации (о чем собственно и пишут в комментариях).
А далее выяснилось, что много предметных областей, которые существуют только в рамках компьютерных вычислений. Например - окошки, формочки и т.п. Но они то же perceivable (воспринимаемы как объекты) и хорошие кандидаты на классы.
NB: Статья чуток поверхностная и тема ОО не раскрыта даже на 10%. Scrum нет нужды оценивать, так опять же нужно было углубиться в инженерный процесс как основу и его приложения в различных контекстах (это не простая тема). Scrum - это упрощение реального процесса, организационный framework, усреднение индивидов до team collaboration (недостатков), с заявленной потенциальной пользой от возникающей синергии и накатки одного и того же процесса (выгоды). Но тут пусть другие. Не люблю Scrum.