Ну и в целом, для большинства проблем что бы проверить решение не нужно заранее знать правильный ответ. Достаточно проверить, что цепочка размышление логически не противоречива, а цепочка вычислений просчитана правильно.
Я не стал разворачивать именно это направление, но фраза «Достаточно, чтобы вся система производила полезный результат дешевле, чем альтернативный способ его получить.» - именно об этом. 100% точности никогда не будет, я не уверен что будет 50%, но даже они расширят спектр задач и решаемых проблем.
Вот тезис «код больше не узкое место» здесь, пожалуй, ключевой.
Если разработка ускорилась в несколько раз, а планирование, ревью и приемка остались прежними, дополнительная скорость кода сама по себе не становится скоростью выпуска, а быстрее переносит работу к следующему ограничению процесса.
Хороший критерий здесь - меняется ли вместе с передачей работы ответственность за результат.
Заказчику в общем случае не должно быть важно, сколько подрядчиков стоит внутри цепочки. Но кто-то один все равно должен отвечать перед ним за срок, качество и Definition of Done целиком.
Проблема начинается, когда работу передали дальше, а ответственность в процессе передачи как-то потерялась.
Тут как раз хорошо видно, почему критическое правило нельзя оставлять только на уровне понимания исполнителя.
Модель правильно определила, что домашний каталог удалять нельзя. А потом все равно его удалила из-за ошибки в реализации.
Если цена действия высока и оно не должно происходить вообще, надежнее отобрать возможность его совершить, чем объяснять исполнителю, почему этого делать не надо.
Это в целом же можно решить - попросив модель, например, составить SWOT-анализ идеи и она вполне непредвзято его сделает? С ИИ - это самая большая проблема - он делает ровно то, что попросишь, а не то, что подразумеваешь.
ИИ действительно может забрать у РП отчеты, протоколы, сбор статусов и значительную часть планирования.
Но это скорее хорошо показывает, что все перечисленное само по себе не является управлением проектом. РП нужен для того, чтобы несколько функций с разными задачами, ресурсами и приоритетами выдали общий результат в заданный срок.
Пока ИИ не получил полномочия распределять между ними ресурсы и разрешать конфликты, профессию он не заменил.
Пожалуй, поэтому обещание «разработчики стали в два раза быстрее» само по себе мало что значит.
Пользователь получает результат не от разработчика, а от всей цепочки. И если ускорили только один ее участок, экономический эффект может оказаться намного скромнее технического.
Мне кажется, главный вопрос здесь вообще не про агентов, а о том кто отвечает за результат целиком.
Можно очень хорошо автоматизировать каждый отдельный шаг, но если между ними никто не отвечает за передачу работы и последствия ошибки, автоматизация просто делает эту проблему быстрее.
У моего харнесса правило - в случае блокера или ошибки модели - сначала проведи полный RCCA, обнови промпт и перезапусти задание. Если задача прошла и если ошибка статическая - обнови скрипты проверки задания, если динамическая - шаблон промпта.
Для этого во всей цепочке и нужен человек. :-)
Ну и в целом, для большинства проблем что бы проверить решение не нужно заранее знать правильный ответ. Достаточно проверить, что цепочка размышление логически не противоречива, а цепочка вычислений просчитана правильно.
Я не стал разворачивать именно это направление, но фраза «Достаточно, чтобы вся система производила полезный результат дешевле, чем альтернативный способ его получить.» - именно об этом. 100% точности никогда не будет, я не уверен что будет 50%, но даже они расширят спектр задач и решаемых проблем.
В этом и есть один из смыслов заметки. :-) сила ИИ - в концентрации.
Это уже не имеет значения. :-)
Я думаю, что вам имеет смысл перечитать заметку, вы не поняли что я имел в виду. :-)
Вот тезис «код больше не узкое место» здесь, пожалуй, ключевой.
Если разработка ускорилась в несколько раз, а планирование, ревью и приемка остались прежними, дополнительная скорость кода сама по себе не становится скоростью выпуска, а быстрее переносит работу к следующему ограничению процесса.
Хороший критерий здесь - меняется ли вместе с передачей работы ответственность за результат.
Заказчику в общем случае не должно быть важно, сколько подрядчиков стоит внутри цепочки. Но кто-то один все равно должен отвечать перед ним за срок, качество и Definition of Done целиком.
Проблема начинается, когда работу передали дальше, а ответственность в процессе передачи как-то потерялась.
Мне кажется, тут важнее даже не дофамин, а почти исчезнувшая стоимость следующей итерации.
Раньше между «интересно» и «попробую еще вот это» стояло несколько часов работы. Теперь следующая попытка стоит несколько минут.
В результате ограничением становится уже не способность что-то сделать, а способность выбрать, что вообще стоит делать и когда остановиться.
Тут как раз хорошо видно, почему критическое правило нельзя оставлять только на уровне понимания исполнителя.
Модель правильно определила, что домашний каталог удалять нельзя. А потом все равно его удалила из-за ошибки в реализации.
Если цена действия высока и оно не должно происходить вообще, надежнее отобрать возможность его совершить, чем объяснять исполнителю, почему этого делать не надо.
Там сама корпоративная ИИ-шка упала и все, без нее все встало.
Для меня ничего, но общественность жалуется .:-)
Это в целом же можно решить - попросив модель, например, составить SWOT-анализ идеи и она вполне непредвзято его сделает?
С ИИ - это самая большая проблема - он делает ровно то, что попросишь, а не то, что подразумеваешь.
С попыткой заменить человека функцией есть одна проблема: функция хорошо описывает штатную работу.
А ценность хорошего специалиста часто становится видна именно тогда, когда штатная ситуация закончилась и инструкции больше не дают готового ответа.
Я ровно об этом и говорю. Если процесс не изменился, а изменилась только система, то смысла нет.
ИИ действительно может забрать у РП отчеты, протоколы, сбор статусов и значительную часть планирования.
Но это скорее хорошо показывает, что все перечисленное само по себе не является управлением проектом. РП нужен для того, чтобы несколько функций с разными задачами, ресурсами и приоритетами выдали общий результат в заданный срок.
Пока ИИ не получил полномочия распределять между ними ресурсы и разрешать конфликты, профессию он не заменил.
Пожалуй, поэтому обещание «разработчики стали в два раза быстрее» само по себе мало что значит.
Пользователь получает результат не от разработчика, а от всей цепочки. И если ускорили только один ее участок, экономический эффект может оказаться намного скромнее технического.
Мне кажется, главный вопрос здесь вообще не про агентов, а о том кто отвечает за результат целиком.
Можно очень хорошо автоматизировать каждый отдельный шаг, но если между ними никто не отвечает за передачу работы и последствия ошибки, автоматизация просто делает эту проблему быстрее.
Если подрядчику платят за переход с УПП на ERP, довольно смело ожидать, что он сам остановится и спросит, нужен ли вам вообще этот переход.
Он зарабатывает на проекте. Проверять, нужен ли бизнесу проект, все-таки обязан кто-то со стороны бизнеса.
Критерий приемки любой автоматизации очень простой: что после нее перестало требовать человеческого времени или решения.
Если ответ «ничего, просто теперь это делается в новой системе», то экономический эффект и смысл автоматизации имеет смысл поискать еще раз.
У моего харнесса правило - в случае блокера или ошибки модели - сначала проведи полный RCCA, обнови промпт и перезапусти задание. Если задача прошла и если ошибка статическая - обнови скрипты проверки задания, если динамическая - шаблон промпта.