Рейтинги языков программирования в 2026 году с учётом ИИ-агентов и нейрослопа Python по-прежнему впереди, классический Си обошёл C++ и вышел на второе место, Java просела до исторического минимума. Привычная сводка, по которой все привыкли сверять, что учить. Вот только Visual Basic вдруг взлетел на седьмую строчку, и объяснение обескураживает. Скорее всего, это не всплеск интереса к языку, а офисные работники, которые массово гуглят, как написать макрос в Excel, и методика засчитывает эти справочные запросы как популярность. А «падение» Go в другом индексе на деле может означать не угасание, а зрелость языка, по которому просто реже ищут ответы. И это только присказка. За последний год у цифр в таблицах появился новый источник искажений, из-за которого взлёты и падения всё слабее связаны с тем, что разработчики учат на самом деле.

Ключевое за 3 дня ⚡ Главное • Meta создаёт облачный бизнес для продажи избыточных мощностей ИИ — Meta планирует сдавать в аренду мощности ИИ, конкурируя с AWS и Azure. • Microsoft запускает Microsoft Frontier Company — Новое подразделение по внедрению ИИ с инвестициями $2.5 млрд. • Anthropic планирует создать собственный чип с Samsung — Переговоры о разработке кастомного чипа для снижения зависимости от Nvidia. • OpenAI готовит три версии GPT-5.6 — Анонсированы модели Luna, Terra и Sol с разным уровнем затрат. • OpenAI создала чип Jalapeño — Разработан собственный ASIC-чип совместно с Broadcom. • Zhipu AI выпустила GLM-5.2 — Китайская open-weight модель, сравнимая с ведущими западными системами. 📈 Рост и Оптимизация • Alibaba сократил токены AI-агентов на 99% — Новый фреймворк экономит токены за счет пропуска загрузки инструментов. • Cisco внедряет AI-агентов для 90k сотрудников — Полномасштабная интеграция ИИ-агентов во все бизнес-процессы компании. • Астрономы создали CIGaRS для анализа сверхновых — ИИ-инструмент в 4 раза точнее измеряет тёмную энергию. • Figure AI вернулась на завод BMW со сложной логистической ролью — Роботы Figure приступили к выполнению логистических задач на производстве. • Waymo открыла поездки на роботакси в Нэшвилле — Запуск коммерческого сервиса беспилотных такси в новом городе. • Tesla начала тестировать Cybercab на дорогах Остина — Начало дорожных испытаний специализированного роботакси. • Обучение ИИ работе с турбинами — Woodside Energy интегрирует ИИ для управления запуском заводов СПГ. 🤖 Промпты и Практика • Превращайте сложные источники в 60-секундные вертикальные видео — NotebookLM теперь генерирует короткие видео на основе документов. • Создание звуковых эффектов с ИИ за секунды — Eleven Labs генерирует аудиоэффекты по текстовому описанию. • Google Docs AI: прослушивание текста и аудиосводки — Gemini в Google Docs теперь умеет озвучивать документы разными голосами. 🛠 Инструменты • Seedance 2.0 — Новая версия ИИ для генерации реалистичного видео. • Grok запустил Connectors и Build — Инструменты для превращения дизайна в код и генерации архитектуры. • AgentMail привлёк $6 млн на email-платформу для AI-агентов — Специализированный API для управления почтой через ИИ-агентов. • Meta улучшила инструмент чтения мозга — Система преобразует сигналы мозга в текст с точностью 61%. • Etched вышел из скрытности с новым AI-оборудованием — Стартап с оценкой $5B представил специализированное ИИ-железо. • Devin Security Swarm — Инструмент для автономного поиска уязвимостей в коде. • Laguna XS 2.1 — MoE-модель на 33 млрд параметров, оптимизированная для кодинга. • Weave Robotics представила Isaac 1 за $8,000 — Анонсирован доступный домашний робот-помощник. • Apptronik запускает фабрику данных для обучения роботов — Центр подготовки данных и новый гуманоид Apollo 2. • Coval — Платформа для тестирования голосовых ботов через симуляции звонков.

