На самом деле проблема значительно глубже. Это не тирания смартфонов, а тирания мобильных телефонов в принципе. Представьте, что у вас нет мобильного телефона. В большинстве банков вам не откроют счёт. Даже некоторые государственные документы может быть затруднительно получить без номера мобильного телефона. Скидку хотите - хрен вам. В интернете хотите зарегистрироваться в соцсети или ещё где - поди найди провайдера электронной почты, не требующего валидацию номера телефона. Де-факто человек без мобильного телефона очень существенно ограничен в правах, хотя законодательно такая дискриминация запрещена.
Вы, вероятно, немного упускаете контекст, но и я, и автор говорим о фрилансе в качестве начала карьеры. Лично я фрилансом не занимаюсь уже 9 лет, поэтому это уже давно не моё болото.
нахватается везде по чуть-чуть
В начале карьеры именно это и нужно. Это поможет определиться со специализацией. Кроме того, это хорошая база, чтобы потом вырасти в T-shaped специалиста.
Мне приходилось участвовать в найме людей, и потом их менторить. Когда берёшь на работу вчерашнего фрилансера, получаешь самостоятельного сотрудника, умеющего решать проблемы. Остаётся только научить его стандартам, принятым в компании. А когда ты берёшь на работу выпускника курсов, ты получаешь сотрудника, который сам не может сделать вообще ничего. Когда ты отойдёшь от него, он просто будет сидеть и ждать, чтобы ты подошёл обратно.
Понятно, что на фрилансе сколько ни расти, выше крепкого джуна не вырастешь. Но фриланс - это отличный фильтр, через который отсеиваются всякие залётные, у которых нет ни способностей, ни мотивации.
Ну если брать задачу с тем же телеграм ботом, фрилансеру нужно будет сделать его от и до. Начиная от получения токена, заканчивая деплоем кода на сервер. А на галере начинающему скажут пиши код отсюда и до обеда, запускай бота этой командой, результат смотри здесь. Вот и получается, что фрилансер обладает более широким кругозором. Вы правы в том, что знания на галере более качественные: расскажут всякие best practices и стандарты кода. Но эти знания всегда более узконаправленные, чуть шаг в сторону и будет "а я не знаю, мне ребята настроили, оно как-то работало". А потом просишь фронтендера кнопку подвинуть, а он говорит "это к верстальщику, а я фронт".
Дичайше плюсую автору. Сам начинал более 10 лет назад именно с фриланса. Хочу добавить, что вовсе не обязательно нужно регистрироваться на биржах. Самые первые заказы можно найти через друзей, доски объявлений и ресурсы комьюнити - как правило в чатах или форумах, посвящённых какой-либо технологии есть раздел с объявлениями.
Больше половины работодателей не считают фриланс коммерческим опытом.
Вот это они кстати зря. Работа на фрилансе - это самый настоящий коммерческий опыт, но это не командная работа со всеми вытекающими - без код-ревью, без CI/CD и вообще скорее всего без автоматизации, без менеджмента. Но, это опыт решения реальных, а не выдуманных задач. Опыт взаимодействия с серверами, хостингами и т.д. А то ведь бывает, что выпускник курсов, имея три года опыта работы на галере, понятие не имеет, как устроен сервер, на котором работает его проект.
Эффективность скорее всего без вопросов. Если человек в принципе в состоянии сделать проект в одиночку, значит его эффективность уже выше среднего. По срокам тоже есть нюансы. Отсутствие созвонов, отсутствие необходимости вникать в стратегию и архитектуру придуманную другим человеком - всё это очень сильно сокращает затраченное время.
Вот это уже ближе к правде. Но тут имеет смысл сравнивать команды. Например, насколько 5 человек + ИИ могут работать быстрее или медленнее, чем просто 5 человек.
Смысл в честном сравнении. Сможет ли ИИ сделать за 40 часов то, что делает программист за 40 часов. 100 игр за 6 часов - это абсолютно бессмысленное сравнение. Самая главная лажа тут в том, что 3 минуты на игру почти 100% означает, что генерация делалась в один проход. Без прогона тестов, без попыток корректировки написанного. Пускай бы лучше гпт те самые 6 часов работал над одной игрой, вот это было бы интересно посмотреть.
А это я у автора спрашиваю. Он, исходя из факта, что 100 игр за 6 часов получились так себе, пришёл к выводу, что чат гпт его не заменит. Но это прямо какая-то очень странная метрика. Я поверю, что автор сможет сделать игру за неделю. Ну так давайте чат гпт тоже будет 40 часов пыхтеть над одной игрой, а потом будем сравнивать результат.
Не знаю, зачем мне пробовать смотреть на свои руки 8 часов. Но я уже 4 года работаю за ноутбуком, сидя но одном и том же стуле. Стул простой, на колёсиках, с газ-патроном, даже спинка не регулируется. Просто сделал его чуть ниже и работаю - удобно. Вот если пересесть на кухню на обычный стул, то там уже да, болит шея через два часа.
Кстати, перед покупкой ноута работал целый год за тем же столом на том же стуле на мак мини с 23-дюймовым моником. Купил ноут, сперва думал последовать рекомендациям и подключить к нему клаву и моник, но сначала просто поставил ноут на стол и включил и сразу понял, что нафиг не нужно мне к нему ничего. Имея в наличии моник и клаву, ни разу даже не возникло желания их подключить.
При чём тут проекты? Речь не о проекте, а об экосистемах, заточенных под конкретные ЯП, фреймворки, CMS и т.д. Например, если речь идёт о любом приложении на React, то экосистема такого приложения обязательно включает стандарты ECMA, Jsdoc (включая разрешение типов), опционально могут включаться правила ESLint, Typescript, правила для package.json и т.д. Неважно, какая архитектура у проекта, неважно кого там звали это разгребать. Экосистема существует в любом случае. А IDE, в том числе джетбрейновские, включают программную реализацию правил и других возможностей экосистемы.
Например, если написать код:
/**
* @param {number} x.
*/
function kek(x) {
return x + 1;
}
console.log(kek('lol'));
то, любая IDE ругнётся на последнюю строчку, т.к. тип передаваемого параметра не соответствует. Всё благодаря jsdoc, который даже не является частью спецификации языка, но является частью экосистемы. И чтобы это сделать, нашей IDE не нужно сканировать миллион проектов на гитхабе.
Это самый примитивный пример, но это иллюстрация того, что такое экосистема. Любая подобная экосистема содержит ряд правил и инструментов, помогающих писать более надёжный код.
Что самое интересное, тот, кто сел изучать язык только что, знать не знает о каких-либо экосистемах. Он сидит в блокноте и ему норм. Он скажет, вот чушь какая - целых три строчки комментария набирать ради непонятно чего. И лишь со временем к нему придёт понимание, что эти три строчки с помощью автодополнения IDE пишутся за пару сек и потом очень помогают избежать ряда ошибок.
Так вот, использование LLM общего назначения для написания программного кода - это то же самое, что писать код в блокноте, игнорируя всю экосистему языка. Да условный ChatGPT практически гарантированно найдёт ошибку в коде выше и объяснит её, но какой ценой? По сути дела мы имеем кучу дата-центров по всему миру, которые занимаются реверс-инжинирингом того, что и так работает не первый десяток лет на любом офисном компьютере.
Можно сравнить ресурсы и время, которые затратит PhpStorm, чтобы подсветить ошибку в коде выше, с ресурсами и временем, которые потратит на это любая LLM. По этим бенчмаркам LLM будет выглядеть просто как какое-то днище.
И теперь вишенка на торте: майкрософт говорит, что 30% их кода сейчас генерируется с помощью ИИ. А теперь давайте посчитаем сколько процентов кода было сгенерировано обычным автодополнением IDE в доИИшную эпоху? Когда набираешь две буквы, и выбираешь переменную с именем из 10 букв. Или всякие import statements, которые вообще полностью автоматически вставляются. Там запросто выйдет, что ещё до бума ИИ программисты набирали сами не более 50% кода. И это всё благодаря грамотно выстроенной экосистеме. То есть какие-то чуваки придумали говорилку, научили её писать код, но за счёт того, что они практически проигнорировали достижения экосистем языков, польза от потраченных ресурсов выглядит на данный момент достаточно сомнительно.
Смотря что вы подразумеваете под наоборот. Давайте попробуем разобрать варианты:
Если специалист хороший, то ему бывает трудно понять достижения предшественников. - не бывает, это противоречит понятию "хороший специалист". Хороший специалист обязан ориентироваться в экосистеме своего стека и обязан уметь читать и понимать чужой код.
Если специалист плохой, то ему бывает легко понять достижения предшественников. - бывает. Достижения предшественников, как правило, довольно очевидны, и даже начинающий может легко их оценить.
Если специалист плохой, то ему бывает трудно понять провалы предшественников. - конечно бывает. Это же плохой специалист, вероятно он потому и плохой, что у него трудности с пониманием.
Если специалист плохой, то ему бывает трудно понять достижения потомков. Тут могу разве что сказать, что сегодня в завтрашний день смотреть могут не все.
Я думаю, это надо закладывать ещё до этапа обучения, а именно на этапе проектирования архитектуры модели. Как в маленьких моделях есть раздельные модели для текста, для картинок и т.д. Программный код не должен восприниматься, как простое текстовое подмножество, он должен изначально приниматься, как отдельное явление.
Ну и что? Я в первые три года своей карьеры тоже не знал. И вообще думал, нафиг все эти IDE, если Sublime text достаточно. Сейчас у зумеров три года опыта - это уже C-level system architect как минимум. Но мы то знаем, что на самом деле стоит за этими регалиями.
На самом деле проблема значительно глубже. Это не тирания смартфонов, а тирания мобильных телефонов в принципе. Представьте, что у вас нет мобильного телефона. В большинстве банков вам не откроют счёт. Даже некоторые государственные документы может быть затруднительно получить без номера мобильного телефона. Скидку хотите - хрен вам. В интернете хотите зарегистрироваться в соцсети или ещё где - поди найди провайдера электронной почты, не требующего валидацию номера телефона. Де-факто человек без мобильного телефона очень существенно ограничен в правах, хотя законодательно такая дискриминация запрещена.
Вы, вероятно, немного упускаете контекст, но и я, и автор говорим о фрилансе в качестве начала карьеры. Лично я фрилансом не занимаюсь уже 9 лет, поэтому это уже давно не моё болото.
В начале карьеры именно это и нужно. Это поможет определиться со специализацией. Кроме того, это хорошая база, чтобы потом вырасти в T-shaped специалиста.
Мне приходилось участвовать в найме людей, и потом их менторить. Когда берёшь на работу вчерашнего фрилансера, получаешь самостоятельного сотрудника, умеющего решать проблемы. Остаётся только научить его стандартам, принятым в компании. А когда ты берёшь на работу выпускника курсов, ты получаешь сотрудника, который сам не может сделать вообще ничего. Когда ты отойдёшь от него, он просто будет сидеть и ждать, чтобы ты подошёл обратно.
Понятно, что на фрилансе сколько ни расти, выше крепкого джуна не вырастешь. Но фриланс - это отличный фильтр, через который отсеиваются всякие залётные, у которых нет ни способностей, ни мотивации.
Ну если брать задачу с тем же телеграм ботом, фрилансеру нужно будет сделать его от и до. Начиная от получения токена, заканчивая деплоем кода на сервер. А на галере начинающему скажут пиши код отсюда и до обеда, запускай бота этой командой, результат смотри здесь. Вот и получается, что фрилансер обладает более широким кругозором. Вы правы в том, что знания на галере более качественные: расскажут всякие best practices и стандарты кода. Но эти знания всегда более узконаправленные, чуть шаг в сторону и будет "а я не знаю, мне ребята настроили, оно как-то работало". А потом просишь фронтендера кнопку подвинуть, а он говорит "это к верстальщику, а я фронт".
Дичайше плюсую автору. Сам начинал более 10 лет назад именно с фриланса. Хочу добавить, что вовсе не обязательно нужно регистрироваться на биржах. Самые первые заказы можно найти через друзей, доски объявлений и ресурсы комьюнити - как правило в чатах или форумах, посвящённых какой-либо технологии есть раздел с объявлениями.
Вот это они кстати зря. Работа на фрилансе - это самый настоящий коммерческий опыт, но это не командная работа со всеми вытекающими - без код-ревью, без CI/CD и вообще скорее всего без автоматизации, без менеджмента. Но, это опыт решения реальных, а не выдуманных задач. Опыт взаимодействия с серверами, хостингами и т.д. А то ведь бывает, что выпускник курсов, имея три года опыта работы на галере, понятие не имеет, как устроен сервер, на котором работает его проект.
Эффективность скорее всего без вопросов. Если человек в принципе в состоянии сделать проект в одиночку, значит его эффективность уже выше среднего. По срокам тоже есть нюансы. Отсутствие созвонов, отсутствие необходимости вникать в стратегию и архитектуру придуманную другим человеком - всё это очень сильно сокращает затраченное время.
Тут надо начинать с того, что ряд продуктов можно сделать в одиночку и без нейросетей.
Но ведь и кулер в видеокарте, на которой LLM крутится, чистит человек.
Вот это уже ближе к правде. Но тут имеет смысл сравнивать команды. Например, насколько 5 человек + ИИ могут работать быстрее или медленнее, чем просто 5 человек.
Тем не менее, полно механизмов, которые выполняют работу без участия человека. Например посудомоечная машина: загрузил грязную посуду, достал чистую.
Смысл в честном сравнении. Сможет ли ИИ сделать за 40 часов то, что делает программист за 40 часов. 100 игр за 6 часов - это абсолютно бессмысленное сравнение. Самая главная лажа тут в том, что 3 минуты на игру почти 100% означает, что генерация делалась в один проход. Без прогона тестов, без попыток корректировки написанного. Пускай бы лучше гпт те самые 6 часов работал над одной игрой, вот это было бы интересно посмотреть.
А это я у автора спрашиваю. Он, исходя из факта, что 100 игр за 6 часов получились так себе, пришёл к выводу, что чат гпт его не заменит. Но это прямо какая-то очень странная метрика. Я поверю, что автор сможет сделать игру за неделю. Ну так давайте чат гпт тоже будет 40 часов пыхтеть над одной игрой, а потом будем сравнивать результат.
Итог, чат гпт не смог создать 100 игр за 6 часов. А автор бы смог?
Мне, как счастливому юзеру винды, ничего об этих тормозах не известно.
А как же BOBODDY?
Не знаю, зачем мне пробовать смотреть на свои руки 8 часов. Но я уже 4 года работаю за ноутбуком, сидя но одном и том же стуле. Стул простой, на колёсиках, с газ-патроном, даже спинка не регулируется. Просто сделал его чуть ниже и работаю - удобно. Вот если пересесть на кухню на обычный стул, то там уже да, болит шея через два часа.
Кстати, перед покупкой ноута работал целый год за тем же столом на том же стуле на мак мини с 23-дюймовым моником. Купил ноут, сперва думал последовать рекомендациям и подключить к нему клаву и моник, но сначала просто поставил ноут на стол и включил и сразу понял, что нафиг не нужно мне к нему ничего. Имея в наличии моник и клаву, ни разу даже не возникло желания их подключить.
При чём тут проекты? Речь не о проекте, а об экосистемах, заточенных под конкретные ЯП, фреймворки, CMS и т.д. Например, если речь идёт о любом приложении на React, то экосистема такого приложения обязательно включает стандарты ECMA, Jsdoc (включая разрешение типов), опционально могут включаться правила ESLint, Typescript, правила для package.json и т.д. Неважно, какая архитектура у проекта, неважно кого там звали это разгребать. Экосистема существует в любом случае. А IDE, в том числе джетбрейновские, включают программную реализацию правил и других возможностей экосистемы.
Например, если написать код:
то, любая IDE ругнётся на последнюю строчку, т.к. тип передаваемого параметра не соответствует. Всё благодаря jsdoc, который даже не является частью спецификации языка, но является частью экосистемы. И чтобы это сделать, нашей IDE не нужно сканировать миллион проектов на гитхабе.
Это самый примитивный пример, но это иллюстрация того, что такое экосистема. Любая подобная экосистема содержит ряд правил и инструментов, помогающих писать более надёжный код.
Что самое интересное, тот, кто сел изучать язык только что, знать не знает о каких-либо экосистемах. Он сидит в блокноте и ему норм. Он скажет, вот чушь какая - целых три строчки комментария набирать ради непонятно чего. И лишь со временем к нему придёт понимание, что эти три строчки с помощью автодополнения IDE пишутся за пару сек и потом очень помогают избежать ряда ошибок.
Так вот, использование LLM общего назначения для написания программного кода - это то же самое, что писать код в блокноте, игнорируя всю экосистему языка. Да условный ChatGPT практически гарантированно найдёт ошибку в коде выше и объяснит её, но какой ценой? По сути дела мы имеем кучу дата-центров по всему миру, которые занимаются реверс-инжинирингом того, что и так работает не первый десяток лет на любом офисном компьютере.
Можно сравнить ресурсы и время, которые затратит PhpStorm, чтобы подсветить ошибку в коде выше, с ресурсами и временем, которые потратит на это любая LLM. По этим бенчмаркам LLM будет выглядеть просто как какое-то днище.
И теперь вишенка на торте: майкрософт говорит, что 30% их кода сейчас генерируется с помощью ИИ. А теперь давайте посчитаем сколько процентов кода было сгенерировано обычным автодополнением IDE в доИИшную эпоху? Когда набираешь две буквы, и выбираешь переменную с именем из 10 букв. Или всякие import statements, которые вообще полностью автоматически вставляются. Там запросто выйдет, что ещё до бума ИИ программисты набирали сами не более 50% кода. И это всё благодаря грамотно выстроенной экосистеме. То есть какие-то чуваки придумали говорилку, научили её писать код, но за счёт того, что они практически проигнорировали достижения экосистем языков, польза от потраченных ресурсов выглядит на данный момент достаточно сомнительно.
А существует ли хоть одна LLM, которая не обошла конкурентов по бенчмаркам?
Смотря что вы подразумеваете под наоборот. Давайте попробуем разобрать варианты:
Если специалистхороший, то ему бывает трудно понять достижения предшественников.- не бывает, это противоречит понятию "хороший специалист". Хороший специалист обязан ориентироваться в экосистеме своего стека и обязан уметь читать и понимать чужой код.Если специалист плохой, то ему бываетлегкопонять достижения предшественников.- бывает. Достижения предшественников, как правило, довольно очевидны, и даже начинающий может легко их оценить.Если специалист плохой, то ему бывает трудно понятьпровалыпредшественников.- конечно бывает. Это же плохой специалист, вероятно он потому и плохой, что у него трудности с пониманием.Если специалист плохой, то ему бывает трудно понять достиженияпотомков.Тут могу разве что сказать, что сегодня в завтрашний день смотреть могут не все.Надеюсь, я ответил на ваш вопрос.
Я думаю, это надо закладывать ещё до этапа обучения, а именно на этапе проектирования архитектуры модели. Как в маленьких моделях есть раздельные модели для текста, для картинок и т.д. Программный код не должен восприниматься, как простое текстовое подмножество, он должен изначально приниматься, как отдельное явление.
Ну и что? Я в первые три года своей карьеры тоже не знал. И вообще думал, нафиг все эти IDE, если Sublime text достаточно. Сейчас у зумеров три года опыта - это уже C-level system architect как минимум. Но мы то знаем, что на самом деле стоит за этими регалиями.