Cohesion и Coupling 🧩🔗

Здарова, работяги!

Если очень коротко: хорошая архитектура — это высокая связность внутри модулей (cohesion) и низкая связанность между ними (coupling). Эти два термина отлично объясняют, почему код либо живёт годами, либо рассыпается от каждого чиха.

В оригинале различить их достаточно просто, но вот в переводе… связанность и связность… Если у вас есть дефекты речи или вы просто устали к концу дня, то готовьтесь к сумбуру. Поэтому я обычно использую другой перевод:
— Cohesion — Связность
— Coupling — Сцепленность

Связность (Cohesion) 🧲
— Насколько сильно и «по делу» связаны части внутри модуля/компонента.
— Высокая связность = модуль делает одну понятную вещь.
— Сигнал проблемы: описываете модуль через «и-и-и» — «карточка товара грузит, форматирует цену, читает локаль и отправляет аналитику».

Сцепленность (Coupling) 🔗
— Насколько сильно модуль зависит от других.
— Низкая сцепленность = модуль знает только минимально необходимое о внешнем мире.
— Сигнал проблемы: изменение структуры store/API ломает полприложения.

Пример 🍿

Плохо: низкая связность + высокая сцепленность

function ProductCard({ id }: { id: string }) {
  const [product, setProduct] = React.useState<any>(null);

  React.useEffect(() => {
    fetch(`/api/products/${id}`)
      .then(r => r.json())
      .then(setProduct);

    window.analytics.track('view_product', { id });
  }, [id]);

  if (!product) return <>Loading...</>;

  const currency = localStorage.getItem('currency') || 'USD';
  const priceText = new Intl.NumberFormat('en', { style: 'currency', currency })
    .format(product.price);

  return (
    <div>
      <img src={product.image} />
      <div>{product.name}</div>
      <div>{priceText}</div>
    </div>
  );
}

— Компонент делает всё: загрузка, форматирование, аналитика, работа со storage, UI.
— Жёсткая привязка к fetch, analytics, localStorage, Intl и структуре product.
— Любое внешнее изменение тянет правки сюда.

Хорошо: высокая связность + низкая сцепленность

type Product = { id: string; name: string; image: string; price: number };
type ProductApi = { getById(id: string): Promise<Product> };
type CurrencyFormatter = (currency: string, amount: number) => string;

function ProductCardView({ product, priceText }: { product: Product; priceText: string }) {
  return (
    <div>
      <img src={product.image} />
      <div>{product.name}</div>
      <div>{priceText}</div>
    </div>
  );
}

type Props = {
  id: string; api: ProductApi; currency: string; formatPrice: CurrencyFormatter;
}

function ProductCard({ id, api, currency, formatPrice }: Props) {
  const product = useProduct(id, api);

  if (!product) return <>Loading...</>;

  const priceText = formatPrice(currency, product.price);

  return <ProductCardView product={product} priceText={priceText} />;
}

— ProductCard оркестрирует UI конкретной карточки (высокая связность).
— Зависимости приходят снаружи: api, formatPrice, currency (низкая сцепленность).
— Легко подменять реализации.

Опасные виды сцепленности на фронте 🛑
— Компонент знает «внутренности» ответа бэкенда и лезет в deeply.nested.a.b.c.
— Временная: функция/эффект B должна вызываться строго после функции/эффекта A (завязка на порядок эффектов).
— Прямое использование window, document, localStorage прямо в компоненте.
— Зависимость от окружения: компонент «знает», что он в проде/тесте.

Как снижать coupling и повышать cohesion 🛠
— Интерфейсы и адаптеры: компоненту нужен api.getById, а не fetch/axios.
— DI через props/context: прокидывайте зависимости сверху.
— Разделяйте UI и данные: View без побочек, отдельные сервисы для данных и бизнес-логики.
— Избегайте «utils.ts на 1000 строк»: маленькие тематические модули (price/strings/date).

...продолжение

Как понять, что связность низкая? 🔍
— Трудно назвать модуль одним коротким предложением.
— Слишком много зависимостей «на всякий случай».
— Тесты громоздкие: чтобы проверить одну вещь — поднимаете полприложения.

Как понять, что сцепленность высокая? ⚠️
— Изменение структуры ответа API ломает десяток компонентов.
— Нельзя протестировать без реального network/localStorage.
— Переезд на другую библиотеку (http, стейт) требует массовых правок.