Покорение книги Эванса продолжается. Сегодня 2 и 3 главы. Вторая глава это буквально пляжный эпизод. Общайтесь на одном языке в рамках работы. Возможно это я чего то не понимаю, но рано или поздно при работе вы будете общаться на одном языке. Выработаете свои термины, придумаете определения, согласуете наименования. Даже если это произойдёт не сразу, то как будто бы это какая то базовая штука, которая на подкорке сидит. Глава третья уже по интереснее. Посыл понятен. Делайте модель вместе с кодом, код должен отражать модель, а модель код. Но некоторые заявления, как по мне бред. Во-первых, завязываться на ООП парадигме при проектировании это бред. В таком случае нам технологии начинают говорить что и как делать, а не наоборот, когда требования говорят, какие технологии брать. Во-вторых, заявление о том, что разработчики что-то там в тихую могут строить, не соответствующее модели. Возможно, во времена Эванса так оно и было, но сейчас даже в униках у большинства людей есть понимание, что так делать не надо. Что есть требования и их описание, и есть реализация.

Далеко идущие цели. Или как за выходные потратить 80% недельной Pro-подписки OpenAI за $200 на экспериментах с /goal. /goal – это режим для AI-агента (я использовал Codex CLI), который позволяет задать агенту цель. Он будет идти до неё, пока не достигнет. Важно, что перед финальным ответом, агент вернётся к исходной цели и перепроверит, а точно ли он её достиг? Как сделать так, чтобы AI-агент мог работать над задачей по-настоящему долго? Мы должны задать следующее: 1. Конечный результат. Чем подробнее – тем лучше. 2. Критерии, описывающие, что такое "готово". 3. Какие у модели есть ограничения. Ключевой пункт на самом деле. Потому что он создаёт для модели feedback-loop. 4. Инструменты, с помощью которых соблюдение ограничений можно проверить. Как это можно организовать на практике: 1. Идём в GPT-5.5 Pro. 2. Надиктовываем ему детально идею проекта, который хотим реализовать. 3. Сообщаем, что сейчас будем собирать детальное ТЗ, которое нужно сразу записывать в md-файлы для подготовки итогового zip-архива (чтоб не потерял ничего по пути). 4. Просим провести с собой глубокое интервью (с вариантами ответов и подсветкой правильного по мнению модели – так проще проходить опрос на 100 вопросов), чтобы вы с GPT понимали детали реализации на 100% одинаково. 5. Далее, опционально, можно уточнить "А будет ли готово к продакшну то решение, которое сейчас описано в ТЗ?". И получить ещё пачку вопросов в интервью с вариантами ответов, чтобы подсветить другие аспекты проекта. 6. Разбиваем с помощью GPT ТЗ на конкретные задачи. Выполнение каждой должно быть проверено через запуск тестов. Unit+автотесты+playwright для UI-тестов. Это те самые ограничения, которые обеспечивают feedback-loop после каждой задачи. 7. На базе сформированного архива просим сделать `/goal`-промпт, который будет ссылаться на md-файлы внутри архива (ибо ограничение в 3000 символов на `/goal`). 8. Готово. После прохождения всех описанных выше этапов – я получил 26 часов работы в /goal-режиме на выполнение 400+ задач по реализации проекта. Схема достаточно общая. Посмотреть на долгий /goal она позволит. Получение production-ready продукта не гарантировано. Придётся напильником доводить до того, что нужно. Есть моменты, в которых её можно улучшить. Например, более суровый feedback-loop и описание каждой из задач в определённом формате. Про свои находки в этих (и других) направлениях расскажу в следующих постах.

🆕 Новая статья: «Ваш ИИ-агент ведёт на вас досье. Я превратил его в RPG-лист персонажа» Каждая ваша реплика в Claude Code лежит на диске - каждое «сделай», каждое «проверь», каждый капс в три часа ночи. У меня этого добра накопилось на 200 тысяч слов - две «Мастер и Маргариты» чистой ругани и команд. И я подумал: досье же готовое, надо вскрывать. Так за сутки диалога родился Prompt Warrior - опенсорсный скилл, который превращает логи в геймифицированный психологический портрет. Спойлер: я «Неистовый Командир Терминала 90 уровня, Железная Длань», и это не комплимент. Что внутри: ➡️ Анатомия JSONL-логов Claude Code: что там лежит кроме «вопрос-ответ» и как выжать из этого 12 повадок, включая индекс оборотня (ночной мат против дневного) ➡️ SCALE - замороженные формулы: почему у всех одна математика и карточками можно честно меряться с коллегами ➡️ 74 ачивки как в Стиме: от «Клуба ста» до легендарного «Тирана» (негатива в 10 раз больше похвалы - моя гордость и позор) ➡️ «Хроника воина»: биография, которую пишет сама нейросеть. Моя вычислила, что я диктую голосом, и что «ковбой стреляет с бедра и, что раздражает летописца сильнее всего, попадает» ➡️ Почему модель не должна писать HTML руками - главный архитектурный урок для всех, кто делает скиллы агентам ➡️ Грабли: токены, посчитанные втрое, Google Fonts без кириллицы и короны в четверть размера ➡️ Аватар-монстр без нейросетей: как я искал замену Pollinations и нашёл её в пакете 2011 года Всё локально, приватно и бесплатно: ни одного сетевого вызова, логи не покидают машину, код открыт под MIT. Установка - одним сообщением в Claude Code, промпт в README. 📝 ЧИТАТЬ СТАТЬЮ НА ХАБРЕ ⭐️ ЗВЕЗДАНУТЬ НА ГИТХАБЕ А теперь главное: прогоните на своих логах и киньте свои титулы в комментарии. Мне дико интересно, есть ли среди вас хоть один «Учтивый Дипломат Машин» - или тут все Неистовые Командиры, как я. P.S. Проект свежий, звезда на гитхабе ему сейчас важнее всего. Ну а плюсик на Хабре - традиционно спасает от хейтеров. Заранее обнял 🧡 Всех обнял, увидимся на стриме всегда ваш - Nerual Dreming ❤️

