В остальном каких-либо претензий у меня нет. Но чисто по личной субъективной оценке сниму балл за итоговый ответ.
Пока тест на "программирование" будет проходить именно так, наверное, стоит относиться ко всем этим сравнениям очень скептически. Нужны формальные требования к "хорошему" коду: анализаторы, притифаеры и другие детерминированные инструменты
Еще для себя заметил один закон, чисто субъективный, но может кто-то тоже замечал
"Чем гибче разработана система, тем быстрее она архитектурно устаревает"
Происходит из-за того, что простые задачи в рамках этой гибкой системы делаются быстро и менеджер скорее дойдет до фичи, которая уже не ложится в текущую систему и ее придется переделывать полностью. Когда система неповоротливая, тяжелая дойти до такой "ломающей архитектуру" фичи менеджеру сложно, потому что он ждет когда сделают его простые фичи
А первые два закона нельзя обойти тем, что заказчикам и исполнителям говорить разную инфу? Разработчикам говоришь, что сделать надо за месяц (да они опоздают и скорее всего сделают за 1.5 месяца) Заказчикам говоришь, что делать фичу 2 месяца
По моим ощущениям уровень программирования 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
Пока тест на "программирование" будет проходить именно так, наверное, стоит относиться ко всем этим сравнениям очень скептически. Нужны формальные требования к "хорошему" коду: анализаторы, притифаеры и другие детерминированные инструменты
Тогда можно будет сравнивать кто пишет лучше код
Войди_в_меня - это конечно мощно...
Так и есть, тут проблема самореференции
Все сводится к тому, что алгоритм H завершится, только если алгоритм H не завершится, в этом и заключается парадокс
Еще для себя заметил один закон, чисто субъективный, но может кто-то тоже замечал
Происходит из-за того, что простые задачи в рамках этой гибкой системы делаются быстро и менеджер скорее дойдет до фичи, которая уже не ложится в текущую систему и ее придется переделывать полностью. Когда система неповоротливая, тяжелая дойти до такой "ломающей архитектуру" фичи менеджеру сложно, потому что он ждет когда сделают его простые фичи
А первые два закона нельзя обойти тем, что заказчикам и исполнителям говорить разную инфу?
Разработчикам говоришь, что сделать надо за месяц (да они опоздают и скорее всего сделают за 1.5 месяца)
Заказчикам говоришь, что делать фичу 2 месяца
А зачем?
По моим ощущениям уровень программирования 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