отличие будет огромное, контекст топ модели против контекста человека, и пока эта проблема не решаемая, плюсом быстрая дообучаемость и адаптивность, все это очень сильно повлияет на результат
Ускоряет только на уровне джунов или cto, либо у вас маленький проект. Поначалу казалось что на реальных, больших задачах топ модели затащат..но .. нет. Ревью, фиксы багов, sdd - сжирает всю эту скорость генерацию слопа :(
Примерно такое ускорение я чувствовал , когда мсдн с дисков стала доступна в веб поиске )
Ей богу, некоторые даже не перевели термины. gpt никак не может быть ии , и никогда эта технология иишкой не станет. Маркетинг и реальность разные вещи.
В случае необходимости просмотра телефона не глазами, кабель вставят в хозяина, до полного понимания необходимости сотрудничества. Эти уловки работают пока ваша информация реально не понадобиться. А при стирании значительно ухудшит моральное и физическое состояние владельца, не более.
Больше достали деграданты(люди кто вроде что-то умел но ии помогло им деградировать в нейрослопера). Люди например начинают отдавать написание спек на ии. И продвигают это как экономию ресурсов. Некоторые на уровне мидла- начинают думать что вполне могут написать свой bpm движок. Паралельно решая что код ревью можно оставить на или тоже. При том что опыта в движках в принципе не имеют. сперва рофлил, но потом начали давать исправлять это "торжество разума". Причем претензии предъявляют не им, а мне что медленно и что предлагаю масштабные правки... И это уже не рофл :)
Чем ближе anthropic, к ipo, тем больше идиотизма мы будем наблюдать. Интересно посмотреть на этот продукт после года эксплуатации. Пока это маркетинговый хайп, не более
В 2026 году отметать все наработки и заявлять, что все не так и нужно делать все по-другому, потому что мне так кажется.. нуда нуда ведь все поменялось со времён Фаулера и Кента Бека, или ничего не поменялось и вы просто делаете ошибку в статье, на голубом глазу заявляя, что они просто устарели и все не так. Сослался я на книгу так как там вроде аксиомы рефакторинга прописаны, которым стоит следовать. 2*2 всегда 4, либо меняйте базовые аксиомы, чего в статье не сделано.
"UPD: про Unit тесты" тут вообще ад описан интересно где такое ) ни разу с таким трёшки не сталкивался)
https://martinfowler.com/articles/refactoring-2nd-ed.html крайне советую. Заодно solid. Штука в том что если вы пишите нормальный код, то юниты это просто подпорки на которые вы ориентируетесь. Фактически колличество тестов до и после должно быть примерно одинаковым. Там так вы код меняете а не использование его. Рефачить в потом писать тесты , странно...
Не ближе его роль в сре. В конкретно этой статье проблема в нт, имхо. Все кейсы про то что нт по сути нет или сделаны для галочки. Первый кейс: у вас либо нет теста, либо логин замокан(какой это тогда ни тест с моками). Очередь переполнилась: либо нет теста либо тест с моками систем с которыми взаимодействует. Моки отвечают быстро, а реальность другая.. 3 кейс тоже самое.Похоже вместо нт написаны бенчмарки. Плюсом вместо доработки и оттачивания стресс тестирования, вводится новая новая практика.
Вообщем просто не понимание процесса разработки.. юниты нужны не только для качества , но и для поддержки кода в будущем, рефакторинг например, да любые изменения в принципе не возможны без покрытия юнит тестами. Есть такой принцип написания текстов FIRST, F-FAST... Такие тесты и него удешевляют разработку, а не стоят дополнительные деньги. Главное в статье спутано покрытие кода и покрытия кейсов использования системы.
Опус о том что показываю сломанные юнит тест , а система работает, показывает просто бездну. Значит работает система не потому варианту , что в тесте, когда пишется код, код и тесты актуализируются. То есть если у вас есть блок мертвого кода, это не значит, что у вас плохие тесты, это значит у вас проблема с процессами разработки.
Опус о невозможности что-то тестить если это Букинг отелей... Тут со дна стучат уже. Ну возьмите вы практически стандарт индустрии: test containers. Или вот есть у вас рест: 400 ошибку. Хотя да.. юнит тесты нужны слабым программистам))
отличие будет огромное, контекст топ модели против контекста человека, и пока эта проблема не решаемая, плюсом быстрая дообучаемость и адаптивность, все это очень сильно повлияет на результат
Ускоряет только на уровне джунов или cto, либо у вас маленький проект. Поначалу казалось что на реальных, больших задачах топ модели затащат..но .. нет. Ревью, фиксы багов, sdd - сжирает всю эту скорость генерацию слопа :(
Примерно такое ускорение я чувствовал , когда мсдн с дисков стала доступна в веб поиске )
Ей богу, некоторые даже не перевели термины. gpt никак не может быть ии , и никогда эта технология иишкой не станет. Маркетинг и реальность разные вещи.
В случае необходимости просмотра телефона не глазами, кабель вставят в хозяина, до полного понимания необходимости сотрудничества. Эти уловки работают пока ваша информация реально не понадобиться. А при стирании значительно ухудшит моральное и физическое состояние владельца, не более.
По ссылкам нейрослоп. Недавно видел презу в таком дизайне. Тоже чуваки вешали про ai. Это видать общее...
Реальные вещи я так понимаю не делали..
Больше достали деграданты(люди кто вроде что-то умел но ии помогло им деградировать в нейрослопера). Люди например начинают отдавать написание спек на ии. И продвигают это как экономию ресурсов. Некоторые на уровне мидла- начинают думать что вполне могут написать свой bpm движок. Паралельно решая что код ревью можно оставить на или тоже. При том что опыта в движках в принципе не имеют. сперва рофлил, но потом начали давать исправлять это "торжество разума". Причем претензии предъявляют не им, а мне что медленно и что предлагаю масштабные правки... И это уже не рофл :)
Очевидно ии участвовало в разработке, в качестве инструмента генерации научной статьи
Это в каком году статья писалась? Вроде +- java в этом плане выровнялись давно.
Как же это все далеко от реального прода, issues, да разработки в принципе.. когда этот ваш нейрослопа уже кончится
Визионер.
Чем ближе anthropic, к ipo, тем больше идиотизма мы будем наблюдать. Интересно посмотреть на этот продукт после года эксплуатации. Пока это маркетинговый хайп, не более
Нейрослоп реклама через гуглтранслейт )
В 2026 году отметать все наработки и заявлять, что все не так и нужно делать все по-другому, потому что мне так кажется.. нуда нуда ведь все поменялось со времён Фаулера и Кента Бека, или ничего не поменялось и вы просто делаете ошибку в статье, на голубом глазу заявляя, что они просто устарели и все не так. Сослался я на книгу так как там вроде аксиомы рефакторинга прописаны, которым стоит следовать. 2*2 всегда 4, либо меняйте базовые аксиомы, чего в статье не сделано.
"UPD: про Unit тесты" тут вообще ад описан интересно где такое ) ни разу с таким трёшки не сталкивался)
https://martinfowler.com/articles/refactoring-2nd-ed.html крайне советую. Заодно solid. Штука в том что если вы пишите нормальный код, то юниты это просто подпорки на которые вы ориентируетесь. Фактически колличество тестов до и после должно быть примерно одинаковым. Там так вы код меняете а не использование его. Рефачить в потом писать тесты , странно...
Вас запишут в луддиты, но благодаря таким , пока ещё, среди кучи аи-слопа, можно найти нормально написанные тексты. нормальные программы.
Не ближе его роль в сре. В конкретно этой статье проблема в нт, имхо. Все кейсы про то что нт по сути нет или сделаны для галочки. Первый кейс: у вас либо нет теста, либо логин замокан(какой это тогда ни тест с моками). Очередь переполнилась: либо нет теста либо тест с моками систем с которыми взаимодействует. Моки отвечают быстро, а реальность другая.. 3 кейс тоже самое.Похоже вместо нт написаны бенчмарки. Плюсом вместо доработки и оттачивания стресс тестирования, вводится новая новая практика.
Мало было январского обновления...
Вообщем просто не понимание процесса разработки.. юниты нужны не только для качества , но и для поддержки кода в будущем, рефакторинг например, да любые изменения в принципе не возможны без покрытия юнит тестами. Есть такой принцип написания текстов FIRST, F-FAST... Такие тесты и него удешевляют разработку, а не стоят дополнительные деньги. Главное в статье спутано покрытие кода и покрытия кейсов использования системы.
Опус о том что показываю сломанные юнит тест , а система работает, показывает просто бездну. Значит работает система не потому варианту , что в тесте, когда пишется код, код и тесты актуализируются. То есть если у вас есть блок мертвого кода, это не значит, что у вас плохие тесты, это значит у вас проблема с процессами разработки.
Опус о невозможности что-то тестить если это Букинг отелей... Тут со дна стучат уже. Ну возьмите вы практически стандарт индустрии: test containers. Или вот есть у вас рест: 400 ошибку. Хотя да.. юнит тесты нужны слабым программистам))
Зачем это на хабре? 100500 статей с оконулевой связью к разработке но про "ai"
0 информативности в или генерированной статье :(