Зависит от задачи. Если задача - дать доступ модели к содержимому локальных документов, то да, RAG или агент+MCP. Но в статье задача "дообучить", и тут RAG не поможет.
У любого знания есть цена (как минимум - время на изучение, но далеко не только это) - и не каждое знание стоит свою цену лично для Вас.
А ещё "знание" бывает ложным, даже если этого вообще никто в текущий момент времени не знает. В истории полно примеров того, как не знающие что что-то "невозможно" умудрялись это что-то сделать/изобрести, в то время как опытные-знающие были на это не способны.
А бывает, когда знаний в какой-то момент становится слишком много, и это вызывает аналитический паралич мешая принятию любых решений.
…плюс много других ситуаций, где лишние знания - совсем не благо.
У меня на DO почтовые порты открыты. Серверу, правда, уже несколько лет, может они изменили правила для новых клиентов - а может после обращения в саппорт эти порты открывают (я уже не помню, обращался ли я или сразу было открыто).
А вот на AWS почтовые порты мне открыть уже несколько лет назад не удалось, даже после месяца активной переписки с несколькими саппортами.
Для бэка, который занимается фронтом "немного", есть смысл скорее смотреть в сторону HTMX сотоварищи, с целью иметь на фронте как можно меньше JS в принципе, и фронтовая архитектура при таком подходе будет мало релевантна.
Есть такой механизм авторизации: для всех, у кого есть ссылка. Он не очень сильно защищает данные, но тем не менее предполагается, что он отличается от "для всех кто погуглил ключевое слово встречающееся по ссылке". Браузеры (вроде Chrome, Яндекс Браузер и, вероятно, Edge), подглядывающие ссылки пользователя без разрешения и сливающие их содержимое в свою БД, должны как-то этот нюанс учитывать - напр. игнорируя ссылку если доступ к ней закрыт в robots.txt. А сервисы использующие такой механизм авторизации должны соответственно настроить robots.txt.
AFAIR ChatGPT не настроил robots.txt, из-за чего и возникла эта проблема. Т.е. это вполне честная уязвимость, которую выявили и пофиксили. Другое дело, что после этого фикса было бы хорошо, если бы все такие ссылки из всех популярных поисковиков отозвала сама OpenAI, а не заставляла этим заниматься всех пользователей.
А в чём проблема дать доступ к шеллу вместо всего этого? Разумеется, с поддержкой белого списка команд, которые агент может запускать без подтверждения, и ручным подтверждением остальных, плюс некоторыми дополнительными защитами (таймаут на выполнение, ограничение на размер вывода, etc. - есть MCP сервера которые всё это реализуют, напр. https://github.com/sonirico/mcp-shell).
Будем откровенны: работать с ИИ в режиме ручного контроля каждого шага нет никакого смысла - это настолько утомительно, что обычно быстрее сделать задачу самому чем с помощью ИИ. А как только ИИ получает возможность самостоятельно писать и запускать тесты (а это - самый минимум для эффективной работы с ИИ, избавляющий от необходимость ревьювить кучу промежуточных некорректных изменений кода) - фактически у него уже есть полный шелл-доступ. И ограничивать этот доступ намного эффективнее и надёжнее снаружи - контролем среды, в которой работает ИИ агент, напр. через виртуалку/докер/firejail/….
Да, они будут молча читать Ваши документы и делать вид, что всё поняли. Только это вообще ничего не значит, к сожалению.
У меня на предыдущем проекте был похожий случай. Я отвечал за команду бэка, и согласовывал с лидом фронта изменения API в виде swagger.yml. И он два года молча аппрувил предложенные изменения. А потом случайно выяснилось, что он понятия не имеет, что такое swagger.yml, и даже не считает необходимым для роли лида фронта в этом разбираться. (Ну и, разумеется, никакие кодгены по нашему swagger.yml фронт не использовал.)
Не знаю, что там в чатике было, но могу сказать как считаю я.
Зависит от природы проекта. Бывают проекты, в которых один клик юзера в 99% превращается в один запрос GraphQL. А бывают, в которых один клик может привести к вызову десятка API (в худшем случае, если этот клик запускает тяжёлую операцию). В последнем случае для расчёта RPS обычно используются два подхода: либо считаем худший случай (тот самый десяток API на одного юзера), либо смотрим по метрикам средний RPS на живой системе и берём коэффициент из реальных данных. Но на этапе написания доки по нефункциональным требованиям обычно ещё нет живой системы с метриками, так что вариант остаётся один. А если на этапе написания этой доки нет понимания какой будет API и сколько там будет запросов на юзера - обычно использую коэффициент 5 на одного юзера.
Нет, дело в том, что документ этот пишется для определённой целевой аудитории - и она должна понимать, о чём идёт речь. В случае нефункциональных требований ЦА - это бизнес (который должен понять документ чтобы заапрувить его) и разработчики/девопсы (которые будут всё это внедрять и проверять). Поэтому перегружать его богатой терминологией (пусть и более точной и формально корректной) - не лучшая идея.
В большинстве проектов дока на нефункциональные требования отсутствует в принципе. Если она есть - это уже хорошо. Если она упоминает большинство указанных в статье разделов - это вообще прекрасно. Если её реально читают, пытаются выполнять и за этим кто-то реально следит - просто бомба. Если там явно сказано, что необходим контроль сложности пароля - не важно в каком виде - это однозначно плюс, а не минус, показывающий что об этом по крайней мере подумали. Может, конечно, в конкретном случае подумали не очень удачно - но сам факт что думали уже радует. Раз подумали и даже записали, значит вероятность что это требование в будущем будет улучшено сильно вырастает.
Это всё сильно зависит от природы проекта. В одном потеря качества вполне может быть допустима, в другом нет. Один должен быть резиновым-эластичным, а другой (игровой сервер, например) может иметь фиксированное значение максимального количества пользователей и отказывать в регистрациях/подключениях при превышении этого лимита. И термин масштабируемость для них будет означать очень разное - но в том или ином виде она есть везде. Можно, конечно, ввести уникальные термины для всех этих случаев, но тогда часть из этих терминов не будет иметь смысла во многих проектах. Даже сейчас многие путаются между доступностью и масштабируемостью (в этой статье доступность явно включили в надёжность, хотя это довольно разные вещи). Так что да, давайте ещё эластичность с робастностью сюда добавим, так сразу станет понятнее, ага.
Я сторонник кратких и actionable документов. Если есть несколько приемлемых вариантов решения то стоит описать требования и дать возможность выбрать конкретное решение тому, кто будет его внедрять. Но в некоторых случаях реального выбора просто нет, либо потому, что удовлетворяющее требованиям решение ровно одно, либо потому, что для единообразия этот проект должен использовать те же решения, что и соседние проекты - и тут намного проще сразу указать нужное решение, а не использовать общие фразы, делая вид, что выбор есть.
Ключевое - описать модель угроз. Дальше из неё вывести конкретные требования - и конкретику вроде "защита всех коммуникаций через mTLS", и описание необходимых процессов, которые требуется внедрить (безопасность - это в большей степени процесс).
Странная таблица неизвестно откуда. Ещё раз: если вы сами гуглосервисы не установите (прошивкой отдельного zip, который сначала ещё и отдельно скачать нужно), в LineageOS ничего гуглового не будет. В теории, конечно, даже в AOSP могут быть встроены какие-то гугловые телеметрии (и тогда они могут быть и в LineageOS), но я о таком не слышал.
Не собственному и не агрессивному, всё ровно наоборот. Лично я по-прежнему считаю важным глубоко знать активно используемый язык и сам его знаю, но я перестал требовать такого же уровня в обязательном порядке от других разработчиков на моих проектах. Что реально необходимо в работе - они легко доучат в процессе работы (по ошибкам линтеров, тестов и во время ревью PR). А всё остальное… ну, не все фанаты программирования готовые учить это из собственного интереса и на практике есть довольно мало задач, в которых такое глубокое знание действительно необходимо. На качество финального результата, как оказалось, намного сильнее влияют совершенно другие факторы.
Вряд ли кто-то 10-15 лет назад был в состоянии предсказать сегодняшнюю ситуацию. И, учитывая скорость развития ИИ, вряд ли кто-то сегодня понимает, что будет через 10-15 лет.
Но если исходить из исторических данных, то сегодня очень мало разработчиков в состоянии понимать, хороший ассемблер выдаёт компилятор или нет - но это не мешает им писать качественный код на языках высокого уровня не заглядывая в ассемблерный результат. ИИ сегодня позволяет сделать второй рывок аналогичный разнице между ассемблером и языками высокого уровня. Так что вполне возможно, что будущие сениоры будут учить будущих джунов скорее архитектуре проектов и менеджменту ИИ, нежели написанию кода на сегодняшних языках высокого уровня. Но при этом останется небольшая прослойка разработчиков, которые будут делать то же самое, что и сегодня, обеспечивая работу нужных для ИИ инструментов - как сегодняшние разработчики компиляторов.
В обеих статьях написана правда. Просто когда нормальный сениор адекватно работает с ИИ получается как в текущей статье, а когда либо не сениор либо сениор с наивными и не адекватными ожиданиями мечтает что ИИ выполнит команду "сделай хорошо, а плохо не делай" - получается результат как в статье по Вашей ссылке.
Если ты знаешь, какой код должен быть на выходе, то вполне реально получить от ИИ то, что нужно. А если ты "на вайбе" и надеешься, что этого достаточно чтобы сделать нетривиальный проект с продакшн-качеством - то нет, не достаточно.
Но если не задумываться о качестве кода, то лично я знаю один продакшн-проект, сделанный не программистом (но очень опытным IT-менеджером) года 2 назад используя тогдашний ChatGPT - хз как ему это удалось, но он как минимум очень хорошо представлял себе нужный проект (это была уже третья версия) и, полагаю, много тестировал вручную. В коде там практически гарантированно дикий ужас, но оно работает, приносит деньги и обошлось намного дешевле, чем нанимать реальных разработчиков.
Зависит от задачи. Если задача - дать доступ модели к содержимому локальных документов, то да, RAG или агент+MCP. Но в статье задача "дообучить", и тут RAG не поможет.
Не любое знание есть благо.
У любого знания есть цена (как минимум - время на изучение, но далеко не только это) - и не каждое знание стоит свою цену лично для Вас.
А ещё "знание" бывает ложным, даже если этого вообще никто в текущий момент времени не знает. В истории полно примеров того, как не знающие что что-то "невозможно" умудрялись это что-то сделать/изобрести, в то время как опытные-знающие были на это не способны.
А бывает, когда знаний в какой-то момент становится слишком много, и это вызывает аналитический паралич мешая принятию любых решений.
…плюс много других ситуаций, где лишние знания - совсем не благо.
Не почту как таковую, а её федеративность - всех загоняют на крупных провайдеров вроде gmail. И это полный беспредел!
У меня на DO почтовые порты открыты. Серверу, правда, уже несколько лет, может они изменили правила для новых клиентов - а может после обращения в саппорт эти порты открывают (я уже не помню, обращался ли я или сразу было открыто).
А вот на AWS почтовые порты мне открыть уже несколько лет назад не удалось, даже после месяца активной переписки с несколькими саппортами.
Eсть способ "решить" эту проблему: https://en.wikipedia.org/wiki/Sender_Rewriting_Scheme
Для бэка, который занимается фронтом "немного", есть смысл скорее смотреть в сторону HTMX сотоварищи, с целью иметь на фронте как можно меньше JS в принципе, и фронтовая архитектура при таком подходе будет мало релевантна.
Есть такой механизм авторизации: для всех, у кого есть ссылка. Он не очень сильно защищает данные, но тем не менее предполагается, что он отличается от "для всех кто погуглил ключевое слово встречающееся по ссылке". Браузеры (вроде Chrome, Яндекс Браузер и, вероятно, Edge), подглядывающие ссылки пользователя без разрешения и сливающие их содержимое в свою БД, должны как-то этот нюанс учитывать - напр. игнорируя ссылку если доступ к ней закрыт в
robots.txt. А сервисы использующие такой механизм авторизации должны соответственно настроитьrobots.txt.AFAIR ChatGPT не настроил
robots.txt, из-за чего и возникла эта проблема. Т.е. это вполне честная уязвимость, которую выявили и пофиксили. Другое дело, что после этого фикса было бы хорошо, если бы все такие ссылки из всех популярных поисковиков отозвала сама OpenAI, а не заставляла этим заниматься всех пользователей.А в чём проблема дать доступ к шеллу вместо всего этого? Разумеется, с поддержкой белого списка команд, которые агент может запускать без подтверждения, и ручным подтверждением остальных, плюс некоторыми дополнительными защитами (таймаут на выполнение, ограничение на размер вывода, etc. - есть MCP сервера которые всё это реализуют, напр. https://github.com/sonirico/mcp-shell).
Будем откровенны: работать с ИИ в режиме ручного контроля каждого шага нет никакого смысла - это настолько утомительно, что обычно быстрее сделать задачу самому чем с помощью ИИ. А как только ИИ получает возможность самостоятельно писать и запускать тесты (а это - самый минимум для эффективной работы с ИИ, избавляющий от необходимость ревьювить кучу промежуточных некорректных изменений кода) - фактически у него уже есть полный шелл-доступ. И ограничивать этот доступ намного эффективнее и надёжнее снаружи - контролем среды, в которой работает ИИ агент, напр. через виртуалку/докер/firejail/….
В теории или на практике? :)
Да, они будут молча читать Ваши документы и делать вид, что всё поняли. Только это вообще ничего не значит, к сожалению.
У меня на предыдущем проекте был похожий случай. Я отвечал за команду бэка, и согласовывал с лидом фронта изменения API в виде swagger.yml. И он два года молча аппрувил предложенные изменения. А потом случайно выяснилось, что он понятия не имеет, что такое swagger.yml, и даже не считает необходимым для роли лида фронта в этом разбираться. (Ну и, разумеется, никакие кодгены по нашему swagger.yml фронт не использовал.)
Не знаю, что там в чатике было, но могу сказать как считаю я.
Зависит от природы проекта. Бывают проекты, в которых один клик юзера в 99% превращается в один запрос GraphQL. А бывают, в которых один клик может привести к вызову десятка API (в худшем случае, если этот клик запускает тяжёлую операцию). В последнем случае для расчёта RPS обычно используются два подхода: либо считаем худший случай (тот самый десяток API на одного юзера), либо смотрим по метрикам средний RPS на живой системе и берём коэффициент из реальных данных. Но на этапе написания доки по нефункциональным требованиям обычно ещё нет живой системы с метриками, так что вариант остаётся один. А если на этапе написания этой доки нет понимания какой будет API и сколько там будет запросов на юзера - обычно использую коэффициент 5 на одного юзера.
Нет, дело в том, что документ этот пишется для определённой целевой аудитории - и она должна понимать, о чём идёт речь. В случае нефункциональных требований ЦА - это бизнес (который должен понять документ чтобы заапрувить его) и разработчики/девопсы (которые будут всё это внедрять и проверять). Поэтому перегружать его богатой терминологией (пусть и более точной и формально корректной) - не лучшая идея.
В большинстве проектов дока на нефункциональные требования отсутствует в принципе. Если она есть - это уже хорошо. Если она упоминает большинство указанных в статье разделов - это вообще прекрасно. Если её реально читают, пытаются выполнять и за этим кто-то реально следит - просто бомба. Если там явно сказано, что необходим контроль сложности пароля - не важно в каком виде - это однозначно плюс, а не минус, показывающий что об этом по крайней мере подумали. Может, конечно, в конкретном случае подумали не очень удачно - но сам факт что думали уже радует. Раз подумали и даже записали, значит вероятность что это требование в будущем будет улучшено сильно вырастает.
Это всё сильно зависит от природы проекта. В одном потеря качества вполне может быть допустима, в другом нет. Один должен быть резиновым-эластичным, а другой (игровой сервер, например) может иметь фиксированное значение максимального количества пользователей и отказывать в регистрациях/подключениях при превышении этого лимита. И термин масштабируемость для них будет означать очень разное - но в том или ином виде она есть везде. Можно, конечно, ввести уникальные термины для всех этих случаев, но тогда часть из этих терминов не будет иметь смысла во многих проектах. Даже сейчас многие путаются между доступностью и масштабируемостью (в этой статье доступность явно включили в надёжность, хотя это довольно разные вещи). Так что да, давайте ещё эластичность с робастностью сюда добавим, так сразу станет понятнее, ага.
Я сторонник кратких и actionable документов. Если есть несколько приемлемых вариантов решения то стоит описать требования и дать возможность выбрать конкретное решение тому, кто будет его внедрять. Но в некоторых случаях реального выбора просто нет, либо потому, что удовлетворяющее требованиям решение ровно одно, либо потому, что для единообразия этот проект должен использовать те же решения, что и соседние проекты - и тут намного проще сразу указать нужное решение, а не использовать общие фразы, делая вид, что выбор есть.
Ключевое - описать модель угроз. Дальше из неё вывести конкретные требования - и конкретику вроде "защита всех коммуникаций через mTLS", и описание необходимых процессов, которые требуется внедрить (безопасность - это в большей степени процесс).
Странная таблица неизвестно откуда. Ещё раз: если вы сами гуглосервисы не установите (прошивкой отдельного zip, который сначала ещё и отдельно скачать нужно), в LineageOS ничего гуглового не будет. В теории, конечно, даже в AOSP могут быть встроены какие-то гугловые телеметрии (и тогда они могут быть и в LineageOS), но я о таком не слышал.
Только если при установке LineageOS вы сами дополнительно установите гугл-сервисы и потом не ограничите их доступ (напр. через XPrivacyLua).
Не собственному и не агрессивному, всё ровно наоборот. Лично я по-прежнему считаю важным глубоко знать активно используемый язык и сам его знаю, но я перестал требовать такого же уровня в обязательном порядке от других разработчиков на моих проектах. Что реально необходимо в работе - они легко доучат в процессе работы (по ошибкам линтеров, тестов и во время ревью PR). А всё остальное… ну, не все фанаты программирования готовые учить это из собственного интереса и на практике есть довольно мало задач, в которых такое глубокое знание действительно необходимо. На качество финального результата, как оказалось, намного сильнее влияют совершенно другие факторы.
Вряд ли кто-то 10-15 лет назад был в состоянии предсказать сегодняшнюю ситуацию. И, учитывая скорость развития ИИ, вряд ли кто-то сегодня понимает, что будет через 10-15 лет.
Но если исходить из исторических данных, то сегодня очень мало разработчиков в состоянии понимать, хороший ассемблер выдаёт компилятор или нет - но это не мешает им писать качественный код на языках высокого уровня не заглядывая в ассемблерный результат. ИИ сегодня позволяет сделать второй рывок аналогичный разнице между ассемблером и языками высокого уровня. Так что вполне возможно, что будущие сениоры будут учить будущих джунов скорее архитектуре проектов и менеджменту ИИ, нежели написанию кода на сегодняшних языках высокого уровня. Но при этом останется небольшая прослойка разработчиков, которые будут делать то же самое, что и сегодня, обеспечивая работу нужных для ИИ инструментов - как сегодняшние разработчики компиляторов.
В обеих статьях написана правда. Просто когда нормальный сениор адекватно работает с ИИ получается как в текущей статье, а когда либо не сениор либо сениор с наивными и не адекватными ожиданиями мечтает что ИИ выполнит команду "сделай хорошо, а плохо не делай" - получается результат как в статье по Вашей ссылке.
Если ты знаешь, какой код должен быть на выходе, то вполне реально получить от ИИ то, что нужно. А если ты "на вайбе" и надеешься, что этого достаточно чтобы сделать нетривиальный проект с продакшн-качеством - то нет, не достаточно.
Но если не задумываться о качестве кода, то лично я знаю один продакшн-проект, сделанный не программистом (но очень опытным IT-менеджером) года 2 назад используя тогдашний ChatGPT - хз как ему это удалось, но он как минимум очень хорошо представлял себе нужный проект (это была уже третья версия) и, полагаю, много тестировал вручную. В коде там практически гарантированно дикий ужас, но оно работает, приносит деньги и обошлось намного дешевле, чем нанимать реальных разработчиков.