До сих пор остаётся незакрытым вопрос - вообще фундаментально, на уровне законов реальности - до какого предела можно увеличить скорость научных исследований (и вообще продается ли она значительному увеличению).
Если считать - что научное открытие - это результат получения из неполных данных о модели - полные, а одно из свойств информации - невозможность сжать данные со случайными распределением, то выходит - что если научные знания - имеют случайное распределение (что очевидно вероятно не совсем так) - то единственный метод получить из неполных данных - полные - полный перебор.
Для биологических учёных - это будет означать, что помимо знаний, на результат будут влиять не меньше - незнания (условно когда учёный не знает факт, который все считают само собой разумеющимся, и делает открытие, поставив эксперемент, результат которого считается предопределённым).
Понятно, что научнык данные - имеют отличное от белого шума распределение (хотя и это не факт, потому, что мы не знаем, сколько не знаем, а судить о распределении по части выборки - не всегда верно), но даже если они имеют некоторое особенное распределение - степень эффективности методики по логическому анализу всё равно строго ограничена некоторым пределом, когда придет время делать полный перебор эксперементально.
Есть ненулевая вероятность, что даже самые гениальный AI (настоящий AI) не даст значительного прироста в скорости открытый, т.к. нужно будет помимо гениального ai - ещё и 100 миллионов эксперементов.
Я знал, я был уверен, что все эти AI агенты такие кривые и глючные потому, что написаны без сами собой "пишет весь код OpenClaw с помощью Codex". Вот почему скорее всего все kilo code, Coda и прочие расширения - вечно сыпят ошибками, кладут студию, зацикливаются и такие кривые.
Я каждую волну llm кодинга пытаюсь завалить мир сгенерированными приложениями (пока вообще не выходит). Расскажу свои выводы.
По плюсам
Llm почти всегда круто реализовывают локализованные задачи. Написать утилиту, скрипт, поправить вёрстку, обновить компонент, написать тест - очень круто. В этих задачах экономия времени прямо реально до 10 раз и больше.
Llm неплохо объясняют код. Если где-то непонятное поведение или надо исправить - есть шанс в половину, что llm даст хорошую наводку на причину проблемы.
Можно быстро раскатать mvp.
А теперь о проблемах
Агенты - чудовищные пожиратели токенов. Когда я использовал бесплатное api со скоростью инференса 50 токенов, на задачу которая решается за 1.5 часа ручного кодинга ушло ~48 часов непрерывной работы агента. Причем задача решена не была, только частичные наработки, которые надо допиливать напильником. И у меня есть ощущение, что на проверки - не помер ли агент в процессе и что он так долго делает - я потратил половину времени от ручного написания кода)
Llm ужасны в нелокализованных задачах. Дайте агенту обширную задачу требующую внести изменения в несколько файлов - и он перечитает их по 10 раз, и перепишет в 5 раз больше чем нужно, зачастую сломав что-то другое, что до этого работало. Я уже видел задачи, когда проблема решалась точечным изменением одного флага, а llm переписывала 800 строк кода.
Llm вообще не знает что такое производительность. Там, где агент писал мне решение, которое почти работало (и правкой импортов, мелочей и пары условий - завелось), я получил 6 кадров на сцене, которая не нёсет никакой нагрузки. Я попросил оптимизировать, и он оптимизировал, но вообще не то, что на самом деле жрало ресурсы. Пол часа напильника, и 6 фпс превратились в 120, но для этого надо понимать код. Оптимизировать написанный код - может быть значительно сложнее, чем написать оптимальный сразу, особенно когда проблемы ты находишь не сразу, а когда сверху ещё 20 зависимостей и сотни строк кода.
Ну и главная проблема - в один прекрасный момент агенты даже, блин, на микроскопической кодовой базе - впадают в тупняк. Они начинают ходить по файлам кругами, переживая контекст и повторяя круг, переписывают одни и те же параметры также обратно, ломают по очереди две фичи туда обратно, чиня одну и ломая вторую, или пишут семиступечантые вундервафли там, где нужно сделать что-то очень простое. И вот когда у тебя один - два новых класса и ты сталкиваешься с проблемой - можно спасти бедолагу руками. Но когда у тебя 100к строк кода, с архитектурой от llm (у меня в одном проекте например агент использовал 3 разных подхода к di в разных классах и 2 к построению интерфейса, и смешал несколько архитектур), то исправить одну протекающую проблему - может занять недели или месяцы.
Пока - по ощущениям, llm в качестве кодера - это как болиды формулы 1. Они очень быстрые, очень красивые, громко звучат, но на треке. И чем дальше ты от идеального трека к суровой реальности, тем больше экспоненциально растут в тебя проблемы.
Так полыхают не потому, что не принимают новый инструмент, а потому, что им пытаются ссать в уши, что он работает намного лучше, чем оно есть по факту.
Я вот всеми руками за, чтобы я решал одну задачу в агент другую или 10, но что codex, что Клод, что chatgpt + kilo code - ну ни одну задачу продуктовую пока не смогли решить, ни с каким промптом. Ни декомпозированную, ни описанную, ни "как есть". Варят килотонны токенов, перечитывают десятки файлов проекта, и в конце составляют план из чуши или вносят изменения в файлы, которые вообще к делу отношения не имеют.
Да вот прямо час назад - я попросил deepseek в чате отцентровать элемент, и все что он сделал - описал какой он молодец и добавил в код комментарии. Комментарии Карл, без единой правки меняющий результат работы программы. Нет, конечно если по пытать его пол часика, он выдаст кривое решение, но я в коде это центрование напишу за три, просто я хотел за 10 секунд.
Ну не годятся пока инструменты, чтобы реально отказаться от знания кода, даже близко не похоже.
Тут как со статистикой. Не нужно даже врать - можно не договаривать. Нет ровным счётом ничего сложного в том, чтобы написать с нуля проект на сто миллионов строк кода ии агентом. Например если твоя задача типична и часто встречалась (например сделать 100500 мини игр в одной), или есть твоё ТЗ уже на сто миллионов строк кода, и главное, если каждый новый блок кода мало взаимодействует с остальным. Например можно нагенерировать какой нибудь декодер кучи форматов, где связанная часть - чисто один файл с выбором in/out, а остальное - раздельные атомарные декодеры.
Проблемы у llm начинаются когда тебе надо не написать проект с нуля а внести правку в существующую многоступенчатую систему. У меня codex на бесплатном api со скоростью инференса 50 токенов в секунду - 6 часов варил одну очевидную строку кода (я решил просто проверить, а не сделал сам)
По моему опыту код до 500 строк получается с первого прогона, от 500 до 1000 2-3 прогона
Пфф, да это вообще легко, вы мне скажите с какого прогона получается внести точечные изменения в этот код из 500строк. Я вот даже на микроскопическом пет проекте, в целях эксперемента, из 4х фич с помощью агента и топовой llm смог реализовать только 1 (как раз ту, где 90% - код с нуля, и 10% использование существующего), и то самую простую. На остальных начинались свистопляски с ломанием базы данных, других частей кода, или зацикливание.
Код полностью описан на уровне технического задания для LLM
Ах если бы оно так работало, то моя задача - добавить новый тип тренировки для кардио в моё пет приложение уже была бы готова. На деле, оно варит проект дольше, чем я бы написал этот код, а в результирующем плане предлагает столько изменений которые не нужны для задачи, что потом ещё десять итераций потребуется чтобы их исправить.
Не сами языки детерминированы и формализованы а их поведение и конечный результат.
Это в корне меняет дело. Ведь если я до этого говорил, о том, что вы пишете на ЯП и получаете однозначно понятный результат, то теперь то значит, что вы пишите на ЯП и получаете однозначно понятный во результат).
В индустрии целые виды фреймворков (rect, compose) и инструментов (docker) и функциональное программирование целиком, сложились ради того, чтобы исключить состояние, потому что состояние сложно контролировать.
А теперь у нас за состояние (код) - будет отвечать ещё и инструмент, который сам вносит море неопределённости. Покрыть все тестами - это конечно звучит как план, только кто все эти тесты напишет, придумает и проверит? Вот у меня llm написала (с некоторыми правками от меня) исполняемый код, он даже решает поставленную задачу, только вместо 120 - выдает 6 кадров, это значит тестами надо крыть не только данные/результат, но и производительность. А если она падает на специфических данных/по памяти/после 100 прогонов.
Нет, как инструмент помощи и решения локальных микрозадач или тревиальных сценариев - ок, как замена ЯП - это яйцо настолько сырое, что ещё не родилась курица которая должна его снести.
В целом, llm агенты неплохи и реально могут поднять производительность - когда ты берешь на себя сложную работу, а на втором экране даёшь агенту небольшую другую задачу (или анализ другой большой задачи). Я так делаю с локальной поднятой qwen3-coder. Сам беру комплексные задачи, а кнопки перекрасить, дизайн подвигать, или найти откуда прилетает параметр - отдаю агенту. Когда он выдает результат - тратишь 2 минуты на ревью, и отправляешь на следующую задачу или на новую итерацию по той-же.
Но комплексные и сложные задачи даже Клод решает пока настолько плохо, что количество итераций и сложность написания тех задания сводит пользу такого подхода на ноль
Языки программирования - от ассемблера на низком уровне до js на высоком - строго детерменированны и формализованы. Llm хаотичны, недетерменированны, и не формализованы.
Чтобы выполнить конкретную операцию на js или asm - всегда есть четкий алгоритм действий, если задача выполнима. На llm никогда нет четкого промтпа даже если задача выполнима.
И самая большая проблема с которой я сталкиваюсь все время - описание задачи для llm достаточно формализованно и четко, сложнее, чем написание кода для решения этой задачи, если речь о правках уже существующего функционала, просто потому, что язык программирования высокого уровня - это и есть язык для четкого и лаконичного описания преобразований данных, а человеческая речь для этого подходит сильно хуже.
Ну близко но не совсем)) откровенно вирусные приложения, и те, которые используют известные уязвимости - отловит гугловский автоанализатор. Если будут подозрительные пермишены или опасные - высока вероятность попасть на ручную проверку индусом - и там уже не пройти. Ну и по правилам - те приложения, которые тянут произвольный исполняемый код с сервера и запускают (уж не знаю что имеется в виду - какой нибудь хитровыкручкнный eval в java через рефлексию или ndk) - запрещены (termicus из стора из за это не поддерживает репозитории, а вот с их сайта - запросто). Хотя практика показывает, что это не касается js кода.
Как человек разрабатывающий мобильные приложения - могу сказать как минимум, что в той-же яндекс метрике, которая обязательна для некоторых типов приложений по закону - есть режим записи экрана (внутри приложения). Если он включен, то аналитики могут посмотреть запись пользовательского сеанса и все действия (но не аппаратно ускоренные окна типо камеры или видео). При этом - куча приложений типо телеги и ВК - по умолчанию открывают ссылки не в системном браузере а прямо в приложении - и это потенциальная утечка.
Сбербанк в своё время заставил меня удалить их приложение а потом и в целом отказаться от услуг тем, что их приложение требовала "для работы встроенного антивируса" - доступ к списку контактов, истории звонков и ещё куче всего (к слову доступ к "телефону" по идее был даже адекватен т.к. позволял получить id девайса и вроде как понять подмену устройства или типо того, но беда в том, что он давал ещё кучу прав в придачу)
А так - за 10 лет разработки, злонамеренных случаев слежки в больших компаниях не встречал, и утаить это не так просто. Думаю такое могут позволить себе библиотеки выдающие api для аналитики. Но вот для аналитики собственно - каждый шаг/клик/просмотр - будет записан.
Рекомендации банальны - отключаете встроенный браузер в приложении (почти всегда есть галка - использовать системный), читайте какие разрешения и зачем просит приложение (банку выдавать контакты не нужно, а вот по тупости систем прав в android - приложению весов - может потребоваться доступ к местоположению потому что без него доступ к bluetooth не получить). Ну и если приложение загоняет вас в системные настройки чтобы получить разрешение (быть поверх всех окон например) - значит это особо опасный пермишн - подумать надо с запасом)
А в целом все как всегда - если читать что написано, будете уязвимы только к 0d уязвимостям)
Может это конкретно с android studio или jetbrain-овскими ide такая беда, но все расширения встраивающиеся туда как будто написаны тем самым llm без участия человека - бесконечные баги, утечки памяти, не очень удобный интерфейс и свойства периодически класть студию. У оценки у них всех около 3/5
Учитывая что скрипт явно нагенерен нейронкой, а автор пишет что "писал скрипт ночью" - сразу возникло сомнение по поводу правдивости всего текста. Хотя может просто неудачный оборот)
Ага, и от того, что их статью захейтили, они плача пойдут вешаться и саботировать работу, нуну.
Просто не будет от них больше никаких статей, а потом и от других не будет. Да их и сейчас уже нет. А ещё хейтерство и разобщённость в it сообществе лишь подтвердит в глазах этих людей правильность их работы.
У меня вот были наброски двух больших технических статей про мобильную разработку в черновиках, но после реакции хабра, когда мне наставили минусов просто за ответ на вопрос, потому что тема вопроса им не понравилась - я решил их на хабр не писать.
Зачем писать технические статьи на сайт про политику.
По делу все человек сказал. Технические статьи и так помирают, а тут ещё и авторов которые хоть что-то правдоподобное пишут минусуют по политическим причинам. Напоминает блм в США и моменты когда за выражение что гендера два - в Европе с работы с позором увольняли. Хабр больше не сайт про технические статьи, надо искать новый.
До сих пор остаётся незакрытым вопрос - вообще фундаментально, на уровне законов реальности - до какого предела можно увеличить скорость научных исследований (и вообще продается ли она значительному увеличению).
Если считать - что научное открытие - это результат получения из неполных данных о модели - полные, а одно из свойств информации - невозможность сжать данные со случайными распределением, то выходит - что если научные знания - имеют случайное распределение (что очевидно вероятно не совсем так) - то единственный метод получить из неполных данных - полные - полный перебор.
Для биологических учёных - это будет означать, что помимо знаний, на результат будут влиять не меньше - незнания (условно когда учёный не знает факт, который все считают само собой разумеющимся, и делает открытие, поставив эксперемент, результат которого считается предопределённым).
Понятно, что научнык данные - имеют отличное от белого шума распределение (хотя и это не факт, потому, что мы не знаем, сколько не знаем, а судить о распределении по части выборки - не всегда верно), но даже если они имеют некоторое особенное распределение - степень эффективности методики по логическому анализу всё равно строго ограничена некоторым пределом, когда придет время делать полный перебор эксперементально.
Есть ненулевая вероятность, что даже самые гениальный AI (настоящий AI) не даст значительного прироста в скорости открытый, т.к. нужно будет помимо гениального ai - ещё и 100 миллионов эксперементов.
Я знал, я был уверен, что все эти AI агенты такие кривые и глючные потому, что написаны без сами собой "пишет весь код OpenClaw с помощью Codex". Вот почему скорее всего все kilo code, Coda и прочие расширения - вечно сыпят ошибками, кладут студию, зацикливаются и такие кривые.
Число бесплатных пользователей из Пентагона выросло в два раза))
Я каждую волну llm кодинга пытаюсь завалить мир сгенерированными приложениями (пока вообще не выходит). Расскажу свои выводы.
По плюсам
Llm почти всегда круто реализовывают локализованные задачи. Написать утилиту, скрипт, поправить вёрстку, обновить компонент, написать тест - очень круто. В этих задачах экономия времени прямо реально до 10 раз и больше.
Llm неплохо объясняют код. Если где-то непонятное поведение или надо исправить - есть шанс в половину, что llm даст хорошую наводку на причину проблемы.
Можно быстро раскатать mvp.
А теперь о проблемах
Агенты - чудовищные пожиратели токенов. Когда я использовал бесплатное api со скоростью инференса 50 токенов, на задачу которая решается за 1.5 часа ручного кодинга ушло ~48 часов непрерывной работы агента. Причем задача решена не была, только частичные наработки, которые надо допиливать напильником. И у меня есть ощущение, что на проверки - не помер ли агент в процессе и что он так долго делает - я потратил половину времени от ручного написания кода)
Llm ужасны в нелокализованных задачах. Дайте агенту обширную задачу требующую внести изменения в несколько файлов - и он перечитает их по 10 раз, и перепишет в 5 раз больше чем нужно, зачастую сломав что-то другое, что до этого работало. Я уже видел задачи, когда проблема решалась точечным изменением одного флага, а llm переписывала 800 строк кода.
Llm вообще не знает что такое производительность. Там, где агент писал мне решение, которое почти работало (и правкой импортов, мелочей и пары условий - завелось), я получил 6 кадров на сцене, которая не нёсет никакой нагрузки. Я попросил оптимизировать, и он оптимизировал, но вообще не то, что на самом деле жрало ресурсы. Пол часа напильника, и 6 фпс превратились в 120, но для этого надо понимать код. Оптимизировать написанный код - может быть значительно сложнее, чем написать оптимальный сразу, особенно когда проблемы ты находишь не сразу, а когда сверху ещё 20 зависимостей и сотни строк кода.
Ну и главная проблема - в один прекрасный момент агенты даже, блин, на микроскопической кодовой базе - впадают в тупняк. Они начинают ходить по файлам кругами, переживая контекст и повторяя круг, переписывают одни и те же параметры также обратно, ломают по очереди две фичи туда обратно, чиня одну и ломая вторую, или пишут семиступечантые вундервафли там, где нужно сделать что-то очень простое. И вот когда у тебя один - два новых класса и ты сталкиваешься с проблемой - можно спасти бедолагу руками. Но когда у тебя 100к строк кода, с архитектурой от llm (у меня в одном проекте например агент использовал 3 разных подхода к di в разных классах и 2 к построению интерфейса, и смешал несколько архитектур), то исправить одну протекающую проблему - может занять недели или месяцы.
Пока - по ощущениям, llm в качестве кодера - это как болиды формулы 1. Они очень быстрые, очень красивые, громко звучат, но на треке. И чем дальше ты от идеального трека к суровой реальности, тем больше экспоненциально растут в тебя проблемы.
Так полыхают не потому, что не принимают новый инструмент, а потому, что им пытаются ссать в уши, что он работает намного лучше, чем оно есть по факту.
Я вот всеми руками за, чтобы я решал одну задачу в агент другую или 10, но что codex, что Клод, что chatgpt + kilo code - ну ни одну задачу продуктовую пока не смогли решить, ни с каким промптом. Ни декомпозированную, ни описанную, ни "как есть". Варят килотонны токенов, перечитывают десятки файлов проекта, и в конце составляют план из чуши или вносят изменения в файлы, которые вообще к делу отношения не имеют.
Да вот прямо час назад - я попросил deepseek в чате отцентровать элемент, и все что он сделал - описал какой он молодец и добавил в код комментарии. Комментарии Карл, без единой правки меняющий результат работы программы. Нет, конечно если по пытать его пол часика, он выдаст кривое решение, но я в коде это центрование напишу за три, просто я хотел за 10 секунд.
Ну не годятся пока инструменты, чтобы реально отказаться от знания кода, даже близко не похоже.
Тут как со статистикой. Не нужно даже врать - можно не договаривать. Нет ровным счётом ничего сложного в том, чтобы написать с нуля проект на сто миллионов строк кода ии агентом. Например если твоя задача типична и часто встречалась (например сделать 100500 мини игр в одной), или есть твоё ТЗ уже на сто миллионов строк кода, и главное, если каждый новый блок кода мало взаимодействует с остальным. Например можно нагенерировать какой нибудь декодер кучи форматов, где связанная часть - чисто один файл с выбором in/out, а остальное - раздельные атомарные декодеры.
Проблемы у llm начинаются когда тебе надо не написать проект с нуля а внести правку в существующую многоступенчатую систему. У меня codex на бесплатном api со скоростью инференса 50 токенов в секунду - 6 часов варил одну очевидную строку кода (я решил просто проверить, а не сделал сам)
Пфф, да это вообще легко, вы мне скажите с какого прогона получается внести точечные изменения в этот код из 500строк. Я вот даже на микроскопическом пет проекте, в целях эксперемента, из 4х фич с помощью агента и топовой llm смог реализовать только 1 (как раз ту, где 90% - код с нуля, и 10% использование существующего), и то самую простую. На остальных начинались свистопляски с ломанием базы данных, других частей кода, или зацикливание.
Ах если бы оно так работало, то моя задача - добавить новый тип тренировки для кардио в моё пет приложение уже была бы готова. На деле, оно варит проект дольше, чем я бы написал этот код, а в результирующем плане предлагает столько изменений которые не нужны для задачи, что потом ещё десять итераций потребуется чтобы их исправить.
Это в корне меняет дело. Ведь если я до этого говорил, о том, что вы пишете на ЯП и получаете однозначно понятный результат, то теперь то значит, что вы пишите на ЯП и получаете однозначно понятный во результат).
В индустрии целые виды фреймворков (rect, compose) и инструментов (docker) и функциональное программирование целиком, сложились ради того, чтобы исключить состояние, потому что состояние сложно контролировать.
А теперь у нас за состояние (код) - будет отвечать ещё и инструмент, который сам вносит море неопределённости. Покрыть все тестами - это конечно звучит как план, только кто все эти тесты напишет, придумает и проверит? Вот у меня llm написала (с некоторыми правками от меня) исполняемый код, он даже решает поставленную задачу, только вместо 120 - выдает 6 кадров, это значит тестами надо крыть не только данные/результат, но и производительность. А если она падает на специфических данных/по памяти/после 100 прогонов.
Нет, как инструмент помощи и решения локальных микрозадач или тревиальных сценариев - ок, как замена ЯП - это яйцо настолько сырое, что ещё не родилась курица которая должна его снести.
В целом, llm агенты неплохи и реально могут поднять производительность - когда ты берешь на себя сложную работу, а на втором экране даёшь агенту небольшую другую задачу (или анализ другой большой задачи). Я так делаю с локальной поднятой qwen3-coder. Сам беру комплексные задачи, а кнопки перекрасить, дизайн подвигать, или найти откуда прилетает параметр - отдаю агенту. Когда он выдает результат - тратишь 2 минуты на ревью, и отправляешь на следующую задачу или на новую итерацию по той-же.
Но комплексные и сложные задачи даже Клод решает пока настолько плохо, что количество итераций и сложность написания тех задания сводит пользу такого подхода на ноль
В статье упоминается про размывание ролей - как code review будет делать менеджер или дизайнер?)
Языки программирования - от ассемблера на низком уровне до js на высоком - строго детерменированны и формализованы. Llm хаотичны, недетерменированны, и не формализованы.
Чтобы выполнить конкретную операцию на js или asm - всегда есть четкий алгоритм действий, если задача выполнима. На llm никогда нет четкого промтпа даже если задача выполнима.
И самая большая проблема с которой я сталкиваюсь все время - описание задачи для llm достаточно формализованно и четко, сложнее, чем написание кода для решения этой задачи, если речь о правках уже существующего функционала, просто потому, что язык программирования высокого уровня - это и есть язык для четкого и лаконичного описания преобразований данных, а человеческая речь для этого подходит сильно хуже.
Так их одна и та-же llm пишет)
Ну близко но не совсем)) откровенно вирусные приложения, и те, которые используют известные уязвимости - отловит гугловский автоанализатор. Если будут подозрительные пермишены или опасные - высока вероятность попасть на ручную проверку индусом - и там уже не пройти. Ну и по правилам - те приложения, которые тянут произвольный исполняемый код с сервера и запускают (уж не знаю что имеется в виду - какой нибудь хитровыкручкнный eval в java через рефлексию или ndk) - запрещены (termicus из стора из за это не поддерживает репозитории, а вот с их сайта - запросто). Хотя практика показывает, что это не касается js кода.
Как человек разрабатывающий мобильные приложения - могу сказать как минимум, что в той-же яндекс метрике, которая обязательна для некоторых типов приложений по закону - есть режим записи экрана (внутри приложения). Если он включен, то аналитики могут посмотреть запись пользовательского сеанса и все действия (но не аппаратно ускоренные окна типо камеры или видео). При этом - куча приложений типо телеги и ВК - по умолчанию открывают ссылки не в системном браузере а прямо в приложении - и это потенциальная утечка.
Сбербанк в своё время заставил меня удалить их приложение а потом и в целом отказаться от услуг тем, что их приложение требовала "для работы встроенного антивируса" - доступ к списку контактов, истории звонков и ещё куче всего (к слову доступ к "телефону" по идее был даже адекватен т.к. позволял получить id девайса и вроде как понять подмену устройства или типо того, но беда в том, что он давал ещё кучу прав в придачу)
А так - за 10 лет разработки, злонамеренных случаев слежки в больших компаниях не встречал, и утаить это не так просто. Думаю такое могут позволить себе библиотеки выдающие api для аналитики. Но вот для аналитики собственно - каждый шаг/клик/просмотр - будет записан.
Рекомендации банальны - отключаете встроенный браузер в приложении (почти всегда есть галка - использовать системный), читайте какие разрешения и зачем просит приложение (банку выдавать контакты не нужно, а вот по тупости систем прав в android - приложению весов - может потребоваться доступ к местоположению потому что без него доступ к bluetooth не получить). Ну и если приложение загоняет вас в системные настройки чтобы получить разрешение (быть поверх всех окон например) - значит это особо опасный пермишн - подумать надо с запасом)
А в целом все как всегда - если читать что написано, будете уязвимы только к 0d уязвимостям)
Может это конкретно с android studio или jetbrain-овскими ide такая беда, но все расширения встраивающиеся туда как будто написаны тем самым llm без участия человека - бесконечные баги, утечки памяти, не очень удобный интерфейс и свойства периодически класть студию. У оценки у них всех около 3/5
Если xray + vless на хостинг ходит, а amneziaWg ни в каких вариациях нет - это достаточный симптом?
Учитывая что скрипт явно нагенерен нейронкой, а автор пишет что "писал скрипт ночью" - сразу возникло сомнение по поводу правдивости всего текста. Хотя может просто неудачный оборот)
А где-то amneziaWg ещё работает? О.о
В трёх локациях где я бывал - уже года полтора как работает в лучшем случае xray + vless, и тот не всегда
Потому что написали техническую статью на сайте про политику и нейросетевой слоп, все же просто.
Ага, и от того, что их статью захейтили, они плача пойдут вешаться и саботировать работу, нуну.
Просто не будет от них больше никаких статей, а потом и от других не будет. Да их и сейчас уже нет. А ещё хейтерство и разобщённость в it сообществе лишь подтвердит в глазах этих людей правильность их работы.
У меня вот были наброски двух больших технических статей про мобильную разработку в черновиках, но после реакции хабра, когда мне наставили минусов просто за ответ на вопрос, потому что тема вопроса им не понравилась - я решил их на хабр не писать.
Зачем писать технические статьи на сайт про политику.
По делу все человек сказал. Технические статьи и так помирают, а тут ещё и авторов которые хоть что-то правдоподобное пишут минусуют по политическим причинам. Напоминает блм в США и моменты когда за выражение что гендера два - в Европе с работы с позором увольняли. Хабр больше не сайт про технические статьи, надо искать новый.