Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 54
Я вот читаю посты евангелистов от ИИ и у меня к ним только один вопрос: покажите запрос к ИИ по нестандартной и сложной задаче. Даже не результат запроса, а с₽ запрос.
В моих рабочих задачах описание какого-то блока может занимать несколько десятков страниц. На обычном языке, с учетом всех нюансов. А смотря на экивоки в запросах к ИИ, понимая что нужно будет учитывать еще и закидоны ИИ, вопросы безопасности и даже указание ничего не удалять…. Я понимаю, что я быстрее решу такую задачу сам, чем составлю запрос к ИИ. Да и примет ли такой большой запрос ИИ - тоже вопрос.
Не евангелист, но пользуюсь, разбиваю задачу на простые модули. ИИ пишет мне по одному модулю за раз, обычно не более 100-1000 строчек
Ну так я и пишу про требования к одному модулю. Который в принципе не разделяется на подзадачи.
Что, у вас там в этом модуле прям вся логика в одной функции? Если нет и разбито на разные классы/методы, то значит прекрасно разделяется на подзадачи. :)
Это sql запрос который формирует данные для финансового отчета по группе компаний.
Учет ведется в одной системе. Одними и теми же документами. Но у каждой организации свои нюансы учета. Плюс есть нюансы отнесения затрат как на прямые или на косвенные, в зависимости от организации проекта и статьи затрат.
А одним запрос это надо сделать потому, что данные потом выгружаются в Power BI.
И это только малая часть условий которые нужно учесть.
Не думаю, что кодинг тулзы подходящее место для разработки SQL запросов, всегда их ручками делал, наверняка есть тулзы для клод кода по работе с базой, но я никогда ими не пользовался и не знаю в каком они состоянии.
Однако если теоритизировать, ты вы сами как его будете делать, прям сразу весь функционал напишете от первой буквы и до конца логики ни разу не запуская? Или по кусочкам: сделали одно, проверили, что он вернул правильные данные, добавили еще логики, опять проверили и т.д.? Если второе, то опять-же, разбивается логика.
Вся сложность не в том, что бы написать огромный запрос SQL за один запрос к ИИ. Тут сложность в том, что бы не потерять уже реализованные нюансы, когда будешь добавлять новые.
куча временных таблиц, для корректной работы с курсами и переменными коэффициентами, 17 запросов по 200 строк в union, а к ним еще две таблицы в одной из которых итоги из объединения в разбивке по проектам...
И в каждом запросе львиную долю занимают условия.
Я, как-то, интереса ради, отдал на растерзание ИИ один запрос. Не из этого отчета, но тоже с мудреной логикой. Один запрос, строк на 150. Пара временных таблиц... И уже на первом вопросе запрос был безнадежно сломан.
Но, справедливости ради, если в запросе нужно реализовать только одну мудреную вещь, ИИ с этим боле-менее справляется.
Попробуйте, ради эксперимента, дать Клоду самому запланировать решение задачи(написать ТЗ самому себе), и потом сравните с тем, как просили решить задачу вы. Увидите много интересного после нескольких итераций.
Есть ощущение, что это засовывание бизнес логики в запросы (надеюсь хоть не в хранимые процедуры), которая возможно была бы лучше в своем слое.
Возможно, это мой личный опыт. Но для себя лимит поставил в 500 строк кода. Потому что дальше, частенько, LLM начинает ломать то, что работает отлично вместо того чтобы починить то что не работает.
Мне вот тоже интересно. Клод невероятен, если работает поверх очень качественных моделей связанных моделей. Он таким образом круто умеет понимать все и вся. Но модели такого уровня да еще влезающие в контекст это большая редкость по ряду причин. И тут Клод начинает строить теории, если раньше чаще спрашивал то сейчас я по 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 точки зрения разработчика ПО эта фраза не имеет смысла, но все пробелы я вам не заполню.
В силу отсутствия у вас практического опыта, это будет бессмысленный разговор. Но если вы хорошо учились, то термины неделимость состояния, отсутствие чётких интерфейсов и нелокальный эффект изменений - подскажут вам, почему не все задачи можно декомпозировать.
очень бы хотелось все таки обсудить проблему, но вы зачем то обсуждаете свое видение невозможности декомпозиции исходя из вам только известных критериев. И предлагаете воскресную угадайку.
Угадайка не интересна, проблема у вас типичная, но если вам просто хочется отстаивать позицию нейроскептиков - можете считать что вам это удалось.
У меня нет необходимости обсуждать решение моих задач. Я их решаю сам и довольно успешно. И не в теории, а на практике.
Все что было нужно мне - пример решения сложной задачи с помощью ИИ. Свои задачи я привел для примера сложности, а не обсуждения как их решать.
Нейроскептиком я не являюсь. Я просто очень хорошо представляю как работает эта технология и какие у нее ограничения.
Если человек успешно решал сложные задачи с помощью ИИ, он бы вполне мог бы это описать. Даже не углубляясь в детали. Общие нюансы, проблемы, ограничения, сильные стороны.
Собственно я схожий вопрос задаю на собеседовании программистам. Расскажите о своем сложном проекте и о том как вы его решали. И программисты рассказывают. А евангелисты ИИ не могут.
Для более конкретного разговора вам бы наконец сформулировать для местной аудитории ту задачу, которую вы считаете достаточно комплексной, но которую невозможно декомпозировать на небольшие понятные нейронке части. Потому что такую, если честно, достаточно сложно представить. Либо одно, либо другое.
Это не задача, это описание продукта целиком.
Это именно что задача. Одна из многих. Причем, даже не самая сложная.
Поищите описание любой 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.
Сделать меню вложенное, где каждый пункт имеет меню в себе на ардуино) Вроде задача простая, но когда доходит до физики - переключение не ловится и ты дальше первого пункта не можешь перевести курсор. Вообще с железом, если задача оказалась не тривиальной - полный провал.
Уж Клава блочила, блочила..
но ёжики продолжали жрать кактус. :)
Эта инструкция не годится.
Во первых, последний Опус 4.7.
Во вторых много ошибочной и просто устаревшей информации. Похоже, текст писался не руками.
Так это же реклама ТГ канала. Чего вы от неё ждёте?)) Задача статьи хотя бы немного быть похожей на настояющую и содержать рекламу в конце. Тут нет никакой задачи обучить или рассказать о чём-то интересном.
Похоже, текст писался не руками.
Ага, причем, похоже, изначальное намерение сделать “полный гайд по Claude Code - в одной этой статье вся информация, которая тебе нужна”, которое наверняка было указано в промпте, из-за протухания контекста постепенно всё больше тонуло, и под конец утонуло: “полный гайд” хоть с какой-то информацией, как этим самым Клодом пользоваться (структура папок и т.п.) сменился полнейшим маркетинговым навозом про наипередовейшие достижения Anthropic с голым перечислением крайних придуманных им .инструментов.
А как разбан получить гайд будет?
Тут автор не упоминает что на базе Claude Code можно сделать и полностью автономного агента, запустив его на отдельном сервере, а не на своем компьютере
Тут автор имеет в виду работу через API. При использовании подписки хотя бы начиная с 100$/m, можете спокойно использовать опус как основную модель
???
Вообще, статья написана очень сумбурно. Очень тяжело читать.
А можно ссылку на оригинал?
Тут скорее нужно промпт просить
Пишешь "дай мне промпт, который бы сгенерировал такую статью?" и аттачишь текст :)
Напиши большую статью для Хабра на тему: [ТЕМА].
Формат: полный практический гайд для новичков с нуля. Стиль — простой, уверенный, разговорный, без академической воды и без рекламного тона.
Структура:
0. Вступление: почему тема важна сейчас и что читатель получит.
1. Что это такое простыми словами.
2. Из каких частей состоит система.
3. Как начать: пошаговая настройка.
4. Основные режимы / функции / сценарии.
5. Настройки, которые реально влияют на результат.
6. Практические примеры использования.
7. Типичные ошибки новичков.
8. Лучшие практики.
9. Ограничения, риски и где нужна ручная проверка.
10. Чеклист внедрения.
11. Финальный вывод.Пиши как технический автор на Хабре: с подзаголовками, примерами, кодовыми блоками, списками, блоками «подходит / не подходит», практическими советами и честными предупреждениями.
Не копируй чужие формулировки. Сделай статью самостоятельной, но в духе большого подробного гайда, который хочется сохранить в закладки.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Claude Code — полный гайд и обучение для новичков с нуля