Мне очень нравится идея Ларри Константина: «Попытка разбиения на части модуля, обладающего связностью, приведёт лишь к увеличению степени связанности кода и снизит его удобочитаемость».

Итого 🧾
— Высокая связность = модуль делает одну вещь и делает её хорошо.
— Низкая сцепленность = модуль знает минимум о внешнем мире и легко заменяет зависимости.

Хорошое решение для снижения coupling - Dependency Injection. Интересно ли вам почитать про DI?

Зачем разработчику комьюнити, если есть книги и YouTube? 🧠🤝

Когда я начинал, думал: все знания — из книг, статей и, в крайнем случае, с YouTube. На старте это правда: базу, язык, фундамент и метанавыки удобнее всего качать именно так - много проверенной информации, которую ты можешь быстро достать.

Но у этого пути есть предел — актуальность. Для фундаментальных вещей книги — мой топ-1. А вот для новых технологий, библиотек, подходов и каких-то «затычек» в решениях, исследованиях лучший источник оказался другой — общение с людьми. Комьюнити, митапы, конференции, кулуарные разговоры после докладов. Самые яркие инсайты за последний год-два я получал именно там.

Плюсы комьюнити:
— Актуальные практики «как делают сейчас», а не год назад - книги пишутся не один день
— Контекст решений: почему сработало и какие компромиссы приняли - часто в статьях упускают важные для вашего кейса детали
— Быструю обратную связь и проверку гипотез
— Контакты, которые помогают с карьерой и проектами - сейчас всё чаще слышу про этот плюс

Может показаться, что чтобы начать погружаться в сообщество необходимо покупать дорогущий билет на крутую конфу (тоже хороший вариант, там еще и доклады интересные😏), но начать можно с ваших локальных сообществ, митапов, либо с формата, который организуют ребята из mindbox — Frontend Speed Dating.

7 октября ребята проводят вечер коротких онлайн-знакомств для фронтенд разработчиков - формат позволяет найти единомышленников, которые решают такие же проблемы, как и вы, познакомиться и после уже продолжить общаться, обсуждать решения и делиться опытом.

📅 Когда: 7 октября

⏰ Во сколько: 19:00–20:30 по мск

📍 Где: Zoom (ссылку пришлём после регистрации)

Зарегистрироваться

Здарова, работяги!

Помню как еще в свой первый год работы в Яндексе учавствовал в создании задач для Yandex Cup. Очень рад, что соревнование не просто продолжает проводиться, а с каждом годом становится все масштабнее и масштабнее. В этом году пройдет уже восьмой международный чемпионат по программированию

Общий призовой фонд в этом году составит 12 миллионов рублей!

Этапы Yandex Cup 2025:
• 20-29 октября — пробный тур для знакомства с платформой и задачами
• 2 ноября — квалификация, где будут определены 180 финалистов
• 5-7 декабря — финал и церемония награждения в Стамбуле

Призы в направлении Фронтенд:

1 место — 500 000 ₽
2 место — 400 000 ₽
3 место — 300 000 ₽
4 место — 200 000 ₽
5 место — 100 000 ₽

Лучшие участники направления смогут по упрощенной схеме пройти собес в компанию и получить офер

Регистрация открыта до 29 октября: тык👈

<Activity></Activity>

Здарова, работяги!

Наконец-то я добрался до докладов с React Conf 2025.

Писать про React Foundation и т. д. я не буду, тк не гадалка. Поживем увидим, к чему это приведет. А вот с фичами давайте разберемся.

Начнем с компонента Activity.

В чем его суть: позволяет скрывать и восстанавливать кусочек интерфейса (компонент со всеми его дочерними), сохраняя внутреннее состояние и «останавливая» срабатывание эффектов, предварительно вызвав cleanup.

Что это нам даёт?

Возможность скрывать элементы без потери состояния — самый базовый кейс. Актуально для вкладок, сайдбаров и подобного. Доклад, да и док, пестрит подобными примерами. Суть в том, что в отличие от условного рендеринга стейт при таком скрытии сбрасываться не будет, поэтому при повторном показе пользователь сможет продолжить с того места, где он остановился.

