Искусственный интеллект

### Cursor как общая среда для заказчика и разработчика

Google влил в Anthropic сорок миллиардов, Cursor "собрали" браузер на GPT-5.2, а я начал писать код совместно с заказчиком.

В этом посте я поделюсь экспирементом, который мы начали на проекте для бизнеса в сфере управления недвижимостью. Расскажу, как я организовал работу с заказчиком в Cursor, почему это оказалось технически интересно, где здесь бизнес логика, и почему общий workspace может стать новой средой между бизнесом, разработкой и ИИ агентами.

## А что если показать заказчику как работать с Cursor и использовать ИИ-агентов?

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

На старте клиент не был человеком из серии "хочу приложение, но не знаю какое" - он уже прошёл классический флоу разработки с командой разработчиков, который не дал желаемого результата. Затем пробовал nocode и ИИ инструменты для написания приложения с нуля. Они дают быстрые прототипы и классный старт, позволяют CEO очень быстро проверить гипотезу, почувствовать интерфейс руками. Но у них есть потолок, в какой-то момент появляются вопросы, которые уже не решаются перетаскиванием блоков - здесь и должна появиться инженерная составляющая, инженерное сопровождение.

Как правило в разрааботке бизнес софта есть классический разрыв. Заказчик знает как всё работает в реальности, а разработчик знает, как это положить в код. Между ними живут созвоны, документы, скриншоты, "а я имел в виду не это", "а вот у нас в сезон бывает иначе"... Если проект маленький, это терпимо, но в процессе масштабирования и усложнения всё начинает сыпаться.

Обзор серверного ускорителя NVIDIA Tesla V100 16 Gb в корпусе от RTX 4090: Часть 1 - Внешний вид, установка и настройка

При работе с Claude Code я столкнулся с проблемой: по мере роста числа агентов стало сложно синхронизировать их правила между машинами и окружениями. Параллельно возник риск — потерять все наработки (скилы, команды, конфигурации) при смене аккаунта или среды.

Я решил считать ~/.claude/ обычным кодом и хранить его в Git.

Так появился claude-config-template — репозиторий, из которого ~/.claude/ собирается через симлинки. В нём лежат скилы, агенты, команды, хуки и MCP-конфигурации.

Это даёт:
- переносимую конфигурацию между машинами
- единый источник правды для всех агентов
- версионирование и откат через Git

За последний год появилось множество видеороликов и статей по использованию нейросетей для изучения английского языка. Очень часто авторы, среди которых попадаются и «дипломированные» учителя, в очень немногочисленных и расплывчатых промптах‑инструкциях просят ИИ ограничиваться каким‑то уровнем CEFR, от A1 до С2. Как ни странно, никто из этих авторов даже не потрудился изучить, понимают ли ChatGPT, Gemini, Claude, Grok, что входит в конкретный уровень, а что — нет. Как это можно проверить?

Практический эксперимент с Meshtastic: две Heltec ESP32 LoRa 32 V4, связь на 702 м в городской среде, разбор LoRa-настроек, ролей нод, MQTT и Python-мост к локальной LLM через Ollama.

Полгода прошло с первой статьи https://habr.com/ru/articles/969230/ , вариометр летает и сигнализирует о наборе высоты и о потере высоты, пилоты довольны. Код сыроват конечно. EMA фильтр стоит, линейная архитектура стоит, записи высот в полете нет и экспорта нет. Как-то работает. Но можно качественнее сделать. А вот когда лень переписывать с нуля, знакомая херня? Но решился.

Развернул Hermes Agent, закинул на аккаунт DeepSeek4 40 юаней, это 430 рублей, и начал диалог в терминал. Работал в диалоге с консолькой, ну просто магия. Без промптов. "Сделай FSM вместо ифов, добавь зуммер в стиле Браунигер, компенсацию акселерометра по трём осям с учётом гравитации, а не по модулю, трек полёта на флешпамять кольцевым буфером с CRC, WiFi экспорт через вебморду."

Я работаю в PR с 2001 года. Тогда профессия пиарщика активно развивалась, на рынке было много политтехнологов и консультантов. За 25 лет профессия сильно трансформировалась, в том числе и по части подготовки контента в различных форматах. И если раньше мы по крупицам собирали информацию и превращали ее в разные материалы, то сегодня контент создается намного быстрее.

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

Задача была простая: протестировать два веб-приложения перед деплоем. Next.js-портфолио и SaaS-чат — accessibility, консольные ошибки, отзывчивость на мобильных. Рутина.