Мой батя ебашит вообще адовые АИ-решения. Ну такой вот примерно рецепт усредненный, потому что вариаций масса. Берется старый промпт, он не читается, читать — это не про моего батю. Он берет этот промпт, вываливает его в чат, сверху хуярит system message на три экрана и начинает докручивать. Добавляет туда огромное количество контекста, ролей, ограничений, few-shot примеров, chain-of-thought, JSON schema, temperature 1.2, RAG, векторку, агентность и КОСТЫЛИ! для стабильности, сверху еще “act as senior developer”. Все это гоняется по кругу, пока логи не начинают плеваться эксепшенами, а модель — уверенно нести хуйню. Потом батя снимает это с локалки и сразу выкатывает в прод. Потом заносит обратно, навесив сверху retry, regex-парсингом, костыльными валидациями и “ну у меня же работает”, начинает юзать. При этом дебажит прямо в проде, тыкая curl’ом по эндпоинтам. Сидит и приговаривает полушепотом: ух бля, GPT мощь. При этом у него на лбу аж пот выступает, потому что токены горят, контекст распух, а модель уже третий раз забыла, кто она и зачем живет. Любезно мне иногда предлагает заревьювить, но я отказываюсь. Надо ли говорить о том, какой дичайший техдолг потом? Наследие такое, что документация от репозитория отклеивается.

Худший язык программирования всех времён /s Инициализировать переменную можно десятком способов, и в одном из них скобки решают, лежит там ноль или мусор с прошлого вызова функции. static делает четыре несвязанные вещи. Целочисленных типов около пятидесяти, а vector — вовсе не вектор, что признавал и сам автор STL. Жанр «почему C++ ужасен» на Хабре выжжен дотла, и всё это читано по двадцать раз. Полгода назад разработчик пробежал 50-минутное видео о худшем языке по диагонали, а теперь пересмотрел целиком и обнаружил неприятное. Если убрать интонацию обиженного джуна и оставить аргументы, процентов 70 там — правда. И все эти боли, от кривых имён до медленных контейнеров, оказываются следствием одного решения из прошлого языка.

ПРОКЛЯТИЕ ПЕРЕИСПОЛЬЗУЕМОСТИ Делюсь болью. Я последние 5 лет на разных уровнях у разработчиков, лидов и техдиректоров, активно встречаю такой паттерн:

Ну давай просто выделим общее и переиспользуем это в другой системе/проекте.