Возможность заранее рендерить кусочек интерфейса — уже более интересный кейс. Если компонент Activity скрыт во время первоначальной отрисовки, его дочерние элементы не будут видны на странице. Но! Самое важное! Они всё равно будут рендериться. У меня было тут два основных опасения: влияние на перф и фоновые эффекты. Но эти моменты продумали: приоритет рендеринга у таких элементов ниже, чем у видимых, а эффекты в них не будут срабатывать.

Сегментация для выборочной гидрации — пожалуй, самое интересное. Selective Hydration позволяет сократить ожидание интерактивности интерфейса — пользователь может быстрее жать на нужные кнопочки. Раньше для разделения дерева на независимые части вы, скорее всего, использовали Suspense, но его использование только для селективной гидрации будет порождать моргания плейсхолдера. Activity лишен этого косяка, но также позволяет выделить независимые части, гидрацию которых можно либо отложить, либо ускорить.

Но! Есть и подводные камни.

Всё, что вы не очистили в cleanup (таймер, интервал, видос, аудио, iframe и т. д., и т. п.) после скрытия может продолжать жить «в фоне» — ждите проблем. Так, например, интервал, обновляющий локальный стейт, продолжит это делать и в скрытом состоянии, а после показа элемента вы увидите последствия его скрытой работы, т. к. стейт при скрытии/показе не сбрасывается.

Может возникнуть вопрос: «А почему не использовать для скрытия css???»

Жизненный цикл и эффекты
- CSS: компонент остаётся смонтирован, эффекты продолжают работать.
- Activity: перед скрытием выполняется cleanup; эффекты «спят», пока поддерево скрыто.

Рендер/перформанс
- CSS: скрытая часть конкурирует за ресурсы как обычно; планировщик React это не учитывает.
- Activity: скрытому поддереву назначается низкий приоритет; можно безопасно пререндерить его в фоне, не мешая видимому UI.

Гидрация/SSR
- CSS: не даёт границы для выборочной гидрации — гидрируется всё как обычно.
- Activity: формирует сегменты для Selective Hydration — можно откладывать/ускорять гидрацию скрытых частей.

Итого: штука интересная, кейсов применения много, посмотрим, как будет использоваться.

#тимлидство

Здарова, работяги!

Вот и прошел ещё один модуль обучения - накопилось много материалов и инсайтов по управлению изменениями. По традиции, делюсь коротким обзором: что нового пройдено, какие идеи показались самыми полезными, а с чем еще предстоит разобраться.

Темы модуля:

1. Модели и подходы к управлению изменениями:
Модель Джона Коттера, ADKAR, Липитт-Кностер - разобрали разные схемы, как запускать и закреплять перемены в команде. ADKAR даже уже попробовал на практике - штука рабочая. Также на TeamLeadConf (отдельный пост напишу) обсуждал эти модели с лидами из других компаний - многие активно применяют, поэтому советую обратить внимание на эти модели, если еще не знакомы.

2. Иммунитет к изменениям:
Почему опытные команды иногда саботируют даже здравые решения, какие глубинные убеждения включают "внутреннего луддита", и как это раскрывать через честные диалоги и спецтехники. Важный инсайд - в каждом из нас живёт свой маленький "хранитель стабильности", важно научиться распознавать, когда он беспокоится по делу, а когда просто - "Раньше было лучше!".

3. Культура открытости и Growth Mindset:
Фиксированное мышление vs Мышление роста - почему мышление роста - это не модный термин, а прямой драйвер для внедрения инноваций. Про осознанность, честный фидбек, безопасную среду, где можно ошибаться, учиться и цепляться за новые возможности.

4. Стратегические и тактические изменения:
Осваивали подходы от малых изменений (incremental), которые делают развитие постоянным процессом, до "больших шагов" и трансформирующих поворотов - когда нужно не просто подкрутить процессы, а серьезно заняться "краксом" (узловой проблемой) (об этом много написано у Ричарда Румельта).

5. Работа с сопротивлением:
Практики работы с группами и стейкхолдерами: как выявлять скрытые страхи, строить коалиции и находить быстрые победы, чтобы команда шла за тобой.

Практика
Особое внимание уделили практике моделей ADKAR и Коттера, что очень помогло быстро начать использовать их в своей работе.

В сухом остатке:
- ADKAR и Коттер действительно рабочие вещи, а не просто сказки седого старца - поэтому обязательно изучаем.
- Ритуалы, артефакты, честная коммуникация, быстрая обратная связь и маленькие победы - must have для любой трансформации.
- И не будьте луддитом, старайтесь быть открытым новому, но не забывайте про критическое мышление - тут важен баланс. Особенно это актуально в текущее время, чтобы балансировать между фанатиками и старообрядцами и внедрять действительно полезные улучшения в области ai.