Открыл Claude Code, подключил Playwright MCP, написал «протестируй приложение». Агент начал работать, делать скриншоты, проверять элементы. На 51-м снапшоте /compact сработал. Текстовый контекст был заполнен на 18%. Я не понял что произошло.

Через час разбирательств я нашёл невидимый image-лимит. Через три часа — понял, что Playwright MCP сжигает в 50 раз больше токенов чем CLI на том же workflow. Через три дня — у меня был рабочий инструмент, который уже тестируют реальные пользователи.

Эта статья — про путь от «хочу просто протестировать» до open-source инструмента, и про архитектурные проблемы, которые заставили его собрать.

Финал серии: Agent Teams, GitHub Actions, Agent SDK, TDD, Ralph-loop на ночь и осторожный прогноз на 2027

Серия на Хабре: часть 1 - что Claude Code умеет из коробки · часть 2 - настройки, хуки и Context Rot · часть 3 - автономная работа и параллелизм.

Однажды вечером я дал Claude Code не задачу "сделай фичу", а уже написанную спеку и сложный план. Дальше работал не один чат, а цепочка: оркестратор разобрал план на независимые куски, поднял кодеров в отдельных worktree, дождался их diff'ов, потом вызвал ревьюеров на каждый кусок и собрал итоговый отчёт. Утром у меня был не "ответ ассистента", а несколько веток, замечания ревью и список решений, которые всё равно должен принять человек.

Это третья и финальная часть серии. В первой я показал что такое Claude Code и почему я называю его командой из 15. Во второй - десять настроек, которые эту команду делают управляемой: CLAUDE.md на 30 строк, permissions, хуки, совещание ботиков через Codex и Gemini, Context Rot.

Сегодня про следующий уровень. Когда конфиги настроены и работаешь каждый день, упираешься в новый потолок. Даже команда из 15 человек внутри одной сессии Claude имеет предел. Субагенты конкурируют за контекст, ветки мешают друг другу, ты переключаешься между задачами и теряешь состояние.

Дальше начинается параллелизм, автоматизация и автономия. Десять приёмов, которые превращают Claude Code из "умного помощника" в систему из отдельных агентов, scheduled tasks и CI-задач.

И в конце - честный разговор про то, куда всё это идёт в 2027 и что останется разработчику.

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

В этой статье я пробую сформулировать облегчённую методологию разработки для кросс-функциональных команд. Центральная идея — явный handover: задача не переходит молча, каждая передача — это осознанное действие с контекстом. По идее, методология должна одинаково работать, когда в команде 3 человека, 15 человек, или когда один или несколько из «участников» — AI-агенты. Это концепт, идея, черновик, открытый для критики и комментариев.

---

## Откуда это взялось

Я руковожу центром разработки клиентских и аналитических решений — 50+ человек в семи кросс-функциональных командах с разными стеками. Аналитики, разработчики, QA, DevOps, сопровождение — всё в одной цепочке, от детализации требований до эксплуатации.

За несколько лет мы перепробовали стандартный набор: Scrum, Kanban, Scrumban. Каждый из них решал что-то своё, но во всех трёх я обнаружил одинаковый пробел.

Ни одна из методологий не отвечает на вопрос: что происходит, когда задача переходит от одной роли к другой?

Вот разработчик написал код и поставил статус «Готово к тестированию». Что дальше? Тестировщик это видит? Знает контекст? Понимает, что конкретно нужно проверить? А если тестировщик заболел — задача просто лежит? Кто за это отвечает?

Ни Scrum, ни Kanban на эти вопросы не отвечают. Они описывают итерации, доски, роли — но не сам момент передачи. А именно там живёт большинство операционных потерь.

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

$800 на видеокарту которая устареет через год или $200/мес с доступом к frontier-моделям? Вот мои цифры

Платформы вроде Character.AI и Replika позиционируют ИИ компаньонов как друга, который всегда рядом, не осуждает и точно знает, что ответить. Миллионы людей по всему миру заменяют ими реальное общение. Последствия уже не гипотетические.

В США после череды громких исков к Character.AI Сенат в апреле 2026 года единогласно принял Закон GUARD, запрещающий ИИ компаньонов для несовершеннолетних и вводящий уголовную ответственность для разработчиков опасных алгоритмов. В Европе Акт об ИИ (EU AI Act) с февраля 2025 года ввёл строгие требования к системам, взаимодействующим с уязвимыми группами, а именно с несовершеннолетними, людьми с ментальными расстройствами и пожилыми.

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

