Как стать автором

Хайп вокруг AI‑агентов продолжается. Компании активно внедряют агентов в продукты, внутренние процессы и даже повседневную рабочую рутину сотрудников. Но чем дальше мы уходим от игрушечных агентских сценариев к реальным продуктовым задачам, тем чаще возникает вопрос — как понять, что агент действительно работает хорошо?

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

Как хранить генеалогическое дерево у себя, подключить к нему ИИ-агента и что из этого получается на практике.

Проект: gramps-web-mcp-rs

Всем привет! Мы два 19-летних студента второго курса из Казахстана. В свободное от учёбы время мы развиваем DreamForge — собственный исследовательский проект в области интерактивных мировых моделей.

Сайт проекта: trydreamforge.com

Несколько лет мы с другом занимались инди‑разработкой игр и Minecraft модов. Один из этих модов со временем набрал миллионы загрузок и начал приносить достаточно денег, чтобы финансировать наши эксперименты с облачными GPU.

По данным GitGuardian (State of Secrets Sprawl), только за 2024 год в публичный GitHub утекло около 23,7 млн секретов — ключей API, токенов, паролей. Подавляющее большинство — не результат взлома, а обычные коммиты, логи и клиентские бандлы. Свежий ключ, попавший в публичный репозиторий, боты начинают пробовать меньше чем через минуту.

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

Я давно хотел убрать из backend‑разработки одну особенно липкую рутину: когда для каждой новой сущности снова и снова приходится собирать одни и те же слои REST API — repository, service, handlers, request/response модели, OpenAPI, auth, тесты, curl‑примеры, Docker и прочую инфраструктуру.

В этой статье рассказываю про query‑first подход и open‑source Go CLI rest, который позволяет реализовать эту идею. Смысл простой: если SQL‑запросы или MongoDB‑контракты уже описывают, какие операции нужны приложению, то из них можно сгенерировать согласованный каркас REST‑сервиса.

В статье показано, как это работает для PostgreSQL и MongoDB, что именно генерируется, что такоеrest doctor и почему цель инструмента — не заменить бизнес‑логику, а снять первые 80–90% повторяющейся ручной работы.

После рабочих встреч часто остаются записи. В моем случае это записи Яндекс Телемоста.

Запись есть, но пользоваться ей не всегда удобно. Если нужно что‑то вспомнить, приходится открывать видео, перематывать, искать нужный кусок, переслушивать. Если нужно передать встречу другому человеку, одного видео обычно мало.

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

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

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

Первую рабочую версию получилось собрать через Codex примерно за 30 минут.

В свое время я выбрал не самую востребованную специальность.

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

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

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

Наш любимый доходяга Яндекс частенько показывает вверху выдачи готовый ответ и ссылается в нём на три‑четыре сайта. При этом по такому же запросу в обычной выдаче сотни, а то и тысячи страниц. Позвольте спросить, по какому такому принципу нейроответ отбирает из этих сотен именно те самые избранные, которые собирают весь куш? Я решил проверить свои (бестолковые) гипотезы на реальных данных.

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

Сразу про масштаб. Это одна ниша и всего 60 обращений, так что на вселенскую истину я не претендую, хотя очень хотелось бы. Но даже на таком объёме картинка получилась на удивление устойчивой, пусть и не такой, как мнение Греты Тунберг обо всём на свете.

Я аналитик, а не разработчик. Весь код для созданной нами платформы написал Claude Opus через Claude Code. Рассказываю без хайпа: как выглядит реальный workflow, где нейросеть незаменима, где она бесполезна, и какая инженерная дисциплина обязательна, чтобы это не превратилось в тыкву на боевом.

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

Я не умею писать продакшн‑код. Я аналитик: читаю код, рассуждаю о системах, проектирую поведение — но профессионально не кодю. Тем не менее у нас в проде работает нетривиальное веб‑приложение, и каждую строчку кода написала нейросеть (Claude Opus, агент Claude Code). Моя роль — архитектор, продакт и QA. Второй ключевой специалист по разработке — дизайнер вебинтерфейсов, также освоивший Claude.

Это не пост «ИИ сам всё сделал, программисты не нужны». Скорее наоборот: я хочу показать, что инженерия никуда не делась — просто из неё вынули операцию «набирать код руками». Всё остальное (проектирование, компромиссы, ловля прод‑онли багов, дисциплина релизов) осталось на человеке. И вот об этом «остальном» — интереснее всего.

Как разогнать copy_if на NEON в 30+ раз без единой ветки в горячем цикле — эмулируем compress инструкцию, которой в NEON нет, через table lookup и немного битовой магии.

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

После этого разговора я решила сделать такое устройство для себя из подручных средств — у меня была простая плата esp32c3 и фоторезистор ky018. Я хотела получить быстрое и простое решение, потому что сама задача довольно тривиальна, а для меня она при этом решала вполне реальную проблему: постоянное напряжение глаз из‑за изменения освещения в течение дня.

Я изучаю AEO/GEO (продвижение брендов в ответах нейросетей) и наткнулся на разбор про странную вещь: нейросети называют одни бренды и будто не замечают другие, причём качество продукта тут ни при чём (SearchAtlas). Объясняют это через понятие сущности: и поиск, и нейросети воспринимают бренд как отдельный объект знания со своими свойствами и связями.

