А король-то голый! Как написать свой Claude Code в 200 строках кода

В Claude code есть:

• Режим планирования

• Thinking

• Модель безопасности и пользовательских разрешений

• Параллельный запуск специализированных субагентов

• Защита от слишком большого ответа инструмента (например, при чтении огромного файла или результата выполнения шелл-команды, или списка файлов или http-ответа итд)

• Автоматическое и ручное сжатие контекста

• Поддержка пользовательских скиллов

• MCP позволяющий подключать любые сторонние тулы

• ACP позволяющий использовать Клода через API. Например, встраивать его в интерфейс IDE

• Настройки, кастомные промпты, кастомные команды и правила безопасности уровня проекта и пользователя

• Интеграция с IDE (видит открытый в данный момент файл и выделенную строку)

• Инструмент редактирования файлов, основанный на diff

• Предпросмотр изменений файла

• Запуск шелл-команд в фоне и управление фоновыми процессами

• Откат беседы и кода к предыдущим состояниям

• База данных всех бесед с возможностью вернуться к любой из них

• Динамический UI написанный на Ink, вылизанный почти до совершенства множеством итераций, основанных на тысячах пользовательских issues.

Это здоровенная махина, и ни в 200, ни в 20000 строк его не запихнуть.

А так-то да, написание helloworld-агента у вас прекрасно проиллюстрировано, но не стоит забывать, что реальные "промышленные" агенты — это 99.9% сложной логической обвязки, 0.1% LLM-вызовов.

Reader3: Андрей Карпаты выпустил легковесную читалку для книг с интеграцией LLM

Когда ж уже сделают читалку PDF, которая на лету будет делать текст респонсивным, чтобы не приходилось на смартфоне увеличивать страницу и скроллить её влево-вправо, чтобы прочитать... Но при этом, чтобы ещё и таблицы превращались в древовидные списки, которые легко читать на смартфоне, и иллюстрации нормально вписывались бы в текст. Я с такой читалки и вручную не поленился бы что-то там "в LLM копировать"

Русский JavaScript — это не баг, это фича будущего. Представляю RJS

Шутки шутками, а тут разработчики на полном серьёзе пилят аналогичный проект. Там раньше интерпретатор был на JS, потом запилили версию языка, компилирующуюся а LLVM. А вы говорите.

Рейтинг лучших пранк-ботов в тг для телефонного розыгрыша друзей

Текст буквально сквозит LLMщиной...

Go: жарим общие данные. Атомно, быстро и без мьютексов

У меня на лэптопе Ryzen 9 (Linux 6.8.0-39-generic) на вашем 4-поточном тесте результаты следующие:

❯ ./t_atom ; ./t_mut
Time 4.179402911s
Sum 0
Time 7.681173311s
Sum 0

Ну, то есть, мьютексов уже проигрывают, но не прямо в 10 раз

Go: жарим общие данные. Атомно, быстро и без мьютексов

Это какая-то мистика прямо. Я запустил ваши тесты на голом линуксе без всякой виртуализации на той же машине, на которой запускал до этого их в WSL2.

Результаты на скриншоте. На той машине (AMD Ryzen 9) атомики медленнее, чем мьютексы, пусть и не настолько сильно.

Атомики медленнее в следующих средах:

1. мой лэптоп AMD Ryzen 9:
- голая винда
- голый линукс
- линукс через WSL

2. AMD EPYC 7763 64-Core в облачном контейнере, где выполняется Github Actions

Атомики быстрее:

- линукс на Android-смартфоне через Termux (практически на голом железе). Там arm64.

Это просто все машины, до которых я смог сегодня дотянуться.

Исходники тестов - ваши, без изменений: https://github.com/harnyk/go-atomic-vs-mutex/tree/master/kamenev .

Пакет testing, как и договаривались, не использую, гоняю скомпилированные бинарники.

Go: жарим общие данные. Атомно, быстро и без мьютексов

У меня какие-то странные бенчмарки получаются. Почему-то атомики работают медленнее, чем мьютексы.

Подскажите, может, я где-то проявил невнимательность?

https://github.com/harnyk/go-atomic-vs-mutex