Higgsfield выпустили плагин для Photoshop

Теперь можно:

– Превращать скетч в готовое изображение в реальном времени по мере рисования
– Разбирать любое изображение на редактируемые слои
– Менять стиль фотографии через пресеты или текстовый промпт

По сути, весь AI-пайплайн для работы с изображениями теперь находится внутри Photoshop.

higgsfield.ai/plugins/photoshop

Карпатый написал 4 инструкции для Claude Code. Репа набрала 40к звёзд за пару дней

Скилл из четырёх файлов меняет поведение модели: больше планирования, меньше галлюцинаций, аккуратнее код, чаще самопроверка. Андрей формализовал собственный подход к работе с агентами и выложил на GitHub.

Раньше работа с агентом выглядела так: «попросил в чате, получил код, скопировал».

Теперь рабочий цикл другой:

👉 SKILLS.md фиксирует повторяющиеся паттерны: как пишутся миграции, как оформляются ошибки, какие соглашения по логированию
👉 AGENTS.md лежит рядом с кодом и описывает архитектуру директории: что здесь живёт, что нельзя трогать
👉 MCP подключает агента к вики, БД, API-докам через стандартный протокол

За полгода узкое место сместилось с возможностей модели на навыки разработчика. Скиллов нужно освоить много: SPEC-разработка, контекст-инжиниринг, Plan Mode, AGENTS.md под каждую директорию, мультиагентные пайплайны. Собрать всё это в рабочую систему самому займёт примерно год экспериментов.

Команда Naition.ai научит этому за 12 недель на своем онлайн-буткемпе.
Преподают практики из Google, Yandex Cloud, Сбера. 15 живых вебинаров по 3 часа: теория, разбор кейса, практика на своём коде:
• настраиваешь ИИ-окружение под свой стек — RAG, MCP, агенты, контекст
• начинаешь быстрее делать фичи — от идеи до внедрения с ИИ на каждом этапе
• собираешь набор ИИ-агентов, которые берут на себя часть задач (бек, фронт, аналитика, DevOps)
• и много другое!

Записаться

Старт: 5 мая.
По промокоду WEUSEJS — скидка 20%.

Бонус для участников первых когорт: 3 месяца в закрытом клубе после обучения.

Записаться

Команда также собрала бесплатную дорожную карту из 40+ концептов со ссылками на источники. По сути оглавление того, что сейчас составляет базовую инженерную грамотность для работы с AI.
Забрать роадмеп по ссылке

Меня недавно позвали в папку IT On и я согласился почти не раздумывая, потому что давно искал что-то похожее.

Там собраны люди, которые реально шарят в своей теме: разработчики, продакты, основатели стартапов, эксперты по карьере в tech. Каждый пишет про своё и в сумме получается полная картина индустрии.

Читаешь и чувствуешь что находишься внутри IT, а не наблюдаешь снаружи. Разница есть, проверено на себе.

Добавляй папку себе, советую!

Anti-corruption layer на фронте: зачем адаптеры между API и UI

Принято считать, что фронтенд просто берёт данные из API и рисует интерфейс.

На практике это быстрый путь к тому,
чтобы внешний контракт начал диктовать архитектуру UI.

В чём проблема

API почти никогда не совпадает с тем,
как думает интерфейс.

Бэкенд может отдавать:

👉 странные названия полей
👉 лишние вложенности
👉 nullable там, где UI ждёт значение
👉 статусы в формате, удобном серверу, а не экрану

Если тащить это напрямую в компоненты,
UI быстро заражается чужой моделью.

Что делает anti-corruption layer

Он ставит прослойку между API и приложением.

Не компонент получает сырой ответ,
а адаптер превращает его в нормальную фронтовую модель.

function mapUserDtoToUser(dto: UserDto): User {
  return {
    id: dto.user_id,
    name: dto.full_name ?? 'Unknown',
    isAdmin: dto.role === 'admin',
  }
}

Компоненту уже не нужно знать,
как именно бэкенд назвал поле.

Почему это важно

UI становится чище

Компоненты работают с понятной моделью,
а не с набором компромиссов из API.

Изменения API дешевле

Поменялся контракт —
меняем адаптер,
а не ищем user_id по всему проекту.

Меньше бизнес-логики в JSX

Все эти проверки:

user?.profile?.data?.attributes?.name

не должны жить в компоненте.

Компонент должен рендерить состояние,
а не расшифровывать ответ сервера.

Где адаптер особенно нужен

👉 API старое или нестабильное
👉 несколько источников данных
👉 разные форматы одной сущности
👉 сложные статусы и enum
👉 много nullable-полей

Чем грязнее внешний мир —
тем полезнее слой нормализации.

Где можно не усложнять

Если проект маленький,
API стабильное,
а модель почти совпадает с UI —
отдельный слой может быть лишним.

Не нужно строить enterprise там,
где достаточно одной функции рядом с запросом.

Главная мысль

Anti-corruption layer — это не архитектура ради архитектуры.

Это защита UI от чужих компромиссов.

API может быть неудобным, историческим или странным.
Но ваш интерфейс не обязан таким становиться.

⁣CSP, CORS и security headers — что фронтендер обязан понимать глубже

Принято считать, что безопасность — это зона бэкенда.
Фронтенд «просто отправляет запросы и рендерит UI».

На практике фронтенд напрямую влияет на то,
будет приложение безопасным или нет.

CORS — это не про «разрешить запрос»

CORS часто воспринимают как настройку:
«чтобы запросы не падали из браузера».

Но по сути это механизм, который говорит:
кто имеет право читать ответ.

