Ну так расскажите, как вы будете декомпозировать и проверять промежуточные значение получаемые при расчете себестоимости многопередельного производства? Что с чем сравнивать? Что выделять?
Вот более простой и наглядный пример: расскажите как вы декомпозируете вычисления чисел Фибоначчи и как будете проверять промежуточный результат.
Да, у Фибоначчи формула попроще, но принцип тот же самый.
Расскажите мне, как декомпозировать расчет себестоимости с учетом того, что любой промежуточный результат расчета себестоимости не имеет никакого смысла и не проверяем в принципе.
Человек не может отрастить сначала левую ногу, потом правую, потом руку… только все одновременно.
За ИИ взялись реальные люди, а не евангелисты. Они пишут реальные истории с реальными проблемами. И читать это полезнее и интереснее, чем маркетинговую хрень.
Разумно. Я обычно скармливают в режиме чата отдельные функции или небольшой кусок кода, что бы контролировать изменения.
А вот как обезопасить себя от нежелательного изменения кода в режима агента - не представляю. Даже на небольшом проекте, в режиме агента, изменения получались фатальные.
Смешной вы человек, право слово. Вы ничего не знаете обо мне, моих навыках, моих задачах. Вы ничего не знаете как работает бизнес. Вы ничего не знаете о приеме/увольнении. А пытаетесь выдавать какие-то суждения.
Ну во-первых, я именно тот человек к которому общаются когда хотят продать технологию или ПО в мою организацию. И если меня не убедят, что технология стоящая, бизнес даже разговаривать не станет с продажниками.
Во-вторых, бизнесу плевать на абстрактную эффективность. Ему нужна конкретика: как это снизит затраты, увеличит доходы или какие риски снимет. И в большинстве своем бизнес предпочтет стабильные проверенные решения, а не маркетинговый муссор.
В-третьих, нельзя уволить человека одним днем. Это и по закону возможно в крайне ограниченных случаях, и по процессу занимает банально больше времени. Рассчитать человека, проверить задолженность перед организацией, сдать или перевести на себя корпоративную симку, вернуть корпоративный ноутбук, передать дела, произвести все выплаты, оформить документы…
Ахренеть логика. Берем вполне себе устоявшийся общеупотребительный термин «задача» и подменяем его жаргонизмом из agile.
А почему не из математики? Или из DnD? Подобная подмена понятий настолько же правомерна. Терминология Agile не является ни общепризнанной, ни единственно возможной. Это просто сленг, который вне agile - ничего не значит.
Впрочем, в остальном ваши суждения столь же спорны и поверхностны.
Стратегическая цель бизнеса заработать больше денег. Занять большую долю рынка. Вытеснить конкурентов.
Один из способов решения этих задач (user story в терминах agile, раз уж иначе вы не понимаете) это контроль доходов и расходов.
А вот необходимый инструмент для контроля расходов и та самая task из agile, это как раз расчет себестоимости производства.
И хоть ты лопни, но разбить расчет себестоимости на более мелкие, но самоценные, блоки невозможно.
Ох уж эти теоретики. Все, заканчиваю спорить о вкусе устриц с теми кто их не ел.
У меня нет необходимости обсуждать решение моих задач. Я их решаю сам и довольно успешно. И не в теории, а на практике.
Все что было нужно мне - пример решения сложной задачи с помощью ИИ. Свои задачи я привел для примера сложности, а не обсуждения как их решать.
Нейроскептиком я не являюсь. Я просто очень хорошо представляю как работает эта технология и какие у нее ограничения.
Если человек успешно решал сложные задачи с помощью ИИ, он бы вполне мог бы это описать. Даже не углубляясь в детали. Общие нюансы, проблемы, ограничения, сильные стороны.
Собственно я схожий вопрос задаю на собеседовании программистам. Расскажите о своем сложном проекте и о том как вы его решали. И программисты рассказывают. А евангелисты ИИ не могут.
Но вы же могли просто написать: проблема в реализации ERP решения одним запросом в sql, а не строить абракадабру. Но тогда бы оказалось, что в самой проблеме и кроется решение.
Нет, про SQL был пример в другой ветке и про другую задачу.
Но ведь я не писал что правила должны быть прописаны в одном месте.
Ну мы возвращаемся к тому, что вы пытаетесь декомпозировать то, что в принципе не декомпозируется в силу сильной взаимосвязанности.
Только сдавал штук 5 экзаменов по этой теме, но сам не ногой, все уже порешено до нас.
Вот почему-то я был в этом уверен. Я сейчас читаю примечательную книжку "Программирование и конфликты" от Роберта Гласс. Очень перекликается с нашей беседой.
C точки зрения разработчика ПО эта фраза не имеет смысла, но все пробелы я вам не заполню.
В силу отсутствия у вас практического опыта, это будет бессмысленный разговор. Но если вы хорошо учились, то термины неделимость состояния, отсутствие чётких интерфейсов и нелокальный эффект изменений - подскажут вам, почему не все задачи можно декомпозировать.
Не надо изобретать терминологию. Она уже давно устоялась. И ни в одном определении Задачи нет привязки к трудоемкости.
Для меня задача, это та задача которую ставит бизнес. Подозреваю, что для кого-то "реализовать журналируемую файловую систему с нуля" тоже может быть задачей.
Далеко не все задачи подлежат декомпозиции. Нельзя декомпозировать слишком сложные или хаотичные задачи, где условия постоянно меняются, а связи между частями неочевидны и запутаны. Декомпозиция требует стабильности, а в таких задачах её нет. А это, буквально, большинство учетных задач.
Ну где же вы тут вводную увидели? Это краткое описание задачи. Считай - просто название. К ней еще файлик листов на 60 с описанием нюансов процесса и формулами должен прилагаться.
Собственно, с тем что ИИ умеет писать шаблонный код я и не спорил никогда. Но мне тут регулярно пытаются доказать, что ИИ может меня полностью заменить, я просто не умею им пользоваться.
Ну так я буквально с этого начал. Покажите мне пример промпта которые решает сложную комплексную задачу. Все что я вижу в примерах, это вопросы из книжки 33 задачи для начинающего программиста.
Вы сами, лично, хоть раз в жизни решали вопрос расчета многопередельной себестоимости производства? На реальном производстве? То что вы написали звучит приблизительно так: ну собрать машину легко. движок поставить на колеса, приделать руль, тормоза, не забыть сиденье, собрать все вместе с корпусом и можно ехать. Так-то оно так, но, как говориться, есть нюансы. Я вот очень хочу посмотреть на то, как вы это декомпозируете в реальном проекте.
Собственно, про декомпозицию вопрос не "зачем нужна декомпозиция", "а чем она поможет при постановке задачи ИИ". Это не та задача, которую можно собрать по частям. Это атомарная задача, которая выполняется для каждого изделия, полуфабриката и материала, рекурсивно обходя все, что используется в производстве.
Ну и меня конечно порадовало: сначала "надо делать декомпозицию", а потом "надо все требования прописать один раз в правилах проекта". Какая же это декомпозиция, когда все требования прописаны в одном месте?
Я слышу "Опус справится" но не вижу ни одного примера сложной задачи, с которой он бы справился.
Всю бухгалтерию?! Себестоимость многопередельного производства это одна задача из сотен.
Декомпозиция? А чем она тут поможет? Финальный вариант должен включать все требования которые были озвучены ранее. А что бы ИИ их не забыл и не потерял, их нужно повторять из раза в раз. И даже при этом, надо следить, что бы не было никакой самодеятельности.
Нет, разбить все на блоки, потом на функции и скармливать ИИ для написания отдельные функции, лучше всего чистые, это я могу. Правда потом, все это придется самому собирать в общий модуль. Потому что для ИИ эта задача окажется либо слишком сложной, либо слишком большой контекст потребуется.
Но я же читаю регулярно новости типа: "я топ менеджер, купил подписку на Claude, выгнал всех программистов и теперь поддерживаю крупный высоконагрузочный проект в одиночку". Я тоже так хочу.
Судя по вашему комментарию, все обсуждение выше вы не читали. Тогда с какой целью взялись комментировать?
Ну так расскажите, как вы будете декомпозировать и проверять промежуточные значение получаемые при расчете себестоимости многопередельного производства? Что с чем сравнивать? Что выделять?
Вот более простой и наглядный пример: расскажите как вы декомпозируете вычисления чисел Фибоначчи и как будете проверять промежуточный результат.
Да, у Фибоначчи формула попроще, но принцип тот же самый.
А как он в сеньеры выбился?
Что до дизайнеров, мне кажется, хорошие работы дизайнера стали только больше цениться, на волне ИИ слопа которым наполнился интернет.
Расскажите мне, как декомпозировать расчет себестоимости с учетом того, что любой промежуточный результат расчета себестоимости не имеет никакого смысла и не проверяем в принципе.
Человек не может отрастить сначала левую ногу, потом правую, потом руку… только все одновременно.
Тут та же ситуация.
Это не решает проблему нежелательного изменения кода. Это помогает аннулировать нежелательные изменения.
Разделение осознанное и оправданное.
Основные процессы хорошо отлажены и внедрены. Трогать их - себе дороже.
А как интерпретировать полученные результаты, это совсем другая история.
За ИИ взялись реальные люди, а не евангелисты. Они пишут реальные истории с реальными проблемами. И читать это полезнее и интереснее, чем маркетинговую хрень.
Разумно. Я обычно скармливают в режиме чата отдельные функции или небольшой кусок кода, что бы контролировать изменения.
А вот как обезопасить себя от нежелательного изменения кода в режима агента - не представляю. Даже на небольшом проекте, в режиме агента, изменения получались фатальные.
Смешной вы человек, право слово. Вы ничего не знаете обо мне, моих навыках, моих задачах. Вы ничего не знаете как работает бизнес. Вы ничего не знаете о приеме/увольнении. А пытаетесь выдавать какие-то суждения.
Ну во-первых, я именно тот человек к которому общаются когда хотят продать технологию или ПО в мою организацию. И если меня не убедят, что технология стоящая, бизнес даже разговаривать не станет с продажниками.
Во-вторых, бизнесу плевать на абстрактную эффективность. Ему нужна конкретика: как это снизит затраты, увеличит доходы или какие риски снимет. И в большинстве своем бизнес предпочтет стабильные проверенные решения, а не маркетинговый муссор.
В-третьих, нельзя уволить человека одним днем. Это и по закону возможно в крайне ограниченных случаях, и по процессу занимает банально больше времени. Рассчитать человека, проверить задолженность перед организацией, сдать или перевести на себя корпоративную симку, вернуть корпоративный ноутбук, передать дела, произвести все выплаты, оформить документы…
Ахренеть логика. Берем вполне себе устоявшийся общеупотребительный термин «задача» и подменяем его жаргонизмом из agile.
А почему не из математики? Или из DnD? Подобная подмена понятий настолько же правомерна. Терминология Agile не является ни общепризнанной, ни единственно возможной. Это просто сленг, который вне agile - ничего не значит.
Впрочем, в остальном ваши суждения столь же спорны и поверхностны.
Стратегическая цель бизнеса заработать больше денег. Занять большую долю рынка. Вытеснить конкурентов.
Один из способов решения этих задач (user story в терминах agile, раз уж иначе вы не понимаете) это контроль доходов и расходов.
А вот необходимый инструмент для контроля расходов и та самая task из agile, это как раз расчет себестоимости производства.
И хоть ты лопни, но разбить расчет себестоимости на более мелкие, но самоценные, блоки невозможно.
Ох уж эти теоретики. Все, заканчиваю спорить о вкусе устриц с теми кто их не ел.
У меня нет необходимости обсуждать решение моих задач. Я их решаю сам и довольно успешно. И не в теории, а на практике.
Все что было нужно мне - пример решения сложной задачи с помощью ИИ. Свои задачи я привел для примера сложности, а не обсуждения как их решать.
Нейроскептиком я не являюсь. Я просто очень хорошо представляю как работает эта технология и какие у нее ограничения.
Если человек успешно решал сложные задачи с помощью ИИ, он бы вполне мог бы это описать. Даже не углубляясь в детали. Общие нюансы, проблемы, ограничения, сильные стороны.
Собственно я схожий вопрос задаю на собеседовании программистам. Расскажите о своем сложном проекте и о том как вы его решали. И программисты рассказывают. А евангелисты ИИ не могут.
Бизнес логику от логики агрегации не отличаем?
Нет, про SQL был пример в другой ветке и про другую задачу.
Ну мы возвращаемся к тому, что вы пытаетесь декомпозировать то, что в принципе не декомпозируется в силу сильной взаимосвязанности.
Вот почему-то я был в этом уверен. Я сейчас читаю примечательную книжку "Программирование и конфликты" от Роберта Гласс. Очень перекликается с нашей беседой.
В силу отсутствия у вас практического опыта, это будет бессмысленный разговор. Но если вы хорошо учились, то термины неделимость состояния, отсутствие чётких интерфейсов и нелокальный эффект изменений - подскажут вам, почему не все задачи можно декомпозировать.
Не надо изобретать терминологию. Она уже давно устоялась. И ни в одном определении Задачи нет привязки к трудоемкости.
Для меня задача, это та задача которую ставит бизнес. Подозреваю, что для кого-то "реализовать журналируемую файловую систему с нуля" тоже может быть задачей.
Далеко не все задачи подлежат декомпозиции. Нельзя декомпозировать слишком сложные или хаотичные задачи, где условия постоянно меняются, а связи между частями неочевидны и запутаны. Декомпозиция требует стабильности, а в таких задачах её нет. А это, буквально, большинство учетных задач.
А почему вы думаете, что я этого не делал? Делал. И результат меня не удовлетворил.
Я за свою карьеру написал и прочитал множество технических проектов, заданий и просто фантазий пользователей.
Так вот, то что предлагает ИИ - это вода. Без конкретики. Без пользы.
Ну где же вы тут вводную увидели? Это краткое описание задачи. Считай - просто название. К ней еще файлик листов на 60 с описанием нюансов процесса и формулами должен прилагаться.
Собственно, с тем что ИИ умеет писать шаблонный код я и не спорил никогда. Но мне тут регулярно пытаются доказать, что ИИ может меня полностью заменить, я просто не умею им пользоваться.
Вот я и спрашиваю, а как правильно?
Ну так я буквально с этого начал. Покажите мне пример промпта которые решает сложную комплексную задачу. Все что я вижу в примерах, это вопросы из книжки 33 задачи для начинающего программиста.
Вы сами, лично, хоть раз в жизни решали вопрос расчета многопередельной себестоимости производства? На реальном производстве? То что вы написали звучит приблизительно так: ну собрать машину легко. движок поставить на колеса, приделать руль, тормоза, не забыть сиденье, собрать все вместе с корпусом и можно ехать. Так-то оно так, но, как говориться, есть нюансы. Я вот очень хочу посмотреть на то, как вы это декомпозируете в реальном проекте.
Собственно, про декомпозицию вопрос не "зачем нужна декомпозиция", "а чем она поможет при постановке задачи ИИ". Это не та задача, которую можно собрать по частям. Это атомарная задача, которая выполняется для каждого изделия, полуфабриката и материала, рекурсивно обходя все, что используется в производстве.
Ну и меня конечно порадовало: сначала "надо делать декомпозицию", а потом "надо все требования прописать один раз в правилах проекта". Какая же это декомпозиция, когда все требования прописаны в одном месте?
Я слышу "Опус справится" но не вижу ни одного примера сложной задачи, с которой он бы справился.
Это именно что задача. Одна из многих. Причем, даже не самая сложная.
Поищите описание любой ERP системы, что бы хотя бы представить уровень сложности. Десяток типовых модулей и до сотни специализированных.
Так вот себестоимость производства, это лишь четвертая часть одного из 10 типовых модулей.
Всю бухгалтерию?! Себестоимость многопередельного производства это одна задача из сотен.
Декомпозиция? А чем она тут поможет? Финальный вариант должен включать все требования которые были озвучены ранее. А что бы ИИ их не забыл и не потерял, их нужно повторять из раза в раз. И даже при этом, надо следить, что бы не было никакой самодеятельности.
Нет, разбить все на блоки, потом на функции и скармливать ИИ для написания отдельные функции, лучше всего чистые, это я могу. Правда потом, все это придется самому собирать в общий модуль. Потому что для ИИ эта задача окажется либо слишком сложной, либо слишком большой контекст потребуется.
Но я же читаю регулярно новости типа: "я топ менеджер, купил подписку на Claude, выгнал всех программистов и теперь поддерживаю крупный высоконагрузочный проект в одиночку". Я тоже так хочу.