Еще прикольная темка - повышает на 30 процентов качество
https://cursor.directory/rules/python
https://cursor.directory/rules/python
cursor.directory
Cursor Directory
Find the best cursor rules for your framework and language
Я наверное дурак или как
Как же я зол на АИ
Ну это же бред
Где то есть глюк с часами
День еще не закрыт а он его считает закрытым
На часах 22:22 10 февраля
Как же я зол на АИ
Ну это же бред
Где то есть глюк с часами
День еще не закрыт а он его считает закрытым
На часах 22:22 10 февраля
👍2
Вайб-кодинг: ожидания, реальность и цена иллюзии скорости
Давно не писал про вайб-кодинг и, пожалуй, начну с главного вывода.
Не расстраивайтесь, если после большого количества времени вы получаете неудовлетворительный результат.
И если система, которую вы строили, работает не так, как вы планировали, это не обязательно провал.
Это часть процесса.
Теперь к сути.
Вайб-кодинг это мощный инструмент. Он действительно разгружает задачи, которые не требуют глубокой архитектуры и системного анализа. Короткое резюме, быстрый анализ, реакция на письмо, генерация вспомогательных функций, первичный разбор данных. В этих зонах AI экономит время и снимает рутину.
Проблемы начинаются там, где задача перестаёт быть линейной.
Когда вы пытаетесь через язык объяснить сложную систему, которую держите в голове, вы сталкиваетесь с фундаментальной вещью.
Человеческое понимание интуитивно, а код требует строгой последовательности.
Мы в голове подразумеваем одно, формулируем второе, а в результате получаем третье.
AI реализует логику так, как он её понял, а не так, как вы имели в виду.
И вот здесь появляется главный риск. Если вы не проверяете код, не понимаете базовые принципы и не контролируете архитектуру, очень легко потерять исходную идею.
Причём это происходит незаметно.
Вы уверены, что всё работает правильно, пока система не начинает вести себя иначе.
Особенно ярко это видно при построении торговой системы.
Там ошибка в логике это не просто баг, это деньги.
Иногда проще и быстрее просчитать параметры вручную, чем полностью делегировать их AI, который может реализовать критическую деталь иначе, чем вы задумывали.
Главный вывод за полтора месяца работы с вайб-кодингом простой.
"AI не понимает на сто процентов то, что вы имеете в виду"
Он интерпретирует. А интерпретация без чётких рамок приводит к расхождениям.
Это не минус инструмента. Это его природа.
Вайб-кодинг это не магия и не замена компетенции. Это современный навык. Как любой инструмент, он требует практики, насмотренности и понимания базовых принципов.
Без этого путь к результату будет долгим и местами болезненным.
Но при правильном подходе результаты со временем становятся лучше.
Просто ставка должна быть не на скорость, а на контроль, ясность логики и понимание того, что именно вы строите.
Давно не писал про вайб-кодинг и, пожалуй, начну с главного вывода.
Не расстраивайтесь, если после большого количества времени вы получаете неудовлетворительный результат.
И если система, которую вы строили, работает не так, как вы планировали, это не обязательно провал.
Это часть процесса.
Теперь к сути.
Вайб-кодинг это мощный инструмент. Он действительно разгружает задачи, которые не требуют глубокой архитектуры и системного анализа. Короткое резюме, быстрый анализ, реакция на письмо, генерация вспомогательных функций, первичный разбор данных. В этих зонах AI экономит время и снимает рутину.
Проблемы начинаются там, где задача перестаёт быть линейной.
Когда вы пытаетесь через язык объяснить сложную систему, которую держите в голове, вы сталкиваетесь с фундаментальной вещью.
Человеческое понимание интуитивно, а код требует строгой последовательности.
Мы в голове подразумеваем одно, формулируем второе, а в результате получаем третье.
AI реализует логику так, как он её понял, а не так, как вы имели в виду.
И вот здесь появляется главный риск. Если вы не проверяете код, не понимаете базовые принципы и не контролируете архитектуру, очень легко потерять исходную идею.
Причём это происходит незаметно.
Вы уверены, что всё работает правильно, пока система не начинает вести себя иначе.
Особенно ярко это видно при построении торговой системы.
Там ошибка в логике это не просто баг, это деньги.
Иногда проще и быстрее просчитать параметры вручную, чем полностью делегировать их AI, который может реализовать критическую деталь иначе, чем вы задумывали.
Главный вывод за полтора месяца работы с вайб-кодингом простой.
"AI не понимает на сто процентов то, что вы имеете в виду"
Он интерпретирует. А интерпретация без чётких рамок приводит к расхождениям.
Это не минус инструмента. Это его природа.
Вайб-кодинг это не магия и не замена компетенции. Это современный навык. Как любой инструмент, он требует практики, насмотренности и понимания базовых принципов.
Без этого путь к результату будет долгим и местами болезненным.
Но при правильном подходе результаты со временем становятся лучше.
Просто ставка должна быть не на скорость, а на контроль, ясность логики и понимание того, что именно вы строите.
❤1👍1
IDM
LONG:
ETH: ENTRY 1866, TP 2149.7, SL 1740.7
HYPE: ENTRY 28.449, TP 31.902, SL 27.298
SHORT:
BTC: ENTRY 71525, TP 69287, SL 72271
ETH: ENTRY 2146.5, TP 1740.7, SL 2149.7
HYPE: ENTRY 32.24, TP 28.46, SL 33.5
PUMP: ENTRY 0.002161, TP 0.001659, SL 0.0022
FVG
Signals: none
LONG:
ETH: ENTRY 1866, TP 2149.7, SL 1740.7
HYPE: ENTRY 28.449, TP 31.902, SL 27.298
SHORT:
BTC: ENTRY 71525, TP 69287, SL 72271
ETH: ENTRY 2146.5, TP 1740.7, SL 2149.7
HYPE: ENTRY 32.24, TP 28.46, SL 33.5
PUMP: ENTRY 0.002161, TP 0.001659, SL 0.0022
FVG
Signals: none
👌3
Вдумайтесь что ему приходится делать что бы просто понять человеческую логику
Я честно в ахере. - Мы разговариваем на двух разных языках
В коде была логическая ошибка с “стражем” для d1_active_until.
Использовалось значение 2**31 - 1 (~2.1e9).
А ваши времена в миллисекундах ~1.7e12.
Поэтому условие hc >= until почти всегда было true, и подходящие H4-кандидаты отбрасывались.
Исправление — увеличить страж:
Заменили на 2**62, чтобы ни одно реальное confirm_time в мс его не превышало.
После этого кандидаты перестали отсекаться неправильно.
Последствия:
Для HYPE количество pivot_idm выросло с 9 до 10.
Появилась пара foot_price 33.5 -> entry_price 32.24 (SHORT, PIVOT_HIGH), которую раньше фильтровало условие с некорректным стражем.
Я честно в ахере. - Мы разговариваем на двух разных языках
В коде была логическая ошибка с “стражем” для d1_active_until.
Использовалось значение 2**31 - 1 (~2.1e9).
А ваши времена в миллисекундах ~1.7e12.
Поэтому условие hc >= until почти всегда было true, и подходящие H4-кандидаты отбрасывались.
Исправление — увеличить страж:
Заменили на 2**62, чтобы ни одно реальное confirm_time в мс его не превышало.
После этого кандидаты перестали отсекаться неправильно.
Последствия:
Для HYPE количество pivot_idm выросло с 9 до 10.
Появилась пара foot_price 33.5 -> entry_price 32.24 (SHORT, PIVOT_HIGH), которую раньше фильтровало условие с некорректным стражем.
IDM
LONG:
ETH: ENTRY 1866, TP 2149.7, SL 1740.7
HYPE: ENTRY 28.449, TP 31.902, SL 27.298
PUMP: ENTRY 0.001875, TP 0.00336, SL 0.001815
SHORT:
BTC: ENTRY 71525, TP 69287, SL 72271
ETH: ENTRY 2146.5, TP 1740.7, SL 2149.7
HYPE: ENTRY 32.24, TP 28.46, SL 33.5
PUMP: ENTRY 0.002161, TP 0.001659, SL 0.0022
FVG
Signals: none
LONG:
ETH: ENTRY 1866, TP 2149.7, SL 1740.7
HYPE: ENTRY 28.449, TP 31.902, SL 27.298
PUMP: ENTRY 0.001875, TP 0.00336, SL 0.001815
SHORT:
BTC: ENTRY 71525, TP 69287, SL 72271
ETH: ENTRY 2146.5, TP 1740.7, SL 2149.7
HYPE: ENTRY 32.24, TP 28.46, SL 33.5
PUMP: ENTRY 0.002161, TP 0.001659, SL 0.0022
FVG
Signals: none
❤🔥1