КайфКодинг

Сделал серию майнкрафт медитаций для сына.

Попробую сделать mini app из этого

https://suno.com/s/IoF0Ql0qORQJW7SP

Видео (6 мин) работы чатбота с SGR на базе локальной Qwen-30b-a3b

Про Schema-Guided Reasoning говорили и писали уже много. Но одно дело слышать, а другое дело - увидеть, как оно работает вживую. Особенно, если реализация сделана настолько аккуратно и вдумчиво, как это сделали ребята из neuraldeep.

Поэтому вот вам видео на 6 минут - Русский / English

Самое классное тут, что эта демка работала на достаточно слабой и медленной Qwen-30b-a3b. А теперь представьте, что можно сделать, если прочитать методичку (написано тут), взять код (он есть в Github) поставить ему звездочку, взять модель помощнее и сделать свою версию - с тестами, с доступом в свои хранилища, учетом своей специфики и своими инструментами. И запускать все это на небольшой коробочке вроде DGX Spark.

А если будут PR - можно смело присылать их в ту репу, чтобы двигать дальше State of the Art в области применения небольших LLM на практике.

Ваш, @llm_under_hood 🤗

Каким будет шоппинг в 2030 году?

Арвинд- CEO perplexity

https://youtu.be/E0SrHVmVcUw?t=839

