Это рутина, зачем набирать код самому если это может делать LLM.
а в чем проблема с набором кода? это занимает меньше 1% времени от всего процесса разработки. мне это наоборот приятно, чувствуешь себя художником перед чистым холстом.
основное время занимает анализ требований, уточнение их и встраивание нового кода в существующую архитектуру.
LLM нужно конкретно писать что конкретно ей сделать так как будто это тупой джуниор только что пришедший на проект. Типо "добавь в файл abc класс Abc, в нем сделай методы которые делают то и то, затем используй этот класс там и там. И добавь юнит тест который проверит такой и такой кейсы."
вот именно что я не могу представить себе таску, которую я могу вот так описать. разработка - всегда постепенный процесс.
пример который Вы привели - это не уровень даже джуна, это секретарша, или кодогенератор. это нафиг не надо, это времени не занимает. основное время на большом проекте занимает внедрение фичи в существующую архитектуру, поиск зависимостей, рефакторинг существующего кода.
Затем заставляешь LLM найти причину бага, типо "фигани дофига принтов, запусти тесты и скажи - ты понял в чем бага или нет".
"фигануть дофига" это конечно хорошо, но как я уже писал в фиксе бага главное анализ истории изменений, а не сделать так чтобы он не проявлялся.
например если это креш изза доступа по null reference, недостаточно поставить проверку на null, я такой фикс обычно не пропускаю, надо понять почему раньше работало, а сейчас появился этот null.
работаю на большом проекте, которому уже под 20 лет. сотни тысяч строк кода, десятки тысяч закрытых воркайтемов, пофикшеных багов.
и вот хоть убей не представляю как на таком проекте можно использовать ИИ.
главное препятствие - для любого изменения нужно понимать архитектуру и код проекта, как это скормить ИИ?
разработка новой фичи - надо знать как заюзать существующий код, чтобы не изобретать велосипед и не копипастить.
фикс бага - нужно проанализировать историю изменений, понять какой фичей или другим багофиксом его создали, прочитать требования на то и другое, пофиксать так чтобы не сломать и старое и новое.
ИИ должен стать архитектором и техлидом на проекте, чтобы эффективно работать. пока же нейронки явно не готовы для этого.
не советовал бы брать какой-то один софт или сайт за эталон, особенно если он более менее современный. команды сейчас везде интернациональные, техписатели не везде есть. в результате в продукт попадает то как сами разработчики перевели.
говорю на своем примере - работаем на американскую компанию, русскояычные разрабы с уровнем инглиша B1-B2 (иногда ниже) иногда придумывают текст на UI, который потом довольно редко правится. но собственно это никого не волнует.
" Создатель, автор - reporter ", для Jira это можно так перевести, точнее перевести с натяжкой на русский, потому что жира - система в которую репортят issues. но вот про автора документа уже или картинки уже так не скажешь.
все идет к тому что программисты в нынешнем понимании исчезнут, станут экономически невыгодны, примерно как сейчас писать на ассемблере. вместо этого будут составители промптов. но как это будет работать для больших проектов пока не понятно. должны будут появиться ИИ-инструменты, специализированные под конкретный проект, чтобы выполнять еще функции архитектора, тех лида, способные сапортить этот конкретный проект.
утверждается, что холонавт для стороннего наблюдателя будет выглядеть навечно зависшим на горизонте событий.
т.е. если второй холонавт упадет по той же траектории, то он "зависнет" для наблюдателя в той же точке пространства, как бы слипнется с первым?
а теперь представим что ЧД активно поглощает вещество, ее горизонт должен расти. получится что через какое-то время мы будем видеть холонавта уже не на горизонте, а из под него?
недавно выбирал себе неттоп, так вот похоже N100 самый идеальный вариант. производительность на уровне i5 8го поколения, энергопотребление 6W впечатляет.
не сказать чтобы я что-то понял в этом объяснении, но если по-простому вы утверждаете что эксперимент по проверке Белла в точке Б даст одинаковый результат независимо от того что делалось с группой частиц А?
создать два набора запутанных друг с другом попарно частиц, один в точке А, другой в точке Б. количество должно быть достаточно для проверки неравенств Белла.
вызвать коллапс ВФ у частиц в точке А. Это должно вызвать коллапс ВФ частиц в точке Б.
сможет ли наблюдатель в точке Б узнать о факте коллапса в точке А с помощью установки для проверки неравенств Белла?
вопрос немного не по теме топика, но может кто-то из понимающих КМ ответит.
существуют экперименты, которые доказывают нарушение неравенств Белла.
а если в таком эксперименте использовать частицы, которые уже детектированы, т.е. после коллапса волновой функции, будут ли результаты экперимента отличаться?
а в чем проблема с набором кода? это занимает меньше 1% времени от всего процесса разработки. мне это наоборот приятно, чувствуешь себя художником перед чистым холстом.
основное время занимает анализ требований, уточнение их и встраивание нового кода в существующую архитектуру.
звучит красиво.
тут еще такой вопрос. ваша LLM работает локально или вы предоставляете доступ наружу для всего кода и документации проекта?
вот именно что я не могу представить себе таску, которую я могу вот так описать. разработка - всегда постепенный процесс.
пример который Вы привели - это не уровень даже джуна, это секретарша, или кодогенератор. это нафиг не надо, это времени не занимает. основное время на большом проекте занимает внедрение фичи в существующую архитектуру, поиск зависимостей, рефакторинг существующего кода.
"фигануть дофига" это конечно хорошо, но как я уже писал в фиксе бага главное анализ истории изменений, а не сделать так чтобы он не проявлялся.
например если это креш изза доступа по null reference, недостаточно поставить проверку на null, я такой фикс обычно не пропускаю, надо понять почему раньше работало, а сейчас появился этот null.
работаю на большом проекте, которому уже под 20 лет. сотни тысяч строк кода, десятки тысяч закрытых воркайтемов, пофикшеных багов.
и вот хоть убей не представляю как на таком проекте можно использовать ИИ.
главное препятствие - для любого изменения нужно понимать архитектуру и код проекта, как это скормить ИИ?
разработка новой фичи - надо знать как заюзать существующий код, чтобы не изобретать велосипед и не копипастить.
фикс бага - нужно проанализировать историю изменений, понять какой фичей или другим багофиксом его создали, прочитать требования на то и другое, пофиксать так чтобы не сломать и старое и новое.
ИИ должен стать архитектором и техлидом на проекте, чтобы эффективно работать. пока же нейронки явно не готовы для этого.
" Давайте просто сходим в Jira и проверим. "
не советовал бы брать какой-то один софт или сайт за эталон, особенно если он более менее современный. команды сейчас везде интернациональные, техписатели не везде есть. в результате в продукт попадает то как сами разработчики перевели.
говорю на своем примере - работаем на американскую компанию, русскояычные разрабы с уровнем инглиша B1-B2 (иногда ниже) иногда придумывают текст на UI, который потом довольно редко правится. но собственно это никого не волнует.
" Создатель, автор - reporter ", для Jira это можно так перевести, точнее перевести с натяжкой на русский, потому что жира - система в которую репортят issues. но вот про автора документа уже или картинки уже так не скажешь.
все идет к тому что программисты в нынешнем понимании исчезнут, станут экономически невыгодны, примерно как сейчас писать на ассемблере. вместо этого будут составители промптов. но как это будет работать для больших проектов пока не понятно. должны будут появиться ИИ-инструменты, специализированные под конкретный проект, чтобы выполнять еще функции архитектора, тех лида, способные сапортить этот конкретный проект.
спасибо за ответы, но все таки хочу еще уточнить.
допустим ЧД растет очень быстро, мы в это время периодически бросаем туда камни (людей жалко)).
что мы увидим, череду камней зависших в разных точках пространства, или брошенные раньше камни будут пропадать по мере расширения горизонта?
утверждается, что холонавт для стороннего наблюдателя будет выглядеть навечно зависшим на горизонте событий.
т.е. если второй холонавт упадет по той же траектории, то он "зависнет" для наблюдателя в той же точке пространства, как бы слипнется с первым?
а теперь представим что ЧД активно поглощает вещество, ее горизонт должен расти. получится что через какое-то время мы будем видеть холонавта уже не на горизонте, а из под него?
а что скажете про процы Intel N100 (N95)?
недавно выбирал себе неттоп, так вот похоже N100 самый идеальный вариант. производительность на уровне i5 8го поколения, энергопотребление 6W впечатляет.
не сказать чтобы я что-то понял в этом объяснении, но если по-простому вы утверждаете что эксперимент по проверке Белла в точке Б даст одинаковый результат независимо от того что делалось с группой частиц А?
возможно глупость говорю, но идея такая.
создать два набора запутанных друг с другом попарно частиц, один в точке А, другой в точке Б. количество должно быть достаточно для проверки неравенств Белла.
вызвать коллапс ВФ у частиц в точке А. Это должно вызвать коллапс ВФ частиц в точке Б.
сможет ли наблюдатель в точке Б узнать о факте коллапса в точке А с помощью установки для проверки неравенств Белла?
вопрос немного не по теме топика, но может кто-то из понимающих КМ ответит.
существуют экперименты, которые доказывают нарушение неравенств Белла.
а если в таком эксперименте использовать частицы, которые уже детектированы, т.е. после коллапса волновой функции, будут ли результаты экперимента отличаться?