Мы ведь уже написали систему перемещения для ботов, давайте для игрока её тоже переиспользуем. У нас ведь уже есть backend-сервис по обработке match-3 логики, давайте его же тупо используем в другой игре 😵 Может казаться, что нужно просто скопировать/вставить решения из одного места или создать общий класс. И черт, это не работает нормально в большинстве случаев. 🔸 Если вы делаете что-то общее, то сначала нужно понять, какие зависимости это общее в себя принимает и отдаёт Если вы сделаете прямой copy/paste, придётся писать кучу обёрток, чтобы подружить новую систему с текущей. Поэтому чтобы действительно такое было возможно, нужно заранее проектировать не только саму систему абстрактно, но и её зависимости 🤯 А это значит, что нужно изначально планировать проектирование ключевых абстракций проекта. Например: 🔹 Весь cross-cutting context. Логирование, конфиги, аналитика, обработка ошибок. Либо придётся кучу мест рефакторить, либо заранее согласовывать единое API для переиспользования между проектами. 🔹 Коммуникация с сервером — пример посложнее. Но суть простая: вы не хотите при переносе дублировать логику обработки ошибок, контрактов взаимодействия и тянуть лишние транзитивные зависимости (другой HTTP-плагин, например). И это важно тупо потому, что это заставляет поддерживать задублированные решения по проекту 🤢 🔹 Изменился формат логирования или когда логи пишутся, а когда нет 🔹 Добавился новый обработчик исключений, формат контракта или обработка краевого случая Вот иди свищи по проекту 10 копий и вкостыливай фикс и туда. При этом ладно этот фикс в коде, ха, это ещё изи, а если ты решил общий микросервис такой выделить… 🔻Чем больше расстояние между зависимостями — тем сложнее и дороже в них вносить изменения. 🔸 Не всё, что кажется общим, таковым является Избитый троп:

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

Ну нет, это не работает. Если заранее не понимать, как именно система будет переиспользоваться, и не переиспользовать сразу — оно не будет работать. Это происходит из одного простого факта: 🔹 Скорость изменения требований разная для каждой из систем. То, что вчера виделось как общее, сегодня жёстко заточено под что-то конкретное, т.к. переиспользуемость стоит времени, сил, денег и тщательного планирования. Или по другому: То что вчера казалось легко можно переиспользовать, сегодня требует узкого и конкретного решения. Так что всё, пожалуйста, я снимаю со всех, кто читает этот пост, «проклятие переиспользуемости» 😘 С этого момента вы можете не писать системы так, чтобы вдруг когда-то их кто-то использовал и сократил себе время. 🔻 Наконец-то можно писать системы, которые заточены на выполнение своей задачи и не раздувают сложность проекта на ровном месте. Но если переживаете, вот правило трёх:

Пока система или её часть не переиспользуется как минимум в трёх независимых местах — ничего общего выделять не нужно.

А если есть требование — выровняйте уровень знаний, покажите цену такого решения, сделайте #проектирование@UniArchitect, внедрите и пользуйтесь на здоровье, все только спасибо скажут. Ставь 👍 если тебе заходит такого рода контент! Ты знаешь кому переслать эту статью 💪 #проект_в_разработке@UniArchitect

Последние несколько дней слушаю с перерывами интервью Ленни Рачицки с Фионой Фанг из Anthropic. Редко советую посмотреть полуторачасовой выпуск целиком, но этот точно стоит времени. Фиона руководит командами Claude Code. До этого были 11 лет в Microsoft, запуск Facebook Marketplace, инфраструктура Instagram. Она прошла несколько технологических эпох и хорошо чувствует, что действительно меняется, а что — просто хайп. Больше всего меня зацепила одна мысль. Правда зацепила, это не клише от чатгпт 😉 Мы уже привыкли говорить, что AI ускоряет разработку. Но почти никто не обсуждает, что происходит дальше. Если команда теперь может писать в несколько раз больше кода, то где становится следующее ограничение? Ответ оказался неожиданно приземлённым. Не в AI. В понимании пользователя, его потребностей и выборе фокуса. И, конечно, в коммуникации между людьми. В том числе, чтобы вся команда одинаково понимала, что вообще нужно строить. И что будет возможно построить с использованием AI нового поколения. Кажется, именно поэтому последние полгода я всё чаще слышу от сильных продуктовых команд одну и ту же мысль: разработка перестаёт быть главным бутылочным горлышком. Да и сам уже вижу на живых примерах — сейчас запускаем систему управления стоками, которую сделали за 3 недели. Ранее это бы заняло минимум 3 месяца. В интервью ещё много интересного: 📌 как Anthropic использует Claude в ежедневной работе; 📌 почему они постепенно уходят от длинных роадмапов; 📌 как меняются требования к инженерам; 📌 какие проблемы AI пока так и не смог решить. Если будете смотреть одно интервью про AI этим летом — я бы выбрал именно это. ▶️ https://youtu.be/Ybrl4FYM57c #videoholidays #claude #aifuture

