По моим ощущениям уровень программирования LLM сейчас это максимум метод или класс, по готовому интерфейсу. Вопрос архитектуры должен брать на себя все еще человек, как вариант, можно попросить другую модель помочь спроектировать архитектуру, описать паттерны и подходы, ограничения и связь компонентов, но все равно приходится вручную следить, чтобы эти правила соблюдались
Можно спокойно написать модели "Реализуй метод А, с параметрами B, C, чтобы возвращал D" - с этим модель справится довольно легко и быстро и это по сути та самая "рутина", которую уже можно отдать LLM, но нельзя написать "Сделай мне фичу А, чтобы она работала так-то так-то", тут уже велик шанс получить хоть и работающий, но очень сложный в понимании и связях код
У меня вопрос по зависимостям, нет ли тут цикличных связей? Ведь в main.go мы объявляем структуру app и вызываем методы, которые объявлены в другом файле, который по сути имеет в зависимостях main.go
и получаешь не пойми что, потом долго уговариваешь его сделать как надо, а потом в очередной итерации он осознает что все ваще не так и переписывает половину проекта как ему хочется, то тут далеко не уедешь
Больше похоже, что ваш «умный ПМ», это тот самый эффективный менеджер в самом худшем смысле слова. Вместо того, чтобы оставить работающий механизм с топ перфомансом (автор это подсвечивал), ваш менеджер обязательно сломает эту систему, чтобы что? Защитить свою значимость? Удовлетворить какие-то внутренние амбиции? Тут как никогда работает правило «работает - не трогай», особенно если это еще и подтверждается другим косвенными метриками
А что такое осмысленное? Вопрос довольно сложный, потому что зависит от нескольких вводных... и сходу на него не ответить
Еще момент, допустим у нас есть картинка 512 на 512, то есть пикселей в ней 512^2. Допустим картинка черно-белая, то есть у нас всего 2^512^2 вариантов... ииииии.... большая часть из них будет простым шумом... шансы попасть не на шум очень маленькие... поэтому простой перебор не очень подходит, даже с ИИ
В целом да, можно даже дальше пойти, почему бы просто не иметь "личного консультанта" в каждом магазине, который все знает и сможет правильно выбрать товар. Тут конечно есть момент, а будет ли этот консультант надежным, но так можно сказать и про "независимых агентов, кто помешает компаниям заносить в девелоперов агентов деньги, чтобы агент выдавал "нужные ответы", короче ждем рекламу от AI агентов и прочие промоушен сценарии
Если так подумать, то одним из направлений развития ПО может статьи ИИфикация интерфейсов и API. То есть когда приложение создается не только для человека, но и для AI агентов. Такое конечно же возможно, если будет бурное развитие AI агентов
Без примеров "как надо" и "как не надо" статья не особо имеет смысла, так как все слишком абстрактно и многие поймут по своему. Пора уже привыкнуть к этому
Если появится возможность блокировать контракты ( не важно по каким причинам ), это станет инструментом для манипуляций. Кто решает, что контракт вредоносный? Какой-то единый орган/организация? Но ведь сеть децентрализована, а если это решается пользователями, возможны способы обмана. В любом случае прецедент будет и это подорвет доверие к сети
Тут есть нюанс, при использовании такой "фабрично кнопки", у вас будет тянутся код всех кнопок, даже если вы используете только одну-две. И какой-нибудь tree shaking тут тоже не поможет
Ууууууф, честно говоря, сложновато. Предложил бы сначала "на кубиках" объяснить общие понятия и концепции работы, а уже потом погружать в поля, классы, код. А то сейчас не очень складывается понимание, что там происходит
Как выглядит и работает очередь задач? Как расставляются приоритеты? Это как рассказывать eventlooop описывая только сигнатуры всяких requestAnimationFrame
На кого будет восстановлен пароль, когда в форме восстановления пароля будет введено "pewpew"
На ту почту которая привязана к аккаунту "pewpew", почему вы решили, что вк не будет делать ни каких проверок только потому что логин у почты/странички совпадает?
По моим ощущениям уровень программирования LLM сейчас это максимум метод или класс, по готовому интерфейсу. Вопрос архитектуры должен брать на себя все еще человек, как вариант, можно попросить другую модель помочь спроектировать архитектуру, описать паттерны и подходы, ограничения и связь компонентов, но все равно приходится вручную следить, чтобы эти правила соблюдались
Можно спокойно написать модели "Реализуй метод А, с параметрами B, C, чтобы возвращал D" - с этим модель справится довольно легко и быстро и это по сути та самая "рутина", которую уже можно отдать LLM, но нельзя написать "Сделай мне фичу А, чтобы она работала так-то так-то", тут уже велик шанс получить хоть и работающий, но очень сложный в понимании и связях код
У меня вопрос по зависимостям, нет ли тут цикличных связей? Ведь в main.go мы объявляем структуру app и вызываем методы, которые объявлены в другом файле, который по сути имеет в зависимостях main.go
Как такие зависимости разруливаются?
Это же дебют Гроба? Если что в честь фамилии, а не то, о чем подумали
UPD: ошибка, это не он
Ну с человеком понятно, а с ИИ то что?
Больше похоже, что ваш «умный ПМ», это тот самый эффективный менеджер в самом худшем смысле слова. Вместо того, чтобы оставить работающий механизм с топ перфомансом (автор это подсвечивал), ваш менеджер обязательно сломает эту систему, чтобы что? Защитить свою значимость? Удовлетворить какие-то внутренние амбиции?
Тут как никогда работает правило «работает - не трогай», особенно если это еще и подтверждается другим косвенными метриками
А что такое осмысленное? Вопрос довольно сложный, потому что зависит от нескольких вводных... и сходу на него не ответить
Еще момент, допустим у нас есть картинка 512 на 512, то есть пикселей в ней 512^2. Допустим картинка черно-белая, то есть у нас всего 2^512^2 вариантов... ииииии.... большая часть из них будет простым шумом... шансы попасть не на шум очень маленькие... поэтому простой перебор не очень подходит, даже с ИИ
В целом да, можно даже дальше пойти, почему бы просто не иметь "личного консультанта" в каждом магазине, который все знает и сможет правильно выбрать товар. Тут конечно есть момент, а будет ли этот консультант надежным, но так можно сказать и про "независимых агентов, кто помешает компаниям заносить в девелоперов агентов деньги, чтобы агент выдавал "нужные ответы", короче ждем рекламу от AI агентов и прочие промоушен сценарии
Если так подумать, то одним из направлений развития ПО может статьи ИИфикация интерфейсов и API. То есть когда приложение создается не только для человека, но и для AI агентов. Такое конечно же возможно, если будет бурное развитие AI агентов
Давайте просто выкатывать debug сборки в прод)
Без примеров "как надо" и "как не надо" статья не особо имеет смысла, так как все слишком абстрактно и многие поймут по своему. Пора уже привыкнуть к этому
А что за компания то?)
Если появится возможность блокировать контракты ( не важно по каким причинам ), это станет инструментом для манипуляций. Кто решает, что контракт вредоносный? Какой-то единый орган/организация? Но ведь сеть децентрализована, а если это решается пользователями, возможны способы обмана. В любом случае прецедент будет и это подорвет доверие к сети
Тут есть нюанс, при использовании такой "фабрично кнопки", у вас будет тянутся код всех кнопок, даже если вы используете только одну-две. И какой-нибудь tree shaking тут тоже не поможет
Ууууууф, честно говоря, сложновато. Предложил бы сначала "на кубиках" объяснить общие понятия и концепции работы, а уже потом погружать в поля, классы, код. А то сейчас не очень складывается понимание, что там происходит
Как выглядит и работает очередь задач? Как расставляются приоритеты? Это как рассказывать eventlooop описывая только сигнатуры всяких requestAnimationFrame
Хотел спросить про другие вопросы, а потом понял, что это перевод) В общем, интересно, конечно, есть ли объективный профит от всей этой затеи
Пара вопросов
Как в итоге повлиял этот переход на скорость загрузки и работу сайта? Есть ли объективные цифры/замеры?
Сколько в итоге у вас получилось серверных компонентов? 10%? 20%?
Есть ли какие то практик, как быстро оценить, какая часть приложения доступна для перевода, чтобы сразу понять, что это того стоит?
Все вызовы к localStorage лучше оборачивать в try-catch, иначе можно поймать различные багули с доступом, например, в FF
О какой связности речь? И какую логику хотите от отображения отделить?
На ту почту которая привязана к аккаунту "pewpew", почему вы решили, что вк не будет делать ни каких проверок только потому что логин у почты/странички совпадает?