А теперь вопрос вам: какие перемены реально запускали у себя, где было самое сильное сопротивление, и что реально помогло? Делитесь инсайтами, рецептами и фейлами 👇

ELIMINATING WATERFALLS

🔴 CRITICAL Impact (2–10× улучшение)

Promise.all() для независимых операций
Самое базовое и важное правило — параллелизация независимых операций

❌ Неправильно (3 round trips):

const user = await fetchUser()
const posts = await fetchPosts()
const comments = await fetchComments()

✅ Правильно (1 round trip):

const [user, posts, comments] = await Promise.all([
  fetchUser(),
  fetchPosts(),
  fetchComments()
])

Мои мысли: Логичное уменьшение критического пути за счёт параллельного старта всего, что не зависит друг от друга. Важно помнить: правило применимо только к независимым запросам. Если при падении одного запроса вы всё равно можете продолжать работу — используйте Promise.allSettled().

---

Не допускайте waterfall-цепочек в API routes
Критично для серверного кода — запускайте независимые операции сразу

❌ Неправильно (config ждёт auth, data ждёт обоих):

export async function GET(request: Request) {
  const session = await auth()
  const config = await fetchConfig()
  const data = await fetchData(session.user.id)
  return Response.json({ data, config })
}

✅ Правильно (auth и config стартуют одновременно):

export async function GET(request: Request) {
  const sessionPromise = auth()
  const configPromise = fetchConfig()
  const session = await sessionPromise
  const [config, data] = await Promise.all([
    configPromise,
    fetchData(session.user.id)
  ])
  return Response.json({ data, config })
}

Мои мысли: В серверных хендлерах waterfall особенно дорогой, поэтому здесь критично отслеживать такие цепочки. Обязательно следите за неймингом промисов: в подобных кейсах код легко превращается в кашу, и поддерживать его становится сложно.

---

Dependency-based parallelization
Продвинутая параллелизация — максимизация параллелизма при частичных зависимостях

❌ Неправильно (profile ждёт config без причины):

const [user, config] = await Promise.all([
  fetchUser(),
  fetchConfig()
])
const profile = await fetchProfile(user.id)

✅ Правильно с better-all (config и profile параллельно):

import { all } from 'better-all'

const { user, config, profile } = await all({
  async user() { return fetchUser() },
  async config() { return fetchConfig() },
  async profile() {
    return fetchProfile((await this.$.user).id)
  }
})

✅ Альтернатива без библиотеки:

const userPromise = fetchUser()
const profilePromise = userPromise.then(user => fetchProfile(user.id))

const [user, config, profile] = await Promise.all([
  userPromise,
  fetchConfig(),
  profilePromise
])

Мои мысли: Мне ближе вариант без библиотеки — минимум магии и максимум профита. Библиотека может повышать «выразительность», но, как по мне, читаемость часто становится хуже.

🟡 HIGH Impact

Defer await until needed
Условная оптимизация — await только там, где данные реально используются

❌ Неправильно (всегда загружает permissions):

async function updateResource(resourceId: string, userId: string) {
  const permissions = await fetchPermissions(userId)
  const resource = await getResource(resourceId)

  if (!resource) {
    return { error: 'Not found' }
  }

  if (!permissions.canEdit) {
    return { error: 'Forbidden' }
  }

  return await updateResourceData(resource, permissions)
}

✅ Правильно (permissions грузим только если ресурс найден):

async function updateResource(resourceId: string, userId: string) {
  const resource = await getResource(resourceId)

  if (!resource) {
    return { error: 'Not found' }
  }

  const permissions = await fetchPermissions(userId)

  if (!permissions.canEdit) {
    return { error: 'Forbidden' }
  }

  return await updateResourceData(resource, permissions)
}

Простой пример с early return:

// ❌ Неправильно
async function handleRequest(userId: string, skipProcessing: boolean) {
  const userData = await fetchUserData(userId)

  if (skipProcessing) {
    return { skipped: true }
  }

  return processUserData(userData)
}

