🧠 CodeSpeak — новый язык от автора Kotlin

Интересный анонс: Андрей Бреслав, создатель языка Kotlin, представил новый проект — CodeSpeak (home.codespeak.dev).

В чём идея

CodeSpeak задуман как язык, где вы описываете что вы хотите, а не как это реализовать.
• Используется «человеческий» синтаксис (на английском), из которого система автоматически генерирует код на привычных языках (Python, JS, Kotlin, Swift и др.).
• Если формулировка неоднозначна, инструмент уточняет смысл у разработчика.
• Уже сгенерированный код не затирается полностью — можно улучшать его руками без риска потерять связь со спецификацией.

Зачем это может быть нужно
• 📌 Быстрая разработка прототипов и MVP.
• 📌 Мост между нетехническими специалистами (аналитики, продукт) и разработчиками.
• 📌 Снижение «технического долга» за счёт работы на уровне требований, а не деталей реализации.

Вопросы и риски
• Как CodeSpeak справится с реально сложной бизнес-логикой?
• Что будет с отладкой и интеграцией в существующие проекты?
• Хватит ли точности «человеческого языка» для промышленных систем?

Почему стоит следить

⚡️ Потому что это новый шаг в карьере Андрея Бреслава — человека, который уже создал один из самых популярных языков в мире (Kotlin). Его эксперименты обычно превращаются в тренды для всей индустрии.

👉 Подробнее: home.codespeak.dev

Попался тут под руку любопытный бенчмарк кодинг моделей из Berkeley https://gorilla.cs.berkeley.edu/leaderboard.html.

Он очень совпадает с моими субъективными ощущениями. GLM-4.6 это SOTA. Да, она плохо дизайнит интерфейсы по сравнению с Opus или Sonnet, НО как круто она дебажит и рефакторит код, восторг

🔥 Crush: мой рабочий конфиг для daily-dev
Гист: https://gist.github.com/dpolishuk/3dd1faed27f526eb329e0f0997a55549

Что внутри (кратко):
• MCP-плагины: perplexity-mcp, context7, task-master-ai, nodejs-docs — быстрый ресёрч, общий контекст по проектам и удобные dev-тулы прямо из терминала.
• LSP: gopls + typenoscript-language-server — точнее правки кода и лучшее авто-дополнение.
• Безопасность: whitelist на auto-run инструментов вместо «разрешить всё».
• Отладка: debug: true + логи (crush logs) — прозрачно видно, что делает агент.

Где лежит crush.json:
1. .crush.json в корне проекта → 2) crush.json в проекте → 3) глобально: ~/.config/crush/crush.json (Win: %USERPROFILE%\AppData\Local\crush\crush.json).

Лайфхаки:
✅ Делите MCP на узкие роли — проще дебажить.
✅ Белый список тулов безопаснее «YOLO».
✅ Включайте LSP даже для чтения кода — качество правок растёт.