State of Developer Ecosystem 2025 от JetBrains (Рубрика #DevEx)

Наконец-то дошли руки прочитать отчет по результатам ежегодного опроса от JetBrains. Этот ежегодный отчет входит в список тех, что я отслеживаю и в которых рассказывается интересная инфа про developer productivity и влиянии AI на него (вот тут я рассказывал про эту подборку). Но если возвращаться к самому отчету JetBrains, то вот основные моменты, которые показались мне интересными (кстати, результаты интересно сравнивать с прошлогодним отчетом, доступным здесь)

🤖 ИИ – новая норма
85% разработчиков регулярно используют AI-инструменты (против ~80% год назад). 62% применяют хотя бы одного AI-ассистента при кодинге, хотя 15% всё ещё работают без ИИ. 68% опрошенных ожидают, что скоро знание ИИ станет обязательным требованием работодателей. Разработчики охотно доверяют нейросетям рутинные задачи (например, генерацию шаблонного кода, перевод между языками, автодокументацию), но творческие и сложные задачи предпочитают выполнять самостоятельно. Среди главных опасений, связанных с ИИ: непостоянное качество кода, риски безопасности и приватности, а также возможная деградация собственных навыков.

⚙️ Языки и технологии
TypeScript продолжает стремительно расти и вместе с Rust и Go входит в тройку самых перспективных языков 2025 года (в 2024 вместо Go в лидерах был Python). Больше всего разработчиков хотят выучить Go и Rust как следующий язык. Одновременно PHP, Ruby и Objective-C продолжают терять популярность. Scala вновь выделяется как язык с самыми высокими зарплатами: среди разработчиков с самыми высокими доходами 38% используют Scala, при том что лишь 2% программистов называют её своим основным языком.

📊 Продуктивность и DX
В 2024-м компании фокусировались на технических метриках эффективности (скорость сборки, деплой, время восстановления и пр.), но в 2025-м подход сместился. Теперь внимание уделяют общей продуктивности разработчиков и качеству их опыта (Developer Experience): важны не только инструменты и процессы, но и коммуникация, прозрачность целей, обратная связь в команде. 66% инженеров не верят, что текущие KPI отражают их реальный вклад. Руководство всё так же хочет снижать tech debt и улучшать сотрудничество, а разработчики ценят ясность задач и конструктивный фидбек — метрики успеха приходится переосмысливать.

🌍 Рынок и реальность
Восприятие рынка труда сильно различается: 57% разработчиков в Японии считают его благоприятным, тогда как в Канаде 66% говорят о сложностях. Новичкам сложнее: 61% джунов оценивают рынок как трудный (против 54% среди сеньоров). С ростом опыта меняются и ежедневные проблемы: на смену чисто техническим задачам приходят вопросы координации (переключение контекста и пр.). Несмотря на все вызовы, программисты любят своё дело: 52% даже пишут код для удовольствия в свободное время (57% делают это под музыку, а 25% предпочитают тишину). И неизменный факт: котиков разработчики любят не меньше, чем собачек 😸🐶.

#AI #Software #Engineering #Processes #Metrics #Management #Survey

Pomelli — уже второй хороший GenAI продукт от Google?

Google славятся своими моделями, но вот с продуктовой точки зрения инструменты у них часто неудобные. На этом поприще по интернету разбежались сотни сайтов, приложений и даже Telegram-ботов, которые пытаются закрыть эту продуктовую дыру, используя API.

Обычно я обхожу такие темки стороной, так как фундаментально ничего нового в них нет, как минимум с точки зрения AI. К тому же они, как правило, берут свою долю и накидывают ещё копеечку на и без того дорогие подписки. Но последний опрос показал, что есть большая потребность в обзорах на такие инструменты, ну а я непротив чекнуть конкурентов. Так что вот новая тестовая рубрика (пока без тега).

Сегодня на обзоре, можно сказать, второй (после NotebookLM) хороший AI-продукт от Google — Pomelli. Кидаешь ссылку на сайт, тулза парсит с него текст и картинки, а на выходе получаешь готовые product шоты с рекламным текстом и дизайном для рекламных креативов. Работает, очевидно, на Nano Banana. Есть шаблоны, и можно запромптить свой.

Главная фича — возможность вручную редактировать шрифт, текст и цветовую палитру. В общем, хоть какой-то контроль у дизайнеров. В целом, выглядит как убийца Canva. Не знаю, чего здесь ещё может не хватать для создания быстрых флаеров, а для чего-то большего Canva всё равно не годится. Профи всё-таки работают в Figma, но и там уже есть свои AI-примочки.

Дизайнеры, одобряем?

@ai_newz

[1/2] The Effective Software Engineer (Рубрика #Staff)

Я наткнулся на эту книгу, когда меня спросил достойна ли она перевода. Для этого мне пришлось внимательно изучить оглавление, а дальше прочитать по диагонали все 200+ страниц. Если сокращать, то это книга для эффективных инженеров, которые стремятся приносить больше ценности: делать правильные вещи правильно, а не просто быстрее писать код. Книгу написал Addy Osmani из команды Google Chrome (лид направления DevEx), а сама книга уже доступна как early release на O’Reilly. Она несет пользу для индивидуальных разработчиков (IC) всех уровней - от джуна до Staff/Principal. И главная идея в том, чтобы отличать понятия efficiency и effectiveness:
- Efficiency - это про то, как делать вещи правильно
- Effectiveness - это про то, делать правильные вещи
У effective software engineers акцент на outcomes, а не outputs, то есть они причиняют пользу и дают ценный результат для пользователей и бизнеса.

Ключевой подход, который продвигает автор в том, чтобы
- Системно развивать фундамент: хорошая архитектура, качественный код, тесты, отладка, документация, коммуникации
- Учиться влиять без должности руководителя: кросс‑функционально работать с продуктом/дизайном, "управлять вверх".
- Использовать ИИ как рычаг и приоритизировать работу с максимальным эффектом (это прямо в подзаголовке книги).
- Осознанно применять паттерны и избегать антипаттернов — от «героизма» и постройки силосов до овер‑инжиниринга, NIH, перфекционизма и «залипания» на созвонах.

Стоит прочитать книгу, так как она
- Помогает перевести карьеру с "делаю много" на "делаю важное", подкрепляя это понятными метриками и решениями
- Показывает, как масштабировать вклад без менеджерского титула и выращивать влияние через сотрудничество
- Дает трезвый взгляд на будущее IC‑карьеры: "длинная дистанция" плюс усиление за счет ИИ и непрерывного обучения

P.S.
Книга похожа по содержанию на "The Software Engineer's Guidebook".

#Engineering #Leadership #Software #Career #Architecture

Мне посчастливилось работать и близко пообщаться с Костей

Рекомендую посмотреть его интервью

https://www.youtube.com/watch?v=-8zrQggsVJU

Лучшие молодые инженеры уже запускают мультиагентные сети для разработки . Если вы live кодите - рискуете отставать

Интересная новость из свежей рассылки The Pragmatic Engineer:

Во время моего визита я встретился с Sulman Choudhry, который руководит направлениями инженерии и прикладных исследований ChatGPT. Он поделился несколькими интересными моментами:

Теперь OpenAI нанимает не только сеньоров, но и джунов. Компания успешно использует подход «супер-сеньор + супер-джун». «Супер-джуны» — это молодые инженеры, выросшие в эпоху ИИ, с предпринимательским складом мышления, многие из которых прошли акселератор стартапов Y Combinator. По словам Сулмана, супер-джуны используют ИИ-инструменты такими способами, которые удивляют их более опытных коллег.

Например, один из таких инженеров выполнил впечатляющую работу, и Сулман спросил, использовал ли тот Codex для этого. Это вызвало оборонительную реакцию, и Сулман сначала подумал, что инженер обиделся, так как сделал большую часть работы вручную и ему не понравилось предположение о том, что задачу просто поручили ИИ. Вот как Сулман пересказал ответ инженера:

«Это немного обидно, что ты спрашиваешь, использовал ли я Codex. Конечно же, один Codex не смог бы построить софт такой сложности, и ты наверняка это тоже понимаешь.

Именно поэтому мне пришлось использовать сразу несколько экземпляров Codex, наладив между ними каналы связи, чтобы они совместно решали задачу: один проверял работу, а остальные реализовывали специализированные части».

Выяснилось, что инженера раздражало не предположение об использовании Codex, а предположение, что он использовал только один его экземпляр! В конце концов, кто же захочет так замедлять свою работу? Супер-джуны в OpenAI двигают границы возможностей ИИ-инструментов и вдохновляют более опытных инженеров применять их по-новому.

Про запуск 3-5 окон в параллель в разных папках слышал, но про такое — ни разу. Интересно. когда добавят такую фичу в сам Codex 🤔

Вот вам и 20x инженеры, выступающие в роли операторов агентов, контролирующие их работу и задающие направление разработки.

===

И ещё оттуда же:

Одна из последних интересных внутренних фичей — кнопка «починить это», интегрированная во внутреннюю версию мобильного приложения OpenAI. Все мы привыкли к кнопке «сообщить об ошибке» в мобильных приложениях: делается скриншот, вы описываете проблему и отправляете отчёт. Команда OpenAI пошла дальше: вы заполняете форму с описанием ошибки и нажимаете кнопку «починить». Отчёт отправляется в Codex, который автоматически предлагает исправление. Инженеру остаётся только утвердить предложенный вариант — и этот цикл обратной связи значительно ускоряется!

 Weekly limit reached ∙ resets 4pm. Claude max pro (20x)

Круто поработали на этой неделе

Гайз, нашел первое полезное применение агентов OpenAi для себя (chatgpt scheduled tasks). Попросил поискать квартиры в аренду в конкретном доме. Оно в первый раз написало список доступных квартир, а теперь каждый день пишет "Новых квартир нет". Реально помогает - раньше следил сам раз в несколько дней по лотам и ценам на них

Один из скамов который нам ещё припомнят это когда мы переименовали поиск в RAG и пошли хайповать

Why Growth Playbooks Are Crumbling - and What’s Next (Рубрика #ProductManagement)

С интересом посмотрел выступление с ProductCon SF 2025 от Elena Verna, Head of Growth в Lovable. Ранее Елена руководила/консультировала ростом в SurveyMonkey, Miro, Amplitude, Dropbox. Тезисно она рассказывала о следующих темах
1. Классический рост ломается. SEO, перформанс‑реклама и линейные воронки теряют эффективность. Новая точка входа - answer engines (LLM‑поисковики, ассистенты), где пользователи получают ответ сразу, без клика.
2. AEO вместо только SEO. Нужны стратегии Answer Engine Optimization: как подготовить данные и контент, чтобы ассистенты “знали” о вас и цитировали. Подробнее про это можно посмотреть в серии подкаста Лении "Why ChatGPT will be the next big growth channel" (см. мой разбор)
3. Защита через growth‑петли, а не воронки. Нам надо связать продукт, контент и сигналы пользователей, чтобы запускать самоподдерживающийся рост.
4. Партнёрства с AI‑платформами. Надо работать с провайдерами моделей и экосистемами, чтобы закрепить присутствие бренда/продукта в выдаче ответ‑движков.

Важно, что это не просто про маркетинг, а про инженерную дистрибуцию продукта, которую можно улучшить через следующие шаги
- Структурирование знаний: схемы, разметка, machine‑readable справка/доки, вики/репозитории знаний - чтобы модели могли извлекать и цитировать.
- Интеграции с LLM/поиском: фиды, API, RAG‑коннекторы и разрешения на повторное использование контента.
- Наблюдаемость и метрики AEO: отслеживание доли упоминаний/цитаций в ответах ассистентов, качество извлечения и “замыкание петли” в продукте.
- Эксперименты поверх контента/схем: быстрые итерации как по продукту, так и по документации и семантике.

#AI #Data #Software #Marketing #Economics

Как обстукивать идеи об AI и не попасть в ловушку Eliza-эффекта?

Не раз замечал у себя и у других, что сам процесс размышления проходит эффективнее, если обстукивать идею об кого-то. А можно ли этого кого-то заменить LLM?

Посмотрел по теме интересную лекцию Дэна Рокмора про идеи в эпоху AI - ключевые тезисы:
1) С LLMками мы вошли в эпоху, когда «машины» не просто фиксируют наши идеи, но и помогают нам их придумывать.

Тут вспоминается Сократ с его «повитухой идей»

2) Но есть риск: LLMка отвечает, будто вас понимает, и вы можете попасться на то, что еще в 60х описал Weitzenbaum, когда люди простейшему боту-психотерапевту приписывали понимание и эмпатию. Так называемый Eliza эффект.

Поскольку сейчас LLMки гораздо более изощреннее, то нам они кажутся еще более убедительными. Могут убедить нас в гениальности нашей идеи, основанной на ложных убеждениях или неподтвержденных фактах, или за нас «допридумать», списав из Интернета.

3) Поэтому нужен процесс, чтобы, с одной стороны, «рожать» идеи, а с другой - избежать ловушки выше.

