Здравствуйте, прочитал обе статьи и часть комментариев с большим интересом.
Экспериментирую с написанием кода с помощью LLM со времен выхода chatGPT 3.5 довольно много и местами успешно. Шишек набил тоже достаточно.
Также учил и учу трейни и джунов. Они тоже любят написать что нибудь с помощью LLM. И на ревью я эти места нахожу.
Поэтому считаю, что неплохо знаю возможности и ограничения кодогенерации LLM.
6 месяцев заняло написание MVP версии продукта. Знания и видение крипторынка и ценности, которую должен принести ваш продукт у вас уже были. Целостных знаний в каком либо языке программирования как не было, так и нет. Такие метрики как масштабируемость, безопасность, оптимальность использования ресурсов, читаемость кода человеком неизвестны.
Под словом «архитектура» в данном комментарии я понимаю структуру кода, а не использование генетических алгоритмов и т.д. Это бизнес функционал, оценивать который без глубокого погружения нельзя.
Из этого вытекают следующие проблемы:
1) Нет никого, кто досконально и точно может объяснить как работает код. Также нет документации и нормального покрытия тестами. Из этого следует, что код по сути своей уже стал легаси, ведь для его поддержки и развития придется нанимать людей и платить им деньги за то, чтобы они разобрались как этот код работает, частично, а скорее всего полностью его переписали под свое видение и чувство прекрасного. Ведь нет никого, кто бы мог защитить текущую архитектуру и объяснить ее преимущества перед подходами к которым привыкли разработчики, которых вы наймете. Забегая наперед скажу, что архитектуры в этом коде скорее всего нет.
2) Безопасность для такого продукта это краеугольный камень. Причем как со стороны аутентификации и авторизации пользователя, так и со стороны эксплуатации уязвимостей стратегий сторонними игроками. Как только продукт попадет на массовый рынок его начнут пробовать на зуб со всех сторон. LLM всегда, по моему опыту оставляет много уязвимостей в безопасности. Чтобы видеть и закрывать эти уязвимости нужны знания и опыт. В финтехе наличие такого специалиста в разработке это обязательное условие. И второе это эксплуатация стратегий бота. Его будут пробовать обмануть и заставить делать неверные выводы сливая бюджет. Чтобы защититься от этого нужен специалист от крипторынка, который вместе с разработчиками будет искать граничные случаи торговли, неучтенные в стратегиях ситуации и реализовывать решение этих проблем. Вы собираетесь работать с деньгами, это очень серьезно и людей написавших приложение с помощью LLM и давших этому приложению доступ к реальным деньгам очень ждут на рынке финансов.
3) Масштабируемость это серьезный вопрос, который зачастую требует закладки основных принципов на этапе проектирования архитектуры. В вашем случае, если вопрос такой пока совсем не стоял, масштабировать приложение малой кровью скорее всего не выйдет и придется многими итерациями приводит код к какому либо подходу архитектуры допускающей масштабируемость. Или скорее всего переписать заново.
По моему мнению, тот функционал, который вы описали в статьях, можно было написать двумя другими путями, избежав проблемы 1 и, частично, проблемы 3. А также создав задел для решения проблемы 2 малой кровью:
1) Мотивированный джун при условии постоянного контакта с вами мог написать этот MVP. Один джун. Время тут зависит от того насколько точно было поставлено ТЗ и сколько раз в процессе оно менялось.
2) Вы могли потратить 5 месяцев из 6 на обучение Питону в нужной области и за месяц написать MVP версию имея целостные знания о нужной части Питона при поддержке LLM и имея знания о том, что именно вы хотите писать.
Ваша оценка команды необходимой для написания созданного вами MVP нереалистична хотя бы потому, что команда разработки никогда бы не создала проект в таком виде, в каком он находится сейчас у вас:)
Предположим мне нужно узнать как отключить рекламу на телефоне Сяоми с ОС 15 версии.
Предположим что я даже как то нашел платную статью автора, где рассказывается об этом.
Но как мне до оплаты понять, что это именно то, что я искал?
Потому что в статье может описываться процесс для версии ОС 15.3, а у меня версия 15.1, где интерфейс имеет различия и тогда статья для меня бесполезна и надо искать другую платную статью.
Так у этого автора все истории какие то такие…. С техническими нестыковками, когда специалист претендует на высокую позицию и при этом у него спрашивают какие то азы, которые этот специалист еще и не знает.
В общем то потратил времени на объяснение ровно столько же, за сколько сделал бы задачу сам минус время на отладку. Время которое ушло бы на отладку будет потрачено на ревью и решение потенциальных косяков реализации.
С джуном я успокаиваю себя тем, что научу его и через 2-3 месяца получу человека который сможет решать подобные задачи самостоятельно. LLM модели в этом аспекте проигрывают.
С другой стороны LLM сделает эту задачу за минуты, а джун потратить часы и дни. Тут LLM явно впереди.
LLM действительно хорошо работают, когда ты точно знаешь что хочешь получить либо совсем не знаешь что тебе нужно и хочешь получить отправную точку в коде от которой можно проводить ресерч, что то вроде «реализуй такую то задачу и опиши с помощью каких инструментов ты ее реализовал и почему», далее спросить «какие еще библиотеки и подходы можно использовать для решения этой задачи.
Хм, я после совещаний, где присутствую не для галочки, а для решения проблемы чувствую себя как выжатый лимон т.к. пытаюсь понять «что говорят все эти люди», чем мне это грозит, предложить свое решение обсуждаемой проблемы.
Стажер тоже выполняет задачу с вероятностью пусть и «очень большой».
Сравнение решения интеллектуальной задачи с помощью LLM vs обычная программа сравнимо со сравнением сортировки предметов по размеру человеком и механизмом.
Сортировка механизмом будет точнее, если механизм хорошо продуман, исправен и предметы сортировки предсказуемы и просты.
Человек же всегда будет ошибаться даже в самой простой работе т.к. именно так он устроен. Но при этом человек способен сортировать предметы по размеру если внезапно изменится их форма, к примеру.
Часто выигрывают люди, более склонные к взаимовыгодному сотрудничеству. Помоги бескорыстно человеку, который может быть полезен тебе в будущем и с высокой долей вероятности этот человек поможет тебе, когда тебе нужна будет помощь. Такие люди обычно объединяются в сообщества на основе общих экономических, культурных интересов, принимают новых членов и выкидывают тех, кто к сотрудничеству не склонен и потребляет гораздо больше, чем дает взамен.
Соответственно твои родственники это не конкуренты, а люди, с которыми нужно работать и кооперироваться, сообща решая проблемы друг друга. И иногда выкидывать из вашего сообщества членов, которые только потребляют ваши ресурсы ничего не давая взамен. К тем кто не в силах больше ничего дать в силу сложившихся обстоятельств это относиться естественно не должно, им нужно помогать безальтернативно т.к. это может произойти с каждым из нас.
Очень интересный автор этот Уоттс, но я, к сожалению, так не смог закончить ни одной его книги. Либо слишком мрачные, либо слишком тяжелее для восприятия.
Если врач создал один док и лог лег в архив, это можно списать на системную ошибку, если такая ситуация повторялась у других.
Если лог о том что доктор создал документ есть, но ошибка больше не повторялась, на доктора вешается метка. 3 метки - служебная проверка - суд - срок за подделку документов.
Каждый случай при котором пациент нашел у себя в ЛК неоказанные услуги должен быть расследован.
Если уж мы затронули ассемблер то я бы привел такую аналогию:
Сам я эти времена не застал, но думаю, что когда появились более высокоуровневые языки, чем ассемблер, программисты говорили, что то вроде «а вот когда им нужно будет сделать вот именно то-то, как эти «высокоуровневые программисты» это сделают без ассемблера, а?»
И были по своему правы. Сейчас тоже есть специалисты по ассемблеру и низкоуровневые языки понемногу развиваются. Но специалистов требуется немного по сравнению с общей массой разработчиков и задачи их весьма специфичны.
Возможно также будет и с программированием на основе ИИ. Человек никуда из этого процесса не денется, просто уровень абстракции и следовательно производительность труда в очередной раз сильно возрастет.
И все равно будут нужны разработчики, которые будут писать код придумывая самостоятельно новые подходы без ИИ. Просто нужда в них будет примерно на уровне нужды в разработчиках на ассемблере сейчас.
И как матерого программиста в свитере и с бородой, который знает наизусть все методы и операторы плюсов заменили вайтишники, которые перекладывают jsonы с помощью StackOverFlow и chatGPT, так и их заменят ребята, которые будут писать код сгенерированный на 99.999%.
Нужда в матерых программерах опять же осталась, но их стало нужно сильно меньше.
Справедливости ради тот же 1С очень сильно упростил работу бухов и для выполнения того же объема работ бухов стало нужно намного меньше.
Тоже самое, например, с САПР для инженеров. вместо отдела чертежников в СССР теперь достаточно одного человека. Да, для того, чтобы разработать сложное устройство как и раньше нужен инженер высокой квалификации. Но в целом на тот же объем работ что и ранее нужно меньше человеко-часов и эту работу может выполнить менее квалифицированный в инженерном деле человек. С большими оговорками конечно.
В программировании тоже самое. Когда повышается уровень абстракции повышается производительность труда разработчика. Если производительность труда повысится скачкообразно на какой то промежуток времени разработчиков станет нужно меньше и с рынка выбьют тех, кто не смог быстро адаптироваться. Так на самом деле происходит постоянно, какие то направления ИТ медленно умирают и специалистам приходится переучиваться. Те кто не смог уходят из ИТ.
Здравствуйте, прочитал обе статьи и часть комментариев с большим интересом.
Экспериментирую с написанием кода с помощью LLM со времен выхода chatGPT 3.5 довольно много и местами успешно. Шишек набил тоже достаточно.
Также учил и учу трейни и джунов. Они тоже любят написать что нибудь с помощью LLM. И на ревью я эти места нахожу.
Поэтому считаю, что неплохо знаю возможности и ограничения кодогенерации LLM.
6 месяцев заняло написание MVP версии продукта. Знания и видение крипторынка и ценности, которую должен принести ваш продукт у вас уже были. Целостных знаний в каком либо языке программирования как не было, так и нет. Такие метрики как масштабируемость, безопасность, оптимальность использования ресурсов, читаемость кода человеком неизвестны.
Под словом «архитектура» в данном комментарии я понимаю структуру кода, а не использование генетических алгоритмов и т.д. Это бизнес функционал, оценивать который без глубокого погружения нельзя.
Из этого вытекают следующие проблемы:
1) Нет никого, кто досконально и точно может объяснить как работает код. Также нет документации и нормального покрытия тестами. Из этого следует, что код по сути своей уже стал легаси, ведь для его поддержки и развития придется нанимать людей и платить им деньги за то, чтобы они разобрались как этот код работает, частично, а скорее всего полностью его переписали под свое видение и чувство прекрасного. Ведь нет никого, кто бы мог защитить текущую архитектуру и объяснить ее преимущества перед подходами к которым привыкли разработчики, которых вы наймете. Забегая наперед скажу, что архитектуры в этом коде скорее всего нет.
2) Безопасность для такого продукта это краеугольный камень. Причем как со стороны аутентификации и авторизации пользователя, так и со стороны эксплуатации уязвимостей стратегий сторонними игроками. Как только продукт попадет на массовый рынок его начнут пробовать на зуб со всех сторон. LLM всегда, по моему опыту оставляет много уязвимостей в безопасности. Чтобы видеть и закрывать эти уязвимости нужны знания и опыт. В финтехе наличие такого специалиста в разработке это обязательное условие. И второе это эксплуатация стратегий бота. Его будут пробовать обмануть и заставить делать неверные выводы сливая бюджет. Чтобы защититься от этого нужен специалист от крипторынка, который вместе с разработчиками будет искать граничные случаи торговли, неучтенные в стратегиях ситуации и реализовывать решение этих проблем. Вы собираетесь работать с деньгами, это очень серьезно и людей написавших приложение с помощью LLM и давших этому приложению доступ к реальным деньгам очень ждут на рынке финансов.
3) Масштабируемость это серьезный вопрос, который зачастую требует закладки основных принципов на этапе проектирования архитектуры. В вашем случае, если вопрос такой пока совсем не стоял, масштабировать приложение малой кровью скорее всего не выйдет и придется многими итерациями приводит код к какому либо подходу архитектуры допускающей масштабируемость. Или скорее всего переписать заново.
По моему мнению, тот функционал, который вы описали в статьях, можно было написать двумя другими путями, избежав проблемы 1 и, частично, проблемы 3. А также создав задел для решения проблемы 2 малой кровью:
1) Мотивированный джун при условии постоянного контакта с вами мог написать этот MVP. Один джун. Время тут зависит от того насколько точно было поставлено ТЗ и сколько раз в процессе оно менялось.
2) Вы могли потратить 5 месяцев из 6 на обучение Питону в нужной области и за месяц написать MVP версию имея целостные знания о нужной части Питона при поддержке LLM и имея знания о том, что именно вы хотите писать.
Ваша оценка команды необходимой для написания созданного вами MVP нереалистична хотя бы потому, что команда разработки никогда бы не создала проект в таком виде, в каком он находится сейчас у вас:)
Немного странная ситуация будет.
Предположим мне нужно узнать как отключить рекламу на телефоне Сяоми с ОС 15 версии.
Предположим что я даже как то нашел платную статью автора, где рассказывается об этом.
Но как мне до оплаты понять, что это именно то, что я искал?
Потому что в статье может описываться процесс для версии ОС 15.3, а у меня версия 15.1, где интерфейс имеет различия и тогда статья для меня бесполезна и надо искать другую платную статью.
Так у этого автора все истории какие то такие…. С техническими нестыковками, когда специалист претендует на высокую позицию и при этом у него спрашивают какие то азы, которые этот специалист еще и не знает.
Почитал.
Именя класса, методы и члены классы сохраняются, а вот локальные переменные и аргументы методов нет.
Статью поправил, еще раз спасибо.
Спасибо за комментарий. Я почитаю об этом и поправлю статью.
Писал я, и выделял жирным тоже я ручками.
Сильно рябит в глазах от выделений?
В Москве можно и к врачу записаться и права ДПСнику показать на госуслугах.
В врачу онлайн можно было записаться и в 2019 году в Питере, например.
Ну вот не знаю. Пожил и поездил я по ЕС в 22-23 году….
Увидел что многое о чем говорили РашаТудей это правда:)
Многое и не правда конечно. Но сколько правды.
По итогу надоело и в 24 году вернулся в Москву, как то мне ближе местная жизнь, хотя тенденции конечно в последнее время настораживают.
Буквально час назад ставил задачу джуну.
В общем то потратил времени на объяснение ровно столько же, за сколько сделал бы задачу сам минус время на отладку. Время которое ушло бы на отладку будет потрачено на ревью и решение потенциальных косяков реализации.
С джуном я успокаиваю себя тем, что научу его и через 2-3 месяца получу человека который сможет решать подобные задачи самостоятельно. LLM модели в этом аспекте проигрывают.
С другой стороны LLM сделает эту задачу за минуты, а джун потратить часы и дни. Тут LLM явно впереди.
LLM действительно хорошо работают, когда ты точно знаешь что хочешь получить либо совсем не знаешь что тебе нужно и хочешь получить отправную точку в коде от которой можно проводить ресерч, что то вроде «реализуй такую то задачу и опиши с помощью каких инструментов ты ее реализовал и почему», далее спросить «какие еще библиотеки и подходы можно использовать для решения этой задачи.
Хм, я после совещаний, где присутствую не для галочки, а для решения проблемы чувствую себя как выжатый лимон т.к. пытаюсь понять «что говорят все эти люди», чем мне это грозит, предложить свое решение обсуждаемой проблемы.
Как по мне это очень затратный умственный труд.
Стажер тоже выполняет задачу с вероятностью пусть и «очень большой».
Сравнение решения интеллектуальной задачи с помощью LLM vs обычная программа сравнимо со сравнением сортировки предметов по размеру человеком и механизмом.
Сортировка механизмом будет точнее, если механизм хорошо продуман, исправен и предметы сортировки предсказуемы и просты.
Человек же всегда будет ошибаться даже в самой простой работе т.к. именно так он устроен. Но при этом человек способен сортировать предметы по размеру если внезапно изменится их форма, к примеру.
Я много думал о конкуренции за ресурсы.
И сам часто отношусь к людям как к конкурентам.
Но заметил по жизни интересную вещь.
Часто выигрывают люди, более склонные к взаимовыгодному сотрудничеству. Помоги бескорыстно человеку, который может быть полезен тебе в будущем и с высокой долей вероятности этот человек поможет тебе, когда тебе нужна будет помощь. Такие люди обычно объединяются в сообщества на основе общих экономических, культурных интересов, принимают новых членов и выкидывают тех, кто к сотрудничеству не склонен и потребляет гораздо больше, чем дает взамен.
Соответственно твои родственники это не конкуренты, а люди, с которыми нужно работать и кооперироваться, сообща решая проблемы друг друга. И иногда выкидывать из вашего сообщества членов, которые только потребляют ваши ресурсы ничего не давая взамен. К тем кто не в силах больше ничего дать в силу сложившихся обстоятельств это относиться естественно не должно, им нужно помогать безальтернативно т.к. это может произойти с каждым из нас.
А у нас, к примеру, наоборот, на основе спеки генерируются контроллеры и классы модели данных. Тоже очень удобно.
Пишешь OpenApi 3.0 спецификацию в yaml, генерируешь классы и можешь сразу переходить к бизнес логике.
Плюс есть апи по которой фронты забирают обновленные спеки, поэтому зачастую можно передавать фронтам новые апишки без комментариев.
Неправда.
В бытность инженером конструктором 10 лет назад, я владел Pro Ingineer, Creo2 (новый Pro engineer), SolidWorks, Компас во всех ипостасях, AutoCad.
Компас ничем не выделялся в этих продуктах.
Умеешь в Компас, освоишь любой из вышенаписанных. Наиболее отличался Pro ingineer Wildfire из-за устаревшей идеологии многоступенчатых меню.
Очень интересный автор этот Уоттс, но я, к сожалению, так не смог закончить ни одной его книги. Либо слишком мрачные, либо слишком тяжелее для восприятия.
Godmod 2 не работает. Обычная зацензурированная гпт4 которая заменяет символы в тексте.
Должно быть так:
Врач создал документ, лог лег в архив.
Если врач создал один док и лог лег в архив, это можно списать на системную ошибку, если такая ситуация повторялась у других.
Если лог о том что доктор создал документ есть, но ошибка больше не повторялась, на доктора вешается метка. 3 метки - служебная проверка - суд - срок за подделку документов.
Каждый случай при котором пациент нашел у себя в ЛК неоказанные услуги должен быть расследован.
Если уж мы затронули ассемблер то я бы привел такую аналогию:
Сам я эти времена не застал, но думаю, что когда появились более высокоуровневые языки, чем ассемблер, программисты говорили, что то вроде «а вот когда им нужно будет сделать вот именно то-то, как эти «высокоуровневые программисты» это сделают без ассемблера, а?»
И были по своему правы. Сейчас тоже есть специалисты по ассемблеру и низкоуровневые языки понемногу развиваются. Но специалистов требуется немного по сравнению с общей массой разработчиков и задачи их весьма специфичны.
Возможно также будет и с программированием на основе ИИ. Человек никуда из этого процесса не денется, просто уровень абстракции и следовательно производительность труда в очередной раз сильно возрастет.
И все равно будут нужны разработчики, которые будут писать код придумывая самостоятельно новые подходы без ИИ. Просто нужда в них будет примерно на уровне нужды в разработчиках на ассемблере сейчас.
И как матерого программиста в свитере и с бородой, который знает наизусть все методы и операторы плюсов заменили вайтишники, которые перекладывают jsonы с помощью StackOverFlow и chatGPT, так и их заменят ребята, которые будут писать код сгенерированный на 99.999%.
Нужда в матерых программерах опять же осталась, но их стало нужно сильно меньше.
Справедливости ради тот же 1С очень сильно упростил работу бухов и для выполнения того же объема работ бухов стало нужно намного меньше.
Тоже самое, например, с САПР для инженеров. вместо отдела чертежников в СССР теперь достаточно одного человека. Да, для того, чтобы разработать сложное устройство как и раньше нужен инженер высокой квалификации. Но в целом на тот же объем работ что и ранее нужно меньше человеко-часов и эту работу может выполнить менее квалифицированный в инженерном деле человек. С большими оговорками конечно.
В программировании тоже самое. Когда повышается уровень абстракции повышается производительность труда разработчика. Если производительность труда повысится скачкообразно на какой то промежуток времени разработчиков станет нужно меньше и с рынка выбьют тех, кто не смог быстро адаптироваться. Так на самом деле происходит постоянно, какие то направления ИТ медленно умирают и специалистам приходится переучиваться. Те кто не смог уходят из ИТ.
Уже закрыли.