IT

47 маркетинговых навыков для AI-агентов 🔹 coreyhaines31/marketingskills ⭐ 38587 звёзд · JavaScript Набор Agent Skills для Claude Code, Codex, Cursor и Windsurf, покрывающий CRO, копирайтинг, SEO, аналитику и growth-инжиниринг. Всё лежит в 47 markdown-файлах, связанных перекрёстными ссылками: copywriting тянет за собой cro и ab-testing, revops — sales-enablement и cold-email. В основе иерархии — навык product-marketing, к которому обращаются остальные. Ставится через npx CLI, плагин Claude Code, клонирование, git submodule или SkillKit для мультиагентных сценариев. В версии 2.0 переименовано 17 навыков, а page-cro и form-cro склеены в общий cro. При апгрейде с v1.x старые папки не удаляются автоматически — придётся чистить руками. репозиторий Полезная Репа 📈

В своих выступлениях Андрей Карпаты рассказывает о том, что он начал разрабатывать программы, выстраивая агентный цикл (Loop Engineering). Это интересная механика, которую я примерно полгода назад пытался использовать в своем оркестраторе. Идея в том, чтобы не говорить ИИ, что делать конкретно, а вместо этого выстроить цикл постепенного написания и улучшения кода. Эдакий эволюционный подход. На самом деле все, кто серьезно занимаются разработкой с помощью ИИ, рано или поздно приходят к этой идее, так как ИИ довольно специфично работает с механизмом внимания (attention) и страдает от разных "эффектов" - потеря информации в середине контекста (lost-in-the-middle), ослабление фокуса на ранних инструкциях, излишнее якорение (anchoring bias) и накопление ошибок (error accumulation), когда модель достраивает решение вокруг уже сгенерированного кода, даже если там есть проблема. Из-за этого модель может пропускать важные детали, даже если указать на них явно. При этом ИИ способен находить отклонения и ошибки если запустить его повторно. Поэтому запуская модель в цикле можно получить нормальный результат. Но есть несколько проблем. Во-первых, большое потребление токенов. Например, средний цикл на 8-10 часов использует от 30 до 60 млн токенов. Если брать токены через API, то получается довольно дорого. Во-вторых, в длинных циклах агент начинает "дрейфовать", постепенно уходя в сторону от поставленной задачи. Проблема в том, что критерии приемки сложно сформулировать так, чтобы они покрывали все детали - сосредоточившись на одном аспекте, упускаешь другие. Даже если проводить многоступенчатые проверки, остается проблема "2 из 3" - когда ты не можешь закрыть все требования одновременно и вынужден идти на компромисс. Чем длиннее цикл, тем сильнее этот эффект. Поэтому я пошел другим путем: вместо того чтобы отказываться от циклов, я делаю их максимально короткими. Плюс ограничиваю количество итераций, а для вариативности решений запускаю несколько агентов с разными системными промптами параллельно, оркестрируя их через общий чат для сбора и сравнения результатов. Коммуникация в чате помогает понять не только "что" делают агенты, но и "почему" они это делают. Кроме чата каждый агент производит артефакты, которые далее могут использовать другими агентами. Если интересно, напишу отдельный пост про агентный харнес, который я использую. Понятно, что с позиции OpenAI, Anthropic и других разработчиков LLM методы, которые способствуют большему потреблению токенов, имеют большую привлекательность - в конце концов, их бизнес-модель строится на продаже токенов. Но для небольших исследований и малого бизнеса подходы с дроблением задач и короткими циклами - куда более эффективный метод, позволяющий сохранить качество кода, не сжигая бюджет и не допуская дрейфа агентов. Мне кажется, что сейчас ключевой навык инженера - не просто умение писать промпты, а способность декомпозировать задачу и настраивать агентную оркестрацию с короткими циклами так, чтобы каждый шаг давал предсказуемый результат. Это и есть та инженерия, которая нужна бизнесу. Но это на словах, на практике доверять агентам пока рано.