Важно понимать:

👉 сервер может обработать запрос
👉 но браузер может не дать прочитать ответ

Именно поэтому:

👉 Access-Control-Allow-Origin: * — не «фикс», а потенциальная дыра
👉 credentials + wildcard — запрещённая комбинация

CORS — это про контроль доступа, а не про обход ошибок.

CSP — ваш последний рубеж

Content Security Policy — это защита от XSS,
даже если у вас уже есть уязвимость.

Пример:

Content-Security-Policy: default-src 'self'; script-src 'self'

Что это даёт:

👉 запрещает выполнение inline-скриптов
👉 блокирует загрузку скриптов с чужих доменов
👉 режет целый класс атак

Но есть нюанс.

Если CSP выглядит так:

script-src * 'unsafe-inline' 'unsafe-eval'

Это не защита. Это иллюзия.

Security headers, которые реально важны

👉 X-Content-Type-Options: nosniff
Браузер не пытается угадать тип файла. Меньше атак через подмену.

👉 X-Frame-Options / frame-ancestors
Защита от clickjacking.

👉 Strict-Transport-Security (HSTS)
Принудительный HTTPS. Без вариантов.

👉 Referrer-Policy
Контроль того, какие данные уходят при переходах.

Где фронтендер влияет напрямую

👉 какие скрипты подключаются
👉 есть ли inline JS
👉 используются ли eval-подобные вещи
👉 как работают сторонние виджеты
👉 как обрабатываются пользовательские данные

Можно иметь идеальный бэкенд и сломать всё на уровне UI.

Частая ошибка

«Мы включили CSP — значит всё ок».

Но:

👉 нет nonce / hash
👉 разрешены любые источники
👉 подключены сторонние скрипты без контроля

В итоге защита есть только на бумаге.

Главная мысль

CSP, CORS и заголовки — это не чекбокс в настройках.
Это часть архитектуры.

Если фронтенд не понимает, как они работают,
безопасность становится случайностью.

Кошмар вайбкодера

xCode Journal

⁣Isolated declarations — ускорение больших monorepo

В TypeScript есть флаг isolatedDeclarations.

Он нужен не для красоты типов,
а для скорости.

Проблема простая:

в больших monorepo генерация .d.ts
может становиться узким местом.

TypeScript часто должен анализировать соседние файлы,
чтобы понять, какие декларации вывести.

На маленьком проекте это почти незаметно.

На большом — начинает болеть.

Что делает isolatedDeclarations

isolatedDeclarations заставляет писать код так,
чтобы декларации можно было генерировать
по файлам независимо.

Из-за этого TypeScript чаще требует явные типы.

Было:

export function getUser() {
  return { id: 1, name: 'Alex' }
}

Лучше так:

type User = {
  id: number
  name: string
}

export function getUser(): User {
  return { id: 1, name: 'Alex' }
}

Меньше магии для компилятора —
быстрее и предсказуемее сборка.

Почему это важно

Когда проект растёт:

👉 TypeScript начинает сильнее зависеть от соседних файлов
👉 инкрементальная сборка замедляется
👉 генерация типов становится дорогой

Изоляция помогает компилятору работать параллельно и проще.

Где это особенно полезно

👉 большие monorepo
👉 библиотеки
👉 project references
👉 параллельная сборка
👉 CI, где каждая минута стоит денег

Главный trade-off

Ты немного платишь:

👉 более явными типами
👉 меньшим type inference
👉 дополнительным boilerplate

Но взамен получаешь:

👉 более быстрые сборки
👉 стабильный compile pipeline
👉 меньше скрытой сложности

Главная мысль

Это хороший пример взрослого engineering trade-off:
чуть больше явности в коде
ради скорости и предсказуемости системы.

⁣Recursive type limits — почему TS иногда «умирает»

В TypeScript можно написать тип,
который выглядит красиво,
но заставляет компилятор страдать.

Особенно когда начинаются рекурсивные типы.

Например:

👉 глубокий DeepPartial
👉 парсинг строк на уровне типов
👉 сложные conditional types
👉 infer внутри infer

На маленьком примере всё работает.

В реальном проекте IDE внезапно начинает думать по 5 секунд.

Почему так происходит

TypeScript не вычисляет типы «бесплатно».

Каждый:

👉 conditional type
👉 union
👉 recursive шаг

нужно реально посчитать.

А если тип разворачивается слишком глубоко,
компилятор упирается в лимиты.

Отсюда знакомое:

Type instantiation is excessively deep
and possibly infinite

И это не всегда баг TypeScript.

Часто это сигнал,
что типовая модель стала слишком умной.

Где обычно всё ломается

Особенно опасны:

👉 рекурсивные mapped types
👉 огромные union’ы
👉 type-level parser’ы
👉 deeply nested generics
👉 utility types поверх utility types

Типы начинают взрываться комбинаторно.

Что обычно помогает

👉 не делать type-level акробатику без нужды
👉 ограничивать глубину рекурсии
👉 разбивать типы на более простые
👉 добавлять явные промежуточные типы
👉 не тащить сложные generic-типы в публичный API

Почему это важно

Сложные типы бьют не только по компиляции.

Они ухудшают:

👉 autocomplete
👉 responsiveness IDE
👉 читаемость кода
👉 onboarding новых людей

Иногда самый дорогой runtime —
это compile time.

Главная мысль

Хороший TypeScript —
это не когда типы поражают воображение.

Хороший TypeScript —
это когда их можно понять через полгода,
а IDE при этом не превращается в обогреватель.