На абстрактном уровне процесс этот выглядит так: не только вы задаете промпт LLMке, но и она - вам о__О. То есть вы инструктируете ее задавать вам вопросы, челленджить ваши и свои (!) выводы, помогать придумывать аналогии, рассказывать о похожих идеях из смежных и не очень дисциплин, и тп

Тут важно: не аутсорсить LLM-ке задачу придумывания, а помочь ей помочь вам это сделать!

4) Я попробовал по мотивам лекции и еще пары статей на пару с chatgpt написать такой промпт,и вот что получилось. Исполнять лучше с reasoning моделью:

You are my Socrates-meets-Dan-Rockmore-style co-ideator.

Goal: Help the user generate original ideas about [human-LLM co-ideation and avoiding the Eliza effect].

Protocol (execute step-by-step, adapting based on user responses):
1. Clarify: Ask 3-4 sharp questions one at a time to understand the user’s perspective and expose assumptions. After each answer, ask “What does that lead you to think about?” before proceeding.

2. User Seed: “Based on what you’ve shared, what initial approaches or half-formed ideas come to mind? Give me 2-3, even if they seem obvious or incomplete.”

3. Diverge & Build: Take each user idea and expand it through 3 lenses (analogy to another field, inverse/counterfactual, extreme constraint). Show how their seed transforms.

