runesleo

Сьогодні за один день витратив 20% тижневого ліміту Claude, трохи занепокоївся😅. Якщо так і далі піде, до четверга залишуся без ліміту.
Озираючись назад, розумію: ліміт з’їдали не великі завдання, а рутина, яку я доручав йому виконувати власноруч: писати скрипти, відстежувати активності, змінювати конфігурацію — усе він робив сам.
Після обіду змінив розподіл роботи: Claude тепер лише мозок — розбиває цілі на завдання, розподіляє їх і перевіряє результат; за кожен напрям довгострокової роботи відповідає окремий Grok Bot: відео, опенсорс і активності для авторів.
Завтра подивлюся, чи вистачить

«Один ШІ розробляє план, один пише, один перевіряє» — сьогодні я справді працював так цілий день (Claude розробляв план і приймав роботу, Cursor писав код). Ось готовий спосіб, який можна просто взяти й використовувати:
一、Коли доручаєте роботу, чітко вкажіть ці 4 речі
1. Які файли потрібно змінити, а яких не можна торкатися
2. Критерії готовності: наприклад, «спочатку покажи попередній перегляд змін для реальних даних, нічого не записуй напряму»
3. Тести, які обов’язково потрібно додати; під час тестування заборонено використовувати реальні облікові записи й дані
4. У звіті про виконану роботу

Нещодавно переглядав проєкти, у яких брав участь, і помітив одну дуже болючу закономірність:
Паперовий прибуток на піку був чималим, у кількох випадках зростав у кілька разів.
А от реально зафіксованого прибутку було набагато менше.
Проблема не у виборі проєктів, а в тому, що я заздалегідь не продумував, як продавати.
Тепер встановив для себе кілька правил:
1. Ще під час входу прописувати план продажу, а коли ціна подвоїться — спершу виводити початкову суму
2. Продавати частинами, не намагатися вгадати пік; продати надто рано — це ціна дотримання цих правил
3. Стежити за ліквідністю: щойно гли

@XCreators @Support Зміна ціни моєї підписки на автора з 21 вересня перебуває в статусі «очікує». Минув уже понад місяць, а з підписників досі стягують плату за старою ціною.
Я створив запит і отримав відповідь, що зі мною зв’яжеться фахівець, але нічого не змінилося. Хтось може перевірити, що сталося? 🙏

Якщо одночасно користуєшся Grok Bot і Claude, то, найімовірніше, половину результатів ти взагалі не отримав.
Я думав, що бачу всю роботу, яку команда ШІ виконує щодня. Перевірив: розмови читати можна, але справжні результати записані у файлах на їхніх хмарних комп’ютерах. Щойно хмарний комп’ютер простоює, він відключається від мережі, а мої регулярні спроби забрати файли щоразу завершувалися тайм-аутом без повідомлення про помилку.
Рішення — зробити навпаки: не забирати файли самому, а дозволити Bot через підключений до нього комп’ютер самостійно надсилати файли назад. Пам’ять теж синхронізуєт

Пул лімітів Cursor працює так: Grok 4.7, Grok 4.6, Grok 4.5 і Composer 2.5 спільно використовують один тижневий пул, з якого також витрачаються ліміти Auto.
Тож у повсякденному використанні немає потреби вмикати Auto — просто вибирайте Grok 4.7 і встановлюйте рівень Extra High.
Зараз я розподіляю роботу так: коли ліміт Claude вичерпано, переходжу на Grok 4.7 у Cursor.

Знову натрапив на підводний камінь із launchd.
У мене є черговий ШІ, який за розкладом викликає codex exec, щоб сортувати знахідки, які надсилають інші ШІ. У терміналі все працює нормально, якщо запускати вручну, але за розкладом через launchd нічого не робить.
З’ясувалося, що причина в тому, що launchd запускає процес із робочою директорією /, яка не належить до жодного git-репозиторію. Codex за замовчуванням перевіряє, чи є поточна директорія git-репозиторієм, і відмовляється виконуватися, якщо це не так. Щоб виправити, достатньо додати параметр --skip-git-repo-check; я ще додав тест, щоб у

