Ну как вам сказать... У меня картина в этом плане куда как лучше (хотя на мой код агент тоже ругается). Потому что я трачу туда своё внимание. Мне совершенно насрать, оптимально ли работает рендеринг, но лежать он должен попендикулярно. Потому что, ежели лежать он будет попендикулярно, на десятой итерации нейронка сама допилит его до надлежащего состояния. А иначе он будет не улучшаться, а деградировать.
Программирование с агентами что-то от садовничества в себе несёт
Мы мимоходом нашли потенциальные дедлоки, но я не запрашивал проверку на баги и тем более аудит безопасности. Меня интересовали архитектура и поддерживаемость.
У меня появляется какое-то вредное нездоровое хобби, оценивать выложенные на Хабр вайбкодерские проекты. (Если что, интерес у меня не праздный, я сам такую же махину пишу)
Если кратко, всё плохо и дело не в том что controller.py большой. Перегруженные ответственностями модули, моногочисленные нарушения границ, дублирование логики. Видно, что предпринимались попытки удержать контроль, но дальше попыток дело не продвинулось.
Цитата агента:
Но структура больше “каталоговая”, чем архитектурная. Папки есть, границ почти нет.
Главная проблема: слои зависят друг от друга в обе стороны. Например, bot_runner.py импортирует API/DB/CRUD bot_runner.py:39, а API импортирует trading core и tasks api/depthsight_api.py:16. То есть api не просто управляет ботом через контракт, а знает внутренности движка; движок, в свою очередь, знает про API-модели и CRUD.
Я бы сформулировал так: архитектурное намерение есть, архитектурной дисциплины нет. Автор, похоже, понимал желаемые компоненты: API, worker, bot runner, market data, frontend. Но по мере добавления фич код начал склеиваться напрямую импортами, глобальным состоянием, большими классами и backward-compatibility костылями.
Я прямо закрываю глаза и вижу, что с каждым днём вам всё сложнее поддерживать этот ком. Проекту нужна методичная пересборка и желательно вчера.
Ууу, как вас бомбит :). Возможно вас утешит, что мне нейронка тоже много чего поломала. (Собственно, все практические советы и раздел по технике безопастности - не из просто так. За каждым советом лежит какая-то проблема, поломка, потерянное время).
Статья пронизана одушевлением и это не просто так. Пока вы будете видеть в агенте только Т9 - хрен у вас чё получится.
У Т9 нет эмоций. Агент же - клубок эмоций и комплексов. Попытка общаться с ним без учёта его "психического состояния"... ну, успехов вашему проекту, что...
Недоделывание, прямое игнорирование инструкций - это всё в порядке вещей. Нужно притереться, чтобы сразу такие вещи замечать и вовремя выправлять.
Так что не расстраиваемся, не поручаем агенту критические операции, пока нет уверенности в нём (я своему до сих пор комититься не разрешаю) , и продолжаем осваивать.
Тут практика нужна. Без практики ничего не будет. Практиковаться лучше на простом. Не надо требовать от агента сложных миграций, пока в ваших руках он тетриса не написал.
Прикольно. Я уже видел этот фокус. При моделирование пространства комплексных чисел через i = e1*e2. Но тут оно поднято на гораздо более высокий уровень.
Проблема в масштабировании этого результата на продакшн - сохранение совместимости. Тут я могу и несколько раз уже так делал - писать и выкидывать огромные подсистемы просто потому, что они мне не нравятся. На существующий продакшн это не распространить, хотя, на работе масштабный рефакторинг наших легаси-монолитов я начал. Но там приходится работать сильно аккуратнее
Мы - это я и агенты. Всё верно. Меня тоже очень интересует эта арифметика. 60 000 на 4 неделе в месяце и на 4 месяца - это около миллиона, а у нас 250 тысяч. Большая часть правок действительно относится к переписыванию кода, а не к написанию нового. Об этом, собственно и та часть статьи, что говорит про рефакторинг.
Проект пережил две огромных миграции. Переписывания движка с пайтон на си - это первая. Потом было еще разбиение получившегося монолита на библиотеки. А ещё мы переписывались с PyQt на собственный UI фреймворк.
Скорее всего суммарный объём правок даже больше. Я как-то видел 130 kloc на горячей неделе, и думаю, что это не самое большое число. Не то чтобы я активно следил за этой метрикой.
Ну как вам сказать... У меня картина в этом плане куда как лучше (хотя на мой код агент тоже ругается). Потому что я трачу туда своё внимание. Мне совершенно насрать, оптимально ли работает рендеринг, но лежать он должен попендикулярно. Потому что, ежели лежать он будет попендикулярно, на десятой итерации нейронка сама допилит его до надлежащего состояния. А иначе он будет не улучшаться, а деградировать.
Программирование с агентами что-то от садовничества в себе несёт
Не знаю.
Мы мимоходом нашли потенциальные дедлоки, но я не запрашивал проверку на баги и тем более аудит безопасности. Меня интересовали архитектура и поддерживаемость.
Для безопасности нужно отдельное исследование.
У меня появляется какое-то вредное нездоровое хобби, оценивать выложенные на Хабр вайбкодерские проекты. (Если что, интерес у меня не праздный, я сам такую же махину пишу)
Если кратко, всё плохо и дело не в том что controller.py большой. Перегруженные ответственностями модули, моногочисленные нарушения границ, дублирование логики. Видно, что предпринимались попытки удержать контроль, но дальше попыток дело не продвинулось.
Цитата агента:
Но структура больше “каталоговая”, чем архитектурная. Папки есть, границ почти нет.
Главная проблема: слои зависят друг от друга в обе стороны. Например, bot_runner.py импортирует API/DB/CRUD bot_runner.py:39, а API импортирует trading core и tasks api/depthsight_api.py:16. То есть api не просто управляет ботом через контракт, а знает внутренности движка; движок, в свою очередь, знает про API-модели и CRUD.
Я бы сформулировал так: архитектурное намерение есть, архитектурной дисциплины нет. Автор, похоже, понимал желаемые компоненты: API, worker, bot runner, market data, frontend. Но по мере добавления фич код начал склеиваться напрямую импортами, глобальным состоянием, большими классами и backward-compatibility костылями.
Я прямо закрываю глаза и вижу, что с каждым днём вам всё сложнее поддерживать этот ком. Проекту нужна методичная пересборка и желательно вчера.
Ууу, как вас бомбит :). Возможно вас утешит, что мне нейронка тоже много чего поломала. (Собственно, все практические советы и раздел по технике безопастности - не из просто так. За каждым советом лежит какая-то проблема, поломка, потерянное время).
Статья пронизана одушевлением и это не просто так. Пока вы будете видеть в агенте только Т9 - хрен у вас чё получится.
У Т9 нет эмоций. Агент же - клубок эмоций и комплексов. Попытка общаться с ним без учёта его "психического состояния"... ну, успехов вашему проекту, что...
Недоделывание, прямое игнорирование инструкций - это всё в порядке вещей. Нужно притереться, чтобы сразу такие вещи замечать и вовремя выправлять.
Так что не расстраиваемся, не поручаем агенту критические операции, пока нет уверенности в нём (я своему до сих пор комититься не разрешаю) , и продолжаем осваивать.
Тут практика нужна. Без практики ничего не будет. Практиковаться лучше на простом. Не надо требовать от агента сложных миграций, пока в ваших руках он тетриса не написал.
Меня не добавили . Обидно :(
О! Это очень точно сформулировано. Характер долга отличается.
Иишка генерит и техдолг тоже, но техдолг иишка исправляет также быстро, как и генерит. Если не быстрее.
Значит, проблема вовсе не в техническом долге.
Это всё правильно. Но совершенно никак не объясняет, зачем помнить формулу корней квадратного уравнения
И всё-таки для моделей qwen надо бы юзать qwen-code. Тем более, что qwen-code - это произведение искусства
А квадратного то зачем?
Точно так же, как с любым другим источником информации
На такое много токенов надо...
Уууу... ИИ и MAX в одной статье... А вы смелый.
Ути, какая знакомая платформа :) . Прошло пятнадцать лет, а на ней как собирали, так и собирают :)
Полезная штука.
В принципе с поиском дублей справляются и сами нейронки, но их в ci встраивать ещё проблемнее. Вообще, пора подобными инструментами обвешиваться.
Вау... Нет, пожалуй, это перебор.
У меня четыре монитора стоят, чтобы делать одну задачу :)
Сколько же понадобится для двух...
Прикольно. Я уже видел этот фокус. При моделирование пространства комплексных чисел через i = e1*e2. Но тут оно поднято на гораздо более высокий уровень.
Комментарий оставить хочется, но по теме что сказать - пока ещё не знаю.
Поэтому докладаю, что статья прикольно написана. Выверенный язык, авторский голос... Приятно читать.
Проблема в масштабировании этого результата на продакшн - сохранение совместимости. Тут я могу и несколько раз уже так делал - писать и выкидывать огромные подсистемы просто потому, что они мне не нравятся. На существующий продакшн это не распространить, хотя, на работе масштабный рефакторинг наших легаси-монолитов я начал. Но там приходится работать сильно аккуратнее
Мы - это я и агенты. Всё верно. Меня тоже очень интересует эта арифметика. 60 000 на 4 неделе в месяце и на 4 месяца - это около миллиона, а у нас 250 тысяч. Большая часть правок действительно относится к переписыванию кода, а не к написанию нового. Об этом, собственно и та часть статьи, что говорит про рефакторинг.
Проект пережил две огромных миграции. Переписывания движка с пайтон на си - это первая. Потом было еще разбиение получившегося монолита на библиотеки. А ещё мы переписывались с PyQt на собственный UI фреймворк.
Скорее всего суммарный объём правок даже больше. Я как-то видел 130 kloc на горячей неделе, и думаю, что это не самое большое число. Не то чтобы я активно следил за этой метрикой.
Проект меняется сумашедшими темпами.