Кстати, тезис про сеньора из соседней команды постепенно тоже уходит. Я постоянно добавляю документацию по проекту, память агента, скиллы и т.д. и вижу что мой агент при прочих равных каждый раз дает все более точные ответы в сравнении с предыдущими попытками. А также более точно ищет причины проблем по сравнению с тем же классом агентов других сотрудников, которые имеют доступ к репозиториям и стендам проекта, но не имеют тех же скиллов и памяти. Короче агенты постепенно нарабатывают экспертизу именно в моих проектах. Конечно не самостоятельно, а с помощью кожаного мешка:)
Как тимлид вижу генерированный код и вижу моменты, когда этот код написан без понимания вопроса «а что вообще тут происходит?»
Когда код написан хорошо, для меня нет разницы каким путем сотрудник этот код получил.
В случае же когда код сотрудник сгенерировал и не пропустил через себя, случается неприятная ситуация при которой я вижу ошибку, спрашиваю у человека почему написано именно так, а человек ответить на вопрос не может или говорит «ну Нейронка так написала, я переделаю».
Т.е. фактически человек является не владельцем своего кода, а передастом кода от нейронки ко мне на ревью.
У меня нет желания участвовать в такой схеме так как генерировать код я умею и сам:)
Поэтому тоже отсеивал бы людей, которые сгенерировали тестовое задание и не удосужились разобраться как оно там работает.
«Скучаю за тобой» - Всю жизнь так говорю, как и вся семья и старые друзья из родного города.
А еще «базар» вместо «рынок», «тремпель» вместо вешалка, «укрАинский» вместо «украИнский» и «заместо» вместо «вместо» ( не у всех)
Это Донбасс.
Согласно текущим литературным нормам русского языка это неправильно. В формальной речи стараюсь не употреблять, но «укрАинский» и «тремпель» само выскакивает, по другому не выходит.
А в повседневном общении эти различия просто вносят свой колорит в речь.
Ну и, конечно, у нас не «звонЯт, а звОнят»:)
Комментарий не пропагандирует южный диалект, а написан с целью пояснить за различия и показать, что люди могут применять такие выражения не из-за необразованности или неуважения к нормам русского языка, а потому что просто не замечают разницы или используют диалект в шутку для сочности языка.
Что в нем написано неизвестно. Откуда уверенность, что ИИ правильно интерпретирует метод, который был написан другим ИИ с совершенно другим контекстом?
Я на практике видел, что LLM зачастую пишет код используя неподходящие имена переменных и методов, не самый очевидный кодстайл и ситуативно вставляет методы в несоответствующие классы просто потому что не в курсе архитектуры проекта и не владеет всем контекстом.
Как с такими вводными может быть уверенность в правильном написании документации?
Это примерно как дать LLM писать тесты к коду написанному в LLM. Тесты будут проходить, и покрытие с n итерации будет на уровне, но будет ли покрыт функционал?
На вопрос «зачем?» отвечает имя класса, функции, метода, имена параметров и переменных внутри методов. Кчли вы используете комментарии для описания кода - нужно быть готовым к тому, что придет другой (или тот же?) разработчик, перепишет метод и забудет отредактировать комментарий. Что делать в таком случае?
LLM не отредактирует комментарий просто потому что его не было в данном ей контексте или ее об этом не попросили.
Здравствуйте, прочитал обе статьи и часть комментариев с большим интересом.
Экспериментирую с написанием кода с помощью 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 действительно хорошо работают, когда ты точно знаешь что хочешь получить либо совсем не знаешь что тебе нужно и хочешь получить отправную точку в коде от которой можно проводить ресерч, что то вроде «реализуй такую то задачу и опиши с помощью каких инструментов ты ее реализовал и почему», далее спросить «какие еще библиотеки и подходы можно использовать для решения этой задачи.
Кстати, тезис про сеньора из соседней команды постепенно тоже уходит.
Я постоянно добавляю документацию по проекту, память агента, скиллы и т.д. и вижу что мой агент при прочих равных каждый раз дает все более точные ответы в сравнении с предыдущими попытками.
А также более точно ищет причины проблем по сравнению с тем же классом агентов других сотрудников, которые имеют доступ к репозиториям и стендам проекта, но не имеют тех же скиллов и памяти.
Короче агенты постепенно нарабатывают экспертизу именно в моих проектах. Конечно не самостоятельно, а с помощью кожаного мешка:)
На Резке я битрейт не замерял, но картинка такая же как когда смотришь с торрента с битрейтом 30+ Mbit/c
Всем известный пиратский кинотеатр с премиум подпиской дает отличный 4k (иногда обманывает конечно).
Та же Дюна сериал или последний аватар смотрятся шикарно.
Также сейчас есть кинотеатры, которые торрентом тянут фильм и сразу показывают.
Все так, я лично видел как мир разработки потерял будущую звезду на этапе настройки переменных окружения для IDE.
Человек разочаровался в программировании и бросил.
Opus обычно так пишет.
Плюс в том, что ему тоже можно писать английские слова русскими буквами «как слышится» и модель понимает.
Можно и на Java core разгуляться:
https://gist.github.com/lolzballs/2152bc0f31ee0286b722
А можно и на EE:
https://github.com/Hello-World-EE/Java-Hello-World-Enterprise-Edition/tree/master/src/com/example
Я поддерживаю ваше мнение.
Как тимлид вижу генерированный код и вижу моменты, когда этот код написан без понимания вопроса «а что вообще тут происходит?»
Когда код написан хорошо, для меня нет разницы каким путем сотрудник этот код получил.
В случае же когда код сотрудник сгенерировал и не пропустил через себя, случается неприятная ситуация при которой я вижу ошибку, спрашиваю у человека почему написано именно так, а человек ответить на вопрос не может или говорит «ну Нейронка так написала, я переделаю».
Т.е. фактически человек является не владельцем своего кода, а передастом кода от нейронки ко мне на ревью.
У меня нет желания участвовать в такой схеме так как генерировать код я умею и сам:)
Поэтому тоже отсеивал бы людей, которые сгенерировали тестовое задание и не удосужились разобраться как оно там работает.
«Скучаю за тобой» - Всю жизнь так говорю, как и вся семья и старые друзья из родного города.
А еще «базар» вместо «рынок», «тремпель» вместо вешалка, «укрАинский» вместо «украИнский» и «заместо» вместо «вместо» ( не у всех)
Это Донбасс.
Согласно текущим литературным нормам русского языка это неправильно. В формальной речи стараюсь не употреблять, но «укрАинский» и «тремпель» само выскакивает, по другому не выходит.
А в повседневном общении эти различия просто вносят свой колорит в речь.
Ну и, конечно, у нас не «звонЯт, а звОнят»:)
Комментарий не пропагандирует южный диалект, а написан с целью пояснить за различия и показать, что люди могут применять такие выражения не из-за необразованности или неуважения к нормам русского языка, а потому что просто не замечают разницы или используют диалект в шутку для сочности языка.
Простите; а вы теоретик или практик?
У меня ощущение, что общаюсь с человеком, который сам код не пишет и кодогенерацией не пользуется.
Пусть LLM пишет код вместе с докой….
Пусть пишет конечно. Пусть весь проект пишет сразу правильно, вместе с докой и отличной архитектурой.
Потому что код никто не читал.
Что в нем написано неизвестно. Откуда уверенность, что ИИ правильно интерпретирует метод, который был написан другим ИИ с совершенно другим контекстом?
Я на практике видел, что LLM зачастую пишет код используя неподходящие имена переменных и методов, не самый очевидный кодстайл и ситуативно вставляет методы в несоответствующие классы просто потому что не в курсе архитектуры проекта и не владеет всем контекстом.
Как с такими вводными может быть уверенность в правильном написании документации?
Это примерно как дать LLM писать тесты к коду написанному в LLM. Тесты будут проходить, и покрытие с n итерации будет на уровне, но будет ли покрыт функционал?
На вопрос «зачем?» отвечает имя класса, функции, метода, имена параметров и переменных внутри методов. Кчли вы используете комментарии для описания кода - нужно быть готовым к тому, что придет другой (или тот же?) разработчик, перепишет метод и забудет отредактировать комментарий. Что делать в таком случае?
LLM не отредактирует комментарий просто потому что его не было в данном ей контексте или ее об этом не попросили.
А кто провалидирует соответствует ли документация коду?:)
Комменты к коду, по моему мнению, bad practice, так как код должен говорить сам за себя без пояснений.
Здравствуйте, прочитал обе статьи и часть комментариев с большим интересом.
Экспериментирую с написанием кода с помощью 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 действительно хорошо работают, когда ты точно знаешь что хочешь получить либо совсем не знаешь что тебе нужно и хочешь получить отправную точку в коде от которой можно проводить ресерч, что то вроде «реализуй такую то задачу и опиши с помощью каких инструментов ты ее реализовал и почему», далее спросить «какие еще библиотеки и подходы можно использовать для решения этой задачи.