Цей період ChatGPT Pro триває до середини листопада, поки що не продовжуватиму підписку.
Останнім часом ці моделі GPT не дуже добре справляються з моїми реальними робочими завданнями; до того ж із 30 жовтня ліміти Codex і Work у Pro ще й скоротять удвічі.
Надалі основними інструментами будуть: Claude — для оцінювання й фіналізації, Grok Bot і Grok Build — для моніторингу X та пошуку інформації, Cursor — для написання коду.
Це не означає, що я зовсім відмовляюся від ChatGPT. Якщо одного дня вийде справді потужна нова модель ChatGPT або з’явиться варте уваги велике оновлення, я знову поновлю під

Я щодня прошу AI готувати кілька X Chat-групам інформаційні дайджести лише для читання; один із пунктів — перевіряти, чи не з’явилися в групах сигнали на кшталт змін правил або ризиків безпеки. Учора він повідомив про одну «зміну правил/ризиків». Я відкрив повідомлення й побачив, що насправді хтось сказав, ніби певний спосіб написання трохи hacky. Англійські слова, пов’язані з ризиками, шукалися за збігом підрядка, і в hacky якраз міститься hack, тож спрацювало сповіщення. Тепер англійські слова шукаються лише як окремі слова, і це хибне спрацювання зникло.
Найгірше в сповіщеннях за ключовими

Кілька днів тому сповіщення про запити в особистих повідомленнях на X постійно повторювалися: запити, які я вже опрацював, через деякий час знову спливали. Я перевірив і з’ясував, що проблема була у відбитку для дедуплікації. Відбиток складався з усього тексту запиту, а в кінці містив кількість підписників у профілі співрозмовника. Щойно співрозмовник отримував одного нового підписника, відбиток змінювався, і система сприймала це як новий запит. Виправлення дуже просте: прибрати кількість підписників із кінця відбитка й залишити лише незмінну частину.
Мій висновок такий: під час дедуплікації в

Збір｜Джерела даних для погодних ринків, дані для бек-тестування Polymarket з інтервалом 5 хвилин — звідки ви їх берете?
У групі TG останні кілька днів люди знову й знову запитують про дані, переважно про три категорії:
· Де шукати джерела даних для погодних ринків
· Чи є дані для бек-тестування Polymarket з інтервалом 5 хвилин
· Чи є сайти, де можна переглядати PnL, бажано з розділенням між балансовим прибутком PM і фактичним прибутком після вирахування комісій
Щоразу розрізнені відповіді в групі швидко губляться, тож краще зібрати тут список того, чим усі насправді користувалися.
Достатньо ві

Інженерна команда Meta поділилася контринтуїтивним висновком: що більше знань має agent, то легше йому помилятися.
Спочатку вони створили універсального agent, який умів усе. На демонстрації він працював нормально, а після запуску в продакшн почав плутати контексти: застосовував правила іменування системи A до системи B. Рішенням було не написати кращий промпт, а зробити так, щоб той agent, який займається диспетчеризацією посередині, нічого не знав: 1,300 рядків коду, який лише класифікує, збирає поля, перевіряє та розподіляє завдання, а 14 спеціалізованих agent відповідають кожен за свою діл

ChatGPT учора знову непомітно змінив фронтенд. У мене є скрипт, який автоматично надсилає команди у вебверсію, і він увесь час знаходив поле введення за допомогою id #prompt-textarea, але вчора раптом перестав його знаходити — вони замінили поле введення на редактор форматованого тексту ProseMirror, і старого id більше не стало. Про такі зміни не буде жодних оголошень, і ти можеш дізнатися про них лише тоді, коли автоматизація зламається. Висновок такий: у будь-якій автоматизації, що працює через DOM вебсторінки, не варто сліпо покладатися на один id; краще передбачити кілька запасних селектор

Учора ціла партія моїх скриптів автоматизації раптом одночасно перестала працювати; пів дня шукав причину, але справа виявилася не в коді — під час оновлення brew автоматично перелінкував python3 на 3.15, а новий site-packages був порожній, тож усі залежності, які раніше встановлювалися через pip, зникли. Ще гірше, що скрипти не повідомляли чітко про відсутні залежності, а просто незрозуміло падали на import. Згодом я додав до моніторингу перевірку: щодня окремо виконувати check, чи на місці залежності python3; щойно brew щось змінить, це можна буде одразу виявити. Покладатися на системний мен