// ✅ Правильно
async function handleRequest(userId: string, skipProcessing: boolean) {
  if (skipProcessing) {
    return { skipped: true }
  }

  const userData = await fetchUserData(userId)
  return processUserData(userData)
}

Мои мысли: Всё просто: если что-то можно не делать — не делайте. Либо выполните что-то более полезное, либо просто сэкономьте ресурсы. Это правило применимо во множестве ситуаций, а не только в React/фронтенде.

---

Strategic Suspense boundaries
UI-оптимизация — layout показывается сразу, данные грузятся внутри

❌ Неправильно (весь layout ждёт данные):

async function Page() {
  const data = await fetchData() // блокирует всю страницу

  return (
    <div>
      <div>Sidebar</div>
      <div>Header</div>
      <div>
        <DataDisplay data={data} />
      </div>
      <div>Footer</div>
    </div>
  )
}

✅ Правильно (Sidebar/Header/Footer сразу; ждёт только DataDisplay):

function Page() {
  return (
    <div>
      <div>Sidebar</div>
      <div>Header</div>
      <div>
        <Suspense fallback={<Skeleton />}>
          <DataDisplay />
        </Suspense>
      </div>
      <div>Footer</div>
    </div>
  )
}

async function DataDisplay() {
  const data = await fetchData() // блокирует только этот компонент
  return <div>{data.content}</div>
}

✅ Продвинутый вариант (несколько компонентов используют одни данные):

function Page() {
  const dataPromise = fetchData() // стартует сразу, но не await

  return (
    <div>
      <div>Sidebar</div>
      <div>Header</div>
      <Suspense fallback={<Skeleton />}>
        <DataDisplay dataPromise={dataPromise} />
        <DataSummary dataPromise={dataPromise} />
      </Suspense>
      <div>Footer</div>
    </div>
  )
}

function DataDisplay({ dataPromise }: { dataPromise: Promise<Data> }) {
  const data = use(dataPromise)
  return <div>{data.content}</div>
}

function DataSummary({ dataPromise }: { dataPromise: Promise<Data> }) {
  const data = use(dataPromise)
  return <div>{data.summary}</div>
}

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

Здарова, работяги!

В этой послепраздничной суете, планированиях и т. д. я совсем забыл выложить пост про «Я люблю фронтенд».

Для меня эта конфа — одна из любимых. И не только потому, что Яндекс, но и потому, что это одна из первых фронтендерских конференций, на которые я вообще попал. Поэтому стараюсь её не пропускать — как и в этот раз.

У ребят всегда всё хорошо с организацией: много весёлых активностей и бодрые доклады.

В этот раз конференция пройдёт 14 февраля — дата достаточно символическая))) Регистрация ещё открыта, так что советую поспешить.

Если будете там — пишите, буду рад пообщаться в перерыве между докладами)

Здарова, работяги! 🤖

В одном из прошлых постов мы начали разбирать AI-скилы правильного использования реакта. Но про сам ai я так ничего и не написал. Я долго думал об, надо или нет, вроде мы тут больше про фронтенд и т. д. Пришел к следующей мысли - на текущий момент я уже слабо представляю современную фронтенд, да вообще любую разработку без ai. И нет, я не хочу сказать, что теперь ai наше всё и т. п. Можно ли жить без него? «Можно, а зачем?» Зачем пытаться упираться гнать на велосипеде, если соседи уже освоили машину. Чтобы ноги были сильные? Для этого есть тренажерный зал, можно кататься в парке и т. д. А в вопросах эффективности/КПД логика иная. Машина просто в большинстве кейсов будет быстрее велосипеда. Давайте разверну мысль подробнее...

Начну с признания - я активно использую агентов и прочее. Использую как в тимлидстве, программировании, так и в быту - приготовление еды(это топ), спорт(спасибо за подбор струн на ракетку), питание(да, я составляю рацион через ИИ, анализы стали лучше). Учитывая такой разброс кейсов, я не могу ограничиться только одним примером/сравнением/иллюстрацией. Поэтому будет два)))

1. ИИ = универсальный язык общения с миром. Мы привыкли, что иностранный язык — это английский, французский и т. д. Но на самом деле для многих разговор юристов, инженеров на русском по кол-ву понятых слов аналогичен разговору иностранцев. Что уже говорить про язык программирования и т. д. Чем тут интересен ИИ? По моему мнению, он стирает этот барьер. Теперь вы можете общаться с миром на нативном именно вам языке(с вашим контекстом) - объяснить что-то машине, получить перевод сложного документа на понятном именно вам языке и т. д. В моих глазах это революция. Очень похоже на переход от языков низкого уровня к языкам высокого. Но помните, что «переводчик» еще учится и иногда сочиняет.

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