Использую crush с GLM-4.6 (Моя реф-ссылка на скидку: https://z.ai/subscribe?ic=HRSUIKMMVP)

И давайте делиться сетапами!

🚀 Perplexity MCP теперь ставится в одно касание через Homebrew

У меня в crush.json есть perplexity-mcp. Вот недостающая инструкция как это у себя настроить.
Я использую @Alcova-AI/perplexity-mcp — лёгкий MCP-сервер, который делает Perplexity полноценным агентом прямо внутри Charmbracelet Crush и других MCP-клиентов.
Работает стабильно, без Python-виртуалок и uv — просто ставится и работает.

Сначала идем за ключом сюда https://www.perplexity.ai/settings/api

Потом:

🧩 Установка

brew tap alcova-ai/tap
brew install perplexity-mcp

🔑 Перед запуском нужно выставить ключ API:

export PERPLEXITY_API_KEY="pplx_************************"

и (опционально) выбрать модель:

export PERPLEXITY_MODEL="sonar-pro"


⸻

⚙️ Интеграция с Crush

Добавь MCP-секцию в ~/.config/crush/crush.json:

{
"$schema": "https://charm.land/crush.json",
"mcp": {
"perplexity": {
"type": "stdio",
"command": "perplexity-mcp",
"env": {
"PERPLEXITY_API_KEY": "pplx_************************",
"PERPLEXITY_MODEL": "sonar-pro"
}
}
}
}

Теперь прямо из Crush можно вызывать Perplexity, как родной инструмент MCP — выполнять поиск, аналитические запросы, ресёрч по теме и всё это в общем контексте с другими агентами 🔍🤖

Давно обещал сделать видео о том как я генерирую код по макетам из Figma, а тут еще и Figma Make подъехал! Собственно на видео процесс подготовки макета, копирования шаблона кода и потом claude code по шаблону делает готовый mvp. Видео с бодрящей музыкой, если что

Вы в коментариях пишите про что еще сделать видео. Задавайте вопросы. Пока я планирую сделать видео по настройске claude code и crush с mcp еще

🧪 Playwright Agents: Planner, Generator и Healer — как это работает

https://dev.to/playwright/playwright-agents-planner-generator-and-healer-in-action-5ajh

Недавно вышла статья на DEV, демонстрирующая новую функциональность Playwright Agents (начиная с версии 1.56) — три агента, которые помогают автоматизировать жизненный цикл тестов: Planner, Generator и Healer.

Что делают агенты

Агент Назначение
Planner Генерирует тест-план (набор сценариев, покрытие фичи).
Generator По плану создаёт реальные тестовые файлы.
Healer При сбоях запускает диагностику и пытается «подлечить» тесты.

Как начать
1. Обновление Playwright до версии ≥ 1.56
2. Запуск команды:

npx playwright init-agents --loop=claude

(вместо vscode можно выбрать claude, opencode и др.)

3. Подготовить seed-файл — базовый контекст / фикстуры, которые копируются в генерируемые тесты.
4. В режиме чата VS Code выбрать агента (Planner, Generator или Healer) и отправлять команды вроде “Generate test plan for feature X” или “Fix failing test”.

Преимущества и ограничения

Плюсы:
• Автоматизация рутинных задач в тестировании
• Быстрое покрытие сценариев
• Возможность самостоятельного восстановления тестов при мелких изменениях

Вопросы / моменты, на которые стоит обратить внимание:
• Безопасность: как агенты работают с конфиденциальными данными (логины, ключи)?
• Нужно ли вручную корректировать планы или дописывать сценарии?
• Насколько хорошо Healer справляется в сложных случаях, когда причина сбоя — не просто изменение селектора?

Итог

Playwright Agents — серьёзный шаг в сторону «умного» тестирования: планирование, генерация и лечение тестов почти без участия человека. Но, как и везде с AI, важны контроль, аудит и разумное применение.

Как я сейчас генерирую суб агентов на Claude Code, вот промпт:

could you pls analyze the project and think up sub agents like here https://docs.anthropic.com/en/docs/claude-code/sub-agents. use file format which was specified in this url. use
perplexity. use best practices. always use context7

Этот промпт за счет использования perplexity дает значительно лучший результат и по точности и по актуальности.

В github уже есть такое. Ну короче github тоже пытается конкурировать с lovable, replit, orchids.app и bolt.new. Рынок огромный!

⚙️ Spec-driven development (SDD) с GitHub Spec Kit
GitHub выкатил Spec Kit — open-source тулкит, который ставит спецификацию в центр разработки: сначала описываем что и зачем, и уже по ней ИИ-агенты генерируют план, задачи и код. Это снижает «vibe-coding» и повышает предсказуемость результата.

Почему это важно
— Спека становится «исполняемым артефактом»: единый источник правды для команды и ИИ.
— Работает с любимыми агентами: Copilot, Claude Code, Gemini CLI, Cursor, Qwen и др.

Процесс из 4 фаз
1. Specify → 2) Plan → 3) Tasks → 4) Implement — на каждом этапе есть проверка/валидация, прежде чем двигаться дальше.

Как попробовать (1 мин):

# Инициализация проекта
uvx --from git+https://github.com/github/spec-kit.git specify init my-app

# Дальше — прямо в вашем агенте:
# /speckit.constitution — зафиксировать принципы/гайдлайны проекта
# /speckit.specify — сформировать продуктовую спеку (что/почему)
# /speckit.plan — технический план (стек, архитектура, ограничения)
# /speckit.tasks — разбиение на задачи
# /speckit.implement — выполнение по списку задач

Команды и CLI описаны в репозитории Spec Kit. Лицензия — MIT.

Где особенно заходит
• 0→1: быстрый старт новых проектов без хаоса.
• N→N+1: добавление фич в сложные кодовые базы.
• Legacy-модернизация: перенос логики в современную архитектуру через спеки.

Источник: GitHub Blog и репозиторий github/spec-kit.

SDD: три инструмента — Kiro, Spec-kit, Tessl

Что такое spec-driven development сейчас? Пишем спецификацию до кода, и она становится источником правды для людей и ИИ. Автор выделяет 3 уровня зрелости:
1. Spec-first — спеку пишем перед задачей;
2. Spec-anchored — спеку сохраняем и эволюционируем вместе с фичей;
3. Spec-as-source — редактируем только спеку, код генерится из неё.