Португальские слова в меня входят с трудом - чтоб их в себя запихнуть, сегодня прям во время трехчасового урока я запилила себе приложение. Попробую с ним решить свою боль - заучивать именно то, что проходим с учителем, а не то, что подкидывает бразильская сова из Дуолинго. Как работает: 1. Прошли урок 2. Я сфотографировала телефоном страницу учебника 3. Он сам вытащил оттуда новые слова и глаголы, закинул в мой словарик 4. Придумал для меня по ним упражнения. 5. Раз в день в ТГ шлет мне напоминалку «иди поучи язык». 6. Подкидывает мне ровно то, что мы проходили и упражнения на моем уровне сложности. Вуаля! У меня появился личный карманный тренер, который знает чему именно сейчас меня надо учить. И копит мои косяки, подкидывая мне их до тех пор, пока не увидит, что выучу. Задача решена - такого функционала, особенно до португальского, я нигде не встречала. И даже если б он был - это была б платная подписка. А так - все внутри моей базовой. Я, конечно, буду еще тестировать и допиливать. Но даже в таком виде - уже то, чего мне очень не хватало. Как сделала? 🚀 в Клоде у меня настроена система анализа - получая задание на рисеч он запускает кучу субагентов, смотрит все аналоги, а также все, что пишут про плюсы и минусы похожих приложений во всех известных соцсетях 🚀 порисечил - исходя из моего запроса и сбора идей предложил конфигурацию и план сборки моего приложения (я сидела на уроке, напомню, поэтому почти не вчитываясь ткнула «окей») 🚀 дальше примерно час он фурычил (модель Fable, использую на максималках пока открыта). Потом сам себя проверил через Codex. 🚀 и в финале дал мне ссылку на моего личного ИИ-тренера по португальскому. Я уже второй раз такой фокус проворачиваю за неделю. В первый - построила себе умный транскрибатор. И теперь вопрос - какова судьба всех приложений, которые выложены в AppStore, если полный чайник может теперь за пару часов полностью их скопировать, дотюнив под себя? Будущее наступило)) С вами был ваш карманный Ии-популяризатор. Ухожу учить глаголы и предлоги… Любовь на удаленке | Оля Сохнева #ии_наудаленке

Мы опубликовали тезис о киберэкономике, то есть новой экономической системе в программируемом и высокоавтоматизированном мире - человечество зажато между двумя экспонентами: технологии порождают новые риски вплоть до киберрабства и вымирания, но они же дают инструменты кибернетической саморегуляции - чтобы выживать, системы обязаны расширяться. капитализм это лучший самооптимизирующийся механизм экспансии, где цена работает как децентрализованный сигнал для баланса спроса и предложения - у экспансии встроенный трейд-офф риска и роста: чем быстрее рост, тем больше новых рисков: от долговых циклов и концентрации богатства до киберрабства владельцами ИИ - киберрабство - риск того, что техномонополии с рефлексивно самоулучшающимся ИИ применят накопленную власть за пределами бизнеса. оно уже здесь: телефон следит за вами, лента формирует убеждения, ИИ-ассистент работает на того кто больше платит - причиной являются человеческие ограничения в наблюдении, анализе, координации и действии - самое сильное из них - это проблема координации, порождающая невозможность коллективного действия. теория игр гарантирует, что индивидуально рациональное поведение даёт устойчиво худший коллективный исход - ИИ снимает эти ограничения: агенты ищут, рассуждают, коммуницируют и исполняют лучше людей. эпоха ограниченной рациональности позади. - смарт-контракты закрывают барьер доверия и гарантий исполнения обязательств: любые два агента, человек или ИИ, заключают сложные контракты без центральной юрисдикции - три рычага ускорения кибернетики: — регулирование через технологию (интерпретируемость ИИ, evals, верифицируемый аудит, полицентричное управление) — переход от экономики внимания к экономике намерений (агент читает интент, находит контрагентов, договаривается и исполняет) — ИИ-генерация рыночных механизмов на лету, где координация становится программируемой - развилка сегодня: смириться с киберрабством и дать рефлексивному технологическому риску привести к вымиранию или ускорить кибернетику, свести новые риски к нулю и сойтись к кибернетической экономике

