Почему в "И как же быть?" не добавлен блок, чтобы были разными моделями ИИ, которые пишут и проверяют код?
Это одно из решений.
На практике, возможно, ещё не налажен удобный механизм для такого разделения, но подходы такие есть.
Например, мы пишем в Cursor, используем модель Composer 2 или Auto режим иногда для кода. А на ci/cd идёт проверка ботом от ChatGPT.
Также не указан случай, когда MR очень большой (50, 200, 1000 файлов изменений). И кто писал - человек или ИИ не известно. Возможно вместе. В таком случае человеку трудно будет проверить такой код глазами (хотя мы так делаем). Но и ИИ ревью тоже помогает, может найти критические ляпы в коде или посоветовать, на что обратить внимание.
Вроде как эта известная проблема - что забывает героев, лица, контекст. Думаю, когда эта проблема будет решена - а она скорее всего будет решена (может быть в БД будет ИИ героев записывать), то ИИ шагнёт далеко вперёд и сможет написать книгу, острый сюжет. А автор уже доведёт эту рыбу до ума
Крестьянин того времени не знал, как починить машину, какую таблетку купить в аптеке, как установить windows. Да даже перевести по СБП он не мог, только голубиной почтой
Нужно задать вопрос - как часто нужно TDD и тестирование в целом?
На примере фронта - компоненты из ui-библиотеки тестировать смысла практически нет, свои простые компоненты можно и на мой взгляд лучше тестировать визуально через Storybook (если нужно, там есть функционал play для тестирования), сетевой код особо не протестируешь.
Остаётся небольшой класс задач типа utils - работа со временем, величинами, различными приведениями. Их можно и нужно тестировать. Но они занимают крайне малый объём кода относительного всего проекта с компонентами и большая часть уже протестирована в библиотека date-fns, ramda и т.п.
Отсюда был сделан вывод для нашего проекта - тестируются только utils функции, которые лежат в library. А написать небольшие тесты через TDD методологию или просто написать тесты становится совсем некритичным.
Слушаю книги с телефона в Яндекс Браузере. Скачиваешь книгу, закидываешь в Читалке, нажимаешь на наушники и всё - аудикнига готово. На выбор озвучка Алиса и мужской голос. Мне больше нравится мужской - он более спокойный.
Есть галлюцинации, но порой они делают книги веселее)
"Разработчик - просто прокладка".
Несогласен с автором.
Мы живём в переходный период, когда ещё не все довели до автоматизма навык общения с ИИ (Гуглом, stackoverflow)
Если не знаешь или не помнишь решения на вопрос, то ИИ может напомнить его
ИИ может предложить несколько вариантов один из которых будет проходить лучше других. Его можно и скинуть
Если удалить комметарией, которые написал ИИ, то уже трудно будет отличить - нужно будет вчитываться в код и видеть алгоритм. Знать стиль человека.
А можно ещё ИИ попросить писать как конкретный разработчик в компании, хаха))
Почему в "И как же быть?" не добавлен блок, чтобы были разными моделями ИИ, которые пишут и проверяют код?
Это одно из решений.
На практике, возможно, ещё не налажен удобный механизм для такого разделения, но подходы такие есть.
Например, мы пишем в Cursor, используем модель Composer 2 или Auto режим иногда для кода. А на ci/cd идёт проверка ботом от ChatGPT.
Также не указан случай, когда MR очень большой (50, 200, 1000 файлов изменений). И кто писал - человек или ИИ не известно. Возможно вместе.
В таком случае человеку трудно будет проверить такой код глазами (хотя мы так делаем). Но и ИИ ревью тоже помогает, может найти критические ляпы в коде или посоветовать, на что обратить внимание.
Можно, пожалуйста, в сравнение добавить Cursor модели - Composer 2 и режим auto?
Cursor очень популярен - интересно увидеть, на каком уровне модели
Для полного сравнения примера счётчиками интересно было бы видеть их реализацию на чистом JS, vue и $mol )
А завтра 1 апреля....
Один Vite 8 перекрывает все остальные новости)
Спасибо за статью.
До Claude пока ещё не добрался, но на Cursor хотелось бы видеть аналогичный подход. Может со временем он появится)
Эти люди - продавцы "франшиз", которые "внедряют" успешно на 70%
да
Это уже вайп-кодинг получается
Надо дождаться, когда PR будет проверять ИИ)
Скорость ответа в режиме рассуждений и с включенным интернет поиском действительно быстрая.
Приятно пользоваться
Вроде как эта известная проблема - что забывает героев, лица, контекст.
Думаю, когда эта проблема будет решена - а она скорее всего будет решена (может быть в БД будет ИИ героев записывать), то ИИ шагнёт далеко вперёд и сможет написать книгу, острый сюжет. А автор уже доведёт эту рыбу до ума
Крестьянин того времени не знал, как починить машину, какую таблетку купить в аптеке, как установить windows. Да даже перевести по СБП он не мог, только голубиной почтой
Попробуйте поднять версию MUI4 на MUI5/6/7 или React 17 на 18/19.
У компаний уходят на это месяцы и то не факт, что получается с первого раза
На рутубе куча пиратки - аниме, сериалы, фильмы. Зайти туда и посмотреть что-то порой уже легче, чем искать фильмы/сериалы на пиратских сайтах
Нужно задать вопрос - как часто нужно TDD и тестирование в целом?
На примере фронта - компоненты из ui-библиотеки тестировать смысла практически нет, свои простые компоненты можно и на мой взгляд лучше тестировать визуально через Storybook (если нужно, там есть функционал play для тестирования), сетевой код особо не протестируешь.
Остаётся небольшой класс задач типа utils - работа со временем, величинами, различными приведениями. Их можно и нужно тестировать. Но они занимают крайне малый объём кода относительного всего проекта с компонентами и большая часть уже протестирована в библиотека date-fns, ramda и т.п.
Отсюда был сделан вывод для нашего проекта - тестируются только utils функции, которые лежат в library. А написать небольшие тесты через TDD методологию или просто написать тесты становится совсем некритичным.
Понял, спасибо. Не знал этого
Слушаю книги с телефона в Яндекс Браузере. Скачиваешь книгу, закидываешь в Читалке, нажимаешь на наушники и всё - аудикнига готово. На выбор озвучка Алиса и мужской голос. Мне больше нравится мужской - он более спокойный.
Есть галлюцинации, но порой они делают книги веселее)