Тема показалась любопытной, и я полез в первоисточники: доки Google, schema.org, Wikidata, замеры Ahrefs и Frase, пару работ с arXiv. Там и уткнулся в неожиданное. Знание о бренде у машины устроено двумя совершенно разными способами, и их постоянно путают. Один способ работает у обычного поиска Google, это Knowledge Graph. Другой у языковых моделей вроде ChatGPT, это память в весах нейросети.

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

Это подробный разбор одного эксперимента. Я взял god node из реального LangGraph агента и попросил 5 американских и 6 китайских моделей сначала предложить, как её распутать, а потом оценить предложения друг друга. Дальше тремя разными способами пытался понять, кому из них в этом деле верить.

Как устроен SFU изнутри: Publisher, Subscriber, комната-маршрутизатор и никакого перекодирования. Дневник разработки на Rust.

Дисклеймер: все события основаны на реальном кейсе борьбы за гарантийный ремонт топового железа в СЦ DNS. Диалоги воспроизведены по памяти, максимально близко к оригиналу, технический абсурд передан без приукрашиваний. Авторское настроение: «мне не смешно».

Представьте ситуацию: вы покупаете бескомпромиссную рабочую станцию. Вся система в сборе приобретается в DNS, там же заказывается сборка. Всё официально и находится на гарантии, кроме одной детали — процессора. Он шёл как OEM, и его годовая гарантия уже благополучно истекла, в то время как на остальные ключевые компоненты (включая дорогущую RTX 4090) гарантия продолжает действовать. Запомните этот факт — вокруг него СЦ построит свою главную защитную стратегию.

В один прекрасный день ваша ультимативная машина превращается в генератор бесконечных аппаратных ошибок шины данных, а мастера из сервисного центра выдвигают техническую гипотезу, достойную Шнобелевской премии по физике. Они заявляют, что пробой PCIe произошёл из‑за троттлинга процессора, который таким образом «убивает» видеокарту. Такое невозможно придумать самому без использования тяжёлых веществ (которые автор статьи категорически осуждает).

В этой статье разберём, почему «волосатый бублик» бессилен против стека ИИ, как контроллер памяти GPU тихо умирает под CUDA‑нагрузкой, и как разворачивался этот комедийный баттл с СЦ DNS.

Управление контекстной рекламой — это много механической работы. Открыть статистику, выгрузить срез, свести два периода в таблице, заметить просевшую кампанию, пойти в другой отчёт, поднять минус‑слова, вернуться, поправить ставку. Каждый шаг по отдельности занимает приличное количество времени, с учетом того, что в больших РК этот процесс еще и подвисает (буквально подвисает, на больших отчетах статистика может грузиться минуты). Все вместе половина рабочего дня уходит на то, чтобы просто понять, что происходит в аккаунте. И таких аккаунтов у специалистов/фрилансеров обычно больше одного, у меня сейчас, например — 7.

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

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

Последние полгода я достаточно активно работал с различными ИИ и решил, что созрел на то что бы сделать свой сервис, который снимет эти проблемы. Логика, как я её видел, должна была быть простой — даёшь ИИ доступ к АПИ Директа, а дальше он сам делает всю магию, и я просто запросами в чате получаю все необходимые данные и управляю кампаниями.
Что может быть проще?)

Каково назначение хуков useMemo и useCallback? Какие ошибки и лучшие практики следует при их использовании, и почему удаление большинства из них может быть хорошей идеей?

Здесь вы найдете ответы на эти вопросы или можете поделиться своей историей «переоптимизации».

Для успешной разработки программного обеспечения важны разумное ограничение затрат времени и выбор способов решения задачи. Как я обнаружил, в PHP-фреймворках много такого, что нужно не во всех приложениях. Из-за этого вес пакета и число файлов, упоминаемых в одном логе становится неудобно большим. При этом, число пакетов, используемых под капотом при выполнении базовых действий невелико.

В какой-то момент я понял, что моё дальнейшее развитие как разработчика требует уменьшения затрат времени на треть. Поисковик, генерирующий ответ, увеличивает её не более чем на четверть, и то в основном за счёт чтения документации. Логично взять и соединить всё лучшее от современных технологий и подходов, проверенных временем. Быстро обнаружил, что регулярно не укладываюсь по времени на целые проценты нужного срока. Само собой разумеется проанализировал то, что мешает писать качественный код быстрее. Обнаружил, что фреймворк вообще и реализации отдельных паттернов проектирования в частности, загромождены. Не все очень длинные классы имеют одну ответственность. Нередко в одной сущности объединена функциональность, нужная по отдельности и занимающая много места в коде и в уме.

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

Я хотел использовать Claude прямо в мессенджере MAX — без браузера, без переключения контекста. Готового решения не было. Нашёл на GitHub китайский проект cc-connect — Go-фреймворк с plugin-архитектурой для подключения AI-агентов к мессенджерам. Telegram, Feishu, Discord там были. MAX — нет.

Написал адаптер, открыл PR. Приняли. Теперь поддержка MAX — часть основного репозитория.

Что такое cc-connect

cc-connect — Go-фреймворк с чёткой трёхслойной архитектурой:

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

У меня есть внутренний дашборд, который собирает список рабочих копий проекта (git worktree) и показывает по каждой последнюю активность. В какой-то момент пришло сообщение: «разные ветки, а последнее сообщение и время везде одинаковые». Я открыл дашборд — и правда: каждая копия отображалась пять раз подряд, с идентичными данными. При этом тесты были зелёные, строчное покрытие — сто процентов, а мутационный прогон по этому куску показывал 97,8%. То есть все три метрики, которым принято доверять, дружно сказали «всё хорошо».