Вот и подходят к концу обе мои квоты на Fable (личная и корпоративная). Отличная ли это модель? Да 👍 Как когда-то GPT-4 значительно повысил надёжность языковых моделей, Fable значительно повысила надёжность агентов. В случае Опуса я предполагал по умолчанию, что я не доверяю выхлопу модели. На все нетривиальные изменения прогонял simplify, review, codex:adrversarial-review, qudo и отсматривал результат глазами. Потому что много раз меня Опус подводил, как в макро, так и в микро-решениях. В случае Fable я по привычке это тоже сначала делал, но пользы от этого было уже не так много. Предположение по умолчанию поменялось. Более того, Fable регулярно делала что-то сверх того, о чём я её просил. Например, когда она составляла отчёт в виде HTML странички, она установила playwright, headless chromium, сделал итоговый скриншот странички, загрузила его на закрытый корпоративный paste, чтобы я мог посмотреть на дизайн глазами до развёртывания. Мог ли такое сделать Опус? Мог конечно, но только если бы я описал весь путь. А я даже не знал, что я такое хочу!😜 Означает ли это, что Fable не ошибался? Лол, конечно ошибался, и тоже и в макро, и в микро. Но вот количество ошибок было гораздо меньше, и исправлять их было проще.

Говорить, что ИИ заменит человека, так же как говорить, что калькулятор заменит математика

Суть метафоры понятна, но ирония в том, что сама метафора подтверждает мысль, что придется конкурировать с ИИ на уровне кода, но не архитектуры. 1. Математик не конкурирует с калькулятором, просто потому что математик - это скорее архитектор, а не кодер. Он работает с теоремами, абстракциями, доказательствами, а не считает, что-то на калькуляторе. 2. Была такая профессия "вычислитель", вот у этих ребят как раз возникли проблемы с появлением вычислительной техники, им пришлось конкурировать со способностью быстро и точно считать, и по итогу победили машины. Любые метафоры неточны, важно понимать, что конкуренция возникает когда возникают общие функции, у хороших инженеров много функций, которые не пересекаются с ИИ, а вот у чисто кодеров пересечений много.

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

Это очень опасное заблуждение, которое возникает из-за того, что на уровне кода (одного приложения) ИИ может выдавать результат, который работатет (проходит тесты). Архитектура системы - это другой разговор. Первое: архитектура оценивается не в моменте, а на дистанции. Хорошая архитектура позволяет сопровождать и развивать систему в течение длительного времени. Проблема в том, что даже самые сильные ИИ-модели принимают решения, которые накапливают техдолг - неверные границы доменов, жесткое зацепление, слабая связность, дублирования и т.д. На дистанции 2–3 месяцев (без человеческих корректировок) внесение изменений в проект порождает эффект домино и кучу побочек. ИИ не "видит", какие части системы меняются синхронно, какие требуют унификации в виде общих интерфейсов и абстракций, часто LLM создаёт распределённый монолит, вместо микросервисов и т.д. Второй момент — есть разница между архитектурой приложения (архитектура на уровне кода) и системной архитектурой. По приложению довольно много типовых схем, которые ИИ может воспроизвести и под контролем человека даже более-менее сопровождать. Системная архитектура - это всегда компромисс между стоимостью, рисками и конкретными ограничениями: бюджетом инфраструктуры, легаси, требованиями регуляторов, реальной командой, которая будет это развивать. ИИ выдаёт архитектуру которая не учитывает нюансов, эта архитектура некая средняя температура по полате, которая получиалась из кучи схем, используемых в обучении, В результате решения не соответствуют конкретной ситуации и не решают проблем системы.

Apple удалила фреймворк для воспроизведения DVD из macOS 27 В описании обновления macOS 27 beta 2 обнаружили информацию об исключении фреймворка DVDPlayback из SDK. Сторонние разработчики больше не могут собирать приложения, которые зависят от этого инструмента, а в будущих релизах операционной системы его полностью вырежут из кода. Фреймворк появился более 20 лет назад в Mac OS X 10.3 и отвечал за нативное воспроизведение видео с оптических дисков. Решение выглядит закономерным, поскольку Apple убрала встроенные приводы из MacBook Air еще в 2008 году, из MacBook Pro — в 2012-м, а в 2024 году окончательно прекратила продажи внешних фирменных дисководов SuperDrive. Изменения в SDK не означают полный запрет оптических носителей на Mac. Пользователи смогут и дальше подключать сторонние USB-приводы для чтения дисков, однако софт для работы с ними теперь должен использовать собственные независимые декодеры и библиотеки вместо удаленного системного инструмента Apple.