Является ли ИИ серебрянной пулей? Не, конечно. Но и отрицать прогресс, считаю, смысла нет. Просто старайтесь применять голову, развивайте критическое мышление, будьте дотошными, перепроверяйте инфу и т. д. Помните, что ответственность несете вы: следовали советам ИИ в готовке и суп получился соленым? Да, пересолили именно вы))) С кодом аналогично.

Ну и во всей этой суматохе, как всегда, очень важен опыт, поэтому для меня сейчас особенно становятся актуальны конфы про ИИ, т. к. там можно после докладика поспрашивать спикера, подискутировать и т. д. Считаю, в текущих условиях это топ один источник инфы, т. к. очень всё молодо-зелено. В ближайшее время планирую посетить AI Dev Day, он пройдет уже 15-го числа, но там нужно регаться, поэтому не затягивайте. Если будете там — пишите, буду рад поделиться опытом)

В каком лагере вы? Делитесь опытом в комментах.

Здарова, работяги!

Подъехали интересные бенчмарки 🤖, советую поизучать. Особенно актуально для активных пользователей курсора и подобного.

А какие модели/связки-моделей используете вы в своей работе?

Cursor написали в своём блоге о том, как отслеживают качество моделей в написании кода. Они используют гибридный онлайн-офлайн процесс.

Оффлайн — это обычный бенчмарк на внутреннем наборе тестов, основанном на сессиях работы инженеров компании. В среднем решение требует гораздо больше строк кода в решении, нежели публичные бенчмарки: изменение 352 строк в ~8 файлах.

Сравнение с другими бенчмарками приведено на второй картинке — откуда также видно, что входное описание куда короче других бенчмарков, то есть в промпте не прописывают каждую маленькую деталь (но детали прописаны в рубрике для автоматической проверки).

Онлайн-часть — это контролируемый анализ на реальном живом трафике. Такие онлайн-оценки помогают выявлять регрессии, например, когда результат работы агента выглядит правильным для проверяющего, но воспринимается хуже самим разработчиком, использующим продукт.

Онлайн-оценка позволяет измерить, действительно ли улучшения помогают разработчикам на практике. Cursor отслеживают набор высокоуровневых прокси-метрик (косвенных показателей) результативности агента на основе действий пользователя.

Онлайн и офлайн бенчмарк очень скоррелированы и имеют одинаковое ранжирование моделей (третья картинка) — в топе GPT-5.4, чуть ниже Opus 4.6 на уровне с GPT-5.2, а собственная модель компании Composer 1.5 обходит Sonnet 4.5 (при том что она гораздо быстрее за счёт инференса на чипах Cerebras).

Приятно удивлён, что пользователи Cursor так высоко оценивают модели OpenAI — но ещё здорово и то, что они требуют меньше токенов для решения задач.

Задачи CursorBench решаются в рамках одной сессии, но компания ожидает, что в течение следующего года подавляющее большинство задач по разработке будет передано агентам с длинным горизонтом планирования, работающим на своих собственных мощностях где-то в облаке — и бенчмарк придётся адаптировать к этому.

Здарова, работяги!

Сегодня принес полезный материал для тимлидов и сочувствующих. Уже совсем скоро пройдет митап Dream Teamlead.

Не на каждой конфе набирается такой бодрый набор спикеров, как тут. Особенно хочу отметить:

• Евгений Антонов(Тимлид Очевидность) — читаю его канал(@general_it_talks), слушаю подкаст — всем рекомендую, очень крутые материалы.

• Александр Поломодов — один из лучших каналов(@book_cube) на русском языке(по моему скромному мнению). Рекомендую не только лидам, но и инженерам. Огромное кол-во материалов про лидерство, систем-дизайн, AI и т. д.

По традиции, если будете там и захотите пообщаться — пишите в лс

Композер 2 только вышел, и уже угодил в скандал. Пупупум....

Похоже Composer 2 — это украденная Kimi 2.5