Инструменты
• Kiro — самый лёгкий: три артефакта (Requirements → Design → Tasks) в Markdown и «memory bank» (“steering”). Фокус на spec-first под конкретную задачу.
• Spec-kit (GitHub) — CLI + слэш-команды в ассистентах. Пайплайн Constitution → Specify → Plan → Tasks с чек-листами и «конституцией» как общими правилами. На практике пока ближе к spec-first (спеки живут в ветках под изменения), хотя риторика — про «живые» спеки.
• Tessl (private beta) — стремится к spec-anchored / spec-as-source: спеку можно реверс-инжинирить из кода, теги вроде @generate/@test, сборка генерит файл с пометкой // GENERATED FROM SPEC - DO NOT EDIT. CLI также умеет работать как MCP-сервер.

Когда что выбирать
— Быстрые фичи в VS Code → Kiro.
— Командная дисциплина и ассистенты (Copilot/Cursor/и т.п.) → Spec-kit.
— Жёсткая модель «спека = источник кода» → Tessl (экспериментально).

Риски/вопросы: оценка на реальных кодовых базах дорога по времени; brownfield-интеграция у ряда тулов тяжеловата; недетерминизм генерации требует уточнять спеку и стратегию её поддержки. Источник: https://martinfowler.com/articles/exploring-gen-ai/sdd-3-tools.html

Если что я начал работать в Kiro, про свои мысли позже напишу

Percolator: шардированный perp-DEX на Solana — «поигрался с Claude, идею можно воровать»
TL;DR: Толя выложил спецификацию/код эксперимента perp-DEX Percolator на Solana, пишет, что «просто балуется с Claude» и просит «украсть идею» — цель: перенести конкуренцию prop-AMM из spot в perps. Репозиторий уже с тестами и подробным планом (Router + Slabs), но это не анонс запуска.

Ключевая цитата из поста Толи:

«Oh man, I now know @AndreCronjeTech’s pain… I am just messing around with Claude… Pinocchio + surfpool… Pls steal the idea. Хочу проверить, можно ли повторить competition prop-AMM из spot — но для perps.»

Что внутри Percolator (по GitHub):
• Архитектура: Router (маршрутизация, коллатерал, портфельная маржа) + Slab (перп-движки LP, независимые «шарды» ордербуков). Идея — изолировать риски каждого LP-движка, а Router гарантирует атомарную маршрутизацию и неттинг портфеля.
• Статус: «core infra complete», 53 unit-теста проходят, интеграционные тесты — позже (Surfpool). Используются Pinocchio (zero-dep Solana SDK), Rust no_std, сборка под BPF. В планах — ликвидации, funding, anti-toxicity (kill band, JIT-penalty, ARG).

Почему это важно:
• На фоне бурного роста perp-DEX’ов (Hyperliquid/Lighter/Aster) Solana-нейтив дизайн с параллельными «slabs» может дать лучшую конкуренцию среди LP и качество исполнения через селективный роутинг. Даже если это «эксперимент», спецификация implementation-ready стимулирует экосистему пилить боевую версию.

Что можно сделать уже сейчас (для билдеров):
1. Прочитать plan.md и схему Router/Slab;
2. Поднять локальный стенд (Surfpool) и обкатать unit/property-тесты;
3. Прототипировать свой Slab с собственным матчингом/риск-моделью и подключить к Router;
4. Дискуссия по ликвидациям/funding/anti-toxicity — пока открыта.

Ссылки (для поста):
GitHub: https://github.com/aeyakovenko/percolator
Обзор: https://cointelegraph.com/news/solana-founder-new-perp-dex-percolator
Цитата/контекст поста: https://x.com/aeyakovenko/status/1980288468094951799

Видео от создателя GitHub SpecKit как его настраивать и делать проекты https://www.youtube.com/watch?v=a9eR1xsfvHg

Тема: сколько реально стоит запуск и эксплуатация крупнейших компаний в области ИИ или почему у Anthropic такие маленькие лимиты , а про opus 4.1 вообще молчу