Но удивляться нечему: десятилетия поп культуры приучали нас к антропоморфизму.

В AI-first разработке в продукт прилетает всё больше pull request от людей с разной глубиной контекста. Формально такие PR могут выглядеть нормально, но ревью всё чаще упирается не в синтаксис, а в попытку понять, что именно этот набор изменений делает с системой.

В статье - почему обычного ревью уже не всегда хватает и как из этой проблемы вырос PRShield: рабочий MVP слоя, который помогает принимать решение перед мержем.

Если вы пользуетесь только интерфейсами социальных сетей и видеохостингов, поглощая рекомендации алгоритмов и ежедневно машинально пролистывая одну и ту же горстку сайтов, то по-настоящему живого интернета не видели. Такой опыт раскрывает, пожалуй, лишь 3–5% от реального потенциала веб-среды.

Да, для подавляющего числа людей интернет умирает. Они живут внутри контролируемых алгоритмами эхо-камер, из которых никогда не вырвутся. Живут и умирают, видя только то, что им «положено видеть». Но это не приговор, и всё вполне может быть иначе.

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

Это неизбежно должно было случиться: искусственный интеллект докатился и до Linux. Один из самых популярных дистрибутивов, Ubuntu, готовится к внедрению нейросетей. К слову, обсуждение этой новости на официальном форуме вышло настолько жарким, что модераторам пришлось включать медленный режим, чтобы хоть как-то усмирить поток комментариев. Давайте и мы попробуем разобраться что там и как. Поехали!

AI уже меняет не только то, как пишется код, но и то, как вообще надо проектировать инженерную среду вокруг разработки. Разбираем Thoughtworks Technology Radar Vol. 34 не как список модных трендов, а как сигнал сдвига: почему context engineering, zero trust, harness engineering и quality gates для coding agents становятся частью обычной практики engineering manager’ов, архитекторов и техлидов.

Чтобы не зависеть от онлайн-сервисов с их лимитами, очередями и закрытыми настройками, локальный генератор изображений можно собрать прямо на своём компьютере. Такой подход даёт больше контроля: можно самостоятельно выбирать модель, менять параметры генерации, подключать LoRA, использовать апскейл, ControlNet и другие инструменты.

Это - ответ на статью "Ваш текст воняет GPT. 12 мест, откуда несёт и почему".

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

Вы можете представить мое удивление, когда сами нажмете на этот тег. "Технотекст 8" - это, как оказалось, "ежегодный конкурс технических статей", и в правилах конкурса четко написано, что оставь надежду, ИИ сюда входящий "Статья написана человеком, при создании статьи не использовался искусственный интеллект". Как же так, явне сгенеренная статья номинирована на конкурс? Что это, fraud или scum? Давайте разбираться вместе.

Прежде всего надо понимать всю иронию происходящего. Текст, который сгенерирован ИИ, подается на конкурс, куда не допускаются тексты, сгенеренные ИИ. И при этом этот текст рассказывает нам, как распознать тексты, сгенеренные ИИ. Что же это, автор сам себе сгенерировал вырыл могилу? Это - интересный вопрос, но мы его рассмотрим чуть позже, а пока я расскажу, что смутило лично меня.

Первое, за что зацепился мой непрофессиональный взгляд, это фраза в самом начале:

Это продолжение первого поста. Там был манифест — сухой, академический, про три опоры устойчивого ИИ. Здесь — то, что происходит когда ты перестаёшь писать манифесты и начинаешь строить.

Привет, Хабр. Это мой первый пост здесь, поэтому пара слов о себе.

Я практикующий юрист, 8+ лет практики, последние годы - в производственном секторе. Веду договорную работу (поставка, подряд, услуги), сопровождаю сделки, закрываю претензионку и представляю компанию в арбитражных судах и спорах по защите прав потребителей - на стороне производителя и поставщика. К коду пришёл через вайбкодинг: захотелось автоматизировать некоторые процессы, начал ковыряться в VS Code, Trae, Cursor и Claude Code, втянулся - и теперь это параллельное хобби рядом с основной практикой.

Последние несколько месяцев пилю IP Agent - телеграм-бота, который по запросу находит релевантную судебную практику и даёт прогноз по размеру компенсации в делах об интеллектуальной собственности. Работает на RAG-пайплайне.

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