Сразу после выхода Composer 2 пользователи заметили что модель на эндпоинте называется kimi-k2p5-rl-0317-s515-fast, а чуть позже пошли (ныне удалённые) шокированные твиты от команды Kimi — по их словам они ничего не знали об использовании Cursor их весов. И раньше ходили слухи что оригинальный Composer был основан на китайской модели — GLM 4.6, так что прецедент такого "ребрендинга" есть, но там ситуация отличается.

Дело в лицензии — если GLM лицензирована по MIT, то у Kimi 2.5 лицензия более сложная — подобные к лицензии MIT права она даёт только до 100 миллионов пользователей продукта или 20 миллионов выручки в месяц. То есть тюн GLM не нарушал лицензию оригинальных весов, а тюн Kimi — нарушает.

Ситуацию обостряет конфликт Anthropic с авторами Kimi — компания обвиняет Moonshot в использовании более чем 3.4 миллионов запросов для дистилляции. Возможно руководство Cursor решило, что из-за собственных проблем с данными, Moonshot не отважится подать на них в суд и им за это ничего не будет.

Достаём попкорн и наблюдаем за ситуацией

@ai_newz

Здарова, работяги!

У меня сложилось впечатление, что в сообществе есть определённая путаница на тему мемори-банков, рулсов, MCP и скиллов. Поэтому сегодня хочу поговорить с вами именно на эту тему.

Начнем с определений.

Memory bank — это внешняя память агента о проекте или пользователе.
Туда обычно кладут долгоживущий контекст: архитектурные решения, договорённости, особенности проекта, вкусы команды, важные факты, которые агент должен помнить между сессиями.
По сути, это способ не объяснять одно и то же заново в каждом чате.
Memory bank как “папка с простынями контекста, которую агент должен перечитывать перед работой” — почти устаревший паттерн.

Rules / рулсы — это инструкции для агента, которые задают рамки его поведения.
Например: “используй только pnpm”, “не трогай файлы миграций”, “компоненты называем через PascalCase”, “перед изменением API сначала предложи план”.

MCP — это протокол, через который агент подключается к внешним инструментам и данным.
Например, к GitHub, Jira, Figma, базе данных, Sentry, файловой системе, внутренним сервисам компании.
MCP превращает агента из “чата, который умеет писать текст” в участника рабочего процесса, который может ходить в нужные системы и получать оттуда контекст.

Skills / скиллы — это переиспользуемые сценарии работы агента под конкретные задачи.
Например: “как делать code review”, “как заводить новый пакет в монорепе”, “как писать тесты в этом проекте”, “как оформлять PR”.

Если совсем коротко:
Memory bank хранит контекст.
Rules задают правила поведения.
MCP даёт доступ к инструментам.
Skills описывают рабочие сценарии.

Использовать агента без них сейчас нет совершенно никакого смысла, качество его работы драматически падает без них. Но нужны ли прям все эти инструменты?
Сейчас всё больше фокус смещается в сторону связки rules и skills.

Rules играет роль закона: они всегда в силе и задают рамки, которые агент не должен нарушать. Агент держит их в контексте всегда.

Skills работают как инструменты: агент знает, что они есть и когда их применять, но не держит их целиком в контексте постоянно.
Нужен code review — достал skill для review.
Нужно завести новый пакет — достал skill для этого сценария.

Окей, с теорией разобрались. Давайте попробуем теперь написать алгоритм выбора инстурмента.

Я бы шёл в таком порядке.

1. Сначала линтеры, форматтеры, тесты, типы и скрипты
Если правило можно проверить автоматически, лучше проверять его автоматически. Не надо забивать микроскопом гвозди.
Линтер не забудет, не потратит токены и не начнёт “творчески интерпретировать” инструкцию.

2. Потом skills
Если речь не про жёсткую проверку, а про сценарий действий, лучше оформить это как skill.
Например: как делать code review, как заводить новый модуль, как расследовать падение CI, как готовить релиз.
Skill хорош тем, что не висит в контексте всегда. Агент знает, когда его доставать, и подтягивает подробную инструкцию только под конкретную задачу.

3. И только потом rules
Rules стоит использовать для того, что должно ограничивать агента всегда и не может быть надёжно выражено через автоматику или skill.
Они самые дорогие, потому что постоянно занимают место в контексте и влияют на каждую задачу, даже если конкретно сейчас это правило не нужно.

Резюмируя
• Если можно зашить в автоматику — зашиваем в автоматику.
• Если это сценарий — пишем skill.
• Если это постоянный инвариант, который агент обязан помнить всегда — пишем rule.