Недавно вышла интересная статья на сайте Where’s Your Ed At (https://www.wheresyoured.at/costs/) в которой автор Edward Zitron приводит данные по расходам Anthropic и Cursor на облачную инфраструктуру (конкретно — Amazon Web Services, AWS). Вот ключевые тезисы:

⸻

🔍 Основное
• Anthropic потратила на AWS $1,35 млрд за 2024 год.
• По состоянию на сентябрь 2025 она уже потратила $2,66 млрд только на AWS, тогда как оценочная выручка — около $2,55 млрд, т.е. расходы на AWS за этот период превышают доходы.
• У Cursor, крупнейшего клиента Anthropic, расходы на AWS выросли с ~$6,2 млн в мае 2025 до ~$12,6 млн в июне 2025.

⸻

🧮 Что это значит
• Бизнес-модель масштабного ИИ выглядит всё более рискованной: расходы на облако и инфраструктуру могут расти быстрее, чем доходы.
• Anthropic, по оценке автора, не просто сильно “находится в минусе”, но и вынуждена поднимать цены или менять условия для своих клиентов, чтобы удерживать баланс.
• Для компаний-построителей интерфейсов и сервисов на базе чужих моделей (как Cursor) ситуация становится критичной: если модельный провайдер резко меняет тарифы или условия, “верхний слой” бизнеса вынужден либо быстро реагировать, либо терпеть убытки.

⸻

🎯 Почему это важно для нас
• Если вы работаете или инвестируете в ИИ-стартапы, факт высокой зависимости от облачных расходов — важный сигнал риска.
• Даже крупные игроки с миллиардными раундами финансирования могут оказаться “на грани”, если накладные расходы растут быстрее доходов.
• В перспективе это может означать либо массовый рост цен для конечных пользователей сервисов ИИ, либо массовые “чистки” менее устойчивых компаний.

🛍️ Lovable × Shopify: магазин «с голоса» за минуты

Lovable запустил нативную интеграцию с Shopify: описываете идею — платформа генерирует витрину, карточки, корзину и checkout, после чего вы «забираете» магазин в Shopify и публикуете. Без кода и лишней рутины.

Как это работает
1. Пишете в Lovable: «Собери магазин для …».
2. Генерируются страницы, навигация, продукты и оформление заказа.
3. Нажимаете Claim — магазин переносится в ваш Shopify-аккаунт.
4. Публикация и продажи.

Ограничения и условия
• Сейчас интеграция доступна только для новых магазинов Shopify.
• Работает «песочница» для сборки без затрат на Shopify; при публикации — 30-дневный триал Shopify, дальше — оплачиваемый тариф Shopify.

Кому это зайдёт
• Создателям и брендам — дропы, мерч, подписки прямо из вашего сайта/приложения.
• Фаундерам — валидация идеи с реальным чекаутом и быстрыми итерациями.
• Бизнесам на Shopify — новые «поверхности»: комьюнити-зоны, in-product-магазины, пост-покупочные флоу.

Зачем пробовать
⚡ скорость MVP — от брифа до продающего магазина за минуты;
🧩 опора на экосистему Shopify (платежи, налоги, приложения) + AI-билдер Lovable;
🧱 можно собирать вокруг витрины лендинги, онбординги и post-purchase сценарии.

https://lovable.dev/blog/shopify-integration

А вот и промо в инсте в вертикалке. Ну токенов теперь еще больше будут жрать)

Отличный теперь конткурент orchids.app будет!

🧩 Spec Workflow MCP — SDD в VS Code с апрувами и живым дашбордом

Основные фишки
• Жёсткий поток: Требования → Дизайн → Задачи, артефакты хранятся в .spec-workflow/ (approvals, archive, specs, templates). Есть approval workflow (approve/reject/revision) и прогресс-бары.
• Live-дашборд в браузере и официальное расширение VSCode (панель со спексами, тасками, апрувами, steering-доками, уведомления). ~3,2k установок.
• Мультиязычность (11 языков, в т.ч. русский).

Чем лучше Task-Master (claude-task-master)
• Не просто задачи из PRD, а формальный апрув-гейтинг спеков с историей правок — это помогает команде и стейкхолдерам синхронизироваться до кодинга.
• Из коробки UI: web-дашборд + официальный VSCode-плагин; у Task-Master упор на CLI/IDE-чат, UI решается сообществом (не первый-парти).
• Структура артефактов проекта стандартизирована (approvals/steering/specs/archive) — удобнее аудита и онбординга. У Task-Master — PRD-центричный флоу и набор MCP-тулов (до 36), но без формального approval-цикла.

Как конкурирует с GitHub Spec-Kit
• Оба про SDD, но подход разный: Spec-Kit — CLI/“slash-команды” и методология (Specify CLI /speckit.*, широчайшая поддержка агентов), а Spec Workflow MCP — MCP-сервер + дашборд/VSCode-UI и локальные артефакты.
• По зрелости и охвату Spec-Kit сейчас лидер (≈40.5k ⭐), но в нём нет встроенного дашборда; в блоге GitHub VS Code-интеграции пока обозначены как направление. Spec Workflow MCP берёт UX-ом и процессным контролем внутри IDE.