⚡️ 30 техник памяти для AI-агентов в Jupyter notebooks Вышел репозиторий Agent Memory Techniques с 30 runnable notebooks по памяти в современных AI-агентах. Внутри собраны основные подходы: conversation buffers, vector stores, knowledge graphs, episodic и semantic memory, MemGPT, Mem0, Letta, Zep, Graphiti и production-паттерны, которые уже встречаются в реальных агентных системах. Это набор ноутбуков, которые можно запускать, менять и сравнивать между собой. Удобно, если нужно понять, чем простая история диалога отличается от долговременной памяти, где уместен vector store, когда нужен graph-based подход и как память влияет на поведение агента в длинной задаче. GitHub: http://github.com/NirDiamant/Agent_Memory_Techniques

Как я с Клодом собрал команде личный кабинет Собирался написать этот пост недели две: идея внутри горела, а я всё равно тянул — ровно потому, что фигачил как раз то, о чём хочу рассказать. Но пора перестать размышлять о вайб-кодинге и показать, что из него всё-таки удалось собрать, а то первая волна эйфории уже схлынула и вымываются те, кто ушёл в мертворождённые продукты. Но начну с контекста. У нас в Overgear, как у любой модной и прогрессивной компании, в начале года случился мощный FOMO: либо оседлаем волну AI-изации, либо из лидера тихо сползём в отстающие, потому что утонем в рутине с её нищим КПД. Поэтому наметили несколько стратегических проектов под автоматизацию и раздали инструменты всей команде — чтобы набивала шишки. На один из таких проектов позвали стороннего интегратора. Он озвучил нехилую сумму за внедрение, и у меня сразу внутри: «wtf, да я сам сделаю лучше» — и сел разбираться с Клодом. Первые потуги были неуклюжие: я только осваивал дисциплину и завалил папку проекта десятками сборок на localhost, по сути мусором. Но уже через неделю почти без усилий поднял свой VPN-сервер ускоритель интернета, который не блокируется: вся семья и друзья на нём сидят, вроде даже без перебоев и жалоб. Тут внутренний авантюрист завёлся сильнее и завёл меня в точку, где я решил замахнуться сразу на рабочий инструмент для всей команды — чтобы люди меньше времени тратили на отчётность и сбор данных, а нужные цифры вытягивали через MCP (это коннекторы нейронок с внешними сервисами вроде Google Ads, GA4, CRM) почти без ручной возни. Проще говоря, свой личный кабинет для команды. Он на скрине — цифры только замазал, так как NDA, все дела. Дальше меня затянуло как в воронку: стал по модулям собирать функцию за функцией и закрывать не только отчётность, но и рутину, которая порой съедала до 30% времени человека. Теперь у ребят вроде как больше места для творчества — мозг не выгорает на операционке. И работают тут ровно те же правила, что для любого продукта: смотришь метрики (MAU, DAU и прочие), проверяешь, даёт продукт больше пользы или больше отъедает ресурса. И где-то здесь я поймал настоящую маниакальную зависимость: пилить и пилить эту ценность, а потом проверять — стала она ценностью или ты просто потешил своё эго очередным инструментом. Побочки, как у любой зависимости, тоже налицо: меньше спишь, уходишь в это с головой и забываешь уделять время родным (Анисия, каюсь!). Спасает, кажется, одно — привычка на каждой собранной штуке спрашивать себя: пользуется ли ей вообще хоть кто-то. Кто на этот вопрос забивает, тот и клепает продукт за продуктом в стол — так и пополняется кладбище мертворождённых. Стала ли это в итоге ценностью для команды — пока честно сказать не могу, ребята только тестируют. Но одно скажу точно: нам удалось проскочить «долину смерти» и распробовать потенциал и вайб-кодинга, и более глубокой работы с данными. Так что Viva la AI лично от себя подпишу, а как с этим быть каждому — это уже сами посмотрите. А у вас как сложилось с вайб-кодингом? Удалось собрать что-то реально рабочее — или пока всё живёт на localhost? Константин Сухачев

Увидел новый опенсурс проект, который решает для агентов проблему подключений внешних сервисов через MCP и API Например вам нужно поработать с Notion через агента, и он начитает искать, есть ли у сервиса MCP, какой API, как авторизоваться. Так вот integrations.sh собирает в себе кучу сайтов и разные способы подключения к ним: 1/ MCP 2/ API и их спецификации 3/ GraphQL ендпоинты 4/ CLI утилиты 5/ Auth инструкции Всего в каталоге около 6000 интеграций У них есть свой MCP:

mcp add --transport http integrations https://integrations.sh/mcp

Или по API:

curl https://integrations.sh/api/[ДОМЕН]/detect

В итоге меньше слитых токенов, агент сразу знает как подцепиться к нужному сервису. @tips_ai #tools