Итого
Не надо пытаться засунуть весь контекст проекта в одно место. Чем точнее вы раскладываете знания по слоям, тем стабильнее и дешевле работает агент.

Интересно ли вам было бы почитать про то, как я пишу скиллы для своих проектов, какие там есть фишки и особенности?

Здарова, работяги!

В прошлый раз разобрались, чем отличаются memory bank, rules, MCP и skills, и сошлись на том, что основной фокус сейчас — связка rules + skills. Сегодня — как я пишу скилы: что стоит оформлять, что нет, и на что обращать внимание.

Коротко напомню разницу

Rules — правила, которые агент держит в контексте всегда и применяет на каждой задаче.
Skills — переиспользуемые сценарии. Агент знает, что они есть и когда их доставать, но не держит целиком в контексте.

Две главные мысли

Первая: если проблему можно решить не скилами и не рулами — решаем не скилами и не рулами.
Линтеры, форматтеры, тайпчек, скрипты, кодгены — надёжнее и дешевле любого guidance. Не забывают, не жгут токены, не интерпретируют инструкцию творчески. Скилы и рулы — это то, к чему приходим, когда автоматикой уже не получается.

Вторая: скилы не пишем впрок.
Отношусь к ним как к коду — пишу по мере необходимости. Со временем набирается своя база, и появляется чувство:
• какие скилы я всегда тащу в новый проект, потому что они проверены опытом;
• какие подключаю ситуативно — например, для React-проекта имеет смысл взять скилы Vercel про React(но не все);
• какие пишу с нуля под конкретные грабли, которые увидел в работе агента.

Скилл «на будущее» обычно не попадает в реальные сценарии и просто висит балластом. А если их много, агент хуже выбирает нужный и описания начинают конфликтовать. Поэтому: увидел поведение, которое не устраивает → если ответ «скилл», только тогда написал.

Алгоритм: что делать, когда хочется добавить guidance

1. Это уже покрыто? Существующий skill, rules, системный промпт, линтер. Если да — обновляю существующее, а не плодю новое.
2. Можно ли решить тулзами? Линтер, тайпчек, скрипт, кодген. Если правило детерминированное — заводим автоматику. Скилл тогда максимум объясняет, что делать поверх тулзы.
3. Это всегда или ситуативно? Всегда и на каждой задаче — rule. Под конкретный тип задач (ревью, новый пакет и тд) — skill.

Как писать сам скилл

Description — самое важное. Агент видит только description в списке доступных скилов и по нему решает, доставать его или нет. Должно быть два блока:
• WHAT: что скилл делает.
• WHEN: триггеры — слова, контексты, типы задач.
Плохо: «помогает с тестами».
Хорошо: «как писать тесты в проекте. Используй при написании, добавлении или рефакторинге test-файлов. Триггеры: ‘написать тест’, ‘покрыть тестами’, ‘тесты падают’».
SKILL.md держу коротким. Ориентир — до 100 строк. Что не влезает — выношу в отдельные файлы и линкую из основного. Глубже одного уровня ссылок не делаю — агент может просто не дочитать.
Прогрессивное раскрытие. В SKILL.md — то, что нужно в 80% случаев. Детали и редкие сценарии — в отдельные файлы.
Один путь, а не пять вариантов. Если в скиле «можно вот так, или вот так» — агент каждый раз выбирает заново и каждый раз по-разному. Даю дефолт и явный запасной вариант для редких случаев.
Конкретные примеры. «Вот вход, вот выход» работает в разы лучше, чем абзац объяснений.
Скрипты вместо генерации. Детерминированную операцию лучше положить готовым скриптом и вызвать, чем описывать «сгенерируй такой-то код». Скрипт надёжнее и не жрёт токены на генерацию.

Резюме
• Сначала пробуем тулзы, потом скилы, в последнюю очередь — rules.
• Скилы не пишем впрок, только по факту.
• В самом скиле: подробное description с WHAT и WHEN, короткий SKILL.md, один путь, конкретные примеры, скрипты для детерминированных операций.

Скилы — это не документация на все случаи жизни. Это набор маленьких заточенных инструментов под сценарии, которые ты уже видел в работе.

В следующий раз могу показать свою личную подборку скилов — глобальные и те, что чаще всего беру в новые проекты. Интересно?