Быстрый старт

npx -y @pimzino/spec-workflow-mcp@latest /path/to/project --AutoStartDashboard
# VSCode: установите "Spec Workflow MCP" из Marketplace



Когда что брать
• Spec Workflow MCP — если нужны апрувы, единая структура артефактов и наблюдаемость в IDE/веб.
• Task-Master — если цель: быстрый таск-менеджмент с мощным набором MCP-тулов (вплоть до research-модели и модульных наборов инструментов).
• GitHub Spec-Kit — если хотите “референсную” SDD-процедуру и широкую агент-поддержку без отдельного MCP-сервера.

https://github.com/Pimzino/spec-workflow-mcp
http://github.com/eyaltoledano/claude-task-master

⚙️ Claude Code Plugins — кратко и по делу

Что это
Плагины расширяют Claude Code: свои /команды, саб-агенты, Agent Skills, хуки и MCP-серверы. Ставятся из маркетплейсов и шарятся внутри команды.

Структура плагина
• commands/ — ваши /команды
• agents/ — саб-агенты под узкие задачи
• skills/ — Agent Skills (автоподхват по контексту)
• hooks/ — автоматизация на событиях
• .mcp.json — MCP-серверы/инструменты
• .claude-plugin/plugin.json — манифест

Установка и управление

/plugin # открыть менеджер
/plugin marketplace add owner/repo
/plugin marketplace add https://gitlab.com/company/plugins.git
/plugin marketplace add ./my-marketplace
/plugin marketplace add https://url.of/marketplace.json

/plugin install plugin-name@marketplace-name
/plugin enable plugin-name@marketplace-name
/plugin disable plugin-name@marketplace-name
/plugin uninstall plugin-name@marketplace-name

Zero-touch для команды
Добавьте маркетплейсы и нужные плагины в настройки репозитория — у всех подтянется автоматически:

# .claude/settings.json
{
"extraKnownMarketplaces": {
"team-tools": { "source": { "source": "github", "repo": "your-org/claude-plugins" } }
},
"enabledPlugins": ["formatter@team-tools", "dev-tools@team-tools"]
}

Dev-лайфхаки
• Локальная разработка: /plugin marketplace add ./dev-marketplace
• Диагностика и конфликты: claude --debug

Полезное
• https://docs.claude.com/en/docs/claude-code/plugins
• https://docs.claude.com/en/docs/claude-code/plugins-reference
• https://docs.claude.com/en/docs/claude-code/plugin-marketplaces

Скоро выложу свой plugin

#ClaudeCode #Plugins #MCP #DevTools #AICoding

🧠 SDD: как мечта Literate Programming стала реальностью с агентами и ИИ

TL;DR: Идея Дональда Кнута «сначала объясни людям, потом машине» наконец материализовалась: спецификация стала единственным источником правды, а агенты/ИИ превращают её в код, тесты и план. Уже сегодня это видно в GitHub Spec Kit; Андрей Бреслав с CodeSpeak идёт тем же курсом.

Откуда всё началось
• Literate Programming (Д. Кнут): программа — это эссе для людей, где код встроен в повествование. Цель — ясность мысли и структуры, удобной человеку.

Почему получилось именно сейчас
• Появились агенты и ИИ, способные брать спеку как вход, уточнять неоднозначности и выдавать готовые артефакты: код/тесты/план задач. Спека живёт рядом с кодом в репозитории (spec-as-code) и не «протухает».

Что уже умеет GitHub Spec Kit (впечатляет):
• Процесс Specify → Plan → Tasks → Implement с CLI и шаблонами.
• Хранение спецификаций в репо, трассировка требований → задач → PR’ов.
• Работа в паре с AI для генерации каркасов и изменений.
• Переход от «вайб-кодинга» к предсказуемому циклу по спекам.

Как попробовать уже сегодня
1. Введите spec-as-code: docs/*.spec.md рядом с исходниками.
2. Пишите фичи как исполняемые требования: цели, контекст, API/схемы, acceptance criteria (Given-When-Then).
3. Пройдите цикл Specify → Plan → Tasks в Spec Kit, генерируйте каркасы/PR’ы агентом — ревью остаётся за вами.

Очень много появляется новых фреймворков в SDD, посмотрите в claude code marketplaces и на github по запросу