Модели как будто действительно повторяют жизненный цикл развития компьютера (удивительно, да?) - самые первые компьютеры умели делать немного и под четким присмотром человека. То же самое с моделями, мы слишком рано требуем от них "всего по нажатию одной кнопки", если требовать от них более мелкие шаги, они будут справляться с ними хорошо, человеку все еще нужно следить за последовательностью этих шагов и их валидировать... но это вопрос времени, когда сложность шагов вырастет до "все по одной кнопке"
Как будто это не баг, а фича. Может просто взять набор важных типовых задач и обучать обучать обучать модели, пока они не станут справляться с этой задачей максимально качественно. И тема самым мы решим проблемы этих задач
Тогда постепенно, закрывая шагами такие задачи, мы сможем продвинуться к какой-то прикладной пользе
Если реализация нужна на незнакомом языке или тебе совсем не хочется думать о всяких нюансах, которые базовые, просто тебе совсем лень, то LLM подойдет идеально
Вот надо тебе баш скрипт написать, ты конечно можешь пойти вспоминать или изучать команды, синтаксис и так далее, а можешь попросить модельку, она с башем хорошо работает. А если ты не можешь сформулировать к ней запрос, то сам то как собрался писать?
В больших кампаниях чаще всего кандидата рассматривают в несколько команд и найм потоковый. Кандидат проходит скрининг и тех собесы, а дальше лиды смотря на него и решают - встречать с ним или нет для финала. Решение "один собес на 1.5 часа" тут нет поможет
В остальном каких-либо претензий у меня нет. Но чисто по личной субъективной оценке сниму балл за итоговый ответ.
Пока тест на "программирование" будет проходить именно так, наверное, стоит относиться ко всем этим сравнениям очень скептически. Нужны формальные требования к "хорошему" коду: анализаторы, притифаеры и другие детерминированные инструменты
Еще для себя заметил один закон, чисто субъективный, но может кто-то тоже замечал
"Чем гибче разработана система, тем быстрее она архитектурно устаревает"
Происходит из-за того, что простые задачи в рамках этой гибкой системы делаются быстро и менеджер скорее дойдет до фичи, которая уже не ложится в текущую систему и ее придется переделывать полностью. Когда система неповоротливая, тяжелая дойти до такой "ломающей архитектуру" фичи менеджеру сложно, потому что он ждет когда сделают его простые фичи
А первые два закона нельзя обойти тем, что заказчикам и исполнителям говорить разную инфу? Разработчикам говоришь, что сделать надо за месяц (да они опоздают и скорее всего сделают за 1.5 месяца) Заказчикам говоришь, что делать фичу 2 месяца
По моим ощущениям уровень программирования LLM сейчас это максимум метод или класс, по готовому интерфейсу. Вопрос архитектуры должен брать на себя все еще человек, как вариант, можно попросить другую модель помочь спроектировать архитектуру, описать паттерны и подходы, ограничения и связь компонентов, но все равно приходится вручную следить, чтобы эти правила соблюдались
Можно спокойно написать модели "Реализуй метод А, с параметрами B, C, чтобы возвращал D" - с этим модель справится довольно легко и быстро и это по сути та самая "рутина", которую уже можно отдать LLM, но нельзя написать "Сделай мне фичу А, чтобы она работала так-то так-то", тут уже велик шанс получить хоть и работающий, но очень сложный в понимании и связях код
У меня вопрос по зависимостям, нет ли тут цикличных связей? Ведь в main.go мы объявляем структуру app и вызываем методы, которые объявлены в другом файле, который по сути имеет в зависимостях main.go
и получаешь не пойми что, потом долго уговариваешь его сделать как надо, а потом в очередной итерации он осознает что все ваще не так и переписывает половину проекта как ему хочется, то тут далеко не уедешь
Больше похоже, что ваш «умный ПМ», это тот самый эффективный менеджер в самом худшем смысле слова. Вместо того, чтобы оставить работающий механизм с топ перфомансом (автор это подсвечивал), ваш менеджер обязательно сломает эту систему, чтобы что? Защитить свою значимость? Удовлетворить какие-то внутренние амбиции? Тут как никогда работает правило «работает - не трогай», особенно если это еще и подтверждается другим косвенными метриками
А что такое осмысленное? Вопрос довольно сложный, потому что зависит от нескольких вводных... и сходу на него не ответить
Еще момент, допустим у нас есть картинка 512 на 512, то есть пикселей в ней 512^2. Допустим картинка черно-белая, то есть у нас всего 2^512^2 вариантов... ииииии.... большая часть из них будет простым шумом... шансы попасть не на шум очень маленькие... поэтому простой перебор не очень подходит, даже с ИИ
В целом да, можно даже дальше пойти, почему бы просто не иметь "личного консультанта" в каждом магазине, который все знает и сможет правильно выбрать товар. Тут конечно есть момент, а будет ли этот консультант надежным, но так можно сказать и про "независимых агентов, кто помешает компаниям заносить в девелоперов агентов деньги, чтобы агент выдавал "нужные ответы", короче ждем рекламу от AI агентов и прочие промоушен сценарии
Если так подумать, то одним из направлений развития ПО может статьи ИИфикация интерфейсов и API. То есть когда приложение создается не только для человека, но и для AI агентов. Такое конечно же возможно, если будет бурное развитие AI агентов
Модели как будто действительно повторяют жизненный цикл развития компьютера (удивительно, да?) - самые первые компьютеры умели делать немного и под четким присмотром человека. То же самое с моделями, мы слишком рано требуем от них "всего по нажатию одной кнопки", если требовать от них более мелкие шаги, они будут справляться с ними хорошо, человеку все еще нужно следить за последовательностью этих шагов и их валидировать... но это вопрос времени, когда сложность шагов вырастет до "все по одной кнопке"
Как будто это не баг, а фича. Может просто взять набор важных типовых задач и обучать обучать обучать модели, пока они не станут справляться с этой задачей максимально качественно. И тема самым мы решим проблемы этих задач
Тогда постепенно, закрывая шагами такие задачи, мы сможем продвинуться к какой-то прикладной пользе
Если реализация нужна на незнакомом языке или тебе совсем не хочется думать о всяких нюансах, которые базовые, просто тебе совсем лень, то LLM подойдет идеально
Вот надо тебе баш скрипт написать, ты конечно можешь пойти вспоминать или изучать команды, синтаксис и так далее, а можешь попросить модельку, она с башем хорошо работает. А если ты не можешь сформулировать к ней запрос, то сам то как собрался писать?
В больших кампаниях чаще всего кандидата рассматривают в несколько команд и найм потоковый. Кандидат проходит скрининг и тех собесы, а дальше лиды смотря на него и решают - встречать с ним или нет для финала. Решение "один собес на 1.5 часа" тут нет поможет
Я вот такую штуку сделал https://thisman.github.io/my-valentine/
Маленькая игра, где до результата надо еще добраться
Пока тест на "программирование" будет проходить именно так, наверное, стоит относиться ко всем этим сравнениям очень скептически. Нужны формальные требования к "хорошему" коду: анализаторы, притифаеры и другие детерминированные инструменты
Тогда можно будет сравнивать кто пишет лучше код
Войди_в_меня - это конечно мощно...
Так и есть, тут проблема самореференции
Все сводится к тому, что алгоритм 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 сборки в прод)