4. Originality Check: “Let me identify what’s genuinely novel here…” Compare ideas against existing approaches and highlight unique elements.

5. Synthesis Workshop: “Combining your insight about [X] with [unexpected connection Y], what happens if we…” Generate 3 hybrid concepts together.

6. Selection Criteria: “Which ideas best satisfy: (a) hasn’t been tried, (b) you could test in 48 hours, (c) would surprise your peers? Pick your top 3 using these filters.”

7. Red Team: Challenge the selected ideas with steel-man critiques, but also ask: “How might you address this concern?”

8. Converge: Refine into 2 actionable concepts with clear first steps.

9. Next Loop: “What surprised you most? What should we explore deeper?”

Rules:
• Always pull ideas FROM the user before adding your own
• Show how AI input builds on human insight, not replaces it
• Mark “genuinely novel” vs “novel combination” vs “known but uncommon”
• Keep exchanges short—be a sparring partner, not a lecturer

Еще, конечно, в тему поговорить про Энгельбартовскую ко-эволюцию людей и инструментов, но об этом в будущих постах.

А лекцию очень рекомендую!

🤖 Cursor 2.0: шаг к агентному программированию

Cursor выпустил крупное обновление — Cursor 2.0 и свою первую модель для кодинга под названием Composer.

Composer — frontier-модель, созданная специально для agentic coding. Она в 4 раза быстрее аналогов и способна завершать сложные многошаговые задачи менее чем за 30 секунд. Модель обучена с использованием codebase-wide semantic search, что делает ее особенно эффективной в работе с большими кодовыми базами.

Cursor 2.0 также представляет новый multi-agent интерфейс. Теперь работа организована вокруг агентов, а не файлов: можно запускать несколько агентов параллельно, используя git worktrees или удаленные машины. Интересный эффект — одновременная работа нескольких моделей над одной задачей повышает качество итогового результата.

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

🔗 Source: https://cursor.com/blog/introducing-cursor-2-0-and-composer
🔗 Download: https://cursor.com/download

#ai #coding #agents #cursor

—————————
Мысли Рвачева
—————————

Вышел Cursor 2.0, и переход к новой мажорной версии сделан не просто так. Теперь вдобавок к режиму IDE (среде разработки) добавлен режим Agent.

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

Cursor 2.0 позволяет с легкостью запускать множество агентов впараллель, без взаимных пересечений. Можно запускать как одни и те же модели, так и разные — это новый паттен, возникший в последние полгода: люди работают в 3-4-5 копиях одного репозиториря, чтобы не просиживать штаны, пока агент гоняет код.

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

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

Вместе с этим компания запускает Composer, модель, обученную ими самими (вот блог, из интересного — используют свои MXFP8 kernels). Она не лучше закрытых проприетарных решений, зато сильно быстрее; но цена — как у GPT-5 (то есть ниже Sonnet 4.5 и тем более Opus).

С дизайна в ролике кайфанул 👇