Может стоит сообщения не по диагонали читать? ;)
Вот цитата из сообщения
"Задачей было создать сервис для фреймворка (т.е. по сути все ИИ не имели "базы знаний" конкретно по нему): ограничение частоты запросов (Rate Limiting)."
Ну естественно нет. Я попросил ИИ выполнить задачу, сервис, который может стать часть фреймоврка . Уточню под "сервисом" тут понимается не какой-то интернет сервис дающий посетителям нечто, а просто часть логики проекта отвечающая за определенную задачу. В данном случае возможность ограничения количества запросов от отдного пользователя в заданную единицу времени.
В плане "фреймворк помог" - тут я имел ввиду именно то, что ожидается от инструмента подобного класса. Я воспользовался его функционалом для реализации своей небольшой задачи. Она живет в моей домашней сети и выполняет мне нужную функцию. точно так же я мог бы сделать и на ларавель и на любом другом фреймворке. Тут просто появился повод погонять фреймворк на реально нужной мне задаче.
[6/12] Очередной этап челенджа. Экватор
Увы этот месяц был сильно загружен работой. И по челенджу ни чего не сделал.
Правда провел тест-сравнение на правах "вне конкурса". Поставил одну и ту же задачу трем разным агентам/моделям. Т.е. промпт основной записал в файл и "скормил" всем трем кандидатам.
GigaCode - бесплатный тариф. Тут с ходу минусы: вообще не понятно какие ограничения, сколько потрачено, сколько осталось. Как я понял (но это не точно) при достижении - его начинает колбасить и выдает какую то техническую ошибку.
Claude (Opus и Haiku) - Платно.
Задачей было создать сервис для фреймворка (т.е. по сути все ИИ не имели "базы знаний" конкретно по нему): ограничение частоты запросов (Rate Limiting). Описал требования и ограничения, необходимость тестов и т.п. Сначала запустил в режиме архитектора, потом уже реализацию.
Увы в спешке запустил их на разных коммитах фреймворка (но разница не критична для сравнения оказалась). Так же в плане claude похоже я реализацию поручил уже хайку. (по невнимательности и неопытности)
Предложенную архитектуру сам прочитал бегло, не правил ни чего, скормил ИИшке для равнения (только основное приведу):
Выбор алгоритма
И дал таблицу где по нескольким параметрам дал оценке по десятибальной шкале. У опуса везде 10 и 10 кроме одной 9, и гага всех хуже, яндекс по середине.
После реализации. Единственный результат, который заработал из коробки SourceCraft. Клод действительно точнее всех следовал архитектуре фреймворка. В прочем тут из основного в этой задаче конфиги у меня типизированные подразумевается.
Но тем не менее все срывались на какие то "типовые" (принятые в популярных фреймворках) шаги. Например гига и клод - вызовы методов "привычных" или с "привычным" набором параметров, а не так как в фреймворке (что и привело к неработоспособности). Яндекс тоже косячил в этом плане - но это не привело к нерабочему коду.
Тесты написали все. Но яндекс гонял тесты не только своих результатов, но и полностью все тесты. Опус написал тесты не для всех созданных классов, проверял только написанные собой тесты (которые не затронули ряд новых классов) - в итоге код нерабочий, (который, уверен, был бы исправлен за одну итерацию, если бы клод запустил все тесты).
Гига... этого пришлось тормознуть. т.к. он полетел в разнос. Запустил тест, чего то поправил, опять запустил, посыпались ошибки как я понимаю от каких то ограничений бесплатного тарифа. - в общем не стал я рисковать.
Вероятно полезно было дать инструкцию, чтобы они выполняли коммиты более атомарно.
По итогу, все решения я достаточно быстро запустил: минут 15 наверно на правки ушло. Правда правил костыльным методом - для продуктового решения мне надо уже детально вникнуть, возможно даже доработать фреймворк будет правильно (например чтоб мидлвары с параметрами указывать без необходимости раннего создания объекта)
Из общего: в из я сказал что для тестов надо написать хранилище данных в массиве (оно не имеет смысла для данной задачи на бою) и все его сделали в основном пространстве имен, а не в тестах (но возможно стоило уточнить).
Опус и гига пошли четко по тз и реализовали идентификацию пользователя по Ip (согласно задаче), а вот яша подошел творчески. Кроме Ip сделал реализации по Ip+UA, по ключу апи, по идентификатору пользователя, а так же для комбинированной идетификации.
Результаты можно посмотреть
claude
sourcecraft
gigacode
В итоге однажды в прод пойдет комбинация из решений SourceCraft и Claude
Опять садишься на своего "коня" ведущего в тупик? Не стоит этого делать.
Вот именно, по этому и чаще всего, а особенно если есть команды на старте, запускаются поэтапно - и это вполне отработанный и успешный путь.
Естественно при любом раскладе. Именно по этому нет смысла к первому релизу вылизывать все в идеал. Особенно если продукт рассчитан на пользователей, а не на "себя любимого".
Странная реакция на шишки. Обычно анализируешь ошибки, делаешь выводы и следующий проект спокойнее запускаешь.
просто мысли вслух ни о ком конкретном:
приступать к реализации идеи (да даже ее планировать) лучше в той нише о которой имеешь действительно представление, в которой вращаешься, иначе, если вдруг дойдет до "релиза" может быть очень больно от неоправдавшихся ожиданий. Опыт штука полезная - не стоит его игнорировать.
В прочем набитые шишки - тоже опыт ;)
Попробуй мне все же поверить: разбей задачи на более мелкие шаги :) . Для примера: я уже одну свою рутинную задачу автоматизировал с использованием своего фреймворка. (так он, можно сказать учебный, да и в самом начале). Т.е. он уже решает какие то задачи, я уже не на тестовых задачах с ним начинаю взаимодействовать. Т.е. я уже вижу не "флажок" , а некий полноценный результат.
Т.е. если идея подразумевает долгую реализацию лучше ее разделять на отдельные шаги дающие промежуточный но функциональный результат. И эти "результаты" - дают дополнительный стимул
Точно так же и с несколькими параллельными задачами. Тут тоже из опыта: у меня на обслуживании несколько проектов (включая сервис выкроек) по некоторым из них сложные задачи (куча логики постоянно развиваются и т.п.). И , с одной стороны, хорошо иногда мозг переключать между разными задачами, с другой стороны это и сложность - ладно бы если задачи были уровня косметического, мозг мышца и он устает. Но у меня это вынужденная мера - так я обеспечиваю стабильность заработка (чтоб не быть зависимым только от одного заказчика). Но когда это не источник дохода - зачем усложнять? Имхо, лучше концентрироваться.
Т.е. если есть несколько идей подразумевающих долгую реализацию, то лучше их выстроить в последовательную линию выполнения, без распараллеливания.
Т.е. вот тебе две мысли, попробуй таки в них поверить. Все это, конечно лишь мое мнение, и что мне помогает. А так все мы +/- одинаковы. 99% что если бы я тащил несколько проектов несколько лет и не видел ни какого релиза - то же бы наскучило и я еще бы 100500 идей начал реализовывать из-за этого.
Знаешь такую поговорку: "Глаза боятся, а руки делают."?
Если бояться сложностей, что будет долго, что не получится, что жизни не хватить и тд. то какой смысл вообще жить? Да, по началу когда возникает идея, сначала на эйфории можешь даже что-то начать делать, но жизнь обламывает, если не слабак, то берёшь себя в руки и потихоньку, но продолжаешь, и вот уже начинает на горизонте маячить флажок финиша.
Дело не в сложностях. Уверяю тебя даже если озадачится созданием одного лишь фреймворка, только полноценного, а не очень усеченного, можно найти задач выше крыши. Тут именно и идет от понимания необходимого объема работ даже по каждой отдельной части.
И тут ты ухватился не за ту нить в моих словах. Если делать все сразу и одновременно - "за двумя зайцами погонишься ни одного не поймаешь". (а в данном случае "зайцев" несколько). Т.е. более разумный подход сделать сначала одно (как минимум до первого релиза, чтоб пошел фидбек), потом другое. Распыляться это плохо, особенно если проект задуман "масштабный". Мой подход не исключает ни сложностей, ни где то там на финише своих готовых ОС, ЯП и т.е. (если конечно потребуются они).
Ну, а потом статистика упрямая вещь либо ядро твоей ОС будет явно кастрированным по сравнению с ядром линукс либо примерно 13 лет только на непосредственный набор кода (и это только ядро, это даже не ОС). Ну ок ты жутко умен и сумеешь оптимизировать. Даже в половину скнинем до 7лет.. И что?
При этом надо понимать для ИТ 7 лет это пипец как много времени. Не получится так, что весь код написанный за эти 7 лет будет актуален в конце - а значит его надо будет переписать. (И 7 лет это чистое время работы: без любых перерывов и скоростным набором)
Ок. Ты рекомендуешь браться за все не думая? Ну например прокопать тоннель через центр земли. Тоже скажешь "глаза бояться, а руки делают". Может лучше все это время потратить на доработку самолетного двигателя, который позволит быстрее долетать до противоположной стороны.
Не надо натягивать поговорки на все что угодно.
НО Еще раз повторюсь: дело все в целях и задачах. Интересно провести свободное время - да вполне норм (даже тоннель можно начать копать - лишь бы нравилось), если же цель получить рабочее решение и использовать его, то все же лучше разумно планировать свои задачи и оптимально прилагать услилия - так можно дойти гораздо дальше, чем пытаясь тащить 100500 задач и видя только флажки в конце "последней мили"