Из чего состоит «сделать» Представьте, что на работе вас попросили добавить поддержку нового способа оплаты через Яндекс.Сплит. Если вы взялись это сделать, вот, что от вас ждут: Сначала вы очень хорошо подумаете и разберетесь в задаче. Куда добавить? Какие ограничения? Как это выглядело бы для клиентов? Затем вы очень хорошо подумаете о решении. Как это будет работать под капотом? Какие есть еще варианты? Что есть из готового, а что нужно и стоит писать самим? Какие требования и ограничения? Потом вы очень хорошо подумаете о краевых случаях. Какие они? Что с ними делать? На что можно забить? Какие не дадут запуститься? Тут вы еще и об ошибках подумаете. Скажем, что делать, если вебхук от Сплита пришел, когда мы лежали? А что делать, если Сплит вовремя не ответил, когда пытались создать заказ? Ретрай? Сколько раз, с какой паузой? Затем подумаете о данных. Что нам надо хранить, в каком виде? Это будет jsonb или нам вообще не нужен список товаров? А если решим расширить существующую модель заказов, как ее смигрировать? Что мы пока не знаем о данных и их хранении? Потом прикинете, как это все проверять. Какие тесты и для чего нужны? Что проверим автоматом, а что вручную? Есть ли у Сплита песочница, как в ней потыкаться? Потом придумаете, как запускать. Сразу всем? Втихаря на 10%? А за чем следить? Потом придумаете «анонс». Как и кому мы об этом рассказываем? Какие слова и термины используем, на что напираем? Что нашим клиентам от того, что у нас появился Сплит? Наконец начнете все это программировать. Возможно, сами, возможно, ллмкой. Проверите то, что получается. Что-то проверите автоматическими тестами, что-то руками, что-то агентом. Главное сейчас — убедиться, что оно готово к пуску. Затем ревью и пара-тройка раундов исправлений. Наконец смержите все в мастер и выкатите в прод. Еще раз убедитесь, что все работает. Не протыкал — не сделал. Если пуск затрагивает коллег, расскажете им об этом. Убедитесь, что не осталось хвостов. Если что-то нужно перепроверить через месяц-два, добавите задачку в календарь или агента. Поздравляю, теперь вы официально сделали задачу. P. S. Конечно, этот список меняется от компании к компании и от разработчика к разработчику. Если вы соло-предприниматель, все на вас. Если вы в бигтехе, анонсы писать не будете, но придется помудохаться с безопасниками. Если вы джун, от вас мало что ждут, но надеются, что вы со временем сможете закрывать весь список. Если вы сеньор, вы и сами все это знаете и регулярно делаете.

ИИ-агенты понимают, получится ли у них код, ещё до того, как его напишут Вышла интересная работа: исследователи заглянули во внутренние состояния coding-агентов и попробовали понять, что модель уже «знает» про код, над которым работает. Масштаб нормальный: – две открытые модели: Qwen3.6-35B-A3B и Laguna-XS.2 – 1231 задача из SWE-Bench Verified и Pro – 22 714 запусков агента – почти 80 тысяч изменений кода – медианная попытка – 52 шага и 36 тысяч токенов К внутренним состояниям модели подключили простую логистическую регрессию, то есть простой классификатор. И он смог определять: – полностью ли работает код – AUC до 0,83 – стало ли упавших тестов меньше – до 0,84 – компилируется ли код – до 0,78 – не сломал ли агент уже работавшие тесты Здесь 0,5 – случайное угадывание, так что сигнал довольно сильный. Причём лучше всего он читался не из последнего слоя модели, а примерно из середины. Но самое интересное – можно было частично предсказывать не только текущее состояние кода, но и будущее! По тому, что происходило внутри модели сейчас, исследователи угадывали, будет ли код рабочим примерно через 25 шагов. К этому моменту AUC падал до ~0,55 на SWE-Bench Verified и ~0,65 на более сложном SWE-Bench Pro, но всё ещё оставался выше случайности. Слабый сигнал сохранялся даже через 50 шагов – около 0,52 и 0,60 соответственно. Авторы назвали это latent programming horizon. Важная оговорка: шаг – это не обязательно новая правка. Агент может читать файлы, искать по проекту и запускать тесты. В медианной траектории было всего два реальных изменения кода. Поэтому речь не о том, что модель заранее держит в голове готовый патч. Скорее, она довольно рано понимает общее направление: задача реально чинится или агент уже куда-то не туда поехал. Практический смысл хороший: можно раньше останавливать провальные попытки, запускать параллельную ветку, повышать effort или подключать более сильную модель – до того, как агент сожжёт десятки тысяч токенов. Короче, код ещё не написан, а модель уже немного понимает, получится он или нет. Следующий шаг – научиться не просто читать этот сигнал, а использовать его, чтобы рулить агентом. Вот это будет прикольно. https://arxiv.org/abs/2607.05188v1

Кто-то только что переписал 40 лет PostgreSQL с нуля на Rust. И он уже проходит 100% официальных тестов Postgres. Проект называется pgrust. Это не форк, а полная реализация с нуля, которая уже проходит все 46 066 запросов из официального тестового набора PostgreSQL 18.3. Postgres разрабатывается уже 40 лет, и некоторые архитектурные решения из 80-х до сих пор приводят к сбоям: - один поток на соединение, фактически отдельный OS-процесс на пользователя - 350+ параметров настройки, которыми нужно управлять вручную - один только VACUUM стал причиной тысяч инцидентов pgrust выбрасывает всё это и начинает заново. Что уже работает: - проходит 96% regression suite PostgreSQL - psql подключается из коробки, есть совместимость с wire protocol - query planner, buffer cache, storage engine, B-tree индексы - JSON/JSONB, window functions, foreign keys, EXPLAIN ANALYZE, regex - тот же движок компилируется в WebAssembly и запускается прямо в браузере на pgrust.com 100% open source. https://github.com/malisper/pgrust