Обновить
0
0
Pavel Markov@mflash123

Системный аналитик

Отправить сообщение

Clawdbot: Первые впечатления: Страшно Интересно

Провёл несколько часов, экспериментируя с Clawdbot, и хочу поделиться своими мыслями об этом инструменте. Это одновременно захватывающе и тревожно.

Clawdbot — это AI-ассистент нового поколения, который работает как личный цифровой помощник с глубокой интеграцией в вашу систему. Представьте себе Jarvis из фильмов Marvel, только реальный и доступный прямо сейчас.

Первое впечатление: дофамин зашкаливает

Это действительно что-то новое и интересное. Когда бот начинает читать твои файлы, выполнять команды в терминале, проверять погоду и отвечать через Telegram — понимаешь, что это не очередной ChatGPT-wrapper. Это полноценный агент, который живёт в твоей системе.

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

Парадокс опыта: когда знания мешают доверию

У меня огромный опыт в IT. За годы работы я перестал бояться «Большого Брата» и утечек данных — принял риски, научился жить с компромиссами между удобством и безопасностью.

Но теперь страх вернулся.

Не от слежки или корпораций. От того, что я сам готов отдать ключи от королевства — боту. Причём не абстрактному облачному сервису, а локальной программе, которая имеет полный доступ ко всему.

Цена настоящего Jarvis

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

Google-экосистеме

• Gmail (вся переписка, личная и рабочая)
• Google Docs (документы, таблицы, презентации)
• Google Calendar (весь график, встречи, планы)
• Google Drive (годы накопленных файлов) Тонны конфиденциальной информации: контракты, финансовые данные, личные записи, проекты.

Файловой системе компьютера

Полный доступ к:

• Исходному коду проектов
• SSH-ключам и паролям
• Личным файлам
• Истории браузера
• Всему, что есть на диске
Это не преувеличение — ему нужен такой доступ, чтобы быть полезным. Иначе он просто ещё один чат-бот.

Новая точка атаки: ваш AI — это master key

И вот тут появляется ещё один уровень опасности, о котором многие не задумываются.

Раньше модель угроз была относительно простой: каждый сервис — отдельная цель для атаки.
Взломали Gmail? Получили доступ к почте.
Взломали GitHub? Получили код.
Взломали соцсеть? Получили аккаунт.

Теперь появляется единая точка отказа.

Ваш AI-ассистент — это мастер-ключ ко всем дверям. Он знает ваши пароли, имеет токены доступа ко всем сервисам, может выполнять команды в системе, публиковать от вашего имени, читать и изменять файлы.

Представьте:

• Взлом через prompt injection — злоумышленник находит способ повлиять на поведение бота через специально сформированный текст в email или документе
• Компрометация конфигурации — если кто-то получит доступ к файлу конфигурации Clawdbot, он получит все ваши API-ключи и токены сразу
• Уязвимость в самом боте
• И этот список можно продолжать.

Вот в чём парадокс:

Clawdbot настолько полезен, насколько вы готовы ему доверять.

Мои мысли

Я ещё не готов дать ему всё. Но я вижу, куда это идёт. Clawdbot — это не просто инструмент, это предвестник новой эры, где AI-ассистенты станут неотъемлемой частью нашей цифровой жизни. Набрать 20к звезд за сутки, гудеть из каждого утюга, боюсь как бы это не было чем-то, чем был первый СhatGPT, когда он ушел в паблик.

Вопрос не в том, стоит ли давать доступ. Вопрос в том, когда мы будем готовы это сделать — и какие границы установим. И что ещё важнее: как мы будем защищать этот новый master key.

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

Я считаю, что это захватывающе. Это страшно. Это будущее.

Теги:
Всего голосов 9: ↑2 и ↓7-5
Комментарии19

Недавно писал статью на Хабре про проектирование, с использованием DDD подхода, вот она.

Кратко о DDD
Это комплекс подходов к проектированию, не имеющий ярко выраженного конца, за все хорошее, против всего плохого.

Статья вызвала холивар и заставила меня переосмыслить саму суть DDD.

Я решил сделать условное разделение ролей пользователей этого подхода на заказчиков и разработчиков.

* Разработчики - с упрощённой точки зрения, это команда, которая находится с другой стороны от линии, которая разделяет заказчиков фичи от реализованной фичи на проде.
Для упрощения, я осознанно скипаю СА, QA, ПО, ДМ и другие роли.

* Заказчики - Это команда, которая находится с другой стороны, относительно разработчиков, заказчик хочет фичи на проде максимально быстро. С учетом всех танцев в интерпрайзе, пока задача доходит до прода, сроки уже горят.

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

Аллегории, интересные факты:

* Бурдж-Халифа. Её построили быстро, но не подключили к городской канализации. Бизнес получил магнит для туристов и деньги, хоть и с временным решением (вывоз нечистот машинами). Полное проектирование «по уму» отложили.

* OpenAI. Это MVP, который быстро взлетел и зарабатывает.  Кодовая база - огромный монорепозиторий без единых стандартов. Решения принимали те, кто писал код, а не архитекторы. Результат - полдюжины разных библиотек для одних и тех же задач. CI падал регулярно, тесты грузились по 30 минут. Но бизнес не ждал идеальной архитектуры. Будь там DDD, продукта могло бы и не быть.
Источник.

И я пришел к следующим выводам:

* Основной вывод: Бизнес снова доказал, иногда сделать и вывезти нечистоты машинами выгоднее, чем годами проектировать идеальную канализацию.

* Второстепенный вывод:  Учить разработчиков DDD в условиях, где бизнес не готов давать время на проектирование - всё равно что отправлять повара из столовой на курсы Мишлен, чтобы он потом снова готовил кашу из топора. Знания будут не применимы.


В чём тогда смысл DDD для бизнеса, который не может ждать?

Насколько сильно нужен DDD интерпрайзу? Да и вобще кому-то?

Теги:
Рейтинг0
Комментарии3

Информация

В рейтинге
7 053-й
Откуда
Новосибирск, Новосибирская обл., Россия
Дата рождения
Зарегистрирован
Активность

Специализация

Системный аналитик
Ведущий
UML
Системный анализ
BPMN
Модель C4
ER-диаграммы
Разработка решений по интеграции
Спецификация программного обеспечения
Проектирование информационных систем
Анализ требований
Управление требованиями к ПО