Comments 81
Я вот читаю посты евангелистов от ИИ и у меня к ним только один вопрос: покажите запрос к ИИ по нестандартной и сложной задаче. Даже не результат запроса, а с₽ запрос.
В моих рабочих задачах описание какого-то блока может занимать несколько десятков страниц. На обычном языке, с учетом всех нюансов. А смотря на экивоки в запросах к ИИ, понимая что нужно будет учитывать еще и закидоны ИИ, вопросы безопасности и даже указание ничего не удалять…. Я понимаю, что я быстрее решу такую задачу сам, чем составлю запрос к ИИ. Да и примет ли такой большой запрос ИИ - тоже вопрос.
Не евангелист, но пользуюсь, разбиваю задачу на простые модули. ИИ пишет мне по одному модулю за раз, обычно не более 100-1000 строчек
Ну так я и пишу про требования к одному модулю. Который в принципе не разделяется на подзадачи.
Что, у вас там в этом модуле прям вся логика в одной функции? Если нет и разбито на разные классы/методы, то значит прекрасно разделяется на подзадачи. :)
Это sql запрос который формирует данные для финансового отчета по группе компаний.
Учет ведется в одной системе. Одними и теми же документами. Но у каждой организации свои нюансы учета. Плюс есть нюансы отнесения затрат как на прямые или на косвенные, в зависимости от организации проекта и статьи затрат.
А одним запрос это надо сделать потому, что данные потом выгружаются в Power BI.
И это только малая часть условий которые нужно учесть.
Не думаю, что кодинг тулзы подходящее место для разработки SQL запросов, всегда их ручками делал, наверняка есть тулзы для клод кода по работе с базой, но я никогда ими не пользовался и не знаю в каком они состоянии.
Однако если теоритизировать, ты вы сами как его будете делать, прям сразу весь функционал напишете от первой буквы и до конца логики ни разу не запуская? Или по кусочкам: сделали одно, проверили, что он вернул правильные данные, добавили еще логики, опять проверили и т.д.? Если второе, то опять-же, разбивается логика.
Вся сложность не в том, что бы написать огромный запрос SQL за один запрос к ИИ. Тут сложность в том, что бы не потерять уже реализованные нюансы, когда будешь добавлять новые.
куча временных таблиц, для корректной работы с курсами и переменными коэффициентами, 17 запросов по 200 строк в union, а к ним еще две таблицы в одной из которых итоги из объединения в разбивке по проектам...
И в каждом запросе львиную долю занимают условия.
Я, как-то, интереса ради, отдал на растерзание ИИ один запрос. Не из этого отчета, но тоже с мудреной логикой. Один запрос, строк на 150. Пара временных таблиц... И уже на первом вопросе запрос был безнадежно сломан.
Но, справедливости ради, если в запросе нужно реализовать только одну мудреную вещь, ИИ с этим боле-менее справляется.
Попробуйте, ради эксперимента, дать Клоду самому запланировать решение задачи(написать ТЗ самому себе), и потом сравните с тем, как просили решить задачу вы. Увидите много интересного после нескольких итераций.
Есть ощущение, что это засовывание бизнес логики в запросы (надеюсь хоть не в хранимые процедуры), которая возможно была бы лучше в своем слое.
Возможно, это мой личный опыт. Но для себя лимит поставил в 500 строк кода. Потому что дальше, частенько, LLM начинает ломать то, что работает отлично вместо того чтобы починить то что не работает.
Разумно. Я обычно скармливают в режиме чата отдельные функции или небольшой кусок кода, что бы контролировать изменения.
А вот как обезопасить себя от нежелательного изменения кода в режима агента - не представляю. Даже на небольшом проекте, в режиме агента, изменения получались фатальные.
А вот как обезопасить себя от нежелательного изменения кода в режима агента - не представляю.
Есть такие штуки: системы управления версиями называются. Например, git. :)
Это не решает проблему нежелательного изменения кода. Это помогает аннулировать нежелательные изменения.
Если давать небольшие конкретные задачи, никакого нежелательного изменения кода не будет, вообще ни разу не сталкивался.
Если задача больше, поставлена некорректно когда полно всякой двусмысленности, то да, может делать не то, что вы имели ввиду, учитесь выражать свои мысли яснее, так, чтоб вас понимали и не было двусмысленности. В любом случае, перед выполнением задачи вам будет выдан план выполнения работ. Просто проверьте его, если модель вас не поняла и задизайнила что-то другое, это сразу будет видно из плана.
Большие задачи я напрямую не даю, всегда разбиваю на подзадачи.
У меня какая история была:
Я даю доступ к файлам проекта в режиме агент. Прошу исправить что-то в одном файле. Небольшое локальное исправление. Агент начинает пыхтеть, читать файлы, говорит что все сделано... и я вижу что изменения внесены даже в те файлы которые не надо было править.
Полез смотреть код, он мне его так отрефакторил что во-первых, он не работает, во-вторых, даже если бы работал дела бы не то, что нужно.
На этот моменте, режим агента мне как-то разонравился. Вернулся в чат. Там я хотя бы заранее понимаю, что поменялось в коде.
Мне вот тоже интересно. Клод невероятен, если работает поверх очень качественных моделей связанных моделей. Он таким образом круто умеет понимать все и вся. Но модели такого уровня да еще влезающие в контекст это большая редкость по ряду причин. И тут Клод начинает строить теории, если раньше чаще спрашивал то сейчас я по 5 дней его останавливаю принудительно (и по той же причине режим кода не использую). Причем вылечить его удается редко, он в 70% случаев игнорирует команды не строить теории в отстутствии информации. Я как то порядка получаса в качестве эксперимента смотрел на вереницу его наивных теорий там, где реальной работы было 3 минуты.
Для себя я вывел такую аналогию. Современные LLM подобны бытовому 3d принтеру. Отлично подходит для быстрого прототипирования и изготовления простых бытовых вещей для личного пользования. Некоторые делают на нем простенький микробизнес. Для производства не подходит. Литейщикам по пластику боятся нечего)
Т.е. правильно понимая суть инструмента - можно пользоваться им с удовольствием. Например, собираю я устройство, тут мне LLM не большой помощник в программировании, потому что чуть в сторону от известных паттернов и начинаются велосипеды из костылей. А вот попросить его написать вебморду для этого устройства - это уже вполне посильная для LLM задача. Более того, она напишет ее даже лучше чем я ее бы написал (вэб это прям вообще не моё). Ну и тесты LLM пишет тоже вполне ок. И опять же, это не в прод, а для личного использования/прототипирования. Если в прод - тут уже кожаные пишут код от и до.
Вот и у меня схожие ощущения. Если дать ему локальную задачу (обычно в пределах функции или метода), результат - добротный. Иногда даже предлагает неочевидные и толковые варианты. А, если ИИ и сглупил, это легко найти и исправить.
Но при написании большого модуля он начинает чудить. Становится проще написать все самому, чем раз за разом его проверять и исправлять.
По этому и интересно посмотреть на рабочий пример подобного запроса)
Вот у меня тоже вопросы к моделям, которые находят в ошибки в кодовой базе. Это как они столько контекста хранят и не ломаются? Тут большой файл в чат закидываешь - он уже куча токенов сжирает
На сколько понимаю, весь код индексируется. А дальше идет работа в пределах ограниченного окна. Но в это окно будет подгружаться код который ссылается на проверяемую переменную или функцию.
Есть у меня легаси проектик, около-CAD на C++, порядка 10 тысяч файлов (немаленьких по большей части, многие в пару тысяч строк или больше, есть и по 20К строк), LOC считать лень. Сказал Копайлоту с ним разобраться, чтоб он мог баги править и фичи дописывать. Он подумал минут 10, и выдал описание (оно же база знаний и поисковый индекс), 15 .MD файлов на 50КБ в общей сложности. Мне показалось, это мало как-то, спрашиваю - что, теперь можешь баги править? Он говорит, давай описание. Скормил ему по очереди 3 тикета из Jira, не очень сложных. Он с ними разделался минут за 5-10 на тикет. Фиксы выглядят вполне разумно. С более сложными, конешно, дело сложнее обстоит - не всегда попадает в точку, да и с первой итерации не всегда получается (да и с 10-й тоже не всегда, честно говоря). Но процесс идет, баги правятся, новый код и тесты пишутся, база знаний растет, я сам ее читаю и нахожу для себя полезное. Типичный процесс работы с багой - он итеративно грепает нужное, читает некоторые файлы (часто кусками, как определяет, что именно читать - не знаю), потом правит код, перестраивает, гоняет тесты, если покраснели - читает логи, правит ошибки, и так пока все не сойдется. Проверять все надо досконально, иногда переписывать куски (самому, или его же заставить), но в целом, экономит кучу времени на рутину. К тому же, сгенерировал он мне пару оч полезных тулов, например, напитонил визуализатор геометрии из логов. Мои 2 цента...
покажите евангелисту нестандартную и сложную задачу
Учет затрат в группе компаний при многопередельном производстве. С учетом требований законодательства тех стран на территории которых работает группа компаний.
С учетом валют, актуальных курсов, курсовых разниц, налогов… ну там реально не один лист требований и формул.
вы хотите всю бухгалтерию одним промптом прикончить? чет не выглядит как задача, выглядит как тз для интерпрайза. нет, если у вас на каждом этапе 3-4 детали, то это Эксель табличка с проверкой на коэффициенты, но если вас интересует фул интерпрайз, то ллм за один промпт такое пока не пишет, декомпозируйте
Всю бухгалтерию?! Себестоимость многопередельного производства это одна задача из сотен.
Декомпозиция? А чем она тут поможет? Финальный вариант должен включать все требования которые были озвучены ранее. А что бы ИИ их не забыл и не потерял, их нужно повторять из раза в раз. И даже при этом, надо следить, что бы не было никакой самодеятельности.
Нет, разбить все на блоки, потом на функции и скармливать ИИ для написания отдельные функции, лучше всего чистые, это я могу. Правда потом, все это придется самому собирать в общий модуль. Потому что для ИИ эта задача окажется либо слишком сложной, либо слишком большой контекст потребуется.
Но я же читаю регулярно новости типа: "я топ менеджер, купил подписку на Claude, выгнал всех программистов и теперь поддерживаю крупный высоконагрузочный проект в одиночку". Я тоже так хочу.
разбить все на блоки, потом на функции и скармливать ИИ для написания отдельные функции, лучше всего чистые, это я могу.
Ну так да. И модель это может, можете ей назначить сперва этот этап декомпозиции.
А что бы ИИ их не забыл и не потерял, их нужно повторять из раза в раз
Пропишите один раз в правилах проекта, и лучше сразу накройте бескомпромиссными тестами на предварительных данных
Правда потом, все это придется самому собирать в общий модуль.
Не вижу о какой общем модуле идет речь. Экономика отдельно, логистика отдельно, производство отдельно, по любому запросу собирается в результирующую таблицу по текущим данным, все что вам нужно - валидировать коэффиценты исходя из внешних данных меняющегося законодательства.
Мы все ещё про разработку ПО или про то что волшебный агент по волшебному промпту должен рассчитать все и сходу? У топ менеджера, который всех выгнал все эти задачи были уже декомпозированы, поэтому переназначение этих этапов на модель не является сложностью. А у вас первая реакция на декомпозцию - "зачем?" Я тут не знаю как ответить. Ну не декомпозируйте, подождите пару лет, там новые модели справятся и с вашей задачей сходу. Хотя и сейчас опус справится, тут скорее вопрос валидации встанет.
Ну так я буквально с этого начал. Покажите мне пример промпта которые решает сложную комплексную задачу. Все что я вижу в примерах, это вопросы из книжки 33 задачи для начинающего программиста.
Вы сами, лично, хоть раз в жизни решали вопрос расчета многопередельной себестоимости производства? На реальном производстве? То что вы написали звучит приблизительно так: ну собрать машину легко. движок поставить на колеса, приделать руль, тормоза, не забыть сиденье, собрать все вместе с корпусом и можно ехать. Так-то оно так, но, как говориться, есть нюансы. Я вот очень хочу посмотреть на то, как вы это декомпозируете в реальном проекте.
Собственно, про декомпозицию вопрос не "зачем нужна декомпозиция", "а чем она поможет при постановке задачи ИИ". Это не та задача, которую можно собрать по частям. Это атомарная задача, которая выполняется для каждого изделия, полуфабриката и материала, рекурсивно обходя все, что используется в производстве.
Ну и меня конечно порадовало: сначала "надо делать декомпозицию", а потом "надо все требования прописать один раз в правилах проекта". Какая же это декомпозиция, когда все требования прописаны в одном месте?
Я слышу "Опус справится" но не вижу ни одного примера сложной задачи, с которой он бы справился.
Но вы же могли просто написать: проблема в реализации ERP решения одним запросом в sql, а не строить абракадабру. Но тогда бы оказалось, что в самой проблеме и кроется решение.
Задачка то стандартная, хоть и сложная, но вся её сложность кроется в валидации промежуточных данных
"надо все требования прописать один раз в правилах проекта". Какая же это декомпозиция, когда все требования прописаны в одном месте?
Но ведь я не писал что правила должны быть прописаны в одном месте.
Вы сами, лично, хоть раз в жизни решали вопрос расчета многопередельной себестоимости производства?
Только сдавал штук 5 экзаменов по этой теме, но сам не ногой, все уже порешено до нас.
Это не та задача, которую можно собрать по частям.
C точки зрения разработчика ПО эта фраза не имеет смысла, но все пробелы я вам не заполню.
Но вы же могли просто написать: проблема в реализации ERP решения одним запросом в sql, а не строить абракадабру. Но тогда бы оказалось, что в самой проблеме и кроется решение.
Нет, про SQL был пример в другой ветке и про другую задачу.
Но ведь я не писал что правила должны быть прописаны в одном месте.
Ну мы возвращаемся к тому, что вы пытаетесь декомпозировать то, что в принципе не декомпозируется в силу сильной взаимосвязанности.
Только сдавал штук 5 экзаменов по этой теме, но сам не ногой, все уже порешено до нас.
Вот почему-то я был в этом уверен. Я сейчас читаю примечательную книжку "Программирование и конфликты" от Роберта Гласс. Очень перекликается с нашей беседой.
C точки зрения разработчика ПО эта фраза не имеет смысла, но все пробелы я вам не заполню.
В силу отсутствия у вас практического опыта, это будет бессмысленный разговор. Но если вы хорошо учились, то термины неделимость состояния, отсутствие чётких интерфейсов и нелокальный эффект изменений - подскажут вам, почему не все задачи можно декомпозировать.
очень бы хотелось все таки обсудить проблему, но вы зачем то обсуждаете свое видение невозможности декомпозиции исходя из вам только известных критериев. И предлагаете воскресную угадайку.
Угадайка не интересна, проблема у вас типичная, но если вам просто хочется отстаивать позицию нейроскептиков - можете считать что вам это удалось.
У меня нет необходимости обсуждать решение моих задач. Я их решаю сам и довольно успешно. И не в теории, а на практике.
Все что было нужно мне - пример решения сложной задачи с помощью ИИ. Свои задачи я привел для примера сложности, а не обсуждения как их решать.
Нейроскептиком я не являюсь. Я просто очень хорошо представляю как работает эта технология и какие у нее ограничения.
Если человек успешно решал сложные задачи с помощью ИИ, он бы вполне мог бы это описать. Даже не углубляясь в детали. Общие нюансы, проблемы, ограничения, сильные стороны.
Собственно я схожий вопрос задаю на собеседовании программистам. Расскажите о своем сложном проекте и о том как вы его решали. И программисты рассказывают. А евангелисты ИИ не могут.
Вам же уже сказали - декомпозиция, разделение на подзадачи, отдельная их реализация. Конечно, не в одном трех-этажном SQL запросе. Все как обычно.
Расскажите мне, как декомпозировать расчет себестоимости с учетом того, что любой промежуточный результат расчета себестоимости не имеет никакого смысла и не проверяем в принципе.
Человек не может отрастить сначала левую ногу, потом правую, потом руку… только все одновременно.
Тут та же ситуация.
Расскажите мне, как декомпозировать расчет себестоимости с учетом того, что любой промежуточный результат расчета себестоимости не имеет никакого смысла и не проверяем в принципе.
Как они могут быть непроверяемые, у вас там квантовые эффекты и фаза Луны в процессе расчётов начинают работать?
Себестоимость формируется из составных частей и никто не знает, какие они - звучит как бред, уж извините. Как тогда ТЗ писали? Если там "не один лист требований и формул", они ж не сплошным одним предложением идут?
Вот вы там пишете:
Учет затрат в группе компаний при многопередельном производстве. С учетом требований законодательства тех стран на территории которых работает группа компаний.
Ни одна компания из группы не знает свои расходы при производстве? Они не делят свои расходы по источнику затрат? Расходы на туалетную бумагу неразличимы от расходов на закупку металлопроката?
Тут сходу можно придумать кучу точек декомпозиции - по отдельным предприятиям, по производственным цепочкам, по странам, по назначению расходов, по переделам и т.п.
Ну так расскажите, как вы будете декомпозировать и проверять промежуточные значение получаемые при расчете себестоимости многопередельного производства? Что с чем сравнивать? Что выделять?
Вот более простой и наглядный пример: расскажите как вы декомпозируете вычисления чисел Фибоначчи и как будете проверять промежуточный результат.
Да, у Фибоначчи формула попроще, но принцип тот же самый.
И в чем проблема-то? Себестоимость состоит из материальных и нематериальных затрат. Хоба, я уже разделил неразделяемое по вашему мнению.
Материальные затраты могут быть как закупочные материалы, так и наша же собственная продукция. В первом случае учитывается закупочная цена, во втором себестоимость. Хоба, одну часть еще на две части разделили.
Что для тех метериалов, что для продукции у нас будут разные парти с разными закупочными ценами и разной себестоимостью. В производство могут уйти совершенно разные партии, но нам для рассчета себестоимости это совершенно по барабану, мы применяем либо ФИФО, либо ЛИФО, уточняете у бухгалтеров, что именно, я уже не помню.
Партионный учет тоже легко бьется на подзадачи, каждая их которых детерминирована и дает проверяемый результат.
Далее что там у нас, нематериальные затраты. Это ФОТ, рассчет которого отдельная большая тема с миллионом подзадач, всякие лицензии, сертификаты, амортизация оборудования. Вот уже три подзадачи. Налоги тоже идут туда? Уже не помню, лет 15 не занимался себестоимостью.
Вся себестоимость разбивается на мелкие проверяемые подзадачи. Если вы брякнете главбуху, что нельзя проверить из чего состоит себестоимость, он вас ссаными тряпками с проекта выгонит.
И да, фибоначчи это тупо один цикл с аккумулятором, но даже он бьется легко на отдельные инструкции.
Предложенный вариант описывает расчет себестоимости слишком упрощенно. Я же не случайно каждый раз уточняю, что речь идет о многопередельном производстве.
Смотрите: Есть номенклатурна, для которой требуется рассчитать себестоимость. Существует процедура costCalculation, куда мы передаем эту номенклатуру в качестве параметра.
Она (номенклатура) может быть либо покупной, либо изделием. С покупной всё достаточно прозрачно: берем цену закупки и на этом останавливаемся. Если же у нас изделие, мы лезем в его состав считаем себестоимость входящих компонентов. И себестоимость компонент считаем той же costCalculation. Что в такой логике, можно декомпозировать?
Однако это еще не полная себестоимость. На каждом этапе, а они у нас имеют вид дерева, для каждого изделия необходимо учесть множество дополнительных факторов:
попутный выпуск, когда в рамках одного передела получаются изделия для разных проектов;
брак и возвратные отходы, причем на разных итерациях одного и того же производства они могут различаться;
расходные материалы, которые не входят напрямую в состав изделия, но тратятся в процессе его изготовления;
и прочие подобные нюансы — список может быть весьма широким.
И на первый взгляд кажется, что все это можно выделить и считать отдельно… но на практике это не работает. Формально, конечно, можно вынести разные части кода в отдельные процедуры. Однако значимый, осмысленный результат можно будет получить только в контексте всего сквозного расчета.
В случае многопередельного производства показатели по одной операции могут зависеть от предыдущих, что тоже надо учитывать.
Контекст (заказ, партия, период, цех и даже конкретный станок) напрямую влияет на себестоимость одной и той же номенклатуры. Даже идентичная продукция может иметь отличающуюся себестоимость. А в случае, когда производство не серийное, все расчеты становятся еще веселее. Потому, что даже приблизительно оценить дополнительные факторы невозможно.
То же самое касается и ФОТ: он распределяется по фактически выполненным операциям в привязке к конкретному производству. Ну а общепроизводственные затраты, в данном случае, можно не распределять, считаем что у нас директ-костинг.
И вот как вы подобную задачу хотите декомпозировать и отдать на откуп ИИ? А, самое главное, как вы будете проверять корректность полученных декомпозиций?
Вы только что сами разбили задачу на отдельные операции. Каждая операция строго детерминирована может считаться отдельно, может быть покрыта тестами и всегда будет выдавать одинаковый результат на одних и тех-же входных параметрах. Даже с учетом рекурсии, когда мы сами используем свой собственный продукт А для производства продукта Б.
Понятно, реальную себестоимость на производстве вы никогда не считали и теоретизируете на пустом место. За сим, продолжать дискуссию не вижу смысла.
Считал, только давным-давно, в нулевых и начале десятых, когда на крупняках все еще использовался Дефли с базой в Оракле. И учет был парционный. Выпустили партию продукции А, оформляем ее на склад, себестоимость УЖЕ должна быть посчитана и записана, иначе на какую сумму материально отвественные будут отвественны? Используем часть этой продукции для производства продукции Б, грузчик Вася взял со склада часть из новой партии, часть из старой, нам его действия не важны, когда оформляем партию продукции Б, для расчета ее себестоимости списываются партии продукции А по ФИФО, либо по ЛИФО, берем уже посчитанную и сохраненную себестоимость нужной партии и используем для расчета себестоимости продукции Б. У меня, собственно аббревиатуры ФИФО/ЛИФО в голове отложились в этот момент, когда занимался партиями материалов и продукции, а не тогда, когда проходил стек и очередь в институте.
Вот учет брака я уже не помню, думаю, этим кусочком занимался кто-то другой. Потому-что задача разбивается на маленькие кусочки и разными кусочками могут заниматься разные люди.
Для более конкретного разговора вам бы наконец сформулировать для местной аудитории ту задачу, которую вы считаете достаточно комплексной, но которую невозможно декомпозировать на небольшие понятные нейронке части. Потому что такую, если честно, достаточно сложно представить. Либо одно, либо другое.
У меня задача попроще, в некотором смысле, но похожая тем, что одним промтом и БЯМкой ее решить трудновато. Математическая модель ДВС с реализацией численной схемы Стренга, да ещё на языке Моделика. Поскольку для такой модели необходимо писать собственный решатель с контролем шага, а ещё и кучку модулей и интерфейсов, для расчета всей физики, то само описание займет очень много времени и места. Надо заранее продумать архитектуру, расписать ее довольно детально, иначе ИИшка упустит очень много деталей (уже пробовал), а иногда предлагает странные решения. Да, мою задачу много проще декомпозировать, но это надо заранее знать самому как сделать. Сэкономить теоретически можно, на чем-то повторяющемся. Но вопрос, а много ли таких похожих классов/функций/моделей и т.д. в проекте? Тем более, если реализуешь что-то относительно уникальное. Полагаю, что значительный прирост можно получить, если решаешь типовые задачи: писать автоматом документацию и поддерживать ее в актуальном состоянии, при изменении кода, например, или любую похожую рутину, которую хорошо формализовать можно. Или вот была у меня задачка систему автоматики сделать для управления двигателем и индикации через HMI. Три дня заняло техническое писание: последовательности экранов и картинок, логика кнопок, цветовые кодировки лампочек, подсветок и вотэтовсе. Осложняется это тем, что оно разбросано по разным документам, некоторые редакции друг-другу противоречат. А написать код и потестить заняло день-полтора с учётом сборки. Допустим, что ЛЛМка сократит мне написание кода даже на день, что не мало, и сделает все с первого раза. Она мне оставит самую тяжёлую работу: все продумать и изложить письменно.
Декомпозиция? А чем она тут поможет? Финальный вариант должен включать все требования которые были озвучены ранее.
В ТЗ любого ПО подразумевается, что финальный вариант его реализации будет охватывать весь описанный функционал, но это никак не мешает декомпозировать разработку.
Правда потом, все это придется самому собирать в общий модуль.
Что вы подразумеваете под "общим модулем"? Экспортируемая библиотека? Божественный класс?
Это не задача, это описание продукта целиком.
Это именно что задача. Одна из многих. Причем, даже не самая сложная.
Поищите описание любой ERP системы, что бы хотя бы представить уровень сложности. Десяток типовых модулей и до сотни специализированных.
Так вот себестоимость производства, это лишь четвертая часть одного из 10 типовых модулей.
У нас явно разное понимание термина "задача". Ваша формулировка на уровне "нужно реализовать журналируемую файловую систему с нуля", ну ка LLM давай, сделай в один заход. Задача это то, что человек может с нуля сделать за неделю, максимум две, все что больше подлежит декомпозиции.
Не надо изобретать терминологию. Она уже давно устоялась. И ни в одном определении Задачи нет привязки к трудоемкости.
Для меня задача, это та задача которую ставит бизнес. Подозреваю, что для кого-то "реализовать журналируемую файловую систему с нуля" тоже может быть задачей.
Далеко не все задачи подлежат декомпозиции. Нельзя декомпозировать слишком сложные или хаотичные задачи, где условия постоянно меняются, а связи между частями неочевидны и запутаны. Декомпозиция требует стабильности, а в таких задачах её нет. А это, буквально, большинство учетных задач.
Не надо изобретать терминологию
Вот и не изобретайте
Для меня задача, это та задача которую ставит бизнес.
Во-первых "задача это задача" это тавтология, а не определение. Во-вторых я, говоря про задачи, использую терминалогию Agile, а какую "устоявшеюся" терминалогию используете вы я понятия не имею.
Epic(Эпик) - это бизнес-инициатива или стратегическая цель, которая формулируется исходя из планов компании. Она отвечает на вопрос: "Какой большой результат мы хотим получить для бизнеса?". Измеряется в бизнес-показателях (ROI, OKR, KPI)
User Story(История) - это ценность для пользователя, которая приносит пользу бизнесу. Каждая Story должна решать конкретную проблему пользователя и при этом вносить вклад в достижщение цели. Измеряется в MVP, LTV, churn, NPS и т.д.
Task(Задача!) - технический шаг, который обеспечивает выполнение Story. Задачи сами по себе не несут бизнес-ценность, но они критичны, потому что без них Story не будет закрыта, а цель не будет достигнута. Измеряются в часах или стори поинтах.
Так вот ИИ служит для выполнения тасков(задач) - ревью кода, написание тестов, реализации CRUD, создания обвязки для инфры, имплементации отдельных компонентов и т.д. А, что вы написали, это Epic, цель для бизнес - "автоматизировать учет затрат в группе компаний при многопередельном производстве с учетом требований законодательства тех стран на территории которых работает группа компаний.".
Ахренеть логика. Берем вполне себе устоявшийся общеупотребительный термин «задача» и подменяем его жаргонизмом из agile.
А почему не из математики? Или из DnD? Подобная подмена понятий настолько же правомерна. Терминология Agile не является ни общепризнанной, ни единственно возможной. Это просто сленг, который вне agile - ничего не значит.
Впрочем, в остальном ваши суждения столь же спорны и поверхностны.
Стратегическая цель бизнеса заработать больше денег. Занять большую долю рынка. Вытеснить конкурентов.
Один из способов решения этих задач (user story в терминах agile, раз уж иначе вы не понимаете) это контроль доходов и расходов.
А вот необходимый инструмент для контроля расходов и та самая task из agile, это как раз расчет себестоимости производства.
И хоть ты лопни, но разбить расчет себестоимости на более мелкие, но самоценные, блоки невозможно.
Ох уж эти теоретики. Все, заканчиваю спорить о вкусе устриц с теми кто их не ел.
Берем вполне себе устоявшийся общеупотребительный термин «задача»
Термин "задача" является общеупотребительным только в широком смысле, на уровне словаря ожегова. В рамках IT он зависит от того, как построен SDLC, и как правильно означает именно, что вкладывается в понятие task, потому что все SDLC пришли из западной разработки.
Терминология Agile не является ни общепризнанной
Терминалогия Agile безусловно является общепризнаной в рамках Agile.
Это просто сленг, который вне agile - ничего не значит.
Это настолько же глупое высказывание, как сказать что термин "компилятор" это сленг, не который ничего не значит вне программирования.
Впрочем, в остальном ваши суждения столь же спорны и поверхностны.
А ваши просто тупые и не аргументированые. Вы даже не смогли дать свои определение "задачи" без тавтологии. У вас буквально с базовой логикой проблемы, а вы береть рассуждать об ИИ. Смешно.
Один из способов решения этих задач (user story в терминах agile, раз уж иначе вы не понимаете) это контроль доходов и расходов.
Нет, опять мимо, контроль доходов и расходов не является способ решения user story в терминах agile. Видите, вы просто даже близко не понимаете о чем говорите.
А вот необходимый инструмент для контроля расходов и та самая task из agile, это как раз расчет себестоимости производства.
Таска в терминах agile это не расчет себестоимости производства, хватить бредить.
И хоть ты лопни, но разбить расчет себестоимости на более мелкие, но самоценные, блоки невозможно.
Правильно говорить "я не могу разбить в виду нехватки опыта, компетенций и знаний".
Ох уж эти теоретики. Все, заканчиваю спорить о вкусе устриц с теми кто их не ел.
Ох уже эти самодовольные индюки, которые проработали всю жизнь в своем пузыре российский контор и теперь думаю что фантазии в их голове являются "общеупотребительными терминами".
Покажите мне программиста, который при такой вводной с первой попытки реализует эту задачу что там себе нафантазировал себе заказчик.
ИИ обещал только быстро писать шаблонный код, худо-бедно мимикрируя под стиль предыдущих авторов (а если их нет, то под средний стиль гитхаба и стек-оверфлоу). Обещаний считывать галлюцинации прямо из мозга постановщика задачи и предвосхищать его даже не сформулированные ещё ожидания, я что-то не припомню. Никаких знаний о вашем продукте, бизнесе, особенностях и соглашениях у него, в общем, тоже нет, а контекст знаний и память к тому же сильно ограничены. Это как пытаться жаловаться на калькулятор - "я нажал на равно а он не смог сделать мне готовую налоговую декларацию"
Ну где же вы тут вводную увидели? Это краткое описание задачи. Считай - просто название. К ней еще файлик листов на 60 с описанием нюансов процесса и формулами должен прилагаться.
Собственно, с тем что ИИ умеет писать шаблонный код я и не спорил никогда. Но мне тут регулярно пытаются доказать, что ИИ может меня полностью заменить, я просто не умею им пользоваться.
Вот я и спрашиваю, а как правильно?
Во-первых вам лично никто ничего не пытается доказать просто потому, что ваше мнение не имеет никакого значения для компаний, производящих LLM. Доказать пытаются владельцами бизнеса и не замену, а повышение эффективности и пока все находится на этапе внедрения и попытки понять как правильно использовать этот новый инструмент.
Во-вторых в тот момент, когда ИИ сможет вас "полностью заменить"(если такой момент когда-то в будущем настанет), вам никто и ничего доказывать уже не будет - вас просто уволят одним днем.
Смешной вы человек, право слово. Вы ничего не знаете обо мне, моих навыках, моих задачах. Вы ничего не знаете как работает бизнес. Вы ничего не знаете о приеме/увольнении. А пытаетесь выдавать какие-то суждения.
Ну во-первых, я именно тот человек к которому общаются когда хотят продать технологию или ПО в мою организацию. И если меня не убедят, что технология стоящая, бизнес даже разговаривать не станет с продажниками.
Во-вторых, бизнесу плевать на абстрактную эффективность. Ему нужна конкретика: как это снизит затраты, увеличит доходы или какие риски снимет. И в большинстве своем бизнес предпочтет стабильные проверенные решения, а не маркетинговый муссор.
В-третьих, нельзя уволить человека одним днем. Это и по закону возможно в крайне ограниченных случаях, и по процессу занимает банально больше времени. Рассчитать человека, проверить задолженность перед организацией, сдать или перевести на себя корпоративную симку, вернуть корпоративный ноутбук, передать дела, произвести все выплаты, оформить документы…
Смешной вы человек, право слово. Вы ничего не знаете обо мне, моих навыках, моих задачах.
Я прекрасно вижу ваши навыки по вашим комментариям.
Вы ничего не знаете как работает бизнес. Вы ничего не знаете о приеме/увольнении. А пытаетесь выдавать какие-то суждения.
Уж поверьте, побольше вашего знаю.
я именно тот человек к которому общаются когда хотят продать технологию или ПО в мою организацию. И если меня не убедят, что технология стоящая, бизнес даже разговаривать не станет с продажниками.
Каким продажниками, никакие продажники из anthropic, google или open ai к вам никогда не придут, попуститесь. И если появится ИИ, который позволит сократить стоимость разработки хотя бы на 30%, то любой бизнес либо будет ее использовать, либо вылетит с рынка из-за неконкурентности. Ваше мнение тут ничего не будет значить.
бизнесу плевать на абстрактную эффективность. Ему нужна конкретика: как это снизит затраты, увеличит доходы или какие риски снимет
Вот именно, по-этому когда конкурирующая компания в вашем секторе на очередном публичном отчете выйдет и скажет "мы внедрили ии и снизили косты на 20%", то ваше мычание про "а мне не доказали" никто и слушать не будет, вам просто поставять задачу(с) "внедрить" и вы будете молча ее исполнять.
нельзя уволить человека одним днем.
Еще как можно, "по соглашению сторон" например. Но уволят вас в один день или предупредят за 2 месяца о "сокращении штата" - легче от этого не станет.
У меня живой пример прошедшей недели: достаточно стандартная и не слишком сложная задача - сделать работающий (!!!) оптимизатор параметров узлов нециклического направленного графа с некоторым списком ограничений на оптимизируемые параметры в качестве ТЗ. Разработчик - Opus 4.6 на платной подписке.
Бродили с ним кругами несколько дней. Сначала были просто запросы реализации кода класса-оптимизатора с unit тестами, по текстовой спецификации. Сами спецификации тестировались от кратко-минимальных до очень подробных. В результате часть своих же сгенерированных тестов не проходят. В процессе итеративных исправлений ломает вообще все тесты. Были попылки сброса контекста и работы с его же кодом с посылом "проанализируй и исправь". Не смог.
Затем, снова с нуля. Он писал декомпозицию и план реализации для себя (да, 5000 строк текста для кода на 400 строк). Результат - почти работающая версия (судя по интеграционным тестам) и работающие unit тесты. После сброса контекста и написания ещё одной пачки unit тестов для этого же кода - половина из них красные. Попытки исправить сделали красными все тесты.
Было ещё несколько аналогичных итераций, но на тот момент я решил остановиться и написать оптимизатор самостоятельно, на основе одной из LLM-реализаций. После вдумчивого review от кода осталось около 10%. В вырезанных кусках неправильно и откровенно криво было реализовано почти всё - от дублирующегося перечисления уже обработанных ранее списочных структур до ошибок в логике.
Единственное, что можно назвать условно полезным - выбор (но не реализацию) алгоритма координатного спуска для оптимизации (не факт, что оптимального для этих графов) и примерная реализация оценочной функции, которую я переписал всего на 50%.
И да, для бойлерплейта и unit тестов я использую LLM достаточно успешно, даже локальные - после выхода Qwen 3.6.
Сделать меню вложенное, где каждый пункт имеет меню в себе на ардуино) Вроде задача простая, но когда доходит до физики - переключение не ловится и ты дальше первого пункта не можешь перевести курсор. Вообще с железом, если задача оказалась не тривиальной - полный провал.
По опыту работы следующие советы.
Разбивайте на независимые модули примерно до 600 строк, следите чтобы Агент не увеличивал этот файл
Используйте тулы для рефактора чтобы модель не правила всё вручную
Не используйте редкие языки или фреймворки, берите классический C++/Python/Java(JS)/PHP
Если что-то нужно проанализировать - генерируйте для этого код на Python/Perl
Обязательно используйте локальные тесты
Не злоупотребляйте git и командной строкой - копипаст только самого необходимого, просите вывести не более 5 строк (ошибки, дебаг, принтф)
Выражайте мысль как можно более кратко, чтобы экономить контекст
Описывайте задачу в числах. Каждый промт обязан содержать какую-либо константу или переменную
Не используйте описание конечных автоматов более 4 узлов
Говорите о алгоритмах и давайте ему оценку О(n) для оптимизации
Между модулями делайте промпт-инъекцию в виде очередей, функций с комплексными структурами. Крайне плохо понимает много аргументов f(a,b,c,d...)
Изолируйте модули очередями, старайтесь делать больше асинхронных вещей с таймаутами, где можно избегайте реалтайма
Промпт-инъекции и скиллы (только когда необходимы)
MCP-серверы (только когда необходимы)
Обязательно - embedder+векторная база данных, например qdrant для индексации кода и даташитов
Если контекстное окно дошло до 85% - стоп-игра, начинайте сначала, не надейтесь на Context compression - это только для проверенных случаев или подзадачи в задаче
Уж Клава блочила, блочила..
но ёжики продолжали жрать кактус. :)
Эта инструкция не годится.
Во первых, последний Опус 4.7.
Во вторых много ошибочной и просто устаревшей информации. Похоже, текст писался не руками.
Так это же реклама ТГ канала. Чего вы от неё ждёте?)) Задача статьи хотя бы немного быть похожей на настояющую и содержать рекламу в конце. Тут нет никакой задачи обучить или рассказать о чём-то интересном.
Похоже, текст писался не руками.
Ага, причем, похоже, изначальное намерение сделать “полный гайд по Claude Code - в одной этой статье вся информация, которая тебе нужна”, которое наверняка было указано в промпте, из-за протухания контекста постепенно всё больше тонуло, и под конец утонуло: “полный гайд” хоть с какой-то информацией, как этим самым Клодом пользоваться (структура папок и т.п.) сменился полнейшим маркетинговым навозом про наипередовейшие достижения Anthropic с голым перечислением крайних придуманных им .инструментов.
А как разбан получить гайд будет?
Тут автор не упоминает что на базе Claude Code можно сделать и полностью автономного агента, запустив его на отдельном сервере, а не на своем компьютере
Тут автор имеет в виду работу через API. При использовании подписки хотя бы начиная с 100$/m, можете спокойно использовать опус как основную модель
???
Вообще, статья написана очень сумбурно. Очень тяжело читать.
А можно ссылку на оригинал?
Тут скорее нужно промпт просить
Пишешь "дай мне промпт, который бы сгенерировал такую статью?" и аттачишь текст :)
Напиши большую статью для Хабра на тему: [ТЕМА].
Формат: полный практический гайд для новичков с нуля. Стиль — простой, уверенный, разговорный, без академической воды и без рекламного тона.
Структура:
0. Вступление: почему тема важна сейчас и что читатель получит.
1. Что это такое простыми словами.
2. Из каких частей состоит система.
3. Как начать: пошаговая настройка.
4. Основные режимы / функции / сценарии.
5. Настройки, которые реально влияют на результат.
6. Практические примеры использования.
7. Типичные ошибки новичков.
8. Лучшие практики.
9. Ограничения, риски и где нужна ручная проверка.
10. Чеклист внедрения.
11. Финальный вывод.Пиши как технический автор на Хабре: с подзаголовками, примерами, кодовыми блоками, списками, блоками «подходит / не подходит», практическими советами и честными предупреждениями.
Не копируй чужие формулировки. Сделай статью самостоятельной, но в духе большого подробного гайда, который хочется сохранить в закладки.
Каждое поколение моделей повышает эффективность создания следующего. Эта рекурсивная акселерация меняет расчёты всей индустрии.
Вы забыли добавить, что каждое поколение моделей требует х5-х10 стоимости на обучение. Стоимости на железки для этого только растут. А вот задачи в любой новой автоматизируемой области наоборот - усложняются со временем, потому что обычно начинают с легких и быстрых задач.
И эта “рекурсивная акселерация” легко упирается в стену экономической нецелесообразности. Не надо по первым шагам в новой области додумывать, что так будет всегда.
Те, кто не может эффективно использовать Cowork, как правило, всё ещё следуют старым привычкам: пишут длинные, детализированные промпты для каждой задачи, а результат всё равно нестабильный. А те, кто действительно разобрался, делают другое: тратят один день на то, чтобы выстроить «контекстную среду» (включая файлы контекста, глобальные инструкции, структуру папок), а затем промптом из 10 слов получают результат, который можно сразу отдавать клиенту.
Думается мне, что если у вас плохо получается в варианте промта, то коворк сделает еще хуже. С чего бы там взяться какой-то особой магии? Он также прочитает все подсказки в разных md, также из этого склеит один большой промт (причем вы не особо то управляете порядком обхода этих файлов и как это ляжет в U-образную кривую его внимания) и также его попытается выполнить. Просто это все он сделает не-алгоритмически, а с нечеткой логикой и иногда глюками. Так что если просто с промтом было плохо, то тут есть шанс огрести плохо в квадрате.
Всем привет!
Несколько лет сижу на Хабре в ридонли, всегда была интересна разработка, и ИТ в целом, но последний год очень хочется попробовать самому что-то сделать.
У меня есть личная потребность в сервисе, идея и понимание о том как он должен работать. Хочу начать с того, что нарисую в Фигме пользовательские экраны.
Подскажите, пожалуйста:
1.Как правильно оформить свою идею и мысли в ТЗ для ИИ, чтобы получить максимальной рабочий результат?
2.Как проще всегда закрыть базовые дыры в знании разработки - я понятия не имею ничего про терминал, среду разработки, да и весь процесс «под капотом» для меня это темный лес.
3.Какие сервисы сейчас актуальны для самостоятельной разработки, с учетом того что бекграунда в этом у меня нет вообще?
4.Насколько сейчас реально из России пользоваться сервисами из п.2?
Не адепт ИИ, но очень хочется сделать что-то для себя. Заранее спасибо всем!
Очень странно все...
5 часов назад статья вишла.
Очень много неточной информации .
Много информации устаревшей.
Счас уже есть opus 4.7 доступен.
Много чего уже на сегодняшний день изменилось из того, что описано как бест практикс в етой статье.
Самое важное - не хватает гайда, как из страны с людьми второго сорта создать аккаунт на claude.com, особенно в связи с последними новостями о том, что Антропик введут (или уже ввели - кто знает?) верификацию по паспорту.
Пока хожу через американский прокси, сегодня даже сон приснился, что опять забанили. Проснулся даже в ужасе. Как только забанят - буду искать таджика, армянина или казаха (домой приглашу, хехе). Не найду - придётся уходить из IT.
Claude Code — полный гайд и обучение для новичков с нуля